[Bug fortran/39253] A bug with interface in gfortran
--- Comment #2 from bubin at qcri dot or dot jp 2009-02-20 08:05 --- It looks like this bug has been fixed since version 4.1. I tried to compile the code with a newer version of gfortran, 4.3.2, and everything went fine. Apologies for a wrong alarm. -- bubin at qcri dot or dot jp changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39253
[Bug testsuite/38164] gcc.target/i386/amd64-abi-3.c fails at -m64 on i686-apple-darwin9
--- Comment #3 from dominiq at lps dot ens dot fr 2009-02-20 09:41 ---
Just add -fomit-frame-pointer to dg-options.
Indeed with the following patch:
--- gcc/testsuite/gcc.target/i386/amd64-abi-3.c 2008-09-02 22:05:08.0
+0200
+++ /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.target/i386/amd64-abi-3.c
2009-02-19 23:20:19.0 +0100
@@ -1,6 +1,6 @@
/* { dg-do compile } */
/* { dg-require-effective-target lp64 } */
-/* { dg-options -O2 -mno-sse } */
+/* { dg-options -O2 -mno-sse -fomit-frame-pointer } */
/* { dg-final { scan-assembler subq\[\\t \]*\\\$88,\[\\t \]*%rsp } } */
/* { dg-final { scan-assembler-not subq\[\\t \]*\\\$216,\[\\t \]*%rsp } } */
the tests pass:
PASS: gcc.target/i386/amd64-abi-3.c (test for excess errors)
PASS: gcc.target/i386/amd64-abi-3.c scan-assembler subq[\\t ]*\\$88,[\\t ]*%rsp
PASS: gcc.target/i386/amd64-abi-3.c scan-assembler-not subq[\\t ]*\\$216,[\\t
]*%rsp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38164
[Bug tree-optimization/39245] FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times optimized nasty_local 0
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-20 09:49 --- Probably the same issue as on AVR? /* PR36598 AVR fail maybe due to cost metrics */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39245
[Bug c/39252] Request new feature __builtin_not_reached();
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-02-20 09:57 --- Though __builtin_not_reached () can be used to implement __builtin_assume (), so it may be more generally useful. if (i 0) __builtin_not_reached (); will make GCC assume that i = 0 on the other edge (of course we'd have to preserve this until some point to take advantage of it). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-20 09:57:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
[Bug target/39240] [4.2/4.3/4.4 Regression] Invalid sibcall optimization with promoted return types and differing signedness
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-20 10:13 --- Subject: Bug 39240 Author: jakub Date: Fri Feb 20 10:13:17 2009 New Revision: 144316 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144316 Log: PR target/39240 * calls.c (expand_call): Clear try_tail_call if caller and callee disagree in promotion of function return value. * gcc.c-torture/execute/pr39240.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr39240.c Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39240
[Bug target/39240] [4.2/4.3 Regression] Invalid sibcall optimization with promoted return types and differing signedness
--- Comment #4 from jakub at gcc dot gnu dot org 2009-02-20 10:19 --- Fixed so far on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.3 Known to work||4.4.0 Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3 Regression] Invalid |Invalid sibcall optimization|sibcall optimization with |with promoted return types |promoted return types and |and differing signedness|differing signedness http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39240
[Bug target/39228] [4.3/4.4 Regression] 387 optimised __builtin_isinf() gives incorrect result
--- Comment #8 from kkojima at gcc dot gnu dot org 2009-02-20 10:41 ---
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr39228.c
SH requires -mieee option for the newly added pr39228.c test.
I guess that alpha is on the same boat. Also it'll fail on
the targets like SPU which have no inf/nan supports. We need
gcc.c-torture/execute/pr39228.x
if { [istarget alpha*-*-*] || [istarget sh*-*-*] } {
# alpha and SH require -mieee for this test.
set additional_flags -mieee
}
if [istarget spu-*-*] {
# No Inf/NaN support on SPU.
return 1
}
return 0
or something like that, doesn't we?
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
CC||kkojima at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39228
[Bug tree-optimization/39245] FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times optimized nasty_local 0
--- Comment #3 from dominiq at lps dot ens dot fr 2009-02-20 10:46 --- This test fails also on powerpc64-unknown-linux-gnu with -m32, see: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01915.html This pr seems to be a duplicate of PR36598 for ppc, arm, and avr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39245
[Bug testsuite/38164] gcc.target/i386/amd64-abi-3.c fails at -m64 on i686-apple-darwin9
--- Comment #4 from uros at gcc dot gnu dot org 2009-02-20 11:25 --- Subject: Bug 38164 Author: uros Date: Fri Feb 20 11:25:42 2009 New Revision: 144318 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144318 Log: PR testsuite/38164 * gcc.target/i386/amd64-abi-3.c: Add -fomit-frame-pointer to dg-options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/amd64-abi-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38164
[Bug testsuite/38164] gcc.target/i386/amd64-abi-3.c fails at -m64 on i686-apple-darwin9
--- Comment #5 from ubizjak at gmail dot com 2009-02-20 11:26 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38164
[Bug middle-end/39157] Code that compiles fine in 1GB of memory with 4.1.2 requires 20GB in 4.2.* and higher
--- Comment #24 from jakub at gcc dot gnu dot org 2009-02-20 12:56 --- Subject: Bug 39157 Author: jakub Date: Fri Feb 20 12:56:01 2009 New Revision: 144320 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144320 Log: PR middle-end/39157 * Makefile.in (loop-invariant.o): Depend on $(PARAMS_H). * params.h (LOOP_INVARIANT_MAX_BBS_IN_LOOP): Define. * params.def (loop-invariant-max-bbs-in-loop): New parameter. * opts.c (decode_options): Set loop-invariant-max-bbs-in-loop parameter to 1000 for -O1 by default. * doc/invoke.texi (loop-invariant-max-bbs-in-loop): Document new parameter. * loop-invariant.c: Include params.h. (move_loop_invariants): Don't call move_single_loop_invariants on very large loops. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/doc/invoke.texi trunk/gcc/loop-invariant.c trunk/gcc/opts.c trunk/gcc/params.def trunk/gcc/params.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #97 from jakub at gcc dot gnu dot org 2009-02-20 13:03 ---
http://gcc.gnu.org/viewcvs?root=gccview=revrev=144320
limits now RTL LICM to loops with less than 1 bbs (-O{2,3,s}) resp. 1000
bbs (-O1).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
--- Comment #13 from hubicka at ucw dot cz 2009-02-20 14:39 --- Subject: Re: [4.4 Regression] Inconsistent reject / accept of code What that means is that we *must not* implicitly instantiate things declared extern template unless they are DECL_DECLARED_INLINE_P. As a consequence, at -O3, we cannot implicitly instantiate non-inline extern template functions. I'm not entirely sure that's what we want it to say, but it does seem like a reasonable expectation for users to have. Beyond this issue, what is the compile speed impact of the earlier change to use possibly_inlined_p? It seems like it might be making us speculatively instantiate a lot more functions for potential inlining even at -O1, which I would expect to cause memory bloat and slower compilation. There was no slowdowns visible on our C++ testers, so I hope it is not too bad. We now get rid of unreachable functions quite early in queue so they are not consuming too much of compilation time. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
[Bug c++/39219] attribute doesn't work with enums properly
--- Comment #9 from hjl dot tools at gmail dot com 2009-02-20 14:47 ---
(In reply to comment #6)
(In reply to comment #5)
Should attribute work on enum constants?
Not sure if this is a question for me but IMO, it should. I would expect
individual enumerators to be more heavily referenced than their types
(sometimes even exclusively) and the warning to be of equal importance
for both. In addition, just like declaring a class deprecated implies
that all members of the class are deprecated, so should declaring
an enumeration deprecated imply that all its enumerators are.
__attribute__((deprecated)) can be used on class members.
Finally, since enumerators of unnamed types can be declared deprecated
not issuing the warning would make such declarations pointless:
$ cat u.cpp g++ -W -Wall -Werror -c u.cpp
enum __attribute__((deprecated)) { e };
int i = e; // warning missing
$
I don't believe gcc supports
enum { e __attribute__((deprecated)) };
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39219
[Bug c++/39225] [4.3 Regression] ICE if destructor doen't match class name
--- Comment #11 from jason at gcc dot gnu dot org 2009-02-20 15:22 --- Subject: Bug 39225 Author: jason Date: Fri Feb 20 15:21:51 2009 New Revision: 144325 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144325 Log: PR c++/39225 * decl.c (grokdeclarator): Handle ~identifier. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/parse/dtor15.C - copied unchanged from r144314, trunk/gcc/testsuite/g++.dg/parse/dtor15.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/decl.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-20 17:14 --- A new patch is at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00961.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2009- |patches/2009- |02/msg00939.html|02/msg00961.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39241
[Bug target/38056] Missed tail calls on ia64
--- Comment #5 from sje at gcc dot gnu dot org 2009-02-20 17:18 --- Subject: Bug 38056 Author: sje Date: Fri Feb 20 17:18:20 2009 New Revision: 144329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144329 Log: PR target/38056 * config/ia64/ia64.c (ia64_function_ok_for_sibcall): Check TARGET_CONST_GP. * gcc.target/ia64/sibcall-opt-1.c: New test. * gcc.target/ia64/sibcall-opt-2.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/ia64/sibcall-opt-1.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/ia64/sibcall-opt-2.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/ia64/ia64.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38056
[Bug target/38056] Missed tail calls on ia64
--- Comment #6 from sje at cup dot hp dot com 2009-02-20 17:20 --- Fixed on mainline and 4.3 branch. -- sje at cup dot hp dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Known to fail||4.3.1 4.3.2 4.3.3 Known to work||4.3.4 4.4.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38056
[Bug tree-optimization/39245] FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times optimized nasty_local 0
--- Comment #4 from danglin at gcc dot gnu dot org 2009-02-20 18:05 --- --param sra-max-structure-size=32 results in optimal code. *** This bug has been marked as a duplicate of 36598 *** -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39245
[Bug middle-end/36598] Failed optimisation of return of struct argment in memcpy-1.c
--- Comment #6 from danglin at gcc dot gnu dot org 2009-02-20 18:05 --- *** Bug 39245 has been marked as a duplicate of this bug. *** -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36598
[Bug middle-end/36598] Failed optimisation of return of struct argment in memcpy-1.c
--- Comment #7 from danglin at gcc dot gnu dot org 2009-02-20 18:08 --- Test also fails on powerpc64 with -m32, arm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36598
[Bug testsuite/27221] g++.dg/ext/alignof2.C fails on powerpc-darwin (and powerpc-aix)
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-02-20 18:36 --- Should we just XFAIL this test for powerpc-*-darwin* and powerpc-*-aix? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27221
[Bug c++/39225] [4.3 Regression] ICE if destructor doen't match class name
--- Comment #12 from jason at gcc dot gnu dot org 2009-02-20 18:59 --- Fixed in 4.3 as well. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
[Bug middle-end/36598] Failed optimisation of return of struct argment in memcpy-1.c
--- Comment #8 from ubizjak at gmail dot com 2009-02-20 19:49 --- (In reply to comment #7) Test also fails on powerpc64 with -m32, arm. And sh4. http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01952.html -- ubizjak at gmail dot com changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|avr-unknown-none| Last reconfirmed|-00-00 00:00:00 |2009-02-20 19:49:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36598
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #98 from lucier at math dot purdue dot edu 2009-02-20 19:52 --- Thank you, that indeed fixes the LICM problem. Based on some comments for this PR and for PR 39157 I thought that a similar patch might apply to PRE. So with euler-14% /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../../mainline/configure --enable-checking=release --prefix=/pkgs/gcc-mainline --enable-languages=c --enable-gather-detailed-mem-stats Thread model: posix gcc version 4.4.0 20090220 (experimental) [trunk revision 144328] (GCC) I ran this command /pkgs/gcc-mainline/bin/gcc -v -c -O2 -fmem-report -ftime-report compiler.i -save-temps ! report-compiler where compiler.i is found at http://www.math.purdue.edu/~lucier/bugzilla/8/ and I killed the job after it required 17GB of RAM. This job compiles just fine with euler-15% /pkgs/gcc-4.1.2/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/pkgs/gcc-4.1.2 Thread model: posix gcc version 4.1.2 in about 1.5 GB of RAM. To derive some statistics I ran /pkgs/gcc-mainline/bin/gcc -v -c -O2 -fmem-report -ftime-report _num.i -save-temps ! report-num where the smaller file _num.i is also found at http://www.math.purdue.edu/~lucier/bugzilla/8/ I'll attach report-num to this PR. The highlights are PRE : 23.28 (24%) usr 0.01 ( 0%) sys 23.51 (24%) wall 681 kB ( 0%) ggc integrated RA : 12.70 (13%) usr 0.00 ( 0%) sys 12.83 (13%) wall 3709 kB ( 2%) ggc TOTAL : 95.93 2.7399.72 227422 kB and that's about it, nothing else above 5%. There are also accurate memory statistics, as I've added a patch to my local sources so that memory statistics don't overflow 32-bit counters. I think the -O1 and -O2 limits for LICM are quite reasonable; would it be possible to limit PRE similarly so that one could compile compiler.i with -O2 in a reasonable amount of memory? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #99 from lucier at math dot purdue dot edu 2009-02-20 19:54 --- Created an attachment (id=17336) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17336action=view) Memory and CPU statistics when compiling _num.i with -O2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #100 from lucier at math dot purdue dot edu 2009-02-20 19:56 --- The large memory requirements for LICM at -O1 and -O2 is still a regression for the 4.2 and 4.3 branches. Jakub's patch is short and elegant; do you think it would be a good idea to backport it to the other open branches? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug c/39254] New: gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
The new testcase gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9 when compiled with -O2 or -Os. The failure is... Executing on host: /sw/src/fink.build/gcc44-4.3.999-20090219/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20090219/darwin_objdir/gcc/ /sw/src/fink.build/gcc44-4.3.999-20090219/gcc-4.4-20090219/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c -w -O2 -lm -o /sw/src/fink.build/gcc44-4.3.999-20090219/darwin_objdir/gcc/testsuite/gcc/va-arg-trap-1.x2 (timeout = 300) /sw/src/fink.build/gcc44-4.3.999-20090219/gcc-4.4-20090219/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c: In function 'bar': /sw/src/fink.build/gcc44-4.3.999-20090219/gcc-4.4-20090219/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c:29: internal compiler error: in move_insn, at haifa-sched.c:1934 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is: /sw/src/fink.build/gcc44-4.3.999-20090219/gcc-4.4-20090219/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c: In function 'bar': /sw/src/fink.build/gcc44-4.3.999-20090219/gcc-4.4-20090219/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c:29: internal compiler error: in move_insn, at haifa-sched.c:1934 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -O2 (internal compiler error) This failure is also occurring on powerpc-ibm-aix5.3.0.0... http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01950.html -- Summary: gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc- apple-darwin9 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug middle-end/39254] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-20 20:52 --- Most likely the __builtin_trap is being turned into a conditional trap which is confusing the scheduler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug tree-optimization/23119] gcc.dg/vect/vect-105.c scan-tree-dump-times vectorized 1 loops 1 fails
--- Comment #6 from sje at cup dot hp dot com 2009-02-20 22:28 ---
Closing this defect as per comment #5. Note that the test is no longer XFAIL
but has
/* { dg-require-effective-target vect_int } */
which I think is a statment that this functionality is intrinsically missing
and unsupported and not temporarily broken.
--
sje at cup dot hp dot com changed:
What|Removed |Added
CC||sje at cup dot hp dot com
Status|REOPENED|RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23119
[Bug middle-end/21059] Bogus warning about clobbered variable
--- Comment #7 from sje at cup dot hp dot com 2009-02-20 22:36 --- It looks like this was fixed in the 4.3 time frame so I am closing the defect. -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to fail||4.0.2 4.0.3 4.0.4 4.1.0 ||4.1.1 4.1.2 4.2.0 4.2.1 ||4.2.2 4.2.3 4.2.4 Known to work||4.3.0 4.3.1 4.3.2 4.4.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21059
[Bug middle-end/21059] Bogus warning about clobbered variable
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21059
[Bug middle-end/39254] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #2 from joseph at codesourcery dot com 2009-02-20 22:47 --- Subject: Re: New: gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9 Does that testcase ICE with a compiler from before the patch that added it? If not, does the builtins.c change I suggested on the gcc list for one possible issue with that patch help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug c++/39236] G++ sets TREE_STATIC and DECL_EXTERNAL on the same VAR_DECLs
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-20 23:38 --- Confirmed, I had saw this originally when I was doing the store-ccp patch which optimized static constant variables that just happened not to be initialized. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-20 23:38:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39236
[Bug c/39255] New: bitfield alias generates incorrect assembly
Consider the following code:
typedef struct {
unsigned long A:16;
unsigned long B:48;
} bits;
int
wrong(unsigned long y)
{
bits *p = (bits *) y;
if (y == 0 || p-A = 512) {
return (1);
}
return (0);
}
int
right(unsigned long y)
{
bits *p = (bits *) y;
if (y == 0 || p-A = 512) {
return (-1);
}
return (0);
}
The *only* difference between right() and wrong() is the return value in the IF
clause. With -O2, the function right() compiles to correct, if suboptimal,
code. The function wrong(), however, generates the following:
wrong:
.prologue
.body
.mmi
cmp.ne p6, p7 = 0, r32
nop 0
addl r14 = 511, r0
.mmi
ld2 r15 = [r12] HUH?
st8 [r12] = r32 HUH?
addl r8 = 1, r0
.mib
nop 0
nop 0
(p7) br.ret.dpnt.many rp
;;
.mmi
cmp4.gtu p6, p7 = r15, r14
;;wrong:
.prologue
.body
.mmi
cmp.ne p6, p7 = 0, r32
nop 0
addl r14 = 511, r0
.mmi
ld2 r15 = [r12]
st8 [r12] = r32
addl r8 = 1, r0
.mib
nop 0
nop 0
(p7) br.ret.dpnt.many rp
;;
.mmi
cmp4.gtu p6, p7 = r15, r14
;;
(p6) addl r14 = 1, r0
(p7) mov r14 = r0
;;
.mib
nop 0
mov r8 = r14
br.ret.sptk.many rp
.endp wrong#
(p6) addl r14 = 1, r0
(p7) mov r14 = r0
;;
.mib
nop 0
mov r8 = r14
br.ret.sptk.many rp
.endp wrong#
It is clearly wrong to perform the load from the stack before the proper value
(r32) has been stored. When run, the value of p-A is the low 16 bits of
whatever was stored on the stack before.
--
Summary: bitfield alias generates incorrect assembly
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsworley at qwest dot net
GCC host triplet: i686-linux-gnu
GCC target triplet: ia64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39255
[Bug c/39255] bitfield alias generates incorrect assembly
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-20 23:47 --- -O2 enables strict aliasing (type based aliasing). You need to use -fno-strict-aliasing to disable that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39255
[Bug c/39255] bitfield alias generates incorrect assembly
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-20 23:56 --- *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39255
[Bug c/21920] aliasing violations
--- Comment #138 from pinskia at gcc dot gnu dot org 2009-02-20 23:56 --- *** Bug 39255 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jsworley at qwest dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c/39255] bitfield alias generates incorrect assembly
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-20 23:59 --- Note in 4.4 and above, GCC generates correct even with strict aliasing enabled and it generates better code, it does not store on the stack at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39255
[Bug target/39146] Unnecessary stack alignment
--- Comment #13 from hjl at gcc dot gnu dot org 2009-02-21 00:01 --- Subject: Bug 39146 Author: hjl Date: Sat Feb 21 00:00:49 2009 New Revision: 144338 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144338 Log: 2009-02-20 Joey Ye joey...@intel.com PR middle-end/39146 * cfgexpand.c (get_decl_align_unit): Update max_used_stack_slot_alignment with align instead of stack_alignment_needed. * function.c (assign_stack_local_1): Update max_used_stack_slot_alignment with alignment_in_bits instead of stack_alignment_needed. (locate_and_pad_parm): Don't update max_used_stack_slot_alignment here. Modified: branches/stack/gcc/ChangeLog.stackalign branches/stack/gcc/cfgexpand.c branches/stack/gcc/function.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug middle-end/39254] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-02-21 00:24 --- Yes, from gcc trunk on 20090120, I see... /sw/src/fink.build/gcc44-4.3.999-20090120/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20090120/darwin_objdir/gcc/ ./va-arg-trap-1.c -w -O2 -lm -o ./va-arg-trap-1.x2 ./va-arg-trap-1.c: In function 'bar': ./va-arg-trap-1.c:29: internal compiler error: in move_insn, at haifa-sched.c:1934 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. on powerpc-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug c/39255] bitfield alias generates incorrect assembly
--- Comment #4 from jsworley at qwest dot net 2009-02-21 00:25 --- Whether or not this is just an aliasing bug, I'd like to understand why changing the return value from 1 to -1 makes the compiler generate correct code. -- jsworley at qwest dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39255
[Bug target/39256] New: __m256 isn't returned in ymm0 in 32bit
[...@gnu-6 pr39146]$ cat bar.i
typedef long long __m256i __attribute__ ((__vector_size__ (32),
__may_alias__));
__m256i
bar (__m256i y, __m256i x)
{
return x;
}
[...@gnu-6 pr39146]$ /export/build/gnu/gcc-stack/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-work/build-x86_64-linux/gcc/ -S -o bar.s -O2 -mavx -m32
bar.i
[...@gnu-6 pr39146]$ cat bar.s
.file bar.i
.text
.p2align 4,,15
.globl bar
.type bar, @function
bar:
pushl %ebp
movl%esp, %ebp
andl$-32, %esp
movl8(%ebp), %eax
vmovdqa %ymm1, (%eax)
movl%ebp, %esp
popl%ebp
ret $4
.size bar, .-bar
__m256 should be returned in ymm0.
--
Summary: __m256 isn't returned in ymm0 in 32bit
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39256
[Bug c/39255] bitfield alias generates incorrect assembly
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-02-21 00:44 --- Because of different optimizations happen. When having 1, it basically creates: if (y == 0) return p-A = 512; return 0; with -1, it keeps the branch. This is normal with aliasing violations really. Anyways the code is undefined so the compiler technically could do anything. *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39255
[Bug c/21920] aliasing violations
--- Comment #139 from pinskia at gcc dot gnu dot org 2009-02-21 00:44 --- *** Bug 39255 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug target/39256] __m256 isn't returned in ymm0 in 32bit
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Keywords||ABI, wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39256
[Bug target/39256] __m256 isn't returned in ymm0 in 32bit
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-21 00:45 --- Where is the ABI documented for AVX? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39256
[Bug middle-end/39254] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #4 from dominiq at lps dot ens dot fr 2009-02-21 00:59 --- Does that testcase ICE with a compiler from before the patch that added it? On powerpc-apple-darwin I see the ICE with gcc at revision 144290 (the test comes in revision 144296). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug target/39256] __m256 isn't returned in ymm0 in 32bit
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-21 00:59 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00974.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg00974.html Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39256
[Bug target/39256] __m256 isn't returned in ymm0 in 32bit
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-21 01:12 --- (In reply to comment #1) Where is the ABI documented for AVX? There is no official ia32 psABI for SSE and AVX. I will upload what we proposed at 2008 gcc summit to http://groups.google.com/group/ia32-abi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39256
[Bug middle-end/39254] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #5 from joseph at codesourcery dot com 2009-02-21 01:16 --- Subject: Re: gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9 On Sat, 21 Feb 2009, dominiq at lps dot ens dot fr wrote: --- Comment #4 from dominiq at lps dot ens dot fr 2009-02-21 00:59 --- Does that testcase ICE with a compiler from before the patch that added it? On powerpc-apple-darwin I see the ICE with gcc at revision 144290 (the test comes in revision 144296). Thanks. So this isn't a regression from my patch, and I don't have anything to suggest about possible causes or fixes in that case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug middle-end/38219] gcc.dg/tree-ssa/vrp47.c fails on powerpc
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-02-21
01:25 ---
So should we have...
Index: gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/vrp47.c (revision 144342)
+++ gcc/testsuite/gcc.dg/tree-ssa/vrp47.c (working copy)
@@ -30,10 +30,10 @@
/* Test that x and y are never compared to 0 -- they're always known to be
0 or 1. */
-/* { dg-final { scan-tree-dump-times \[xy\]\[^ \]* != 0 vrp1 } } */
+/* { dg-final { scan-tree-dump-times \[xy\]\[^ \]* != 0 vrp1 { xfail
powerpc*-*-* } } } */
/* This one needs more copy propagation that only happens in dom1. */
-/* { dg-final { scan-tree-dump-times x\[^ \]* y 1 dom1 } } */
+/* { dg-final { scan-tree-dump-times x\[^ \]* y 1 dom1 { xfail
powerpc*-*-* } } } */
/* { dg-final { scan-tree-dump-times x\[^ \]* y 1 vrp1 { xfail *-*-* } }
} */
/* These two are fully simplified by VRP. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219
[Bug tree-optimization/31677] gcc.dg/memcpy-1.c tree dump scan fails on several targets
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-02-21 01:32 --- Adding --param sra-max-structure-size=32 solves the problem on powerpc-apple-darwin9 at both -m32 and -m64 as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31677
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #101 from dberlin at gcc dot gnu dot org 2009-02-21 04:13 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines PRE already gives up on this testcase, at least on my computer, and takes no memory. All of the memory here is being eaten by IRA and DF. The actual time sink is SCCVN's DFS, which builds a large SCC then counts it's size and gives up (which in turn causes PRE to give up). It's not clear you can really modify this to give up earlier than it does (since you don't know the size of the SCC until it's already done all the work anyway) without a ton of work. I'm replacing this algorithm with a non-SCC based one in 4.5. On Fri, Feb 20, 2009 at 2:52 PM, lucier at math dot purdue dot edu gcc-bugzi...@gcc.gnu.org wrote: --- Comment #98 from lucier at math dot purdue dot edu 2009-02-20 19:52 --- Thank you, that indeed fixes the LICM problem. Based on some comments for this PR and for PR 39157 I thought that a similar patch might apply to PRE. .. I think the -O1 and -O2 limits for LICM are quite reasonable; would it be possible to limit PRE similarly so that one could compile compiler.i with -O2 in a reasonable amount of memory? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug middle-end/38219] gcc.dg/tree-ssa/vrp47.c fails on powerpc
--- Comment #6 from bonzini at gnu dot org 2009-02-21 07:28 --- Subject: Re: gcc.dg/tree-ssa/vrp47.c fails on powerpc I'd rather do so only on the branch when it is created. I'm pretty sure this can be fixed, but it's probably not stage4 stuff. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219
