[Bug tree-optimization/52307] Segmentation fault in Lapack with -O3 -floop-flatten -floop-strip-mine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52307 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Severity|normal |critical --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-02-19 08:00:36 UTC --- There are many more bugs. This occurs with xlintsts stest.in and (using the debugger) the segfault is Program received signal SIGSEGV, Segmentation fault. 0x100b2bd0 in spbtrf (uplo='\000', n=0, kd=0, ab=..., ldab=0, info=0, _uplo=optimized out) at spbtrf.f:336 336 WORK( I, J ) = ZERO SUBROUTINE SPBTRF( UPLO, N, KD, AB, LDAB, INFO ) * * -- LAPACK computational routine (version 3.4.0) -- * -- LAPACK is a software package provided by Univ. of Tennessee,-- * -- Univ. of California Berkeley, Univ. of Colorado Denver and NAG Ltd..-- * November 2011 * * .. Scalar Arguments .. CHARACTER UPLO INTEGERINFO, KD, LDAB, N * .. * .. Array Arguments .. REAL AB( LDAB, * ) * .. * * = * * .. Parameters .. REAL ONE, ZERO PARAMETER ( ONE = 1.0E+0, ZERO = 0.0E+0 ) INTEGERNBMAX, LDWORK PARAMETER ( NBMAX = 32, LDWORK = NBMAX+1 ) * .. * .. Local Scalars .. INTEGERI, I2, I3, IB, II, J, JJ, NB * .. * .. Local Arrays .. REAL WORK( LDWORK, NBMAX ) ... * Zero the lower triangle of the work array. * DO 90 J = 1, NB DO 80 I = J + 1, NB WORK( I, J ) = ZERO 80 CONTINUE 90 CONTINUE Trying to reduce this further.
[Bug c/51437] GCC should warn on the use of reserved identifier/macro names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 --- Comment #10 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2012-02-19 09:33:05 UTC --- (In reply to comment #9) (In reply to comment #8) You really do want to flag both definition and usage. For instance, there's plenty of buggy software (especially GNU software like binutils) using __pid_t and similar when it should be using pid_t, etc. In the case of identifiers containing __ or starting with _[A-Z], that does hold true; I hadn't considered programs using internal identifiers when corresponding public identifiers exist. (Ideally the headers could have avoided exposing those internal identifiers to user programs in the first place, but I don't know any sensible way to implement that.) However, note that the standards also reserve various other classes of names, such as types ending in _t, for which GCC should only flag definitions, not uses. Only system headers should define new _t types, but user code can *use* types like time_t or pid_t without warning. These are only reserved for POSIX, and should not always be warned about! (Some of the other reserved identifier categories, such as E[A-Z0-9].*, is[a-z].*, to[a-z].*, and mem[a-z].* should go under some separate, more pedantic warning option.) I don't see why this should happen at all. There's nothing special about these general names? From an undefined behavior standpoint, defining a name in the reserved namespace is no worse than using a name in the referred namespace assuming the implementation has defined it. Both are incorrect C usage and both should be flagged. True. I had mostly wanted to avoid generating hundreds of warnings for the same identifier. However, that seems better than missing cases like the __pid_t you mentioned above. My heuristic about -isystem would prevent flagging usage of reserved names resulting from implementations of system headers - for instance, if a macro in a system header used __uint32_t because it needs to avoid making uint32_t visible. Right. That seems like the same heuristic documented at http://gcc.gnu.org/onlinedocs/cpp/System-Headers.html that I referenced in comment 7: Macros defined in a system header are immune to a few warnings wherever they are expanded.
[Bug tree-optimization/51782] -ftree-sra: Missing address-space information leads to wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #18 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-19 09:31:52 UTC --- (In reply to comment #17) Created attachment 26695 [details] Untested proposed fix This untested patch fixes the issue for me on a cross-compiler. It would be great if someone who is set up to run the testsuite on a platform with multiple address spaces or a simulator of one could test it a bit. Thanks. It will take some days.
[Bug libffi/52223] [4.5/4.6/4.7 Regression] libffi's man page install breaks with multilibs and overridden mandir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52223 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2012-02-19 10:16:09 UTC --- Reopening, since Joseph's comment and analogous patch for libquadmath implies that this is in fact expected to work.
[Bug c/51437] GCC should warn on the use of reserved identifier/macro names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 --- Comment #11 from David Krauss potswa at mac dot com 2012-02-19 11:09:28 UTC --- (In reply to comment #10) (In reply to comment #9) However, note that the standards also reserve various other classes of names, such as types ending in _t, for which GCC should only flag definitions, not uses. Only system headers should define new _t types, but user code can *use* types like time_t or pid_t without warning. These are only reserved for POSIX, and should not always be warned about! Yes, respecting POSIX would be overkill. In particular, it's OK and common to define such types in C++ outside the global namespace. (Some of the other reserved identifier categories, such as E[A-Z0-9].*, is[a-z].*, to[a-z].*, and mem[a-z].* should go under some separate, more pedantic warning option.) I don't see why this should happen at all. There's nothing special about these general names? See comment #3, they are reserved in C99 §7.26 Future library directions (although those patterns aren't quite right).
[Bug target/51882] ICE: in extract_insn, at recog.c:2109 (unrecognizable insn) when building Mesa on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51882 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2012-02-19 11:17:20 UTC --- (In reply to comment #0) However, the issue is no longer present in the latest 4.7 snapshot (tested with a custom toolchain based on gcc-4.7-20120114). Using Ramana's reduced test case I still get the ICE with gcc-4.7-20120218.
[Bug target/52258] __builtin_isgreaterequal is sometimes signaling on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52258 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-02-19 11:23:54 UTC --- Can you provide a standalone runtime test case that fails (with a SIGFPE I assume) when the bug is triggered?
[Bug target/52258] __builtin_isgreaterequal is sometimes signaling on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52258 --- Comment #2 from Aurelien Jarno aurelien at aurel32 dot net 2012-02-19 11:30:36 UTC --- Created attachment 26700 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26700 Testcase
[Bug tree-optimization/52307] Segmentation fault in Lapack with -O3 -floop-flatten -floop-strip-mine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52307 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-19 12:22:21 UTC --- PR52307 could be a duplicate.
[Bug tree-optimization/52307] Segmentation fault in Lapack with -O3 -floop-flatten -floop-strip-mine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52307 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-19 CC||grosser at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-19 12:21:42 UTC --- Confirmed with '-O2 -floop-flatten'. The failure disappears if I link the codes compiled with these option to lapack_LINUX.a compiled with -O2 or -O3. This PR could be a duplicate of pr52275. Note that UPLO should be U or L and not \0.
[Bug tree-optimization/52275] The polyhedron test air.f90 is miscompiled with '-O2 -floop-flatten' after revision 184265
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52275 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-19 12:26:24 UTC --- PR52307 could be a duplicate.
[Bug tree-optimization/52307] Segmentation fault in Lapack with -O3 -floop-flatten -floop-strip-mine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52307 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-19 12:27:18 UTC --- PR52307 could be a duplicate. Oops! put in the wrong pr;-(
[Bug tree-optimization/52307] Segmentation fault in Lapack with -O3 -floop-flatten -floop-strip-mine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52307 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-19 13:34:13 UTC --- In spbtrf.f I have put PRINT statements before and after the loops DO 90 J = 1, NB DO 80 I = J + 1, NB WORK( I, J ) = ZERO 80 CONTINUE 90 CONTINUE The print after the loops is never reached. The code generated between the last print before the loops and the first one after with -O2 is call__gfortran_st_write_done leal1(%r14), %edi movl$1, %eax movq168(%rsp), %r8 movl$1, %ecx L30: leaq34(%rax), %rsi addl$1, %ecx cmpl%r14d, %ecx jg L28 leaq(%r8,%rax,4), %rax movl%r14d, %edx subl%ecx, %edx addq%rsi, %rdx leaq572(%rsp,%rdx,4), %rdx .align 4,0x90 L29: movl$0x, (%rax) addq$4, %rax cmpq%rdx, %rax jne L29 L28: cmpl%edi, %ecx movq%rsi, %rax jne L30 leaqLC14(%rip), %rcx movl$343, 240(%rsp) leaq224(%rsp), %rdi movq%rcx, 232(%rsp) movl$128, 224(%rsp) movl$6, 228(%rsp) call__gfortran_st_write When compiled with -O2 -floop-flatten, it is call__gfortran_st_write_done movl$2, %ecx movl$4294967295, %esi subq%r15, %rcx movq%rcx, %rdx movq%rcx, %rax sarq$63, %rdx idivq %rsi testq %rdx, %rdx je L27 movq%rcx, %rdx xorq%rsi, %rdx notq%rdx shrq$63, %rdx addq%rdx, %rax L27: movabsq $-8589934593, %rcx movq%r15, %rdx salq$32, %rdx addq%r15, %rdx addq%rdx, %rcx cmpq%rcx, %rax jge L28 movabsq $-8589934594, %r11 movl$2, %r9d movq%rax, %r8 leaq-2(%r15), %r10 addq%rdx, %r11 subq%r15, %r9 L31: leaq(%r9,%r8), %rax cmpq%r10, %r8 movq%r10, %rdi cmovle %r8, %rdi movq%rax, %rsi sarq$32, %rsi testl %eax, %eax setne %al movzbl %al, %eax addq%rax, %rsi cmpq%rdi, %rsi jg L29 leaq(%rsi,%r8), %rdx movq%rsi, %rax salq$5, %rax leaq1(%rdx,%rax), %rax leaq704(%rsp,%rax,4), %rdx xorl%eax, %eax .align 4,0x90 L30: movl$0x, (%rdx) leaq(%rax,%rsi), %rcx addq$132, %rdx addq$1, %rax cmpq%rdi, %rcx jl L30 L29: leaq1(%r8), %rax cmpq%r8, %r11 jle L28 movq%rax, %r8 jmp L31 L28: leaqLC14(%rip), %rax movl$343, 240(%rsp) leaq224(%rsp), %rdi movq%rax, 232(%rsp) movl$128, 224(%rsp) movl$6, 228(%rsp) call__gfortran_st_write
[Bug tree-optimization/52307] Segmentation fault in Lapack with -O3 -floop-flatten -floop-strip-mine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52307 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-19 14:19:23 UTC --- Reduced code integer :: I, J, NB = 3 real :: WORK(3,3) =1.0 real :: ZERO = 0.0 DO 90 J = 1, NB DO 80 I = J + 1, NB WORK( I, J ) = ZERO 80 CONTINUE 90 CONTINUE print *, WORK end
[Bug lto/50616] lto1.exe: internal compiler error: invalid resolution in the resolution file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50616 Stefan Reichardt fbi.sr at gmx dot de changed: What|Removed |Added CC||fbi.sr at gmx dot de --- Comment #8 from Stefan Reichardt fbi.sr at gmx dot de 2012-02-19 14:29:16 UTC --- Could you please tell which file you are speaking of, where to apply your fix from comment #6? This bug does not occur on my system. i compiled gcc-4.7.0-20120217 on mingw32 on Windows 7 - 64bit for target=avr. But my compiler will generate the bug when run on 32-bit Windows. If i apply your hack from comment #6, will my compiler-lto then be usable on 32-bit but not on 64bit?
[Bug testsuite/52229] [4.7 Regression] FAIL: gfortran.dg/vect/pr32380.f -O scan-tree-dump-times vect vectorized 7 loops 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52229 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-19 14:42:35 UTC --- A working patch has been submitted at http://gcc.gnu.org/ml/fortran/2012-02/msg00068.html .
[Bug ada/52219] [4.7 Regression] FAIL: cxg2001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52219 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-19 15:20:14 UTC --- cxg2001 has passed my last tests without failure. What is it supposed to test? Is it in the same class as Thread_Sleep_2 in libjava or thread_leak_test.c in boehm-gc for which I got ~6 failures out of ~90 regtests?
[Bug ada/52219] [4.7 Regression] FAIL: cxg2001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52219 --- Comment #7 from Iain Sandoe iains at gcc dot gnu.org 2012-02-19 15:37:47 UTC --- (In reply to comment #6) cxg2001 has passed my last tests without failure. likewise on all my recent tests on both patched un-patched trees. I find that the acats tests are quite likely to exhibit random fails on D9 and D10 for parallel tests on loaded machines, but I associate that with the test-environment (repeating make check-ada has always come up clean - except for cases with real bugs). Which is different from the libjava/boehm-gc cases which always exhibit the marginal fails even on a single process test cycle. ... the test looks like it is doing some FP work - so not likely to be subject to the two following phenomena: Is it in the same class as Thread_Sleep_2 in libjava this randomly fails for a known reason (OS bug), we should probably ask for the Java to be changed so that the timeout has a suitable capture range (it doesn't look like the bug will be fixed in D9 or D10). or thread_leak_test.c in boehm-gc for which I got ~6 failures out of ~90 regtests? this (I think) is related to operating close to the limit of available stack (but that's unconfirmed and on the TODO to investigate). = .. although, it's not impossible that either effect could manifest in cxg2001.a, it seems unlikely. I'd be more inclined to blame expect/tcl/dejgnu + system load. Unless you can repeat the failure.
[Bug ada/52219] [4.7 Regression] FAIL: cxg2001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52219 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-19 15:39:01 UTC --- All ACATS tests come with a description in the file. Given the contents of the log file, this was probably an external glitch.
[Bug target/51882] ICE: in extract_insn, at recog.c:2109 (unrecognizable insn) when building Mesa on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51882 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2012-02-19 16:06:11 UTC --- This bug happens in reload...
[Bug lto/50616] lto1.exe: internal compiler error: invalid resolution in the resolution file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50616 --- Comment #9 from niXman i.nixman at gmail dot com 2012-02-19 16:22:52 UTC --- lto-plugin/lto-plugin.c http://gcc.gnu.org/viewcvs/trunk/lto-plugin/lto-plugin.c?view=markup line 363.
[Bug libstdc++/52309] New: [c++0x] unordered_set illegally requires value_type::operator!=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52309
Bug #: 52309
Summary: [c++0x] unordered_set illegally requires
value_type::operator!=
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ro...@binarylife.net
$ cat test.cpp
#include unordered_set
struct value {};
struct hash { std::size_t operator()(value const)const; };
bool operator==(value const,value const);
std::unordered_setvalue,hash set;
bool z=(set==set);
$ g++ -std=c++0x -c test.cpp 21 | egrep error
./include/c++/4.7.0/bits/hashtable_policy.h:1116:4: error: no match for
‘operator!=’ in ‘__ity.std::__detail::_Node_const_iterator_Value,
__constant_iterators, __cache::operator*value, true, true() !=
__itx.std::__detail::_Node_const_iterator_Value, __constant_iterators,
__cache::operator*value, true, true()’
set==set needs operator!=(value,value).
The value type is EqualityComparable and looks good for unordered_set.
(17.6.3.1, 23.2.1, 23.2.5/2 and 23.2.5/11)
All other associative unordered containers do not need
value_type::operator!=(). Only unordered_set requires it.
[Bug lto/50616] lto1.exe: internal compiler error: invalid resolution in the resolution file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50616 --- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org 2012-02-19 16:31:32 UTC --- Yes, not all msvcrt versions are supporting %ll width modifier. Modern versions of it (as 64-bit versions) are supporting it, but older (and still pretty common on 32-bit OSes) don't. Therefore it is for native Windows apps more compatible to use here instead %I64. As Andrew mentioned we might should use here instead PRIx64 for output of 64-bit integer-scalars. Any patch in this direction would be welcome for me.
[Bug libstdc++/52309] [c++0x] unordered_set illegally requires value_type::operator!=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52309 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-19 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-19 16:54:37 UTC --- Oops, but seems trivial to fix.
[Bug libstdc++/52300] Gthreads functions linking error at dynamic linking with libstdc++ when using MinGW.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52300 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-19 CC||ktietz at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org 2012-02-19 17:12:13 UTC --- As pe-coff doesn't have fully compatible support for weaks to ELF ones, we should disable it. In static version it works, but when used in shared variant it doesn't. I suggest the following patch to solve this problem: Index: gthr.h === --- gthr.h (revision 184333) +++ gthr.h (working copy) @@ -135,6 +135,14 @@ */ #if SUPPORTS_WEAK +/* The pe-coff weak support isn't fully compatible to ELF's weak. + For static libraries it might would work, but as we need to deal + with shared versions too, we disable it for mingw-targets. */ +#ifdef __MINGW32__ +#undef GTHREAD_USE_WEAK +#define GTHREAD_USE_WEAK 0 +#endif + #ifndef GTHREAD_USE_WEAK #define GTHREAD_USE_WEAK 1 #endif
[Bug libstdc++/52300] Gthreads functions linking error at dynamic linking with libstdc++ when using MinGW.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52300 --- Comment #2 from niXman i.nixman at gmail dot com 2012-02-19 17:14:03 UTC --- Thanks Kai!
[Bug c/52310] New: Internal Compiler Error when building lesstif with -Wp,-D_FORTIFY_SOURCE=2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52310
Bug #: 52310
Summary: Internal Compiler Error when building lesstif with
-Wp,-D_FORTIFY_SOURCE=2
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pter...@gmail.com
Created attachment 26701
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26701
Preprocessed source
[pterjan@jonund Xm-2.1]$ gcc -DHAVE_CONFIG_H -I. -I. -I../../include
-I../../include/Motif-2.1 -I../../include/Motif-2.1 -I/usr/include
-I/usr/include -O2 -g -pipe -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
-DMWM_DDIR=\/usr/share/X11/mwm\ -c XmString.c -fPIC -DPIC -o
.libs/XmString.o
{standard input}: Assembler messages:
{standard input}: Warning: end of file not at end of a line; newline inserted
{standard input}:2041: Error: unbalanced parenthesis in operand 2.
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
gcc: internal compiler error: Segmentation fault (program cc1)
I attached the preprocessed source, it crashes here (x86_64) when using gcc -g
-c XmStringE.c with gcc-4.6.2
This preprocessed source builds fine using gcc-4.5.1 (even if it gives a lot of
warning about casting pointers to int).
[Bug target/50946] ICE on armhf with webkitgtk+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50946 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2012-02-19 17:29:00 UTC --- The ICE stopped on trunk with Richard Sandiford's Tighten ARM's CANNOT_CHANGE_MODE_CLASS patch in r171520: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01631.html http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg00945.html The patch was described only as improving code quality, not as fixing any specific bugs, so it's possible the underlying bug is still latent on trunk.
[Bug middle-end/42961] [4.5/4.6 regression] IRA register preferencing bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42961 --- Comment #8 from Mikael Pettersson mikpe at it dot uu.se 2012-02-19 17:43:07 UTC --- The movss instructions were eliminated on trunk by Vladimir Makarov's patch to solve recent SPEC2000 degradation in r178019: http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01954.html http://gcc.gnu.org/ml/gcc-cvs/2011-08/msg01034.html The code generation change at that point is: --- pr42961.s-r178018 2012-02-19 18:22:46.0 +0100 +++ pr42961.s-r178019 2012-02-19 18:17:07.0 +0100 @@ -10,18 +10,17 @@ ucomiss %xmm2, %xmm2 jp .L7 jne .L7 - movss %xmm1, -4(%rsp) .L2: movlf(%rip), %eax testl %eax, %eax je .L4 - movss -4(%rsp), %xmm2 + movaps %xmm1, %xmm2 .L4: movaps %xmm2, %xmm0 ret .L7: movaps %xmm1, %xmm2 - movss %xmm0, -4(%rsp) + movaps %xmm0, %xmm1 jmp .L2 .cfi_endproc .LFE0:
[Bug target/51882] ICE: in extract_insn, at recog.c:2109 (unrecognizable insn) when building Mesa on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51882
--- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2012-02-19
17:48:16 UTC ---
With slightly modified test case (manually inlined apply_aa_coverage()):
BEFORE RELOAD:
(insn 142 133 314 9 (set (subreg:SI (reg:HI 283) 0)
(unsigned_fix:SI (fix:SF (reg/v:SF 226 [ a ] besttry.c:73 682
{fixuns_truncsfsi2}
(expr_list:REG_DEAD (reg/v:SF 226 [ a ])
(nil)))
Reloads for insn # 142
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 11 fp)
(const_int -65536
[0x]))
CORE_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0)
reload_in_reg: (plus:SI (reg/f:SI 11 fp)
(const_int -65536
[0x]))
reload_reg_rtx: (reg:SI 12 ip)
Reload 1: GENERAL_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0), can't combine,
secondary_reload_p
reload_reg_rtx: (reg:DI 8 r8)
Reload 2: GENERAL_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0), can't combine,
secondary_reload_p
reload_reg_rtx: (reg:SI 10 sl)
secondary_out_reload = 1
secondary_out_icode = reload_outhi
Reload 3: reload_out (SI) = (subreg:SI (mem/c:HI (plus:SI (plus:SI (reg/f:SI 11
fp)
(const_int
-65536 [0x]))
(const_int -52
[0xffcc])) [14 %sfp+-65544 S2 A64]) 0)
VFP_LO_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (subreg:SI (reg:HI 283) 0)
reload_reg_rtx: (reg:SI 77 s14)
secondary_out_reload = 2
AFTER RELOAD:
(insn 142 133 355 9 (set (reg:SI 77 s14)
(unsigned_fix:SI (fix:SF (reg/v:SF 78 s15 [orig:226 a ] [226]
besttry.c:73 682 {fixuns_truncsfsi2}
(nil))
(insn 355 142 356 9 (set (reg:SI 12 ip)
(plus:SI (reg/f:SI 11 fp)
(const_int -65536 [0x]))) besttry.c:73 4
{*arm_addsi3}
(nil))
(insn 356 355 357 9 (set (reg:HI 10 sl)
(reg:SI 77 s14)) besttry.c:73 -1
(nil))
(insn 357 356 358 9 (set (mem:QI (plus:SI (reg:SI 12 ip)
(const_int -52 [0xffcc])) [0 S1 A8])
(reg:QI 10 sl)) besttry.c:73 -1
(nil))
(insn 358 357 359 9 (set (reg:SI 8 r8)
(lshiftrt:SI (subreg:SI (reg:HI 10 sl) 0)
(const_int 8 [0x8]))) besttry.c:73 -1
(nil))
(insn 359 358 314 9 (set (mem:QI (plus:SI (reg:SI 12 ip)
(const_int -51 [0xffcd])) [0 S1 A8])
(reg:QI 8 r8)) besttry.c:73 -1
(nil))
besttry.c: In function ‘_swrast_write_rgba_span’:
besttry.c:108:1: error: unrecognizable insn:
(insn 356 355 357 9 (set (reg:HI 10 sl)
(reg:SI 77 s14)) besttry.c:73 -1
(nil))
besttry.c:108:1: internal compiler error: in extract_insn, at recog.c:2123
Looks like a secondary reload failed.
[Bug c++/52311] New: implicitly_declare_fn: valgrind problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52311 Bug #: 52311 Summary: implicitly_declare_fn: valgrind problem Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com I just tried to compile the file gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mangle2.C under valgrind on trunk dated 20120216 on an AMD x86_64 box. Valgrind said ==19480== Conditional jump or move depends on uninitialised value(s) ==19480==at 0x666A2A: implicitly_declare_fn(special_function_kind, tree_node*, bool) (method.c:1538) ==19480==by 0x66914A: lazily_declare_fn(special_function_kind, tree_node*) (method.c:1766) ==19480==by 0x66FA94: lookup_fnfields_1(tree_node*, tree_node*) (search.c:1449) ==19480==by 0x673156: lookup_field_r(tree_node*, void*) (search.c:1479) ==19480==by 0x66D743: _Z12dfs_walk_allP9tree_nodePFS0_S0_PvES3_S1_.constprop.7 (search.c:1581) ==19480==by 0x66F5FB: lookup_member(tree_node*, tree_node*, int, bool, int) (search.c:1213) No special flags required.
[Bug c++/52312] New: grokfndecl: valgrind problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52312 Bug #: 52312 Summary: grokfndecl: valgrind problem Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com I just tried to compile the file gcc/testsuite/g++.dg/cpp0x/udlit-nounder-neg.C under valgrind on trunk dated 20120216 on an AMD x86_64 box. Valgrind said ==11414== Conditional jump or move depends on uninitialised value(s) ==11414==at 0x4C442F: grokfndecl(tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, int, overload_flags, int, tree_node*, int, int, int, int, special_function_kind, bool, int, tree_node*, tree_node**, unsigned int) (decl.c:7394) ==11414==by 0x53949D: grokdeclarator(cp_declarator const*, cp_decl_specifier_seq const*, decl_context, int, tree_node**) (decl.c:10349) ==11414==by 0x53A575: start_decl(cp_declarator const*, cp_decl_specifier_seq*, int, tree_node*, tree_node*, tree_node**) (decl.c:4346) ==11414==by 0x617793: cp_parser_init_declarator(cp_parser*, cp_decl_specifier_seq*, VEC_deferred_access_check_gc*, bool, bool, int, bool*, tree_node**) (parser.c:15660) No special flags required.
[Bug libgomp/52303] libgomp leaves threads lying around that cause trouble if the program is later fork()'d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52303 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-19 18:01:58 UTC --- Preserving the threads after the parallel region finishes is basically required by the standard, as a new parallel region with the same number of threads needs to preserve threadprivate data. So even after a parallel region is left, your process is still multi-threaded.
[Bug c/51437] GCC should warn on the use of reserved identifier/macro names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 --- Comment #12 from Josh Triplett josh at joshtriplett dot org 2012-02-19 18:50:34 UTC --- (In reply to comment #10) (In reply to comment #9) However, note that the standards also reserve various other classes of names, such as types ending in _t, for which GCC should only flag definitions, not uses. Only system headers should define new _t types, but user code can *use* types like time_t or pid_t without warning. These are only reserved for POSIX, and should not always be warned about! I stand corrected. I thought that the C standard reserved types with a _t suffix, but I just re-checked the C99 and C11 specs and they don't have that reservation, only some more specific reservations such as the others I mentioned.
[Bug c/51437] GCC should warn on the use of reserved identifier/macro names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 --- Comment #13 from Josh Triplett josh at joshtriplett dot org 2012-02-19 18:56:28 UTC --- (In reply to comment #11) (In reply to comment #10) (In reply to comment #9) (Some of the other reserved identifier categories, such as E[A-Z0-9].*, is[a-z].*, to[a-z].*, and mem[a-z].* should go under some separate, more pedantic warning option.) I don't see why this should happen at all. There's nothing special about these general names? See comment #3, they are reserved in C99 §7.26 Future library directions (although those patterns aren't quite right). I wrote those patterns based on C11 section 7.30 Future library directions. 7.30.3 says Macros that begin with E and a digit or E and an uppercase letter may be added to the declarations in the errno.h header.. 7.30.2 says Function names that begin with either is or to, and a lowercase letter may be added to the declarations in the ctype.h header.; 7.30.12 also reserves those two for wctype.h. 7.30.11 says Function names that begin with str, mem, or wcs and a lowercase letter may be added to the declarations in the string.h header. AFAICT, those reservations match the regexes I gave.
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #16 from Igor Zamyatin izamyatin at gmail dot com 2012-02-19 18:58:41 UTC --- Jakub, could you please clarify your statement - But libstdc++.so.6's tree.cc has been compiled with -fPIC -DPIC before Benjamin's change and is compiled with those flags after those changes as well Compiler logs show somwhat opposite to this statement: Before Benjamin's commit libtool is called without -prefer-pic: /bin/sh ../libtool --tag CXX --mode=compile -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -Wabi -ffunction-sections -fdata-sections -frandom-seed=tree.lo -g -O2 -D_GNU_SOURCE -c -o tree.lo ../../../../libstdc++-v3/src/tree.cc and then libtool: compile: /export/users/izamyati/././gcc/xgcc -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -Wabi -ffunction-sections -fdata-sections -frandom-seed=tree.lo -g -O2 -D_GNU_SOURCE -c ../../../../libstdc++-v3/src/tree.cc -o tree.o /dev/null 21. But in the same time there is the following libtool: compile: /export/users/izamyati/././gcc/xgcc -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -Wabi -ffunction-sections -fdata-sections -frandom-seed=tree.lo -g -O2 -D_GNU_SOURCE -c ../../../../libstdc++-v3/src/tree.cc -fPIC -DPIC -o .libs/tree.o which is absent after Benjamin's commit. Does all this mean that actually tree.cc compiled with fPIC?
[Bug fortran/38114] unneeded temp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38114 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-02-19 19:14:32 UTC --- Closing as invalid (nobody spoke up), just to keep the bug list a bit more tidy.
[Bug fortran/50688] OpenMP: Strange interaction with BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50688 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-02-19 19:23:48 UTC --- Hmm... I think this can be closed, BLOCK doesn't really make much sense in WORKSHARE. I certainly won't fix this (and the optimization which put a BLOCK inside a workshare has been removed anyway :-)
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-19 19:24:05 UTC --- libstdc++.so.6 obviously contained -fPIC code before and does now as well, and people really should be using the shared library (almost) always. See http://www.akkadia.org/drepper/no_static_linking.html for some details. So, if you are doing SPEC testing with -static, it probably just doesn't test what people normally use or should use. Can you please test Paolo's patch, if the slowdown you see is inherent in the PIC code, or if it is about the different inlining decision? Thanks.
[Bug c++/52312] grokfndecl: valgrind problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52312 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-19 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug c++/52312] grokfndecl: valgrind problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52312 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-19 19:33:21 UTC --- Created attachment 26702 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26702 gcc47-pr52312.patch Untested fix.
[Bug c++/52311] implicitly_declare_fn: valgrind problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52311
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-02-19
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Target Milestone|--- |4.7.0
Ever Confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-19
19:48:39 UTC ---
In the
if (LAMBDA_TYPE_P (ctype)
(sfk == sfk_constructor
|| sfk == sfk_copy_assignment))
{
*deleted_p = true;
return;
}
case synthesized_method_walk doesn't initialize *trivial_p and *constexpr_p.
While the caller clears constexpr_p in that case:
/* Don't bother marking a deleted constructor as constexpr. */
if (deleted_p)
constexpr_p = false;
...
it doesn't clear trivial_p (nor set) and uses it in:
if (!trivial_p type_has_trivial_fn (type, kind))
type_set_nontrivial_flag (type, kind);
So, to fix this, either synthesized_method_walk should in that case initialize
*trivial_p (either to false or true, or conditionally, depending on what is
right), or the caller should do the same (can it do it for all deleted_p types,
not just the lambda ctors/copyctors?), or the if (!trivial_p should also
guarded with !deleted_p.
Jason?
[Bug fortran/44022] Spurious 'unused parameter' for a used procedure argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44022 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-02-19 20:00:39 UTC --- Fixed with the fix for PR 48847. No separate test case necessary. Closing.
[Bug fortran/47844] Array stride ignored for pointer-valued function results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47844 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||tkoenig at gcc dot gnu.org --- Comment #11 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-02-19 20:02:31 UTC --- Is this fixed now? From the comments, it seems that we can close this.
[Bug c/52310] Internal Compiler Error when building lesstif with -Wp,-D_FORTIFY_SOURCE=2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52310 --- Comment #1 from Pascal Terjan pterjan at gmail dot com 2012-02-19 20:23:15 UTC --- Created attachment 26703 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26703 Reduce source code leading to the crash Here is the minimal code I managed to trigger the crash
[Bug c/52310] Internal Compiler Error when building lesstif with -Wp,-D_FORTIFY_SOURCE=2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52310 Pascal Terjan pterjan at gmail dot com changed: What|Removed |Added Attachment #26701|0 |1 is obsolete|| --- Comment #2 from Pascal Terjan pterjan at gmail dot com 2012-02-19 20:23:58 UTC --- Created attachment 26704 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26704 Preprocessed code for the minimal code
[Bug c/52310] Internal Compiler Error when building lesstif with -Wp,-D_FORTIFY_SOURCE=2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52310 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-19 20:24:18 UTC --- Dup of PR51077.
[Bug c/51437] GCC should warn on the use of reserved identifier/macro names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 --- Comment #14 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2012-02-19 21:51:37 UTC --- I don't think adding future reserved identifiers serves any purpose. In general, code is written against a certain version of a language's Standard, with the current constraints, not would-be might-be constraints. Perhaps split that into a very pedantic extra warning or something.
[Bug fortran/52313] New: useless error message for old version of .mod file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52313 Bug #: 52313 Summary: useless error message for old version of .mod file Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: daniel.pr...@monash.edu This is a fairly minor request, but should be an easy one to fix. When upgrading gfortran to a newer version, you often get the following error message: use blah 1 Fatal Error: Parse error when checking module version for file 'blah.mod' opened at (1) ...cryptically referring to the fact that the module was previously compiled with an old version of gfortran. Any chance this can be changed to something more understandable by humans? My suggestion is: Fatal error: 'blah.mod' module version is wrong, most likely because it was compiled with an old version of gfortran. Delete the .mod file and retry. (this bug report is because I got a support request because some code I support didn't compile with a new version of gfortran) Thanks, Daniel
[Bug target/52258] __builtin_isgreaterequal is sometimes signaling on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52258 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2012-02-19 23:32:52 UTC --- On my Tegra2 machine the testcase does report that FE_INVALID got set when compiled at -O1 with gcc-4.6 and 4.5, but not when compiled at -O0.
[Bug rtl-optimization/42522] (zero_extract:SI (mem:QI) ...) misoptimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #16 from Mikael Pettersson mikpe at it dot uu.se 2012-02-19 23:48:41 UTC --- Since r171341 (a big complex optabs cleanup patch) trunk aka 4.7 generates bar: move.l 4(%sp),%a0 tst.b (%a0) jne .L3 clr.l %d1 move.b 1(%a0),%d1 swap %d1 clr.w %d1 clr.l %d0 move.b 2(%a0),%d0 lsl.l #8,%d0 or.l %d1,%d0 or.b 3(%a0),%d0 moveq #8,%d1 cmp.l %d0,%d1 scs %d0 extb.l %d0 neg.l %d0 rts .L3: clr.l %d0 rts for the m68k-elf target. (The code is much better for m68k-linux.)
[Bug target/52261] [avr] Add support for AVR Xmega cores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52261 --- Comment #3 from Stefan Reichardt fbi.sr at gmx dot de 2012-02-20 02:01:30 UTC --- Could you add support for the few new devices with USB Support aswell? example Xmega32A4U. For the moment, i am using your code with xmega128a1 and i see no problems. Thanks alot!
[Bug middle-end/52314] New: gimplifier produces volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52314
Bug #: 52314
Summary: gimplifier produces volatile
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org
Noticed when improving tree-ssa-forwprop and other passes but is reproducible
on the trunk also.
Take:
volatile double bar;
int foo()
{
double baz = -__builtin_huge_val();
return baz = -bar;
}
--- CUT ---
The gimple output is:
foo ()
{
int D.1591;
volatile double bar.0;
volatile double D.1593;
double baz;
baz = -Inf;
bar.0 = bar;
D.1593 = -bar.0;
D.1591 = D.1593 = baz;
return D.1591;
}
--- CUT ---
The variables marked with volatile are wrongly marked as volatile. Even though
those two decls are not marked with volatile, their types are. When fold
happens, it sometimes wraps SAVE_EXPR around them because the whole volatile on
the type issue.
[Bug middle-end/52314] [4.4/4.5/4.6/4.7 Regression] gimplifier produces volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52314 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Known to work||4.3.5 Keywords||wrong-code Last reconfirmed||2012-02-20 AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Summary|gimplifier produces |[4.4/4.5/4.6/4.7 |volatile|Regression] gimplifier ||produces volatile Target Milestone|--- |4.7.0 Known to fail||4.4.5, 4.7.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-20 04:38:21 UTC --- I am going to fix this. This was working correctly in 4.3.5
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #18 from Vladimir Yakovlev vbyakovl23 at gmail dot com 2012-02-20 05:37:32 UTC --- I tested Paolo's patch and got acceleration on 447.dial base: +7.36% peak: +5.97% Also I looked dumps: the new routine 'local_Rb_tree_increment' in inlined now in both uses.
