[Bug c++/58040] New: Cannot take address-of public using-declaration of member from protected base class

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040 Bug ID: 58040 Summary: Cannot take address-of public using-declaration of member from protected base class Product: gcc Version: 4.8.1 Status: UNCONFIRMED

[Bug middle-end/58041] New: Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 Bug ID: 58041 Summary: Unaligned access to arrays in packed structure Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 30579 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30579action=edit test case to show the bug

[Bug c++/58040] Cannot take address-of public using-declaration of member from protected base class

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC|

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Sandra, this seems to be unrelated to your strict-volatile-bitfields patch, as it happens with or without that patch.

[Bug lto/58042] New: MinGW GCC produces problematic x64 executable with -O2 -static -flto -m64

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58042 Bug ID: 58042 Summary: MinGW GCC produces problematic x64 executable with -O2 -static -flto -m64 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity:

[Bug fortran/58043] New: Incorrect behaviour of polymorphic array

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043 Bug ID: 58043 Summary: Incorrect behaviour of polymorphic array Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot

[Bug c++/58040] Cannot take address-of public using-declaration of member from protected base class

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||fabien at

[Bug c++/57734] Returning template alias to enum class fails with invalid declarator

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57734 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- This isn't just about returning, eg: typedef eclass_aliasvoid test;

[Bug c++/32197] ICE when compiling with gcov options

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32197 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug c++/34624] templated code is rejected different type in nontype template argument

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34624 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug c++/36266] C++ typedef misplaced in DWARF information

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36266 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org

[Bug c++/37140] type inherited from base class not recognized

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|fabien at gcc dot gnu.org |

[Bug c++/37140] type inherited from base class not recognized

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||wschmidt at gcc

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se --- I see the exact same failure pattern on sparc64-linux: 4.7 generates working code, 4.8 and 4.9 generate code that SIGBUS:es, failure starts with r190037, -m32 or -m64 makes no

[Bug libfortran/58020] Code for handling IEEE exceptions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- The issues have hopefully been resolved and are now in the package. See http://mathalacarte.com/hpcconsult Thanks for the comments made above. Give feedback where it

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #6 from Bill Schmidt wschmidt at gcc dot gnu.org --- I'll investigate. It may be a day or two before I can get to it, but this is pretty clearly my issue. Thanks, Bill

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55956 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|SUSPENDED |WAITING

[Bug inline-asm/58044] New: -mno-see2avx does not seems to work

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58044 Bug ID: 58044 Summary: -mno-see2avx does not seems to work Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm

[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code

[Bug c++/58045] New: gcc 4.8 produces an undefined reference to an inline function

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58045 Bug ID: 58045 Summary: gcc 4.8 produces an undefined reference to an inline function Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #13 from Martin Jambor jamborm at gcc dot gnu.org --- Created attachment 30583 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30583action=edit Untested fix This is how I'd like to fix the problem if the patch passes bootstrap and

[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043 --- Comment #2 from janus at gcc dot gnu.org --- Here is a reduced test case, which demonstrates the same problem in a somewhat more compact manner: program main implicit none type :: adof_t real :: grd(1:2) end type

[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043 --- Comment #3 from janus at gcc dot gnu.org --- The WRITE of the second element in main is translated into: _gfortran_transfer_real_write (dt_parm.7, (real(kind=4) *) ((struct adof_t *) dofs._data.data + (sizetype) ((dofs._data.offset + 1) *

[Bug fortran/55207] Automatic deallocation of variables declared in the main program

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 --- Comment #9 from janus at gcc dot gnu.org --- (In reply to janus from comment #8) I think we need the patch in comment 6 after all. But how do we get rid of the remaining regressions? Simplest solution: Move the code in these test cases from

[Bug fortran/55207] Automatic deallocation of variables declared in the main program

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 janus at gcc dot gnu.org changed: What|Removed |Added Attachment #28620|0 |1 is obsolete|

[Bug c++/58046] New: template operator= in SFINAE class

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58046 Bug ID: 58046 Summary: template operator= in SFINAE class Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug libfortran/58020] Code for handling IEEE exceptions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #12 from richard.koolhans at gmail dot com --- Thanks for doing the test with -O3. That is what I see, also. My tests show: With -O0 everything works. With -O1 everything runs but there are some failures. With -O2 everything runs

[Bug c++/58047] New: parse error with typedef introduced from base class

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047 Bug ID: 58047 Summary: parse error with typedef introduced from base class Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #8 from Martin Jambor jamborm at gcc dot gnu.org --- I believe that you need to set alignment of the type of MEM_REFs you create in replace_ref along the lines it is done in build_ref_for_offset in tree-sra.c. I wonder whether

[Bug c/58048] New: internal compiler error: Max. number of generated reload insns per insn is achieved (90)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048 Bug ID: 58048 Summary: internal compiler error: Max. number of generated reload insns per insn is achieved (90) Product: gcc Version: 4.8.1 Status: UNCONFIRMED

[Bug c/58048] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #9 from Martin Jambor jamborm at gcc dot gnu.org --- More specifically, if I am correct assuming that the MEM_REF replace_ref builds always accesses exactly the same memory as the previous access *expr does (and only the address is

[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #6 from Roy Stogner roystgnr at ices dot utexas.edu --- Copyright assignment shouldn't be a problem. The one serious non-technical problem is going to be finding time to work on a patch. The only technical issue I've discovered so

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #10 from Martin Jambor jamborm at gcc dot gnu.org --- Created attachment 30587 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30587action=edit x86_64-linux testcase To prove the point, this is an x86_64-linux testcase. I will

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #11 from Bill Schmidt wschmidt at gcc dot gnu.org --- Hi Martin, Your assumptions are correct, but I'm not sure this is the best place to handle it. It looks like what you are doing is replacing one already correct memory reference

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #12 from Bill Schmidt wschmidt at gcc dot gnu.org --- ...which apparently is not quite right, since the candidates still appear in the table. Hm. But you get the idea -- do the check earlier.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #13 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Hi, just one question, how about the -m[no-]unaligned-access option? If -munaligned-access had been given the code was almost right, I mean AFAIK ldr/str should be handled

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #14 from Bill Schmidt wschmidt at gcc dot gnu.org --- (In reply to Bernd Edlinger from comment #13) Hi, just one question, how about the -m[no-]unaligned-access option? If -munaligned-access had been given the code was almost

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #15 from Bill Schmidt wschmidt at gcc dot gnu.org --- Bernd, Mikael, Martin: Could you please test this on your respective targets? Index: gcc/gimple-ssa-strength-reduction.c

[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- I think so, yes. Your help is welcome anyway, worst case, we'll apply the changes for the next release series instead of 4.9. In a few hours I will send you privately the

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #16 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Bill Schmidt from comment #15) Bernd, Mikael, Martin: Could you please test this on your respective targets? Congatulations! it works. If I compile with

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #17 from Bill Schmidt wschmidt at gcc dot gnu.org --- Excellent! Thanks for the confirmation.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #18 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Bill Schmidt from comment #15) Bernd, Mikael, Martin: Could you please test this on your respective targets? This patch eliminates the misalignment faults for me on

[Bug c++/54537] undiagnosed using-declaration conflicting with used function

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug c++/54537] undiagnosed using-declaration conflicting with used function

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|CLOSED ---

[Bug fortran/57710] [OOP] [F08] _vptr not set for allocatable CLASS component inside BLOCK

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57710 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to janus from comment #2) Can't we do a 'static' initialization (of _vptr *and* _data) in both cases? Well, you need to free and finalize the variable - hence, it cannot

[Bug rtl-optimization/57963] LRA S/390: esa mode failure memcpy-chk

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57963 --- Comment #1 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Thanks, Andreas. I've reproduced the bug. I hope to fix it on this week.

[Bug tree-optimization/57994] Constant folding of infinity

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994 --- Comment #13 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- A difference that may occur in the future if the C library adds a rsqrt function (based on the IEEE 754-2008 rSqrt function) or constant folding is used on builtins: in MPFR,

[Bug fortran/55207] Automatic deallocation of variables declared in the main program

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org --- Putting this inside a subroutine, one gets: class(c), pointer :: px = x 1 Error: Pointer initialization target at (1) must have the SAVE

[Bug fortran/55207] Automatic deallocation of variables declared in the main program

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 --- Comment #12 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #11) + if ((gfc_current_state () == COMP_MODULE + || gfc_current_state () == COMP_PROGRAM) I haven't tried the patch, but does it work

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306 --- Comment #11 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #10) Putting this inside a subroutine, one gets: class(c), pointer :: px = x 1 Error: Pointer initialization

[Bug c++/58046] template operator= in SFINAE class

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58046 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords|

[Bug c++/58047] parse error with typedef introduced from base class

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW

[Bug libstdc++/57779] vector insert fails to diagnose iterators pointing into *this in debug mode

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57779 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug middle-end/58041] Unaligned access to arrays in packed structure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #19 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Bill Schmidt from comment #15) Bernd, Mikael, Martin: Could you please test this on your respective targets? Well, my target is x86_64 but yes, it works. (In

[Bug libstdc++/58049] New: [4.9 Regression] libstdc++ bootstrap failure for fix to PR libstdc++/57779

: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org In file included from /tmp/20130801/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/ debug/safe_sequence.h:34:0, from /nasfarm/edelsohn

[Bug libstdc++/58049] [4.9 Regression] libstdc++ bootstrap failure for fix to PR libstdc++/57779

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58049 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last

[Bug c++/58050] New: RVO fails when calling static function through unnamed temporary

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58050 Bug ID: 58050 Summary: RVO fails when calling static function through unnamed temporary Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal

[Bug c++/58051] New: No named return value optimization when returned object is implicitly converted

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051 Bug ID: 58051 Summary: No named return value optimization when returned object is implicitly converted Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity:

[Bug c++/58052] New: Copy initialization using conversion operator does not find correct candidates for initialization of final result

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58052 Bug ID: 58052 Summary: Copy initialization using conversion operator does not find correct candidates for initialization of final result Product: gcc Version:

[Bug c++/58053] New: Bogus error ... is private ... within this context

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58053 Bug ID: 58053 Summary: Bogus error ... is private ... within this context Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c++/58053] Bogus error ... is private ... within this context

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58053 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED