[Bug bootstrap/43615] New: bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
My usual routine to build gcc-trunk started failing yesterday (or the day before)? The configure has remained unchanged (notice --disable-multilib --disable-bootstrap): /data/vondele/gcc_bench/gcc_trunk/gcc/configure --prefix=/data/vondele/gcc_bench/gcc_trunk/build --enable-languages=c,c++,fortran --program-suffix=-trunk --disable-multilib --disable-bootstrap --with-gmp=/data/vondele/gcc_bench/libs/ --with-mpfr=/data/vondele/gcc_bench/libs/ --with-mpc=/data/vondele/gcc_bench/libs/ The error seems to be: -fvisibility=hidden -DHIDE_EXPORTS /data/vondele/gcc_bench/gcc_trunk/obj/./gcc/xgcc -B/data/vondele/gcc_bench/gcc_trunk/obj/./gcc/ -B/data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/bin/ -B/data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/lib/ -isystem /data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/include -isystem /data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/sys-include -g -O2 -m32 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../.././gcc -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/. -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../include -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS In file included from /usr/include/features.h:354:0, from /usr/include/stdio.h:28, from /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/tsystem.h:87, from /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/libgcc2.c:29: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory compilation terminated. make[4]: *** [_muldi3.o] Error 1 make[4]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/32/libgcc' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgcc' make[2]: *** [all-multi] Error 2 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj' make: *** [all] Error 2 -- Summary: bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug target/43550] arm missing rev16
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-04-01 07:03:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43550
[Bug bootstrap/43615] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-01 07:06 --- svn versions: last known good: 157842 first known bad: 157896 CCing a RM -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Summary|bootstrap fails:|[4.5 Regression] bootstrap |/usr/include/gnu/stubs.h:7:2|fails: |7: fatal error: gnu/stubs- |/usr/include/gnu/stubs.h:7:2 |32.h: No such file or |7: fatal error: gnu/stubs- |directory |32.h: No such file or ||directory Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug regression/43616] New: Extra register move
Compile the following code with options -Os -march=armv7-a -mthumb
extern long long foo();
void bar2(long long* p)
{
long long t = foo();
*p = t;
}
GCC generates:
bar2:
push{r4, lr}
mov r4, r0
bl foo
mov r2, r0 // A
mov r3, r1 // B
strdr2, [r4] // C
pop {r4, pc}
1. The register moves in instructions AB is a regression relate to gcc4.4.0.
The result of gcc4.4 is:
push{r4, lr}
mov r4, r0
bl foo
strdr0, [r4]
pop {r4, pc}
The regression may be caused by some changes in ira. Before ira both versions
have similar rtx sequence:
(call_insn 6 3 7 2 src/tb.c:4 (parallel [
(set (reg:DI 0 r0)
(call (mem:SI (symbol_ref:SI ("foo") [flags 0x41]
) [0 S4 A32])
(const_int 0 [0x0])))
(use (const_int 0 [0x0]))
(clobber (reg:SI 14 lr))
]) 255 {*call_value_insn} (nil)
(nil))
(insn 7 6 8 2 src/tb.c:4 (set (reg/v:DI 133 [ t ])
(reg:DI 0 r0)) 657 {*thumb2_movdi} (nil))
(insn 8 7 0 2 src/tb.c:5 (set (mem:DI (reg/v/f:SI 134 [ p ]) [2 S8 A64])
(reg/v:DI 133 [ t ])) 657 {*thumb2_movdi} (expr_list:REG_DEAD
(reg/v/f:SI 134 [ p ])
(expr_list:REG_DEAD (reg/v:DI 133 [ t ])
(nil
After ira, gcc4.5 generates:
(call_insn 6 3 7 2 src/tb.c:4 (parallel [
(set (reg:DI 0 r0)
(call (mem:SI (symbol_ref:SI ("foo") [flags 0x41]
) [0 S4 A32])
(const_int 0 [0x0])))
(use (const_int 0 [0x0]))
(clobber (reg:SI 14 lr))
]) 255 {*call_value_insn} (nil)
(nil))
(insn 7 6 8 2 src/tb.c:4 (set (reg/v:DI 2 r2 [orig:133 t ] [133])
(reg:DI 0 r0)) 657 {*thumb2_movdi} (expr_list:REG_EQUIV (mem:DI
(reg/v/f:SI 4 r4 [orig:134 p ] [134]) [2 S8 A64])
(nil)))
(insn 8 7 11 2 src/tb.c:5 (set (mem:DI (reg/v/f:SI 4 r4 [orig:134 p ] [134]) [2
S8 A64])
(reg/v:DI 2 r2 [orig:133 t ] [133])) 657 {*thumb2_movdi} (nil))
But gcc4.4 generates:
(call_insn 6 3 8 2 src/tb.c:4 (parallel [
(set (reg:DI 0 r0)
(call (mem:SI (symbol_ref:SI ("foo") [flags 0x41]
) [0 S4 A32])
(const_int 0 [0x0])))
(use (const_int 0 [0x0]))
(clobber (reg:SI 14 lr))
]) 257 {*call_value_insn} (nil)
(nil))
(insn 8 6 16 2 src/tb.c:5 (set (mem:DI (reg/v/f:SI 4 r4 [orig:134 p ] [134]) [2
S8 A64])
(reg/v:DI 0 r0 [orig:133 t ] [133])) 651 {*thumb2_movdi} (nil))
2. Since r4 is never used again after instruction C, it can also be written as
a stm instruction. In thumb2, strd is a 32bit instruction, but stm is 16 bit.
--
Summary: Extra register move
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43616
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #7 from manfred99 at gmx dot ch 2010-04-01 07:42 --- Thanks for the quick fix! I can confirm that the patch works for both the "(a)" and the "*" case. In the code, there is still some size_t reference, should probably be gfc_offset as well: if (u == NULL) return ((size_t) -1); Not that it would matter, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #17 from developer at sandoe-acoustics dot co dot uk 2010-04-01 08:02 --- AFAICT the root problem does not relate to export of symbols from emutls (or to its use). Although this perhaps needs a different PR The root problem is that the emutls implementation generates symbols in the data area that are (AFAICT) translated into thread-unique addresses by _emutls_get_address. The two symbols in question are declared static and private and are being optimized away. (you will find that the profile tests work at -O0). I am not sure why they are being optimized away when there is a reference to them in the asm file -- see (b) below. The variables need to be preserved and coalesced within one binary. a/ A work-round solution is to mark the two variables PUBLIC and COMMON. I've tested that this works on i686-apple-darwin and ia32-pc-linux BUT b/ Looking at http://gcc.gnu.org/ml/gcc/2010-03/msg00482.html It is perhaps the case that other attributes are not being copied that are causing this problem. Of course, maybe this is also a limitation of emutls. I don't have time to do much on this today -- and the trunk freeze is fast approaching.. input from more experienced would be welcome... -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added CC||developer at sandoe- ||acoustics dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #18 from bonzini at gnu dot org 2010-04-01 08:08 --- TREE_USED then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug target/43613] Some architecture-dependent codes
--- Comment #2 from aflyhorse at foxmail dot com 2010-04-01 08:23 --- Got your ideas and be sorry for i chobber the building tree of my computer and the tree of package, there shouldn't be /gcc/src in the path (I was confused when i'm looking for the file myself) that time i'm testing the --enable-hash-synchronization option And could you please tell me why I always fail to build libgcj (after make install type "gcj -v" it tells me that libgcj.spec is missing and i find no libgcj.a & .la in my lib directory) even if i added "--enable-libgcj --enable-libjava" in configure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613
[Bug target/43613] Some architecture-dependent codes
--- Comment #3 from aflyhorse at foxmail dot com 2010-04-01 08:26 --- Also, the compiler do stopped and treat warnings as errors while compiling ira-conflicts.c until i changed these 2 "%ld" to "%I64u" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #19 from developer at sandoe-acoustics dot co dot uk 2010-04-01 08:30 --- (In reply to comment #18) > TREE_USED then? It doesn't do it... tried that first ;-) [ and it is copied] However, I see the comment that variables can change status during their life - or perhaps it's a bug... I also tried TREE_ADDRESSABLE and DECL_PRESERVED_P - but now I see that these are not copied. hmmm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
Re: [Bug bootstrap/43615] New: bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
Sent from my iPhone On Apr 1, 2010, at 12:03 AM, "jv244 at cam dot ac dot uk" > wrote: My usual routine to build gcc-trunk started failing yesterday (or the day before)? The configure has remained unchanged (notice --disable-multilib --disable-bootstrap): --disable-bootstrap is almost never a good idea for a native build. /data/vondele/gcc_bench/gcc_trunk/gcc/configure --prefix=/data/vondele/gcc_bench/gcc_trunk/build --enable-languages=c,c++,fortran --program-suffix=-trunk --disable- multilib --disable-bootstrap --with-gmp=/data/vondele/gcc_bench/libs/ --with-mpfr=/data/vondele/gcc_bench/libs/ --with-mpc=/data/vondele/gcc_bench/libs/ The error seems to be: -fvisibility=hidden -DHIDE_EXPORTS /data/vondele/gcc_bench/gcc_trunk/obj/./gcc/xgcc -B/data/vondele/gcc_bench/gcc_trunk/obj/./gcc/ -B/data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/ bin/ -B/data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/ lib/ -isystem /data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/ include -isystem /data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/sys- include -g -O2 -m32 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast- qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 - D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../.././gcc -I/data/vondele/gcc_bench/gcc_trunk/gcc/ libgcc -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/. -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../include -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o - MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS In file included from /usr/include/features.h:354:0, from /usr/include/stdio.h:28, from /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/tsystem.h:87, from /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/libgcc2.c:29: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory compilation terminated. make[4]: *** [_muldi3.o] Error 1 make[4]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/32/ libgcc' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/ libgcc' make[2]: *** [all-multi] Error 2 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/ libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj' make: *** [all] Error 2 -- Summary: bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
--- Comment #2 from pinskia at gmail dot com 2010-04-01 08:50 --- Subject: Re: New: bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory Sent from my iPhone On Apr 1, 2010, at 12:03 AM, "jv244 at cam dot ac dot uk" wrote: > My usual routine to build gcc-trunk started failing yesterday (or > the day > before)? > > The configure has remained unchanged (notice --disable-multilib > --disable-bootstrap): --disable-bootstrap is almost never a good idea for a native build. > > /data/vondele/gcc_bench/gcc_trunk/gcc/configure > --prefix=/data/vondele/gcc_bench/gcc_trunk/build > --enable-languages=c,c++,fortran --program-suffix=-trunk --disable- > multilib > --disable-bootstrap --with-gmp=/data/vondele/gcc_bench/libs/ > --with-mpfr=/data/vondele/gcc_bench/libs/ > --with-mpc=/data/vondele/gcc_bench/libs/ > > The error seems to be: > > -fvisibility=hidden -DHIDE_EXPORTS > /data/vondele/gcc_bench/gcc_trunk/obj/./gcc/xgcc > -B/data/vondele/gcc_bench/gcc_trunk/obj/./gcc/ > -B/data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/ > bin/ > -B/data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/ > lib/ > -isystem > /data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/ > include > -isystem > /data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/sys- > include > -g -O2 -m32 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast- > qual > -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - > isystem > ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 - > D__GCC_FLOAT_NOT_NEEDED > -I. -I. -I../../.././gcc -I/data/vondele/gcc_bench/gcc_trunk/gcc/ > libgcc > -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/. > -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc > -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../include > -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/config/libbid > -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o - > MT _muldi3.o > -MD -MP -MF _muldi3.dep -DL_muldi3 -c > /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/libgcc2.c \ > -fvisibility=hidden -DHIDE_EXPORTS > In file included from /usr/include/features.h:354:0, > from /usr/include/stdio.h:28, > from > /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/tsystem.h:87, > from > /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/libgcc2.c:29: > /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such > file or > directory > compilation terminated. > make[4]: *** [_muldi3.o] Error 1 > make[4]: Leaving directory > `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/32/ > libgcc' > make[3]: *** [multi-do] Error 1 > make[3]: Leaving directory > `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/ > libgcc' > make[2]: *** [all-multi] Error 2 > make[2]: *** Waiting for unfinished jobs > make[2]: Leaving directory > `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/ > libgcc' > make[1]: *** [all-target-libgcc] Error 2 > make[1]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj' > make: *** [all] Error 2 > > > -- > Summary: bootstrap fails: /usr/include/gnu/stubs.h:7:27: > fatal >error: gnu/stubs-32.h: No such file or directory > Product: gcc > Version: 4.5.0 >Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: bootstrap >AssignedTo: unassigned at gcc dot gnu dot org >ReportedBy: jv244 at cam dot ac dot uk > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #8 from jb at gcc dot gnu dot org 2010-04-01 08:55 --- (In reply to comment #7) > I can confirm that the patch works for both the "(a)" and the "*" case. Thanks for testing. I'll commit the patch to 4.5 tonight. > In the code, there is still some size_t reference, should > probably be gfc_offset as well: > >if (u == NULL) > return ((size_t) -1); > > Not that it would matter, though. Yeah, it won't make any difference. The real bug here is using size_t for the return value, there is PR39654 for that. (And, of course, (size_t) -1 is some very large value since size_t is unsigned, and not -1 which is the correct behavior). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug c/36367] warning for questionable compound expression
--- Comment #4 from pzhao at gcc dot gnu dot org 2010-04-01 09:19 ---
Sorry! I have misunderstood this issue before.
Is it to ask for warn at the following test case?
=
int foo (int a)
{
return a;
}
int bar (int c)
{
if (foo (1), c) // Warn foo(1) don't have obvious side-effects here?
return 1;
else
return 0;
}
===
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2008-05-29 12:00:46 |2010-04-01 09:19:19
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36367
[Bug fortran/43591] PPC: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #5 from burnus at gcc dot gnu dot org 2010-04-01 09:26 --- (In reply to comment #3) > Reduced test: [...] (In reply to comment #4) > Further reduced test that does not give an ICE, but several errors: > Although gfortran should not give an ICE, I have doubts about the validity of > the code. Well, using type omega_procedures procedure(number_particles_out), nopass, pointer :: number_particles_out => NULL() end type omega_procedures is definitely wrong: You tell that the procedure pointer has the interface of itself. By itself, gfortran also properly diagnoses this: Error: Interface 'number_particles_out' of procedure pointer component 'number_particles_out' at (1) must be explicit But seemingly, this resolution comes too late - the ICE happens earlier. That's definitely an ICE-on-invalid-code bug. * * * However, if I compile the real, 7479 line program with ifort, I do not get any error message. I try now to reduce - using delta - the big program, under the constraint that it still compiles without any error with ifort. Let's see where that leads to. Cf. http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug libfortran/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #3 from burnus at gcc dot gnu dot org 2010-04-01 09:41 --- (In reply to comment #2) > It appears to be a regression. See results for 4.4: > I'll rebuild 4.5 and check point a. Thanks - I marked it as regression, but without having access to armv5tejl it is impossible to debug - thus you need to do this deed. Can you also do the following: Using the 4.4 or 4.5 binary with the 4.5 or 4.4 libgfortran. I suspect that libgfortran has a bug. As some bugfixes went also into 4.4.x, it might be that the latest 4.4.x branch has the same bug. - At least finding the regression-causing bug should be easier if it is in libgfortran as one can rather quickly build it, without rebuilding the while of GCC. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|FAIL: gfortran.dg/PR19872.f |[4.5 Regression] FAIL: |execution test; formatted |gfortran.dg/PR19872.f |read - wrong numbers|execution test; formatted ||read - wrong numbers Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug c/36367] warning for questionable compound expression
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-04-01 10:10 --- > Is it to ask for warn at the following test case? Yes, it is. An additional condition could be that the type be non-void. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36367
[Bug c++/43608] Boost.MPL code doesn't get the placeholders substituted anymore
--- Comment #1 from redi at gcc dot gnu dot org 2010-04-01 10:49 --- Created an attachment (id=20271) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20271&action=view) reduced testcase reduced to just the instantiation that fails with 4.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43608
[Bug c++/43608] Boost.MPL code doesn't get the placeholders substituted anymore
--- Comment #2 from redi at gcc dot gnu dot org 2010-04-01 10:53 --- the subject line is misleading, I think the placeholders are still substituted in exactly the same way, but as part of that an invalid instantiation is generated while determining the template_arity of the metafunction. The invalid instantiation occurs in a sizeof expression and was previously ignored (presumably due to SFINAE) but now causes an error. I don't think SFINAE applies in that context, which would make 4.5 correct -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43608
[Bug c++/43608] Boost.MPL code doesn't get the placeholders substituted anymore
--- Comment #3 from redi at gcc dot gnu dot org 2010-04-01 11:10 --- Created an attachment (id=20272) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20272&action=view) reduced testcase with fix added but commented out Comeau's online compiler agrees with GCC 4.5 As the reporter says, the testcase can be fixed by adding an explicit specialisation of metafunction< arg<2> > ... I don't know why this works. The second attachment has the specialisation, commented out. -- redi at gcc dot gnu dot org changed: What|Removed |Added Attachment #20271|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43608
[Bug libfortran/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-04-01 11:25 --- Reverting back to... TREE_PUBLIC (ic_void_ptr_var) = 0; in the proposed patch results in the missing symbols again. Can we just leave... TREE_PUBLIC (ic_void_ptr_var) = 1; and find some way to coalesce the symbols so that the failure in... FAIL: gcc.dg/tree-prof/ic-misattribution-1.c compilation, -fprofile-generate -D_PROFILE_GENERATE disappears. Lastly, any chance we can change this to a P1 so that it is fixed before the gcc 4.5 release? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug libfortran/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-04-01 11:26 --- (In reply to comment #4) > Reverting back to... > > TREE_PUBLIC (ic_void_ptr_var) = 0; > > in the proposed patch results in the missing symbols again. > Can we just leave... > > TREE_PUBLIC (ic_void_ptr_var) = 1; > > and find some way to coalesce the symbols so that the failure in... > > FAIL: gcc.dg/tree-prof/ic-misattribution-1.c compilation, -fprofile-generate > -D_PROFILE_GENERATE > > disappears. Lastly, any chance we can change this to a P1 so that it is fixed > before the gcc 4.5 release? > Sorry. Wrong PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2010-04-01 11:27 --- Reverting back to... TREE_PUBLIC (ic_void_ptr_var) = 0; in the proposed patch results in the missing symbols again. Can we just leave... TREE_PUBLIC (ic_void_ptr_var) = 1; and find some way to coalesce the symbols so that the failure in... FAIL: gcc.dg/tree-prof/ic-misattribution-1.c compilation, -fprofile-generate -D_PROFILE_GENERATE disappears. Lastly, any chance we can change this to a P1 so that it is fixed before the gcc 4.5 release? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43602
[Bug fortran/43591] PPC: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #6 from ohl at physik dot uni-wuerzburg dot de 2010-04-01 11:47 --- (In reply to comment #5) > Well, using > type omega_procedures > procedure(number_particles_out), nopass, pointer :: number_particles_out > => NULL() > end type omega_procedures > > is definitely wrong: You tell that the procedure pointer has the interface of > itself. But that's not the problem: module m implicit none type t procedure(p1_type), nopass, pointer :: p1 => NULL() procedure(p2_type), nopass, pointer :: p2 => NULL() end type t contains subroutine proc (t1, t2) type(t), intent(in) :: t1, t2 integer, dimension(t1%p1(), t2%p2()) :: table end subroutine proc end module m produces the same error. What is invaild about the code is that t1%p1() and t2%p2() are not initialization expressions. Everthing works fine, when the tables are allocatable. BTW: gfortran produces correct code for the variant when the procedures are not procedure pointers. I stumpled over this OCE when rewriting some code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug target/42886] [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)
--- Comment #8 from nightstrike at gmail dot com 2010-04-01 11:54 --- I'd recommend closing this as invalid. We build 12 relocatable toolchains for windows daily for http://mingw-w64.sf.net/ I'm pretty sure it works :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
[Bug c++/42609] [4.5 regression] undesired operation when working with mno-cygwin
--- Comment #4 from rguenther at suse dot de 2010-04-01 12:04 ---
Subject: Re: [4.5 regression] undesired operation when working
with mno-cygwin
On Thu, 1 Apr 2010, davek at gcc dot gnu dot org wrote:
> --- Comment #3 from davek at gcc dot gnu dot org 2010-04-01 01:11 ---
> I figure this is worth fixing in the ~22-hour window remaining before 2nd
> April. The option although deprecated should not for preference be released
> in
> a broken state, and since it worked in all previous versions (i.e. before I
> added the libstdc++ wrappers) this is a regression. The fix should be really
> really trivial:
>
> Index: gcc/config/i386/cygwin.h
> ===
> --- gcc/config/i386/cygwin.h(revision 157789)
> +++ gcc/config/i386/cygwin.h(working copy)
> @@ -108,7 +108,7 @@ along with GCC; see the file COPYING3. If not see
> #define CXX_WRAP_SPEC_OPT "muse-libstdc-wrappers"
> #endif
>
> -#define CXX_WRAP_SPEC "%{" CXX_WRAP_SPEC_OPT ":" CXX_WRAP_SPEC_LIST "}"
> +#define CXX_WRAP_SPEC "%{!mno-cygwin:%{" CXX_WRAP_SPEC_OPT ":"
> CXX_WRAP_SPEC_LIST "}}"
>
> #else /* !defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS) */
>
>
> I'll set the bootstrap going now. That'll leave me some time to test it this
> coming lunchtime/afternoon/evening (UK time) and check it in long before
> midnight.
>
> Richard G., please speak up if you have any objection to this plan, if I
> haven't heard anything from you by a few hours before the midnight deadline
> I'll assume you're ok with it.
It looks reasonable - well, I don't know nothing about cygwin. But
it doesn't touch other targets, so if a cygwin maintainer is ok with
it I'm fine with it as well.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42609
[Bug other/43617] New: cloog-ppl 0.15.9's configure corrupts with funny codes
Sorry to distrub you all, but when i downloaded and untar the latest cloog-ppl (which is one of the infrastructure of gcc). when i ./configure it, it fails to find ppl (with --with-ppl=/local) and break down asking for PolyLib. When i look into the configure script itself, i found it is corrupted. 12694: if test "x$with_ppl" != "x" -a "x$with_ppl" != "xno"; then 12702: if test "x$with_ppl" != "xyes" ; then 12843: if test "x$ac_cv_header_ppl_c_h" = x""yes; then the last one is especially funny, isn't it? Sorry i don't know where to report it, so i reported it here... -- Summary: cloog-ppl 0.15.9's configure corrupts with funny codes Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aflyhorse at foxmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43617
[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-01 12:11 --- It looks like you are missing 32bit multilib pieces of your target glibc (thus an install problem) when building the 32bit libgcc multilib. If you think not then check if any of the offending headers appear to be fixincluded. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug fortran/43591] PPC: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #7 from dominiq at lps dot ens dot fr 2010-04-01 12:17 --- (In reply to comment #6) > What is invaild about the code is that t1%p1() and t2%p2() are not > initialization expressions. Everthing works fine, when the tables are > allocatable. That was the origin of my question about the validity of the code. > BTW: gfortran produces correct code for the variant when the procedures are > not > procedure pointers. I stumpled over this OCE when rewriting some code. Why would this make the code valid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug fortran/43591] PPC: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #8 from burnus at gcc dot gnu dot org 2010-04-01 12:28 ---
(In reply to comment #6)
> But that's not the problem:
> type t
> procedure(p1_type), nopass, pointer :: p1 => NULL()
> procedure(p2_type), nopass, pointer :: p2 => NULL()
That's not valid either as you have not defined "p1_type" - replacing it by
INTEGER should work, though. -- Well, it actually does not as specification
expressions need to be PURE.
* * *
Daniel, Janus: What do you think about the following incomplete patch? It needs
some extra handling as, e.g., the PURE check fails for the procedure pointer
(it works for the type-bound procedure) and maybe one should insert an assert
that it is really a function and not a subroutine and things like that, but
otherwise it seems to work.
Test case:
!
module m
implicit none
type t
procedure(p1_type), nopass, pointer :: p1 => NULL()
contains
procedure, nopass :: tbp => p1_type
end type t
contains
subroutine proc (t1, t2)
type(t), intent(in) :: t1, t2
integer, dimension(t1%p1(), t2%tbp()) :: table
end subroutine proc
pure function p1_type()
integer :: p1_type
p1_type = 42
end function p1_type
end module m
!
Index: expr.c
===
--- expr.c (revision 157899)
+++ expr.c (working copy)
@@ -3559,6 +3559,8 @@ gfc_traverse_expr (gfc_expr *expr, gfc_s
switch (expr->expr_type)
{
+case EXPR_PPC:
+case EXPR_COMPCALL:
case EXPR_FUNCTION:
for (args = expr->value.function.actual; args; args = args->next)
{
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||domob at gcc dot gnu dot org
GCC build triplet|x86_64-unknown-linux-gnu|
GCC host triplet|x86_64-unknown-linux-gnu|
GCC target triplet|x86_64-unknown-linux-gnu|
Last reconfirmed|2010-03-30 17:58:35 |2010-04-01 12:28:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
--- Comment #4 from mikpe at it dot uu dot se 2010-04-01 12:35 --- The bug reporter explicitly specified --disable-multilib, yet gcc-4.5 apparently now tries to build libgcc with -m32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug fortran/43591] PPC: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #9 from burnus at gcc dot gnu dot org 2010-04-01 12:36 --- (In reply to comment #7) > (In reply to comment #6) > > What is invaild about the code is that t1%p1() and t2%p2() are not > > initialization expressions. Everthing works fine, when the tables are > > allocatable. > > That was the origin of my question about the validity of the code. What you have is called an "automatic (explicit) array", which does not need to have initialization expressions for bounds but just specification expressions: 5.3.8.2 Explicit-shape array R516 explicit-shape-spec is [ lower-bound : ] upper-bound R517 lower-bound is specification-expr R518 upper-bound is specification-expr C531 (R516) An explicit-shape-spec whose bounds are not constant expressions shall appear only in a subprogram, derived type de nition, BLOCK construct, or interface body. 7.1.11 Specification expression [...] A function is a specification function if it is a pure function, is not a standard intrinsic function, is not an internal function, is not a statement function, and does not have a dummy procedure argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
--- Comment #5 from jv244 at cam dot ac dot uk 2010-04-01 12:41 --- Created an attachment (id=20273) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20273&action=view) log of the build -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
--- Comment #6 from jv244 at cam dot ac dot uk 2010-04-01 12:42 --- (In reply to comment #4) > The bug reporter explicitly specified --disable-multilib, yet gcc-4.5 > apparently now tries to build libgcc with -m32. right... you've been faster. I've added the logs of the build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug fortran/43591] PPC: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #10 from ohl at physik dot uni-wuerzburg dot de 2010-04-01 12:45 --- (In reply to comment #8) > That's not valid either as you have not defined "p1_type" - replacing it by > INTEGER should work, though. -- Well, it actually does not as specification > expressions need to be PURE. Doesn't help module m implicit none type t procedure(p1_type), nopass, pointer :: p1 => NULL() procedure(p2_type), nopass, pointer :: p2 => NULL() end type t abstract interface pure function p1_type () result (n) integer :: n end function p1_type pure function p2_type () result (n) integer :: n end function p2_type end interface contains subroutine proc (t1, t2) type(t), intent(in) :: t1, t2 integer, dimension(t1%p1(), t2%p2()) :: table end subroutine proc end module m (The abstract interface is in the original bug report, but was removed in Dominiques's reduction). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug other/43617] cloog-ppl 0.15.9's configure corrupts with funny codes
--- Comment #1 from redi at gcc dot gnu dot org 2010-04-01 13:13 --- it might look unusual but it's valid e.g. test xyes = x""yes && echo ok I don't think that's the source of your problem, and since you haven't actually described any issue this report looks invalid -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43617
[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-04-01 13:15 --- Obviously caused by 2010-03-31 Ralf Wildenhues PR bootstrap/43328 * configure.ac: Do not pass --enable-multilib nor --disable-multilib in baseargs. Accept explicitly passed --enable_multilib. * configure: Regenerate. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rwild at gcc dot gnu dot org Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-01 13:15:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug bootstrap/43328] multilib bootstrap broken.
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-04-01 13:17 --- Fixed? But caused PR43615. --disable-multilib no longer works. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||43615 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43328
[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug tree-optimization/42956] [4.4 Regression] internal compiler error: Segmentation fault with -O1
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-04-01 13:20 --- The "Complete." part shouldn't be backported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956
[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-04-01 13:25 --- Subject: Bug 43602 Author: rguenth Date: Thu Apr 1 13:24:58 2010 New Revision: 157907 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157907 Log: 2010-04-01 Richard Guenther PR middle-end/43602 Revert 2010-03-30 Seongbae Park Jack Howarth * tree-profile.c (tree_init_ic_make_global_vars): Make static variables TLS. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-profile.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43602
[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-04-01 13:26 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43602
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-04-01 13:27 --- Can you try to identify the patch that introduced this regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug tree-optimization/43611] [4.5 Regression] ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions
--- Comment #2 from zsojka at seznam dot cz 2010-04-01 13:29 --- Created an attachment (id=20274) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20274&action=view) reduced testcase Command line: gcc -O3 -fkeep-inline-functions pr43611.C or gcc -O2 -fipa-cp-clone -fkeep-inline-functions pr43611.C or gcc -O1 -fipa-cp -fipa-cp-clone -fkeep-inline-functions pr43611.C -- zsojka at seznam dot cz changed: What|Removed |Added Attachment #20270|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43611
[Bug tree-optimization/43141] [4.5 Regression] Wrong debug information with IPA-SRA
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-04-01 13:32 --- Subject: Bug 43141 Author: jamborm Date: Thu Apr 1 13:31:53 2010 New Revision: 157909 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157909 Log: 2010-04-01 Martin Jambor PR tree-optimization/43141 * testsuite/gcc.dg/guality/pr43141.c: New test. Added: trunk/gcc/testsuite/gcc.dg/guality/pr43141.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43141
[Bug tree-optimization/43611] [4.5 Regression] ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-01 13:39 ---
The issue seems to be the C++ frontend marking inline functions needed
at cp/semantics.c:3452 while the middle-end should already take care
of that in cgraph_decide_is_function_needed.
Somehow that confuses us and we end up performing inlining on a body
that has been reclaimed.
Honza?
The following "fixes" it, bug arguably the bug must then be latent
with dllexport.
Index: cp/semantics.c
===
--- cp/semantics.c (revision 157906)
+++ cp/semantics.c (working copy)
@@ -3449,8 +3449,7 @@ expand_or_defer_fn_1 (tree fn)
this function as needed so that finish_file will make sure to
output it later. Similarly, all dllexport'd functions must
be emitted; there may be callers in other DLLs. */
- if ((flag_keep_inline_functions && DECL_DECLARED_INLINE_P (fn))
- || lookup_attribute ("dllexport", DECL_ATTRIBUTES (fn)))
+ if (lookup_attribute ("dllexport", DECL_ATTRIBUTES (fn)))
mark_needed (fn);
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot
||org, hubicka at gcc dot gnu
||dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-04-01 13:39:09
date||
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43611
[Bug target/43618] New: Incorrect sse2_cvtX2Y pattern
Many SSE cvt instructions take 64bit memory source
instead of 128bit. In
(define_insn "sse2_cvtps2pd"
[(set (match_operand:V2DF 0 "register_operand" "=x")
(float_extend:V2DF
(vec_select:V2SF
(match_operand:V4SF 1 "nonimmediate_operand" "xm")
(parallel [(const_int 0) (const_int 1)]]
"TARGET_SSE2"
"%vcvtps2pd\t{%1, %0|%0, %1}"
[(set_attr "type" "ssecvt")
(set_attr "prefix" "maybe_vex")
(set_attr "mode" "V2DF")
(set_attr "prefix_data16" "0")
(set_attr "amdfam10_decode" "direct")])
memory operand is V2SF, not V4SF. As the result, we get
[...@gnu-6 tmp]$ cat x.c
float v2sf[8] __attribute ((aligned(16)));
double v4df[8] __attribute ((aligned(16)));
void
foo ()
{
int i;
for (i = 0; i < 8; i++)
v4df[i] = v2sf[i];
}
[...@gnu-6 tmp]$ /usr/gcc-4.5/bin/gcc -S -O3 x.c
[...@gnu-6 tmp]$ cat x.s
.file "x.c"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movaps v2sf(%rip), %xmm1
cvtps2pd%xmm1, %xmm0
movapd %xmm0, v4df(%rip)
xorps %xmm0, %xmm0
movhlps %xmm1, %xmm0
movaps v2sf+16(%rip), %xmm1
cvtps2pd%xmm0, %xmm0
movapd %xmm0, v4df+16(%rip)
cvtps2pd%xmm1, %xmm0
movapd %xmm0, v4df+32(%rip)
xorps %xmm0, %xmm0
movhlps %xmm1, %xmm0
cvtps2pd%xmm0, %xmm0
movapd %xmm0, v4df+48(%rip)
ret
instead of
[...@gnu-6 tmp]$ /opt/intel/Compiler/11.1/059/bin/intel64/icc -S -O2 x.c
[...@gnu-6 tmp]$ cat x.s
# -- Machine type EFI2
# mark_description "Intel(R) C++ Compiler for applications running on Intel(R)
64, Version 11.1Build 20091012 %s";
# mark_description "-S -O2";
.file "x.c"
.text
..TXTST0:
# -- Begin foo
# mark_begin;
.align16,0x90
.globl foo
foo:
..B1.1: # Preds ..B1.0
..___tag_value_foo.1: #5.1
cvtps2pd v2sf(%rip), %xmm0 #8.15
cvtps2pd 8+v2sf(%rip), %xmm1 #8.15
cvtps2pd 16+v2sf(%rip), %xmm2 #8.15
cvtps2pd 24+v2sf(%rip), %xmm3 #8.15
movaps%xmm0, v4df(%rip) #8.5
movaps%xmm1, 16+v4df(%rip) #8.5
movaps%xmm2, 32+v4df(%rip) #8.5
movaps%xmm3, 48+v4df(%rip) #8.5
ret #9.1
--
Summary: Incorrect sse2_cvtX2Y pattern
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43618
[Bug other/43617] cloog-ppl 0.15.9's configure corrupts with funny codes
--- Comment #2 from aflyhorse at foxmail dot com 2010-04-01 13:42 --- Sorry sir I've made a mistake... But since I've successfully build gmp & mpfr & mpc & ppl so i think there might be an error here... I configured it with: ../src/configure --build=x86_64-w64-mingw32 --with-ppl="" --with-gmp="" --prefix="" --with-host-libstdcxx="-lstdc++ -lsupc++" --disable-shared --enable-static CFLAGS="-O3 -fomit-frame-pointer -pipe -march=k8 -mfpmath=sse -m64 -Wa,-march=k8 -Wa,-mtune=k8" LDFLAGS="-s -Wl,--as-needed" it works for me on cloog-ppl 0.15.8 so i think it's a mistake of the tarball at that time... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43617
[Bug other/43617] cloog-ppl 0.15.9's configure corrupts with funny codes
--- Comment #3 from redi at gcc dot gnu dot org 2010-04-01 13:46 --- (In reply to comment #2) > I configured it with: > ../src/configure --build=x86_64-w64-mingw32 --with-ppl="" --with-gmp="" > --prefix="" that can't be right -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43617
[Bug target/43610] [4.5 Regression] ICE: in prepare_float_lib_cmp, at optabs.c:4392 with -fno-trapping-math and _Decimal64 comparison
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-01 13:48 --- Because we only have an optab for LT (reversed UNGE), but FLOAT_LIB_COMPARE_RETURNS_BOOL is false. Without -fno-trapping-math we use LT from the start which works. I suppose FLOAT_LIB_COMPARE_RETURNS_BOOL should return true for decimal float modes on x86? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-01 13:48:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43610
[Bug target/42886] [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)
--- Comment #9 from aflyhorse at foxmail dot com 2010-04-01 13:48 --- (In reply to comment #8) > I'd recommend closing this as invalid. We build 12 relocatable toolchains for > windows daily for http://mingw-w64.sf.net/ > > I'm pretty sure it works :) > Agree. I've made a bootstrap a week before and copied and merged it with the dev-cpp. Before i did this version i've moved a cross-compiled version from /msys/1.0/mingw64 to /msys/1.0/mingw for pretty look :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #14 from joel at gcc dot gnu dot org 2010-04-01 13:49 --- I am starting the regression hunt. Don't worry about it Ralf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug tree-optimization/42963] [4.5 Regression] Redundant switch labels not cleaned up anymore
--- Comment #3 from steven at gcc dot gnu dot org 2010-04-01 13:51 --- How is the polishing going? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42963
[Bug target/43610] [4.5 Regression] ICE: in prepare_float_lib_cmp, at optabs.c:4392 with -fno-trapping-math and _Decimal64 comparison
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-01 13:51 --- And I believe the regression is because of either cond-optab or expand-from-SSA which causes us no longer to fallback to expand a UNORD b || a >= b. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org, matz ||at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43610
[Bug lto/43609] LTO -fwhopr generating shared library: ICE in csi_node at cgraph.h:663
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-01 13:53 --- This is just PR41584 I think. *** This bug has been marked as a duplicate of 41584 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43609
[Bug lto/41584] WHOPR doesn't grok empty units
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-01 13:53 --- *** Bug 43609 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rwild at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41584
[Bug c++/43608] Boost.MPL code doesn't get the placeholders substituted anymore
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-01 13:56 --- EDG accepts the reduced testcase in strict mode. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43608
[Bug target/42886] [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)
--- Comment #10 from aflyhorse at foxmail dot com 2010-04-01 13:58 --- night-strike can i ask a question that had x86_64-w64-mingw32 supported libgcj yet? I failed even explictly --enable-libgcj... and a so-called wiki of mingw-w64 (http://www.cadforte.com/wiki/index.php/Java) said "Java is, unfortunately, not supported in 64-bit by gcc at this time.", i don't know if it's true... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
[Bug target/43610] [4.5 Regression] ICE: in prepare_float_lib_cmp, at optabs.c:4392 with -fno-trapping-math and _Decimal64 comparison
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-01 13:59 --- (In reply to comment #1) > Because we only have an optab for LT (reversed UNGE), but > FLOAT_LIB_COMPARE_RETURNS_BOOL is false. > > Without -fno-trapping-math we use LT from the start which works. > > I suppose FLOAT_LIB_COMPARE_RETURNS_BOOL should return true for decimal > float modes on x86? > I don't think so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43610
[Bug tree-optimization/43607] [4.3/4.4/4.5 Regression] ICE in gimple_op, at gimple.h:1633 with -fipa-type-escape
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-01 14:03 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Component|middle-end |tree-optimization Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to work||4.2.4 Last reconfirmed|-00-00 00:00:00 |2010-04-01 14:03:13 date|| Summary|ICE in gimple_op, at|[4.3/4.4/4.5 Regression] ICE |gimple.h:1633 with -fipa- |in gimple_op, at |type-escape |gimple.h:1633 with -fipa- ||type-escape Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43607
[Bug tree-optimization/43607] [4.3/4.4/4.5 Regression] ICE in gimple_op, at gimple.h:1633 with -fipa-type-escape
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-01 14:06 --- Subject: Bug 43607 Author: rguenth Date: Thu Apr 1 14:05:49 2010 New Revision: 157911 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157911 Log: 2010-04-01 Richard Guenther PR tree-optimization/43607 * ipa-type-escape.c (check_call): Do not access non-existing arguments. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-type-escape.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43607
[Bug tree-optimization/43607] [4.3/4.4 Regression] ICE in gimple_op, at gimple.h:1633 with -fipa-type-escape
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-01 14:06 --- Fixed on trunk sofar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.2.4 |4.2.4 4.5.0 Summary|[4.3/4.4/4.5 Regression] ICE|[4.3/4.4 Regression] ICE in |in gimple_op, at|gimple_op, at gimple.h:1633 |gimple.h:1633 with -fipa- |with -fipa-type-escape |type-escape | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43607
[Bug target/43618] Incorrect sse2_cvtX2Y pattern
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-01 14:16 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-04-01 14:16:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43618
[Bug target/42886] [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-04-01 14:18 --- Invalid then. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
[Bug tree-optimization/43614] [4.4/4.5 Regression] ice in gimple_rhs_has_side_effects, at gimple.c:2248
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-01 14:21 --- Looks like a tuples issue in IVOPTs. Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |tree-optimization Known to fail||4.4.3 4.5.0 Known to work||4.3.4 Summary|[4.5 Regression] ice in |[4.4/4.5 Regression] ice in |gimple_rhs_has_side_effects,|gimple_rhs_has_side_effects, |at gimple.c:2248|at gimple.c:2248 Target Milestone|4.5.0 |4.4.4 Version|unknown |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43614
[Bug tree-optimization/43614] [4.4/4.5 Regression] ice in gimple_rhs_has_side_effects, at gimple.c:2248
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-04-01 03:07:50 |2010-04-01 14:22:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43614
[Bug tree-optimization/43614] [4.4/4.5 Regression] ice in gimple_rhs_has_side_effects, at gimple.c:2248
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-01 14:35 --- The issue is that build6 looks at TMR_SYMBOL to set TREE_SIDE_EFFECTS, but really TMRs volatileness or side-effectness depends on the original reference it was created from, not TMR_SYMBOL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43614
[Bug c++/43608] Boost.MPL code doesn't get the placeholders substituted anymore
--- Comment #5 from jason at gcc dot gnu dot org 2010-04-01 14:47 --- My copy of EDG 4.1 does not accept the reduced testcase; it gives the same error as GCC 4.5. "red.cc", line 111: error: class "arg<2>" has no member "inner_type" typedef typename Foo::inner_type type; ^ detected during: instantiation of class "metafunction [with Foo=arg<2>]" at line 83 instantiation of class "template_arity_impl [with F=metafunction>, N=1]" at line 91 instantiation of class "template_arity [with F=metafunction>]" at line 116 We instantiate metafunction> for argument-dependent lookup of the call to arity_helper(type_wrapper). 3.4.2 says that if an argument type is a class template specialization, we consider the associated classes and namespaces of the template arguments, which in this case means F, or metafunction>. And in order to perform that lookup, we instantiate metafunction>. Providing the explicit specialization prevents the implicit instantiation, so argument-dependent lookup just doesn't consider that scope. This is also fully conformant. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43608
[Bug c++/43608] Boost.MPL code doesn't get the placeholders substituted anymore
--- Comment #6 from jason at gcc dot gnu dot org 2010-04-01 14:59 --- Another way to fix the testcase would be to give an explicit scope for arity_helper, so argument-dependent lookup isn't needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43608
[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)
--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-04-01 15:02 --- This is a miscompilation during stage2. The file libcpp/expr.c is miscompiled. The problem is occurring in num_positive, which ends up generating a shift of a long long right by 63. The code generated is creating spills that are of SImode variables for the shift output, but then the result is being loaded back as a DImode object. Due to scheduling, one of the stores is being moved incorrectly after the load and we get the following assembly fragment: 342c: fa2b fb02 lsr.w fp, fp, r2 3430: fa0c f003 lsl.w r0, ip, r3 3434: fa2c f301 lsr.w r3, ip, r1 3438: fa2c f202 lsr.w r2, ip, r2 343c: ea40 000b orr.w r0, r0, fp 3440: 9245str r2, [sp, #276] ; 0x114 <- first part of store 3442: 4686mov lr, r0 3444: 2201movsr2, #1 3446: ea1e 0e21 ands.w lr, lr, r1, asr #32 344a: bf38it cc 344c: 469emovcc lr, r3 344e: a944add r1, sp, #272; 0x110 3450: e9d1 0100 ldrdr0, r1, [r1] <- Load back 3454: 2300movsr3, #0 3456: f8cd e110 str.w lr, [sp, #272] ; 0x110 <- Second part (oops, too late). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[Bug bootstrap/43619] New: Bootstrap failure: "/lib/cpp" fails sanity check
There is no /lib/cpp. There doesn't seem to be any need to run any C++ in stage 1 anyway. checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking how to run the C++ preprocessor... /lib/cpp configure: error: in `/cygdrive/c/jimdata/home/cvsroot/gcc-obj/gcc': configure: error: C++ preprocessor "/lib/cpp" fails sanity check See `config.log' for more details. make[1]: *** [configure-gcc] Error 1 make[1]: Leaving directory `/cygdrive/c/jimdata/home/cvsroot/gcc-obj' make: *** [all] Error 2 uname -a CYGWIN_NT-5.1 mckelvey-xp 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin BUILDING: alias CONFIGURECVS='/cygdrive/c/jimdata/home/cvsroot/gcc/configure --verbose --enable-threads --disable-nls --enable-checking=release --disable-win32-registry --disable-sjlj-exceptions --disable-bootstrap --enable-languages=c,c++ 2>&1 | tee clog' alias BUILD='nice make CFLAGS='\'''\'' BOOT_CFLAGS='\'''\'' LIBCFLAGS='\''-g -O'\'' CXXFLAGS='\''-O'\'' LIBCXXFLAGS='\''-g -O'\'' 2>&1 | tee log' I'll attach the full log and the log from configure. -- Summary: Bootstrap failure: "/lib/cpp" fails sanity check Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mckelvey at maskull dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43619
[Bug bootstrap/43619] Bootstrap failure: "/lib/cpp" fails sanity check
--- Comment #1 from mckelvey at maskull dot com 2010-04-01 15:09 --- Created an attachment (id=20275) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20275&action=view) Output from ./configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43619
[Bug bootstrap/43619] Bootstrap failure: "/lib/cpp" fails sanity check
--- Comment #2 from mckelvey at maskull dot com 2010-04-01 15:10 --- Created an attachment (id=20276) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20276&action=view) Log from ./configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43619
[Bug bootstrap/43619] Bootstrap failure: "/lib/cpp" fails sanity check
--- Comment #3 from mckelvey at maskull dot com 2010-04-01 15:10 --- Created an attachment (id=20277) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20277&action=view) Log from bootstrap -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43619
[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)
--- Comment #10 from rearnsha at gcc dot gnu dot org 2010-04-01 15:11
---
Insn sequence from postreload dump (order is correct):
(insn 4979 1883 4589 173 /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c:1281
(set (mem/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 276 [0x114])) [87 %sfp+-540 S4 A64])
(reg:SI 2 r2)) 585 {*thumb2_movsi_vfp} (nil))
(insn 4589 4979 4980 173 /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c:1281
(set (reg:DI 2 r2 [1071])
(const_int 1 [0x1])) 587 {*thumb2_movdi_vfp} (expr_list:REG_EQUIV
(const_int 1 [0x1])
(nil)))
(insn 4980 4589 4981 173 /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c:1281
(set (reg:SI 1 r1)
(plus:SI (reg/f:SI 13 sp)
(const_int 272 [0x110]))) 4 {*arm_addsi3} (nil))
(insn 4981 4980 1885 173 /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c:1281
(set (reg:DI 0 r0)
(mem/c:DI (reg:SI 1 r1) [87 %sfp+-544 S8 A64])) 587 {*thumb2_movdi_vfp}
(nil))
(insn 1885 4981 1887 173 /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c:1281
(set (reg:DI 2 r2 [1070])
(and:DI (reg:DI 2 r2 [1071])
(reg:DI 0 r0))) 64 {anddi3} (expr_list:REG_EQUAL (and:DI (mem/c:DI
(plus:SI (reg/f:SI 13 sp)
(const_int 272 [0x110])) [87 %sfp+-544 S8 A64])
(const_int 1 [0x1]))
(nil)))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[Bug c++/43608] Boost.MPL code doesn't get the placeholders substituted anymore
--- Comment #7 from sefi at s-e-f-i dot de 2010-04-01 15:21 --- Thank you all very much. Explicitly scoping arity_helper indeed fixes the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43608
[Bug bootstrap/43619] Bootstrap failure: "/lib/cpp" fails sanity check
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-04-01 15:25 --- >--disable-bootstrap What happens if you remove that part? Disabling bootstrap for native builds are not really supported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43619
[Bug target/42886] [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)
--- Comment #12 from nightstrike at gmail dot com 2010-04-01 15:27 --- (In reply to comment #10) > night-strike can i ask a question that had x86_64-w64-mingw32 supported libgcj > yet? I failed even explictly --enable-libgcj... and a so-called wiki of > mingw-w64 (http://www.cadforte.com/wiki/index.php/Java) said "Java is, > unfortunately, not supported in 64-bit by gcc at this time.", i don't know if > it's true... > This is kind of off topic for this bug, and I invite you to use our resources at mingw-w64.sf.net (mailing list, forum, irc). As for java, libffi works, and boehm-gc works. Those are dependencies for java. I don't know if the in-tree boehm-gc was ever updated from upstream, so you might have to do that manually (the in-tree version was very out of date when we were porting it). As for libgcj itself I never tried to build it. I can try, and we can work on it if you like. Please take replies to one of the aforementioned places. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)
--- Comment #11 from rearnsha at gcc dot gnu dot org 2010-04-01 15:32 --- Created an attachment (id=20278) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20278&action=view) compressed source for bug Compiled with /home/rearnsha/gnu/gcc/trunkd16/./stage1-gcc/xgcc -B/home/rearnsha/gnu/gcc/trunkd16/./stage1-gcc/ -B/usr/local/armv7l-unknown-linux-gnueabi/bin/ -B/usr/local/armv7l-unknown-linux-gnueabi/bin/ -B/usr/local/armv7l-unknown-linux-gnueabi/lib/ -isystem /usr/local/armv7l-unknown-linux-gnueabi/include -isystem /usr/local/armv7l-unknown-linux-gnueabi/sys-include -I/home/rearnsha/gnusrc/gcc/trunk/libcpp -I. -I/home/rearnsha/gnusrc/gcc/trunk/libcpp/../include -I/home/rearnsha/gnusrc/gcc/trunk/libcpp/include -g -O2 -W -Wall -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -pedantic -Wno-long-long -Werror -I/home/rearnsha/gnusrc/gcc/trunk/libcpp -I. -I/home/rearnsha/gnusrc/gcc/trunk/libcpp/../include -I/home/rearnsha/gnusrc/gcc/trunk/libcpp/include -c -o expr.o -MT expr.o -MMD -MP -MF .deps/expr.Tpo /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c -save-temps Note, compiler was configured with: '--with-cpu=cortex-a9' '--with-fpu=vfpv3-d16' '--with-float=softfp' '--with-mode=thumb' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[Bug target/43610] [4.5 Regression] ICE: in prepare_float_lib_cmp, at optabs.c:4392 with -fno-trapping-math and _Decimal64 comparison
--- Comment #4 from hjl dot tools at gmail dot com 2010-04-01 15:37 --- It is caused by revision 149031: http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg01016.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43610
[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*
--- Comment #17 from bonzini at gnu dot org 2010-04-01 15:42 --- Subject: Re: ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin* On 04/01/2010 01:27 PM, howarth at nitro dot med dot uc dot edu wrote: > --- Comment #14 from howarth at nitro dot med dot uc dot edu 2010-04-01 > 11:27 --- > Reverting back to... > > TREE_PUBLIC (ic_void_ptr_var) = 0; > > in the proposed patch results in the missing symbols again. > Can we just leave... > > TREE_PUBLIC (ic_void_ptr_var) = 1; No, I don't see how this can be correct. The symbols must _not_ be coalesced, that's why TREE_PUBLIC is zero. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43602
[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)
--- Comment #12 from ramana at gcc dot gnu dot org 2010-04-01 15:55 ---
I see this on arm-eabi cross with gcc version 4.5.0 20100401 (experimental)
[trunk revision 157899] (GCC)
With the following command line options -
./xgcc -B`pwd` -S -O2 -mthumb -mcpu=cortex-a9 -mfpu=vfpv3-d16 ~/expr.i -da -g
In 203r.sched2 I see the following insn sequence which appears to be wrong to
my naked eye.
(insn 5045 1929 5046 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (set (reg:SI 1
r1)
(plus:SI (reg/f:SI 13 sp)
(const_int 272 [0x110]))) 4 {*arm_addsi3} (nil))
(insn:TI 5046 5045 6004 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (set
(reg:DI 0 r0)
(mem/c:DI (reg:SI 1 r1) [87 %sfp S8 A64])) 587 {*thumb2_movdi_vfp}
(nil))
(insn 6004 5046 5042 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (parallel [
(set (reg:SI 3 r3 [+4 ])
(const_int 0 [0x0]))
(clobber (reg:CC 24 cc))
]) 704 {*thumb2_movsi_shortim} (expr_list:REG_UNUSED (reg:CC 24 cc)
(nil)))
(insn:TI 5042 6004 6002 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (set
(mem/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 272 [0x110])) [87 %sfp+-544 S4 A64])
(reg:SI 14 lr)) 585 {*thumb2_movsi_vfp} (expr_list:REG_DEAD (reg:SI 14
lr)
(nil)))
(insn:TI 6002 5042 6003 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (parallel [
(set (reg:SI 3 r3 [+4 ])
(and:SI (reg:SI 3 r3 [+4 ])
(reg:SI 1 r1 [+4 ])))
(clobber (reg:CC 24 cc))
]) 700 {*thumb2_alusi3_short} (expr_list:REG_DEAD (reg:SI 1 r1 [+4 ])
(expr_list:REG_UNUSED (reg:CC 24 cc)
(nil
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[Bug tree-optimization/43611] [4.5 Regression] ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions
--- Comment #4 from jason at redhat dot com 2010-04-01 15:55 --- Subject: Re: [4.5 Regression] ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions On 04/01/2010 09:39 AM, rguenth at gcc dot gnu dot org wrote: > The issue seems to be the C++ frontend marking inline functions needed > at cp/semantics.c:3452 while the middle-end should already take care > of that in cgraph_decide_is_function_needed. Another example of why I've been thinking about reworking all the C++ front end linkage code to play better with cgraph... > The following "fixes" it, but arguably the bug must then be latent > with dllexport. The patch looks OK since cgraph_decide_is_function_needed handles flag_keep_inline_functions. I'm not sure why doing this here would be a problem, however; mark_needed ends up calling cgraph_mark_needed_node, which really ought to be a reasonable way to indicate that a function is needed... Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43611
[Bug fortran/43591] PPC: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #11 from dominiq at lps dot ens dot fr 2010-04-01 15:57 --- The patch in comment #8 fixes the ICEs for the various reduced tests, however for the original code I get ward.f90:405.19: end module ward_lib 1 Internal Error at (1): gfc_is_constant_expr(): Unknown expression type -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug bootstrap/43619] Bootstrap failure: "/lib/cpp" fails sanity check
--- Comment #5 from schwab at linux-m68k dot org 2010-04-01 15:59 --- You have a bad c++ in your path: configure:4892: checking whether we are using the GNU C++ compiler configure:4911: c++ -c conftest.cpp >&5 /usr/local/libexec/gcc/i686-pc-cygwin/4.5.0/cc1plus.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory configure:4911: $? = 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43619
[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2010-04-01 16:00 --- Paolo, Is there any other debug info I can provide (on gcc trunk pre-reversion) to help debug this issue? Also could you switch an x86_64 linux build of gcc trunk over to using emutls and try to reproduce it under ELF? Jack -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43602
[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*
--- Comment #19 from bonzini at gnu dot org 2010-04-01 16:01 --- No, I don't have time to debug this further, sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43602
[Bug bootstrap/43619] Bootstrap failure: "/lib/cpp" fails sanity check
--- Comment #6 from schwab at linux-m68k dot org 2010-04-01 16:05 --- AC_PROG_CXX was added with the --enable-build-with-cxx support. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43619
[Bug target/43610] [4.5 Regression] ICE: in prepare_float_lib_cmp, at optabs.c:4392 with -fno-trapping-math and _Decimal64 comparison
--- Comment #5 from bonzini at gnu dot org 2010-04-01 16:10 --- Created an attachment (id=20279) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20279&action=view) patch Here is a totally untested patch... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43610
[Bug rtl-optimization/21803] [ia64] gcc produces really odd predicated code
--- Comment #6 from steven at gcc dot gnu dot org 2010-04-01 16:17 --- I am testing this patch on ia64 now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21803
[Bug tree-optimization/43614] [4.4/4.5 Regression] ice in gimple_rhs_has_side_effects, at gimple.c:2248
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-01 16:18 --- Subject: Bug 43614 Author: rguenth Date: Thu Apr 1 16:18:07 2010 New Revision: 157913 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157913 Log: 2010-04-01 Richard Guenther PR middle-end/43614 * tree-ssa-address.c (copy_mem_ref_info): Copy TREE_SIDE_EFFECTS and TREE_THIS_VOLATILE. (copy_ref_info): Likewise. * tree-ssa-operands.c (get_tmr_operands): Check TREE_THIS_VOLATILE. * tree.c (build6_stat): Ignore side-effects of all but arg5 for TARGET_MEM_REF. Set TREE_THIS_VOLATILE from arg5 of TARGET_MEM_REF. * gcc.c-torture/compile/pr43614.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr43614.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-address.c trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree-ssa-operands.c trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43614
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #9 from jb at gcc dot gnu dot org 2010-04-01 16:23 --- Subject: Bug 43605 Author: jb Date: Thu Apr 1 16:22:57 2010 New Revision: 157914 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157914 Log: PR libfortran/43605 Fix FTELL for formatted files Added: trunk/gcc/testsuite/gfortran.dg/ftell_3.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug tree-optimization/43614] [4.4 Regression] ice in gimple_rhs_has_side_effects, at gimple.c:2248
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-01 16:25 --- Fixed on trunk sofar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.4.3 4.5.0 |4.4.3 Known to work|4.3.4 |4.3.4 4.5.0 Summary|[4.4/4.5 Regression] ice in |[4.4 Regression] ice in |gimple_rhs_has_side_effects,|gimple_rhs_has_side_effects, |at gimple.c:2248|at gimple.c:2248 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43614
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #10 from jb at gcc dot gnu dot org 2010-04-01 16:31 --- Subject: Bug 43605 Author: jb Date: Thu Apr 1 16:31:01 2010 New Revision: 157915 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157915 Log: PR libfortran/43605 FTELL incorrect for formatted files. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/ftell_3.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug bootstrap/43328] multilib bootstrap broken.
--- Comment #17 from rwild at gcc dot gnu dot org 2010-04-01 16:32 --- Subject: Bug 43328 Author: rwild Date: Thu Apr 1 16:32:38 2010 New Revision: 157916 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157916 Log: /: PR bootstrap/43615 PR bootstrap/43328 Revert: 2010-03-31 Ralf Wildenhues * configure.ac: Do not pass --enable-multilib nor --disable-multilib in baseargs. Accept explicitly passed --enable_multilib. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43328
[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
--- Comment #8 from rwild at gcc dot gnu dot org 2010-04-01 16:32 --- Subject: Bug 43615 Author: rwild Date: Thu Apr 1 16:32:38 2010 New Revision: 157916 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157916 Log: /: PR bootstrap/43615 PR bootstrap/43328 Revert: 2010-03-31 Ralf Wildenhues * configure.ac: Do not pass --enable-multilib nor --disable-multilib in baseargs. Accept explicitly passed --enable_multilib. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #11 from jb at gcc dot gnu dot org 2010-04-01 16:34 --- Fixed, closing. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
--- Comment #9 from rwild at gcc dot gnu dot org 2010-04-01 16:40 --- Fixed by reverting the offending patch. -- rwild at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-01 16:43 --- The following test integer i character*99 buffer open(10,FILE="telltest.txt") call ftell(10,i) print*,i read(10,'(a)') buffer print *, "'",trim(buffer),"'" call ftell(10,i) print*,i read(10,*) buffer print *, "'",trim(buffer),"'" call ftell(10,i) print*,i close(10) end gives 0 '123456' 7 'D' 113 I would expect '789' and 10. Am I wrong? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
