[Bug c++/52742] Initializing an array using brace initializer and template parameters

[M at ttDiesel dot co.uk]

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

--- Comment #1 from Mat  2012-03-28 07:07:58 UTC ---
A shorter reproducer has been shown here: https://gist.github.com/2220810

This does not actually have the template parameters inside the braces.

[Bug libitm/52695] libitm/config/x86/cacheline.h: '__m64' does not name a type

[freebsd at nagilum dot org]

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

Nagilum  changed:

   What|Removed |Added

 CC||freebsd at nagilum dot org

--- Comment #6 from Nagilum  2012-03-28 07:14:43 
UTC ---
Same here, building it from the FreeBSD port.
../../gcc-4.7-20120225/configure --disable-nls
--enable-languages=c,c++,objc,fortran --libdir=/usr/local/lib/gcc47
--libexecdir=/usr/local/libexec/gcc47 --program-suffix=47
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc47/include/c++/
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local
--with-pkgversion=FreeBSD Ports Collection --with-system-zlib --disable-libgcj
--prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc47
--build=i386-portbld-freebsd9.0

bails at:
libtool: compile:  /var/tmp/export/ports/lang/gcc47/work/build/./gcc/g++
-B/var/
tmp/export/ports/lang/gcc47/work/build/./gcc/ -nostdinc++ -nostdinc++
-I/var/tmp
/export/ports/lang/gcc47/work/build/i386-portbld-freebsd9.0/libstdc++-v3/include
/i386-portbld-freebsd9.0
-I/var/tmp/export/ports/lang/gcc47/work/build/i386-port
bld-freebsd9.0/libstdc++-v3/include
-I/var/tmp/export/ports/lang/gcc47/work/gcc-
4.7-20120225/libstdc++-v3/libsupc++
-I/var/tmp/export/ports/lang/gcc47/work/gcc-
4.7-20120225/libstdc++-v3/include/backward
-I/var/tmp/export/ports/lang/gcc47/wo
rk/gcc-4.7-20120225/libstdc++-v3/testsuite/util
-L/var/tmp/export/ports/lang/gcc47/work/build/i386-portbld-freebsd9.0/libstdc++-v3/src
-L/var/tmp/export/ports/lang/gcc47/work/build/i386-portbld-freebsd9.0/libstdc++-v3/src/.libs
-B/usr/local/i386-portbld-freebsd9.0/bin/
-B/usr/local/i386-portbld-freebsd9.0/lib/ -isystem
/usr/local/i386-portbld-freebsd9.0/include -isystem
/usr/local/i386-portbld-freebsd9.0/sys-include -DHAVE_CONFIG_H -I.
-I../.././../gcc-4.7-20120225/libitm
-I../.././../gcc-4.7-20120225/libitm/config/x86
-I../.././../gcc-4.7-20120225/libitm/config/posix
-I../.././../gcc-4.7-20120225/libitm/config/generic
-I../.././../gcc-4.7-20120225/libitm -march=i486 -mtune=i386
-fomit-frame-pointer -Wall -pthread -Werror -std=gnu++0x -funwind-tables
-fno-exceptions -fno-rtti -fabi-version=4 -g -Os -O2 -pipe -march=geode
-mtune=geode -I/usr/local/include -fno-strict-aliasing -MT aatree.lo -MD -MP
-MF .deps/aatree.Tpo -c ../.././../gcc-4.7-20120225/libitm/aatree.cc  -fPIC
-DPIC -o .libs/aatree.o
In file included from ../.././../gcc-4.7-20120225/libitm/libitm_i.h:85:0,
 from ../.././../gcc-4.7-20120225/libitm/aatree.cc:28:
../.././../gcc-4.7-20120225/libitm/config/x86/cacheline.h:55:3: error: '__m64'
does not name a type

[Bug c/52747] No warning from toolchain with nested function and --noexecstack

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  2012-03-28 07:17:44 
UTC ---
Only if you need to take the address of the function.  Calling a nested
function from within the containing function doesn't need a trampoline.

[Bug rtl-optimization/44141] Redundant loads and stores generated for AMD bdver1 target

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  2012-03-28 
07:47:58 UTC ---
Having a vector mode changing subreg on the LHS of an instruction is a very
common issue in the i386 backend, and unfortunately e.g. means that lots of
insns can't be combined or simplified.  I wonder if the expansion sometimes
shouldn't use a non-subregged temporary as lhs and add a move from subreg of
the temporary to the desired destination.

BTW, if with TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL ps is more desirable than pd
for movs, then perhaps it would be better to add a mode attr similar to
ssemodesuffix, which would emit pd or ps for V2DFmode depending on
TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL (see e.g. i128 mode attr).

[Bug target/51106] [4.5/4.6 Regression] ICE in move_insn, at haifa-sched.c:2314

[rguenther at suse dot de]

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

--- Comment #19 from rguenther at suse dot de  
2012-03-28 07:59:59 UTC ---
On Tue, 27 Mar 2012, abel at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51106
> 
> --- Comment #18 from Andrey Belevantsev  2012-03-27 
> 14:08:23 UTC ---
> (In reply to comment #17)
> > Looks reasonable.  Though I think that whoever removed the fallthru
> > edge should have adjusted the flags on the others.
> That's simply delete_basic_block at cfgcleanup.c:2612 -- we have block 2 with
> two successors 4 and 5, and block 4 is trivially dead (empty, no succ, etc.),
> so when removing block 4 we just remove the 2->4 edge which is the only
> fallthru one.  Which seems fine as the asm in question is seen by the rest of
> code as an unconditional jump then.  Only when we remove it, we get no jump 
> and
> still no fallthru bit, which confuses purge_dead_edges.

I see.

[Bug target/52736] [4.5/4.6/4.7/4.8 Regression] miscompilation: store to aliased __m128d is 8 Bytes off

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  2012-03-28 
08:01:17 UTC ---
Author: jakub
Date: Wed Mar 28 08:01:00 2012
New Revision: 185904

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185904
Log:
PR target/52736
* config/i386/sse.md (sse2_loadlpd splitter): Use offset 0
instead of 8 in adjust_address.

* gcc.target/i386/pr52736.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr52736.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug target/52736] [4.5/4.6/4.7/4.8 Regression] miscompilation: store to aliased __m128d is 8 Bytes off

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2012-03-28 
08:03:41 UTC ---
Author: jakub
Date: Wed Mar 28 08:03:11 2012
New Revision: 185905

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185905
Log:
PR target/52736
* config/i386/sse.md (sse2_loadlpd splitter): Use offset 0
instead of 8 in adjust_address.

* gcc.target/i386/pr52736.c: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr52736.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/i386/sse.md
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug target/52736] [4.5/4.6/4.7/4.8 Regression] miscompilation: store to aliased __m128d is 8 Bytes off

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  2012-03-28 
08:10:25 UTC ---
Author: jakub
Date: Wed Mar 28 08:09:55 2012
New Revision: 185906

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185906
Log:
PR target/52736
* config/i386/sse.md (sse2_loadlpd splitter): Use offset 0
instead of 8 in adjust_address.

* gcc.target/i386/pr52736.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/pr52736.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/i386/sse.md
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug target/52736] [4.5/4.6/4.7/4.8 Regression] miscompilation: store to aliased __m128d is 8 Bytes off

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #13 from Jakub Jelinek  2012-03-28 
08:15:36 UTC ---
Fixed for 4.6+ (note, even in 4.6 the bug is just latent).

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

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

--- Comment #15 from Michael Haubenwallner  2012-03-28 08:21:37 UTC ---
(In reply to comment #14)
> > Do you see any technical issue why Import
> > Files cannot be used this way for filename-based versioning over the
> > traditional onefile-membername-based versioning?
> 
> I think that import files can be used the way you suggest.

Ok, thank you!

> I am not sure I understand why you write that libNAME.so is broken.  AIX can
> search for a bare shared object named libNAME.so.

It isn't broken in a technical sense from AIX' point of view,
it is broken in the package manager's point of view, not allowing for /any/
kind of versioning at all (neither via filename nor via archive member with
F_LOADONLY flag), as well as breaking multilib.

> Also, I still believe that your "Linux" solution will require linking with
> -brtl or -bsvr4.

Yes, and the main (because technical) reason is to keep static linking
possible.

This also is the reason I've named the commandline switch "*able-aix-svr4" for
now, but I don't have a hard opinion here, because
--disable-static _would_ allow (administrative-wise) for import files even
without -brtl/-bsvr4 (easiest via symlink libNAME.a -> libNAME.so.1).

As the name "aix-svr4" implies runtime linking, maybe "aix-soname" is more
suitable...

So - what I'm still unsure is:
*) how far to go with disable-static (symlink libNAME.a->libNAME.so.1),
   maybe upon aix-svr4=compat only?
*) which name and values for the configure-switch are as obvious as possible:
   1 : --enable-aix-svr4=[no | compat | yes]
   1l: --enable-aix-svr4=[no | yes | only]   # less forceful
   2 : --enable-aix-soname=[no | compat | yes]
   2l: --enable-aix-soname=[no | yes | only] # less forceful
   3 : --with-aix-soname=[aix,no | both | svr4,yes]
   3l: --with-aix-soname=[aix,no | both,yes | svr4]  # less forceful

Where "less forceful" means to take 'yes' to provide both (A)ix+(L)inux,
needing 'only' to drop (A)ix,
while the others take 'yes' to provide (L)inux _only_, needing 'compat' or
'both' to provide (A)ix too.

Also, I'd like to _allow_ for package /maintainers/ to set either 'both' or
'only' (whichever name the values will have) as default value via LT_INIT
(usually upon some API/SONAME bump), while still allowing for package
/managers/ to override.

Using above names, this would be:
for (A)ix+(L)inux   for (L)inux only
(1 )  LT_INIT([ aix-svr4=compat   ])  LT_INIT([ aix-svr4])
(1l)  LT_INIT([ aix-svr4  ])  LT_INIT([ aix-svr4=only   ])
(2 )  LT_INIT([ aix-soname=compat ])  LT_INIT([ aix-soname  ])
(2l)  LT_INIT([ aix-soname])  LT_INIT([ aix-soname=only ])
(3 )  LT_INIT([ aix-soname=both   ])  LT_INIT([ aix-soname  ])
(3l)  LT_INIT([ aix-soname])  LT_INIT([ aix-soname=svr4 ])

More/better ideas?

Thank you!

[Bug target/52737] [avr]: -mtiny-stack shall not influence multilib selection

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2012-03-28 
08:31:46 UTC ---
Author: gjl
Date: Wed Mar 28 08:31:26 2012
New Revision: 185907

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185907
Log:
PR target/52737
* contrib/gcc_update (files_and_dependencies):
Remove gcc/config/avr/t-multilib from touch data.

gcc/
PR target/52737
* config.gcc (tm_file): Remove avr/multilib.h.

* doc/invoke.texi (AVR Options): Adjust
documentation of -mtiny-stack.

* config/avr/genmultilib.awk: Remove code to generate multilib.h.
(BEGIN): Use -msp8 as multilib option instead of -mtiny-stack.
* config/avr/t-avr: Remove generation of multilib.h.
* config/avr/t-multilib: Regenerate.
* config/avr/multilib.h: Remove.
* config/avr/avr.opt (-msp8): New option.
(avr_sp8): New variable.
* config/avr/driver-avr.c (avr_device_to_sp8): New function.
* config/avr/avr.h (AVR_HAVE_SPH): New define.
(AVR_HAVE_8BIT_SP): Also set by avr_sp8 i.e. -msp8.
(avr_device_to_sp8): New prototype.
(EXTRA_SPEC_FUNCTIONS): Add { "device_to_sp8", avr_device_to_sp8 }
(DRIVER_SELF_SPECS): New define.
* config/avr/avr-c.c (avr_cpu_cpp_builtins): New built-in defines:
__AVR_SP8__, __AVR_HAVE_SPH__.
* config/avr/avr.c (output_movhi): Use AVR_HAVE_SPH instead of
AVR_HAVE_8BIT_SP to decide if SP_H is present.
(avr_file_start): Ditto.

libgcc/
PR target/52737
* config/avr/lib1funcs.S: Use __AVR_HAVE_SPH__ for SP_H checks
instead of __AVR_HAVE_8BIT_SP__.


Removed:
trunk/gcc/config/avr/multilib.h
Modified:
trunk/ChangeLog
trunk/contrib/gcc_update
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/avr/avr-c.c
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.h
trunk/gcc/config/avr/avr.opt
trunk/gcc/config/avr/driver-avr.c
trunk/gcc/config/avr/genmultilib.awk
trunk/gcc/config/avr/t-avr
trunk/gcc/config/avr/t-multilib
trunk/gcc/doc/invoke.texi
trunk/libgcc/ChangeLog
trunk/libgcc/config/avr/lib1funcs.S

[Bug c++/52746] [4.7/4.8 Regression] Explicit virtual destructor call replaced by direct call in template function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-28
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |4.7.1
Summary|[4.7 Regression] Explicit   |[4.7/4.8 Regression]
   |virtual destructor call |Explicit virtual destructor
   |replaced by direct call in  |call replaced by direct
   |template function   |call in template function
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2012-03-28 
08:53:58 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183133
aka second part of PR48051 fix.

[Bug target/52736] [4.5/4.6/4.7/4.8 Regression] miscompilation: store to aliased __m128d is 8 Bytes off

[kretz at kde dot org]

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

--- Comment #14 from Matthias Kretz  2012-03-28 09:03:05 
UTC ---
Thanks! Great response time!

And yes, I started to notice the bug on 4.6.x now, too. In different unit
tests, though. I'll see if I can come up with a workaround for the "broken"
compilers.

[Bug target/52737] [avr]: -mtiny-stack shall not influence multilib selection

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  2012-03-28 
09:04:49 UTC ---
Author: gjl
Date: Wed Mar 28 09:04:11 2012
New Revision: 185908

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185908
Log:
Backport from 2012-03-28 mainline r185907.

PR target/52737
* contrib/gcc_update (files_and_dependencies):
Remove gcc/config/avr/t-multilib from touch data.

gcc/
Backport from 2012-03-28 mainline r185907.

PR target/52737
* config.gcc (tm_file): Remove avr/multilib.h.

* doc/invoke.texi (AVR Options): Adjust
documentation of -mtiny-stack.

* config/avr/genmultilib.awk: Remove code to generate multilib.h.
(BEGIN): Use -msp8 as multilib option instead of -mtiny-stack.
* config/avr/t-avr: Remove generation of multilib.h.
* config/avr/t-multilib: Regenerate.
* config/avr/multilib.h: Remove.
* config/avr/avr.opt (-msp8): New option.
(avr_sp8): New variable.
* config/avr/driver-avr.c (avr_device_to_sp8): New function.
* config/avr/avr.h (AVR_HAVE_SPH): New define.
(AVR_HAVE_8BIT_SP): Also set by avr_sp8 i.e. -msp8.
(avr_device_to_sp8): New prototype.
(EXTRA_SPEC_FUNCTIONS): Add { "device_to_sp8", avr_device_to_sp8 }
(DRIVER_SELF_SPECS): New define.
* config/avr/avr-c.c (avr_cpu_cpp_builtins): New built-in defines:
__AVR_SP8__, __AVR_HAVE_SPH__.
* config/avr/avr.c (output_movhi): Use AVR_HAVE_SPH instead of
AVR_HAVE_8BIT_SP to decide if SP_H is present.
(avr_file_start): Ditto.

libgcc/
Backport from 2012-03-28 mainline r185907.

PR target/52737
* config/avr/lib1funcs.S: Use __AVR_HAVE_SPH__ for SP_H checks
instead of __AVR_HAVE_8BIT_SP__.


Removed:
branches/gcc-4_7-branch/gcc/config/avr/multilib.h
Modified:
branches/gcc-4_7-branch/ChangeLog
branches/gcc-4_7-branch/contrib/gcc_update
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config.gcc
branches/gcc-4_7-branch/gcc/config/avr/avr-c.c
branches/gcc-4_7-branch/gcc/config/avr/avr.c
branches/gcc-4_7-branch/gcc/config/avr/avr.h
branches/gcc-4_7-branch/gcc/config/avr/avr.opt
branches/gcc-4_7-branch/gcc/config/avr/driver-avr.c
branches/gcc-4_7-branch/gcc/config/avr/genmultilib.awk
branches/gcc-4_7-branch/gcc/config/avr/t-avr
branches/gcc-4_7-branch/gcc/config/avr/t-multilib
branches/gcc-4_7-branch/gcc/doc/invoke.texi
branches/gcc-4_7-branch/libgcc/ChangeLog
branches/gcc-4_7-branch/libgcc/config/avr/lib1funcs.S

[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  2012-03-28 
09:06:30 UTC ---
Author: ebotcazou
Date: Wed Mar 28 09:06:03 2012
New Revision: 185909

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185909
Log:
PR middle-end/51893
* expmed.c (store_bit_field_1): Fix wordnum value for big-endian
targets.

Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/expmed.c

[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.1

--- Comment #13 from Eric Botcazou  2012-03-28 
09:10:35 UTC ---
Fixed in the 4.7.x series.  Thanks for the bug report and the patch.

[Bug target/52692] [avr]: Add support for avr-specific built-ins + LTO

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2012-03-28 
09:13:47 UTC ---
Author: gjl
Date: Wed Mar 28 09:13:41 2012
New Revision: 185910

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185910
Log:
gcc/
PR target/52692
* config/avr/avr.c (TARGET_BUILTIN_DECL): New define.
(avr_builtin_decl): New static function.
(struct avr_builtin_description, avr_bdesc): Move up.
Add GTY marker. Add field fndecl. Remove redundant field id.
(avr_init_builtins): Initialize avr_bdesc[ID].fndecl.
(avr_expand_builtin): Code cleanup because .id is removed.

testsuite/
PR target/52692
* gcc.target/avr/torture/builtins-2.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/avr/torture/builtins-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c
trunk/gcc/testsuite/ChangeLog

[Bug target/52692] [avr]: Add support for avr-specific built-ins + LTO

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  2012-03-28 
09:19:30 UTC ---
Author: gjl
Date: Wed Mar 28 09:19:10 2012
New Revision: 185911

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185911
Log:
gcc/
Backport from 2012-03-28 mainline r185910.

PR target/52692
* config/avr/avr.c (TARGET_BUILTIN_DECL): New define.
(avr_builtin_decl): New static function.
(struct avr_builtin_description, avr_bdesc): Move up.
Add GTY marker. Add field fndecl. Remove redundant field id.
(avr_init_builtins): Initialize avr_bdesc[ID].fndecl.
(avr_expand_builtin): Code cleanup because .id is removed.

testsuite/
Backport from 2012-03-28 mainline r185910.

PR target/52692
* gcc.target/avr/torture/builtins-2.c: New test.


Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/avr/torture/builtins-2.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/avr/avr.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug c/52747] No warning from toolchain with nested function and --noexecstack

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot
   ||gnu.org
 Resolution||WORKSFORME

--- Comment #2 from Eric Botcazou  2012-03-28 
09:26:55 UTC ---
You can pass -Wtrampolines in the 4.6.x series.

[Bug target/52554] Variable called $1 causes invalid asm to be generated

[webmaster at openhardware dot de]

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

webmaster at openhardware dot de changed:

   What|Removed |Added

 CC||webmaster at openhardware
   ||dot de

--- Comment #5 from webmaster at openhardware dot de 2012-03-28 09:36:47 UTC ---
Hi, I tested the 42 it mit older gcc, and it behaved better:

 gcc --version
gcc (GCC) 4.2.4 (Gentoo 4.2.4 p1.0)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


 cat >try.c
int $42 = 0;

int main(void) {
return $42;
}


 gcc try.c; ./a.out; echo $?  
/tmp/ccY61UFa.s: Assembler messages:
/tmp/ccY61UFa.s:18: Error: junk `(%rip)' after expression
bash: ./a.out: No such file or directory
127

 gcc -O2 try.c; ./a.out; echo $? 
/tmp/ccXk0zWe.s: Assembler messages:
/tmp/ccXk0zWe.s:8: Error: junk `(%rip)' after expression
bash: ./a.out: No such file or directory
127


But I would expect an syntax error thrown by gcc here.

[Bug middle-end/52750] New: 32xsigned char __builtin_shuffle

[jakub at gcc dot gnu.org]

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

 Bug #: 52750
   Summary: 32xsigned char __builtin_shuffle
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: marc.gli...@normalesup.org
Depends on: 52607


typedef signed char V __attribute__((vector_size (32)));
V
f (V x)
{
  V m = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31};
  return __builtin_shuffle (x, m);
}

ICEs without -mavx2, because generic vector lowering is using a wrong type for
BIT_FIELD_REF positions.

[Bug middle-end/52750] 32xsigned char __builtin_shuffle

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-03-28
   Target Milestone|--- |4.7.1
 Ever Confirmed|0   |1

[Bug c++/50043] [C++0x] Implement core/1123

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Severity|enhancement |normal

[Bug fortran/46539] libquadmath: Add -static-libquadmath

[arnaud02 at users dot sourceforge.net]

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

--- Comment #4 from Arnaud Desitter  
2012-03-28 10:05:29 UTC ---
Thanks for the workarounds. 

For information, the Intel Fortran compiler has "-static-intel" which links
statically Intel provided libraries. Such option may be un-practical for gcc.

[Bug target/52741] [avr] -mtiny-stack must not make assumptions on upper 8 bits of SP resp. FP

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2012-03-28 
10:07:06 UTC ---
Author: gjl
Date: Wed Mar 28 10:06:51 2012
New Revision: 185912

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185912
Log:
PR target/52741
Revert r181936 from 2011-12-02 for:
* config/avr/libgcc.S (__prologue_saves__, __epilogue_restores__)
* config/avr/avr.md (movhi_sp_r_irq_off, movhi_sp_r_irq_on)
* config/avr/avr.c (output_movhi, avr_file_start)


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/avr/avr.c
branches/gcc-4_6-branch/gcc/config/avr/avr.md
branches/gcc-4_6-branch/gcc/config/avr/libgcc.S

[Bug middle-end/52750] 32xsigned char __builtin_shuffle

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2012-03-28 
10:14:10 UTC ---
Created attachment 27020
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27020
gcc48-pr52750.patch

Untested fix.

[Bug fortran/52751] New: private module variable are not exported as local

[arnaud02 at users dot sourceforge.net]

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

 Bug #: 52751
   Summary: private module variable are not exported as local
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arnau...@users.sourceforge.net


>cat  qq.f
  module mm
  integer, private :: i
  end module
>gfortran470 -c qq.f
>nm qq.o
 B __mm_MOD_i

>cat qq.c
static int i;
>gcc470 -c qq.c
>nm qq.o
 b i

Variables private to a module could be marked as local ("b" instead of "B") in
the same way that "static" variables are in C. 

This is related to PR40973, which is about procedures.

[Bug target/51002] SP_H register is used even on targets that do not have it (eg attiny26)

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #12 from Georg-Johann Lay  2012-03-28 
10:25:27 UTC ---
Fixed in 4.7.1

[Bug target/52741] [avr] -mtiny-stack must not make assumptions on upper 8 bits of SP resp. FP

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #2 from Georg-Johann Lay  2012-03-28 
10:26:47 UTC ---
Resolved in 4.6.4

[Bug target/51345] [avr] Devices with 8-bit SP need their own multilib(s)

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Georg-Johann Lay  2012-03-28 
10:29:40 UTC ---
Rescheduled for 4.7.1

[Bug target/52737] [avr]: -mtiny-stack shall not influence multilib selection

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Georg-Johann Lay  2012-03-28 
10:27:36 UTC ---
Fixed in 4.7.1

[Bug rtl-optimization/44141] Redundant loads and stores generated for AMD bdver1 target

[venkataramanan.kumar at amd dot com]

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

--- Comment #13 from Venkataramanan  
2012-03-28 10:32:31 UTC ---
(In reply to comment #12)
> Having a vector mode changing subreg on the LHS of an instruction is a very
> common issue in the i386 backend, and unfortunately e.g. means that lots of
> insns can't be combined or simplified.  I wonder if the expansion sometimes
> shouldn't use a non-subregged temporary as lhs and add a move from subreg of
> the temporary to the desired destination.

The expander now converts as shown below for unaligned moves with V2DF mode.

if (TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL)
{
  op0 = gen_lowpart (V4SFmode, op0);
  op1 = gen_lowpart (V4SFmode, op1);
  emit_insn (gen_sse_movups (op0, op1));
  return;
}

You mean conversion is not needed here?  


> BTW, if with TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL ps is more desirable than 
> pd
> for movs, then perhaps it would be better to add a mode attr similar to
> ssemodesuffix, which would emit pd or ps for V2DFmode depending on
> TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL (see e.g. i128 mode attr).

Yes with TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL we want to generate movups
instead of movupd.

[Bug rtl-optimization/44141] Redundant loads and stores generated for AMD bdver1 target

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  2012-03-28 
10:40:45 UTC ---
(In reply to comment #13)
> The expander now converts as shown below for unaligned moves with V2DF mode.
> 
> if (TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL)
> {
>   op0 = gen_lowpart (V4SFmode, op0);
>   op1 = gen_lowpart (V4SFmode, op1);
>   emit_insn (gen_sse_movups (op0, op1));
>   return;
> }
> 
> You mean conversion is not needed here?  

No, I meant it should do perhaps:
  rtx tem = gen_reg_rtx (V4SFmode);
  emit_insn (gen_sse_movups (tem, gen_lowpart (V4SFmode, op1)));
  emit_move_insn (op0, gen_lowpart (GET_MODE (op0), tem));
  return;
or similar.  Of course in this case it can be done using changes in the
patterns (note, there are lots of other insns that emit {,v}mov{u,a}pd,
which of those should be changed?), I meant this as a general comment that
a vector mode changing subreg on a lhs of an insn is highly undesirable.

[Bug target/52692] [avr]: Add support for avr-specific built-ins + LTO

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Georg-Johann Lay  2012-03-28 
10:53:19 UTC ---
Fixed in 4.7.1

[Bug target/51345] [avr] Devices with 8-bit SP need their own multilib(s)

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|4.7.1   |4.7.0

[Bug target/51002] SP_H register is used even on targets that do not have it (eg attiny26)

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|4.7.1   |4.7.0

[Bug target/50931] [avr] Support a 24-bit scalar integer mode

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords|documentation   |
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.7.1   |4.7.0

--- Comment #4 from Georg-Johann Lay  2012-03-28 
11:07:26 UTC ---
Fixed in 4.7.0 (up to documentation)

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[dje at gcc dot gnu.org]

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

--- Comment #16 from David Edelsohn  2012-03-28 
12:29:29 UTC ---
Symbolic linking or hard linking libNAME.so.1 to libNAME.so doesn't work?  I
seem to remember something strange about the way AIX loader followed symbolic
links.

For versioning one can use libNAME.1.so or libNAME-1.so -- as long as ".so" is
the file extension.

[Bug libgcj/52694] [4.8 regression] bootstrap failure: libjava/java/io/natVMConsole.cc:35:20: error: 'IUCL C' was not declared in this scope

[gnu_andrew at member dot fsf.org]

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

Andrew John Hughes  changed:

   What|Removed |Added

 CC||gnu_andrew at member dot
   ||fsf.org

--- Comment #7 from Andrew John Hughes  
2012-03-28 12:59:28 UTC ---
Thanks for the fix.  The original code is adapted from the native Console code
in GNU Classpath which worked fine on GNU/Linux.  I'll port the change back to
that code too.

[Bug libgcj/50845] java.util.concurrent.ThreadPoolExecutor do not work with core thread=0

[bentatham at nanometrics dot ca]

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

Ben Tatham  changed:

   What|Removed |Added

 CC||bentatham at nanometrics
   ||dot ca

--- Comment #2 from Ben Tatham  2012-03-28 
13:17:35 UTC ---
I have observed the same problem.  I am unclear if it will _ever_ create a new
thread or not.

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

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

--- Comment #17 from Michael Haubenwallner  2012-03-28 14:20:52 UTC ---
(In reply to comment #16)
> Symbolic linking or hard linking libNAME.so.1 to libNAME.so doesn't work? I
> seem to remember something strange about the way AIX loader followed symbolic
> links.

The real (archive) file needs to be (available as) libNAME.so.1, which is what
the loader will search for. So there is no symbolic link involved at runtime,
unless we also do the libNAME.so.1 -> libNAME.so.1.2.3 symlink, which libtool
already does for the (B)roken variant.

Maybe these symlink troubles with the AIX loader are related to those .nfsXXX
files seen sometimes?

But still: Good to know we should not symlink libNAME.so.1 -> libNAME.so.1.2.3.

> For versioning one can use libNAME.1.so or libNAME-1.so -- as long as ".so" is
> the file extension.

This would imply to use '-lNAME.1' or '-lNAME-1' for the linker.
But the linker usually gets '-lNAME', hence libNAME.so (or libNAME.a) needs to
be available.

However, libNAME.so may be a symlink to libNAME.so.2 already, while
libNAME.so.1 is still around for binaries built when libNAME.so was a symlink
to libNAME.so.1.
(Isn't this what the SONAME is for at all?)

[Bug middle-end/50708] Infinite loop between rshift_double and lshift_double if count is LONG_MIN

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||borut.razem at gmail dot
   ||com

--- Comment #6 from Richard Guenther  2012-03-28 
14:23:40 UTC ---
*** Bug 52653 has been marked as a duplicate of this bug. ***

[Bug middle-end/52653] GCC 4.6.* bug on i386 Linux and mingw platforms

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #4 from Richard Guenther  2012-03-28 
14:23:40 UTC ---
.

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

[Bug middle-end/50708] Infinite loop between rshift_double and lshift_double if count is LONG_MIN

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #7 from Richard Guenther  2012-03-28 
14:24:15 UTC ---
Mine.

[Bug c/52747] No warning from toolchain with nested function and --noexecstack

[noloader at gmail dot com]

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

--- Comment #3 from Jeffrey Walton  2012-03-28 
14:33:38 UTC ---
Ah, OK. -Wtrampolines works. But I'm not seeing a warning about the loss of
no-exec stacks:

int main(int argc, char* argv[])
{
  (void)argc;
  (void)argv;

  void foo()
  {
printf("main: %p\n", &main);
printf("argv: %p\n", argv);

printf("foo: %p\n", &foo);   
  }

  foo();

  return 0;
}

$ gcc -Wall -Wextra -fPIE -Wtrampolines -Wl,-z,relro -Wl,-z,now
-Wl,-z,noexecstack -Wl,-z,noexecheap warn-test.c -o warn-test.exe
warn-test.c: In function ‘main’:
warn-test.c:10:8: warning: trampoline generated for nested function ‘foo’
[-Wtrampolines]
/usr/bin/ld: warning: -z noexecheap ignored.

$ ./warn-test.exe 
main: 0x4005c7
argv: 0x7fff65a9a138
foo: 0x7fff65a9a028

[Bug middle-end/52750] 32xsigned char __builtin_shuffle

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2012-03-28 
14:41:16 UTC ---
Author: jakub
Date: Wed Mar 28 14:40:57 2012
New Revision: 185914

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185914
Log:
PR middle-end/52750
* tree-vect-generic.c (vector_element): Perform multiplication
for pos in bitsizetype type instead of idx type.

* gcc.c-torture/compile/pr52750.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr52750.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-generic.c

[Bug c/52747] No warning from toolchain with nested function and --noexecstack

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2012-03-28 
14:44:09 UTC ---
The -Wtrampolines is that warning.  Note that -Wl,-z,noexecstack is a user
error in that case, you are requesting the linker to override any automatic
deduction on whether trampolines are used or not, by promising they aren't
used, even when you actually use them.  If you don't use -Wl,-z,noexecstack,
the compiler/assembler/linker will DTRT automatically, unless you have *.s/*.S
sources (those need to be tagged manually, or with -Wa,--noexecstack).

[Bug middle-end/52750] 32xsigned char __builtin_shuffle

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-03-28 
14:46:23 UTC ---
Author: jakub
Date: Wed Mar 28 14:46:14 2012
New Revision: 185916

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185916
Log:
PR middle-end/52750
* tree-vect-generic.c (vector_element): Perform multiplication
for pos in bitsizetype type instead of idx type.

* gcc.c-torture/compile/pr52750.c: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/compile/pr52750.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/tree-vect-generic.c

[Bug middle-end/52691] [4.7/4.8 Regression] va_start to builtin_next_arg optimization lost

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2012-03-28 
14:47:59 UTC ---
Author: jakub
Date: Wed Mar 28 14:47:45 2012
New Revision: 185917

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185917
Log:
PR middle-end/52691
* tree-ssa-ccp.c (optimize_stdarg_builtin): Optimize
__builtin_va_start to __builtin_next_arg if the latter is
builtin_decl_explicit_p rather than when it is not.

* gcc.dg/pr52691.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr52691.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug middle-end/52691] [4.7/4.8 Regression] va_start to builtin_next_arg optimization lost

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-03-28 
14:49:40 UTC ---
Author: jakub
Date: Wed Mar 28 14:49:26 2012
New Revision: 185918

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185918
Log:
PR middle-end/52691
* tree-ssa-ccp.c (optimize_stdarg_builtin): Optimize
__builtin_va_start to __builtin_next_arg if the latter is
builtin_decl_explicit_p rather than when it is not.

* gcc.dg/pr52691.c: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr52691.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/tree-ssa-ccp.c

[Bug c/52747] No warning from toolchain with nested function and --noexecstack

[noloader at gmail dot com]

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

--- Comment #5 from Jeffrey Walton  2012-03-28 
14:52:29 UTC ---
My apologies for the additional comments.

$ checksec.sh --file ./warn-test.exe 
RELRO   STACK CANARY  NXPIE RPATH 
RUNPATH  FILE
Full RELRO  Canary found  NX enabledNo PIE  No RPATH   No
RUNPATH   ./warn-test.exe

So, it appears I have a trampoline, and NX is enabled? When I run the program,
I do not segfault:

And PIE caught me off guard considering -fPIE and:
$ cat /proc/sys/kernel/randomize_va_space 
2

[Bug middle-end/52750] 32xsigned char __builtin_shuffle

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2012-03-28 
14:53:09 UTC ---
Fixed.

[Bug middle-end/52691] [4.7/4.8 Regression] va_start to builtin_next_arg optimization lost

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2012-03-28 
14:58:12 UTC ---
Fixed.

[Bug middle-end/52693] Wrong code with SRA and arrays

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  2012-03-28 
15:04:53 UTC ---
Author: jamborm
Date: Wed Mar 28 15:04:45 2012
New Revision: 185920

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185920
Log:
2012-03-28  Martin Jambor  

PR middle-end/52693
* tree-sra.c (sra_modify_assign): Do not call
load_assign_lhs_subreplacements when working with an unscalarizable
region.

* testsuite/gcc.dg/torture/pr52693.c: New test.


Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr52693.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/tree-sra.c

[Bug ada/52752] New: GNAT bug box on instantiation of subprogram with "not null"-qualified named access type

[lithiumcat at gmail dot com]

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

 Bug #: 52752
   Summary: GNAT bug box on instantiation of subprogram with "not
null"-qualified named access type
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lithium...@gmail.com


Created attachment 27021
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27021
Minimal testcase triggering the bug box

It seems that GNAT compilation fails when I instantiate a subprogram when one
of its argument is of type "not null Named_Access_Type".

It can be reproduced using the attached gnatchop'ed Ada source:

$ gnatchop testcase.ada
splitting testcase.ada into:
   test.ads
   test.adb
   testcase.adb
$ gnatmake testcase.adb
gnatgcc -c testcase.adb
gnatgcc -c test.adb
+===GNAT BUG DETECTED==+
| 4.6.2 20111026 (release) -=> GNAT AUX [FreeBSD64] (x86_64-aux-freebsd9.0) GCC
error:|
| in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4134  |
| Error detected at test.adb:8:4 [test.adb:29:4]   |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

test.adb
test.ads

compilation abandoned
gnatmake: "test.adb" compilation error



Using exactly the same source but without the "not null" qualifications does
not trigger the bug. Similarly, putting the "not null" qualification in the
type declaration instead of in the argument does not trigger the bug either.
In both cases, here is the output:

$ gnatmake testcase.adb
gnatgcc -c testcase.adb
gnatgcc -c test.adb
gnatbind -x testcase.ali
gnatlink testcase.ali
$ ./testcase
Testcase
$

As the bug box mentions, I'm using a patched gcc version, known as gnat-aux,
usable on FreeBSD. However the bug has been confirmed on AdaCore's version by
several people in comp.lang.ada, so it is likely to be present in all GNAT
versions, so I'm still reporting it here.

[Bug middle-end/52472] ICE: in convert_debug_memory_address, at cfgexpand.c:2491

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
   Last reconfirmed|2012-03-03 00:00:00 |2012-03-28 0:00
   Host|mingw32 |

--- Comment #7 from Georg-Johann Lay  2012-03-28 
15:27:42 UTC ---
Reduced test-case: Compile with:

$ avr-gcc ice-memx.c -S -g -Os


extern const __memx unsigned data[][10];

unsigned long ice (void)
{
unsigned long addr32;

return addr32 = (unsigned long) data;
}

[Bug c/52753] New: GCC not honoring -fPIE

[noloader at gmail dot com]

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

 Bug #: 52753
   Summary: GCC not honoring -fPIE
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: noloa...@gmail.com


It appears GCC 4.6.1 is not honoring -fPIE under all circumstances. Below, I
expect to see "Elf file type is DYN"

$ cat warn-test.c
#include 

int main(int argc, char* argv[])
{
  (void)argc;
  (void)argv;

  printf("argc: %d\n", argc); 
  printf("argv: %p\n", argv); 
  printf("main: %p\n", &main); 

  return 0;
}

$ gcc -Wall -Wextra -O2 -fPIE -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack
-Wl,-z,noexecheap warn-test.c -o warn-test.exe/usr/bin/ld: warning: -z
noexecheap ignored.

$ ./warn-test.exe 
argc: 1
argv: 0x7fffe3139e28
main: 0x400440

$ ./warn-test.exe 
argc: 1
argv: 0x7fffbd2864f8
main: 0x400440

$ readelf -l warn-test.exe | grep "Elf file type"
Elf file type is EXEC (Executable file)

$ cat /proc/sys/kernel/randomize_va_space 2
2

$ uname -a
Linux mint-12-x64 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux

$ gcc --version
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug other/52754] New: [4.7 regression, miscompilation] indirect indexing broken with -fpredictive-commoning

[kretz at kde dot org]

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

 Bug #: 52754
   Summary: [4.7 regression, miscompilation] indirect indexing
broken with -fpredictive-commoning
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kr...@kde.org


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

The attached testcase is compiled to access the indexes array at bogus offsets.
If line 8 is removed and line 7 written as
unsigned int indexes[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
the error disappears.

% /opt/gcc-4.7.0/bin/g++ -msse2 -v -O1 -fpredictive-commoning main.cpp
Using built-in specs.
COLLECT_GCC=/opt/gcc-4.7.0/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc-4.7.0/libexec/gcc/x86_64-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ./configure --prefix=/opt/gcc-4.7.0 --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --enable-languages=c,c++,fortran
--with-gmp=/opt/gcc-4.7.0 --with-mpfr=/opt/gcc-4.7.0 --with-ppl=/opt/gcc-4.7.0
--with-cloog=/opt/gcc-4.7.0 --with-libelf=/opt/gcc-4.7.0
--with-mpc=/opt/gcc-4.7.0 --enable-lto
Thread model: posix
gcc version 4.7.0 (GCC)
COLLECT_GCC_OPTIONS='-msse2' '-v' '-O1' '-fpredictive-commoning'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /opt/gcc-4.7.0/libexec/gcc/x86_64-linux-gnu/4.7.0/cc1plus -quiet -v
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE main.cpp -quiet -dumpbase main.cpp
-msse2 -mtune=generic -march=x86-64 -auxbase main -O1 -version
-fpredictive-commoning -o /tmp/ccmv6Zx9.s
GNU C++ (GCC) version 4.7.0 (x86_64-linux-gnu)
compiled by GNU C version 4.7.0, GMP version 5.0.4, MPFR version 3.1.0,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../include/c++/4.7.0

/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../include/c++/4.7.0/x86_64-linux-gnu

/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../include/c++/4.7.0/backward
 /opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/include
 /usr/local/include
 /opt/gcc-4.7.0/include
 /opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++ (GCC) version 4.7.0 (x86_64-linux-gnu)
compiled by GNU C version 4.7.0, GMP version 5.0.4, MPFR version 3.1.0,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 32eb1a24aeca8b97e0c59b4b063f668f
COLLECT_GCC_OPTIONS='-msse2' '-v' '-O1' '-fpredictive-commoning'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'

/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../x86_64-linux-gnu/bin/as
--64 -o /tmp/cca4x2R5.o /tmp/ccmv6Zx9.s
COMPILER_PATH=/opt/gcc-4.7.0/libexec/gcc/x86_64-linux-gnu/4.7.0/:/opt/gcc-4.7.0/libexec/gcc/x86_64-linux-gnu/4.7.0/:/opt/gcc-4.7.0/libexec/gcc/x86_64-linux-gnu/:/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/:/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/:/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../x86_64-linux-gnu/bin/
LIBRARY_PATH=/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/:/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../x86_64-linux-gnu/lib/:/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-msse2' '-v' '-O1' '-fpredictive-commoning'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /opt/gcc-4.7.0/libexec/gcc/x86_64-linux-gnu/4.7.0/collect2 --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o
/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/crtbegin.o
-L/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0
-L/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../lib64
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../x86_64-linux-gnu/lib
-L/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/../../.. /tmp/cca4x2R5.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/opt/gcc-4.7.0/lib/gcc/x86_64-linux-gnu/4.7.0/crtend.o
/usr/lib/x86_64-linux-gnu/crtn.o

% ./a.out
[1]7716 bus error  ./a.out

[Bug c++/52755] New: Error on use of implicitly deleted operator=

[holger.hopp at sap dot com]

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

 Bug #: 52755
   Summary: Error on use of implicitly deleted operator=
Classification: Unclassified
   Product: gcc
   Version: 4.6.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: holger.h...@sap.com


Following code compiles fine with every gcc, with every g++ -std=c++98, 
with g++-4.5 -std=c++0x, but not with g++ -std=c++0x (or -std=c++11) since 4.6.

typedef volatile struct t1s { int a; } t1;
typedef struct t2s { t1 b; } t2;
t2 x, y;

void foo(void)
{
  x = y;
}

compile with: g++ -std=c++0x vola.cpp

vola.cpp: In function 'void foo()':
vola.cpp:7:7: error: use of deleted function 't2s& t2s::operator=(const t2s&)'
vola.cpp:2:16: error: 't2s& t2s::operator=(const t2s&)' is implicitly deleted
because the default definition would be ill-formed:
vola.cpp:2:16: error: no matching function for call to 't1s::operator=(const
volatile t1&) volatile'
vola.cpp:2:16: note: candidates are:
vola.cpp:1:25: note: t1s& t1s::operator=(const t1s&)
vola.cpp:1:25: note:   no known conversion for argument 1 from 'const volatile
t1' to 'const t1s&'
vola.cpp:1:25: note: t1s& t1s::operator=(t1s&&)
vola.cpp:1:25: note:   no known conversion for argument 1 from 'const volatile
t1' to 't1s&&'

[Bug other/52754] [4.7/4.8 Regression] indirect indexing broken with -fpredictive-commoning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2012-03-28
 CC||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|[4.7 regression,|[4.7/4.8 Regression]
   |miscompilation] indirect|indirect indexing broken
   |indexing broken with|with -fpredictive-commoning
   |-fpredictive-commoning  |
   Target Milestone|--- |4.7.1

--- Comment #1 from Jakub Jelinek  2012-03-28 
16:05:53 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178028

[Bug c/52753] GCC not honoring -fPIE

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andreas Schwab  2012-03-28 16:12:22 
UTC ---
You need to link with -pie to get a PIE.  Just like -fpic does not imply
-shared.

[Bug c/52753] GCC not honoring -fPIE

[noloader at gmail dot com]

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

--- Comment #2 from Jeffrey Walton  2012-03-28 
16:18:58 UTC ---
Thanks Andreas. Forgive my ignorance, but what does -fPIE do exactly (if not
enable Position Independent Executables)?

[Bug c/52747] No warning from toolchain with nested function and --noexecstack

[sch...@linux-m68k.org]

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

--- Comment #6 from Andreas Schwab  2012-03-28 16:27:48 
UTC ---
The trampoline is only referenced, but never used in your example.

[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from William J. Schmidt  2012-03-28 
16:28:42 UTC ---
Dominique, can you please post your patches out on the gcc-patches mailing list
so they can be approved?  Again, I'm happy to commit them once they've met
approval by the maintainers, but I'm not permitted to post other people's
patches.

Thanks,
Bill

[Bug other/52754] [4.7/4.8 Regression] indirect indexing broken with -fpredictive-commoning

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2012-03-28 
16:48:51 UTC ---
Seems ref_at_iteration is buggy, when iter is negative, but ARRAY_REF's index
is TYPE_UNSIGNED smaller than size of pointer, computing the ARRAY_REF's index
in the smaller unsigned type isn't a good idea, because then we end up with
those
0xfffdU etc. indexes while we want -3L.
Wonder if it is generally ok to do the computation in a wider type (if any),
or if we should just handle the simple cases (integer_onep (iv.step) ? ) and
punt otherwise.

[Bug other/52754] [4.7/4.8 Regression] indirect indexing broken with -fpredictive-commoning

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-03-28 
17:22:15 UTC ---
Created attachment 27023
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27023
gcc48-pr52754.patch

Patch I had in mind.  Seems to fix the testcase.  Richard, what do you think
about this?

[Bug middle-end/52756] New: [4.7 Regression] 255.vortex in SPEC CPU 2000 failed to build

[hjl.tools at gmail dot com]

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

 Bug #: 52756
   Summary: [4.7 Regression] 255.vortex in SPEC CPU 2000 failed to
build
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: areg.melikadam...@gmail.com


On Linux/x86-64, revision 185913 gave:

gcc -c -o env1.o  -fno-strict-aliasing -DSPEC_CPU2000_LP64 -O2
-ffast-math   env1.c
...
env1.c: In function 'Env_FetchObj0AttrOffset':
env1.c:1094:12: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
specmake[3]: *** [env1.o] Error 1

Revision 185825. is OK.

[Bug c++/52755] Error on use of implicitly deleted operator=

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-03-28 
17:39:52 UTC ---
(In reply to comment #0)
> Following code compiles fine with every gcc, with every g++ -std=c++98, 
> with g++-4.5 -std=c++0x, but not with g++ -std=c++0x (or -std=c++11) since 
> 4.6.

That's because G++ 4.6 was changed to reject your invalid program, it's
supposed to do that, and it means G++ 4.6 is better than G++ 4.5 :)

Isn't the error quite clear?

Assigning t2s needs to use the assignment operator, but that function can't be
implicitly-defined because assigning the volatile member requires
t1s::operator=(const volatile t1s&) which doesn't exist, because the
implicit-declared copy assignment operator has the signature
t1s::operator=(const t1s&)

To fix your code you should either define copy assignment for t1s so it works
on volatile objects, or define assignment for t2s so it doesn't need
t1s::operator= e.g.

  t2s& operator=(const t2s& t) { b.a = t.b.a; return *this; }

[Bug c++/52755] Error on use of implicitly deleted operator=

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-03-28 
17:45:24 UTC ---
(In reply to comment #1)
> Assigning t2s needs to use the assignment operator, but that function can't be
> implicitly-defined because assigning the volatile member requires
> t1s::operator=(const volatile t1s&) which doesn't exist, 

Actually that should say:

"t1s::operator=(const volatile t1s&) volatile" which doesn't exist,

[Bug middle-end/52693] Wrong code with SRA and arrays

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor  2012-03-28 
18:03:34 UTC ---
Author: jamborm
Date: Wed Mar 28 18:03:28 2012
New Revision: 185921

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185921
Log:
2012-03-28  Martin Jambor  

PR middle-end/52693
* tree-sra.c (sra_modify_assign): Do not call
load_assign_lhs_subreplacements when working with an unscalarizable
region.

* testsuite/gcc.dg/torture/pr52693.c: New test.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr52693.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/tree-sra.c

[Bug middle-end/52693] Wrong code with SRA and arrays

[jamborm at gcc dot gnu.org]

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

--- Comment #11 from Martin Jambor  2012-03-28 
18:20:28 UTC ---
Author: jamborm
Date: Wed Mar 28 18:20:20 2012
New Revision: 185923

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185923
Log:
2012-03-28  Martin Jambor  

PR middle-end/52693
* tree-sra.c (sra_modify_assign): Do not call
load_assign_lhs_subreplacements when working with an unscalarizable
region.

* testsuite/gcc.dg/torture/pr52693.c: New test.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr52693.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree-sra.c

[Bug middle-end/52693] Wrong code with SRA and arrays

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Jambor  2012-03-28 
18:22:49 UTC ---
Patch (http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01708.html)
applied to all affected branches (4.5, 4.6 and 4.7) and trunk.
Thus, fixed.

[Bug tree-optimization/52558] write introduction incorrect wrt the C++11 memory model

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |aldyh at gcc dot gnu.org
   |gnu.org |

--- Comment #13 from Aldy Hernandez  2012-03-28 
19:04:35 UTC ---
mine

[Bug libstdc++/52740] Unable to make gcc-4.x.x after successful configuration

[mohammadsohaibajmal at gmail dot com]

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

--- Comment #3 from mohammadsohaibajmal at gmail dot com 2012-03-28 19:07:57 
UTC ---
I have GLIBCXX_2.5 installed on my computer and I need version 3.4.9 or higher.
I needed to install version 4 or higher for gcc so I randomly chose to install
gcc-4.4.0. I can try 4.4.7 also

However, all steps I performed and errors I encounetred are imentioned below
Although I am not sure the error messages I got are sufficiently helpful or
not.

After downloading GCC and placing it in a directory I ran its configuration
script

/Gcc/gcc-4.4.0/configure --target=/usr/local/gcc-4.4.0/

It gave me error saying mpfr and gmp needs to be installed. I downloaded gmp
version  5.0.4 and mpfr version 3.1.0. For installing gmp I simply ran
following commands

./configure
make 
make install

Everything executed pretty smoothly. Afterwards for installing mpfr I followed
its instruction and first applied patch inside mpfr folder,as directed in
INSTALL file

curl http://www.mpfr.org/mpfr-3.1.0/allpatches | patch -N -Z -p1

patch was applied successfully

Afterwords I executed 

./configure

This gave me following WARNING at the end of execution

configure: WARNING: ==
configure: WARNING: 'gmp.h' and 'libgmp' seem to have different versions or
configure: WARNING: we cannot run a program linked with GMP (if you cannot
configure: WARNING: see the version numbers above). A cause may be different
configure: WARNING: GMP versions with different ABI's or the use of --with-gmp
configure: WARNING: or --with-gmp-include with a system include directory
configure: WARNING: (such as /usr/include or /usr/local/include).
configure: WARNING: However since we can't use 'libtool' inside the configure,
configure: WARNING: we can't be sure. See 'config.log' for details.
configure: WARNING: ==

At the end it said that creating Makefile etc. Afterwards I ran 

make 
make check
make install

No error appeared in this whole procedure except for above mentioned warning.

Afterwards I again ran configure script of gcc as mentioned above, which
finished succefully saying "creating Makefile"

/Gcc/gcc-4.4.0/configure --target=/usr/local/gcc-4.4.0/

But when I ran make it gave me following error as in my first post 

make [2]: Leaving directory '/root/fixincludes'
make [1]: *** [all-fixincludes] Error 2
make [1]: Leaving directory '/root'
make: *** [all] Error 2

This is all the erro rit showed me. I have no Idea what to do about it. If
there is a better and stable version which can give me GLIBC3.4.9 I'll use
that, and also can you please refer to me appropriate guide for installing GCC
because the instructions available on this website has so many configurations
that I do not know which one will be appropriate.
Another Important point to note is after even the installation of mentioned
versions of gmp and mpfr when I do rpm -qa|grep gmp and rpm -qa|grep mpfr the
output I get is older version for gmp installed by distro and no output for
mpfr? 

So I have not been able to install them properly despite no error I received,
or any other configuration is requried. I followed their INSTALL guides in
their folders.

Thank you very much for assistance that you can provide in this regard.

[Bug rtl-optimization/48133] [4.5/4.6/4.7/4.8 Regression] ICE: in get_loop_body, at cfgloop.c:831 with -O -funroll-loops -fthread-jumps -fno-tree-ch

[dcb314 at hotmail dot com]

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

dcb  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #8 from dcb  2012-03-28 19:36:17 UTC ---

I am also seeing this problem when compiling the new Linux kernel version 3.3

[Bug libstdc++/52740] Unable to make gcc-4.x.x after successful configuration

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-03-28 
19:46:04 UTC ---
(In reply to comment #3)
> I have GLIBCXX_2.5 installed on my computer and I need version 3.4.9 or 
> higher.
> I needed to install version 4 or higher for gcc so I randomly chose to install
> gcc-4.4.0. I can try 4.4.7 also

"Randomly" picking a .0 release is a terrible idea.  It is the first release
from a new series so inevitably has bugs which will be fixed in later versions,
so if you're going to choose a 4.4 release, pick the latest one not the most
buggy one of the whole series.

> However, all steps I performed and errors I encounetred are imentioned below
> Although I am not sure the error messages I got are sufficiently helpful or
> not.
> 
> After downloading GCC and placing it in a directory I ran its configuration
> script
> 
> /Gcc/gcc-4.4.0/configure --target=/usr/local/gcc-4.4.0/
> 
> It gave me error saying mpfr and gmp needs to be installed. I downloaded gmp
> version  5.0.4 and mpfr version 3.1.0. For installing gmp I simply ran
> following commands
> 
> ./configure
> make 
> make install
> 
> Everything executed pretty smoothly. Afterwards for installing mpfr I followed
> its instruction and first applied patch inside mpfr folder,as directed in
> INSTALL file
> 
> curl http://www.mpfr.org/mpfr-3.1.0/allpatches | patch -N -Z -p1

Don't use mpfr 3.1.0, it's known not to work, see PR 50461 for details.

As it says at http://gcc.gnu.org/install/prerequisites.html "Newer versions may
work in some cases, but it's safer to use the exact versions documented."  


> patch was applied successfully
> 
> Afterwords I executed 
> 
> ./configure
> 
> This gave me following WARNING at the end of execution
> 
> configure: WARNING: ==
> configure: WARNING: 'gmp.h' and 'libgmp' seem to have different versions or
> configure: WARNING: we cannot run a program linked with GMP (if you cannot
> configure: WARNING: see the version numbers above). A cause may be different
> configure: WARNING: GMP versions with different ABI's or the use of --with-gmp
> configure: WARNING: or --with-gmp-include with a system include directory
> configure: WARNING: (such as /usr/include or /usr/local/include).
> configure: WARNING: However since we can't use 'libtool' inside the configure,
> configure: WARNING: we can't be sure. See 'config.log' for details.
> configure: WARNING: ==

This is probably because you already had GMP isntalled somewhere, so installing
it again gives you two incompatible versions.

> At the end it said that creating Makefile etc. Afterwards I ran 
> 
> make 
> make check
> make install
> 
> No error appeared in this whole procedure except for above mentioned warning.
> 
> Afterwards I again ran configure script of gcc as mentioned above, which
> finished succefully saying "creating Makefile"
> 
> /Gcc/gcc-4.4.0/configure --target=/usr/local/gcc-4.4.0/
> 
> But when I ran make it gave me following error as in my first post 
> 
> make [2]: Leaving directory '/root/fixincludes'
> make [1]: *** [all-fixincludes] Error 2
> make [1]: Leaving directory '/root'
> make: *** [all] Error 2
> 
> This is all the erro rit showed me.

No it isn't, it will have printed many, MANY lines of output, and the error is
not shown in the last four lines you've copied.

> I have no Idea what to do about it.

I've already given you the link:
"Please read http://gcc.gnu.org/wiki/InstallingGCC and ensure you are not
making
the common mistakes listed there."

That page describes a foolproof way to build GCC, with the first suggestion
being the simplest: install gmp-devel and mpfr-devel RPMs from your
distribution.

> If
> there is a better and stable version which can give me GLIBC3.4.9 I'll use
> that, and also can you please refer to me appropriate guide for installing GCC

I already referred you to the simpler instruction on the wiki.

Please read it and you'll save us both time and effort.

> because the instructions available on this website has so many configurations
> that I do not know which one will be appropriate.
> Another Important point to note is after even the installation of mentioned
> versions of gmp and mpfr when I do rpm -qa|grep gmp and rpm -qa|grep mpfr the
> output I get is older version for gmp installed by distro and no output for
> mpfr? 

Of course, because you didn't install RPMs, you installed from source, so
obviously the rpm tool doesn't know about the other versions.

PLEASE READ http://gcc.gnu.org/wiki/InstallingGCC !

Basically, I suggest you delete the versions of gmp and mpfr you installed
manually and then use your distro's package management tool to install
gmp-devel and mpfr-devel RPMs.

[Bug c++/52757] New: [C++11] A lamba functions is not able to be used as a function pointer when passed as an explicit template argument

[metaprogrammingtheworld at gmail dot com]

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

 Bug #: 52757
   Summary: [C++11] A lamba functions is not able to be used as a
function pointer when passed as an explicit template
argument
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: metaprogrammingthewo...@gmail.com


The following are two simple test-cases for what appears to be the same
problem. The main issue is that you can't use a lambda function as a template
argument where the template parameter type is a function pointer type. It seems
that this happens because there is no constexpr conversion operator from the
lambda function type to the corresponding function pointer type (in places
where the pointer is not required to be a compile-time constant, the conversion
works properly, as expected).

First test-case:

//
template< int (*)() > struct foo;
typedef foo< [] { return 0; } > bar;
//

main.cpp:2:31: error: could not convert template argument '{}' to 'int (*)()'
main.cpp:2:36: error: invalid type in declaration before ';' token



Second test-case (error message may shed light on the root of the problem):

//
constexpr int (*foo)() = [] { return 0; };
//

main.cpp:1:41: error: '::operator int (*)()() const' is not a
constexpr function

[Bug c++/52757] [C++11] A lamba functions is not able to be used as a function pointer when passed as an explicit template argument

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-03-28 
19:58:41 UTC ---
(In reply to comment #0)
> that this happens because there is no constexpr conversion operator from the
> lambda function type to the corresponding function pointer type 

Is there supposed to be?

"The closure type for a lambda-expression with no lambda-capture has a public
non-virtual non-explicit const conversion function to pointer to function
having the same parameter and return types as the closure type's function call
operator. The value returned by this conversion function shall be the address
of a function that, when invoked, has the same effect as invoking the closure
type's function call operator."

A closure is not literal and its conversion operator isn't constexpr.

[Bug c++/52757] [C++11] A lamba functions is not able to be used as a function pointer when passed as an explicit template argument

[metaprogrammingtheworld at gmail dot com]

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

--- Comment #2 from Matt Calabrese  
2012-03-28 20:10:02 UTC ---
Hmm. That seems artificially limiting, but thanks for looking it up -- sorry
for the erroneous bug report.

[Bug c++/52757] [C++11] A lamba functions is not able to be used as a function pointer when passed as an explicit template argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Jonathan Wakely  2012-03-28 
20:13:37 UTC ---
.

[Bug fortran/52652] call to gfc_match_asynchronous for allocatable at parse.c line 164

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  2012-03-28 20:45:30 
UTC ---
Author: pault
Date: Wed Mar 28 20:45:16 2012
New Revision: 185924

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185924
Log:
2012-03-28  Paul Thomas  
Tobias Burnus  

PR fortran/52652
* match.c (gfc_match_allocate, gfc_match_deallocate): Change
"not.. or" to "neither.. nor".
* parse.c (decode_specification_statement): Correct error in
chpice of matching function for "allocatable". 

2012-03-28  Paul Thomas  
Tobias Burnus  

PR fortran/52652
* gfortran.dg/allocate_class_1.f90 : Change error test.
* gfortran.dg/allocate_with_typespec_4.f90 : Change error test.
* gfortran.dg/allocate_alloc_opt_1.f90 : Change error test.
* gfortran.dg/deallocate_alloc_opt_1.f90 : Change error test.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/parse.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_1.f90
trunk/gcc/testsuite/gfortran.dg/allocate_class_1.f90
trunk/gcc/testsuite/gfortran.dg/allocate_with_typespec_4.f90
trunk/gcc/testsuite/gfortran.dg/deallocate_alloc_opt_1.f90

[Bug fortran/52652] call to gfc_match_asynchronous for allocatable at parse.c line 164

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||pault at gcc dot gnu.org
 Resolution||FIXED

--- Comment #3 from Paul Thomas  2012-03-28 20:51:02 
UTC ---
Thanks for the good call, Brian!

Fixed on trunk

Paul

[Bug libfortran/52758] New: libgfortran/intrinsics/chmod.c: Array index out of bounds

[dcb314 at hotmail dot com]

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

 Bug #: 52758
   Summary: libgfortran/intrinsics/chmod.c: Array index out of
bounds
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


I just tried to analyse the source code of 
trunk 20120328 with static analysis tool cppcheck.

The cppcheck said

[libgfortran/intrinsics/chmod.c:144]: (error) Array 'rwxXstugo[9]' index 9 out
of bounds

Source code is

  rwxXstugo[9] = false;

but

  bool rwxXstugo[9];

I am surprised the usual gcc checks don't catch this.

[Bug c++/52759] New: ICE in 4.7.0, C++ in cp/mangle.c

[adrian at llnl dot gov]

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

 Bug #: 52759
   Summary: ICE in 4.7.0, C++ in cp/mangle.c
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: adr...@llnl.gov


The machine is running Ubuntu 10.04, 64 bit on an Intel Xeon.

g++ test.cxx -c
test.cxx:8:42: internal compiler error: in mangle_decl_string, at
cp/mangle.c:3306
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Attached is the delta-reduced example.

[Bug c++/52759] ICE in 4.7.0, C++ in cp/mangle.c

[adrian at llnl dot gov]

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

--- Comment #1 from Adrian Prantl  2012-03-28 21:42:11 
UTC ---
Created attachment 27024
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27024
delta-reduced example

[Bug tree-optimization/52760] New: Revision 185599 causes miscompare on sphinx3

[pthaugen at gcc dot gnu.org]

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

 Bug #: 52760
   Summary: Revision 185599 causes miscompare on sphinx3
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pthau...@gcc.gnu.org
CC: berg...@gcc.gnu.org, rgue...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


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

The fix for pr52636 (r185599) introduced a miscompare for cpu2006 benchmark
482.sphinx3 on PowerPC. Attatched testcase can be run and shows incorrect
results.

temp/sphinx3> gcc -m64 -O3 -mcpu=power7 junk.c
temp/sphinx3> a.out
Result = 0101 0303 0505 0707


Output should be:
Result = 0100 0302 0504 0706

[Bug rtl-optimization/52629] out-of-bounds access in reload1.c

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.8.0

--- Comment #3 from Eric Botcazou  2012-03-28 
21:51:51 UTC ---
On the trunk only.

[Bug c++/52597] [C++11] missing diagnostics for invalid use of non-static member function in decltype

[hstong at ca dot ibm.com]

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

--- Comment #2 from Hubert Tong  2012-03-28 23:51:37 
UTC ---
The message from 4.7.0 does not really make sense, although it probably does
fix the functional issues associated with the reported bug in contexts where
SFINAE applies.

[Bug fortran/52724] Internal read with character(kind=4) data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #2 from Jerry DeLisle  2012-03-29 
01:05:20 UTC ---
I am curious about what this line is doing:

buffer4 = 4_'123'

buffer4 is a kind=1 variable.  have you tried: character(kind=4) buffer4(100) ?

[Bug c++/52761] New: [C++11] Missing diagnostic for opaque unscoped enum declaration without base

[hstong at ca dot ibm.com]

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

 Bug #: 52761
   Summary: [C++11] Missing diagnostic for opaque unscoped enum
declaration without base
Classification: Unclassified
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu


### Self-contained source:$ cat enumredecl.cc
enum E { X };
enum E;  // illegal


### Analysis:
For C++2011, subclause 7.2 [dcl.enum] paragraph 2 says:
An opaque-enum-declaration declaring an unscoped enumeration shall not omit the
enum-base.

The code is also invalid under C++03.
The "redeclaration" does not meet the requirements in C++03 clause 7 [dcl.dcl]
paragraph 3 for the omission of the init-declarator-list in a simple-
declaration. Namely, it is not a class definition or declaration and is not a
enum definition.

It also fails to requirements in subclause 7.1.5.3 [dcl.type.elab] paragraph 1
for an elaborated-type-specifier that is the sole constituent of a declaration.
Namely, it is neither an explicit specialization, explicit instantiation, class
declaration nor friend class declaration.


### Compiler invocations:
$ g++-4.6.0 --std='c++0x' -Wall -W -pedantic enumredecl.cc -c
$ g++-4.6.0 --std='c++98' -Wall -W -pedantic enumredecl.cc -c


### Compiler output (both cases):
(return code 0)


### g++ -v output:$ g++-4.6.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.6.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ./configure --prefix=/data/gcc --program-suffix=-4.6.0
--disable-libssp --disable-libgcj --enable-version-specific-runtime-libs
--with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared
--enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran
--with-gmp=/usr/local
Thread model: posix
gcc version 4.6.0 (GCC)

[Bug middle-end/51200] Wrong code sequence to store restrict volatile bitfield

[jye2 at gcc dot gnu.org]

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

--- Comment #7 from jye2 at gcc dot gnu.org 2012-03-29 02:15:37 UTC ---
Author: jye2
Date: Thu Mar 29 02:15:29 2012
New Revision: 185944

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185944
Log:
2012-03-28  Joey Ye  

Backported from mainline
2011-12-20  Bernd Schmidt  

PR middle-end/51200
* expr.c (store_field): Avoid a direct store if the mode is larger
than the size of the bit field.
* stor-layout.c (layout_decl): If flag_strict_volatile_bitfields,
treat non-volatile bit fields like volatile ones.
* toplev.c (process_options): Disallow combination of
-fstrict-volatile-bitfields and ABI versions less than 2.
* config/arm/arm.c (arm_option_override): Don't enable
flag_strict_volatile_bitfields if the ABI version is less than 2.
* config/h8300/h8300.c (h8300_option_override): Likewise.
* config/rx/rx.c (rx_option_override): Likewise.
* config/m32c/m32c.c (m32c_option_override): Likewise.
* config/sh/sh.c (sh_option_override): Likewise.

2011-12-22  Joey Ye  

* toplev.c (process_options): Fix typo.

testcases:

Backported from mainline
2011-12-20  Bernd Schmidt  

PR middle-end/51200
* gcc.target/arm/volatile-bitfields-4.c: New test.
* c-c++-common/abi-bf.c: New test.

2011-12-26  Joey Ye  

PR middle-end/51200
* gcc.dg/volatile-bitfields-2.c: New test.


Added:
branches/gcc-4_6-branch/gcc/testsuite/c-c++-common/abi-bf.c
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/volatile-bitfields-2.c
branches/gcc-4_6-branch/gcc/testsuite/gcc.target/arm/volatile-bitfields-4.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/arm/arm.c
branches/gcc-4_6-branch/gcc/config/h8300/h8300.c
branches/gcc-4_6-branch/gcc/config/m32c/m32c.c
branches/gcc-4_6-branch/gcc/config/rx/rx.c
branches/gcc-4_6-branch/gcc/config/sh/sh.c
branches/gcc-4_6-branch/gcc/expr.c
branches/gcc-4_6-branch/gcc/stor-layout.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/toplev.c

[Bug c++/52746] [4.7/4.8 Regression] Explicit virtual destructor call replaced by direct call in template function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |

[Bug middle-end/32074] Optimizer does not exploit assertions

[scovich at gmail dot com]

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

--- Comment #5 from Ryan Johnson  2012-03-29 02:46:50 
UTC ---
(In reply to comment #4)
> We have __builtin_unreachable() now which should allow for this optimization.

I've been using __builtin_unreachable() for some time now, and it's very nice
for its intended purpose (telling gcc when it's safe to produce better code).
I've noticed, though, that the ``x'' passed to assert(x) in already-existing
code is often too expensive (or side effect-ful) to optimize away when
converted to ``if(!(x)) { __builtin_unreachable(); }'' 

I would therefore advise against executing the expression passed to assertions
under NDEBUG. I use the following in my own code instead:

#ifdef NDEBUG
#define ASSUME(x) do { if (!(x)) __builtin_unreachable(); } while (0)
#else
#define ASSUME assert
#endif

The idea is to state assumptions that might help the compiler generate better
code... treating them like assertions in debug mode to catch faulty
assumptions. Assertions, meanwhile, should retain their traditional purpose of
debugging aid or sanity test and continue to disappear completely in NDEBUG
node.

Recommend to close as WONTFIX, unless there are other reasons to keep it open.

[Bug c++/52746] [4.7/4.8 Regression] Explicit virtual destructor call replaced by direct call in template function

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2012-03-29 
02:58:33 UTC ---
Author: jason
Date: Thu Mar 29 02:58:29 2012
New Revision: 185945

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185945
Log:
PR c++/52746
* typeck.c (lookup_destructor): Clear BASELINK_QUALIFIED_P if
we didn't get an explicit scope.
* pt.c (tsubst_baselink): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/overload/virtual2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[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 #9 from Benjamin Kosnik  2012-03-29 
06:14:41 UTC ---
Author: bkoz
Date: Thu Mar 29 06:14:32 2012
New Revision: 185950

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

PR libstdc++/52689
* libsupc++/Makefile.am (LTCXXCOMPILE, CXXLINK): Tweak.
* libsupc++/Makefile.in: Regenerated.
* src/Makefile.am (LTCXXCOMPILE, CXXLINK): Tweak.
(libstdc___la_SOURCES): Add in compatiblity files, with content
that varies with -DPIC.
* src/Makefile.in: Regenerated.
* src/c++11/Makefile.am (LTCXXCOMPILE, CXXLINK): Tweak.
* src/c++11/Makefile.in: Regenerated.
* src/c++11/compatibility-atomic-c++0x.cc: Guard with PIC.
* src/c++11/compatibility-c++0x.cc: Same.
* src/c++11/future.cc: Consolidate compatibility bits into..
* src/c++11/mutex.cc: Consolidate compatibility bits into..
* src/c++11/compatibility-thread-cxx0x.cc: ...here. New.
* src/c++98/Makefile.am (LTCXXCOMPILE, CXXLINK): Tweak.
* src/c++98/Makefile.in: Regenerated.
* src/c++98/compatibility-ldbl.cc: Guard with PIC
* src/c++98/compatibility-list-2.cc: Same.
* src/c++98/compatibility-list.cc: Same.
* src/c++98/compatibility.cc: Tweak comments.

Added:
trunk/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc
  - copied, changed from r185946, trunk/libstdc++-v3/src/c++11/mutex.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/Makefile.am
trunk/libstdc++-v3/libsupc++/Makefile.in
trunk/libstdc++-v3/src/Makefile.am
trunk/libstdc++-v3/src/Makefile.in
trunk/libstdc++-v3/src/c++11/Makefile.am
trunk/libstdc++-v3/src/c++11/Makefile.in
trunk/libstdc++-v3/src/c++11/compatibility-atomic-c++0x.cc
trunk/libstdc++-v3/src/c++11/compatibility-c++0x.cc
trunk/libstdc++-v3/src/c++11/future.cc
trunk/libstdc++-v3/src/c++11/mutex.cc
trunk/libstdc++-v3/src/c++98/Makefile.am
trunk/libstdc++-v3/src/c++98/Makefile.in
trunk/libstdc++-v3/src/c++98/compatibility-ldbl.cc
trunk/libstdc++-v3/src/c++98/compatibility-list-2.cc
trunk/libstdc++-v3/src/c++98/compatibility-list.cc
trunk/libstdc++-v3/src/c++98/compatibility.cc

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

[fragabr at gmail dot com]

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

 Bug #: 52762
   Summary: Firefox 11 segfault with gcc 4.7 (-O3
-march=corei7-avx)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: frag...@gmail.com


I compiled Firefox 11 source code with gcc 4.7 and the following optimization:

-O3 -march=corei7-avx (for Sandy Bridge, core i7 2700k)

If i use just -march=corei7 it runs fine. GCC bug?

It compiled fine, but it segfaults:

#0  0x7f6e37521360 in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#1  0x7f6e3752d099 in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#2  0x7f6e3753e3fa in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#3  0x7f6e3753a073 in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#4  0x7f6e37874bdf in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#5  0x7f6e378740db in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#6  0x7f6e285fb3c0 in ?? ()
#7  0x0003 in ?? ()
#8  0x7f6e1dc35da0 in ?? ()
#9  0x7f6e1f0c3fd0 in ?? ()
#10 0x7f6e1f31df30 in ?? ()
#11 0x7f6e1e6e3e90 in ?? ()
#12 0xff00 in ?? ()
#13 0x00ff in ?? ()
#14 0x00444949534a736e in ?? ()
#15 0x726567616e614d79 in ?? ()
#16 0x32850f003a0074f4 in ?? ()
#17 0x777c81004085 in ?? ()
#18 0x0e850f003f00 in ?? ()
#19 0x83c35d5b04718901 in ?? ()
#20 0x0019 in ?? ()
#21 0x7f6e37174c38 in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#22 0x7f6e371749f9 in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#23 0x7f6e37874014 in NS_InvokeByIndex_P () from
/usr/local/lib/firefox-11.0/libxul.so
#24 0x7f6e375437c7 in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#25 0x7f6e37548940 in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#26 0x7f6e37ad7d53 in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#27 0x7f6e37ac765c in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#28 0x7f6e37ad7d14 in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#29 0x7f6e37ad8562 in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#30 0x7f6e37a4b3d7 in JS_CallFunctionValue () from
/usr/local/lib/firefox-11.0/libxul.so
#31 0x7f6e3753e727 in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#32 0x7f6e3753a073 in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#33 0x7f6e37874bdf in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#34 0x7f6e378740db in ?? () from /usr/local/lib/firefox-11.0/libxul.so
#35 0x7f6e23861700 in ?? ()
#36 0x7f6e1dc32280 in ?? ()
#37 0x7f6e23861700 in ?? ()
#38 0x7f6e24aeb110 in ?? ()
#39 0x7f6e24aeb110 in ?? ()
#40 0x0002 in ?? ()
#41 0x in ?? ()