[Bug middle-end/35308] Straight line strength reduction

2013-07-16 Thread wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35308 Bill Schmidt changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|---

[Bug libstdc++/57916] New: Improve std::sort paritioning by explicitly employing the pivot

2013-07-16 Thread alexey.tourbin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57916 Bug ID: 57916 Summary: Improve std::sort paritioning by explicitly employing the pivot Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement

[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy

2013-07-16 Thread brooks at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 Brooks Moses changed: What|Removed |Added CC||brooks at gcc dot gnu.org --- Comment #10

[Bug c/57915] New: ICE in set_address_disp, at rtlanal.c:5537

2013-07-16 Thread etienne_lorrain at yahoo dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57915 Bug ID: 57915 Summary: ICE in set_address_disp, at rtlanal.c:5537 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug fortran/57912] gfortran/coarray/alloc_comp_2.f90 ICE

2013-07-16 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57912 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCO

[Bug libstdc++/57914] New: Memory leak in __cxa_thread_atexit when using thread_local

2013-07-16 Thread stephen.d.croll at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57914 Bug ID: 57914 Summary: Memory leak in __cxa_thread_atexit when using thread_local Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Prio

[Bug fortran/57912] gfortran/coarray/alloc_comp_2.f90 ICE

2013-07-16 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57912 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1

[Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto

2013-07-16 Thread iains at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094 --- Comment #17 from Iain Sandoe --- Created attachment 30514 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30514&action=edit proposed fix. So the problem here is that when we bind multiple objects together (each of which has an anonymous i

[Bug target/55657] objc/obj-c++ failures present under darwin12

2013-07-16 Thread iains at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55657 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/55656] objc/obj-c++ failures present under darwin11

2013-07-16 Thread iains at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55656 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c++/56429] [C++11] Explicitly defaulted private constructor is not private

2013-07-16 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56429 Jonathan Wakely changed: What|Removed |Added CC||charlie at charliedyson dot net --- Com

[Bug c++/57913] [C++11] Explicitly defaulted constructor does not respect access specifier

2013-07-16 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57913 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

2013-07-16 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #20 from Jack Howarth --- (In reply to Iain Sandoe from comment #19) Yes. It might be a more profitable use of time to work on moving from the compatibility unwinder onto the newer compact unwinder for modern darwin.

[Bug c++/57913] New: [C++11] Explicitly defaulted constructor does not respect access specifier

2013-07-16 Thread charlie at charliedyson dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57913 Bug ID: 57913 Summary: [C++11] Explicitly defaulted constructor does not respect access specifier Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: norma

[Bug fortran/57912] New: gfortran/coarray/alloc_comp_2.f90 ICE

2013-07-16 Thread belagod at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57912 Bug ID: 57912 Summary: gfortran/coarray/alloc_comp_2.f90 ICE Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran

[Bug target/57911] New: alignment of arrays allocated stack on ARM : 4 bytes ?

2013-07-16 Thread yann at droneaud dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57911 Bug ID: 57911 Summary: alignment of arrays allocated stack on ARM : 4 bytes ? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Comp

[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?

2013-07-16 Thread yann at droneaud dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 --- Comment #10 from Yann Droneaud --- (In reply to Andrew Pinski from comment #9) > (In reply to Yann Droneaud from comment #8) > > Could someone comment on which optimisation is achieved by aligning such > > small arrays ? > > The simple answer

[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?

2013-07-16 Thread yann at droneaud dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 --- Comment #8 from Yann Droneaud --- Using -Os show different results: Arrays object | u8_0 | 0x7fff9b4c05bc |1 | 4 |1 object | u8_1 |

[Bug fortran/57910] New: ICE (segfault) with deferred-lemgth strings

2013-07-16 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57910 Bug ID: 57910 Summary: ICE (segfault) with deferred-lemgth strings Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal P

[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?

2013-07-16 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 --- Comment #9 from Andrew Pinski --- (In reply to Yann Droneaud from comment #8) > Could someone comment on which optimisation is achieved by aligning such > small arrays ? The simple answer is so each array is more likely to fit into a cache li

[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?

2013-07-16 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?

2013-07-16 Thread yann at droneaud dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 --- Comment #6 from Yann Droneaud --- Created attachment 30512 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30512&action=edit Demonstrate stack allocation of array aligned on 16 bytes

[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?

2013-07-16 Thread yann at droneaud dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 Yann Droneaud changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?

2013-07-16 Thread yann at droneaud dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 --- Comment #4 from Yann Droneaud --- (In reply to Andrew Pinski from comment #2) > Your test program is not fully testing things correctly. > kind name address size alignment required > > object | u8_5 |

[Bug target/57909] [ARM] ICE with internal memcpy and -mno-unaligned-access

2013-07-16 Thread yvan.roux at linaro dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 --- Comment #2 from Yvan Roux --- Created attachment 30511 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30511&action=edit a first fix

[Bug target/57909] [ARM] ICE with internal memcpy and -mno-unaligned-access

2013-07-16 Thread yvan.roux at linaro dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 --- Comment #1 from Yvan Roux --- The issue is that an UNSPEC_UNALIGNED_LOAD insn is emitted whereas the flag -mno-unaligned-access is passed, which implies that this insn is not recognized. The generation of the unaligned load is made in the gen

[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?

2013-07-16 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 Andrew Pinski changed: What|Removed |Added Target||x86_64-*-linux-gnu Status|UNC

[Bug c/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?

2013-07-16 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 --- Comment #2 from Andrew Pinski --- Your test program is not fully testing things correctly. kind name address size alignment required > object | u8_5 | 0x7fffefdd4810 |3 |16 |1 >

[Bug target/57909] New: [ARM] ICE with internal memcpy and -mno-unaligned-access

2013-07-16 Thread yvan.roux at linaro dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 Bug ID: 57909 Summary: [ARM] ICE with internal memcpy and -mno-unaligned-access Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priori

[Bug c/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?

2013-07-16 Thread yann at droneaud dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 --- Comment #1 from Yann Droneaud --- Additionally, for ARM target (ARMv7), it seems GCC align arrays on stack to 4 bytes boundary ... but I don't found the ABI specification that require such alignment. kind name addres

[Bug c/57908] New: alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?

2013-07-16 Thread yann at droneaud dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 Bug ID: 57908 Summary: alignment of arrays allocated stack on amd64/x86_64: 16 bytes ? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

2013-07-16 Thread iains at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #19 from Iain Sandoe --- I

[Bug testsuite/55956] Multiple failures on powerpc-apple-darwin9 in the acats test if the check-ada is run from the gcc directory

2013-07-16 Thread iains at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55956 --- Comment #4 from Iain Sandoe --- This is another manifestation of 44107. The installed libgcc_s on darwin9 has an unwinder that does not recognise modern gcc output. The testsuite usually hides this by setting DYLD_LIBRARY_PATH/LD_LIBRARY_PAT

[Bug c++/55203] No unused warning for variables of non-trivial types

2013-07-16 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #9 from Jonathan Wakely --- I can fix the docs some time.

[Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto

2013-07-16 Thread iains at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094 --- Comment #16 from Iain Sandoe --- *** Bug 55654 has been marked as a duplicate of this bug. ***

[Bug target/55654] objc/obj-c++ failures present under darwin10

2013-07-16 Thread iains at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55654 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/57907] New: warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch [enabled by default]

2013-07-16 Thread christian.helm...@genode-labs.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57907 Bug ID: 57907 Summary: warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch [enabled by default] Product: gcc Version: 4.7.3 Status: UNCONFIRMED

[Bug c++/55203] No unused warning for variables of non-trivial types

2013-07-16 Thread l.lunak at suse dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #8 from Lubos Lunak --- (In reply to Jonathan Wakely from comment #6) > Which are the relevant classes? It seems to me that we want to tag almost > everything except a few RAII types such as std::lock_guard and > std::unique_lock, whi

[Bug c++/57903] Object not getting constructed - Code misinterpreted as function declaration?

2013-07-16 Thread michael at dietschi dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57903 --- Comment #3 from michael at dietschi dot net --- Oops! Thanks for clarification and sorry for the noise.

[Bug fortran/57906] New: Coarray components: Assignment optimized away (gfortran.dg/coarray/lib_realloc_1.f90)

2013-07-16 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57906 Bug ID: 57906 Summary: Coarray components: Assignment optimized away (gfortran.dg/coarray/lib_realloc_1.f90) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keyw

[Bug c++/57903] Object not getting constructed - Code misinterpreted as function declaration?

2013-07-16 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57903 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/57905] New: braced-init-list allowed in default template-argument

2013-07-16 Thread potswa at mac dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57905 Bug ID: 57905 Summary: braced-init-list allowed in default template-argument Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compone

[Bug c++/55203] No unused warning for variables of non-trivial types

2013-07-16 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #7 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #6) > std::lock_guard that is unused is useless. Oops, I meant is *not* useless! Sorry.

[Bug c++/57846] CRTP, templates, metaprogramming, forwarding and static member

2013-07-16 Thread vince.rev at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57846 --- Comment #1 from Vincent --- Apparently, this is also a bug in the last version (4.9): http://stackoverflow.com/questions/17515079/crtp-templates-metaprogramming-forwarding-and-static-member-a-bug-in-g-4-8

[Bug c++/55203] No unused warning for variables of non-trivial types

2013-07-16 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #6 from Jonathan Wakely --- Which are the relevant classes? It seems to me that we want to tag almost everything except a few RAII types such as std::lock_guard and std::unique_lock, which would be quite tedious. It's certainly appli

[Bug fortran/57904] New: Bogus(?) "invokes undefined behavior" warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)

2013-07-16 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904 Bug ID: 57904 Summary: Bogus(?) "invokes undefined behavior" warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90) Product: gcc Version: 4.9.0

[Bug c++/57903] Object not getting constructed - Code misinterpreted as function declaration?

2013-07-16 Thread michael at dietschi dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57903 --- Comment #1 from michael at dietschi dot net --- Created attachment 30509 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30509&action=edit command-line and output

[Bug c++/57903] New: Object not getting constructed - Code misinterpreted as function declaration?

2013-07-16 Thread michael at dietschi dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57903 Bug ID: 57903 Summary: Object not getting constructed - Code misinterpreted as function declaration? Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: no