[Bug fortran/43179] ICE invalid if accessing array member of non-array
--- Comment #7 from pault at gcc dot gnu dot org 2010-07-18 07:09 --- (In reply to comment #2) > (In reply to comment #1) > > This fixes it and regtests. > > + if (array->expr_type != EXPR_VARIABLE && array->expr_type != > > EXPR_FUNCTION) > > The patch looks OK, but actually I fail to see when an EXPR_FUNCTION is valid > in this case. If I try: Try allocatable_scalar_5.f90 Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43179
[Bug c/44961] size_t typedef failure
--- Comment #2 from aj at member dot fsf dot org 2010-07-18 08:24 --- (In reply to comment #1) > Looks like a bug in antlr3. > Yes, it seems that something was wrong with my build configuration. Sorry! -- aj at member dot fsf dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44961
[Bug target/44974] Function with attribute noreturn omits a call to another function with noreturn
--- Comment #1 from mikpe at it dot uu dot se 2010-07-18 09:09 --- I see the same with gcc-4.6 -O1 built natively on armv5tel-linux-gnueabi. With -O0/-O2/-Os or 4.5/4.4 -O1 foo1() calls _Exit() as it should. Thus a regression. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44974
[Bug fortran/44868] [OOP] Error recovery: ICE after invalid TBP call
--- Comment #5 from janus at gcc dot gnu dot org 2010-07-18 09:23 ---
(In reply to comment #3)
> At revision 162276, I get
>
> pr44868.f90:245.24:
>
> tst_case => self%list(i)
> 1
> Error: Pointer assignment target is neither TARGET nor POINTER at (1)
Dominique, I think you're compiling the wrong code. There is no "tst_case" in
comment #0.
On the test case in comment #0 I currently get:
c0.f90:59.22:
call suite%add("second_test", test_b)
1
Error: 'add' at (1) is not a member of the 'test_suite' structure
c0.f90:70.11:
use my_test
1
Fatal Error: Can't open module file 'my_test.mod' for reading at (1): No such
file or directory
The error message is correct. As long as there is no ICE (and no valgrind
errors), this PR can be closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44868
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #14 from mikpe at it dot uu dot se 2010-07-18 09:57 --- gcc-4.6 r162277 bootstrap failure on i686-linux: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/dwarf2out.o differs gcc/reg-stack.o differs gcc/reload.o differs gcc/recog.o differs gcc/i386.o differs libiberty/hashtab.o differs make[2]: *** [compare] Error 1 Configured just with --enable-languages=c and --with-gmp/mpfr/mpc paths. Reverting r162270 fixes it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug fortran/44868] [OOP] Error recovery: ICE after invalid TBP call
--- Comment #6 from dominiq at lps dot ens dot fr 2010-07-18 10:22 --- > Dominique, I think you're compiling the wrong code. Yes, it was the invalid version in pr44869. With the code in comment #0 I also get Error: 'add' at (1) is not a member of the 'test_suite' structure without ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44868
[Bug lto/44533] [4.6 Regression] Revision 160679 miscompiles capacita.f90 with -O3 -finline-limit=600 -flto
--- Comment #2 from dominiq at lps dot ens dot fr 2010-07-18 10:44 --- Silently fixed since at least revision 161009. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44533
[Bug c/43797] __attribute__((deprecated("message"))) produces unexpected messages in some cases.
--- Comment #3 from iains at gcc dot gnu dot org 2010-07-18 11:52 --- http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01432.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43797
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #15 from mikpe at it dot uu dot se 2010-07-18 11:55 --- And on powerpc64-linux with gcc-4.6 r162277: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/tree-ssa.o differs libiberty/regex.o differs make[2]: *** [compare] Error 1 Configured just with --with-cpu=default32 --enable-languages=c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #16 from mikpe at it dot uu dot se 2010-07-18 12:31 --- And on sparc64-linux with gcc-4.6 r162277: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! libdecnumber/decimal32.o differs libdecnumber/decimal64.o differs libdecnumber/decimal128.o differs make[2]: *** [compare] Error 1 Configured just --with-cpu=v8 --enable-languages=c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug c/44598] -Wunused-variable miss 'static const char x[] = "";'
--- Comment #5 from dimhen at gmail dot com 2010-07-18 12:40 --- 'functions as designed' -- dimhen at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44598
[Bug tree-optimization/26939] loop number of iterations analysis not working
--- Comment #24 from dimhen at gmail dot com 2010-07-18 12:56 ---
is this the same problem? -- 'i*2 < 35' can't overflow
void
foo(char *ptr, unsigned size)
{
unsigned i;
for(i=0; i*2 < size && i*2 < 35; i++ ) {
*ptr++ = 0;
}
}
# gcc -Wunsafe-loop-optimizations -O3 -c unsafe_loop.c
unsafe_loop.c: In function foo:
unsafe_loop.c:5:5: warning: cannot optimize loop, the loop counter may overflow
[-Wunsafe-loop-optimizations]
gcc/x86/[trunk revision 162274]
--
dimhen at gmail dot com changed:
What|Removed |Added
CC||dimhen at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug c/44975] Stack trashed by call inside inline asm
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-18 13:31 --- You need to in the inline asm subtract 128 from rsp, do the call, then add it back. -- 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=44975
[Bug fortran/44978] New: extended derived types are resolved more than once
Consider the following test case: type :: t1 type(xy),pointer :: c end type t1 type, extends(t1) :: t2 end type type, extends(t2) :: t3 end type end This is correctly rejected with: type(xy),pointer :: c 1 Error: The pointer component 'c' of 't1' at (1) is a type that has not been declared The problem is that the error message occurs three times (or even more, if one adds further types which extend upon t1), because resolve_fl_derived is called more than once for the base type. -- Summary: extended derived types are resolved more than once Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44978
[Bug c/44977] [4.4/4.5/4.6 Regression] ice in propagate_rhs_into_lhs, at tree-ssa-dom.c:2728
-- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-18 14:42:54 date|| Summary|ice in |[4.4/4.5/4.6 Regression] ice |propagate_rhs_into_lhs, at |in propagate_rhs_into_lhs, |tree-ssa-dom.c:2728 |at tree-ssa-dom.c:2728 Version|unknown |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44977
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #17 from danglin at gcc dot gnu dot org 2010-07-18 15:20 --- And on hppa64-hp-hpux11.11 gcc-4.6 162277 in stage2: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/g cc-4.6.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11 /lib/ -isystem /opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/include -isystem /op t/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/sys-include-g -O2 -O2 -g -O2 -DIN _GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-protot ypes -Wold-style-definition -isystem ./include -fPIC -Dpa64=1 -DELF=1 -mlong-c alls -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I.. /.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/.. /gcc -I../../../gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _popcountdi 2.o -MT _popcountdi2.o -MD -MP -MF _popcountdi2.dep -DL_popcountdi2 -c ../../../ gcc/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../gcc/libgcc/../gcc/libgcc2.c: In function '__popcountsi2':../../../gcc/l ibgcc/../gcc/libgcc2.c: In function '__popcountdi2': ../../../gcc/libgcc/../gcc/libgcc2.c:791:1: internal compiler error: Segmentatio n fault -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #18 from hjl dot tools at gmail dot com 2010-07-18 15:22 --- (In reply to comment #3) > x86_64 failures are expected due to a backend bug, see the patch I sent today. > > HJ, any chance you could run make check on the stage1 compiler on ia64 to find > a testcase? > New failures from revision 162264 to 162270 are: FAIL: gcc.dg/20020425-1.c (internal compiler error) FAIL: gcc.dg/20020425-1.c (test for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug target/44974] Function with attribute noreturn omits a call to another function with noreturn
--- Comment #2 from mikpe at it dot uu dot se 2010-07-18 16:07 --- Not ARM-specific. The same failure occurs for i686/powerpc64/sparc64-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44974
[Bug fortran/44353] rejects legal fortran
--- Comment #3 from pault at gcc dot gnu dot org 2010-07-18 16:16 --- Subject: Bug 44353 Author: pault Date: Sun Jul 18 16:15:43 2010 New Revision: 162286 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162286 Log: 2010-07-18 Paul Thomas PR fortran/44353 * match.c (gfc_match_iterator): Remove error that iterator cannot be INTENT(IN). 2010-07-18 Paul Thomas PR fortran/44353 * gfortran.dg/data_implied_do_2.f03 : New test. Added: trunk/gcc/testsuite/gfortran.dg/data_implied_do_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44353
[Bug fortran/44962] [OOP] ICE with specification expression SIZE()
-- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-18 16:17:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44962
[Bug middle-end/31980] ICE in cancel_option() for Negative marked options
--- Comment #3 from John dot Tytgat at aaug dot net 2010-07-18 17:11 --- I'm updating my port for 4.6trunk and this gcc problem is still there. My suggested patch in comment #1 is still applicable and attached it after having brought up-to-date for trunk. ChangeLog: John Tytgat * gcc/opts-common.c (cancel_option): Don't recurse for Negative marked options. -- John dot Tytgat at aaug dot net changed: What|Removed |Added Status|WAITING |UNCONFIRMED Summary|ICE in cancel_option() |ICE in cancel_option() for ||Negative marked options http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31980
[Bug middle-end/31980] ICE in cancel_option() for Negative marked options
--- Comment #4 from John dot Tytgat at aaug dot net 2010-07-18 17:13 --- Created an attachment (id=21241) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21241&action=view) Fix ICE in cancel_option() by repreventing a recursive call for Negative marked option -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31980
[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-18 17:21 ---
It looks like a store is scheduled wrong.
Slightly reduced test case:
-- 8< #define vector
__attribute__((vector_size(16) ))
vector int f1(vector int t, int a)
{
((int*)&t)[1] = a;
return t;
}
int main(void)
{
vector int a = {0, 0, 0, 0};
vector int c = {0, 1, 0, 0};
vector int a0;
a0 = f1(a, 1);
if (memcmp (&a0, &c, sizeof(a0)))
__builtin_abort ();
return 0;
}
-- 8<
Compiled at "-O2 -fno-inline -fpic" this will abort. The assembler output for
f1 is this:
6 .global f1#
7 .type f1#, @function
8 .proc f1#
9 f1:
10 .prologue
11 .body
12 .mmi
13 mov r15 = r12
14 nop 0
15 mov r14 = r12
16 ;;
17 .mmi
18 st8 [r15] = r32, 8
19 ;;
20 st8 [r15] = r33, -4
21 nop 0
22 .mii
23 ld8 r8 = [r14], 8
24 nop 0
25 ;;
26 nop 0
27 .mmb
28 ld8 r9 = [r14]
29 st4 [r15] = r34
30 br.ret.sptk.many b0
31 .endp f1#
The store on line 29 looked suspicious because the three stores (lines 18, 20,
and 29) are together in the unscheduled version (i.e. with
-fno-schedule-insns2, lines 15, 17, and 19):
6 .global f1#
7 .type f1#, @function
8 .proc f1#
9 f1:
10 .prologue
11 .body
12 mov r15 = r12
13 mov r14 = r12
14 ;;
15 st8 [r15] = r32, 8
16 ;;
17 st8 [r15] = r33, -4
18 ;;
19 st4 [r15] = r34
20 ld8 r8 = [r14], 8
21 ;;
22 ld8 r9 = [r14]
23 br.ret.sptk.many b0
24 ;;
25 .endp f1#
The abort goes away if I hack the assembly manually with an extra bundle to
move the three stores back together:
.global f1# .global f1#
.type f1#, @function .type f1#, @function
.proc f1# .proc f1#
f1: f1:
.prologue .prologue
.body .body
.mmi.mmi
mov r15 = r12 mov r15 = r12
nop 0 nop 0
mov r14 = r12 mov r14 = r12
;; ;;
.mmi.mmi
st8 [r15] = r32, 8 st8 [r15] = r32, 8
;; ;;
st8 [r15] = r33, -4 st8 [r15] = r33, -4
nop 0 nop 0
> ;;
> .mii
> st4 [r15] = r34
> nop 0
> nop 0
.mii.mii
ld8 r8 = [r14], 8 ld8 r8 = [r14], 8
nop 0 nop 0
;; ;;
nop 0 nop 0
.mmb.mmb
ld8 r9 = [r14] ld8 r9 = [r14]
st4 [r15] = r34 | nop 0
br.ret.sptk.many b0 br.ret.sptk.many b0
.endp f1# .endp f1#
I am not an ia64 expert, but I see no reason why moving the store is a bad
idea. Will have to look at the RTL, and if that doesn't help I'll leave this to
a target specialist.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
--- Comment #6 from steven at gcc dot gnu dot org 2010-07-18 17:29 --- Smaller hand-changed assembly without new bundle (left aborts, right does not): .global f1# .global f1# .type f1#, @function .type f1#, @function .proc f1# .proc f1# f1: f1: .prologue .prologue .body .body .mmi.mmi mov r15 = r12 mov r15 = r12 nop 0 nop 0 mov r14 = r12 mov r14 = r12 ;; ;; .mmi.mmi st8 [r15] = r32, 8 st8 [r15] = r32, 8 ;; ;; st8 [r15] = r33, -4 st8 [r15] = r33, -4 nop 0 nop 0 .mii | ;; > .mmb > st4 [r15] = r34 > ;; ld8 r8 = [r14], 8 ld8 r8 = [r14], 8 nop 0 < ;; ;; nop 0 nop 0 .mmb.mmb ld8 r9 = [r14] ld8 r9 = [r14] st4 [r15] = r34 | nop 0 br.ret.sptk.many b0 br.ret.sptk.many b0 .endp f1# .endp f1# The only thing that seems to matter, is that "st4 [r15] = r34" comes before "ld8 r9 = [r14]". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
--- Comment #7 from steven at gcc dot gnu dot org 2010-07-18 17:40 --- Ah, and since both r14 and r15 are initially copies of r12, they point to the same memory area (modulo auto-increments/decrements). So indeed an alias thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug middle-end/29256] [4.3/4.4/4.5/4.6 regression] loop performance regression
--- Comment #34 from rguenth at gcc dot gnu dot org 2010-07-18 17:49 --- In particular we are now back to generating the very bogus ivtmp.10_12 = (long unsigned int) &a[-1]; ivtmp.16_15 = (long unsigned int) &c[-1]; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||sandra at codesourcery dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug debug/44971] [4.6 Regression] -fcompare-debug failure with uninitialized read in walk_gimple_stmt
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-18 17:50 --- 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|NEW |ASSIGNED Last reconfirmed|2010-07-17 13:37:31 |2010-07-18 17:50:44 date|| Summary|-fcompare-debug failure with|[4.6 Regression] -fcompare- |uninitialized read in |debug failure with |walk_gimple_stmt|uninitialized read in ||walk_gimple_stmt http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44971
[Bug tree-optimization/44972] [4.6 Regression] ICE: in load_assign_lhs_subreplacements, at tree-sra.c:2475
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-18 17:51 --- 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|NEW |ASSIGNED Last reconfirmed|2010-07-17 18:07:36 |2010-07-18 17:51:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
[Bug c/44977] [4.4/4.5/4.6 Regression] ice in propagate_rhs_into_lhs, at tree-ssa-dom.c:2728
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-18 18:01 --- It is caused by revision 139286: http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg00848.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44977
[Bug target/44862] bootstrap with --enable-build-with-cxx and --with-libiconv-prefix fails
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-07-18 18:05 --- Fixed at revision 162275. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44862
[Bug rtl-optimization/44979] New: [4.6 regression] Revision 162270 failed many x86-64 tests
On Linux/x86-64, revision 162270: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00624.html caused: FAIL: gcc.c-torture/execute/nest-stdar-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/nest-stdar-1.c execution, -O3 -g FAIL: gcc.c-torture/execute/pr44575.c execution, -O1 FAIL: gcc.c-torture/execute/pr44575.c execution, -O2 FAIL: gcc.c-torture/execute/pr44575.c execution, -O2 -flto FAIL: gcc.c-torture/execute/pr44575.c execution, -O2 -fwhopr FAIL: gcc.c-torture/execute/pr44575.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/pr44575.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/pr44575.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/pr44575.c execution, -O3 -g FAIL: gcc.c-torture/execute/pr44575.c execution, -Os FAIL: gcc.c-torture/execute/stdarg-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/stdarg-1.c execution, -O3 -g FAIL: gcc.c-torture/execute/stdarg-3.c execution, -O1 FAIL: gcc.c-torture/execute/stdarg-3.c execution, -O2 FAIL: gcc.c-torture/execute/stdarg-3.c execution, -O2 -flto FAIL: gcc.c-torture/execute/stdarg-3.c execution, -O2 -fwhopr FAIL: gcc.c-torture/execute/stdarg-3.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/stdarg-3.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/stdarg-3.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/stdarg-3.c execution, -O3 -g FAIL: gcc.c-torture/execute/stdarg-3.c execution, -Os FAIL: gcc.c-torture/execute/stdarg-4.c execution, -O1 FAIL: gcc.c-torture/execute/stdarg-4.c execution, -O2 FAIL: gcc.c-torture/execute/stdarg-4.c execution, -O2 -flto FAIL: gcc.c-torture/execute/stdarg-4.c execution, -O2 -fwhopr FAIL: gcc.c-torture/execute/stdarg-4.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/stdarg-4.c execution, -O3 -g FAIL: gcc.c-torture/execute/stdarg-4.c execution, -Os FAIL: gcc.c-torture/execute/va-arg-26.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/va-arg-26.c execution, -O3 -g FAIL: gcc.target/i386/amd64-abi-5.c execution test FAIL: gcc.target/i386/vararg-3.c execution test FAIL: gcc.target/i386/vararg-7.c execution test -- Summary: [4.6 regression] Revision 162270 failed many x86-64 tests Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization 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=44979
[Bug rtl-optimization/44979] [4.6 regression] Revision 162270 failed many x86-64 tests
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44979
[Bug rtl-optimization/44980] New: [4.6 regression] Revision 162270 failed 450.soplex in SPEC CPU 2006
On Linux/ia32, revision 162270: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00624.html caused: Running 450.soplex test base o3 default 450.soplex: copy 0 non-zero return code (exit code=0, signal=11) Invalid run; unable to continue. I used "-m32 -O3 -msse2 -mfpmath=sse -ffast-math -funroll-loops" to compile the benchmark. -- Summary: [4.6 regression] Revision 162270 failed 450.soplex in SPEC CPU 2006 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization 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=44980
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #19 from bernds at gcc dot gnu dot org 2010-07-18 18:38 --- Created an attachment (id=21242) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21242&action=view) Another patch I've managed to reproduce some differences with -g vs. no-debug builds. This patch fixes them for me. I still didn't see it during bootstrap - do I need to do anything unusual (other than configure/make?) There's one fix in there that may also help with miscompilations, although I still haven't managed to reproduce any of those either. The ia64 crash HJ reported also doesn't happen here with a cross compiler. -- bernds at gcc dot gnu dot org changed: What|Removed |Added Attachment #21239|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug middle-end/44974] [4.6 Regression] Function with attribute noreturn omits a call to another function with noreturn
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-18 18:39 --- Confirmed. We loose the call during expansion. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|target |middle-end Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-07-18 18:39:14 date|| Summary|Function with attribute |[4.6 Regression] Function |noreturn omits a call to|with attribute noreturn |another function with |omits a call to another |noreturn|function with noreturn Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44974
[Bug target/44981] New: cfstring_format_type supported needed darwin10
The testcase... Executing on host: /sw/src/fink.build/gcc45-4.5.1-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc45-4.5.1-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc45-4.5.1-1000/gcc-4.5.1/gcc/testsuite/gcc.dg/framework-1.c -F. -S -o framework-1.s(timeout = 300) In file included from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:43:0,^M from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:20,^M from /System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20,^M from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21,^M from /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20,^M from /sw/src/fink.build/gcc45-4.5.1-1000/gcc-4.5.1/gcc/testsuite/gcc.dg/framework-1.c:4:^M /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBundle.h:147:1: error: format string argument not a string type^M compiler exited with status 1 output is: In file included from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:43:0,^M from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:20,^M from /System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20,^M from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21,^M from /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20,^M from /sw/src/fink.build/gcc45-4.5.1-1000/gcc-4.5.1/gcc/testsuite/gcc.dg/framework-1.c:4:^M /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBundle.h:147:1: error: format string argument not a string type^M FAIL: gcc.dg/framework-1.c (test for excess errors) is due to the absence of support for the cfstring_format_type format_type in c-format.c. This should be implemented by porting over those changes from Apple's gcc-5646.1 source tree that are wrapped with "APPLE LOCAL radar 5096648" comments. -- Summary: cfstring_format_type supported needed darwin10 Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: *-apple-darwin10 GCC host triplet: *-apple-darwin10 GCC target triplet: *-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44981
[Bug tree-optimization/44977] [4.4/4.5/4.6 Regression] ice in propagate_rhs_into_lhs, at tree-ssa-dom.c:2728
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-18 18:42 --- 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|NEW |ASSIGNED Last reconfirmed|2010-07-18 14:42:54 |2010-07-18 18:42:24 date|| Target Milestone|--- |4.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44977
[Bug target/44981] cfstring_format_type support needed darwin10
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-07-18
18:48 ---
Note that this issue only occurs in darwin10 because of the introduction of ...
#if defined(__GNUC__) && (__GNUC__*10+__GNUC_MINOR__ >= 42) &&
!defined(__INTEL_COMPILER) && (TARGET_OS_MAC || TARGET_OS_EMBEDDED)
#define CF_FORMAT_FUNCTION(F,A) __attribute__((format(CFString, F, A)))
#define CF_FORMAT_ARGUMENT(A) __attribute__((format_arg(A)))
#else
#define CF_FORMAT_FUNCTION(F,A)
#define CF_FORMAT_ARGUMENT(A)
#endif
in /System/Library/Frameworks/CoreFoundation.framework/Headers/CFString.h which
makes the assumption that all gcc greater than gcc 4.2 supports the CFString
format. I had suggested in radar 6845745 that this be fixed in darwin10 with...
---
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFString.h.orig
2009-04-30 20:23:48.0 -0400
+++ /System/Library/Frameworks/CoreFoundation.framework/Headers/CFString.h
2009-04-30 22:41:41.0 -0400
@@ -153,7 +153,7 @@
#define CFSTR(cStr) __CFStringMakeConstantString("" cStr "")
#endif
-#if defined(__GNUC__) && (__GNUC__*10+__GNUC_MINOR__ >= 42) &&
!defined(__INTEL_COMPILER) && (TARGET_OS_MAC || TARGET_OS_EMBEDDED)
+#if defined(__GNUC__) && (__APPLE_CC__ > 5600) && (__GNUC__*10+__GNUC_MINOR__
>= 42) && !defined(__INTEL_COMPILER) && (TARGET_OS_MAC || TARGET_OS_EMBEDDED)
#define CF_FORMAT_FUNCTION(F,A) __attribute__((format(CFString, F, A)))
#define CF_FORMAT_ARGUMENT(A) __attribute__((format_arg(A)))
#else
but I don't think this will ever happen for darwin10. Mike has suggested that
better fix is to add port over the support for the CFString format.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44981
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #20 from hjl dot tools at gmail dot com 2010-07-18 18:52 --- (In reply to comment #19) > Created an attachment (id=21242) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21242&action=view) [edit] > Another patch I am testing it now. > I've managed to reproduce some differences with -g vs. no-debug builds. This > patch fixes them for me. I still didn't see it during bootstrap - do I need > to > do anything unusual (other than configure/make?) What is your glibc version? I can reproduce it with glibc 2.11 and 2.12. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #21 from hjl dot tools at gmail dot com 2010-07-18 19:03 --- (In reply to comment #19) > Created an attachment (id=21242) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21242&action=view) [edit] > Another patch > This patch passed the last failure. I will report any regressions in testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #22 from mikpe at it dot uu dot se 2010-07-18 19:53 --- And on armv5tel-linux-gnueabi with gcc-4.6 r162277: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/tree-ssa.o differs gcc/sel-sched-ir.o differs make[2]: *** [compare] Error 1 Configured just with --enable-languages=c --with-arch=armv5te --with-tune=xscale -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug middle-end/44974] [4.6 Regression] Function with attribute noreturn omits a call to another function with noreturn
--- Comment #4 from mikpe at it dot uu dot se 2010-07-18 19:59 --- It's caused by r160051: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg01110.html -- mikpe at it dot uu dot se changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44974
[Bug rtl-optimization/44980] [4.6 Regression] Revision 162270 failed 450.soplex in SPEC CPU 2006
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.6 regression] Revision |[4.6 Regression] Revision |162270 failed 450.soplex in |162270 failed 450.soplex in |SPEC CPU 2006 |SPEC CPU 2006 Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44980
[Bug tree-optimization/44897] -fwhopr + ipa-sra misoptimize sqlite
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-18 20:21 --- IPA-SRA => Martin -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-18 20:21:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44897
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #23 from hjl dot tools at gmail dot com 2010-07-18 20:34 --- (In reply to comment #19) > Created an attachment (id=21242) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21242&action=view) [edit] > Another patch > > I've managed to reproduce some differences with -g vs. no-debug builds. This > patch fixes them for me. I still didn't see it during bootstrap - do I need > to > do anything unusual (other than configure/make?) This fixed bootstrap on Linux/ia32. There are no regressions in gcc testsuite. > > There's one fix in there that may also help with miscompilations, although I > still haven't managed to reproduce any of those either. The ia64 crash HJ > reported also doesn't happen here with a cross compiler. This still miscompiles 450.soplex. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #24 from bernds at gcc dot gnu dot org 2010-07-18 20:39 --- Created an attachment (id=21243) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21243&action=view) Patch v4 I found another potential bug in the interaction between the existing code and the new one. Fixing this doesn't seem to cause any code generation differences in any of the testcases I looked at, but maybe it could help with some of the bootstrap failures on other targets or with Spec2k6? -- bernds at gcc dot gnu dot org changed: What|Removed |Added Attachment #21242|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #25 from bernds at gcc dot gnu dot org 2010-07-18 20:40 --- (In reply to comment #17) > And on hppa64-hp-hpux11.11 gcc-4.6 162277 in stage2: > ../../../gcc/libgcc/../gcc/libgcc2.c:791:1: internal compiler error: > Segmentatio > n fault If the latest patch does not fix this, could you run the testsuite on the stage1 compiler (i.e. make check in stage1-gcc or prev-gcc if the former doesn't exist)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #26 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-18 20:43 --- Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap Doing a non bootstrap build, I see the following new fail: FAIL: gcc.c-torture/execute/950605-1.c execution, -O1 f: .PROC .CALLINFO FRAME=128,CALLS,SAVE_RP,ENTRY_GR=3 .ENTRY std %r2,-16(%r30) ldi 255,%r28 cmpb,= %r28,%r26,L$0003 The least significant byte of the argument passed in register %r26 is no longer extracted, causing compare to fail. The is what I see with gcc-4.4: f: .PROC .CALLINFO FRAME=128,CALLS,SAVE_RP,ENTRY_GR=3 .ENTRY std %r2,-16(%r30) extrd,u %r26,63,8,%r26 ldi 255,%r28 cmpb,= %r28,%r26,L$0004 Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug debug/44971] [4.6 Regression] -fcompare-debug failure with uninitialized read in walk_gimple_stmt
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-18 20:46 ---
@@ -29,7 +29,7 @@
(note# 0 0 NOTE_INSN_DELETED)
(note# 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note# 0 0 NOTE_INSN_FUNCTION_BEG)
-(insn:TI# 0 0 pr44971.c:22 (set (reg/f:SI 0 ax [orig:58 D. ] [58])
+(insn:TI# 0 0 pr44971.c:22 (set (reg/v/f:SI 0 ax [orig:58 info ] [58])
(mem/f/c:SI (symbol_ref:SI ("_XftintInfo") )
[ MEM[(struct XftintInfo * *)&_XftintInfo]+0 S4 A32]))# {*movsi_internal}
(nil))
(insn/f:TI# 0 0 pr44971.c:20 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [ S4
A8])
(reg/f:SI 6 bp))# {*pushsi2} (nil))
@@ -37,7 +37,7 @@
(reg/f:SI 7 sp))# {*movsi_internal} (nil))
(note# 0 0 NOTE_INSN_PROLOGUE_END)
(insn:TI# 0 0 pr44971.c:22 (set (reg:CCZ 17 flags)
-(compare:CCZ (reg/f:SI 0 ax [orig:58 D. ] [58])
+(compare:CCZ (reg/v/f:SI 0 ax [orig:58 info ] [58])
(const_int 0 [0])))# {*cmpsi_ccno_1} (nil))
(jump_insn:TI# 0 0 pr44971.c:22 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
...
caused by phiprop. It chooses one dereference result to choose the
result. But debug stmts change order of immediate uses.
With debug stmts (uses of prev_1):
# VUSE <.MEM_8(D)>
info_5 = *prev_1;
# DEBUG prev => prev_1
# VUSE <.MEM_8(D)>
D.1973_6 = *prev_1;
without:
# VUSE <.MEM_8(D)>
D.1973_6 = *prev_1;
# VUSE <.MEM_8(D)>
info_5 = *prev_1;
so relying on stable order of immediate uses is now wrong? The compare-debug
failure is spurious, there is no difference in the assembly output.
I can fix it by always degrading debug info and creating a new variable.
Alex, why should the immediate use lists show this behavior?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||aoliva at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44971
[Bug fortran/34260] Give warning if procedure with implicit interface is called with different arguments
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-07-18 20:49 --- Subject: Bug 34260 Author: dfranke Date: Sun Jul 18 20:49:30 2010 New Revision: 162287 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162287 Log: gcc/fortran/: 2010-07-18 Daniel Franke Paul Thomas PR fortran/30668 PR fortran/31346 PR fortran/34260 * resolve.c (resolve_global_procedure): Improved checking if an explicit interface is required. PR fortran/40011 * resolve.c (resolve_global_procedure): Resolve the gsymbol's namespace before trying to reorder the gsymbols. gcc/testsuite/: 2010-07-18 Daniel Franke Paul Thomas PR fortran/30668 PR fortran/31346 PR fortran/34260 PR fortran/40011 * gfortran.dg/pr40999.f: Fix function type. * gfortran.dg/whole_file_5.f90: Likewise. * gfortran.dg/whole_file_6.f90: Likewise. * gfortran.dg/whole_file_16.f90: New. * gfortran.dg/whole_file_17.f90: New. * gfortran.dg/whole_file_18.f90: New. * gfortran.dg/whole_file_19.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_16.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_17.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_18.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_19.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr40999.f branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_5.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34260
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays without explicit interface
--- Comment #12 from dfranke at gcc dot gnu dot org 2010-07-18 20:49 --- Subject: Bug 31346 Author: dfranke Date: Sun Jul 18 20:49:30 2010 New Revision: 162287 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162287 Log: gcc/fortran/: 2010-07-18 Daniel Franke Paul Thomas PR fortran/30668 PR fortran/31346 PR fortran/34260 * resolve.c (resolve_global_procedure): Improved checking if an explicit interface is required. PR fortran/40011 * resolve.c (resolve_global_procedure): Resolve the gsymbol's namespace before trying to reorder the gsymbols. gcc/testsuite/: 2010-07-18 Daniel Franke Paul Thomas PR fortran/30668 PR fortran/31346 PR fortran/34260 PR fortran/40011 * gfortran.dg/pr40999.f: Fix function type. * gfortran.dg/whole_file_5.f90: Likewise. * gfortran.dg/whole_file_6.f90: Likewise. * gfortran.dg/whole_file_16.f90: New. * gfortran.dg/whole_file_17.f90: New. * gfortran.dg/whole_file_18.f90: New. * gfortran.dg/whole_file_19.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_16.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_17.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_18.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_19.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr40999.f branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_5.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug fortran/30668] -fwhole-file should catch function of wrong type
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-07-18 20:49 --- Subject: Bug 30668 Author: dfranke Date: Sun Jul 18 20:49:30 2010 New Revision: 162287 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162287 Log: gcc/fortran/: 2010-07-18 Daniel Franke Paul Thomas PR fortran/30668 PR fortran/31346 PR fortran/34260 * resolve.c (resolve_global_procedure): Improved checking if an explicit interface is required. PR fortran/40011 * resolve.c (resolve_global_procedure): Resolve the gsymbol's namespace before trying to reorder the gsymbols. gcc/testsuite/: 2010-07-18 Daniel Franke Paul Thomas PR fortran/30668 PR fortran/31346 PR fortran/34260 PR fortran/40011 * gfortran.dg/pr40999.f: Fix function type. * gfortran.dg/whole_file_5.f90: Likewise. * gfortran.dg/whole_file_6.f90: Likewise. * gfortran.dg/whole_file_16.f90: New. * gfortran.dg/whole_file_17.f90: New. * gfortran.dg/whole_file_18.f90: New. * gfortran.dg/whole_file_19.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_16.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_17.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_18.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_19.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr40999.f branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_5.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30668
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #58 from dfranke at gcc dot gnu dot org 2010-07-18 20:49 --- Subject: Bug 40011 Author: dfranke Date: Sun Jul 18 20:49:30 2010 New Revision: 162287 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162287 Log: gcc/fortran/: 2010-07-18 Daniel Franke Paul Thomas PR fortran/30668 PR fortran/31346 PR fortran/34260 * resolve.c (resolve_global_procedure): Improved checking if an explicit interface is required. PR fortran/40011 * resolve.c (resolve_global_procedure): Resolve the gsymbol's namespace before trying to reorder the gsymbols. gcc/testsuite/: 2010-07-18 Daniel Franke Paul Thomas PR fortran/30668 PR fortran/31346 PR fortran/34260 PR fortran/40011 * gfortran.dg/pr40999.f: Fix function type. * gfortran.dg/whole_file_5.f90: Likewise. * gfortran.dg/whole_file_6.f90: Likewise. * gfortran.dg/whole_file_16.f90: New. * gfortran.dg/whole_file_17.f90: New. * gfortran.dg/whole_file_18.f90: New. * gfortran.dg/whole_file_19.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_16.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_17.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_18.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_19.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr40999.f branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_5.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug tree-optimization/44972] [4.6 Regression] ICE: in load_assign_lhs_subreplacements, at tree-sra.c:2475
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-18 20:57 --- Martin, can you have a look here? All this build_ref_for_offset should now be very easy. But we need to have the original access tree that we replace as well. The built access should simply be fold_build2 (MEM_REF, type-of-the-access, address-of-the-base, build_int_cst (reference_alias_ptr_type (reference-to-replace), constant-offset)); which is valid in all cases (doesn't need VIEW_CONVERT_EXPRs or anything like that). I think I tried to do that on the mem-ref branch but failed as build_ref_for_offset is convoluted and the allow_ptr flag confuses me (I think the IPA uses should be separated from the SRA ones). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org AssignedTo|rguenth at gcc dot gnu dot |jamborm at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
[Bug target/44631] [sparc] long long to double conversion error
--- Comment #6 from mikpe at it dot uu dot se 2010-07-18 20:58 --- Created an attachment (id=21244) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21244&action=view) fix Linux kernel math emulation FP_FROM_INT macro The bug is in the Linux kernel math-emu code. The _FP_FROM_INT macro which converts integers to raw floats is supposed to produce normalized floats, but due to an error in a boundary condition, it fails to do so for a range of numbers, resulting in very incorrect floats for those numbers. The fix is syntactically trivial (s/http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44631
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #27 from bernds at gcc dot gnu dot org 2010-07-18 21:00 ---
(In reply to comment #26)
> Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap
>
> Doing a non bootstrap build, I see the following new fail:
> FAIL: gcc.c-torture/execute/950605-1.c execution, -O1
David, this seems to be caused by a different revision. The postreload pass
we're discussing here makes no changes to RTL on that testcase. Please ensure
you find the right revision that introduces a problem.
In this case, it probably was another of my changes that caused this failure,
although I can't tell what's wrong. The extend insn disappears during fwprop1:
-(insn 3 5 4 2 950605-1.c:3 (set (reg/v:DI 68 [ c+-7 ])
-(zero_extend:DI (reg:SI 26 %r26 [ c+-3 ]))) 133 {*pa.md:4633} (nil))
+(note 5 0 4 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
-(note 4 3 7 2 NOTE_INSN_FUNCTION_BEG)
+(note 4 5 7 2 NOTE_INSN_FUNCTION_BEG)
(insn 7 4 8 2 950605-1.c:4 (set (reg:SI 69)
(const_int 255 [0xff])) 71 {*pa.md:2130} (nil))
(jump_insn 8 7 9 2 950605-1.c:4 (set (pc)
-(if_then_else (eq (subreg/s/u:SI (reg/v:DI 68 [ c+-7 ]) 4)
+(if_then_else (eq (reg:SI 26 %r26 [ c+-3 ])
(reg:SI 69))
(label_ref:DI 23)
-(pc))) 46 {*pa.md:1330} (expr_list:REG_BR_PROB (const_int 9996
[0x270c])
-(nil))
+(pc))) 46 {*pa.md:1330} (expr_list:REG_DEAD (reg:SI 69)
+(expr_list:REG_DEAD (reg/v:DI 68 [ c+-7 ])
+(expr_list:REG_BR_PROB (const_int 9996 [0x270c])
+(nil
I can't find anything wrong with this, as it's a SImode comparison. Is the
backend emitting the correct compare instruction?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug fortran/44953] FAIL: gfortran.dg/char4_iunit_1.f03 * execution test
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-07-18 21:07 --- Created an attachment (id=21245) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21245&action=view) Proposed Patch Please test the attached patch. This patch cleans up pointer use and adds a few snippets I missed in the first implementations, namely in write_char and write_separator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44953
[Bug tree-optimization/44972] [4.6 Regression] ICE: in load_assign_lhs_subreplacements, at tree-sra.c:2475
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-18 21:10 --- Created an attachment (id=21246) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21246&action=view) prototype sth like this, with the FIXME resolved (it's not clear which is the reference we are replacing at each site). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
[Bug fortran/30668] -fwhole-file should catch function of wrong type
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-07-18 21:12 --- Fixed in trunk and 4.5. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30668
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays without explicit interface
--- Comment #13 from dfranke at gcc dot gnu dot org 2010-07-18 21:13 --- Fixed in trunk and 4.5. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug fortran/34260] Give warning if procedure with implicit interface is called with different arguments
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-07-18 21:15 --- Fixed in trunk and 4.5. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34260
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #28 from bernds at gcc dot gnu dot org 2010-07-18 21:15 --- Created an attachment (id=21247) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21247&action=view) Minimally tested patch for the hppa problem Seems like we're extending from the wrong mode. Does this fix it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-18
21:15 ---
Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap
> David, this seems to be caused by a different revision. The postreload pass
> we're discussing here makes no changes to RTL on that testcase. Please ensure
> you find the right revision that introduces a problem.
Possibly, that is true. The title of this PR was quite general. Anyway,
I will start a new PR if there are multiple unrelated issues. I will
determine the exact revision. Last successful bootstrap on this target
was 162195.
> -(insn 3 5 4 2 950605-1.c:3 (set (reg/v:DI 68 [ c+-7 ])
> -(zero_extend:DI (reg:SI 26 %r26 [ c+-3 ]))) 133 {*pa.md:4633} (nil))
> +(note 5 0 4 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
It looks to me like the extend insn is wrong. With 4.4, we had
(insn 4 3 5 2
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/950605-1.c:3
(set (reg/v:DI 68 [ c+-7 ])
(zero_extend:DI (subreg:QI (reg:SI 69) 3))) -1 (nil))
> I can't find anything wrong with this, as it's a SImode comparison. Is the
> backend emitting the correct compare instruction?
The backend has only SImode and DImode comparisons.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug tree-optimization/44972] [4.6 Regression] ICE: in load_assign_lhs_subreplacements, at tree-sra.c:2475
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-18 21:22 --- More like if (TREE_CODE (*expr) == MEM_REF && TREE_OPERAND (*expr, 0) != ADDR_EXPR) *expr = fold_build2 (MEM_REF, exp_type, TREE_OPERAND (*expr, 0), int_const_binop (PLUS_EXPR, build_int_cst (/* FIMXE */build_pointer_type (exp_type), offset), TREE_OPERAND (*expr, 1), 0)); else *expr = fold_build2 (MEM_REF, exp_type, build_fold_addr_expr (*expr), build_int_cst (/* FIMXE */build_pointer_type (exp_type), offset)); with some cleanup, of course. I'll take another look tomorrow. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jamborm at gcc dot gnu dot |rguenth at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
[Bug c++/44916] Incorrect function overloading with static_cast
--- Comment #1 from james dot dennett at gmail dot com 2010-07-18 21:37 --- Thanks to Ian for reporting this for me (my buganizer account wasn't well at the time). This appears to duplicate bug 39415. I have a hacky fix for this, adding a conversion to the correct target type after the conversion used by the current code, included here for reference: $ svn diff gcc/cp/typeck.c Index: gcc/cp/typeck.c === --- gcc/cp/typeck.c (revision 157950) +++ gcc/cp/typeck.c (working copy) @@ -5743,7 +5743,14 @@ base = lookup_base (TREE_TYPE (type), TREE_TYPE (intype), c_cast_p ? ba_unique : ba_check, NULL); - return build_base_path (MINUS_EXPR, expr, base, /*nonnull=*/false); + return build_static_cast_1 (type, + build_base_path (MINUS_EXPR, + expr, + base, + /*nonnull=*/false), + c_cast_p, + valid_p, + complain); } if ((TYPE_PTRMEM_P (type) && TYPE_PTRMEM_P (intype)) -- james dot dennett at gmail dot com changed: What|Removed |Added CC||james dot dennett at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44916
[Bug c++/39415] static_cast used as downcast can silently lose const
--- Comment #2 from james dot dennett at gmail dot com 2010-07-18 21:39 --- 44916 is a duplicate of this bug (and includes a hacky fix, but no automated regression test). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39415
[Bug fortran/44953] FAIL: gfortran.dg/char4_iunit_1.f03 * execution test
--- Comment #9 from dominiq at lps dot ens dot fr 2010-07-18 21:59 ---
> Created an attachment (id=21245)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21245&action=view) [edit]
> Proposed Patch
>
> Please test the attached patch.
make -k check-gfortran RUNTESTFLAGS="dg.exp=char4_iunit_*.f03
--target_board=unix'{-m32,-m64}'"
...
=== gfortran Summary ===
# of expected passes64
So the patch fixes this PR. I have launched a full gfortran regtest to be sure,
but do not expect any surprise. Thanks for the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44953
[Bug c/44975] Stack trashed by call inside inline asm
--- Comment #4 from ramiro dot polla at gmail dot com 2010-07-18 22:08 --- That won't work in this case. If I subtract anything from rsp inside the inline asm, the local variable relative to f will no longer be valid. Notice where gcc put it: 21: ff 54 24 f8 callq *-0x8(%rsp) Is there no way to tell gcc that either a call is being made inside the inline asm or that this function should not be considered a leaf function? If there isn't one yet, could such a feature request be acceptable? (like __attribute__((no_leaf_function)) or something) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44975
[Bug c++/39415] static_cast used as downcast can silently lose const
--- Comment #3 from redi at gcc dot gnu dot org 2010-07-18 22:11 --- *** Bug 44916 has been marked as a duplicate of this bug. *** -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39415
[Bug c++/44916] Incorrect function overloading with static_cast
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-18 22:11 --- Thanks, James, confirming as a dup *** This bug has been marked as a duplicate of 39415 *** -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44916
[Bug c++/39415] static_cast used as downcast can silently lose const
--- Comment #4 from redi at gcc dot gnu dot org 2010-07-18 22:13 --- Adding wrong-code keyword, as shown by the testcase in PR 44916 -- redi at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Known to fail||4.4.4 4.5.1 4.6.0 Last reconfirmed|2009-03-10 11:04:47 |2010-07-18 22:13:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39415
[Bug fortran/44953] FAIL: gfortran.dg/char4_iunit_1.f03 * execution test
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-07-18 22:19 --- Full regression test passed on IBM Power 5. I will submit patch for approval this evening. Thanks for bug report and testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44953
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #30 from hjl dot tools at gmail dot com 2010-07-18 22:22 --- (In reply to comment #24) > Created an attachment (id=21243) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21243&action=view) [edit] > Patch v4 > > I found another potential bug in the interaction between the existing code and > the new one. Fixing this doesn't seem to cause any code generation > differences > in any of the testcases I looked at, but maybe it could help with some of the > bootstrap failures on other targets or with Spec2k6? > This doesn't fix SPEC CPU 2006. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug c++/44969] [C++0x] std::is_constructible broken for fundamental types.
--- Comment #7 from jason at redhat dot com 2010-07-18 22:33 --- Subject: Re: [C++0x] std::is_constructible broken for fundamental types. On 07/17/2010 03:14 PM, paolo dot carlini at oracle dot com wrote: > I attached a draft which fixes the original testcase as a SFINAE issue. Seems > to me rather straightforward and consistent with existing practice in > typeck.c, > just passes down complain to build_x_compound_expr_from_list. Regtests fine. Looks good. I haven't tracked down the other issue yet. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44969
[Bug tree-optimization/44897] -fwhopr + ipa-sra misoptimize sqlite
--- Comment #5 from hubicka at ucw dot cz 2010-07-18 22:35 --- Subject: Re: -fwhopr + ipa-sra misoptimize sqlite > IPA-SRA => Martin Well, the trick is that IPA-SRA is run before LTO streaming, so it means that it should not be affected by -fwhopr at all (and linking resulting .o file w/o LTO seems to work). So it is really combination of those. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44897
[Bug target/29258] internal compiler error: Segmentation fault
--- Comment #7 from dschlic1 at gmail dot com 2010-07-18 23:51 --- Created an attachment (id=21248) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21248&action=view) Script file to build arm cross compiler causes segmentation fault The attached script file causes the compiler to have a segmentation fault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29258
[Bug c/44982] New: crash on invalid code if((a==1) ? (void) (0) : 1)
o...@lonkero:~/code$ gcc bug.c -Wall
bug.c: In function main:
bug.c:5: error: void value not ignored as it ought to be
bug.c:5: error: void value not ignored as it ought to be
bug.c:5: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccoFNCjw.out file, please attach this to
your bugreport.
o...@lonkero:~/code$ cat /tmp/ccoFNCjw.out
// /usr/lib/gcc/i486-linux-gnu/4.4.1/cc1 -quiet bug.c -D_FORTIFY_SOURCE=2
-quiet -dumpbase bug.c -mtune=generic -march=i486 -auxbase bug -Wall
-fstack-protector -o - -frandom-seed=0
# 1 "bug.c"
# 1 ""
# 1 ""
# 1 "bug.c"
int main(void)
{
int a=1;
if((a==1) ? (void) (0) : 1);
return 0;
}
--
Summary: crash on invalid code if((a==1) ? (void) (0) : 1)
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: soundis at infa dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44982
[Bug fortran/44353] rejects legal fortran
--- Comment #4 from pault at gcc dot gnu dot org 2010-07-19 05:05 --- Subject: Bug 44353 Author: pault Date: Mon Jul 19 05:05:23 2010 New Revision: 162294 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162294 Log: 2010-07-19 Paul Thomas PR fortran/44353 * match.c (gfc_match_iterator): Revert. 2010-07-19 Paul Thomas PR fortran/44353 * gfortran.dg/data_implied_do_2.f03 : Remove. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44353
