[Bug c++/52830] New: ICE: canonical types differ for identity types ... when attempting SFINAE with member type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830 Bug #: 52830 Summary: ICE: canonical types differ for identity types ... when attempting SFINAE with member type Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lucdan...@free.fr Created attachment 27061 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27061 Testcase Using $ gcc-snapshot --version gcc-snapshot (Debian 20120313-1) 4.8.0 20120313 (experimental) [trunk revision 185345] I get the following when attempting to compile what I believe to be a correct testcase program (although I could be wrong on correctness): main.cpp:25:21: internal compiler error: canonical types differ for identical types std::enable_ifstd::is_sametypename fooT::type, U::value, int and std::enable_ifstd::is_sameT, U::value, int The program compiles and behaves as expected if T is used instead of type/typename fooT::type in both declaration and definition, or if bar is defined inline.
[Bug c/52825] incorrect message for incompatible pointer type with extra struct for a typedeffed struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52825
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2012-04-02
07:09:49 UTC ---
Also happens with gcc 4.6, 4.5, and 4.4. gcc 4.3 and older just print passing
argument 1 of 'f' from incompatible pointer type without trying to show the
corresponding types.
The problem is that gcc incorrectly refers to the type foo from 'typedef struct
{...} foo;' (note: no struct tag) as 'struct foo' in the diagnostic.
[Bug fortran/52789] gfortran sets -Wunused-parameter in the C sense as well as the Fortran sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52789 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-04-02 07:40:32 UTC --- This may have been fixed with the fix for PR 48847. Can you maybe check on trunk/4.7.0 ?
[Bug c++/9050] [DR 147] Can't explicitly specialize C++ constructor templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9050 --- Comment #16 from Johannes Schaub schaub.johannes at googlemail dot com 2012-04-02 07:43:23 UTC --- (In reply to comment #15) (In reply to comment #14) Good point, I've pointed out the problem with the proposed resolution. Note that we currently have http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#581 open. Even when 12.1 would have allowed both the injected class name and it followed by template-arguments, the name lookup rules would never allow it to match the second condition because the injected class name would always have been translated to a name denoting the constructor instead of the class. So ultimately, 12.1 allowing the injected class name followed by template arguments could only be used in an unqualified-id constructor declaration in C++03.
[Bug fortran/52789] gfortran sets -Wunused-parameter in the C sense as well as the Fortran sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52789 --- Comment #4 from Mat Cross mathewc at nag dot co.uk 2012-04-02 08:03:22 UTC --- (In reply to comment #3) Can you maybe check on trunk/4.7.0 ? I've just tried with $ gfortran --version GNU Fortran (GCC) 4.7.1 20120331 (prerelease) $ gfortran -c -Wunused-parameter unused.f90 unused.f90:2.23: integer, parameter :: i = 0 1 Warning: Unused parameter 'i' declared at (1) unused.f90:1:0: warning: unused parameter ‘x’ [-Wunused-parameter] and $ gfortran --version GNU Fortran (GCC) 4.8.0 20120330 (experimental) [trunk revision 185988] $ gfortran -c -Wunused-parameter unused.f90 unused.f90:2.23: integer, parameter :: i = 0 1 Warning: Unused parameter 'i' declared at (1) unused.f90:1:0: warning: unused parameter ‘x’ [-Wunused-parameter]
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #31 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-02 08:16:52 UTC --- (In reply to comment #30) (In reply to comment #26) The caret is not a solution to this problem, because what Gabriel wants is to not reconstruct expressions ONLY when the caret is shown, but he has said in the past that the caret should default to OFF to not change the current output for IDEs and other software parsing the output of gcc like emacs, so we are back to printing the monsters mentioned above by default. I think I've said before that caret should default to on when the output is a terminal. Well, that is reassuring. Then, will we still pretty-print expressions in diagnostics once we have the caret? Is there a GCC way to detect that the output is a terminal?
[Bug c++/40942] GCC accepts code that Comeau and MSVC deems invalid.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40942 --- Comment #9 from Dodji Seketeli dodji at gcc dot gnu.org 2012-04-02 08:51:30 UTC --- Author: dodji Date: Mon Apr 2 08:51:26 2012 New Revision: 186067 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186067 Log: PR c++/40942 - Failure of template specialization partial ordering gcc/cp/ * pt.c (more_specialized_fn): Don't apply decay conversion to types of function parameters. gcc/testsuite/ * g++.old-deja/g++.pt/spec40.C: Adjust to take the resolution of DR 214 in account. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.old-deja/g++.pt/spec40.C
[Bug c++/40942] GCC accepts code that Comeau and MSVC deems invalid.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40942 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Dodji Seketeli dodji at gcc dot gnu.org 2012-04-02 08:56:24 UTC --- Fixed in 4.8 (trunk).
[Bug middle-end/52821] [4.8 Regression] 191.fma3d in SPEC CPU 2000 failed to build with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52821 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-02 09:10:16 UTC --- Ah great, thanks. For the FSF branches, I would say, let's just condition the assignment on 4.6 (+ testcase) and have the complete fix/improvement for 4.7/4.8. Can you send the patch to the mailing lists too? Minor nit: first blush, doesn't seem completely obvious to me what a 'true' predicate is - and normally we just have a test for each overload, eg, with/without predicate. Thus I would recommend extending a bit the comment in the testcase, even better also have a separate testcase (named as the PR #) for the specific case in the PR and also extend at will the existing test(s).
[Bug c++/52814] Internal compiler error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52814 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.1 Known to fail||4.6.0 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 09:12:27 UTC --- Fixed in 4.6.1.
[Bug bootstrap/52808] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52808 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-02 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 09:13:44 UTC --- Mine.
[Bug java/52805] [4.8 Regression] 243 new GCC HEAD@185977 regressions (libjava failures)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52805 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 09:14:35 UTC --- I also see the issue, all runtime tests fail with OOM.
[Bug c/52802] Equality rewrites pessimizes code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52802 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-04-02 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 09:16:20 UTC --- How would you do with a single compare?!
[Bug middle-end/52793] [4.8 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52793 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug rtl-optimization/52803] [4.8 Regression] ICE: in ira, at ira.c:3616 with -fno-move-loop-invariants on almost any code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52803 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-02 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 09:15:50 UTC --- Might be caused by my changes. Looking into it.
[Bug fortran/52789] gfortran sets -Wunused-parameter in the C sense as well as the Fortran sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52789 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-02 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-02 09:38:34 UTC --- Confirmed. * * * We have for GCC in general: Language Independent Options Warning Options -Wunused-parameter Warn whenever a function parameter is unused aside from its declaration. (It is automatically enabled with -Wunused or -Wall.) And gfortran specific: -Wunused-dummy-argument Warn about unused dummy arguments. This option is implied by -Wall. -Wunused-parameter Contrary to gcc's meaning of -Wunused-parameter, gfortran's implementation of this option does not warn about unused dummy arguments (see -Wunused-dummy-argument), but about unused PARAMETER values. -Wunused-parameter is not included in -Wall but is implied by -Wall -Wextra. * * * TODO: * -Wunused does not imply any of the Fortran -Wunused-* warnings. But it should! Interestingly, is does not even seem to enable the middle end warnings. * If only -Wunused-parameter is used - but no flag which implies -Wunused-dummy-argument, the parameter has to be eliminated for the middle-end handling. Thus, we need a gfc_option.* for it - and ensure that warn_unused_parameter has the proper value (e.g. 0 if only -Wunused-parameter is used.)
[Bug middle-end/52831] New: extract_bit_field_1: issue when str_rtx unsafe from target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52831 Bug #: 52831 Summary: extract_bit_field_1: issue when str_rtx unsafe from target Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: aurelien.buhrig@gmail.com This bug makes gcc.c-torture/execute/20040625-1.c fail on my private target port with gcc 4.6.3. Note that it also occurs on trunk during expand, but it seems to be masked by next passes. The issue occurs when: - str_rtx (op0) is not safe from target - when bitsize BITS_PER_WORD Example: WORD_MODE = HImode Pmode == ptr_mode == PSImode extract_bit_field_1 (str_rtx=0x2c15be28, bitsize=32, bitnum=0, unsignedp=1, packedp=1 '\001', target=0x2c16c880, mode=PSImode, tmode=PSImode, fallback_p=1 '\001') (gdb) call debug_rtx (str_rtx) (mem:BLK (reg/v/f:PSI 22 [ s ]) [2 *s_3(D)+0 S4 A8]) (gdb) call debug_rtx (target) (reg/v/f:PSI 22 [ s ]) Here is the expand log from trunk (see insns 19 and 20): ; s_4 = s_3(D)-next; (insn 10 9 11 (clobber (reg/v/f:PSI 22 [ s ])) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 11 10 12 (set (reg:QI 25) (mem:QI (plus:PSI (reg/v/f:PSI 22 [ s ]) (const_int 2 [0x2])) [0+2 S1 A8])) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 12 11 13 (set (reg:HI 24) (zero_extend:HI (reg:QI 25))) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 13 12 14 (set (reg:HI 26) (reg:HI 24)) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 14 13 15 (set (reg:HI 26) (unspec:HI [ (reg:HI 26) ] 11)) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 15 14 16 (set (strict_low_part (subreg:QI (reg:HI 26) 1)) (const_int 0 [0])) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 16 15 17 (set (reg:QI 28) (mem:QI (plus:PSI (reg/v/f:PSI 22 [ s ]) (const_int 3 [0x3])) [0+3 S1 A8])) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 17 16 18 (set (reg:HI 27) (zero_extend:HI (reg:QI 28))) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 18 17 19 (set (reg:HI 29) (ior:HI (reg:HI 27) (reg:HI 26))) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 19 18 20 (set (subreg:HI (reg/v/f:PSI 22 [ s ]) 2) (reg:HI 29)) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 20 19 21 (set (reg:QI 31) (mem:QI (reg/v/f:PSI 22 [ s ]) [0+0 S1 A8])) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 21 20 22 (set (reg:HI 30) (zero_extend:HI (reg:QI 31))) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) (insn 22 21 23 (set (reg:HI 32) (reg:HI 30)) /home/buhrig/work/sdk/gcc/trunk/src/gcc/testsuite/gcc.c-torture/execute/20040625-1.c:8 -1 (nil)) The provided patch solves the issue by using an intermediate reg, when needed, before extracting in word mode.
[Bug middle-end/52831] extract_bit_field_1: issue when str_rtx unsafe from target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52831 --- Comment #1 from Aurelien Buhrig aurelien.buhrig.gcc at gmail dot com 2012-04-02 09:42:28 UTC --- Created attachment 27062 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27062 Fix
[Bug c/52802] Equality rewrites pessimizes code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52802 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2012-04-02 09:43:03 UTC --- On x86, mov and jcc don't clobber the flags, so the first cmpl should compare with 8 not 7, the jbe should be adjusted to jb, and then the second cmpl is redundant as the flags from the first cmpl are still available.
[Bug fortran/52729] Symbol has no implicit type in SELECT TYPE block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52729 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-02 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-02 09:54:32 UTC --- That's an odd issue. The problem only occurs if one has a BLOCK (or the SELECT TYPE or ASSOCIATE constructs which use it internally). At the same time, one needs to have the function on the LHS of both a procedure call and a proc-pointer assignment. I think that one somewhere only looks as the namespace and its parent (ns-parent) instead of walking higher up. Reduced example: module testMod implicit none contains subroutine testSub() procedure(double precision ), pointer :: r double precision :: testVal block testVal=testFunc() r = testFunc end block end subroutine testSub double precision function testFunc() end function testFunc end module testMod
[Bug fortran/52832] New: ASSOCIATE construct with proc-pointer selector is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52832 Bug #: 52832 Summary: ASSOCIATE construct with proc-pointer selector is rejected Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Encountered when looking at PR 52729. I have not checked whether the following program is valid, but my feeling is that it is. Currently, gfortran rejects it with: associate (k=r) 1 Error: Expected association at (1) subroutine testSub() procedure(real), pointer :: r associate (k=r) end associate end subroutine testSub
[Bug c++/52833] New: -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833
Bug #: 52833
Summary: -O2 optimizes loop to infinite when loop invariant
based on arithmetic overflow
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gwpub...@wp.pl
Created attachment 27063
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27063
This loop compiles to endless when O2 in gcc 4.6.1
Hello,
following code is based on artihmetic overflow assumption (after overflow we
gen 0 number on x86 and x86_64):
$cat overflow_loop.cpp
int main(){
int s=1, i=0;
while (s0) {
++i;
s=2*s;
}
return i;
}
While it compiles fine when -O1 and -O2 , on -O3 compiles to infinite loop.
Let's generate assembly codes:
$ g++ -O1 -S -o overflow_loop-O1.s overflow_loop.cpp
$ g++ -O2 -S -o overflow_loop-O2.s overflow_loop.cpp
There is following difference between loops:
overflow_loop-O1.s
(...)
.L2:
addl$1, %eax
cmpl$31, %eax
jne.L2
(...)
overflow_loop-O2.s
(...)
.L2:
jmp.L2
(...)
Let's check what flags are enabled for O1 and O2
$ echo '$ gcc -c -Q -O2 --help=optimizers | grep enabled | sort '
optim_O2.txt
$ gcc -c -Q -O2 --help=optimizers | grep enabled | sort optim_O2.txt
$ echo '$ gcc -c -Q -O1 --help=optimizers | grep enabled | sort '
optim_O1.txt
$ gcc -c -Q -O1 --help=optimizers | grep enabled | sort optim_O1.txt
Here is the difference:
$ diff optim_O{1,2}.txt
1c1,5
$ gcc -c -Q -O1 --help=optimizers | grep enabled | sort
---
$ gcc -c -Q -O2 --help=optimizers | grep enabled | sort
-falign-functions [enabled]
-falign-jumps [enabled]
-falign-labels [enabled]
-falign-loops [enabled]
3a8
-fcaller-saves [enabled]
7a13,14
-fcrossjumping [enabled]
-fcse-follow-jumps [enabled]
10a18
-fdevirtualize [enabled]
12a21
-fexpensive-optimizations [enabled]
13a23
-fgcse [enabled]
18a29,30
-finline-small-functions[enabled]
-fipa-cp[enabled]
21a34
-fipa-sra [enabled]
27a41,43
-foptimize-register-move[enabled]
-foptimize-sibling-calls[enabled]
-fpeephole2 [enabled]
29a46
-fregmove [enabled]
30a48,50
-freorder-blocks[enabled]
-freorder-functions [enabled]
-frerun-cse-after-loop [enabled]
40a61
-fschedule-insns2 [enabled]
44a66,67
-fstrict-aliasing [enabled]
-fthread-jumps [enabled]
47a71
-ftree-builtin-call-dce [enabled]
62a87
-ftree-pre [enabled]
68a94
-ftree-switch-conversion[enabled]
70a97
-ftree-vrp [enabled]
Finally, detailed compiler version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.6-20110819/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --enable-gnu-unique-object
--enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto
--enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold
--disable-multilib --disable-libssp --disable-libstdcxx-pch
--enable-checking=release
Thread model: posix
gcc version 4.6.1 20110819 (prerelease) (GCC)
[Bug c++/52833] -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833 --- Comment #1 from Grzegorz Wierzowiecki gwpublic at wp dot pl 2012-04-02 10:09:15 UTC --- Created attachment 27064 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27064 overflow_loop-O1.s - Assembly after -O1
[Bug c++/52833] -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833 --- Comment #2 from Grzegorz Wierzowiecki gwpublic at wp dot pl 2012-04-02 10:09:48 UTC --- Created attachment 27065 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27065 overflow_loop-O2.s - assembly after -O2
[Bug c++/52833] -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833 --- Comment #3 from Grzegorz Wierzowiecki gwpublic at wp dot pl 2012-04-02 10:11:02 UTC --- Created attachment 27066 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27066 compiler flags enabled by -O1
[Bug c++/52833] -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833 --- Comment #4 from Grzegorz Wierzowiecki gwpublic at wp dot pl 2012-04-02 10:11:32 UTC --- Created attachment 27067 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27067 compiler flags enabled by -O2
[Bug c++/52833] -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-02 10:12:34 UTC --- (In reply to comment #0) following code is based on artihmetic overflow assumption (after overflow we gen 0 number on x86 and x86_64): Bad assumption, overflow is undefined behaviour. The bug submission form asys to read http://gcc.gnu.org/bugs/ before reporting bugs, which says if your code works as you expect with -fwrapv then it's not a bug in the compiler, it's a bug in your code.
[Bug c++/52833] -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833 Grzegorz Wierzowiecki gwpublic at wp dot pl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Grzegorz Wierzowiecki gwpublic at wp dot pl 2012-04-02 10:16:31 UTC --- Thanks for confirmation, I wanted to ensure it works as expected.
[Bug target/52802] Equality rewrites pessimizes code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52802 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Status|WAITING |NEW Component|c |target --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 10:28:58 UTC --- Confirmed. On the tree level we canonicalize things which is good, if you change the source to what the canonicalization looks like you get the same problem. Target issue.
[Bug fortran/52832] ASSOCIATE construct with proc-pointer selector is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52832 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-02 10:30:43 UTC --- From Fortran 2008: R804 association is associate-name = selector R805 selector is expr or variable R602 variable is designator or expr R601 designator is object-name and expr boils down to: R701 primary is constant or designator ! See above or ... Thus, it boils down to the question whether that's fulfilled for a procedure pointer. Note that there such entries, which make me inclined that it is not valid: R554 saved-entity is object-name or proc-pointer-name R639 pointer-object is variable-name [or ...] or proc-pointer-name Possible usage of proc-pointer selectors: associate(f = very%long%name%procptr) f = something ! usage as variable a = f(4) + f(7) * f(x) + ... ! usage as expr where the latter is more useful. A quick test shows that ifort, pgf95 and crayftn accept proc-pointers in ASSOCIATE.
[Bug middle-end/52800] [4.8 Regression] eglibc build broken with internal compiler error in cfgloop .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52800 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-02 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Summary|eglibc build broken with|[4.8 Regression] eglibc |internal compiler error in |build broken with internal |cfgloop . |compiler error in cfgloop . Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 10:34:03 UTC --- Fixed by Index: gcc/cprop.c === --- gcc/cprop.c (revision 186066) +++ gcc/cprop.c (working copy) @@ -1916,7 +1916,7 @@ execute_rtl_cprop (void) changed = one_cprop_pass (); flag_rerun_cse_after_global_opts |= changed; if (changed) -cleanup_cfg (0); +cleanup_cfg (CLEANUP_CFG_CHANGED); return 0; }
[Bug bootstrap/52808] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52808 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Depends on||52756 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 10:39:39 UTC --- The fix for this depends on fixing PR52756. The issue here is -ftracer.
[Bug c++/52833] -O2 optimizes loop to infinite when loop invariant based on arithmetic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52833 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug middle-end/52756] [4.8 Regression] 255.vortex in SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52756
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02
11:38:59 UTC ---
It doesn't work, as we expect loop_latch_edge () to work during further
threading.
It also does not work because we miss some threadings and thus hit the assert
that e-aux is NULL after threading is done.
The issue is that we thread both the latch and the loop entry edge. But the
code special casing each case does not consider that both may happen at
the same time. If we'd re-start at thread_through_loop_header for the case
in this bug we'd fail, as the entry edges THREAD_TARGET2 is set.
Thus, I'll try again with
Index: gcc/tree-ssa-threadupdate.c
===
--- gcc/tree-ssa-threadupdate.c (revision 186066)
+++ gcc/tree-ssa-threadupdate.c (working copy)
@@ -838,6 +838,7 @@ thread_through_loop_header (struct loop
edge_iterator ei;
basic_block tgt_bb, atgt_bb;
enum bb_dom_status domst;
+ bool threaded_latch = false;
/* We have already threaded through headers to exits, so all the threading
requests now are to the inside of the loop. We need to avoid creating
@@ -908,6 +909,7 @@ thread_through_loop_header (struct loop
if (single_succ_p (header))
goto fail;
+thread_rest:
if (latch-aux)
{
if (THREAD_TARGET2 (latch))
@@ -916,7 +918,7 @@ thread_through_loop_header (struct loop
tgt_bb = tgt_edge-dest;
}
else if (!may_peel_loop_headers
- !redirection_block_p (loop-header))
+ !redirection_block_p (header))
goto fail;
else
{
@@ -950,7 +952,7 @@ thread_through_loop_header (struct loop
if (!tgt_bb)
{
/* There are no threading requests. */
- return false;
+ return threaded_latch;
}
/* Redirecting to empty loop latch is useless. */
@@ -971,7 +973,7 @@ thread_through_loop_header (struct loop
loop-header = NULL;
loop-latch = NULL;
loops_state_set (LOOPS_NEED_FIXUP);
- return thread_block (header, false);
+ return threaded_latch | thread_block (header, false);
}
if (tgt_bb-loop_father-header == tgt_bb)
@@ -994,9 +996,10 @@ thread_through_loop_header (struct loop
loop-latch = thread_single_edge (latch);
gcc_assert (single_succ (loop-latch) == tgt_bb);
loop-header = tgt_bb;
+ threaded_latch = true;
/* Thread the remaining edges through the former header. */
- thread_block (header, false);
+ goto thread_rest;
}
else
{
@@ -1039,7 +1042,7 @@ fail:
free (e-aux);
e-aux = NULL;
}
- return false;
+ return threaded_latch;
}
/* Walk through the registered jump threads and convert them into a
[Bug rtl-optimization/52803] [4.8 Regression] ICE: in ira, at ira.c:3616 with -fno-move-loop-invariants on almost any code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52803 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 11:59:51 UTC --- Author: rguenth Date: Mon Apr 2 11:59:47 2012 New Revision: 186080 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186080 Log: 2012-04-02 Richard Guenther rguent...@suse.de PR middle-end/52803 * loop-init.c (gate_handle_loop2): Destroy loops here if we don't enter RTL loop optimizers. * gcc.dg/pr52803.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr52803.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-init.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/52800] [4.8 Regression] eglibc build broken with internal compiler error in cfgloop .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52800 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 12:00:39 UTC --- Fixed.
[Bug rtl-optimization/52803] [4.8 Regression] ICE: in ira, at ira.c:3616 with -fno-move-loop-invariants on almost any code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52803 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 11:59:59 UTC --- Fixed.
[Bug middle-end/52800] [4.8 Regression] eglibc build broken with internal compiler error in cfgloop .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52800 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 12:00:34 UTC --- Author: rguenth Date: Mon Apr 2 12:00:30 2012 New Revision: 186081 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186081 Log: 2012-04-02 Richard Guenther rguent...@suse.de PR rtl-optimization/52800 * cprop.c (execute_rtl_cprop): Call cleanup_cfg with CLEANUP_CFG_CHANGED. Modified: trunk/gcc/ChangeLog trunk/gcc/cprop.c
[Bug regression/52834] New: [4.7 Regression] ICE (segfault) in check_tag_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52834 Bug #: 52834 Summary: [4.7 Regression] ICE (segfault) in check_tag_decl Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org Created attachment 27068 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27068 preprocessed source seen with the 4.7.0 release (x86_64-linux-gnu), works with 4.6.3 $ g++ -c -g ProcessDies.ii In file included from /usr/include/libsysactivity/global.h:56:0, from /usr/include/libsysactivity/libsysactivity.h:122, from /home/packages/tmp/sentinella-0.9.0/src/Conditions/ProcessDies.h:24, from /home/packages/tmp/sentinella-0.9.0/src/Conditions/ProcessDies.cpp:21: /usr/include/libsysactivity/process.h:40:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Program received signal SIGSEGV, Segmentation fault. 0x004fed50 in check_tag_decl(cp_decl_specifier_seq*) () (gdb) bt #0 0x004fed50 in check_tag_decl(cp_decl_specifier_seq*) () #1 0x0050f0e6 in shadow_tag(cp_decl_specifier_seq*) () #2 0x0056bfdd in ?? () #3 0x00571238 in ?? () #4 0x0057547c in ?? () #5 0x00574118 in ?? () #6 0x00574458 in ?? () #7 0x005754f8 in ?? () #8 0x00574118 in ?? () #9 0x005759e3 in c_parse_file() () #10 0x00605c05 in c_common_parse_file() () #11 0x0086fae0 in toplev_main(int, char**) () #12 0x75ddcead in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #13 0x004e8181 in _start ()
[Bug regression/52834] [4.7 Regression] ICE (segfault) in check_tag_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52834
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-04-02 13:47:30 UTC ---
Testcase:
__attribute__ ((visibility(default))) enum foo{
bar = 0 };
% gcc -c test.ii
test.ii:2:11: internal compiler error: Segmentation fault
Please submit a full bug report,
[Bug middle-end/52756] [4.8 Regression] 255.vortex in SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52756
--- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02
14:05:31 UTC ---
With that patch gcc.dg/tree-ssa/ssa-dom-thread-2.c regresses as we do not
perform the threading through the header edge anymore. Note that using
thread_block (header, true); for the rest of the header edges does not
work either, as it still happily creates the multiple entry loop with
the bogus header.
The following is another possibility - remove the remaining threadings
that would be harmful but allow those that would be safe.
Index: gcc/tree-ssa-threadupdate.c
===
--- gcc/tree-ssa-threadupdate.c (revision 186082)
+++ gcc/tree-ssa-threadupdate.c (working copy)
@@ -826,6 +826,17 @@ determine_bb_domination_status (struct l
return (bb_reachable ? DOMST_DOMINATING : DOMST_LOOP_BROKEN);
}
+/* Return true if BB is part of the new pre-header that is created
+ when threading the latch to DATA. */
+
+static bool
+def_split_header_continue_p (const_basic_block bb, const void *data)
+{
+ const_basic_block new_header = (const_basic_block) data;
+ return (bb-loop_father == new_header-loop_father
+ bb != new_header);
+}
+
/* Thread jumps through the header of LOOP. Returns true if cfg changes.
If MAY_PEEL_LOOP_HEADERS is false, we avoid threading from entry edges
to the inside of the loop. */
@@ -990,11 +1001,46 @@ thread_through_loop_header (struct loop
if (latch-aux)
{
+ basic_block *bblocks;
+ unsigned nblocks, i;
+
/* First handle the case latch edge is redirected. */
loop-latch = thread_single_edge (latch);
gcc_assert (single_succ (loop-latch) == tgt_bb);
loop-header = tgt_bb;
+ /* Remove the new pre-header blocks from our loop. */
+ bblocks = XCNEWVEC (basic_block, loop-num_nodes);
+ nblocks = dfs_enumerate_from (header, 0, def_split_header_continue_p,
+ bblocks, loop-num_nodes, tgt_bb);
+ for (i = 0; i nblocks; i++)
+ {
+ remove_bb_from_loops (bblocks[i]);
+ add_bb_to_loop (bblocks[i], loop_outer (loop));
+ }
+ free (bblocks);
+
+ /* Cancel remaining threading requests that would make the
+loop a multiple entry loop. */
+ FOR_EACH_EDGE (e, ei, header-preds)
+ {
+ edge e2;
+ if (e-aux == NULL)
+ continue;
+
+ if (THREAD_TARGET2 (e))
+ e2 = THREAD_TARGET2 (e);
+ else
+ e2 = THREAD_TARGET (e);
+
+ if (e-src-loop_father != e2-dest-loop_father
+ e2-dest != loop-header)
+ {
+ free (e-aux);
+ e-aux = NULL;
+ }
+ }
+
/* Thread the remaining edges through the former header. */
thread_block (header, false);
}
[Bug middle-end/52756] [4.8 Regression] 255.vortex in SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52756 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-02 15:13:50 UTC --- Author: rguenth Date: Mon Apr 2 15:13:45 2012 New Revision: 186085 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186085 Log: 2012-04-02 Richard Guenther rguent...@suse.de PR tree-optimization/52756 * tree-ssa-threadupdate.c (def_split_header_continue_p): New function. (thread_through_loop_header): After threading through the loop latch remove the split part from the loop and clear further threading opportunities that would create a multiple entry loop. * gcc.dg/torture/pr52756.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr52756.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadupdate.c
[Bug fortran/52835] New: Incorrect code generated by gfortran 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 Bug #: 52835 Summary: Incorrect code generated by gfortran 4.7.0 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arnau...@users.sourceforge.net uname -sm Linux x86_64 cat qq.f SUBROUTINE QQ2( ISU, ZSPM, RSV, MS ) INTEGER :: ISU(MS) CHARACTER(8) :: ZSPM(MS) REAL :: RSV(MS) DO IS=1,MS ISU(IS)=0 ZSPM(IS)=' ' RSV(IS) =0.0 ENDDO END subroutine qq2 SUBROUTINE QQ() INTEGER, ALLOCATABLE :: ISU(:) CHARACTER(8), ALLOCATABLE :: ZSPM(:) REAL, ALLOCATABLE :: RSV(:) ALLOCATE( RSV(3) ) ALLOCATE( ISU(3) ) ALLOCATE( ZSPM(3) ) CALL QQ2( ISU, ZSPM, RSV, 3 ) write(*,*) '--',zspm(1) END subroutine qq program p1 call qq() end program p1 gfortran470 -O3 -g qq.f -static-libgfortran ; valgrind --track-origins=yes ./a.out ==18017== Memcheck, a memory error detector ==18017== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==18017== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==18017== Command: ./a.out ==18017== ==18017== Syscall param write(buf) points to uninitialised byte(s) ==18017==at 0x3541CC4150: __write_nocancel (in /lib64/libc-2.5.so) ==18017==by 0x40981C: raw_write (unix.c:308) ==18017==by 0x40F4FE: _gfortrani_fbuf_flush (unix.h:56) ==18017==by 0x405416: _gfortrani_next_record (transfer.c:3397) ==18017==by 0x405CF8: _gfortran_st_write_done (transfer.c:3592) ==18017==by 0x401C5B: qq_ (qq.f:22) ==18017==by 0x401CFC: main (qq.f:26) ==18017== Address 0x4c2fb44 is 4 bytes inside a block of size 512 alloc'd ==18017==at 0x4A0776F: malloc (vg_replace_malloc.c:263) ==18017==by 0x4037B8: _gfortrani_get_mem (memory.c:43) ==18017==by 0x40F38A: _gfortrani_fbuf_init (fbuf.c:43) ==18017==by 0x408F89: _gfortrani_init_units (unit.c:585) ==18017==by 0x403747: init (main.c:226) ==18017==by 0x4196F5: ??? (in /tmp/arnaud/a.out) ==18017==by 0x401612: ??? (in /tmp/arnaud/a.out) ==18017==by 0x9CA212C: ??? ==18017==by 0x419676: __libc_csu_init (in /tmp/arnaud/a.out) ==18017==by 0x3541C1D84D: (below main) (in /lib64/libc-2.5.so) ==18017== Uninitialised value was created by a heap allocation ==18017==at 0x4A0776F: malloc (vg_replace_malloc.c:263) ==18017==by 0x401BE0: qq_ (qq.f:20) ==18017==by 0x401CFC: main (qq.f:26) ==18017== -- ==18017== ==18017== HEAP SUMMARY: ==18017== in use at exit: 0 bytes in 0 blocks ==18017== total heap usage: 20 allocs, 20 frees, 3,878 bytes allocated ==18017== ==18017== All heap blocks were freed -- no leaks are possible ==18017== ==18017== For counts of detected and suppressed errors, rerun with: -v ==18017== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4) The test case above demonstrates the problem observed on a large production system. In qq2, zspm is not set properly to as shown by valgrind. This is taking place only when compiled with -O3. This is a regression with respect to gfortran 4.6.2.
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #32 from Jason Merrill jason at gcc dot gnu.org 2012-04-02 15:57:16 UTC --- (In reply to comment #31) Well, that is reassuring. Then, will we still pretty-print expressions in diagnostics once we have the caret? No, there should be no need to. Is there a GCC way to detect that the output is a terminal? I don't know if there's a usual GCC way, but isatty seems like a good way.
[Bug middle-end/52835] [4.7/4.8 Regression] -O3 wrongly optimizes loop __builtin_memcpy away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2012-04-02 Component|fortran |middle-end CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 Summary|Incorrect code generated by |[4.7/4.8 Regression] -O3 |gfortran 4.7.0 |wrongly optimizes loop ||__builtin_memcpy away Target Milestone|--- |4.7.1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-02 16:11:37 UTC --- Confirmed - and smells rather like a middle-end issue. (Or a rather convoluted FE declaration bug.) Works with my 2011-12-24-r182676 build Fails with my 2012-02-28-r184613 build (Note: Those contained some patches, which shouldn't™ affect the result.) * * * Works with: gfortran -fdump-tree-optimized -funswitch-loops -fpredictive-commoning -fgcse-after-reload -ftree-vectorize -finline-functions -fipa-cp-clone -O2 (And fails with -O3 and the -fno-* version of those flags.) Thus, none of the specific flags which get enabled with -O3 seems too blame. * * * Looking at the optimized dump, the loop DO IS=1,MS ISU(IS)=0 ZSPM(IS)=' ' RSV(IS) =0.0 ENDDO gets replaced by: __builtin_memset (D.1976_27, 0, 12); __builtin_memset (D.1956_11, 0, 12); That's almost fine, however, the ZSPM(is) = ' ' is lacking. With -O2 one finds in the loop: __builtin_memcpy (D.2078_113, [0], 8); Note that ZSPM is an array of size 3 of character strings of length 8: character(len=8) :: ZSPM(MS) where MS is 3. The best (optimized) version would be something like memset(ZSPM, , 3*8);. In 4.6, one had (with -O3) and expanded loop with the following for [0], [1] and [2]: D.1697_89 = MEM[(character(kind=1)[0:D.1598][1:8] *)D.1577_23][0]; __builtin_memcpy (D.1697_89, [0], 8);
[Bug middle-end/52835] [4.7/4.8 Regression] -O3 wrongly optimizes loop __builtin_memcpy away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-04-02 16:18:47 UTC --- r183622 is OK r183649 miscompiles the code.
[Bug java/52805] [4.8 Regression] 243 new GCC HEAD@185977 regressions (libjava failures)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52805 --- Comment #5 from Iain Sandoe iains at gcc dot gnu.org 2012-04-02 16:29:25 UTC --- Rainer's commit (http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00031.html) fixes this for i686-darwin9.
[Bug fortran/52774] Derived-type assignment: check required to prevent double deallocation of allocatable component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52774 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2012-04-02 CC||burnus at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever Confirmed|0 |1 Summary|A check is needed to|Derived-type assignment: |prevent deallocation in |check required to prevent |realloc-lhs |double deallocation of ||allocatable component Known to fail||4.3.4, 4.7.1, 4.8.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-02 16:36:17 UTC --- Confirmed. Remarks: a) The reduced program in comment 0 is invalid: As p1%p is not allocated, accessing it with print *, p1%p is invalid - and is likely to segfault. Solution: Use print *, allocated (p1%p) which shall print F; that still gives the expected segfault or invalid free() errors from valgrind with current gfortran - as expected. b) The issue is unrelated to realloc on assignment and seems to be related to allocatable components (TR 15581, a GCC 4.2 feature). At least the program in comment 0 [modified as in comment (a)] also fails with GCC 4.3, using -fno-realloc-lhs does not help, and valgrind shows the same failure.
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 --- Comment #7 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-02 16:41:41 UTC --- Sounds good. Will send the patches to the list, probably tomorrow. Thanks!
[Bug regression/52834] [4.7 Regression] ICE (segfault) in check_tag_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52834 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-04-02 16:45:42 UTC --- Dup of PR52671 ?
[Bug java/52805] [4.8 Regression] 243 new GCC HEAD@185977 regressions (libjava failures)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52805 --- Comment #6 from Iain Sandoe iains at gcc dot gnu.org 2012-04-02 17:13:14 UTC --- (In reply to comment #2) e.g. AFAICT, although darwin defines JCR_SECTION_NAME, there is no crt machinery to deal with it [darwin has it's own crt code] JFTR (in case anyone else has gone looking for it), there's no entry in the Darwin system-provided crts for this, and we don't supply an FSF one for it either - instead, it appears that the class init code is provided in libgcj.dylib (from libjava/darwin.cc).
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #33 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-02 17:15:47 UTC --- (In reply to comment #32) (In reply to comment #31) Well, that is reassuring. Then, will we still pretty-print expressions in diagnostics once we have the caret? No, there should be no need to. As a first minimal step, would a first patch be enough that simply: * Adds an option to disable/enable the caret? By default on if(isatty), otherwise off. * Implements the caret by reopening the file, looks for the appropriate line, and prints this line, then prints a '^' below it using the column info. Of course this may fail in some cases, like non-ANSI input, and not preprocessing, but it will work in 99% of the cases. In any case, it is not clear to me that we want to print the preprocessed line instead of the original text.
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #34 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-02 17:18:34 UTC --- (In reply to comment #32) Of course this may fail in some cases, like non-ANSI input, and not preprocessing, but it will work in 99% of the cases. In any case, it is not clear to me that we want to print the preprocessed line instead of the original text. BTW, non-ANSI input may not even handled correctly by libcpp according to PR49152, so I think we don't need to worry about it just now.
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #35 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-02 17:19:15 UTC --- (In reply to comment #34) (In reply to comment #32) Of course this may fail in some cases, like non-ANSI input, and not preprocessing, but it will work in 99% of the cases. In any case, it is not clear to me that we want to print the preprocessed line instead of the original text. BTW, non-ANSI input may not even handled correctly by libcpp according to PR49152, so I think we don't need to worry about it just now. Sorry, I meant PR49973 .
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #36 from pinskia at gmail dot com pinskia at gmail dot com 2012-04-02 17:35:59 UTC --- I know some of us use tee and that disables termainal detection code usually. Or output to a file and then use tail -f. So please don't do that. It would confuse lots of users. Sent from my Palm Pre on ATamp;T On Apr 2, 2012 4:17, manu at gcc dot gnu.org lt;gcc-bugzi...@gcc.gnu.orggt; wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #31 from Manuel López-Ibáñez lt;manu at gcc dot gnu.orggt; 2012-04-02 08:16:52 UTC --- (In reply to comment #30) gt; (In reply to comment #26) gt; gt; The caret is not a solution to this problem, because what Gabriel wants is to gt; gt; not reconstruct expressions ONLY when the caret is shown, but he has said in gt; gt; the past that the caret should default to OFF to not change the current output gt; gt; for IDEs and other software parsing the output of gcc like emacs, so we are gt; gt; back to printing the monsters mentioned above by default. gt; gt; I think I've said before that caret should default to on when the output is a gt; terminal. gt; Well, that is reassuring. Then, will we still pretty-print expressions in diagnostics once we have the caret? Is there a GCC way to detect that the output is a terminal?
[Bug middle-end/52835] [4.7/4.8 Regression] -O3 wrongly optimizes loop __builtin_memcpy away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 --- Comment #3 from Arnaud Desitter arnaud02 at users dot sourceforge.net 2012-04-02 17:54:06 UTC --- Additionally: cat xxx.f SUBROUTINE XXX(RES,ALP,REN,NN ) DIMENSION ALP(NN),REN (NN),RES (NN) DO IP = 1,NN REN(IP) = 0.0 ALP(IP) = 0.0 CALL YYY(ALP(IP),REN(IP),RES(IP)) ENDDO END gfortran470 -c -O3 -o xxx_O3.o xxx.f ; gfortran470 -c -O2 -o xxx_O2.o xxx.f ; nm xxx*.o xxx_O2.o: T xxx_ U yyy_ xxx_O3.o: U memset T xxx_ When compiled with -O3, the call to YYY is not generated. This is a pretty serious wrong code generation.
[Bug regression/52834] [4.7 Regression] ICE (segfault) in check_tag_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52834 --- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-04-02 18:31:21 UTC --- (In reply to comment #2) Dup of PR52671 ? Yes. Gcc-4.8 from today is fine. Gcc-4.7 release fails. Haven't tried the gcc-4.7 branch, but it seems obvious.
[Bug libffi/52497] libffi doesn't build on powerpc64-linux after latest upstream merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52497 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-02 AssignedTo|unassigned at gcc dot |bergner at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug libffi/52497] libffi doesn't build on powerpc64-linux after latest upstream merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52497 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Peter Bergner bergner at gcc dot gnu.org 2012-04-02 18:50:22 UTC --- Patch committed to gcc sources as revision 186091. AG will merge these changes back to upstream libffi.
[Bug middle-end/52835] [4.7/4.8 Regression] -O3 wrongly optimizes loop __builtin_memcpy away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-04-02 19:18:22 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=183624 and it is ldist that incorrectly removes the call.
[Bug middle-end/52835] [4.7/4.8 Regression] -O3 wrongly optimizes loop __builtin_memcpy away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-04-02 19:38:31 UTC --- Created attachment 27069 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27069 gcc48-pr52835.patch Untested fix. Ignoring failures from compute_*loop can't be right.
[Bug fortran/52724] Internal read with character(kind=4) data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52724 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-02 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-02 20:01:08 UTC --- (In reply to comment #2) I am curious about what this line is doing: character buffer4(100) buffer4 = 4_'123' Well, that line does what it should do: It assign the value '123' - trimmed to one character (namely '1') to the array buffer4. The array4 then contains 100 times the value '1'. (In reply to comment #0) read(buffer4,*) i print *,i end ig25@linux-fd1f:~/Krempel/Opt gfortran foo.f90 ig25@linux-fd1f:~/Krempel/Opt ./a.out 1 And seemingly that's also what Thomas gets. * * * (In reply to comment #2) buffer4 is a kind=1 variable. have you tried: character(kind=4) buffer4(100) ? Well, with len=1,kind=4 or with len=2,kind=2 one gets, respectively, 1 and 12 - which is the expected result. However, the following fails: character(len=2,kind=4) buffer4(100) integer i buffer4 = 4_'123' read(buffer4,*) i print *,i end Fortran runtime error: Bad integer for item 1 in list input Printing the value of the array as print *, buffer4, one gets the expected 121212 as output. And reading the line as read(buffer4,'(i5)') i works and yields 12. Only when replacing the formatted read by a list-directed read, it fails.
[Bug target/52836] New: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52836 Bug #: 52836 Summary: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13084 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mead...@codesourcery.com Target: arm From r185746 trunk: $ ./install/bin/arm-none-linux-gnueabi-gcc -O2 -funroll-loops -march=armv7-a arm-minipool-ice.c /home/meadori/etc/bugs/arm-minipool-ice.c: In function 'Super_Mix': /home/meadori/etc/bugs/arm-minipool-ice.c:144:3: warning: incompatible implicit declaration of built-in function 'memset' [enabled by default] /home/meadori/etc/bugs/arm-minipool-ice.c: In function 'Next_Fugue': /home/meadori/etc/bugs/arm-minipool-ice.c:175:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13084 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/52836] internal compiler error: in push_minipool_fix, at config/arm/arm.c:13084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52836 --- Comment #1 from Meador Inge meadori at codesourcery dot com 2012-04-02 20:54:30 UTC --- Created attachment 27070 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27070 Reproduction case
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #37 from Jason Merrill jason at gcc dot gnu.org 2012-04-02 22:05:13 UTC --- (In reply to comment #36) I know some of us use tee and that disables termainal detection code usually. Right, so then you don't get the caret by default. You can still enable it with a flag if you want. Actually, it's not clear to me that the caret line would be likely to cause trouble for IDEs in any case; they already have to deal with output that isn't a specific error. Maybe we should just turn it on by default in all cases, and possibly backtrack to only on a tty if it causes problems.
[Bug c++/52837] New: ICE in cp/mangle.c:3306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52837 Bug #: 52837 Summary: ICE in cp/mangle.c:3306 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@godbolt.org GCC version: 4.7.0 (custom build) System type: Ubuntu 11.10 3.0.0-16-generic $ /site/apps/gcc-4.7.0-drw.2/bin/gcc -v Using built-in specs. COLLECT_GCC=/site/apps/gcc-4.7.0-drw.2/bin/gcc COLLECT_LTO_WRAPPER=/site/apps/gcc-4.7.0-drw.2/libexec/gcc/x86_64-linux-gnu/4.7.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ./configure --prefix /site/apps/gcc-4.7.0-drw.2 --build=x86_64-linux-gnu --enable-clocale=gnu --enable-gold --enable-languages=c,c++ --enable-ld=default --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugin --enable-shared --enable-threads=posix --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-pkgversion=DRW-internal-build --with-plugin-ld=ld.gold --with-system-zlib --with-gmp=/home/prodappadmin/fig-packages/scratch/gcc/4.7.0/build/gmp-5.0.2 --with-mpfr=/home/prodappadmin/fig-packages/scratch/gcc/4.7.0/build/mpfr-3.1.0 --with-mpc=/home/prodappadmin/fig-packages/scratch/gcc/4.7.0/build/mpc-0.9 --with-libelf=/home/prodappadmin/fig-packages/scratch/gcc/4.7.0/build/libelf-0.8.9 Thread model: posix gcc version 4.7.0 (DRW-internal-build) command-line: /site/apps/gcc-4.7.0-drw.2/bin/gcc -MD -g3 -Wall -fPIC -DXP_UNIX -DIN_GCC -DPLUGIN_NO_POISON -DHAVE_CONFIG_H -I/site/apps/gcc-4.7.0-drw.2/lib/gcc/x86_64-linux-gnu/4.7.0/plugin/include -I/home/mgodbolt/build/objs-js/dist/include -I/home/mgodbolt/build/objs-js/dist/lib -I//home/mgodbolt/local/include/js/ -O2 -x c++ -c util.c compiler output: In file included from /home/mgodbolt/build/objs-js/dist/include/jsval.h:48:0, from /home/mgodbolt/build/objs-js/dist/include/jspubtd.h:47, from /home/mgodbolt/build/objs-js/dist/include/jsapi.h:49, from gcc_compat.h:31, from util.c:21: /home/mgodbolt/build/objs-js/dist/include/jsutil.h:642:58: internal compiler error: in mangle_decl_string, at cp/mangle.c:3306 When compiling the attached file we get an ICE in cp/mangle.c line 3306 (commented We shouldn't be trying to mangle an uninstantiated template.). I have been unable to winnow down a more confined example of this error as I am very unfamiliar with the code being built (it's an old version of the mozilla JS runtime). The error can be reproduced with the attached preprocessed file using simply cc1plus util.ii
[Bug c++/52837] ICE in cp/mangle.c:3306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52837 --- Comment #1 from Matt Godbolt matt at godbolt dot org 2012-04-02 22:17:15 UTC --- Created attachment 27071 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27071 This is the .ii file that reproduces the problem. (gzipped to get past upload limitations) (attempt at attaching .ii file, first attempt failed).
[Bug c++/52837] ICE in cp/mangle.c:3306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52837 --- Comment #2 from Matt Godbolt matt at godbolt dot org 2012-04-02 22:51:14 UTC --- After a little more research, I've managed to get a 4-line reproduction case. (See attached). I also confirmed this code compiles without error on GCC4.5 and GCC4.6.
[Bug c++/52837] ICE in cp/mangle.c:3306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52837 --- Comment #3 from Matt Godbolt matt at godbolt dot org 2012-04-02 22:52:26 UTC --- Created attachment 27072 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27072 Minimal reproducible test case $ /site/apps/gcc-4.7.0-drw.2/bin/gcc -c gcc-4.7-ice-demangle.cc gcc-4.7-ice-demangle.cc:6:58: internal compiler error: in mangle_decl_string, at cp/mangle.c:3306
[Bug target/52838] New: [x32] missed optimization for pointer return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52838
Bug #: 52838
Summary: [x32] missed optimization for pointer return value
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bartolde...@users.sourceforge.net
The program test.c:
extern void *foo(void);
extern void bar(void*);
void test(void)
{
bar(foo());
}
when compiled with
gcc-4.7 -mx32 -Os -S test.c
produces:
.filetest.c
.text
.globltest
.typetest, @function
test:
.LFB0:
.cfi_startproc
pushq%rax
.cfi_def_cfa_offset 16
callfoo
popq%rdx
.cfi_def_cfa_offset 8
movq%rax, %rdi
jmpbar
.cfi_endproc
.LFE0:
.sizetest, .-test
.identGCC: (Debian 4.7.0-1) 4.7.0
.section.note.GNU-stack,,@progbits
Here movq %rax, %rdi could be replaced by movl %eax, %edi, saving one
prefix byte 0x48.
[Bug java/52815] class.c:2815:53: error: 'JCR_SECTION_NAME' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52815 --- Comment #2 from dave.anglin at bell dot net 2012-04-03 01:05:02 UTC --- Fix is obvious but should GCC be smart enough to ignore code code after gcc_unreachable? -- John David Anglindave.ang...@bell.net
[Bug libstdc++/52839] New: double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 Bug #: 52839 Summary: double free or corruption running tr1/.../default_weaktoshared.exe Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: amo...@gmail.com Occasionally seen with r185830 when running libstdc++ testsuite on power7. Quickly reproducible using a few copies of while LD_LIBRARY_PATH=necessary_paths ./default_weaktoshared.exe; do true done *** glibc detected *** ./default_weaktoshared.exe: double free or corruption (fasttop): 0x100222e8 *** === Backtrace: = /lib/power7/libc.so.6(+0x833b8)[0xfc333b8] /lib/power7/libc.so.6(cfree+0x94)[0xfc38b24] /home/amodra/build/gcc-virgin/powerpc-linux/./libstdc++-v3/src/.libs/libstdc++.so.6(_ZdlPv+0x2c)[0xff12b7c] ./default_weaktoshared.exe[0x1eb8] /lib/power7/libpthread.so.0(+0x749c)[0xfd6749c] /lib/power7/libc.so.6(clone+0x84)[0xfca2160] === Memory map: 0010-0012 r-xp 00:00 0 [vdso] 0fbb-0fd4 r-xp fd:00 20234319 /lib/power7/libc-2.11.1.so 0fd4-0fd5 rw-p 0018 fd:00 20234319 /lib/power7/libc-2.11.1.so 0fd6-0fd8 r-xp fd:00 20234324 /lib/power7/libpthread-2.11.1.so 0fd8-0fd9 rw-p 0001 fd:00 20234324 /lib/power7/libpthread-2.11.1.so 0fda-0fdc r-xp fd:00 24224298 /home/amodra/build/gcc-virgin/gcc/libgcc_s.so.1 0fdc-0fdd rw-p 0001 fd:00 24224298 /home/amodra/build/gcc-virgin/gcc/libgcc_s.so.1 0fde-0fe9 r-xp fd:00 20234322 /lib/power7/libm-2.11.1.so 0fe9-0fea r--p 000a fd:00 20234322 /lib/power7/libm-2.11.1.so 0fea-0feb rw-p 000b fd:00 20234322 /lib/power7/libm-2.11.1.so 0fec-0ffd r-xp fd:00 34160649 /home/amodra/build/gcc-virgin/powerpc-linux/libstdc++-v3/src/.libs/libstdc++.so.6.0.17 0ffd-0ffe r--p 0010 fd:00 34160649 /home/amodra/build/gcc-virgin/powerpc-linux/libstdc++-v3/src/.libs/libstdc++.so.6.0.17 0ffe-0fff rw-p 0011 fd:00 34160649 /home/amodra/build/gcc-virgin/powerpc-linux/libstdc++-v3/src/.libs/libstdc++.so.6.0.17 1000-1001 r-xp fd:00 14912951 /home/amodra/build/gcc-virgin/powerpc-linux/libstdc++-v3/testsuite/default_weaktoshared.exe 1001-1002 rw-p fd:00 14912951 /home/amodra/build/gcc-virgin/powerpc-linux/libstdc++-v3/testsuite/default_weaktoshared.exe 1002-1005 rwxp 00:00 0 [heap] f22e-f22f ---p 00:00 0 f22f-f2b4 rw-p 00:00 0 f2b4-f2b5 ---p 00:00 0 f2b5-f33a rw-p 00:00 0 f33a-f33b ---p 00:00 0 f33b-f3c0 rw-p 00:00 0 f3c0-f3c3 rw-p 00:00 0 f3c3-f3d0 ---p 00:00 0 f3d5-f3d6 ---p 00:00 0 f3d6-f45b rw-p 00:00 0 f45b-f45c ---p 00:00 0 f45c-f4e1 rw-p 00:00 0 f4e1-f4e2 ---p 00:00 0 f4e2-f567 rw-p 00:00 0 f567-f568 ---p 00:00 0 f568-f5ed rw-p 00:00 0 f5ed-f5ee ---p 00:00 0 f5ee-f673 rw-p 00:00 0 f673-f674 ---p 00:00 0 f674-f6f9 rw-p 00:00 0 f6f9-f6fa ---p 00:00 0 f6fa-f77f rw-p 00:00 0 f77f-f782 r-xp fd:00 7757916 /lib/ld-2.11.1.so f782-f783 rw-p 0002 fd:00 7757916 /lib/ld-2.11.1.so ffd1-ffe6 rw-p 00:00 0 [stack] /bin/bash: line 2: 4173 Aborted (core dumped)
[Bug target/52828] powerpc -m32 -Os writes register saves below stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52828 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-03 AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org | Ever Confirmed|0 |1
[Bug ada/52752] GNAT bug box on instantiation of subprogram with not null-qualified named access type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52752 denkpadje at gmail dot com changed: What|Removed |Added CC||denkpadje at gmail dot com --- Comment #2 from denkpadje at gmail dot com 2012-04-03 02:36:59 UTC --- It seems the error is triggered in a different .c file with GNAT GPL 2010: $ gnatmake -v -gnat05 -gnatd -O0 testcase.adb: +===GNAT BUG DETECTED==+ | GPL 2010 (20100603) (i686-pc-linux-gnu) GCC error: | | in simplify_subreg, at simplify-rtx.c:4924 | | Error detected around test.adb:16| ... compilation abandoned $ gnatmake -v -gnat05 -gnatd -O1 testcase.adb: +===GNAT BUG DETECTED==+ | GPL 2010 (20100603) (i686-pc-linux-gnu) GCC error: | | in simplify_subreg, at simplify-rtx.c:4924 | | Error detected around test.adb:21| ... raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423 $ gnatmake -v -gnat05 -gnatd -O2 testcase.adb: gcc -c -gnat05 -gnatd -O2 test.adb raised STORAGE_ERROR : stack overflow (or erroneous memory access) No gnat bug box with -O2 :/
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #38 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-03 03:41:00 UTC --- (In reply to comment #37) Actually, it's not clear to me that the caret line would be likely to cause trouble for IDEs in any case; they already have to deal with output that isn't a specific error. Maybe we should just turn it on by default in all cases, and possibly backtrack to only on a tty if it causes problems. What I was trying to say, I think it would confuse an user who did a make and saw an error and then did another make but this time piped to tee or to an output file. And looked at the output file and it was different than what was on the tty before. This is why I think we should not worry about the IDEs and just have them handle those cases just as we handle the case of emitting more debugging info and such.
[Bug target/52836] internal compiler error: in push_minipool_fix, at config/arm/arm.c:13084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52836 Chung-Lin Tang cltang at gcc dot gnu.org changed: What|Removed |Added CC||cltang at gcc dot gnu.org --- Comment #2 from Chung-Lin Tang cltang at gcc dot gnu.org 2012-04-03 04:33:44 UTC --- Also note that, for the above testcase from Meador, the ICE is hidden after the changes in rev.185913, although a similar fail may still be triggered for gcc.c-torture/compile/920928-2.c
