[Bug target/12027] [3.3/3.4/4.0 Regression] sparclite-coff build fails with INIT_SECTION_ASM_OP' undeclared
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20 10:24 --- Mine. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12027
[Bug fortran/18565] gfortran: CONJG: false error message about standard violation
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2004-11-20 12:03 --- (In reply to comment #0) z2 = conjg (z1) 1 Error: Type of argument 'z' in call to 'conjg' at (1) should be COMPLEX(4), not COMPLEX(8) Yep, I think this in intrinsic.c: add_sym_1 (dconjg, 1, 1, BT_COMPLEX, dd, GFC_STD_GNU, NULL, gfc_simplify_conjg, gfc_resolve_conjg, z, BT_COMPLEX, dd, 0); should be: add_sym_1 (dconjg, 1, 1, BT_COMPLEX, dd, GFC_STD_F95, NULL, gfc_simplify_conjg, gfc_resolve_conjg, z, BT_COMPLEX, dd, 0); Toon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18565
[Bug fortran/18518] equivalenced variables are not saved
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2004-11-20 12:10 --- Hmmm, I do not get this on my powerpc-unknown-linux-gnu: [EMAIL PROTECTED]:~/g95-bugs$ /usr/snp/bin/gfortran -O2 18518.f90 [EMAIL PROTECTED]:~/g95-bugs$ (LD_LIBRARY_PATH=/usr/snp/lib export LD_LIBRARY_PATH; ./a.out) 12345 12345 [EMAIL PROTECTED]:~/g95-bugs$ /usr/snp/bin/gfortran -v Reading specs from /usr/snp/lib/gcc/powerpc-unknown-linux-gnu/4.0.0/specs Configured with: ../gcc/configure --prefix=/usr/snp --disable-nls --disable-multilib Thread model: posix gcc version 4.0.0 20041119 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18518
[Bug fortran/17815] Language name for --enable-languages should be fortran instead of f95
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2004-11-20 12:16 --- I agree too, that's why I changed the status of this bug report to NEW, i.e., confirmed :-) Toon. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-20 12:16:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17815
[Bug bootstrap/18574] bootstrap comprison failed
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20 12:59 --- I can't reproduce with: cat LAST_UPDATED Sat Nov 20 11:33:24 CET 2004 Sat Nov 20 10:33:24 UTC 2004 Configured with: /home/eric/cvs/gcc/configure amd64-mandrake-linux-gnu --prefix=/home/eric/install/gcc/native --enable-__cxa_atexit --enable-languages=c,c++,objc,f95,java --enable-checking=assert,misc,tree,rtl,rtlflag --disable-libmudflap Thread model: posix gcc version 4.0.0 20041120 (experimental) However, I'm seeing a bootstrap comparison failure on sparc-sun-solaris2.5.1: Bootstrap comparison failure! ./fold-const.o differs cp/typeck.o differs and sparc-sun-solaris2.6: Bootstrap comparison failure! ./fold-const.o differs but not on sparc*-sun-solaris2.x (x =7). -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[Bug libfortran/16135] [4.0 Regression] libfortran doesn't build, use of C99 types
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-20 13:15 --- Subject: Bug 16135 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-20 13:15:17 Modified files: libgfortran: ChangeLog acinclude.m4 config.h.in configure configure.ac libgfortran.h libgfortran/intrinsics: date_and_time.c libgfortran/io : write.c Log message: PR target/16135 * acinclude.m4 (LIBGFOR_TARGET_ILP32): New check. * configure.ac: Include LIBGFOR_TARGET_ILP32. * configure: Regenerate. * config.h.in: Likewise. * libgfortran.h: Provide default definitions for C99 types on ILP32 targets that don't have them. PR target/17999 * configure.ac: Check for snprintf. * configure: Regenerate. * config.h.in: Likewise. * intrinsics/date_and_time.c (date_and_time): Do not use snprinf if it is not available. * io/write.c (output_float): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.111r2=1.112 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/acinclude.m4.diff?cvsroot=gccr1=1.3r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/config.h.in.diff?cvsroot=gccr1=1.11r2=1.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/configure.diff?cvsroot=gccr1=1.19r2=1.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/configure.ac.diff?cvsroot=gccr1=1.14r2=1.15 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/libgfortran.h.diff?cvsroot=gccr1=1.13r2=1.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/date_and_time.c.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/write.c.diff?cvsroot=gccr1=1.16r2=1.17 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16135
[Bug fortran/18518] equivalenced variables are not saved
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-20 13:19 --- Hmmm, I do not get this on my powerpc-unknown-linux-gnu: Here's a reduced assembly output: $ gfortran -v Reading specs from /home/ig25/lib/gcc/i686-pc-linux-gnu/4.0.0/specs Configured with: ../gcc/configure --prefix=/home/ig25 --enable-languages=c,c++,f95 Thread model: posix gcc version 4.0.0 20041120 (experimental) $ cat pr18518-test2.f90 subroutine foo integer i,g,h data i/0/ equivalence (g,h) save g if (i == 0) then i = 1 h = 12345 end if print *,h end subroutine foo $ gfortran -S pr18518-test2.f90 $ cat pr18518-test2.s .file pr18518-test2.f90 .local i.456 .comm i.456,4,4 .section.rodata .LC0: .string pr18518-test2.f90 .text .globl foo_ .type foo_, @function foo_: pushl %ebp movl%esp, %ebp subl$24, %esp movli.456, %eax testl %eax, %eax jne .L2 movl$1, i.456 movl$12345, -4(%ebp) .L2: movl$.LC0, _gfortran_filename movl$10, _gfortran_line movl$6, _gfortran_ioparm movl$1, _gfortran_ioparm+16 call_gfortran_st_write movl$4, 4(%esp) leal-4(%ebp), %eax movl%eax, (%esp) call_gfortran_transfer_integer call_gfortran_st_write_done leave ret .size foo_, .-foo_ .ident GCC: (GNU) 4.0.0 20041120 (experimental) .section.note.GNU-stack,,@progbits $ The movl $12345, -4(%ebp) above is clearly wrong - it loads the value of 12345 into a stack location, not a saved location. It would be good to check assembly output on your machine to see wether the same problem occurs (even if the test example doesn't show it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18518
[Bug libfortran/16135] [4.0 Regression] libfortran doesn't build, use of C99 types
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20 13:21 --- See http://gcc.gnu.org/ml/fortran/2004-11/msg00127.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16135
[Bug libfortran/16991] [meta-bug] libgfortran does not build every where
-- Bug 16991 depends on bug 16135, which changed state. Bug 16135 Summary: [4.0 Regression] libfortran doesn't build, use of C99 types http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16135 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16991
[Bug libfortran/17999] [4.0 Regression] libfortran: uses some C99 functions (snprintf)
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20 13:21 --- See http://gcc.gnu.org/ml/fortran/2004-11/msg00127.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17999
[Bug libfortran/16135] [4.0 Regression] libfortran doesn't build, use of C99 types
-- Bug 16135 depends on bug 17999, which changed state. Bug 17999 Summary: [4.0 Regression] libfortran: uses some C99 functions (snprintf) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17999 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16135
[Bug bootstrap/18574] bootstrap comprison failed
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20 13:40 --- However, I'm seeing a bootstrap comparison failure on sparc-sun-solaris2.5.1: Bootstrap comparison failure! ./fold-const.o differs cp/typeck.o differs and sparc-sun-solaris2.6: Bootstrap comparison failure! ./fold-const.o differs The differences are only in debug sections too. And both targets use STABS, unlike sparc*-sun-solaris2.x (x=7) that have switched to DWARF-2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[Bug bootstrap/18574] bootstrap comprison failed
--- Additional Comments From belyshev at lubercy dot com 2004-11-20 14:01 --- I can confirm this on i686-pc-linux-gnu: Bootstrap comparison failure! ./fold-const.o differs ./loop.o differs -- What|Removed |Added Severity|normal |critical GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[Bug bootstrap/18574] bootstrap comprison failed
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20 14:12 --- At this point we can say that there is a problem somewhere. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-20 14:12:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[Bug libfortran/15234] libgfortran doesn't compile on Tru64 UNIX V4.0F
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 15:45 --- This is __NOT__ fixed by (because alpha is a LP64 target) but it makes it easier to fix: * acinclude.m4 (LIBGFOR_TARGET_ILP32): New check. * configure.ac: Include LIBGFOR_TARGET_ILP32. * configure: Regenerate. * config.h.in: Likewise. * libgfortran.h: Provide default definitions for C99 types on ILP32 targets that don't have them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15234
[Bug libfortran/14325] [libgfortran] libgfortran does not build with newlib on arm-elf (stdint.h does not define the right types)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 15:46 --- Arm is fixed but not all targets which use newlib by (because some targets are LP64 aka MMIX): * acinclude.m4 (LIBGFOR_TARGET_ILP32): New check. * configure.ac: Include LIBGFOR_TARGET_ILP32. * configure: Regenerate. * config.h.in: Likewise. * libgfortran.h: Provide default definitions for C99 types on ILP32 targets that don't have them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14325
[Bug middle-end/18574] [4.0 Regression] bootstrap comprison failed
--- Additional Comments From andreast at gcc dot gnu dot org 2004-11-20 15:47 --- I get differs too on powerpc-apple-darwin7.6.0 with --enable-checking (and without): Bootstrap comparison failure! ./combine.o differs ./convert.o differs ./fold-const.o differs cp/parser.o differs cp/typeck.o differs java/parse.o differs These failure starts just after my patch to tree-vectorizer.c (My patch bootstraps successful) Either this: http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg00935.html Or this patch seem responsible: http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg00936.html I could reproduce it. with cvs update -D before these patches - ok. cvs update -D after these patches, nok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[Bug rtl-optimization/18577] New: [3.3 regression] variable use moved before initialization
Test case:
static float tfcos12[3];
__attribute__((noinline)) double f(double x) { return x; }
int g;
int main(void) {
int i, j;
for (i = 0; i 1; i++)
tfcos12[i] = 0.5;
for (i = 0; i 1; i++) {
tfcos12[i] = 0.5 * f(i);
for (j = 0; j 12; j++)
g++;
}
return 0;
}
% gcc -funroll-all-loops -O2 test.c ./a.out
zsh: floating point exception (core dumped) ./a.out
The reason is that the constant 0.5 is first used and then loaded:
[...]
cpys $f10,$f10,$f2 # use $f10
lds $f10,$LC0($1) !gprellow # before loading it
[...]
mult $f2,$f0,$f0# and this FPEs
This does not happen without -funroll-all-loops. Also not at -O, or with
3.4.
--
Summary: [3.3 regression] variable use moved before
initialization
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Keywords: wrong-code
Severity: critical
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: alphaev68-unknown-linux-gnu
GCC host triplet: alphaev68-unknown-linux-gnu
GCC target triplet: alphaev68-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18577
[Bug rtl-optimization/18577] [3.3 regression] variable use moved before initialization
-- What|Removed |Added Target Milestone|--- |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18577
[Bug tree-optimization/18576] missing jump threading because of type changes
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-20 16:44 --- Confirmed, I see similar code on x86: .L4: xorl%ebx, %ebx .L7: xorl%edx, %edx testb %bl, %bl jne .L2 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-20 16:44:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18576
[Bug preprocessor/18102] darwin framework header search depends on order of options
--- Additional Comments From mrs at apple dot com 2004-11-20 16:46 --- This patch is ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18102
[Bug target/11292] [new-ra] causes sibcalling to go wrong.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 16:49 --- And now this is fixed on the mainline. -- What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11292
[Bug rtl-optimization/13246] [meta-bug] new-ra related problems
-- Bug 13246 depends on bug 11292, which changed state. Bug 11292 Summary: [new-ra] causes sibcalling to go wrong. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11292 What|Old Value |New Value Status|SUSPENDED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13246
[Bug tree-optimization/18576] missing jump threading because of type changes
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-20
17:01 ---
I have the following in the .optimized dump:
flow_bb_inside_loop_p (loop, source_loop)
{
unsigned char D.1171;
struct loop * D.1170;
struct loop * * D.1169;
struct loop * * D.1168;
unsigned int D.1167;
unsigned int D.1166;
struct loop * * D.1165;
int D.1164;
int D.1163;
int iftmp.0;
int D.1161;
struct loop * outer;
struct loop * loop;
unsigned char D.1146;
unsigned char D.1145;
int iftmp.1;
int D.1140;
int D.1160;
# BLOCK 0
# PRED: ENTRY [100.0%] (fallthru,exec)
if (loop == source_loop) goto L8; else goto L0;
# SUCC: 6 [10.4%] (true,exec) 1 [89.6%] (false,exec)
# BLOCK 1
# PRED: 0 [89.6%] (false,exec)
L0:;
D.1164 = loop-depth;
if (source_loop-depth = D.1164) goto L4; else goto L1;
# SUCC: 4 [50.0%] (true,exec) 2 [50.0%] (false,exec)
# BLOCK 2
# PRED: 1 [50.0%] (false,exec)
L1:;
if (loop != *(source_loop-pred + (struct loop * *) ((unsigned int) D.1164 *
4))) goto L4; else goto L2;
# SUCC: 4 [81.0%] (true,exec) 3 [19.0%] (false,exec)
# BLOCK 3
# PRED: 2 [19.0%] (false,exec)
L2:;
iftmp.0 = 1;
goto bb 7 (L14);
# SUCC: 7 [100.0%] (fallthru,exec)
# BLOCK 4
# PRED: 1 [50.0%] (true,exec) 2 [81.0%] (true,exec)
L4:;
iftmp.0 = 0;
# SUCC: 7 [100.0%] (fallthru)
# BLOCK 7
# PRED: 4 [100.0%] (fallthru) 3 [100.0%] (fallthru,exec)
L14:;
if ((unsigned char) (int) (unsigned char) iftmp.0 != 0) goto L8; else goto
L7;
# SUCC: 6 [33.0%] (true,exec) 5 [67.0%] (false,exec)
# BLOCK 5
# PRED: 7 [67.0%] (false,exec)
L7:;
iftmp.1 = 0;
goto bb 8 (L15);
# SUCC: 8 [100.0%] (fallthru,exec)
# BLOCK 6
# PRED: 0 [10.4%] (true,exec) 7 [33.0%] (true,exec)
L8:;
iftmp.1 = 1;
# SUCC: 8 [100.0%] (fallthru)
# BLOCK 8
# PRED: 6 [100.0%] (fallthru) 5 [100.0%] (fallthru,exec)
L15:;
return (int) (unsigned char) iftmp.1;
# SUCC: EXIT [100.0%]
}
Control flow graph:
ENTRY
|
0
|\
| \
1 \
|\ \
| \ \
2 \ \
|\ | |
| \| |
3 4 |
| / |
|/|
7 /
|\ /
| \ /
5 6
| /
|/
8
|
EXIT
Dominator tree:
0
/|\
6 8 1
/|\
4 7 2
| |
5 3
The problematic part is here:
# BLOCK 3
# PRED: 2 [19.0%] (false,exec)
L2:;
iftmp.0 = 1;
goto bb 7 (L14);
# SUCC: 7 [100.0%] (fallthru,exec)
# BLOCK 4
# PRED: 1 [50.0%] (true,exec) 2 [81.0%] (true,exec)
L4:;
iftmp.0 = 0;
# SUCC: 7 [100.0%] (fallthru)
# BLOCK 7
# PRED: 4 [100.0%] (fallthru) 3 [100.0%] (fallthru,exec)
L14:;
if ((unsigned char) (int) (unsigned char) iftmp.0 != 0) goto L8; else goto
L7;
# SUCC: 6 [33.0%] (true,exec) 5 [67.0%] (false,exec)
Possible causes of the missed jump thread:
1) Are casts getting in the way?
2) Do we need that one of edges into the condition we want to
thread through dominates the block?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18576
[Bug tree-optimization/18576] missing jump threading because of type changes
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 17:11 --- Note changing flow_loop_nested_p to return an int instead of unsigned char, the jump threading works -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18576
[Bug fortran/18578] New: intent(inout) violation is not detected
$ gfortran -v Reading specs from /home/ig25/lib/gcc/i686-pc-linux-gnu/4.0.0/specs Configured with: ../gcc/configure --prefix=/home/ig25 --enable-languages=c,c++,f95 Thread model: posix gcc version 4.0.0 20041120 (experimental) $ cat vary.f90 program main call foo(3.0) contains subroutine foo(a) real, intent(inout) :: a a = a + 3. end subroutine foo end program main $ gfortran vary.f90 $ The compiler should detect that the acutal parameter cannot be intent(inout) in this case. -- Summary: intent(inout) violation is not detected Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18578
[Bug tree-optimization/18576] missing jump threading because of type changes
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-20 17:11 --- Situation in DOM3: # BLOCK 4 # PRED: 3 [100.0%] (fallthru,exec) 2 [81.0%] (true,exec) 1 [50.0%] (true,exec) # iftmp.0_1 = PHI 0(2), 1(3), 0(1); L4:; D.1171_13 = (unsigned char) iftmp.0_1; D.1160_14 = (int) D.1171_13; D.1145_16 = (unsigned char) D.1160_14; if (D.1145_16 != 0) goto L8; else goto L7; # SUCC: 6 [33.0%] (true,exec) 5 [67.0%] (false,exec) So this is almost certainly casts again getting in the way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18576
[Bug fortran/18579] New: intent(out) violation is not detected
gfortran -v Reading specs from /home/ig25/lib/gcc/i686-pc-linux-gnu/4.0.0/specs Configured with: ../gcc/configure --prefix=/home/ig25 --enable-languages=c,c++,f95 Thread model: posix gcc version 4.0.0 20041120 (experimental) $ cat vary2.f90 program main real :: b call foo(b) contains subroutine foo(a) real, intent(out) :: a a = a + 3. end subroutine foo end program main $ gfortran vary2.f90 $ This violation of intent(out) should be reported. It's there for a reason... -- Summary: intent(out) violation is not detected Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18579
[Bug target/18580] New: Vectorizer failures
This PR is aimed at tracking the vectorizer failures on the SPARC. As of today, we have 11 failures on SPARC 32-bit: FAIL: gcc.dg/vect/vect-13.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-27.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-27a.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-29.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-29a.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-48a.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-56a.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-72.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-72a.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-77.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-77a.c scan-tree-dump-times vectorized 1 loops 1 which are either related to max vector operations (vect-13.c) or unaligned operations (the remaining 10 failures). -- Summary: Vectorizer failures Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc*-*-* GCC host triplet: sparc*-*-* GCC target triplet: sparc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18580
[Bug middle-end/18574] [4.0 Regression] bootstrap comprison failed
--- Additional Comments From hjl at lucon dot org 2004-11-20 17:33 --- I have verified that this patch http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01624.html is the cause. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |law at redhat dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[Bug target/18580] Vectorizer failures
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-20 17:34 --- Subject: Bug 18580 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-20 17:34:28 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg/vect: vect-13.c vect-27.c vect-27a.c vect-29.c vect-29a.c vect-48a.c vect-56a.c vect-72.c vect-72a.c vect-77.c vect-77a.c Log message: PR target/18580 * gcc.dg/vect/vect-13.c, vect-27.c, vect-27a.c, vect-29.c, vect-29a.c, vect-48a.c, vect-56a.c, vect-72.c, vect-72a.c, vect-77.c, vect-77a.c: XFAIL on the SPARC. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4623r2=1.4624 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-13.c.diff?cvsroot=gccr1=1.5r2=1.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-27.c.diff?cvsroot=gccr1=1.3r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-27a.c.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-29.c.diff?cvsroot=gccr1=1.3r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-29a.c.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-48a.c.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-56a.c.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-72.c.diff?cvsroot=gccr1=1.3r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-72a.c.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-77.c.diff?cvsroot=gccr1=1.4r2=1.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-77a.c.diff?cvsroot=gccr1=1.2r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18580
[Bug target/18580] Vectorizer failures (max, unaligned)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 17:44 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|sparc*-*-* | GCC host triplet|sparc*-*-* | Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2004-11-20 17:44:56 date|| Summary|Vectorizer failures |Vectorizer failures (max, ||unaligned) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18580
[Bug fortran/18578] intent(inout) violation is not detected
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 17:46 --- I assume you are talking about: call foo(3.0) if so confirmed, there should be a warning about this being undefined. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2004-11-20 17:46:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18578
[Bug fortran/18579] intent(out) violation is not detected
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 17:48 --- Confirmed. -- What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2004-11-20 17:48:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18579
[Bug target/18580] Vectorizer failures (max, unaligned)
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20 17:53 --- We have one additional failure on SPARC 64-bit: FAIL: gcc.dg/vect/pr18425.c scan-tree-dump-times vectorized 1 loops 1 The pr18425.c.t50.vect logfile contains: loop at pr18425.c:15: not vectorized: can't calculate alignment for data ref. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18580
[Bug tree-optimization/18576] [3.4/4.0 Regression] missing jump threading because of type changes
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 17:56 --- Hmm, this is 3.4 and 4.0 Regression, 3.3.3 produced: flow_bb_inside_loop_p: pushl %ebp movl%esp, %ebp movl8(%ebp), %ecx pushl %ebx movl12(%ebp), %eax xorl%ebx, %ebx cmpl%eax, %ecx je .L5 movl(%ecx), %edx cmpl%edx, (%eax) jle .L4 movl4(%eax), %eax cmpl%ecx, (%eax,%edx,4) je .L5 .p2align 4,,15 .L4: movl%ebx, %eax popl%ebx popl%ebp ret .p2align 4,,7 .L5: movl$1, %ebx jmp .L4 But 4.0 and 3.4.0 produces: flow_bb_inside_loop_p: pushl %ebp movl%esp, %ebp subl$8, %esp movl%esi, 4(%esp) movl8(%ebp), %ecx xorl%esi, %esi movl%ebx, (%esp) movl12(%ebp), %eax cmpl%eax, %ecx je .L3 movl(%ecx), %edx xorl%ebx, %ebx cmpl%edx, (%eax) jle .L5 movl4(%eax), %eax cmpl%ecx, (%eax,%edx,4) je .L7 .L5: testb %bl, %bl je .L2 .L3: movl$1, %esi .L2: movl%esi, %eax movl(%esp), %ebx movl4(%esp), %esi movl%ebp, %esp popl%ebp ret .L7: movl$1, %ebx jmp .L5 -- What|Removed |Added Severity|enhancement |minor Known to fail||3.4.0 4.0.0 Known to work||3.3.3 Summary|missing jump threading |[3.4/4.0 Regression] missing |because of type changes |jump threading because of ||type changes Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18576
[Bug target/18580] Vectorizer failures (max, unaligned)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 17:59 --- gcc.dg/vect/pr18425.c also fails on ppc64 IIRC, see PR 18403. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18580
[Bug tree-optimization/18403] FAILs to vectorize testcases on ppc64-linux
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20 18:26 --- Testcase pr18425.c can't be vectorized with -m64 because there's no vector support for 64bit elements. This testcase should also xfail (not temporarily) when -m64 is used or if the compiler is configured with powerpc64*. Same on SPARC 64-bit (i.e. sparc64-*-* or sparc-*-* with -m64). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18403
[Bug c++/18581] New: ICE in 3.4.3, regression from 3.4.2
The following snippet compiles fine with GCC versions prior to 3.4.3
and aborts with an ICE with 3.4.3:
struct S {
int i;
int a[];
};
S v = { 0, {} };
$ g++ -V 3.4.3 -c bug.cc
bug.cc:6: internal compiler error: in tree_low_cst, at tree.c:3313
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
$ g++ -V 3.4.2 -c bug.cc
$ g++ -V 3.4.1 -c bug.cc
$ g++ -V 3.4.0 -c bug.cc
$ g++ -V 3.3.3 -c bug.cc
--
Summary: ICE in 3.4.3, regression from 3.4.2
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bagnara at cs dot unipr dot it
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18581
[Bug c++/18581] ICE in 3.4.3, regression from 3.4.2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 18:33 --- *** This bug has been marked as a duplicate of 18384 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18581
[Bug c++/18384] [3.3/3.4/4.0 Regression] ICE on zero-length array with empty initializer...
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 18:33 --- *** Bug 18581 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||bagnara at cs dot unipr dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18384
[Bug java/18550] Remainder on floating point doesn't return the expected result
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 18:40 --- This is a mygwin bug as I only just get a call to fmod: callfmod -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18550
[Bug tree-optimization/18546] tree vectorizer does not understand RETURN_DECL
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 18:41 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-20 18:41:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18546
[Bug middle-end/18535] fix_irreducible_loops could be improved
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 18:42 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-20 18:42:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18535
[Bug target/18358] XPASS: gcc.c-torture/execute/20020227-1.c execution at -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 18:43 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-20 18:43:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18358
[Bug bootstrap/18142] Unknown pseudo-op: .machine compiling darwin-crt2.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 18:45 --- Confirmed, this is minor as the problem is that you need a new binutils as reported before. -- What|Removed |Added Severity|critical|minor Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2004-11-20 18:45:17 date|| Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18142
[Bug bootstrap/18142] Unknown pseudo-op: .machine compiling darwin-crt2.c
--- Additional Comments From bothner at gcc dot gnu dot org 2004-11-20 19:30 --- It's minor if we accept that people who run Darwin without the updated binutils and try to build from source will get an error message without any clue about what to do. Perhaps we can hope there aren't very many such people, or all/most of them will have read the release notes. But it seems to me obvious that re-applying Kelley's patch (imperfect though it might be) is an improvement over the current situation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18142
[Bug target/18510] GCC should have instrinsics for SPARC VIS instructions
--- Additional Comments From phython at gcc dot gnu dot org 2004-11-20 20:00 --- http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01653.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18510
[Bug middle-end/18582] New: Internal compiler error with arrays of type V2DF
Using
gcc -c ice.c
with the following file ice.c
typedef double v2df __attribute__((mode(V2DF)));
void
sse_interpolate_kernel()
{
double x2[2];
v2df xs[2];
xs[0] = __builtin_ia32_loadupd(x2);
}
leads to the following internal compiler error:
ice.c: In function `sse_interpolate_kernel':
ice.c:11: internal compiler error: in instantiate_virtual_regs_lossage, at
function.c:3756
Please submit a full bug report,
The error seems to disappear if I replace the array xs by simple variables or if
I use -O.
--
Summary: Internal compiler error with arrays of type V2DF
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sbo at mis dot mpg dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18582
[Bug middle-end/18582] [3.3/3.4 Regression] Internal compiler error with arrays of type V2DF
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 20:21 --- : Search converges between 2003-01-27-trunk (#173) and 2003-02-03-trunk (#174). : Search converges between 2003-01-28-3.3 (#19) and 2003-02-04-3.3 (#20). Fixed on the mainline by the merge of the tree-ssa: : Search converges between 2004-05-11-trunk (#454) and 2004-05-14-trunk (#455). Fixed on the tree-ssa branch: : Search converges between 2003-08-15-ssa (#58) and 2003-08-16-ssa (#59). (note this does not make sense as usually the things are fixed by the tree-ssa when optimizing). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2004-11-20 20:21:57 date|| Summary|Internal compiler error with|[3.3/3.4 Regression] |arrays of type V2DF |Internal compiler error with ||arrays of type V2DF Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18582
[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases
--- Additional Comments From ebotcazou at libertysurf dot fr 2004-11-20 20:32 --- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases [ Yes, I got the message regarding the bootstrap comparison failure on darwin. I'm going to try and reproduce it on a relatively old PPC box here. It'll take quite some time though. I do plan on flushing out one more patch while my PPC bootstrap is running. ] There are problems on x86_64, SPARC, PowerPC and i686, see the PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524
[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases
--- Additional Comments From law at redhat dot com 2004-11-20 20:39 --- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases On Sat, 2004-11-20 at 21:33 +0100, Eric Botcazou wrote: [ Yes, I got the message regarding the bootstrap comparison failure on darwin. I'm going to try and reproduce it on a relatively old PPC box here. It'll take quite some time though. I do plan on flushing out one more patch while my PPC bootstrap is running. ] There are problems on x86_64, SPARC, PowerPC and i686, see the PR. I haven't seen the comparison failure on i686 -- if I had I never would have checked in the patch. PPC is the only other kind of box I have here locally. There's some other approaches I can (and will) try while the PPC box is doing its thing. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524
[Bug c++/16307] -Wchar-subscripts does not warn on pointers
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 20:42 --- Fixed on the mainline by: 2004-11-20 Joseph S. Myers [EMAIL PROTECTED] * c-typeck.c (build_array_ref): Don't check for index == 0. Make checks for neither argument being an array or pointer (swapping the arguments if necessary), the array argument being a pointer to or array of functions and for -Wchar-subscripts warnings upfront. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16307
[Bug c++/16307] -Wchar-subscripts does not warn on pointers
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 20:48 --- Oh, it is not fixed by that patch. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16307
[Bug middle-end/18574] [4.0 Regression] bootstrap comprison failed
--- Additional Comments From hjl at lucon dot org 2004-11-20 21:47 --- FYI, I saw the same problem on Linux/ia64, Linux/ia32 and Linux/x86_64. I am using the last binutils from CVS if that matters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[Bug middle-end/18574] [4.0 Regression] bootstrap comprison failed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 21:56 --- I see it on i686-pc-linux-gnu, i686-pc-openbsd3.1 and powerpc-darwin. My linux box has 1GB of memory, maybe this is a GC problem but I really dout it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[Bug c/18583] New: error on valid code: const __attribute__((altivec(vector__))) doesn't work in arrays
If you try to have a constant array of vectors on gcc-3.4.3 you you may get parse errors when they shouldn't. All seems related to the vector definition and where you place the const attribute. If you define each array element constant and vector is defined as __vector - __attribute__((altivec(__vector))), you may get a parse error; if vector is defined as __attribute__((vector_size(16))) all works. If isn't a parser bug, is a documentation issue. please look at the testcase for further details -- Summary: error on valid code: const __attribute__((altivec(vector__))) doesn't work in arrays Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lu_zero at gentoo dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-unknown-linux-gnu GCC host triplet: powerpc-unknown-linux-gnu GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18583
[Bug target/18583] [3.4 Regression] error on valid code: const __attribute__((altivec(vector__))) doesn't work in arrays
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |target Keywords||rejects-valid Summary|error on valid code: const |[3.4 Regression] error on |__attribute__((altivec(vecto|valid code: const |r__))) doesn't work in |__attribute__((altivec(vecto |arrays |r__))) doesn't work in ||arrays Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18583
[Bug target/18583] [3.4 Regression] error on valid code: const __attribute__((altivec(vector__))) doesn't work in arrays
--- Additional Comments From lu_zero at gentoo dot org 2004-11-20 22:09 --- Created an attachment (id=7573) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7573action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18583
[Bug target/18583] [3.4 Regression] error on valid code: const __attribute__((altivec(vector__))) doesn't work in arrays
-- What|Removed |Added Known to fail||3.4.3 Known to work||4.0.0 3.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18583
[Bug target/18583] [3.4 Regression] error on valid code: const __attribute__((altivec(vector__))) doesn't work in arrays
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 22:35 --- Confirmed. The problem is: nop_expr 0x40f6aac8 type vector_type 0x40ddbd24 __vector signed short type integer_type 0x40dcc89c HI size integer_cst 0x40dc9280 constant 16 unit size integer_cst 0x40dc9360 constant 2 align 16 symtab 0 alias set -1 precision 16 min integer_cst 0x40dc9680 -32768 max integer_cst 0x40dc96a0 32767 pointer_to_this pointer_type 0x40ddb15c V8HI size integer_cst 0x40dc97a0 constant 128 unit size integer_cst 0x40dc99c0 constant 16 align 128 symtab 0 alias set -1 constant arg 0 vector_cst 0x40f419c0 type vector_type 0x40f68570 __vector signed short type integer_type 0x40dcc89c readonly V8HI size integer_cst 0x40dc97a0 128 unit size integer_cst 0x40dc99c0 16 align 128 symtab 0 alias set -1 pointer_to_this pointer_type 0x40f6889c constant elt0: integer_cst 0x40ddde40 constant 4095 elt1: integer_cst 0x40dddea0 constant 5681 elt2: integer_cst 0x40dddf00 constant 5351 elt3: integer_cst 0x40dddf60 constant 4816 elt4: integer_cst 0x40dddfc0 constant 4095 elt5: integer_cst 0x40f6b020 constant 4816 elt6: integer_cst 0x40f6b080 constant 5351 elt7: integer_cst 0x40f6b0e0 constant 5681 Note the NOP_EXPR and how the vector types are located at different memory location. -- What|Removed |Added CC||janis at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-20 22:35:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18583
[Bug middle-end/18574] [4.0 Regression] bootstrap comprison failed
--- Additional Comments From law at redhat dot com 2004-11-20 23:20 --- Subject: Re: [4.0 Regression] bootstrap comprison failed On Sat, 2004-11-20 at 21:56 +, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 21:56 --- I see it on i686-pc-linux-gnu, i686-pc-openbsd3.1 and powerpc-darwin. My linux box has 1GB of memory, maybe this is a GC problem but I really dout it. Actually, it has all the classic signs of a GC issue. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[Bug fortran/18584] New: --std=f would be nice
F is a modern subset of Fortran that does away with a lot of historical cruft (that Fortran has more than enough of). I personally would like to use it for new developments, and a --std=f switch would come in very handy for this. -- Summary: --std=f would be nice Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P1 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18584
[Bug java/18585] New: uniform passing of the classpath parameter
Sun: java: -classpath -cp javac: -classpath GNU: gij: -classpath -cp gcj: --classpath= While gij is unified to java, so is gcj neither to javac or to any other. What look better? --cp --classpath which has some style, or -cp -classpath which would be equal to java and gij. I prefer the last possiblity for gij and gcj. It could be a 'de facto' standard and fixed in 4.0. Bojan -- Summary: uniform passing of the classpath parameter Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: enhancement Priority: P1 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bojan at antonovic dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18585
[Bug java/18585] uniform passing of the classpath parameter
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21 00:02 --- Confirmed, related to PR 1374. -- What|Removed |Added OtherBugsDependingO||1374 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-21 00:02:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18585
[Bug fortran/18584] --std=f would be nice
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21 00:03 --- What is the difference between f and the standardized versions of fortran? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18584
[Bug java/18585] uniform passing of the classpath parameter
--- Additional Comments From bojan at antonovic dot com 2004-11-21 01:16 --- Subject: Re: uniform passing of the classpath parameter pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21 00:02 --- Confirmed, related to PR 1374. Ok. But from Sun's side, their actual verions 1.4 and 1.5 are the benchmark, and they are the same for this little topic. Bojan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18585
[Bug rtl-optimization/17860] [3.4 only] Wrong generated code for loop with varying bound
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21 01:39 --- The reason why I say this can never even happen on 4.0 is because the loop notes are not done until after the new rtl-loop pass is done. -- What|Removed |Added Summary|Wrong generated code for|[3.4 only] Wrong generated |loop with varying bound |code for loop with varying ||bound Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17860
[Bug c++/18530] [4.0 regression] Bogus warnings about shadowed variables __ct, __dt
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-21
01:40 ---
There seems to be some conflict between the names __ct, __dt and the
constructor and destructor of the class. Just compile the following code
snippet with -Wshadow:
struct A
{
A();
~A();
void foo(int __ct, int __dt) {}
};
I get the error messgage:
bug.cc: In member function 'void A::foo(int, int)':
bug.cc:5: warning: declaration of '__dt' shadows a member of 'this'
bug.cc:5: warning: declaration of '__ct' shadows a member of 'this'
With different names for the parameters of foo no warning is generated.
If I remove the destructor, only the warning for __ct is generated.
It looks like the problem was introduced in mid July:
: Search converges between 2004-07-13-trunk (#485) and 2004-07-14-trunk (#486).
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||monitored
Last reconfirmed|-00-00 00:00:00 |2004-11-21 01:40:57
date||
Summary|Bogus warning about shadowed|[4.0 regression] Bogus
|variable in |warnings about shadowed
|locale_facets.tcc |variables __ct, __dt
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18530
[Bug c++/18530] [4.0 regression] Bogus warnings about shadowed variables __ct, __dt
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
01:50 ---
There were only two patches to the C++ front-end during that time period. Both
were by the same
person and they both touched the namelookup code.
2004-07-14 Mark Mitchell [EMAIL PROTECTED]
2004-07-13 Mark Mitchell [EMAIL PROTECTED]
The part which looks like caused this problem is:
* name-lookup.c (pushdecl): Use lookup_member, not
IDENTIFIER_CLASS_VALUE.
The problem relates to this testcase:
struct A
{
int f(void);
void foo(int f) {}
};
note how f is a real member here and we warn about it but since __ct and __dt,
I think refers to the
construtor and deconstrutor so we get the overloaded set for them too.
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org, mark at codesourcery
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18530
[Bug c++/16307] -Wchar-subscripts does not warn on pointers
-- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16307
[Bug c++/18586] New: [4.0 regression] ICE on invalid template member declaration
The following code snippet causes an ICE on mainline:
==
templateint struct A
{
templateint N int AN::i;
};
==
bug.cc:3: error: type 'AN' is not derived from type 'Aanonymous '
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
According to Phil's regression hunter the regression was introduced in August:
: Search converges between 2004-08-04-trunk (#504) and 2004-08-05-trunk (#505).
--
Summary: [4.0 regression] ICE on invalid template member
declaration
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18586
[Bug c++/18586] [4.0 regression] ICE on invalid template member declaration
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21 02:02 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-21 02:02:13 date|| Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18586
[Bug c++/18530] [4.0 regression] Bogus warnings about shadowed variables __ct, __dt
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-21 02:21 --- Mark, it was in fact your patch http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg00730.html that caused the regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18530
[Bug c++/18586] [4.0 regression] ICE on invalid template member declaration
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21 02:29 --- Confirmed, here is the backtrace: #0 0x001f2ad8 in pop_scope (t=0x0) at ../../gcc/cp/name-lookup.c:2571 #1 0x0013cde8 in cp_parser_init_declarator (parser=0x41e9a30c, decl_specifiers=0xb410, function_definition_allowed_p=1 '\001', member_p=1 '\001', declares_class_or_enum=0, function_definition_p=0xb460 ) at ../../gcc/cp/parser.c:10615 #2 0x001467cc in cp_parser_single_declaration (parser=0x41e9a30c, member_p=1 '\001', friend_p=0xb4c8 ) at ../../gcc/cp/parser.c:14876 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18586
[Bug rtl-optimization/18577] [3.3 regression] variable use moved before initialization
--- Additional Comments From falk at debian dot org 2004-11-21 02:33
---
The bug seems to be caused by the loop unroller making a pseudo local
to be able to duplicate it while it is still needed outside of the loop.
Reverting Eric Botcazou's patch for rtl-optimization/11841, which is
also about this, fixes the problem. I don't really understand what's going
on, but is it possible we still have to look at the pseudo luids and not
only the note luids? Like this?
diff -u -p -r1.184.2.9 unroll.c
--- unroll.c17 May 2004 21:05:48 - 1.184.2.9
+++ unroll.c21 Nov 2004 02:30:41 -
@@ -794,6 +794,8 @@ unroll_loop (loop, insn_count, strength_
for (r = FIRST_PSEUDO_REGISTER; r max_reg_before_loop; ++r)
if (REGNO_FIRST_UID (r) 0 REGNO_FIRST_UID (r) max_uid_for_loop
REGNO_FIRST_LUID (r) = copy_start_luid
+REGNO_LAST_UID (r) 0 REGNO_LAST_UID (r) max_uid_for_loop
+REGNO_LAST_LUID (r) = copy_end_luid
REGNO_LAST_NOTE_UID (r) 0 REGNO_LAST_NOTE_UID (r)
max_uid_for_loop
REGNO_LAST_NOTE_LUID (r) = copy_end_luid)
{
--
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18577
[Bug c++/18586] [4.0 regression] ICE on invalid template member declaration
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21 03:18 --- I am almost certain this was caused by: http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00212.html -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org, mark at codesourcery ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18586
[Bug middle-end/18574] [4.0 Regression] bootstrap comprison failed
--- Additional Comments From law at redhat dot com 2004-11-21 04:24 --- Subject: Re: [4.0 Regression] bootstrap comprison failed On Sat, 2004-11-20 at 21:56 +, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20 21:56 --- I see it on i686-pc-linux-gnu, i686-pc-openbsd3.1 and powerpc-darwin. My linux box has 1GB of memory, maybe this is a GC problem but I really dout it. Unable to reproduce on my PPC box either. I'm going to try a couple more things tonight to try and ferret out this problem. But if those are not successful I'm going to need someone to do a little legwork to help me nail this thing down. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[Bug middle-end/12392] very long optimized compile
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21 04:53 --- With the mainline on ppc-darwin we have a huge problem in the scheduler: scheduling: 131.99 (44%) usr 52.35 (75%) sys 231.63 (46%) wall PRE (GCSE) is also a problem too: PRE : 38.78 (13%) usr 1.82 ( 3%) sys 73.43 (15%) wall For the scheduler at least we have linked lists which we allocate a lot of. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392
[Bug middle-end/18574] [4.0 Regression] bootstrap comprison failed
--- Additional Comments From law at redhat dot com 2004-11-21 05:15 --- I've found something that might be of interest. It's certainly odd, but I don't yet know if the odd behavior I'm could explain the bootstrap comparison failures yet. I'm still poking... Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[Bug tree-optimization/18587] New: build_v_may_defs and build_vuses should be hastables instead of varray
For PR 15855 we see that the tree aliasing analysis is slow: tree alias analysis : 24.22 ( 6%) usr 0.75 ( 2%) sys 26.57 ( 5%) wall 9% of the total time is spent looking at for if something is in either build_v_may_defs or build_vuses. -- Summary: build_v_may_defs and build_vuses should be hastables instead of varray Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: minor Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: dnovillo at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18587
[Bug middle-end/15855] [3.4/4.0 Regression] g++ crash with -O2 and -O3 on input file
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21 05:33 --- These part are 4.0 regressions: tree alias analysis : 24.22 ( 6%) usr 0.75 ( 2%) sys 26.57 ( 5%) wall tree PHI insertion: 7.71 ( 2%) usr 1.26 ( 3%) sys 9.24 ( 2%) wall tree SSA rewrite : 11.52 ( 3%) usr 4.32 (11%) sys 20.63 ( 4%) wall tree SSA other: 21.33 ( 5%) usr 3.77 (10%) sys 27.79 ( 5%) wall tree operand scan : 26.65 ( 7%) usr 3.78 (10%) sys 31.64 ( 6%) wall These are most likely not: combiner : 25.57 ( 6%) usr 0.20 ( 1%) sys 26.78 ( 5%) wall scheduling: 211.44 (52%) usr 4.35 (11%) sys 225.27 (43%) wall -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15855
[Bug middle-end/15855] [3.4/4.0 Regression] g++ crash with -O2 and -O3 on input file
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21 05:54 --- The combiner problem comes from the distrubute_notes loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15855
[Bug tree-optimization/18587] build_v_may_defs and build_vuses should be hastables instead of varray
-- What|Removed |Added OtherBugsDependingO||15855 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18587
[Bug middle-end/18574] [4.0 Regression] bootstrap comprison failed
--- Additional Comments From law at redhat dot com 2004-11-21 06:31 --- OK. I can see a way that we might be getting these comparison failures. We're hashing on pointers, then doing table traversals. If the memory layout changes, the ordering of objects in the hash table can change. Changing the order of objects in the hash table changes the order in which they are presented to the callbacks during a hash table traversal. That in turn can change the ordering of incoming edges in newly created blocks. That in turn can change the order of PHI arguments in those newly created blocks. Changing the order of arguments within the PHI nodes can change how we coalesce during the out-of-ssa translation. At least that's the best theory I've got. I'm testing a patch which loses the pointer hash (we can hash on the index of the destination block). That ought to bring stability to the hash table traversals even if the memory map changes. It should also be slightly faster. Of course since I haven't been able to actually reproduce the failure I have no way of directly knowing if my theory is correct. I'll have to rely on y'all and the autotester to tell me if things are better. Anyway, I'm hoping to get those changes in tonight if testing can complete before I crash for the night. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases
--- Additional Comments From ebotcazou at libertysurf dot fr 2004-11-21 07:12 --- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases I haven't seen the comparison failure on i686 -- if I had I never would have checked in the patch. PPC is the only other kind of box I have here locally. Right, the problem seems to be very sensitive to the environment. H.J. saw it on AMD64 while I didn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524
[Bug rtl-optimization/18577] [3.3 regression] variable use moved before initialization
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-21 07:14 --- The bug seems to be caused by the loop unroller making a pseudo local to be able to duplicate it while it is still needed outside of the loop. Reverting Eric Botcazou's patch for rtl-optimization/11841, which is also about this, fixes the problem. Thanks for investigating. I don't really understand what's going on, but is it possible we still have to look at the pseudo luids and not only the note luids? Like this? IIRC note luids are supposed to be a superset of regular luids, so your check should be redundant (see regclass.c:reg_scan_mark_refs). Now something could have invalidated this relationship. -- What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18577
