[Bug c++/52874] Which directory in gcc contains error or exception message templates?

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52874

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andrew Pinski  2012-04-05 
05:19:55 UTC ---
"segmentation fault" is part of the shell IIRC.  I think you want to look into
perror.  But that is all libc and not part of GCC.

[Bug c++/52875] New: ADL failure + ICE in decltype

[dave at boostpro dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52875

 Bug #: 52875
   Summary: ADL failure + ICE in decltype
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boostpro.com


Created attachment 27095
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27095
reproducer

I get:


y.cpp: In substitution of 'template decltype (swap(x.a, y.a)) swap(T&,
T&) [with T = A]':
y.cpp:11:17:   required by substitution of 'template decltype
(swap(x.a, y.a)) swap(T&, T&) [with T = B]'
y.cpp:20:14:   required from here
y.cpp:11:17: error: 'swap' was not declared in this scope
y.cpp:11:17: note: suggested alternative:
y.cpp:11:17: note:   'swap'
y.cpp: In substitution of 'template decltype (swap(x.a, y.a)) swap(T&,
T&) [with T = A]':
y.cpp:11:17:   required from here
y.cpp:11:17: error: 'swap' was not declared in this scope
y.cpp:11:17: note: suggested alternative:
y.cpp:11:17: note:   'swap'
'
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/52874] Which directory in gcc contains error or exception message templates?

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52874

--- Comment #1 from Paolo Carlini  2012-04-05 
05:03:45 UTC ---
Do you *really* believe this is a Bug, and as such, Bugzilla is the proper
place to handle it?

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

[amodra at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839

--- Comment #14 from Alan Modra  2012-04-05 04:00:07 
UTC ---
Created attachment 27094
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27094
config patch

Yes, the 32-bit failure seems to be gone if we use the gcc builtin atomics. 
Multiple copies of the testcase have been running now for an hour and half, and
no testsuite regressions with the attached patch.

[Bug c++/52874] New: Which directory in gcc contains error or exception message templates?

[mahdy.khayyamian at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52874

 Bug #: 52874
   Summary: Which directory in gcc contains error or exception
message templates?
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mahdy.khayyam...@gmail.com


Hi,

I wonder where are the files or directories that contain the error messages or
exceptions that is shown to the user?

I would like to make a dictionary of all the error messages which is output to
the user in g++ for a text mining task. For example where does "segmentation
fault" message text is stored and so on.


Any idea?

-Mahdy

[Bug rtl-optimization/52838] [x32] missed optimization for pointer return value

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52838

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #3 from H.J. Lu  2012-04-05 00:46:13 
UTC ---
(In reply to comment #2)
> The existence of (subreg/s/u:SI (reg:DI 60) 0) means that (reg:DI 60) is known
> to be a zero-extended 32-bit value, so the optimization is valid (and useful).

Can we somehow keep the knowledge that it is a zero-extended 32-bit value?
It is useful for encoding purpose.

[Bug bootstrap/52840] bootstrap fails in libstdc++, missing compatibility.lo

[bkoz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52840

Benjamin Kosnik  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
 CC||bkoz at gcc dot gnu.org
   Host||x86_64-linux-gnu
  Build||x86_64-linux-gnu

--- Comment #3 from Benjamin Kosnik  2012-04-05 
00:42:48 UTC ---

This patch is ok.

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

[amodra at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839

--- Comment #13 from Alan Modra  2012-04-04 23:02:34 
UTC ---
Huh, so glibc has a powerpc specific pthread_once, and that one has a different
bug.  Lack of lwsync before atomic_increment (once_control);

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

[amodra at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839

--- Comment #12 from Alan Modra  2012-04-04 22:27:43 
UTC ---
glibc/ntpl/pthread_once.c:

static int once_lock = LLL_LOCK_INITIALIZER;

int
__pthread_once (once_control, init_routine)
 pthread_once_t *once_control;
 void (*init_routine) (void);
{
  /* XXX Depending on whether the LOCK_IN_ONCE_T is defined use a
 global lock variable or one which is part of the pthread_once_t
 object.  */
  if (*once_control == PTHREAD_ONCE_INIT)
{
  lll_lock (once_lock, LLL_PRIVATE);

  /* XXX This implementation is not complete.  It doesn't take
 cancelation and fork into account.  */
  if (*once_control == PTHREAD_ONCE_INIT)
{
  init_routine ();

  *once_control = !PTHREAD_ONCE_INIT;
}

  lll_unlock (once_lock, LLL_PRIVATE);
}

  return 0;
}
strong_alias (__pthread_once, pthread_once)

This is quite broken for weakly ordered memory model.  Notice how a thread that
sees *once_control != PTHREAD_ONCE_INIT has no barriers at all.  That means the
read of *once_control has no ordering with respect to what happened on the
thread that ran init_routine.

[Bug rtl-optimization/52838] [x32] missed optimization for pointer return value

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52838

--- Comment #2 from Eric Botcazou  2012-04-04 
21:41:02 UTC ---
> This looks like a combine problem:
> 
> (insn 8 6 9 2 (set (reg/f:SI 59 [ D.1705 ])
> (subreg/s/u:SI (reg:DI 60) 0)) pr52838.c:6 64 {*movsi_internal}
>  (expr_list:REG_DEAD (reg:DI 60)
> (nil)))
> 
> (insn 9 8 10 2 (set (reg/f:DI 62 [ D.1705 ])
> (zero_extend:DI (reg/f:SI 59 [ D.1705 ]))) pr52838.c:6 112
> {*zero_extendsidi2_rex64}
>  (expr_list:REG_DEAD (reg/f:SI 59 [ D.1705 ])
> (nil)))
> 
> This gets transformed by combine pass:
> 
> 
> Trying 8 -> 9:
> Successfully matched this instruction:
> (set (reg/f:DI 62 [ D.1705 ])
> (reg:DI 60))
> deferring deletion of insn with uid = 8.
> modifying insn i3 9 r62:DI=r60:DI
>   REG_DEAD: r60:DI
> 
> into:
> 
> (note 8 6 9 2 NOTE_INSN_DELETED)
> 
> (insn 9 8 10 2 (set (reg/f:DI 62 [ D.1705 ])
> (reg:DI 60)) pr52838.c:6 62 {*movdi_internal_rex64}
>  (expr_list:REG_DEAD (reg:DI 60)
> (nil)))
> 
> But, but ... high 32 bits are not cleared anymore!

The existence of (subreg/s/u:SI (reg:DI 60) 0) means that (reg:DI 60) is known
to be a zero-extended 32-bit value, so the optimization is valid (and useful).

[Bug ada/37619] overriding Finalize gives: warning: declaration of "Finalize" hides one at line N

[nicolas.boulenguez at free dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37619

nicolas.boulenguez at free dot fr changed:

   What|Removed |Added

 CC||nicolas.boulenguez at free
   ||dot fr

--- Comment #4 from nicolas.boulenguez at free dot fr 2012-04-04 21:32:44 UTC 
---
Reproduced with 4.6.3 (-gnatwh).
Removing the private separator removes the warning.

package Bug is
   type T1 is tagged null record;
   procedure P (Object : T1);
   type T2 is private;
private
   type T2 is new T1 with null record;
   overriding procedure P (Object : T2);
end Bug;

[Bug libitm/52854] [x32] libitm failures on x32

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52854

Uros Bizjak  changed:

   What|Removed |Added

 Target||x32
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.1

--- Comment #4 from Uros Bizjak  2012-04-04 21:22:19 
UTC ---
Fixed.

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839

--- Comment #11 from Jonathan Wakely  2012-04-04 
20:22:57 UTC ---
I can reproduce this with -m32 on gcc110

If I compile with -D_GLIBCXX_ATOMIC_BUILTINS then I no longer get the
double-free, after running in a loop for several minutes - can you confirm
that?

That implies the bug is in the non-atomic builtin fallback code in
config/cpu/generic/atomicity_mutex/atomicity.h which defines __exchange_and_add
like so:

  _Atomic_word
  __attribute__ ((__unused__))
  __exchange_and_add(volatile _Atomic_word* __mem, int __val) throw ()
  {
__gnu_cxx::__scoped_lock sentry(get_atomic_mutex());
_Atomic_word __result;
__result = *__mem;
*__mem += __val;
return __result;
  }

This basically does a pthread_mutex_lock on a function-local static
pthread_mutex_t.  Could this also be a problem in the underlying pthread lib?

I was surprised that _GLIBCXX_ATOMIC_BUILTINS is not automatically defined, but
indeed 32/libstdc++-v3/config.log shows:

configure:15247: checking for atomic builtins for long long
configure:15276: /home/jwakely/build/./gcc/xgcc -shared-libgcc
-B/home/jwakely/build/./gcc -nostdinc++
-L/home/jwakely/build/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src
-L/home/jwakely/build/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-B/home/jwakely/gcc/4.x/powerpc64-unknown-linux-gnu/bin/
-B/home/jwakely/gcc/4.x/powerpc64-unknown-linux-gnu/lib/ -isystem
/home/jwakely/gcc/4.x/powerpc64-unknown-linux-gnu/include -isystem
/home/jwakely/gcc/4.x/powerpc64-unknown-linux-gnu/sys-include  -m32 -fPIC
-mstrict-align -o conftest -g -O2 -D_GNU_SOURCE -fno-exceptions   conftest.cpp 
>&5
/tmp/cck5YUAJ.o: In function `main':
/home/jwakely/build/powerpc64-unknown-linux-gnu/32/libstdc++-v3/conftest.cpp:30:
undefined reference to `__atomic_fetch_add_8'
/home/jwakely/build/powerpc64-unknown-linux-gnu/32/libstdc++-v3/conftest.cpp:32:
undefined reference to `__atomic_compare_exchange_8'

It seems unfortunate that we can't use __exchange_and_add on a 4-byte int just
because the platform doesn't provide atomic ops for 64-bit types.

[Bug c++/24985] caret diagnostics

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985

Jason Merrill  changed:

   What|Removed |Added

  Attachment #27092|0   |1
is obsolete||

--- Comment #21 from Jason Merrill  2012-04-04 
19:19:21 UTC ---
Created attachment 27093
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27093
Patch to prune caret diagnostics from gcc output

Actually, this seems like a better approach: rather than disable the caret
diagnostics, prune them from the output.  This regexp will remove any pair of
lines where the first starts with a space and the second consists of spaces
followed by a caret.

[Bug rtl-optimization/52838] [x32] missed optimization for pointer return value

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52838

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-04
 CC||ebotcazou at gcc dot
   ||gnu.org
  Component|target  |rtl-optimization
 Ever Confirmed|0   |1

--- Comment #1 from Uros Bizjak  2012-04-04 19:06:57 
UTC ---
This looks like a combine problem:

(insn 8 6 9 2 (set (reg/f:SI 59 [ D.1705 ])
(subreg/s/u:SI (reg:DI 60) 0)) pr52838.c:6 64 {*movsi_internal}
 (expr_list:REG_DEAD (reg:DI 60)
(nil)))

(insn 9 8 10 2 (set (reg/f:DI 62 [ D.1705 ])
(zero_extend:DI (reg/f:SI 59 [ D.1705 ]))) pr52838.c:6 112
{*zero_extendsidi2_rex64}
 (expr_list:REG_DEAD (reg/f:SI 59 [ D.1705 ])
(nil)))

This gets transformed by combine pass:


Trying 8 -> 9:
Successfully matched this instruction:
(set (reg/f:DI 62 [ D.1705 ])
(reg:DI 60))
deferring deletion of insn with uid = 8.
modifying insn i3 9 r62:DI=r60:DI
  REG_DEAD: r60:DI

into:

(note 8 6 9 2 NOTE_INSN_DELETED)

(insn 9 8 10 2 (set (reg/f:DI 62 [ D.1705 ])
(reg:DI 60)) pr52838.c:6 62 {*movdi_internal_rex64}
 (expr_list:REG_DEAD (reg:DI 60)
(nil)))

But, but ... high 32 bits are not cleared anymore!

Confirmed as a rtl optimization issue, adding CCs for their opinion.

[Bug c++/24985] caret diagnostics

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985

--- Comment #20 from Manuel López-Ibáñez  2012-04-04 
18:52:32 UTC ---
(In reply to comment #19)
> Created attachment 27092 [details]
> Patch to add -fno-diagnostics-show-caret for testing
> 
> This seems like what you want for the last bit.

Great, this works for C++, however, the caret is enabled for diagnostic that
uses the diagnostics machinery, independently of the language (for example,
warnings from the middle-end). If there is no general way, I guess I can do
this for every language.

[Bug c++/24985] caret diagnostics

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985

--- Comment #19 from Jason Merrill  2012-04-04 
18:47:58 UTC ---
Created attachment 27092
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27092
Patch to add -fno-diagnostics-show-caret for testing

This seems like what you want for the last bit.

[Bug ada/52873] New: A.18.2 Vectors To_Index (C) = 0 though C /= No_Element

[nicolas.boulenguez at free dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52873

 Bug #: 52873
   Summary: A.18.2 Vectors To_Index (C) = 0 though C /= No_Element
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nicolas.bouleng...@free.fr


--  Last line raises Constraint_Error.
--  To_Index (C) = 0 though C /= No_Element.

with Ada.Containers.Vectors; --  A.18.2
procedure Bug is
   package V1s is new Ada.Containers.Vectors (Positive, Integer);
   V1 : constant V1s.Vector := V1s.To_Vector (0, 1);
   package V2s is new Ada.Containers.Vectors (Positive, V1s.Vector, V1s."=");
   V2 : constant V2s.Vector := V2s.To_Vector (V1, 1);
   C  : constant V1s.Cursor := V1s.First (V2s.First_Element (V2));
   I  : constant Integer := V1s.Element (C);
begin
   null;
end Bug;

[Bug bootstrap/52867] Compilation of gcc-4.4.7 with gcc-4.2.4 fails on arm platform

[surrano at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52867

--- Comment #2 from Szűcs, Gábor  2012-04-04 18:28:52 
UTC ---
(In reply to comment #1)
> GCC 4.4 series is now end-of-life.  No further maintenance is planned.  Please
> upgrade to a more recent set of sources

Hello,

Thanks for the feedback; since 4.4.7 was released less than a month ago I was
not aware of this. The reason of choosing 4.4 was that I didn't dare to go
upper in versions.

The good news is that, after another "make distclean" compiler got beyond
c-common.c and eventually going forward...

Accepting your statement, please advise what is the best bet for a compiler for
such an archaic architecture (considering that Lenny is last of Debian that
supports arm; Squeeze supports only armel). Does it make sense to even try
compiling e.g. 4.7, or I should stay as low as possible, with 4.5 being the
oldest one maintained? (none beyond 4.4 list armv5 in "successful builds")

Generally speaking; is there a list on supported architectures / cpus at least?

Thanks in advance,
G.

[Bug bootstrap/52867] Compilation of gcc-4.4.7 with gcc-4.2.4 fails on arm platform

[rearnsha at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52867

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Richard Earnshaw  2012-04-04 
18:17:22 UTC ---
GCC 4.4 series is now end-of-life.  No further maintenance is planned.  Please
upgrade to a more recent set of sources

[Bug libstdc++/52689] static linking with libstdc++ fails

[uros at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689

--- Comment #16 from uros at gcc dot gnu.org 2012-04-04 17:25:41 UTC ---
Author: uros
Date: Wed Apr  4 17:25:27 2012
New Revision: 186142

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186142
Log:
Partially revert:
2012-03-28  Benjamin Kosnik  

PR libstdc++/52689
* src/c++98/compatibility-ldbl.cc: Guard with PIC


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++98/compatibility-ldbl.cc

[Bug libstdc++/52689] static linking with libstdc++ fails

[bkoz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689

--- Comment #15 from Benjamin Kosnik  2012-04-04 
17:23:52 UTC ---
Patch in comment #13 is ok to check in, sadly.

[Bug plugins/52872] --enable-plugin; incorrrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac

[rai...@emrich-ebersheim.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872

--- Comment #2 from Rainer Emrich  2012-04-04 
17:22:19 UTC ---
(In reply to comment #1)
> It really won't change that much as -rdynamic and exported symbols are not
> supported on windows right now anyways.

Agreed, but I think it's pretty easy to correct this at least on trunk, before
it bites us later on.

[Bug c++/52871] segmentation fault with wrongly-formed lambdas

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52871

--- Comment #1 from Jonathan Wakely  2012-04-04 
17:22:09 UTC ---
already fixed in 4.7.0, this is almost certainly a dup of PR 47687

[Bug plugins/52872] --enable-plugin; incorrrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872

--- Comment #1 from Andrew Pinski  2012-04-04 
17:18:22 UTC ---
It really won't change that much as -rdynamic and exported symbols are not
supported on windows right now anyways.

[Bug plugins/52872] New: --enable-plugin; incorrrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac

[rai...@emrich-ebersheim.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872

 Bug #: 52872
   Summary: --enable-plugin; incorrrect test for "exported
symbols" and "-rdynamic" in gcc/configure.ac
Classification: Unclassified
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rai...@emrich-ebersheim.de


On systems with non empty $exeext the configure tests are failing with:

checking for exported symbols...
d:\opt\devel\gnu\gcc\MINGW_NT\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-4.6.1\bin\objdump.exe:
'conftest': No such file
checking for -rdynamic...
d:\opt\devel\gnu\gcc\MINGW_NT\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-4.6.1\bin\objdump.exe:
'conftest': No such file

All active branches are affected!

possible patch against trunk, see below.

I'm not really sure if this is the right thing to do for a cross setup or if we
have to use $host_exeext. Anyway, something along the lines should fix it, al
least for a native bootstrap.


diff -Naur gcc-trunk/gcc/configure.ac gcc-new/gcc/configure.ac
--- gcc-trunk/gcc/configure.ac  2012-03-29 18:25:52.789019300 +0200
+++ gcc-new/gcc/configure.ac2012-04-04 19:02:29.669435800 +0200
@@ -5021,14 +5021,14 @@
   if test "x$export_sym_check" != x; then
 echo "int main() {return 0;} int foobar() {return 0;}" > conftest.c
 ${CC} ${CFLAGS} ${LDFLAGS} conftest.c -o conftest > /dev/null 2>&1
-if $export_sym_check conftest | grep foobar > /dev/null; then
+if $export_sym_check conftest${exeext} | grep foobar > /dev/null; then
   : # No need to use a flag
   AC_MSG_RESULT([yes])
 else
   AC_MSG_RESULT([yes])
   AC_MSG_CHECKING([for -rdynamic])
   ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest > /dev/null
2>&1
-  if $export_sym_check conftest | grep foobar > /dev/null; then
+  if $export_sym_check conftest${exeext} | grep foobar > /dev/null; then
 plugin_rdynamic=yes
 pluginlibs="-rdynamic"
   else

[Bug libstdc++/52689] static linking with libstdc++ fails

[bkoz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689

--- Comment #14 from Benjamin Kosnik  2012-04-04 
17:06:09 UTC ---

Patch in comment #12 is ok to check in. Thanks!

[Bug middle-end/52861] (missed optimisation) missed transformation to memset with -O3

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52861

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||burnus at gcc dot gnu.org
  Component|fortran |middle-end

--- Comment #1 from Tobias Burnus  2012-04-04 
16:35:18 UTC ---
Regarding the first test cases:

For qq1.f, the loop remains and one gets in the loop:
MEM[base: isu_34(D), index: ivtmp.19_49, step: 4, offset: 0B] = 0;
__builtin_memcpy (D.1901_38, &""[0], 8);
MEM[base: rsv_45(D), index: ivtmp.19_49, step: 4, offset: 0B] = 0.0;


For qq2, the first loop is replaced by:
__builtin_memset (isu_35(D), 0, D.1935_54);
__builtin_memset (rsv_38(D), 0, D.1935_54);
while for the character string, the loop is kept.



For the rather common (Fortran) case of assigning blanks (" ") to a string (cf.
also the third test case), it would be good to replace the loop
__builtin_memcpy (D.1909_46, &""[0], 8);
by (outside the loop)
__builtin_memset (D.1909_46, " ", *);

[Bug c++/52871] New: segmentation fault with wrongly-formed lambdas

[volpyansky+gcc at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52871

 Bug #: 52871
   Summary: segmentation fault with wrongly-formed lambdas
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: volpyansky+...@gmail.com


Created attachment 27091
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27091
try to compile this using: g++-4.6 -g -std=c++0x x.cpp

Probably wrong syntax/understanding causing SEGV in gcc 4.5 and gcc 4.6


$ g++-4.6 -g -std=c++0x -v -save-temps x.cpp
Using built-in specs.
COLLECT_GCC=g++-4.6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6-20101220-1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default
--with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.0 20101220 (experimental) [trunk revision 168097]
(Ubuntu/Linaro 4.6-20101220-1) 
COLLECT_GCC_OPTIONS='-g' '-std=c++0x' '-v' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.6.0/cc1plus -E -quiet -v -D_GNU_SOURCE x.cpp
-mtune=generic -march=x86-64 -std=c++0x -g -fworking-directory -fpch-preprocess
-o x.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.6
 /usr/include/c++/4.6/x86_64-linux-gnu
 /usr/include/c++/4.6/backward
 /usr/lib/gcc/x86_64-linux-gnu/4.6.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.6.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-g' '-std=c++0x' '-v' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.6.0/cc1plus -fpreprocessed x.ii -quiet
-dumpbase x.cpp -mtune=generic -march=x86-64 -auxbase x -g -std=c++0x -version
-o x.s
GNU C++ (Ubuntu/Linaro 4.6-20101220-1) version 4.6.0 20101220 (experimental)
[trunk revision 168097] (x86_64-linux-gnu)
compiled by GNU C version 4.6.0 20101220 (experimental) [trunk revision
168097], GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu/Linaro 4.6-20101220-1) version 4.6.0 20101220 (experimental)
[trunk revision 168097] (x86_64-linux-gnu)
compiled by GNU C version 4.6.0 20101220 (experimental) [trunk revision
168097], GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: dfbc99081573568ba8a67f5ca3d62186
g++-4.6: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/52793] [4.8 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52793

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from H.J. Lu  2012-04-04 16:23:23 
UTC ---
Fixed as of revision 186097.  This could be a dup of PR 52756.

[Bug tree-optimization/52870] ICE during SLP pattern matching

[uweigand at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52870

Ulrich Weigand  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-04
 AssignedTo|unassigned at gcc dot   |uweigand at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Ulrich Weigand  2012-04-04 
15:56:06 UTC ---
It seems the problem is that vect_recog_widen_mult_pattern includes a statement
into a pattern it detects which is actually outside of the basic block that SLP
is currently operating on.  This later on causes the ICE since the statement
does not have an assigned stmt_vinfo.

I'm testing a fix.

[Bug tree-optimization/52870] New: ICE during SLP pattern matching

[uweigand at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52870

 Bug #: 52870
   Summary: ICE during SLP pattern matching
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: uweig...@gcc.gnu.org
Target: x86_64-linux-gnu


Building the following testcase with -O -ftree-vectorize on x86_64:

long
test (int *x)
{
  unsigned long sx, xprec;

  sx = *x >= 0 ? *x : -*x;

  xprec = sx * 64;

  if (sx < 16384)
foo (sx);

  return xprec;
}


results in an ICE:

crash1.c:5:1: internal compiler error: vector VEC(vec_void_p,base) index domain
error, in vinfo_for_stmt at tree-vectorizer.h:628

(When building with --disable-checking, we get a segmentation fault instead.)

[Bug libitm/52854] [x32] libitm failures on x32

[hjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52854

--- Comment #3 from hjl at gcc dot gnu.org  2012-04-04 
15:51:23 UTC ---
Author: hjl
Date: Wed Apr  4 15:51:15 2012
New Revision: 186141

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186141
Log:
Use long long in gtm_jmpbuf for x86-64

2012-04-04  H.J. Lu  

Backported from mainline
2012-04-04  H.J. Lu  

PR libitm/52854
* config/x86/target.h (gtm_jmpbuf): Replace long with long long
for x86-64.

Modified:
branches/gcc-4_7-branch/libitm/ChangeLog
branches/gcc-4_7-branch/libitm/config/x86/target.h

[Bug c++/52762] Firefox 11 segfault with gcc 4.7 (-O3 -march=corei7-avx)

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52762

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-04-04
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #9 from Jason Merrill  2012-04-04 
15:51:18 UTC ---
I'll put it in Waiting until we have a testcase smaller than Firefox.

[Bug c++/24985] caret diagnostics

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #18 from Paolo Carlini  2012-04-04 
15:49:33 UTC ---
Oh my, Manuel, yesterday I was walking by myself and it occurred to me that I
didn't understand at all why we are not doing *already* what you are suggesting
now!! Of course the idea came from Jason's comment about using a script. I said
to myself: if we can do it so easily with a script, why can't we do it as part
of GCC itself?!? (I'm not touching at all the issues with existing bugs in the
column information, ranges, etc)

[Bug libitm/52854] [x32] libitm failures on x32

[hjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52854

--- Comment #2 from hjl at gcc dot gnu.org  2012-04-04 
15:49:31 UTC ---
Author: hjl
Date: Wed Apr  4 15:49:23 2012
New Revision: 186140

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186140
Log:
Use long long in gtm_jmpbuf for x86-64

2012-04-04  H.J. Lu  

PR libitm/52854
* config/x86/target.h (gtm_jmpbuf): Replace long with long long
for x86-64.

Modified:
trunk/libitm/ChangeLog
trunk/libitm/config/x86/target.h

[Bug c++/52869] New: "this" not being allowed in noexcept clauses

[dave at boostpro dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869

 Bug #: 52869
   Summary: "this" not being allowed in noexcept clauses
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boostpro.com


Given the following, GCC says: "error: invalid use of 'this' at top level"
However, according to [expr.prim.general]/3 'this'
should be valid in the exception-specification as it comes after the
member function's optional cv-qualifier-seq.

  #define RETURNS(...) noexcept(noexcept(__VA_ARGS__)) -> decltype(__VA_ARGS__)
 { return (__VA_ARGS__); } 

  struct mul_ {
  int operator()() const { return 1; }

  template 
  A operator()(A const & a) const noexcept(A(std::move(a))) { return a; }

  template 
  auto operator()(A const & a, B const & b, C const &... c) const
  RETURNS((*this)(a * b, c...))
  };

[Bug c++/52845] non-void return type deduced for lambda with empty compound statement

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52845

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Jason Merrill  2012-04-04 
15:44:54 UTC ---
Fixed.

[Bug tree-optimization/52868] New: [4.6/4.7/4.8 Regression] 4.6 is faster on Atom

[izamyatin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52868

 Bug #: 52868
   Summary: [4.6/4.7/4.8 Regression] 4.6 is faster on Atom
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com
Target: i386


Created attachment 27090
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27090
Testcase

For attached case 4.6 is ~10% faster than 4.7 and trunk.

IVopts works differently and it leads to performance degradation

THis is possibly related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272

Command line to reproduce:
-O2 -march=atom -m32 -mtune=atom -msse2 -static

[Bug target/52855] ARM: Internal compiler error: in extract_insn, at recog.c:2109

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52855

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target
   Severity|major   |normal

[Bug c++/24985] caret diagnostics

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985

--- Comment #17 from Manuel López-Ibáñez  2012-04-04 
15:28:08 UTC ---
Created attachment 27089
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27089
caret diagnostics patch

[Bug c++/52845] non-void return type deduced for lambda with empty compound statement

[mattipee at yahoo dot co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52845

--- Comment #2 from mattipee at yahoo dot co.uk 2012-04-04 15:29:49 UTC ---
r186139 works for me.

Thank you, Jason.
Matt.

[Bug c/52855] ARM: Internal compiler error: in extract_insn, at recog.c:2109

[mpthompson at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52855

--- Comment #1 from Mike Thompson  2012-04-04 
15:29:47 UTC ---
This bug can be reproduced using the standard gcc 4.6.3 packages that is part
of the Debian wheezy armhf port.  The command line to trigger the bug is:

 gcc -DPERL_CORE -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -D_FORTIFY_SOURCE=2 -g
-O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
-Werror=format-security -fno-strict-aliasing -pipe -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64   -O2 -g -Wall   -W -Wextra
-Wdeclaration-after-statement -Wendif-labels -Wc++-compat -Wwrite-strings -marm
-march=armv6 -mfpu=vfp -o cccPDUUP.o cccPDUUP.

The regular Debian wheezy gcc is configured with the following options:

Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-1'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a
--with-float=hard --with-fpu=vfpv3-d16 --with-mode=thumb
--enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix

[Bug c++/24985] caret diagnostics

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #16 from Manuel López-Ibáñez  2012-04-04 
15:26:50 UTC ---
@Jason,

This is my current patch. It directly opens the file a looks for the line. 

I see several improvements that could be made, like handling very long lines in
a smarter way, a cache of already opened files, and moving all this code to
libcpp (or even better to a separate liblinemap library). But there are
improvements that could be done post-commit.

This patch bootstraps for languages=all,ada with both the default set to off
and on, and regression tested with the default set to off, because I couldn't
find a good way to tell DejaGNU to always use -fno-diagnostics-show-caret. Does
anyone know the correct way to do this? This is the only missing piece.

If it looks ok to you, I will write a changelog and submit it to gcc-patches.

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Depends on||24985

--- Comment #39 from Manuel López-Ibáñez  2012-04-04 
15:27:35 UTC ---
Patch available for caret diagnostics in PR24985. It works!

[Bug tree-optimization/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop

[izamyatin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865

--- Comment #5 from Igor Zamyatin  2012-04-04 
15:20:41 UTC ---
Seems it doesn't like non-empty latch block in Fortran case

[Bug bootstrap/52867] New: Compilation of gcc-4.4.7 with gcc-4.2.4 fails on arm platform

[surrano at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52867

 Bug #: 52867
   Summary: Compilation of gcc-4.4.7 with gcc-4.2.4 fails on arm
platform
Classification: Unclassified
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: surr...@gmail.com


Initial note: I don't know if it qualifies as a bug for GCC-4.2.4 (current
compiler) or GCC-4.4.7 (target compiler) so please adjust if necessary.

Architecture: ARM (D-Link DNS-323)
OS: chroot-ed Debian 5.0 Lenny

GCC used for compilation: 4.2.4
Delorian:/home/gab/dev/gcc-obj# gcc -v
Using built-in specs.
Target: arm-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libssp --enable-checking=release
--build=arm-linux-gnu --host=arm-linux-gnu --target=arm-linux-gnu
Thread model: posix
gcc version 4.2.4 (Debian 4.2.4-6)

GCC to be compiled: 4.4.7

GMP is fresh download, to be compiled together with GCC (5.0.4)
MPFR is fresh download, to be compiled together with GCC (3.1.0)
PPL is NOT installed (hope it's not mandatory)

Configure command: 
export CFLAGS="-O0"
../gcc-4.4.7/configure --enable-languages=c,c++ --with-mode=arm --disable-nls
2>&1 | tee log.configure3

Description of error:
1. When compiling without CFLAGS="-O0" (defaults to "-g -O2"), compilation
fails while building fixincludes:

gcc -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -Wno-overlength-strings
-pedantic -Wno-long-long   -DHAVE_CONFIG_H -I. -I../../../gcc-4.4.7/fixincludes
-I../include -I../../../gcc-4.4.7/fixincludes/../include
../../../gcc-4.4.7/fixincludes/fixincl.c
../../../gcc-4.4.7/fixincludes/fixincl.c: In function 'run_compiles':
../../../gcc-4.4.7/fixincludes/fixincl.c:395: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

Trial-and-error showed that compile gets over this point if "-O0" is used. The
"-g" flag is irrelevant, it is "-O2" that causes the segfault.

2. When compiling again, it fails because mpfr.h is not found.
I got over it by issuing "make compile" in mpfr dir.

3. When compiling again, it fails while compiling gcc/c-common.c:

gcc -c  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I.
-I. -I../../gcc-4.4.7/gcc -I../../gcc-4.4.7/gcc/.
-I../../gcc-4.4.7/gcc/../include -I../../gcc-4.4.7/gcc/../libcpp/include
-I/home/gab/dev/gcc-obj/./gmp -I/home/gab/dev/gcc-4.4.7/gmp
-I/home/gab/dev/gcc-obj/./mpfr -I/home/gab/dev/gcc-4.4.7/mpfr 
-I../../gcc-4.4.7/gcc/../libdecnumber -I../../gcc-4.4.7/gcc/../libdecnumber/dpd
-I../libdecnumber../../gcc-4.4.7/gcc/c-common.c -o c-common.o
../../gcc-4.4.7/gcc/c-common.c: In function 'c_define_builtins':
../../gcc-4.4.7/gcc/c-common.c:3963: error: total size of local objects too
large
../../gcc-4.4.7/gcc/c-common.c:4036: confused by earlier errors, bailing out
The bug is not reproducible, so it is likely a hardware or OS problem.

I could not find any way to proceed forward with this.

Problem is reproducible on the command line when make fails, just by repeating
the appropriate gcc commands.

[Bug libstdc++/52866] [4.8 Regression] build with --enable-libstdcxx-debug fails in libstdc++

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52866

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-04
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-04-04 
15:07:11 UTC ---
Confirmed, I've had the same problem but not had time to debug it yet.

[Bug c++/52763] Warning if compare between enum and non-enum type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52763

--- Comment #4 from Jonathan Wakely  2012-04-04 
15:00:57 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > But what about cases such as (val1 == (ONE|TWO)) ?
> > 
> > (ONE|TWO) is of type 'int' but that code is correct and shouldn't warn
> 
> In my opinion, there should be a warning here, because (ONE|TWO) is not in the
> enumeration range (there is no definition for 3).

It is in range.  For enum { NONE = 0, ONE = 1, TWO = 2 } the standard says the
values of the enumeration are in the range 0 to 3, e.g. it could be represented
by a two-bit unsigned integer.  The standard sets the rules, not your opinion
:)

Also, that would warn for perfectly valid (and very common) uses of enumeration
types for bitmasks, e.g. std::ios::openmode could be defined as an enumeration
type and you could say

   if (mode == (std::ios::in|std::ios::out))

where there is no enumerator defined for in|out, but this code is common and
should not warn.

> If it was defined (e.g. typedef enum {NONE = 0, ONE = 1, TWO = 2, THREE = 3}
> tEnumType), result could again be of the enumeration type and there would be 
> no
> warning.

No, the result would still be an int, ONE|TWO has type int, period.

I think the warning could be useful in some cases, but it needs to be defined
much more carefully than simply "warning each time a enumeration type is
compared to a non enumeration type" as you suggested.

[Bug libstdc++/52866] New: [4.8 Regression] build with --enable-libstdcxx-debug fails in libstdc++

[doko at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52866

 Bug #: 52866
   Summary: [4.8 Regression] build with --enable-libstdcxx-debug
fails in libstdc++
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org


today's trunk fails to build, when configured with --enable-libstdcxx-debug

make[10]: Leaving directory
`/home/packages/gcc/snap/gcc-snapshot-20120404/build/x86_64-linux-gnu/libstdc++-v3/src/debug/c++11'
make[10]: Entering directory
`/home/packages/gcc/snap/gcc-snapshot-20120404/build/x86_64-linux-gnu/libstdc++-v3/src/debug'
make[10]: *** No rule to make target `compatibility.lo', needed by
`libstdc++.la'.  Stop.
make[10]: Leaving directory
`/home/packages/gcc/snap/gcc-snapshot-20120404/build/x86_64-linux-gnu/libstdc++-v3/src/debug'
make[9]: *** [all-recursive] Error 1

[Bug c++/52845] non-void return type deduced for lambda with empty compound statement

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52845

--- Comment #1 from Jason Merrill  2012-04-04 
14:40:58 UTC ---
Author: jason
Date: Wed Apr  4 14:40:51 2012
New Revision: 186139

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186139
Log:
PR c++/52845
* decl.c (finish_function): Update fntype after deducing return type.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-warn4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865

Tobias Burnus  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #4 from Tobias Burnus  2012-04-04 
14:26:18 UTC ---
Reopen for reconsideration by the GCC's vectorization experts.

[Bug fortran/52864] [4.6/4.7/4.8 Regression] Assignment to pointer component for INTENT(IN) dummy argument

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52864

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-04
 Ever Confirmed|0   |1

--- Comment #1 from Tobias Burnus  2012-04-04 
14:23:09 UTC ---
Interesting issue. The problem is that
  ptr = 
is valid while
  nonptr = 
is not. That was checked via "is_pointer". However, "ptr(1,1)" has is_pointer
== false (which is correct).

On the other hand, "check_intentin" handles both pointer assignments and normal
assignment. While for pointers:
  ptr%ptr => null()
is valid, the following isn't
  ptr => null()
By contrast,
  val = value
  val%val = value
are valid.

Solution: Set check_intentin differently for assignments than for pointer
assignments.

Draft patch.

--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4654,11 +4654,15 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer,
bool alloc_obj,
   for (ref = e->ref; ref && check_intentin; ref = ref->next)
 {
   if (ptr_component && ref->type == REF_COMPONENT)
check_intentin = false;
   if (ref->type == REF_COMPONENT && ref->u.c.component->attr.pointer)
-   ptr_component = true;
+   {
+ ptr_component = true;
+ if (!pointer)
+   check_intentin = false;
+   }
 }
   if (check_intentin && sym->attr.intent == INTENT_IN)
 {
   if (pointer && is_pointer)
{

[Bug c++/52763] Warning if compare between enum and non-enum type

[gccrepo...@gmx-topmail.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52763

--- Comment #3 from Mikka  2012-04-04 14:22:45 UTC 
---
(In reply to comment #2)
> But what about cases such as (val1 == (ONE|TWO)) ?
> 
> (ONE|TWO) is of type 'int' but that code is correct and shouldn't warn

In my opinion, there should be a warning here, because (ONE|TWO) is not in the
enumeration range (there is no definition for 3).
If it was defined (e.g. typedef enum {NONE = 0, ONE = 1, TWO = 2, THREE = 3}
tEnumType), result could again be of the enumeration type and there would be no
warning.

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

[amodra at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839

--- Comment #10 from Alan Modra  2012-04-04 14:20:57 
UTC ---
I caught the 64-bit failure in the act.  It's dying on the gcc_assert in
unwind-dw2.c:_Unwind_SetSpColumn, with the value read from
dwarf_reg_size_table[1] being zero.  The implication here is that
__gthread_once, ie. pthread_once, does not provide proper locking for the
power7 weakly ordered memory model.  It's too late here tonight to go delving
into libpthread to prove my case, but it certainly seems like the 64-bit
failure is not a gcc problem.

[Bug c++/52845] non-void return type deduced for lambda with empty compound statement

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52845

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-04
 CC||jason at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug tree-optimization/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||burnus at gcc dot gnu.org
  Component|fortran |tree-optimization

--- Comment #3 from Tobias Burnus  2012-04-04 
14:00:30 UTC ---
(In reply to comment #2)
>   DOUBLE PRECISION Dx(*) , Dy(*)
> and
>   double X[1000], Y[1000]
> are not at all the same.

But one still gets the same result if one uses:

  void daxpy(int m, int n, double X[], double Y[], double z)

which should be close to what one gets with Fortran.


 * * *

For the Fortran loop, -ftree-vectorizer-verbose=3 shows:

14: = analyze_loop_nest =
14: === vect_analyze_loop_form ===
14: not vectorized: unexpected loop form.
14: bad loop form.


For the C loop:
6: Profitability threshold is 2 loop iterations.
6: created 1 versioning for alias checks.
6: vectorizing stmts using SLP.
6: LOOP VECTORIZED.


For the Fortran loop, using ifort 12.1:
(15): (col. 19) remark: BLOCK WAS VECTORIZED.
(14): (col. 16) remark: loop was not vectorized: not inner loop.



Original dump for the Fortran loop (-fdump-tree-original):

D.1862 = mp1;
D.1863 = *n;
i = D.1862;
if (D.1863 < D.1862) goto L.2;
countm1.0 = (unsigned int) (NON_LVALUE_EXPR 
- NON_LVALUE_EXPR ) / 4;
while (1)
  {
(*dy)[(integer(kind=8)) i + -1] = (*dy)[(integer(kind=8)) i + -1]
  + *da * (*dx)[(integer(kind=8)) i + -1];
(*dy)[(integer(kind=8)) (i + 1) + -1]
   = (*dy)[(integer(kind=8)) (i + 1) + -1]
 + *da * (*dx)[(integer(kind=8)) (i + 1) + -1];
(*dy)[(integer(kind=8)) (i + 2) + -1]
   = (*dy)[(integer(kind=8)) (i + 2) + -1]
 + *da * (*dx)[(integer(kind=8)) (i + 2) + -1];
(*dy)[(integer(kind=8)) (i + 3) + -1]
   = (*dy)[(integer(kind=8)) (i + 3) + -1]
 + *da * (*dx)[(integer(kind=8)) (i + 3) + -1];
L.1:;
i = i + 4;
if (countm1.0 == 0) goto L.2;
countm1.0 = countm1.0 + 4294967295;
  }
L.2:;

[Bug c++/52826] Implement core/1170

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52826

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Paolo Carlini  2012-04-04 
13:55:58 UTC ---
Oops, thanks for reminding me, Daniel, let's close this one, then.

*** This bug has been marked as a duplicate of bug 51213 ***

[Bug c++/52763] Warning if compare between enum and non-enum type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52763

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Target|x86_64  |
   Host|Fedora 16   |
  Build|20120306|

--- Comment #2 from Jonathan Wakely  2012-04-04 
13:56:46 UTC ---
But what about cases such as (val1 == (ONE|TWO)) ?

(ONE|TWO) is of type 'int' but that code is correct and shouldn't warn

[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #1 from Paolo Carlini  2012-04-04 
13:55:58 UTC ---
*** Bug 52826 has been marked as a duplicate of this bug. ***

[Bug fortran/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Richard Guenther  2012-04-04 
13:49:38 UTC ---
DOUBLE PRECISION Dx(*) , Dy(*)

and

double X[1000], Y[1000]

are not at all the same.

[Bug fortran/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop

[izamyatin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865

--- Comment #1 from Igor Zamyatin  2012-04-04 
13:27:11 UTC ---
Created attachment 27088
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27088
C test

[Bug fortran/52865] New: GCC can't vectorize fortran loop but able to vectorize similar c-loop

[izamyatin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865

 Bug #: 52865
   Summary: GCC can't vectorize fortran loop but able to vectorize
similar c-loop
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com
Target: x86-64


Created attachment 27087
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27087
Fortran test

That looks strange but the compiler behaves differently on O3 for attached test
cases. 
Fortran can't vectorize loop which looks quite simple

Is it expected behavior?

[Bug fortran/52864] [4.6/4.7/4.8 Regression] Assignment to pointer component for INTENT(IN) dummy argument

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52864

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
  Known to work||4.1.2, 4.4.6, 4.5.3
   Target Milestone|--- |4.6.4
  Known to fail||4.6.1, 4.6.3, 4.7.0, 4.8.0

[Bug fortran/52864] New: [4.6/4.7/4.8 Regression] Assignment to pointer component for INTENT(IN) dummy argument

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52864

 Bug #: 52864
   Summary: [4.6/4.7/4.8 Regression] Assignment to pointer
component for INTENT(IN) dummy argument
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Reported by Vladimír at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0869abb167bf5680

The following program is rejected since GCC 4.6; it is related to PR 50684 but
not fixed by that patch.

The following program is rejected with:

Error: Dummy argument 'd' with INTENT(IN) in variable definition
   context (assignment) at (1)


 program test
type PoisFFT_Solver3D
  complex, dimension(:,:,:),&!contiguous,
  pointer :: work => null()
end type PoisFFT_Solver3D
 contains
 subroutine PoisFFT_Solver3D_FullPeriodic(D, Phi, RHS)
   type(PoisFFT_Solver3D), intent(in) :: D
   D%work(i,j,k) = 0.0
 end subroutine
 end

[Bug c++/52763] Warning if compare between enum and non-enum type

[gccrepo...@gmx-topmail.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52763

Mikka  changed:

   What|Removed |Added

 Target||x86_64
   Host||Fedora 16
  Build||20120306

--- Comment #1 from Mikka  2012-04-04 13:03:00 UTC 
---
Warning is also missing in 4.7.0 (Debian 4.7.0-1)

[Bug driver/52863] Enable -Wall by default

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52863

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  2012-04-04 
12:39:07 UTC ---
Although Clang is getting away with this, there are some very noisy warnings in
GCC's -Wall, like:

-Warray-bounds (only with -O2) -Wsign-compare (only in C++) -Wuninitialized 

For sure, some -Wall warnings should be enabled by default, such as -Wformat, 
-Wformat-security and -Wnonnull (like Ubuntu does already).

Other candidates, in my opinion, are -Wimplicit, -Wcomment and
-Wsequence-point.

[Bug bootstrap/52808] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52808

Richard Guenther  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #14 from Richard Guenther  2012-04-04 
12:22:21 UTC ---
Fixed.

[Bug bootstrap/52808] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52808

--- Comment #13 from Richard Guenther  2012-04-04 
12:12:07 UTC ---
Author: rguenth
Date: Wed Apr  4 12:12:00 2012
New Revision: 186135

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186135
Log:
2012-04-04  Richard Guenther  

PR tree-optimization/52808
* tracer.c (tail_duplicate): Do not tail-duplicate loop header
blocks.
* Makefile.in (tracer.o): Depend on $(CFGLOOP_H).

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/tracer.c

[Bug driver/52863] Enable -Wall by default

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52863

--- Comment #1 from Dominique d'Humieres  2012-04-04 
12:09:21 UTC ---
(1) WTF?
(2) Please don't.

[Bug c/52862] [4.5/4.6/4.7/4.8 Regression] ICE convert_to_pointer, at convert.c:50

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52862

Richard Guenther  changed:

   What|Removed |Added

  Known to work||4.4.6
   Target Milestone|--- |4.5.4
Summary|ICE convert_to_pointer, at  |[4.5/4.6/4.7/4.8
   |convert.c:50|Regression] ICE
   ||convert_to_pointer, at
   ||convert.c:50
  Known to fail||4.5.4

[Bug c/52862] ICE convert_to_pointer, at convert.c:50

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52862

--- Comment #3 from Richard Guenther  2012-04-04 
11:58:44 UTC ---
More reduced:

void ASMAtomicWritePtrVoid(const void *pv);
void rtThreadDestroy(void)
{
  void * const pvTypeChecked = ((void *)0);
  ASMAtomicWritePtrVoid((void *)(pvTypeChecked));
}

[Bug c/52862] ICE convert_to_pointer, at convert.c:50

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52862

--- Comment #2 from Richard Guenther  2012-04-04 
11:56:31 UTC ---
Reduced testcase, fails with -O:

typedef struct _AVLPVNodeCore {
void * Key;
} AVLPVNODECORE;
void ASMAtomicWritePtrVoid(void * volatile *ppv, const void *pv);
typedef struct RTTHREADINT {
AVLPVNODECORE Core;
} *PRTTHREADINT;
void rtThreadDestroy(PRTTHREADINT pThread)
{
  __typeof__(*(&pThread->Core.Key)) volatile * const ppvTypeChecked =
(&pThread->Core.Key);
  __typeof__(*(&pThread->Core.Key)) const pvTypeChecked = ((void *)0);
  ASMAtomicWritePtrVoid((void * volatile *)(ppvTypeChecked), (void
*)(pvTypeChecked));
}

We ICE here:

47/* Propagate overflow to the NULL pointer.  */
48if (integer_zerop (expr))
49  return force_fit_type_double (type, double_int_zero, 0,
50TREE_OVERFLOW (expr));

with expr being NON_LVALUE_EXPR <0B>.

[Bug driver/52863] New: Enable -Wall by default

[gdr at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52863

 Bug #: 52863
   Summary: Enable -Wall by default
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org


title says all.

[Bug go/51874] Many libgo testsuite failures on IRIX

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

--- Comment #15 from Rainer Orth  2012-04-04 11:48:45 
UTC ---
(In reply to comment #1)
> For the 64-bit Solaris/x86 case, Solaris engineering has identified and fixed
> the bug:
> 
> 7133114 fsbase (%fs:0) is not set properly after makecontext()/setcontext()
> 
> The fix will be in Solaris 11 Update 1, and I've requested a Solaris 10
> Update 10 backport, which will be delivered as a patch on top of patch
> 144501-19.

Just FYI, the fix for the bug above is now available in Solaris 11 SRU 5 and
Solaris 10/x86 patch 147441-14.  It's also included in a beta of Solaris 11
Update 1.

  Rainer

[Bug c/52862] ICE convert_to_pointer, at convert.c:50

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52862

Richard Guenther  changed:

   What|Removed |Added

   Keywords||ice-checking
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-04
 Ever Confirmed|0   |1
  Known to fail||4.6.4, 4.7.1, 4.8.0

--- Comment #1 from Richard Guenther  2012-04-04 
11:47:01 UTC ---
Confirmed.  Reducing.

[Bug c++/52849] crash when using suscript operator in delctype argument

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52849

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #2 from Daniel Krügler  
2012-04-04 11:43:22 UTC ---
This example causes no error in gcc 4.8.0 20120311 (experimental)

[Bug c++/52853] problem in stddef.h, Blender build fails

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52853

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #7 from Jonathan Wakely  2012-04-04 
11:42:33 UTC ---
(In reply to comment #6)
> "fix for building on linux with gcc4.7, an error was caused by undefining
> __cplusplus, so as to work with mingw4.4"

Don't undefine __cplusplus, that's never appropriate.

[Bug c++/48518] Inconsistent instantiation behavior depending on operator overloading

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48518

--- Comment #2 from Jonathan Wakely  2012-04-04 
11:38:57 UTC ---
(In reply to comment #0)
> The following program instantiates wrap, but a very similar program
> that doesn't call an overloaded operator doesn't:

Neither does an even more similar program that calls the operator function
directly:

template  struct scoped_ptr {
  C& operator*() const {
return *ptr_;
  }
  C* ptr_;
};
template struct wrap {
  T must_be_complete;
};
class Undefined;
struct S {
  wrap &content() const {
// return *content_;
return content_.operator*();
  }
  scoped_ptr > content_;
};

So the difference seems to be how the operator is looked up, possibly related
to whether the built-in operator* is considered, so due to [over.match.oper].

[Bug libgcj/52645] gnu/java/net/natPlainDatagramSocketImpl.cc:660:14: error: 'IPPROTO_IPV6' was not declared in this scope

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645

Rainer Orth  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-04/msg00192.htm
   ||l

--- Comment #12 from Rainer Orth  2012-04-04 11:35:00 
UTC ---
Thanks for the confirmation.  Patch submitted.

  Rainer

[Bug c++/52826] Implement core/1170

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52826

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2012-04-04 11:31:45 UTC ---
The intention of bug 51213 was to cover this.

[Bug c/52862] New: ICE convert_to_pointer, at convert.c:50

[aj at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52862

 Bug #: 52862
   Summary: ICE convert_to_pointer, at convert.c:50
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@gcc.gnu.org


Created attachment 27086
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27086
preprocessed file

Building VirtualBox with GCC 4.7.0 fails with:/common/misc/thread.c:610:5:
internal compiler error: tree check: expected class ‘constant’, have ‘unary’
(non_lvalue_expr) in convert_to_pointer, at convert.c:50

command lines are:

gcc
-Wp,-MD,/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/common/misc/.thread.o.d
 -nostdinc -isystem /usr/lib64/gcc/x86_64-suse-linux/4.7/include
-I/usr/src/linux-3.3.0-2/arch/x86/include -Iarch/x86/include/generated
-Iinclude  -I/usr/src/linux-3.3.0-2/include -include
/usr/src/linux-3.3.0-2/include/linux/kconfig.h  
-I/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 -mtune=generic
-mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args
-DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1 -pipe -Wno-sign-compare -mno-sse -mno-mmx -mno-sse2
-mno-3dnow -Wframe-larger-than=2048 -fno-stack-protector
-Wno-unused-but-set-variable -fomit-frame-pointer -fasynchronous-unwind-tables
-g -fno-inline-functions-called-once -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO
-include
/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/include/VBox/SUPDrvMangling.h
  -I/lib/modules/3.3.0-2-desktop/build/include  
-I/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/
 
-I/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/include
 
-I/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/r0drv/linux
 
-I/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/vboxdrv/
 
-I/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/vboxdrv/include
 
-I/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/vboxdrv/r0drv/linux
-D__KERNEL__ -DMODULE -DRT_OS_LINUX -DIN_RING0 -DIN_RT_R0 -DIN_SUP_R0 -DVBOX
-DRT_WITH_VBOX -DVBOX_WITH_HARDENING -DCONFIG_VBOXDRV_AS_MISC -DRT_ARCH_AMD64
-DVBOX_WITH_64_BITS_GUESTS  -DMODULE  -D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(thread)"  -D"KBUILD_MODNAME=KBUILD_STR(vboxdrv)"
-c -o
/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/common/misc/.tmp_thread.o
/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/common/mibyrd:/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv>
gcc
-Wp,-MD,/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/common/misc/.thread.o.d
 -nostdinc -isystem /usr/lib64/gcc/x86_64-suse-linux/4.7/include
-I/usr/src/linux-3.3.0-2/arch/x86/include -Iarch/x86/include/generated
-Iinclude  -I/usr/src/linux-3.3.0-2/include -include
/usr/src/linux-3.3.0-2/include/linux/kconfig.h  
-I/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 -mtune=generic
-mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args
-DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1 -pipe -Wno-sign-compare -mno-sse -mno-mmx -mno-sse2
-mno-3dnow -Wframe-larger-than=2048 -fno-stack-protector
-Wno-unused-but-set-variable -fomit-frame-pointer -fasynchronous-unwind-tables
-g -fno-inline-functions-called-once -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO
-include
/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/include/VBox/SUPDrvMangling.h
  -I/lib/modules/3.3.0-2-desktop/build/include  
-I/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/
 
-I/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/include
 
-I/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/r0drv/linux
 
-I/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/vboxdrv/
 
-I/home/abuild/rpmbuild/BUILD/VirtualBox-4.1.10/modules_build_dir/default/vboxdrv/vboxdrv/include
 
-I/home/abuild/

[Bug c++/48518] Inconsistent instantiation behavior depending on operator overloading

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48518

--- Comment #1 from Jonathan Wakely  2012-04-04 
11:15:54 UTC ---
Clang appears to agree with GCC now.

This reminds me of PR 46824

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

[amodra at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839

--- Comment #9 from Alan Modra  2012-04-04 11:12:56 
UTC ---
Heh.  We're even.  I didn't notice yours was a 64-bit failure until you told me
your gcc revision number.

[Bug c++/52853] problem in stddef.h, Blender build fails

[montagne29 at wanadoo dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52853

--- Comment #6 from Bastien Montagne  2012-04-04 
11:08:45 UTC ---
Bah, it’s not my day :/

Now it appears the error was on our side – quoting commit r45392 on blender svn
(ten minutes ago):

"fix for building on linux with gcc4.7, an error was caused by undefining
__cplusplus, so as to work with mingw4.4"

So this report can be closed, I think. Sorry for the noise.

[Bug c++/52853] problem in stddef.h, Blender build fails

[montagne29 at wanadoo dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52853

Bastien Montagne  changed:

   What|Removed |Added

  Attachment #27084|0   |1
is obsolete||

--- Comment #5 from Bastien Montagne  2012-04-04 
11:00:10 UTC ---
Comment on attachment 27084
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27084
preprocessed version of VideoFFmpeg.cpp

wrong archive attached, sorry.

[Bug c++/52853] problem in stddef.h, Blender build fails

[montagne29 at wanadoo dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52853

--- Comment #4 from Bastien Montagne  2012-04-04 
10:59:23 UTC ---
Created attachment 27085
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27085
preprocessed version of VideoFFmpeg.cpp

grmpg… I should awake, some times. sorry again

[Bug c++/52853] problem in stddef.h, Blender build fails

[montagne29 at wanadoo dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52853

Bastien Montagne  changed:

   What|Removed |Added

  Component|c   |c++

--- Comment #3 from Bastien Montagne  2012-04-04 
10:57:21 UTC ---
Hmm… Actually, it’s a c++ file, sorry for that mistake… :/

Attached the .i version of the file generating the error.

[Bug c/52853] problem in stddef.h, Blender build fails

[montagne29 at wanadoo dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52853

--- Comment #2 from Bastien Montagne  2012-04-04 
10:56:04 UTC ---
Created attachment 27084
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27084
preprocessed version of VideoFFmpeg.cpp

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839

--- Comment #8 from Jonathan Wakely  2012-04-04 
10:39:07 UTC ---
Doh, I completely failed to notice yours is powerpc not powerpc64 so I wasn't
testing 32-bit, sorry.  I'll re-check when I get home this evening.

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

[amodra at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839

--- Comment #7 from Alan Modra  2012-04-04 09:57:51 
UTC ---
I also see the same 64-bit failure on r186130.  A lot harder to reproduce than
the 32-bit one I originally reported (which is still there on r186130). Likely
not a problem with .eh_frame info since the fail only happens rarely.

[Bug fortran/52668] [4.7/4.8 Regression] Incorrect unused warning for USE associating variable in common block

[arnaud02 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52668

--- Comment #2 from Arnaud Desitter  
2012-04-04 09:42:47 UTC ---
The patch posted at http://gcc.gnu.org/ml/fortran/2012-03/msg00124.html fixes
the problem.

[Bug fortran/52861] New: (missed optimisation) missed transformation to memset with -O3

[arnaud02 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52861

 Bug #: 52861
   Summary: (missed optimisation) missed transformation to memset
with -O3
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arnau...@users.sourceforge.net


This is a minor missed-optimisation noticed as follow up to PR52835.
This is not a regression.

>cat qq1.f
  SUBROUTINE QQ2( ISU, ZSPM, RSV, MS )
  INTEGER :: ISU(MS)
  CHARACTER(8) :: ZSPM(MS)
  REAL :: RSV(MS)

  DO IS=1,MS
 ISU(IS)=0
 ZSPM(IS)=' '
 RSV(IS) =0.0
  ENDDO
  END subroutine qq2
>cat qq2.f
  SUBROUTINE QQ2( ISU, ZSPM, RSV, MS )
  INTEGER :: ISU(MS)
  CHARACTER(8) :: ZSPM(MS)
  REAL :: RSV(MS)

  DO IS=1,MS
 ISU(IS)=0
 RSV(IS) =0.0
  ENDDO
  DO IS=1,MS
 ZSPM(IS)=' '
  ENDDO
  END subroutine qq2
>gfortran470 -O3 -c qq1.f ; gfortran470 -O3 -c qq2.f
>nm qq1.o qq2.o

qq1.o:
 T qq2_

qq2.o:
 U memset
 T qq2_

The compiler has not be able to transform the assignments to ISU and RSV as
calls to memset when the loop contains an assignment to a CHARACTER variable.
This suggests that the dependency generator can be improved or that the Fortran
front-end could pass a better representation to the middle-end.

Additionally, it should be possible to transform 
  DO IS=1,MS
 ZSPM(IS)=' '
  ENDDO
as a call to memset. gcc 4.7.0 cannot:

>cat qq3.f
  SUBROUTINE QQ2( ZSPM, MS )
  CHARACTER(8) :: ZSPM(MS)
  DO IS=1,MS
 ZSPM(IS)=' '
  ENDDO
  END subroutine qq2
>/usr/local/gcc/gfortran470 -O3 -c qq3.f
>nm qq3
qq3.f  qq3.o
>nm qq3.o
 T qq2_

[Bug c/52853] problem in stddef.h, Blender build fails

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52853

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-04-04
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-04-04 
09:18:00 UTC ---
Please attach preprocessed source.

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839

--- Comment #6 from Jonathan Wakely  2012-04-04 
08:31:02 UTC ---
Revision: 186100

[Bug fortran/52860] New: I/O: gfortran rejects writing after hitting END=

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52860

 Bug #: 52860
   Summary: I/O: gfortran rejects writing after hitting END=
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Reported by Christian Convey at
http://gcc.gnu.org/ml/fortran/2012-03/msg00138.html

Note: I have not checked the standard whether the following program is valid, I
just want to make sure that the email does not get lost. Please also answer the
original reporter.


The following program reads from an empty file (created through the open
statement) - it immediately hits an END - and then tries to write to that file.

That succeeds with:
  g77, g95, gfortran <= 4.4, pgf90, ifort

It fails with:
  gfortran >= 4.5, openf95, pathf95, crayftn
with the message:
  Fortran runtime error: Sequential READ or WRITE not allowed after EOF
  marker, possibly use REWIND or BACKSPACE

Please check whether that's indeed the proper error. (If so, should we add some
legacy support?)


  PROGRAM MYTEST
   OPEN( UNIT=3, FILE='FOO', STATUS='UNKNOWN',
 1   FORM='FORMATTED', ACCESS='SEQUENTIAL', IOSTAT=IOS )
   write (*,*) 'reading'
   READ ( UNIT=3, FMT=*, END=10 )  BFR
   write (*,*) 'Done readin (no END)'
   GO TO 20
!10  REWIND( UNIT=3 )
   10  write (*,*) 'Hit END - writing'
   WRITE( UNIT=3, FMT='(A16)' )  'BATCH MODE = OFF'
   write (*,*) 'Done writing'
   20  write (*,*) 'Really done - closing'
   CLOSE( UNIT=3 )
   END PROGRAM