[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
--- Comment #17 from jakub at gcc dot gnu dot org 2010-03-23 06:48 ---
But clearly it is not var-tracking that eats all the memory, instead it is the
scheduler, and it happens also with -g0, and doesn't happen with
-fno-schedule-insns -fno-schedule-insns2. So, please open a separate bugreport
about it, reopening this one for unrelated reasons will just lead to confusion.
I guess I could add { target { ! ia64-*-* } } as a quick workaround.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
[Bug c++/42556] Unnecessary generation of a zero initializer for array with C++
--- Comment #3 from jiez at gcc dot gnu dot org 2010-03-23 08:55 --- My patch for this bug: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01039.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42556
[Bug debug/42959] g++ does not emit DW_AT_default_value
--- Comment #6 from dodji at gcc dot gnu dot org 2010-03-23 09:33 --- Created an attachment (id=20167) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20167action=view) Draft patch This draft patch emits a DW_AT_GNU_default_value_unrepresentable attribute flag when the default argument value cannot be represented because e.g. it involves temporaries. Tom, if the patch does what you want, I can propose it for discussion/inclusion for GCC 4.6? -- dodji at gcc dot gnu dot org changed: What|Removed |Added Attachment #20107|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42959
[Bug other/43489] New: gcc fails to build
make[3]: Entering directory `/root/src/GNU/unmodified_gnu/gcc-4.4.3/i686-pc-linux-gnu/libgfortran' if /bin/sh ./libtool --tag=CC --mode=compile /root/src/GNU/unmodified_gnu/gcc-4.4.3/host-i686-pc-linux-gnu/gcc/xgcc -B/root/src/GNU/unmodified_gnu/gcc-4.4.3/host-i686-pc-linux-gnu/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../.././libgfortran -I. -iquote../.././libgfortran/io -I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config -I../../host-i686-pc-linux-gnu/gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -MT unix.lo -MD -MP -MF .deps/unix.Tpo -c -o unix.lo `test -f 'io/unix.c' || echo '../.././libgfortran/'`io/unix.c; \ then mv -f .deps/unix.Tpo .deps/unix.Plo; else rm -f .deps/unix.Tpo; exit 1; fi libtool: compile: /root/src/GNU/unmodified_gnu/gcc-4.4.3/host-i686-pc-linux-gnu/gcc/xgcc -B/root/src/GNU/unmodified_gnu/gcc-4.4.3/host-i686-pc-linux-gnu/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../.././libgfortran -I. -iquote../.././libgfortran/io -I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config -I../../host-i686-pc-linux-gnu/gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -MT unix.lo -MD -MP -MF .deps/unix.Tpo -c ../.././libgfortran/io/unix.c -fPIC -DPIC -o .libs/unix.o /usr/include/bits/mathinline.h: Assembler messages: /usr/include/bits/mathinline.h:4848: Error: symbol `fstat64' is already defined /usr/include/bits/mathinline.h:4881: Error: symbol `lstat64' is already defined /usr/include/bits/mathinline.h:4914: Error: symbol `stat64' is already defined make[3]: *** [unix.lo] Error 1 make[3]: Leaving directory `/root/src/GNU/unmodified_gnu/gcc-4.4.3/i686-pc-linux-gnu/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/src/GNU/unmodified_gnu/gcc-4.4.3/i686-pc-linux-gnu/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/root/src/GNU/unmodified_gnu/gcc-4.4.3' make: *** [all] Error 2 OnSight_PC: 10.10.10.16 pwd /root/src/GNU/unmodified_gnu/gcc-4.4.3 OnSight_PC: 10.10.10.16 gcc --version gcc (GCC) 3.2.2 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Summary: gcc fails to build Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jon at jonshouse dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43489
[Bug debug/41130] GCC should emit an index of publicly named entities
--- Comment #14 from dodji at gcc dot gnu dot org 2010-03-23 09:54 --- Not working on this atm. -- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dodji at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
[Bug c/43488] Get compiler internal error with DFP expression
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-23 10:17 --- For which target? What internal error? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43488
[Bug rtl-optimization/43477] -march=k8-sse3 on turion-rm75 failed
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-23 10:24 --- We need a testcase to reproduce the bug (preprocessed source). You also might want to try removing -mcmodel=large (you really shouldn't need that). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43477
[Bug other/43489] gcc fails to build
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-23 10:49 --- That's a bug in your glibc headers, not in gcc. Just use newer glibc. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43489
[Bug c/43490] New: sin(x) (actually probably all trig) is inaccurate for large x
sin(x) (and sinf(x)) *used* to work accurately on earlier gcc versions, e.g. gcc 3.4.6 20060404 (Red Hat 3.4.6-9) ON x86_64-redhat-linux gcc 4.2.1 on Macintosh OR cross compiling for ARM Cortex-A8 with gcc version 4.3.2 BUT sin(x) becomes progressively more inaccurate with increasing magnitude of x, as with the above version (on x86). At a guess, it would seem like something has broken the range reduction maths. (Of course, it could be the source to the maths library that is broken but I can't tell if that is the case or whether it's the compiler that has broken it) Systems that were found to be broken: gcc 4.4.1 (Ubuntu 4.4.1-4ubuntu9) gcc 4.4.3 20100108 (prerelease) (Debian 4.4.2-9) GNU C 4.3.2 (i686-pc-linux-gnu) (Gentoo 4.3.2-r3 p1.6, pie-10.1.5 Build command: gcc -v -save-temps -o simplesintest -g -DDEBUG=1 -DDEBUG_INFO=1 -Wall -W -pedantic -std=c99 simplesintest.c -lm Command line: ./simplesintest Typical output is: = Test 0: sin(43998769152.00) (i.e. sin(0xa3e87f * 2^12)) is computed as -4.081937e-09 (-0x1.188230b6dp-28) It SHOULD be ~ -4.025292e-09 (-0x1.149dafd6b8987p-28) Relative error is 1.407% sinf(43998769152.00) (i.e. sinf(0xa3e87f * 2^12)) is computed as -4.081937e-09 (-0x1.18823p-28) It SHOULD be ~ -4.025292e-09 (-0x1.149dbp-28) Relative error is 1.407% Test 1: sin(9903547467890318699652972544.00) (i.e. sin(0x800017 * 2^70)) is computed as 2.763719e-01 (0x1.1b013a2290cc8p-2) It SHOULD be ~ 2.003433e-01 (0x1.9a4d9074cecaap-3) Relative error is -37.949% sinf(9903547467890318699652972544.00) (i.e. sinf(0x800017 * 2^70)) is computed as 2.763719e-01 (0x1.1b013ap-2) It SHOULD be ~ 2.003433e-01 (0x1.9a4d9p-3) Relative error is -37.949% Test 2: sin(8773115793420245409943394342404096.00) (i.e. sin(0xd84625 * 2^89)) is computed as 7.399661e-01 (0x1.7adcd596e1d56p-1) It SHOULD be ~ 2.044974e-08 (0x1.5f52ea84f120cp-26) Relative error is -3618461696.000% sinf(8773115793420245409943394342404096.00) (i.e. sinf(0xd84625 * 2^89)) is computed as 7.399661e-01 (0x1.7adcd6p-1) It SHOULD be ~ 2.044974e-08 (0x1.5f52eap-26) Relative error is -3618461696.000% Test 3: sin(10633823966279326983230456482242756608.00) (i.e. sin(0x80 * 2^100)) is computed as -7.480374e-01 (-0x1.7efec078c6a44p-1) It SHOULD be ~ -4.205416e-02 (-0x1.5881f6eeb6a8dp-5) Relative error is 1678.748% sinf(10633823966279326983230456482242756608.00) (i.e. sinf(0x80 * 2^100)) is computed as -7.480373e-01 (-0x1.7efecp-1) It SHOULD be ~ -4.205416e-02 (-0x1.5881f6p-5) Relative error is 1678.748% = -- Summary: sin(x) (actually probably all trig) is inaccurate for large x Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: simon dot fenney at imgtec dot com GCC build triplet: ??? GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #1 from simon dot fenney at imgtec dot com 2010-03-23 12:06 --- Created an attachment (id=20168) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20168action=view) Trivial test program that outputs sin(x) and sinf(x) for various vals VS expected results I haven't added tests for cos or tan etc, but I expect they will be broken as well. *My guess* is that the range reduction that gets X down to the equivalent in the range [0, Pi/2] or [0, Pi/4] has broken as the errors get worse with increasing x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #2 from pluto at agmk dot net 2010-03-23 12:08 --- duplicate of PR43405. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug c/43488] Get compiler internal error with DFP expression
--- Comment #2 from tydeman at tybor dot com 2010-03-23 12:08 ---
Host and target info:
CPU: Intel Pentium 4
OS: Linux
Fedora Core 10 with gcc 4.3.2
Fedora Core 11 with gcc 4.4.1
Fedora Core 12 with gcc 4.4.3
Command line options: CFLAGS=-std=gnu99 -pedantic -H -fno-builtin
-frounding-math -DTAILOR ${INCS}
Failure:
test65.c:4: internal compiler error: in decimal_to_decnumber, at dfp.c:114
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43488
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #3 from simon dot fenney at imgtec dot com 2010-03-23 12:20 --- (In reply to comment #2) duplicate of PR43405. It's doesn't seem to be the same. I just tried the test source from 43405 and on the old system (gcc 3.4.6) (which I assumed was working) got: double precision: sin(1e22) = -0.8522008497671888 quad precison: sin(1e22)=0.4626130407646018 while on the systems I was worried about, got double precision: sin(1e22) = 0.4626130407646017 quad precison: sin(1e22)=0.4626130407646018 Using maple and computing the result to 30 decimal places, I get -.852200849767188801772705893753 so it looks like there is an additional problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug c/43488] Get compiler internal error with DFP expression
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-23 12:30 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org Status|WAITING |NEW Ever Confirmed|0 |1 Known to fail||4.2.4 4.3.4 4.4.2 4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-03-23 12:30:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43488
[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls
--- Comment #8 from ktietz at gcc dot gnu dot org 2010-03-23 12:32 --- (In reply to comment #7) An updated patch is at http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00937.html Patch is fine. It is absolutely necessary to support gcc's intrinsic headers for mingw. The fixinclude approach is one way to solve it and I am fine by it. For mingw-w64 we used the #pragma push/pop_macro feature to make sure we declare function without getting problems by this define in ia32intrin.h. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #4 from dominiq at lps dot ens dot fr 2010-03-23 13:00 --- BUT sin(x) becomes progressively more inaccurate with increasing magnitude of x, as with the above version (on x86). At a guess, it would seem like something has broken the range reduction maths. Since pi is irrational, range reduction is inherently broken for large x. Try to compute sin(x) for a large value of x and its nearest values from below and above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #20 from manu at gcc dot gnu dot org 2010-03-23 13:05 --- (In reply to comment #19) I wanted to record my unfinished patch to track macro expansion locations, and this bug seemed like an appropriate place. What is missing from this patch? Is it only the macro location tracked or the parameter expanded within the macro? Does this enable us to track macro expansions like Clang? http://clang.llvm.org/diagnostics.html (search Macro Expansion) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #5 from simon dot fenney at imgtec dot com 2010-03-23 13:10 --- (In reply to comment #4) BUT sin(x) becomes progressively more inaccurate with increasing magnitude of x, as with the above version (on x86). At a guess, it would seem like something has broken the range reduction maths. Since pi is irrational, range reduction is inherently broken for large x. Try to compute sin(x) for a large value of x and its nearest values from below and above. Yes, I am aware of that, but the *standard* seems to be to assume that the source value is accurate, compute the range reduced result to sufficient precision, and then compute sine/cosine to the required ULP accuracy. (e.g. see Payne-Hanek reduction algorithm or any of the newer methods such as ftp://ftp.inria.fr/INRIA/publication/dienst/RR-4267.pdf). It was working on earlier incarnations so is frustrating that it's now broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #6 from pluto at agmk dot net 2010-03-23 13:17 --- (In reply to comment #3) (In reply to comment #2) duplicate of PR43405. Using maple and computing the result to 30 decimal places, I get -.852200849767188801772705893753 so it looks like there is an additional problem. you can test two different implementations: 1). '-O2 -m32 -fno-builtin' - force libm.so calls and test libc implementation. 2). '-O2 -m32' to test gcc compile-time evaluation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug rtl-optimization/43471] Unnecessary reload of asm m operand address
--- Comment #4 from rearnsha at gcc dot gnu dot org 2010-03-23 13:18 --- This second example clearly has nothing to do with the stated bug report summary line (there's no m constraint anywhere in the test case), and you make no attempt to explain what you think is wrong. Please see the pages on reporting bugs and make sure you provide sufficient details for a developer to both *understand* and *replicate* the problem you are having. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43471
[Bug rtl-optimization/43473] hword size destination variable induces suboptimal code generation compared to full word size var
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-03-23 13:21 --- You haven't explained what you think is wrong, and you haven't even said what options you used to generated the code. If the optimizer is not on the generated code *will* be very poor. That's why we have an optimizer. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43473
[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls
--- Comment #9 from hjl at gcc dot gnu dot org 2010-03-23 13:24 --- Subject: Bug 40722 Author: hjl Date: Tue Mar 23 13:24:37 2010 New Revision: 157665 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157665 Log: Fix stdlib.h for mingw. 2010-03-23 H.J. Lu hongjiu...@intel.com PR target/40722 * mkfixinc.sh: Fix stdlib.h for mingw. Modified: trunk/fixincludes/ChangeLog trunk/fixincludes/mkfixinc.sh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-23 13:28 --- This is a glibc problem. Confirmed by LD_PRELOADing a different libm which makes it work. Please report to glibc bugzilla instead. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #8 from simon dot fenney at imgtec dot com 2010-03-23 13:37 --- (In reply to comment #6) you can test two different implementations: 1). '-O2 -m32 -fno-builtin' - force libm.so calls and test libc implementation. 2). '-O2 -m32' to test gcc compile-time evaluation. FWIW I've just tried gcc -o simplesintest -Wall -W -pedantic -std=c99 simplesintest.c -O2 -m32 -fno-builtin -lm and gcc -o simplesintest -Wall -W -pedantic -std=c99 simplesintest.c -O2 -m32 -lm and they've made no difference :-| -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug debug/19192] [4.3/4.4/4.5 Regression] Current development gcc generates inaccurate line info for example code
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-03-23 13:37
---
Unassinging Andrew. Raising priority to P2.
At -O2 we now optimize main () to
main ()
{
bb 2:
# DEBUG a = 2
# DEBUG b = 3
# DEBUG c = 4
# DEBUG a = 3
# DEBUG b = 4
[t.c : 13:22] printf ([t.c : 13] [t.c : 13] %d\n[0], 9); [tail call]
[t.c : 14:13] return;
}
at -O1 we get
bb 2:
# DEBUG a = 2
# DEBUG b = 3
# DEBUG c = 4
[t.c : 8:32] D.2741_4 = add2 (3, 4);
[t.c : 8:15] D.2740_5 = D.2741_4 + 2;
[t.c : 13:22] printf ([t.c : 13] [t.c : 13] %d\n[0], D.2740_5);
[t.c : 14:13] return;
which seems to be close to the reported case. the + 2 has line 8 and thus
is ok before TER. We still expand to
(insn 12 11 13 t.c:13 (parallel [
(set (reg:SI 61)
(plus:SI (reg:SI 58 [ D.2741 ])
(const_int 2 [0x2])))
(clobber (reg:CC 17 flags))
]) -1 (nil))
(insn 13 12 14 t.c:13 (set (reg:SI 4 si)
(reg:SI 61)) -1 (nil))
(insn 14 13 15 t.c:13 (set (reg:DI 5 di)
(symbol_ref/f:DI (*.LC0) [flags 0x2] string_cst 0x75b36820)) -1
(nil))
(insn 15 14 16 t.c:13 (set (reg:QI 0 ax)
(const_int 0 [0x0])) -1 (nil))
(call_insn 16 15 0 t.c:13 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI (printf) [flags 0x41] function_decl
0x77efc000 printf) [0 S1 A8])
(const_int 0 [0x0]))) -1 (nil)
(expr_list:REG_DEP_TRUE (use (reg:QI 0 ax))
(expr_list:REG_DEP_TRUE (use (reg:DI 5 di))
thus expanding a TERd expression does not properly reset location infromation.
CC'ing Micha.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|amacleod at redhat dot com |unassigned at gcc dot gnu
||dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug target/43358] [4.5 Regression] IRA: internal compiler error: in pool_free, at alloc-pool.c:335
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-23 13:39 --- CCing mips maintainer -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rdsandiford at googlemail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43358
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-23 13:39 --- David? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug target/43469] [4.5 Regression] ICE trying to compile glibc for ARM thumb2
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-23 13:41 --- Not exactly a primary or secondary target. CCing maintainer. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43469
[Bug target/43484] [4.5 Regression] GCC 4.5 does not build gamess, zeusmp on powerpc -m32 with loop unrolling
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|rtl-optimization|target Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43484
[Bug rtl-optimization/43471] Unnecessary reload of asm m operand address
--- Comment #5 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-23 14:04 --- The problem is that gcc sometimes emits instructions that are copying the global r4 (even when it's marked as const) into temporary. Originally I thought that the simplies case was this asm statememt, but it looks like it depends on having adress of a structure field taken as a parameter for a function that's later inlined. I'll file a new report with the second example and this explanation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43471
[Bug target/43469] [4.5 Regression] ICE trying to compile glibc for ARM thumb2
--- Comment #5 from tschwinge at gcc dot gnu dot org 2010-03-23 14:14 --- Also got hit by this. -- tschwinge at gcc dot gnu dot org changed: What|Removed |Added CC||tschwinge at gcc dot gnu dot ||org Last reconfirmed|2010-03-22 08:56:27 |2010-03-23 14:14:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43469
[Bug rtl-optimization/43491] New: Unnecessary temporary for global register variable
gcc sometimes allocates a temporary register for a variable that is global and
has a fixed register. This happens when:
a. the global is a register-fixed variable
b. global is a pointer to structure
c. an address of structure's field is passed as argument to inlined function
d. the global is marked as constant
code:
struct b {
unsigned g,h,j;
};
register struct b *const reg asm(r4);
static inline int diff(unsigned *p)
{
return *p;
}
void c(void);
void d(void)
{
while (diff(reg-j))
c();
}
generates:
d:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
ldr r3, [r4, #8]@ first ok
push{r5, lr}
mov r5, r4 @ an temporary even when r4 is marked const
cbz r3, .L1
.L4:
bl c
ldr r3, [r5, #8]@ accesses via temporary
cmp r3, #0
bne .L4
.L1:
pop {r5, pc}
--
Summary: Unnecessary temporary for global register variable
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mirq-gccboogs at rere dot qmqm dot pl
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491
[Bug rtl-optimization/43473] hword size destination variable induces suboptimal code generation compared to full word size var
--- Comment #2 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-23 14:37 --- Sorry, I try to split encountered problems into simple testcases and after a few I forgot to add the common things to bugreports. The difference between ma() and mb() in the example is a global's size: ma(): - unsigned short global, generates two insns for the operation: ldrhr2, [r3, #0] mvn r2, r2, asl #18 mvn r2, r2, lsr #18 strhr2, [r3, #0]@ movhi mb(): - unsigned int global, generates one insn for the same operation: ldr r2, [r3, #0] orr r2, r2, #49152 str r2, [r3, #0] 'u' and 'd' are compile time constants. compiled with: arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -O3 -S a.c $ LANG=C arm-none-eabi-gcc -v Using built-in specs. COLLECT_GCC=/usr/src/gcc-armtest/bin/arm-none-eabi-gcc COLLECT_LTO_WRAPPER=/usr/src/gcc-armtest/libexec/gcc/arm-none-eabi/4.5.0/lto-wrapper Target: arm-none-eabi Configured with: ../gcc-combined/configure --with-newlib --prefix=/usr/src/gcc-armtest --target arm-none-eabi --enable-languages=c --disable-libssp Thread model: single gcc version 4.5.0 20100319 (experimental) (GCC) $ LANG=C svn info Path: . URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 157582 Node Kind: directory Schedule: normal Last Changed Author: bernds Last Changed Rev: 157582 Last Changed Date: 2010-03-19 19:41:22 +0100 (Fri, 19 Mar 2010) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43473
[Bug target/43484] [4.5 Regression] GCC 4.5 does not build gamess, zeusmp on powerpc -m32 with loop unrolling
--- Comment #6 from meissner at gcc dot gnu dot org 2010-03-23 15:10 --- The rs6000 change on 2010-03-17 is the culprit. If I do a svn update for the sandbox, and then do: $ svn update -r157529 gcc/config/rs6000 There is no error. -- meissner at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bergner at vnet dot ibm dot |dot org |com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-23 15:10:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43484
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #21 from tromey at gcc dot gnu dot org 2010-03-23 15:19 --- What is missing from this patch? Is it only the macro location tracked or the parameter expanded within the macro? The biggest problem with the patch is that I didn't finish debugging it. It causes regressions of various kinds -- it is pretty buggy. There are a few FIXME comments marking known bad spots. It tracks the full location of each token. So, if a given token resulted from a macro expansion, you can determine the token's location from before the macro expansion (which might come from another macro expansion, or a macro definition, or be an argument to a macro invocation). It doesn't currently handle the original location of tokens arising from stringizing or pasting. Does this enable us to track macro expansions like Clang? Yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug debug/19192] [4.3/4.4/4.5 Regression] Current development gcc generates inaccurate line info for example code
--- Comment #12 from jakub at gcc dot gnu dot org 2010-03-23 15:22 ---
Thus we are talking about:
extern int printf (const char *, ...);
__attribute__((noinline))
int add2 (int a, int b)
{
return a + b;
}
static inline int add3 (int a, int b, int c)
{
return a + add2 (b, c);
}
int
main ()
{
printf (%d\n, add3 (2, 3, 4));
return 0;
}
right? Seems get_gimple_for_ssa_name indeed provides correct location on the
created trees, it is just that the expansion ignores it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug debug/19192] [4.3/4.4/4.5 Regression] Current development gcc generates inaccurate line info for example code
--- Comment #13 from jakub at gcc dot gnu dot org 2010-03-23 15:56 --- Created an attachment (id=20169) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20169action=view) gcc45-pr19192.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug target/43484] [4.5 Regression] GCC 4.5 does not build gamess, zeusmp on powerpc -m32 with loop unrolling
--- Comment #7 from meissner at gcc dot gnu dot org 2010-03-23 16:10 --- I forgot Peter was on vacation. I'll take it. -- meissner at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|bergner at vnet dot ibm dot |meissner at gcc dot gnu dot |com |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43484
[Bug debug/42959] g++ does not emit DW_AT_default_value
--- Comment #7 from tromey at gcc dot gnu dot org 2010-03-23 16:11 --- In the case where the default value is an expression, would it be possible to just emit the expression as a string? I believe that would be sufficient for gdb's purposes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42959
[Bug debug/19192] [4.3/4.4/4.5 Regression] Current development gcc generates inaccurate line info for example code
--- Comment #14 from matz at gcc dot gnu dot org 2010-03-23 16:16 --- Simply replace the recursive call to expand_expr_real_1 with a call to expand_expr_real. That's the wrapper setting locations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug debug/19192] [4.3/4.4/4.5 Regression] Current development gcc generates inaccurate line info for example code
--- Comment #15 from jakub at gcc dot gnu dot org 2010-03-23 16:17 --- Created an attachment (id=20170) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20170action=view) gcc45-pr19192.patch Updated patch that also fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43479#c1 testcase. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #20169|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug debug/19192] [4.3/4.4/4.5 Regression] Current development gcc generates inaccurate line info for example code
--- Comment #16 from jakub at gcc dot gnu dot org 2010-03-23 16:19 --- Actually it is not, it restores neither curr_insn_block or curr_insn_source_location. Perhaps the fix would be to fix that function though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug rtl-optimization/43477] -march=k8-sse3 on turion-rm75 failed
--- Comment #3 from aflyhorse at foxmail dot com 2010-03-23 16:30 --- (In reply to comment #2) We need a testcase to reproduce the bug (preprocessed source). You also might want to try removing -mcmodel=large (you really shouldn't need that). I've tryed to remove all newly added optimize option seperately, and only remove the -mcmodel doesn't work. The resolving way is to remove all the options concerning sse3 (including -march=k8-sse3 -mtune=k8-sse3 -Wa,march=k8+sse3; use -march=k8 and -nsse3 produce the same error). I am building binutils (SVN 20100317) at that time. I have tried various way of CCFLAGS struggling to avoid this problem. In addition, file: /libcpp/files.c: Line 609-614: comparison is always false under win x64 and /gcc/emit-rtl.c: Line 361: /gcc/ggc-common.c: Line 310: /gcc/graphite-dependences.c: Line 107: /gcc/src/gcc/ira-conflicts.c: Line 125: /gcc/src/gcc/pointer-set.c: Line 67: /gcc/src/gcc/tree dump: Line 168: /gcc/src/gcc/cp/class.c: Line 6740, 6742, 6764, 6767, 6900: all have host-dependent code such as explictly cast a pointer to long (in win x64 means long long to long) and use %ld or lx to fprintf a pointer. they cause the cc1 treat warnings as error and stop the make procedure, though they are easy to fix manually but quite annoying while making bootstrap. (These are gcc 4.5.0 20100322 version source) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43477
[Bug debug/19192] [4.3/4.4/4.5 Regression] Current development gcc generates inaccurate line info for example code
--- Comment #17 from jakub at gcc dot gnu dot org 2010-03-23 16:37 --- Created an attachment (id=20171) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20171action=view) gcc45-pr19192.patch Patch that does that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug debug/19192] [4.3/4.4/4.5 Regression] Current development gcc generates inaccurate line info for example code
--- Comment #18 from matz at gcc dot gnu dot org 2010-03-23 16:46 --- It should mostly not matter anymore as expand_expr_real_[12] and friends use an explicit location parameter, stored away before expanding operands. But to be safe, yes, expand_expr_real() should instead also restore the old location. You don't need to check for NULL gimple_block(), set_curr_insn_block does that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug fortran/43492] New: f951: internal compiler error: in gfc_add_component_ref, at fortran/expr.c:352
Hi, The attached code produces the subject error. [sfili...@donald bug14]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnudev/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran : (reconfigured) ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.5.0 20100320 (experimental) (GCC) [sfili...@donald bug14]$ gfortran -c psb_base_mat_mod.f03 f951: internal compiler error: in gfc_add_component_ref, at fortran/expr.c:352 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: f951: internal compiler error: in gfc_add_component_ref, at fortran/expr.c:352 Product: gcc Version: fortran-dev Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43492
[Bug fortran/43492] f951: internal compiler error: in gfc_add_component_ref, at fortran/expr.c:352
--- Comment #1 from sfilippone at uniroma2 dot it 2010-03-23 17:10 --- Created an attachment (id=20172) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20172action=view) test case If I switch the comments on lines 27-28 the code compiles, i.e. it is the GENERIC interface that is not resolved correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43492
[Bug debug/43479] Missing DW_TAG_lexical_block+DW_TAG_variable
--- Comment #3 from jakub at gcc dot gnu dot org 2010-03-23 17:24 ---
Created an attachment (id=20173)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20173action=view)
gcc45-pr43479-test.patch
This testcase is fixed on x86_64-linux by the PR19192 proposed patch (second or
third).
Unfortunately it still fails on i686-linux. DEBUG_INSNs look sane in
*.asmcons:
(debug_insn 9 6 10 2 pr43479.c:8 (var_location:SI l (plus:SI (reg/v:SI 62 [ l
])
(const_int 1 [0x1]))) -1 (nil))
(debug_insn 10 9 11 2 pr43479.c:10 (var_location:SI h (reg/v:SI 64 [ n ])) -1
(nil))
(debug_insn 11 10 12 2 pr43479.c:12 (var_location:SI i (reg/v:SI 61 [ k ])) -1
(nil))
(debug_insn 12 11 13 2 pr43479.c:13 (var_location:SI k (plus:SI (reg/v:SI 61 [
k ])
(const_int 1 [0x1]))) -1 (nil))
(debug_insn 13 12 14 2 pr43479.c:17 (var_location:SI j (reg/v:SI 63 [ m ])) -1
(nil))
(debug_insn 14 13 15 2 pr43479.c:18 (var_location:SI m (plus:SI (reg/v:SI 63 [
m ])
(const_int 1 [0x1]))) -1 (nil))
where all the pseudos are initialized like:
(insn 3 2 4 2 pr43479.c:7 (set (reg/v:SI 62 [ l ])
(mem/c/i:SI (plus:SI (reg/f:SI 16 argp)
(const_int 4 [0x4])) [0 l+0 S4 A32])) 47 {*movsi_1}
(expr_list:REG_EQUIV (mem/c/i:SI (plus:SI (reg/f:SI 16 argp)
(const_int 4 [0x4])) [0 l+0 S4 A32])
(nil)))
But in *.ira dump all 4 debug_insns are clobber (const_int 0), likely reload
doesn't figure out that it could use REG_EQUIV...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43479
[Bug c++/43493] New: exception ignores catch-clause when std::ostringstream helps in throwing
See following code snippet; when the MY_THROW macro is changed to
do { throw ::my_error( MeSSaGe ); } while( 1 )
then I get the expected result, i.e. invocation of the executable prints error
foo and returns 1 to the shell... This is on an i7 iMac with Mac OS X 10.6.2
with 64bit Kernel and current GCC 4.4.3 from MacPorts.
co...@tigger:/tmp cat debug.cc
#include sstream
#include iostream
#include stdexcept
struct my_error
: public std::runtime_error
{
explicit
my_error( const std::string message )
: std::runtime_error( message )
{ }
};
#define MY_THROW( MeSSaGe ) \
do { std::ostringstream oss; oss MeSSaGe; throw ::my_error( oss.str() );
} while( 1 )
template typename T
bool throwing( const T )
{
MY_THROW( foo );
}
int main()
{
try {
throwing( 42.0 );
}
catch ( const ::my_error e ) {
std::cerr error e.what() \n;
return 1;
}
return 0;
}
co...@tigger:/tmp g++-mp-4.4 -Iinclude -std=c++0x -pedantic -Wall -Wextra -O3
-m64 -march=native debug.cc -o debug
co...@tigger:/tmp ./debug
Abort trap
co...@tigger:/tmp g++-mp-4.4 --version
g++-mp-4.4 (GCC) 4.4.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
co...@tigger:/tmp g++-mp-4.4 -v
Using built-in specs.
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.4.3/configure --prefix=/opt/local
--build=x86_64-apple-darwin10
--enable-languages=c,c++,objc,obj-c++,java,fortran
--libdir=/opt/local/lib/gcc44 --includedir=/opt/local/include/gcc44
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-4.4 --with-gxx-include-dir=/opt/local/include/gcc44/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --enable-stage1-checking
Thread model: posix
gcc version 4.4.3 (GCC)
co...@tigger:/tmp
--
Summary: exception ignores catch-clause when std::ostringstream
helps in throwing
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at cohi dot at
GCC host triplet: 86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43493
[Bug c/43494] New: gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
When running the testsuite on ia64-unknown-linux-gnu with extra passes containing -fpic/-fPIC I get the following additional error on the 4.4 branch: FAIL: gcc.c-torture/execute/vector-2.c execution, -O2 FAIL: gcc.c-torture/execute/vector-2.c execution, -Os on 4.5 trunk I get: FAIL: gcc.c-torture/execute/vector-2.c execution, -O2 -- Summary: gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug rtl-optimization/43413] Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used
--- Comment #9 from law at redhat dot com 2010-03-23 17:36 --- Subject: Re: Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used On 03/22/10 16:20, vmakarov at redhat dot com wrote: --- Comment #6 from vmakarov at redhat dot com 2010-03-22 22:20 --- (In reply to comment #4) FWIW, I seem to get considerably worse code from mainline than you -- for -O3 -ffast-math -mcpu=power7 -mvsx -maltivec I get 140 stfs and 192 lfs insns (compared to 117 139 respectively that you reported). I suspect the differnce is because Mike calculated only stfs/lfs and you stfs(x)/lfs(x). But may be I am wrong. I think you're right. I get 117/144 for the mainline now (compared to 117/139 in the PR), so those are in the right ballpark. With the LRS bits I get 110/130, which is a clear improvement, but still nowhere near good. Just for fun, I ran the same code through the a ppc compiler with the LRS code from reload-v2 and get 133:178 stfs/lsf insns, so that code clearly is helping, but it's not enough to offset the badness shown by IRA. I couldn't reconcile how -fno-ira-share-spill-slots would be changing the number of load/store insns, so I poked at that a bit. Yes, I cannot understand that too. Given how -fno-ira-share-spill-slots twiddles the bitmaps in the reload chains, it's got to either be reload register selection or reallocation occuring during reload. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43413
[Bug c/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
--- Comment #1 from ghazi at gcc dot gnu dot org 2010-03-23 17:36 --- 4.4.4 ia64 results with error: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01631.html 4.5.0 ia64 results with error: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01997.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.4 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug target/43493] exception ignores catch-clause when std::ostringstream helps in throwing
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-23 17:37 --- Most likely related to PR 43277. I want to say Darwin10's unwinder is broken ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Keywords||EH, wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43493
[Bug c/43495] New: [4.5 regression] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC
When running the testsuite on ia64-unknown-linux-gnu with extra passes containing -fpic/-fPIC I get the following additional error on the 4.5 trunk: FAIL: gcc.c-torture/execute/2603-1.c execution, -O2 FAIL: gcc.c-torture/execute/2603-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/2603-1.c execution, -O3 -g FAIL: gcc.c-torture/execute/2603-1.c execution, -Os This is a regressions from previous releases. Testsuite results showing the extra error: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01997.html -- Summary: [4.5 regression] gcc.c-torture/execute/2603-1.c fails with -fpic/-fPIC Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43495
[Bug debug/43479] Missing DW_TAG_lexical_block+DW_TAG_variable
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-23 17:54 --- It is update_equiv_regs that does this. Will look into it tomorrow. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-23 17:54:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43479
[Bug fortran/43492] f951: internal compiler error: in gfc_add_component_ref, at fortran/expr.c:352
--- Comment #2 from sfilippone at uniroma2 dot it 2010-03-23 18:01 --- Forgot to highlight that this only applies to fortran-dev branch, with a fresh 4.5 build it compiles cleanly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43492
[Bug c/43496] New: gcc.target/powerpc/gcse-1.c fails on powerpc-unknown-linux-gnu with -fpic/-fPIC
When running the testsuite on powerpc-unknown-linux-gnu with extra passes containing -fpic/-fPIC I get the following additional error: FAIL: gcc.target/powerpc/gcse-1.c scan-assembler-times @ha 1 The error happens on the 4.3/4.4 branches and 4.5 trunk: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01996.html http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01913.html http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01630.html The pattern @ha appears zero times in the pic assembler output. I don't speak ppc, so is this expected or is it a GCC bug? -- Summary: gcc.target/powerpc/gcse-1.c fails on powerpc-unknown- linux-gnu with -fpic/-fPIC Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43496
[Bug testsuite/43496] gcc.target/powerpc/gcse-1.c fails on powerpc-unknown-linux-gnu with -fpic/-fPIC
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-23 18:20 --- I don't speak ppc, so is this expected or is it a GCC bug? The testcase just needs to be changed for -fPIC/-fpic really, maybe just skipped. The @ha means taking the high part of the address for relocations. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |testsuite Known to fail|4.3.5 4.4.4 4.5.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43496
[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-23 18:22 --- This sounds like an aliasing issue which is only exposed on ia64. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |rtl-optimization Keywords||alias, wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug pch/43497] New: gcc.dg/pch/static-1.c and gcc.dg/pch/static-2.c fail on powerpc-unknown-linux-gnu with -fPIC
When running the testsuite on powerpc-unknown-linux-gnu with extra passes containing -fPIC I get the following additional error on the 4.3 branch: FAIL: gcc.dg/pch/static-1.c -O0 -g assembly comparison FAIL: gcc.dg/pch/static-1.c -O0 assembly comparison FAIL: gcc.dg/pch/static-2.c -O0 -g assembly comparison FAIL: gcc.dg/pch/static-2.c -O0 assembly comparison Testsuite results: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01996.html The error does NOT occur with -fpic. Only -fPIC triggers it. Later versions (4.4 branch or 4.5 trunk) also do NOT show this error. -- Summary: gcc.dg/pch/static-1.c and gcc.dg/pch/static-2.c fail on powerpc-unknown-linux-gnu with -fPIC Product: gcc Version: 4.3.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43497
[Bug pch/43497] gcc.dg/pch/static-1.c and gcc.dg/pch/static-2.c fail on powerpc-unknown-linux-gnu with -fPIC
--- Comment #1 from ghazi at gcc dot gnu dot org 2010-03-23 18:39 --- The -O0 vs -O0 -g diffs appear to be the same except for line number changes. So here is just the -O0 -g diffs for both testcases: line #69 .LCL1: .LCL0: line #70 .long .LCTOC1-.LCF1 .long .LCTOC1-.LCF0 line #88 bcl 20,31,.LCF1 bcl 20,31,.LCF0 line #89 .LCF1: .LCF0: line #91 lwz 0,.LCL1-.LCF1(30) lwz 0,.LCL0-.LCF0(30) FAIL: gcc.dg/pch/static-1.c -O0 -g assembly comparison line #70 .LCL1: .LCL0: line #71 .long .LCTOC1-.LCF1 .long .LCTOC1-.LCF0 line #89 bcl 20,31,.LCF1 bcl 20,31,.LCF0 line #90 .LCF1: .LCF0: line #92 lwz 0,.LCL1-.LCF1(30) lwz 0,.LCL0-.LCF0(30) FAIL: gcc.dg/pch/static-2.c -O0 -g assembly comparison -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.5 Known to work||4.4.4 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43497
[Bug c++/43498] New: -fasynchronous-unwind-tables does not seem to do anything
I have compiled various C and C++ source files in attempt to generate async
unwind tables for better stack trace accuracy with asynchronous signals, adding
-fasynchronous-unwind-tables to compile options. I have so far been completely
unable to come up with any example where the option would produce any
difference in the generated binaries, and unwind tables (.eh_frame)
specifically.
For example please compile the following source file foo.cc:
struct A1 { virtual ~A1(); virtual double foo(void); };
struct A2 { virtual ~A2(); virtual double bar(void); };
struct B : A1, A2 { ~B(); virtual double foo(void); };
A1::~A1() {}
double A1::foo() { return 3.14; }
A2::~A2() {}
double A2::bar() { return 2.17; }
B::~B() {}
double B::foo() { return A1::foo() + A2::bar(); }
with and without -fasynchronous-unwind-tables:
c++ -fasynchronous-unwind-tables -O2 -fPIC -W -Wall -shared -o libfooa.so
foo.cc
c++ -O2 -fPIC -W -Wall -shared -o libfoob.so foo.cc
then compare unwind information:
for x in a b; do
objdump -w -x -d libfoo$x.so foo$x-disasm.txt
readelf -Wa --debug=frames libfoo$x.so foo$x-info.txt
done
diff -u foo{a,b}-disasm.txt
--- fooa-disasm.txt 2010-03-23 18:28:46.0 +0100
+++ foob-disasm.txt 2010-03-23 18:28:46.0 +0100
@@ -1,6 +1,6 @@
-libfooa.so: file format elf64-x86-64
-libfooa.so
+libfoob.so: file format elf64-x86-64
+libfoob.so
architecture: i386:x86-64, flags 0x0150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x0c90
diff -u foo{a,b}-info.txt
(no output)
note that there is basically no difference at all, and there is
no unwind info for the thunks, disassembly has:
0df0 _ZN1B3fooEv:
df0: 53 push %rbx
df1: 48 89 fbmov%rdi,%rbx
df4: 48 83 c3 08 add$0x8,%rbx
df8: 48 83 ec 10 sub$0x10,%rsp
dfc: e8 7f fe ff ff callq c80 _zn2a13fo...@plt
e01: 48 89 dfmov%rbx,%rdi
e04: f2 0f 11 44 24 08 movsd %xmm0,0x8(%rsp)
e0a: e8 41 fe ff ff callq c50 _zn2a23ba...@plt
e0f: f2 0f 58 44 24 08 addsd 0x8(%rsp),%xmm0
e15: f2 0f 11 44 24 08 movsd %xmm0,0x8(%rsp)
e1b: 48 83 c4 10 add$0x10,%rsp
e1f: 5b pop%rbx
e20: c3 retq
e21: 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00nopw
%cs:0x0(%rax,%rax,1)
0e30 _ZThn8_N1BD1Ev:
e30: 48 83 c7 f8 add$0xfff8,%rdi
e34: eb 0a jmpe40 _ZN1BD1Ev
e36: 66 2e 0f 1f 84 00 00 00 00 00 nopw %cs:0x0(%rax,%rax,1)
0e40 _ZN1BD1Ev:
e40: 48 89 6c 24 f8 mov%rbp,-0x8(%rsp)
e45: 48 89 5c 24 f0 mov%rbx,-0x10(%rsp)
e4a: 48 83 ec 18 sub$0x18,%rsp
[snip]
and unwind info has a gap at 0xe30, the thunk, and does not describe
the epilogue at address 0xe1b:
00b0 001c 00b4 FDE cie= pc=0df0..0e21
Augmentation data: 00 00 00 00
DW_CFA_advance_loc: 1 to 0df1
DW_CFA_def_cfa_offset: 16
DW_CFA_offset: r3 (rbx) at cfa-16
DW_CFA_advance_loc: 11 to 0dfc
DW_CFA_def_cfa_offset: 32
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
00d0 001c 00d4 FDE cie= pc=0e40..0e99
Augmentation data: 83 00 00 00
DW_CFA_advance_loc: 14 to 0e4e
DW_CFA_def_cfa_offset: 32
DW_CFA_offset: r3 (rbx) at cfa-24
DW_CFA_offset: r6 (rbp) at cfa-16
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
I believe the part about missing unwind info for epilogues is a known problem
and patches have been committed to the head. Similarly lack of unwind
information for global ctors and dtors seems to be known. But how about the
missing unwind information for the thunks?
More exactly where should I expect the -fasynchronous-unwind-tables option to
make a difference? Any example code / output available?
The compiler is GCC 4.3.4 with binutils 2.19.1 on RHEL5-derived system.
$ c++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure
--prefix=/build/3jm/slc5_amd64_gcc434/external/gcc/4.3.4
--enable-languages=c,c++,fortran
--with-gmp=/build/3jm/slc5_amd64_gcc434/external/gcc/4.3.4/tmp/gmp
--with-mpfr=/build/3jm/slc5_amd64_gcc434/external/gcc/4.3.4/tmp/mpfr
--enable-shared
Thread model: posix
gcc version 4.3.4 (GCC)
$ as -v /dev/null
GNU assembler version 2.19.1 (x86_64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.19.1
$ ld -v
GNU ld (GNU Binutils) 2.19.1
--
[Bug rtl-optimization/43413] Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used
--- Comment #10 from vmakarov at redhat dot com 2010-03-23 18:45 --- (In reply to comment #5) Still I'll investigate a bit more why there are a lot of unexpected spills during assignment with -mvsx for the current code. The problem is in that part of VSX_REGS (altivec regs) does not contain values of SFmode. The coloring algorithm does not take it into account. The problem can be solved if we check this in available register calculation. The patch I will send soon decreases # stfs(x)/lfs(x) from 332 to 246. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43413
[Bug c++/43498] -fasynchronous-unwind-tables does not seem to do anything
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-23 18:47 --- -fasynchronous-unwind-tables is the default on x86_64. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug c++/43498] -fasynchronous-unwind-tables does not seem to do anything
--- Comment #2 from lat at cern dot ch 2010-03-23 18:52 --- Created an attachment (id=20174) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20174action=view) Random C source file for testing Random C source file for additional testing. Compile on Linux with and without -fasynchronous-unwind-tables, with normal compile gcc -g -std=gnu99 -W -Wall -O2 islocal.c -o islocal. No difference in readelf --debug=frames output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug c++/43498] -fasynchronous-unwind-tables does not seem to do anything
--- Comment #3 from lat at cern dot ch 2010-03-23 18:54 --- Ah, that would explain it. Does it mean that all omissions and inaccuracies in unwind information are bugs? Like the lack of unwind info for thunks? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug middle-end/43498] -fasynchronous-unwind-tables does not seem to do anything
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-23 18:56 --- (In reply to comment #3) Ah, that would explain it. Does it mean that all omissions and inaccuracies in unwind information are bugs? Like the lack of unwind info for thunks? yes thunks should have unwind tables also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug libgomp/43499] New: libgomp.fortran/appendix-a/a.22.7.f90 and libgomp.fortran/omp_parse3.f90 fail on powerpc-unknown-linux-gnu with -fpic
When running the testsuite on powerpc-unknown-linux-gnu with extra passes containing -fpic I get the following additional error on the 4.3 branch: Running target unix/-fpic FAIL: libgomp.fortran/appendix-a/a.22.7.f90 -Os (test for excess errors) UNRESOLVED: libgomp.fortran/appendix-a/a.22.7.f90 -Os compilation failed to produce executable FAIL: libgomp.fortran/omp_parse3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) UNRESOLVED: libgomp.fortran/omp_parse3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions compilation failed to produce executable It only triggers with -fpic, -fPIC does not trigger. The error only occurs on the 4.3 branch, later versions (4.4 branch and 4.5 trunk) do not show the error. Testsuite results showing the error: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01996.html The gcc.log file shows this message for both failures: /usr/bin/ld: BFD 2.17 Debian GNU/Linux internal error, aborting at ../../bfd/elf32-ppc.c line 6071 in ppc_elf_relocate_section /usr/bin/ld: Please report this bug. While binutils ld shouldn't crash, I think we should see if GCC is producing erroneous output too. -- Summary: libgomp.fortran/appendix-a/a.22.7.f90 and libgomp.fortran/omp_parse3.f90 fail on powerpc-unknown- linux-gnu with -fpic Product: gcc Version: 4.3.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43499
[Bug middle-end/43498] -fasynchronous-unwind-tables does not seem to do anything
--- Comment #5 from lat at cern dot ch 2010-03-23 18:58 --- OK, reopening bug then. -- lat at cern dot ch changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug libgomp/43499] libgomp.fortran/appendix-a/a.22.7.f90 and libgomp.fortran/omp_parse3.f90 fail on powerpc-unknown-linux-gnu with -fpic
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-23 19:00 --- BFD 2.17 Considering this is an old version of binutils, it might be a bug in binutils. Since this is openmp code, I would not doubt it is related to TLS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43499
[Bug libgomp/43499] libgomp.fortran/appendix-a/a.22.7.f90 and libgomp.fortran/omp_parse3.f90 fail on powerpc-unknown-linux-gnu with -fpic
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-23 19:02 --- And most likely fixed by: http://sourceware.org/ml/binutils/2008-11/msg00240.html :) Which is talking about TLS and the different models which gets changed by -fPIC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43499
[Bug middle-end/43498] No unwind info for thunks even with -fasynchronous-unwind-tables
--- Comment #6 from lat at cern dot ch 2010-03-23 19:04 --- Changing subject to be more descriptive of the actual bug. -- lat at cern dot ch changed: What|Removed |Added Summary|-fasynchronous-unwind-tables|No unwind info for thunks |does not seem to do anything|even with -fasynchronous- ||unwind-tables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug c/43495] [4.5 regression] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC
--- Comment #1 from ghazi at gcc dot gnu dot org 2010-03-23 19:05 --- Testcase also fails on powerpc-unknown-linux-gnu with -fpic/-fPIC: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01630.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|ia64-unknown-linux-gnu |ia64-unknown-linux-gnu ||powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43495
[Bug other/43357] fixincludes/tests/base/iso/math_c99.h check fails
--- Comment #2 from zsojka at seznam dot cz 2010-03-23 19:06 --- I can't reproduce it anymore in r157675 with x86_64, probably fixed by r157573: http://gcc.gnu.org/viewcvs?view=revisionrevision=157573 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43357
[Bug target/43498] No unwind info for thunks even with -fasynchronous-unwind-tables
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-23 19:13 --- The x86-64 target writes directly out asm rather than going through some RTL code which causes unwind tables not to be written out for the thunks. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-23 19:13:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug rtl-optimization/43413] Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used
--- Comment #11 from vmakarov at gcc dot gnu dot org 2010-03-23 19:19 --- Subject: Bug 43413 Author: vmakarov Date: Tue Mar 23 19:18:42 2010 New Revision: 157676 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157676 Log: 2010-03-23 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/43413 * ira-color.c (setup_allocno_available_regs_num): Count prohibited hard regs too. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-color.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43413
[Bug middle-end/43500] New: gcc.c-torture/execute/va-arg-trap-1.c fails on powerpc-unknown-linux-gnu with -fPIC
When running the testsuite on powerpc-unknown-linux-gnu with extra passes containing -fPIC I get the following additional errors on the 4.4 branch: FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -O2 (internal compiler error) FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -O3 -g (internal compiler error) FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -Os (internal compiler error) I don't have a logfile handy, but compiling the test by hand using -fPIC and any one of the above optimization levels I get this error: va-arg-trap-1.c:29: internal compiler error: in move_insn, at haifa-sched.c:1934 The problem does not happen in 4.5 trunk, so perhaps we can backport a fix if it can be identified. -- Summary: gcc.c-torture/execute/va-arg-trap-1.c fails on powerpc- unknown-linux-gnu with -fPIC Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43500
[Bug middle-end/43500] gcc.c-torture/execute/va-arg-trap-1.c fails on powerpc-unknown-linux-gnu with -fPIC
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-23 19:25 --- *** This bug has been marked as a duplicate of 39254 *** -- 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=43500
[Bug target/39254] [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #20 from pinskia at gcc dot gnu dot org 2010-03-23 19:25 --- *** Bug 43500 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug target/39254] [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #21 from ghazi at gcc dot gnu dot org 2010-03-23 19:55 --- As noted in duplicate PR43500, I am able to reproduce this error on plain powerpc-unknown-linux-gnu when adding -fPIC. I can run tests for the 4.4. branch but it will take several days to get a baseline result vs a patch one given extra -fPIC runs. If it passes I'll apply the patch to 4.4 per Richard's approval in comment#18. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.4 Known to work||4.5.0 Last reconfirmed|2009-06-17 04:20:01 |2010-03-23 19:55:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug target/33120] Data not put in BSS section on Mac OS
--- Comment #10 from mrs at gcc dot gnu dot org 2010-03-23 20:03 --- Subject: Bug 33120 Author: mrs Date: Tue Mar 23 20:02:57 2010 New Revision: 157677 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157677 Log: PR target/33120 * config/darwin.h (ASM_OUTPUT_ALIGNED_BSS): Add. * config/darwin.c (darwin_output_aligned_bss): Add. * config/darwin-protos.h: Add darwin_output_aligned_bss. testsuite: * g++.dg/ext/instantiate2.C: Update for .zerofill as it doesn't follow the usual conventions for symbol definitions. * gcc.target/i386/darwin-zerofill.c: Add. Added: trunk/gcc/testsuite/gcc.target/i386/darwin-zerofill.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-protos.h trunk/gcc/config/darwin.c trunk/gcc/config/darwin.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/instantiate2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120
[Bug middle-end/42181] [4.5 Regression][graphite] -fgraphite-identity miscompiles air.f90
--- Comment #27 from spop at gcc dot gnu dot org 2010-03-23 20:08 ---
I just verified that the problem is well in CLooG-PPL.
With CLooG-ISL we generate a correct code that looks like this:
for (c2=1;c2=D.1554_10-3;c2++) {
S1(c2);
for (c4=0;c4=c2-1;c4++) {
S2(c2,c4);
S3(c2,c4);
S4(c2,c4);
}
S2(c2,c2);
S4(c2,c2);
for (c4=c2+1;c4=D.1554_10-2;c4++) {
S2(c2,c4);
S3(c2,c4);
S4(c2,c4);
}
S5(c2);
S6(c2);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug target/33120] Data not put in BSS section on Mac OS
--- Comment #11 from mrs at gcc dot gnu dot org 2010-03-23 20:13 --- This should now be fixed. -- mrs at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120
[Bug other/43357] fixincludes/tests/base/iso/math_c99.h check fails
--- Comment #3 from danglin at gcc dot gnu dot org 2010-03-23 20:24 --- Also don't see any more. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43357
[Bug target/39254] [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #22 from dominiq at lps dot ens dot fr 2010-03-23 20:32 --- As noted in duplicate PR43500, I am able to reproduce this error on plain powerpc-unknown-linux-gnu when adding -fPIC. I can run tests for the 4.4. branch but it will take several days to get a baseline result vs a patch one given extra -fPIC runs. If it passes I'll apply the patch to 4.4 per Richard's approval in comment#18. I have applied the patch on powerpc-apple-darwin9 gcc-4_4-branch revision 157642. It bootstrapped for languages gcc and fortran. I am currently regtesting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #3 from davem at gcc dot gnu dot org 2010-03-23 20:40 --- Sorry, it's taking a long time to sort out the test case. The GLIBC regex code is huge and non-trivial. However I did track down that it might be dependent upon optimization options, for example I can reproduce with -mtune=niagara2 but I can't reproduce without it. I'll keep working on trying to cook up a test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug debug/43501] New: [4.4/4.5 Regression] ICE: Segmentation fault with -g due to too deep recursion
Command line:
gcc -g testcase.c
- testcase.c -
void foo (int __attribute__ ((__mode__ (vector_size (8 x) {}
void bar (int x[i()]) {}
--
(reduced from testsuite/gcc.dg/parm-impl-decl-1.c)
Tested revisions:
r157675 - crash
r157460 - crash
r157122 - crash
r153685 - crash
4.4 r153695 - crash
4.4.3 (gentoo) - crash
4.3.4, 4.2.4 (gentoo) - OK
Output:
$ /mnt/svn/gcc-trunk/binary-157675-lto/bin/gcc -g testcase.c
testcase.c:1:1: warning: '__mode__' attribute ignored
gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.
GDB backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x7636df3a in vfprintf () from /lib/libc.so.6
(gdb) bt
#0 0x7636df3a in vfprintf () from /lib/libc.so.6
#1 0x76392e19 in vsprintf () from /lib/libc.so.6
#2 0x76378f38 in sprintf () from /lib/libc.so.6
#3 0x005ceb36 in gen_subprogram_die (decl=0x75a80d00,
context_die=0x75a855d8) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:17886
#4 0x005d510c in gen_decl_die (decl=0x75a80d00, origin=value
optimized out, context_die=0x75a855d8) at
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19521
#5 0x005cd460 in decls_for_scope (stmt=0x75a850b0,
context_die=0x75a855d8, depth=0) at
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19200
#6 0x005cd9b9 in gen_subprogram_die (decl=0x75a80d00,
context_die=value optimized out) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:18060
#7 0x005d510c in gen_decl_die (decl=0x75a80d00, origin=value
optimized out, context_die=0x75a855d8) at
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19521
#8 0x005cd460 in decls_for_scope (stmt=0x75a850b0,
context_die=0x75a855d8, depth=0) at
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19200
#9 0x005cd9b9 in gen_subprogram_die (decl=0x75a80d00,
context_die=value optimized out) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:18060
#10 0x005d510c in gen_decl_die (decl=0x75a80d00, origin=value
optimized out, context_die=0x75a855d8) at
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19521
#11 0x005cd460 in decls_for_scope (stmt=0x75a850b0,
context_die=0x75a855d8, depth=0) at
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19200
#12 0x005cd9b9 in gen_subprogram_die (decl=0x75a80d00,
context_die=value optimized out) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:18060
...
#17850 0x005cd9b9 in gen_subprogram_die (decl=0x75a80d00,
context_die=value optimized out) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:18060
#17851 0x005d510c in gen_decl_die (decl=0x75a80d00, origin=value
optimized out, context_die=0x75a855d8) at
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19521
#17852 0x005cd460 in decls_for_scope (stmt=0x75a850b0,
context_die=0x75a855d8, depth=0) at
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19200
#17853 0x005cd9b9 in gen_subprogram_die (decl=0x75a80d00,
context_die=value optimized out) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:18060
#17854 0x005d510c in gen_decl_die (decl=0x75a80d00, origin=value
optimized out, context_die=0x75a855d8) at
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19521
#17855 0x005cd460 in decls_for_scope (stmt=0x75a850b0,
context_die=0x75a855d8, depth=0) at
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19200
#17856 0x005cd9b9 in gen_subprogram_die (decl=0x75a80d00,
context_die=value optimized out) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:18060
#17857 0x005d510c in gen_decl_die (decl=0x75a80d00, origin=value
optimized out, context_die=0x75a85000) at
/mnt/svn/gcc-trunk/gcc/dwarf2out.c:19521
#17858 0x0061c78d in rest_of_handle_final () at
/mnt/svn/gcc-trunk/gcc/final.c:4287
#17859 0x00725e0b in execute_one_pass (pass=0x116d400) at
/mnt/svn/gcc-trunk/gcc/passes.c:1567
#17860 0x00726095 in execute_pass_list (pass=0x116d400) at
/mnt/svn/gcc-trunk/gcc/passes.c:1622
#17861 0x007260a7 in execute_pass_list (pass=0x11faaa0) at
/mnt/svn/gcc-trunk/gcc/passes.c:1623
#17862 0x007260a7 in execute_pass_list (pass=0x11faa40) at
/mnt/svn/gcc-trunk/gcc/passes.c:1623
#17863 0x0081c4c5 in tree_rest_of_compilation (fndecl=0x75a80d00)
at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:413
#17864 0x009a0441 in cgraph_expand_function (node=0x77ed8750) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1548
#17865 0x009a11c0 in cgraph_output_in_order () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1724
#17866 0x009a31ef in cgraph_optimize () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1872
#17867 0x009a33c5 in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1096
#17868 0x004b0753 in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:9512
#17869 0x007cb010 in compile_file (argc=13, argv=0x7fffdbd8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1065
#17870 do_compile (argc=13, argv=0x7fffdbd8) at
[Bug middle-end/42181] [4.5 Regression][graphite] -fgraphite-identity miscompiles air.f90
--- Comment #28 from spop at gcc dot gnu dot org 2010-03-23 21:24 ---
I fixed this problem in CLooG-PPL: the code generated with
the new version looks like the code generated by CLooG-ISL:
for (c2=1;c2=D.1554_10-3;c2++) {
S1(c2);
for (c4=0;c4=c2-1;c4++) {
S2(c2,c4);
S3(c2,c4);
S4(c2,c4);
}
S2(c2,c2);
S4(c2,c2);
for (c4=c2+1;c4=D.1554_10-2;c4++) {
S2(c2,c4);
S3(c2,c4);
S4(c2,c4);
}
S5(c2);
S6(c2);
}
I will bootstrap and test the graphite branch with the modified
version of CLooG-PPL and then if everything looks good,
I will prepare a new version CLooG-PPL-0.15.9 and I will
upload it on ftp://gcc.gnu.org/pub/gcc/infrastructure/
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug middle-end/42181] [4.5 Regression][graphite] -fgraphite-identity miscompiles air.f90
--- Comment #29 from spop at gcc dot gnu dot org 2010-03-23 21:27 --- Also note that with the fix in CLooG-PPL, gfortran -O2 -fgraphite-identity air.f90 -o air ./air passes without error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug debug/43501] [4.4/4.5 Regression] ICE: Segmentation fault with -g due to too deep recursion
--- Comment #1 from zsojka at seznam dot cz 2010-03-23 21:31 --- Created an attachment (id=20175) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20175action=view) better testcase This testcase is better as it is valid C89 code (I believe) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43501
[Bug debug/43501] [4.4/4.5 Regression] ICE: Segmentation fault with -g due to too deep recursion
--- Comment #2 from zsojka at seznam dot cz 2010-03-23 21:33 --- C89 + GNU extensions, that is -- zsojka at seznam dot cz changed: What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.4.3 4.5.0 Known to work||3.3.6 4.2.4 4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43501
[Bug debug/43501] [4.4/4.5 Regression] ICE: Segmentation fault with -g due to too deep recursion
--- Comment #3 from jakub at gcc dot gnu dot org 2010-03-23 22:05 --- I'd say this is a dup of PR43381. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43501
[Bug target/43498] No unwind info for thunks even with -fasynchronous-unwind-tables
--- Comment #8 from jakub at gcc dot gnu dot org 2010-03-23 22:10 --- At least when using CFI asm this is solvable easily, see how I've changed i386 PIC setup generation. Without CFI asm it would be much harder though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug c/43495] [4.5 regression] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC
--- Comment #2 from ghazi at gcc dot gnu dot org 2010-03-23 22:17 --- Testcase also fails on sparc64-unknown-linux-gnu with -fpic/-fPIC in both 32 and 64 bit modes: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00753.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|ia64-unknown-linux-gnu |ia64-unknown-linux-gnu |powerpc-unknown-linux-gnu |powerpc-unknown-linux-gnu ||sparc64-unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43495
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-23 22:41 --- Wouldn't this be the same issue as http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01086.html ? On the trunk it wasn't just one commit, but several: 156888, 156889, 156893, 156903, 156913 If yes, would be interesting to know whether it is the 156888 commit or the other ones, and narrow it down to a single miscompiled routine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug target/43435] [4.3/4/4 Regression] SH: Bad registers are restored before ISR is leaved
--- Comment #3 from kkojima at gcc dot gnu dot org 2010-03-23 23:13 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43435
[Bug rtl-optimization/43413] Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used
--- Comment #12 from meissner at gcc dot gnu dot org 2010-03-23 23:40 --- This reduces the spills, and brings the performance backs up. I'm closing the bug. Thanks. -- meissner at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43413
[Bug target/43484] [4.5 Regression] GCC 4.5 does not build gamess, zeusmp on powerpc -m32 with loop unrolling
--- Comment #8 from meissner at gcc dot gnu dot org 2010-03-23 23:43 --- I have tracked down the issue, and will submit a patch tomorrow after further testing. The issue is when a multi-word items is loaded to GPRS, and the address is of the form (r0+reg), the compiler was using r0 as the base register, which is not allowed in the powerpc architecture. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43484
[Bug c++/43502] New: uninitialised read in grokfndecl() with lambda functions cause -fcompare-debug failures
Command line:
g++ -std=c++0x testcase.cpp
testcase.cpp
void f() { []{}(); }
--
valgrind shows uninitialised read with this testcase
Tested revisions:
r157675 - fail
Valgrind output:
$ valgrind --trace-children=yes -q /mnt/svn/gcc-trunk/binary-157675-lto/bin/g++
-std=c++0x testcase.cpp
==11819== Conditional jump or move depends on uninitialised value(s)
==11819==at 0x4D59C8: grokfndecl (decl.c:6657)
==11819==by 0x4DC9E2: grokdeclarator (decl.c:9301)
==11819==by 0x4DDD52: grokmethod (decl.c:12657)
==11819==by 0x578109: cp_parser_lambda_expression (parser.c:7409)
==11819==by 0x56BA6E: cp_parser_primary_expression (parser.c:3344)
==11819==by 0x5802BA: cp_parser_postfix_expression (parser.c:4741)
==11819==by 0x569BE7: cp_parser_unary_expression (parser.c:5667)
==11819==by 0x571A27: cp_parser_binary_expression (parser.c:6337)
==11819==by 0x571F2A: cp_parser_assignment_expression (parser.c:6548)
==11819==by 0x5722B9: cp_parser_expression (parser.c:6694)
==11819==by 0x5727DB: cp_parser_expression_statement (parser.c:7809)
==11819==by 0x564145: cp_parser_statement (parser.c:7674)
==11819==
--
Summary: uninitialised read in grokfndecl() with lambda functions
cause -fcompare-debug failures
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43502
[Bug c++/43502] uninitialised read in grokfndecl() with lambda functions cause -fcompare-debug failures
--- Comment #1 from zsojka at seznam dot cz 2010-03-24 00:03 --- Created an attachment (id=20176) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20176action=view) reduced testcase showing -fcompare-debug failure Line numbers are random: $ /mnt/svn/gcc-trunk/binary-157675-lto/bin/g++ -std=c++0x -fcompare-debug -c pr43502.C -save-temps ; diff pr43502.gkd pr43502.gk.gkd g++: pr43502.C: -fcompare-debug failure 79c79 (insn/f# 0 0 pr43502.C:25576972 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8]) --- (insn/f# 0 0 pr43502.C:17876971 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8]) 81c81 (insn/f# 0 0 pr43502.C:25576972 (set (reg/f:DI 6 bp) --- (insn/f# 0 0 pr43502.C:17876971 (set (reg/f:DI 6 bp) 108c108 (insn/f# 0 0 pr43502.C:25576972 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8]) --- (insn/f# 0 0 pr43502.C:17876971 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8]) 110c110 (insn/f# 0 0 pr43502.C:25576972 (set (reg/f:DI 6 bp) --- (insn/f# 0 0 pr43502.C:17876971 (set (reg/f:DI 6 bp) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43502
