[Bug middle-end/26835] New: ICE in f951 on valid code at -O2 -ftree-loop-linear
$ cat test.f90 subroutine testf(b,a,index,n,pad,check1i) integer, intent(in) :: n,pad,index(n) integer, parameter :: r16=selected_real_kind(15,30) integer, save :: n2,n2bit,n4 real*8, intent(inout) :: a(0:n/8-1+pad,0:7),b(0:n/8-1+pad,0:7),check1i real*8 :: check1r,c0,s0,r1,r2,r3,i1,i2,i3,tt real*8 :: tr1,tr2,ti1,ti2,c1,s1,c2,s2,c3,s3 real*8 :: t1,t2,t3,t4,t5,t6,t7,t8,t9,t10,t11,t12,t13,t14,t15,t16 real*8, parameter :: rnd_const = 0.75d0 * 2d0**53 real*8, allocatable, save :: w1(:,:),w2(:,:) real(kind=r16), save :: mt,one=1,two=2,one_fourth,pi,theta,theta2,theta4,mt2,mt4 logical, save :: first_entry=.true. n2=n/2; n2bit=nint(log(1d0*n2)/log(2d0)) n4=n/4 allocate(w1(2,n4)) j=1 mm=1 if(mod(n2bit,3)==1)then do m=1,n4-1 mt =m*theta w2(1,j)=cos(mt) w2(2,j)=sin(mt) j=j+1 enddo endif if(n2==1048576)then; GOTO 1; endif if(n2==2097152)GOTO 1 STOP 1 continue tt=a(0,0) if(n2==4096)then; a=b; RETURN; endif if(n2==32768)RETURN if(n2==65536)then RETURN endif if(n2==131072)then RETURN endif if(n2==262144)then; a=b; RETURN; endif if(n2==524288)then RETURN endif if(n2==1048576)then RETURN endif if(n2==2097152)RETURN STOP end subroutine testf $ elm3b11:/home/pawar /opt/gcc-nightly/trunk-20060323/bin/gfortran -c -o test.o -ftree-loop-linear -O2 -m32test.f90 gfortran: Internal error: Segmentation fault (program f951) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for instructions. This is a reduced test case from 189.lucas benchmark. It could be reduced further. But I'm getting different errors if I try to do that. -- Summary: ICE in f951 on valid code at -O2 -ftree-loop-linear Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26835
[Bug middle-end/26836] New: ICE on valid code (tree type is null in tree-gimple.c)
$ cat test.f90 subroutine ld_mod (sinc,einc) implicit real(kind(0d0)) (a-h,o-z) real(kind(0d0)), intent(in) :: sinc(6), einc(6) real(kind(0d0)), parameter :: OneUpon3 = (1.0D+0 / 3.0D+0) real(kind(0d0)), parameter :: TwoUpon3 = (2.0D+0 / 3.0D+0) Bulk_Strain_Inc = Einc(1) + Einc(2) + Einc(3) DEmag2 = -Bulk_Strain_Inc*Bulk_Strain_Inc DO i = 1,6 DEmag2 = DEmag2 + Einc(i)*Einc(i) ENDDO IF (DEmag2 .GT. 0.0) THEN DO i = 1,6 DSmag2 = DSmag2 + Sinc(i)*Sinc(i) ENDDO ENDIF RETURN END $ elm3b11:/home/pawar /opt/gcc-nightly/trunk-20060323/bin/gfortran -O2 -m32 test.f90 test.f90: In function ld_mod: test.f90:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. backtrace shows, in execute_pass_one(), pass-name=phicprop -- Summary: ICE on valid code (tree type is null in tree-gimple.c) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26836
[Bug middle-end/26817] New: ICE in verify_ssa
$ cat y.f90 subroutine test(b,a,n) integer, intent(in) :: n integer, save :: n2 real*8, save :: n2inv real*8, intent(inout) :: a(0:n/8-1,0:7),b(0:n/8-1,0:7) real*8 :: r1,i1,tt if(n2==262144)then; a=b; GOTO 1; endif if(n2==524288)then GOTO 1 endif if(n2==1048576)then GOTO 1 endif if(n2==2097152)GOTO 1 STOP 1 continue r1=a(0,4); i1=a(1,4) tt=(r1+i1)*(r1-i1); i1=r1*i1 b(2,0)=tt *n2inv b(3,0)=(i1+i1)*n2inv if(n2==8)RETURN STOP end subroutine test $ elm3b11:/home/pawar /opt/gcc-nightly/trunk-20060322/bin/gfortran -c -o y.o -ftree-loop-linear -O2 -m32 y.f90 y.f90: In function test: y.f90:1: error: definition in block 15 follows the use for SSA_NAME: PARM_NOALIAS.19_70 in statement: # VUSE PARM_NOALIAS.19_70; r1_33 = (*a_32)[D.916_30]; y.f90:1: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in verify_ssa Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26817
[Bug other/26601] New: --whole-program --combine with gcc4.1 fails to link cpu2000 benchmarks
Hi, Following is the list of benchmarks failed to compile/link using --fwhole-program --combine option with GCC, $/opt/gcc-nightly/4.1-20060228/bin/gcc -v Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_4.1_anonsvn/4.1/configure --prefix=/opt/gcc-nightly/4.1-20060228 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/4.1-20060228/bin/as --with-ld=/opt/gcc-nightly/4.1-20060228/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,java,objc --enable-checking --with-mpfr=/opt/gcc-nightly/4.1-20060228 Thread model: posix gcc version 4.1.0 Integer: 164.gzip, 175.vpr, 176.gcc, 181.mcf, 186.crafty, 197.parser, 252.eon, 253.perlbmk, 254.gap, 255.vortex, 256.bzip2, 300.twolf Floating point: 168.wupwise, 171.swim, 172.mgrid, 173.applu, 177.mesa, 178.galgel, 187.facerec, 188.ammp, 189.lucas, 191.fma3d, 200.sixtrack 301.apsi Onlys benchmark succeeded are 179.art and 183.equake. The other compiler options used are -m32 -O3 -mcpu=power4 All the integer benchmarks failed with indefined reference errors. All the fortran benchmarks failed with following error, /opt/gcc-nightly/4.1-20060228/lib/gcc/powerpc64-linux/4.1.0/../../../../lib/libgfortranbegin.a(fmain.o): In function `main': /home/gccbuild/gcc_4.1_anonsvn/4.1/libgfortran/fmain.c:18: undefined reference to `MAIN__' collect2: ld returned 1 exit status -- Summary: --whole-program --combine with gcc4.1 fails to link cpu2000 benchmarks Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26601
[Bug fortran/26550] New: ICE in gimplify_expr() on valid code
Hello, Following code causes an ICE in gimplify_expr(). $ cat test.f90 module my_module implicit none type point real :: x end type point type(point), pointer, public :: stdin = NULL() contains subroutine p(w) character(128) :: w call r(stdin,(/w/)) end subroutine end elm3b11:/home/pawar /opt/gcc-nightly/trunk-20060303/bin/gfortran test.f90 test.f90: In function p: test.f90:10: internal compiler error: in gimplify_expr, at gimplify.c:5788 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in gimplify_expr() on valid code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26550
[Bug regression/26435] New: ICE with -O1 -ftree-loop-linear and higher optimization
Hi,
Following code gets ICE.
elm3b11:/home/pawar cat test.c
typedef struct _A2 A2;
struct _A2 {
int type ;
int n1 ;
int n2 ;
int inc1 ;
int inc2 ;
double *entries ;
};
double
A2_infinityNorm (
A2 *mtx
) {
double norm ;
int ncol, nrow ;
if ( (nrow = mtx-n1) = 0 || (ncol = mtx-n2) = 0 ) {
return(0.0) ;
}
norm = 0.0 ;
if ( ((mtx)-type == 1) ) {
if ( mtx-inc2 == 1 ) {
double sum ;
double *row = mtx-entries ;
int inc1 = mtx-inc1, irow, jcol ;
for ( irow = 0 ; irow nrow ; irow++, row += inc1 ) {
for ( jcol = 0, sum = 0.0 ; jcol ncol ; jcol++ ) {
sum += fabs(row[jcol]) ;
}
if ( norm sum ) {
norm = sum ;
}
}
}
}
return(norm) ; }
elm3b11:/home/pawar /opt/gcc-nightly/trunk-20060220/bin/gcc -c -O1
-ftree-loop-linear test.c
test.c: In function A2_infinityNorm:
test.c:32: warning: incompatible implicit declaration of built-in function
fabs
test.c:15: error: definition in block 19 does not dominate use in block 15
for SSA_NAME: row_27 in statement:
row_38 = PHI row_27(15), row_18(6);
PHI argument
row_27
for PHI node
row_38 = PHI row_27(15), row_18(6);
test.c:15: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE with -O1 -ftree-loop-linear and higher optimization
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uttamp at us dot ibm dot com
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26435
[Bug other/26327] New: memory leaks
I've few memory leaks to report and they are as follows, ipa-inline.c in function cgraph_early_inlining. pointer 'order' tree-if-conv.c infunction combine_blocks, returned memory. loop-unroll.c in function referenced_in_one_insn_in_loop_p, pointer 'body' cfgloop.c in function cancel_loop, pointer 'bbs' collect2.c in function prefix_from_string, pointer 'nstore' reload1.c in function fix_abnormal_edges, pointer 'blocks' I'll submit a patch to fix these leaks. -- Summary: memory leaks Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26327
[Bug other/26147] another memory leak
--- Comment #4 from uttamp at us dot ibm dot com 2006-02-16 00:35 --- Subject: Re: another memory leak --- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-15 23:09 --- Fixed. dist_v and init_v are GC pointers so they don't really need to be freed manually. That's correct. I realized it after submitting the bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26147
[Bug other/26184] New: memory leaks in swing modulo scheduling function
Hi, Found following memory leaks in modulo-sched.c In function, sms_schedule(), memory allocated and pointed by g_arr is not freed. In function sms_schedule_by_order(), sbitmap memory allocated and pointed by must_precede, must_follow and tobe_scheduled respectively, not freed. -- Summary: memory leaks in swing modulo scheduling function Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26184
[Bug other/26184] memory leaks in swing modulo scheduling function
--- Comment #1 from uttamp at us dot ibm dot com 2006-02-08 22:43 --- I missed another memory leak in the same file, in function generate_reg_moves(), memory pointed by uses_of_defs is not freed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26184
[Bug other/26184] memory leaks in swing modulo scheduling function
--- Comment #2 from uttamp at us dot ibm dot com 2006-02-08 22:44 --- I'll submit a patch to fix these leaks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26184
[Bug c/26145] New: memory leak in loop unswitching.
Hi, Noticed a memory leak in tree-ssa-loop-unswitch.c in routine tree_unswitch_single_loop() function. I'll submit a patch to fix this leak. -- Summary: memory leak in loop unswitching. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26145
[Bug tree-optimization/26147] New: another memory leak
After running coverity tool I discovered following memory leaks. 1) in gcc/opts.c: memory never freed allocated by 'new_option' pointer. 2) in gcc/df-core.c: Memory never freed allocated by 'postorder' pointer. 3) in tree-data-ref.c: memory never freed allocated by dist_v and init_v pointers. I'll submit the patches to fix these leaks. -- Summary: another memory leak Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26147
[Bug c/25929] ICE with -ftree-loop-linear
--- Comment #3 from uttamp at us dot ibm dot com 2006-01-25 16:56 ---
Reduced test case
int vq_index(float *in, const float *codebook, int len, int entries)
{
int i,j;
int best_index=0;
for (i=0;ientries;i++)
{
float dist=0;
for (j=0;jlen;j++)
{
float tmp = in[j]-*codebook++;
dist += tmp*tmp;
}
if (i==0 || dist0)
{
best_index=i;
}
}
return best_index;
}
$ elm3b11:/home/pawar /opt/gcc-nightly/trunk-20060123/bin/gcc -O1
-ftree-loop-linear -c ccbdYzn2.c
ccbdYzn2.c: In function vq_index:
ccbdYzn2.c:3: internal compiler error: in lambda_loopnest_to_gcc_loopnest, at
lambda-code.c:1982
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25929
[Bug tree-optimization/25937] ICE with -O2 -ftree-loop-linear
--- Comment #5 from uttamp at us dot ibm dot com 2006-01-25 23:14 --- I put the line numbers in there because I just wanted to point out the different error messages I get with small changes in code. ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25937
[Bug tree-optimization/25962] New: Pointer (null) check after the use
In file gcc/cgraphunit.c, function verify_cgraph_node(struct cgraph_node
*node), the input argument 'node' has been dereferenced before doing any
checking till on line 717 with following codition,
...
717 if (!node)
718{
719 error (node not found in DECL_ASSEMBLER_NAME hash);
720 error_found = true;
721}
...
Shouldn't this code be moved at the begining of this function? before
de-referencing it?
Also, on line 789-793, if there is any error, we call dump_cgraph_node(), which
dumps the cgraph node. Shouldn't we do a check for non-null 'node', either here
before calling or in function dump_cgraph_node() itself? This has been,
reported as a possible error by 'coverity prevent tool'.
Any thoughts?
--
Summary: Pointer (null) check after the use
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uttamp at us dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25962
[Bug c++/11987] [3.4/4.0/4.1/4.2 regression] Accepts-invalid with inherited nested type
--- Comment #10 from uttamp at us dot ibm dot com 2006-01-23 19:20 --- Just for the information. I tested this bug against following branches, gcc-3.2.3 - causes an ICE gcc-3.4.0 - no ICE gcc-3.4.2 - no ICE gcc-3.4.3 - no ICE gcc-4.0.0 - no ICE gcc-4.1.0 - no ICE gcc-4.0.2 - no ICE gcc-4.2.0 20060123 - no ICE -- uttamp at us dot ibm dot com changed: What|Removed |Added CC||uttamp at us dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11987
[Bug c/25933] New: memory leaks
Hi All, Last week I ran a static analysis tool 'coverity prevet' on the GCC codebase and found few memory leaks. 1) One of the memory leak is in gcc/loop-unroll.c, not freeing the dom_bbs pointer while returning from the function in function unroll_loop_runtime_iterations. 2) another memory leak is in tree-ssa-live.c, not freeing memory allocated by varaible seen in function type_var_init. I'll submit the patches for the above problems. -- Summary: memory leaks Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25933
[Bug tree-optimization/25937] New: ICE: Illegal instruction, with valid code
Hi,
Following code causing an ICE with mainline.
elm3b9:/home/pawar cat test.c
1 int func(float *v1, const float *v2, int l, int e)
2 {
3int i,j, bi=0;
4float md=0, d=0, t;
5for (i=0;i e;i--)
6{
7 for (j=0;jl;j++)
8 {
9 t = v1[j]-*v2++;
10 d += t*t;
11 }
12 if ( d md)
13 md=d;
14}
15 }
$ /opt/gcc-nightly/trunk-20060123/bin/gcc -v -c -O2 -ftree-loop-linear test.c
Using built-in specs.
Target: powerpc64-linux
Configured with: /home/gccbuild/gcc_trunk_anonsvn/trunk/configure
--prefix=/opt/gcc-nightly/trunk-20060123 --build=powerpc64-linux
--host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32
--with-as=/opt/gcc-nightly/trunk-20060123/bin/as
--with-ld=/opt/gcc-nightly/trunk-20060123/bin/ld --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,java,objc
--enable-checking --with-mpfr=/opt/gcc-nightly/trunk-20060123
Thread model: posix
gcc version 4.2.0 20060123 (experimental)
/home/gcc-nightly/trunk-20060123/bin/../libexec/gcc/powerpc64-linux/4.2.0/cc1
-quiet -v -iprefix
/home/gcc-nightly/trunk-20060123/bin/../lib/gcc/powerpc64-linux/4.2.0/
-D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux
-Asystem=linux -Asystem=unix -Asystem=posix test.c -quiet -dumpbase test.c
-auxbase test -O2 -version -ftree-loop-linear -o /tmp/cc145sWC.s
ignoring nonexistent directory
/home/gcc-nightly/trunk-20060123/bin/../lib/gcc/powerpc64-linux/4.2.0/../../../../powerpc64-linux/include
ignoring duplicate directory
/opt/gcc-nightly/trunk-20060123/lib/gcc/powerpc64-linux/4.2.0/include
ignoring nonexistent directory
/opt/gcc-nightly/trunk-20060123/lib/gcc/powerpc64-linux/4.2.0/../../../../powerpc64-linux/include
#include ... search starts here:
#include ... search starts here:
/home/gcc-nightly/trunk-20060123/bin/../lib/gcc/powerpc64-linux/4.2.0/include
/usr/local/include
/opt/gcc-nightly/trunk-20060123/include
/usr/include
End of search list.
GNU C version 4.2.0 20060123 (experimental) (powerpc64-linux)
compiled by GNU C version 4.2.0 20060123 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: ab2acf781189b94f37d1814045ecf667
test.c: In function func:
test.c:2: internal compiler error: Illegal instruction
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
If I remove -v option from the command line, I get following,
$ /opt/gcc-nightly/trunk-20060123/bin/gcc -c -O2 -ftree-loop-linear test.c
gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
If I remove, declaration bi=0 from line 3, I get following,
$ elm3b11:/home/pawar/reghunt/work /opt/gcc-nightly/trunk-20060123/bin/gcc -c
-O2 -ftree-loop-linear test.c
test.c: In function func:
test.c:2: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
On line 5, if change i-- to i++, I get following (without bi=0),
$ elm3b11:/home/pawar/reghunt/work /opt/gcc-nightly/trunk-20060123/bin/gcc -c
-O2 -ftree-loop-linear test.c
test.c: In function func:
test.c:2: error: definition in block 17 does not dominate use in block 6
for SSA_NAME: v2_38 in statement:
v2_42 = PHI v2_38(6), v2_31(11);
PHI argument
v2_38
for PHI node
v2_42 = PHI v2_38(6), v2_31(11);
test.c:2: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
and with bi=0, on line 3 I get,
$ elm3b11:/home/pawar/reghunt/work /opt/gcc-nightly/trunk-20060123/bin/gcc -c
-O2 -ftree-loop-linear test.c
test.c: In function func:
test.c:2: error: definition in block 17 does not dominate use in block 6
for SSA_NAME: v2_38 in statement:
v2_42 = PHI v2_38(6), v2_9(11);
PHI argument
v2_38
for PHI node
v2_42 = PHI v2_38(6), v2_9(11);
test.c:2: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE: Illegal instruction, with valid code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uttamp at us dot ibm dot com
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25937
[Bug tree-optimization/25937] ICE: Illegal instruction, with valid code
--- Comment #1 from uttamp at us dot ibm dot com 2006-01-24 01:58 --- fyi: This works till trunk-20060106. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25937
[Bug middle-end/24565] [4.1/4.2 Regression] facerec performance regression
--- Comment #6 from uttamp at us dot ibm dot com 2006-01-16 18:19 --- Steve, The numbers have changed since the last time I saw them. The current facerec perf. numbers are much close to the Oct. when I reported it. Do we still want me to investigate this any further? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24565
[Bug middle-end/24565] [4.1/4.2 Regression] facerec performance regression
--- Comment #8 from uttamp at us dot ibm dot com 2006-01-16 23:56 --- I'm closing this bug as FIXED since the current facerec benchmark numbers on powerpc64-linux seems to be lot closer to the numbers generatged in Oct 2005 (before reported regression happen). -- uttamp at us dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24565
[Bug middle-end/23785] [4.1/4.2 Regression] 197.parser performance drop
--- Comment #6 from uttamp at us dot ibm dot com 2006-01-17 00:42 --- With the latest mainline, the performance numbers for parser benchmark are very close to the reported numbers (on July 29th 2005). With the mainline, parser numbers on powerpc64-linux with -O3 -m32 -mcpu=power4 -ffast-math -fpeel-loops -ftree-loop-linear -funroll-loops flags is, 197.parser: 438 (and the reported drop was at 423). Looking at the current numbers I don't think I should investigate this any further. I'm thinking of closing this bug as FIXED. Any thoughts? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23785
[Bug fortran/24886] another runtime error goes undetected
--- Comment #6 from uttamp at us dot ibm dot com 2006-01-11 22:02 --- Subject: Re: another runtime error goes undetected On Wed, 2006-01-11 at 09:07 +, pault at gcc dot gnu dot org wrote: --- Comment #5 from pault at gcc dot gnu dot org 2006-01-11 09:07 --- (In reply to comment #4) This is not a bug. gfortran behavior is identical to ifort. Actually, it is quite specifically NOT permitted by the standard. To quote 12.4.1.1: If a scalar dummy argument is of type default character, the length len of the dummy argument shall be less than or equal to the length of the actual argument. The dummy argument becomes associated with the leftmost len characters of the actual argument. If an array dummy argument is of type default character, the restriction on the length is for the entire array and not for each array element. The reason for this is obvious enough; try writing beyond len and you will eventually get a seg fault. Uttam is quite correct to pick this out as a bug, although I am not sure that we want a runtime error, except when -fbounds-check is active. This could be implemented, with advantage in trans-expr(gfc_conv_function_call) by copying over some of the code from trans-array.c. Compile time check will be much better fix than the runtime. As it happens, in building a fix for PRs 20881, 23308 25710, I am about to add same file argument checking, which is why I encountered this PR. It will fix Uttam's testcase but not the case where subroutine foo is truly external. - Uttam -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24886
[Bug middle-end/25657] runtime error with 200.sixtrack benchmark
--- Comment #8 from uttamp at us dot ibm dot com 2006-01-04 16:50 --- This has been fixed with todays mainline tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25657
[Bug middle-end/25656] runtime error with 191.fma3d benchmark
--- Comment #4 from uttamp at us dot ibm dot com 2006-01-04 16:50 --- This has been fixed with todays mainline tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25656
[Bug middle-end/25657] runtime error with 200.sixtrack benchmark
--- Comment #9 from uttamp at us dot ibm dot com 2006-01-04 16:51 --- *** This bug has been marked as a duplicate of 25578 *** -- uttamp at us dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25657
[Bug rtl-optimization/25578] [4.2 Regression] gfortran version 4.2.0 20051227 - 144 new testsuite failures since 2005121
--- Comment #9 from uttamp at us dot ibm dot com 2006-01-04 16:51 --- *** Bug 25657 has been marked as a duplicate of this bug. *** -- uttamp at us dot ibm dot com changed: What|Removed |Added CC||uttamp at us dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25578
[Bug middle-end/25656] runtime error with 191.fma3d benchmark
--- Comment #5 from uttamp at us dot ibm dot com 2006-01-04 16:52 --- *** This bug has been marked as a duplicate of 25578 *** -- uttamp at us dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25656
[Bug rtl-optimization/25578] [4.2 Regression] gfortran version 4.2.0 20051227 - 144 new testsuite failures since 2005121
--- Comment #10 from uttamp at us dot ibm dot com 2006-01-04 16:52 --- *** Bug 25656 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25578
[Bug middle-end/25656] New: runtime error with 191.fma3d benchmark
Since 23rd Dec. this benchmark getting runtime error with miscompare output. I'm doing regression hunt to track the patch which most probably have caused the failure. -- Summary: runtime error with 191.fma3d benchmark Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25656
[Bug middle-end/25657] New: runtime error with 200.sixtrack benchmark
Since 23rd Dec. this benchmark getting runtime error with miscompare output. I'm doing regression hunt to track the patch which most probably have caused the failure. Since similar problem is reported for fma3d benchmark (maybe the same patch has caused the problem) Has this seen on other platforms, too? Uttam -- Summary: runtime error with 200.sixtrack benchmark Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25657
[Bug middle-end/25657] runtime error with 200.sixtrack benchmark
--- Comment #3 from uttamp at us dot ibm dot com 2006-01-04 01:46 --- peak options are, -O3 -mcpu=power4 -ffast-math -ftree-loop-linear -funroll-loops -fpeel-loops -m32 base options are, -O2 -mcpu=power4 -m32 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25657
[Bug middle-end/25656] runtime error with 191.fma3d benchmark
--- Comment #3 from uttamp at us dot ibm dot com 2006-01-04 01:47 --- peak options are, -O3 -mcpu=power4 -ffast-math -ftree-loop-linear -funroll-loops -fpeel-loops -m32 base options are, -O2 -mcpu=power4 -m32 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25656
[Bug middle-end/25657] runtime error with 200.sixtrack benchmark
--- Comment #7 from uttamp at us dot ibm dot com 2006-01-04 02:02 --- Yes, I'll. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25657
[Bug middle-end/24565] [4.1/4.2 Regression] facerec performance regression
--- Comment #4 from uttamp at us dot ibm dot com 2005-12-22 14:11 --- Sorry for the delay and I never expected that someone else will figure it out for me. It just that I got distracted doing other things and right now I'm on vacation. I don't have access to the machine where I could do the investigation. But I'll do that as soon as I get back. IIRC, I did find the code from facerec benchmark, which was getting optimized badly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24565
[Bug fortran/20839] do-loop with do-construct-name needs needs end do
--- Comment #4 from uttamp at us dot ibm dot com 2005-12-09 21:40 --- I did build and completed the regression test. The patch in comment #3 fixes this problem (when compiled with -pedantic option) but gfortran still fails to report this as an error with -std=f95 without -pedantic. I've created a new patch where I took the Steven's patch and added GFC_STD_F95 along with pedantic check. About the error message, how about, Construct name on END DO at %L does not match the Named DO construct, sounds? Below, I'm listing the patch for completeness. Can somebody look at it pease? Thansks, Uttam --- gcc_org/gcc/gcc/fortran/parse.c 2005-11-30 09:56:16.0 -0800 +++ gcc/gcc/fortran/parse.c 2005-12-09 13:33:32.0 -0800 @@ -23,6 +23,7 @@ Software Foundation, 51 Franklin Street, #include config.h #include system.h +#include flags.h #include setjmp.h #include gfortran.h #include match.h @@ -2057,6 +2058,10 @@ loop: break; case ST_IMPLIED_ENDDO: + if ((pedantic || GFC_STD_F95) gfc_current_block () != NULL) + gfc_error_now + (Construct name on END DO at %L does not match the Named DO construct, + gfc_current_block()-declared_at); break; default: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20839
[Bug fortran/25319] New: namelist error
$ cat test.f95 program test_namelist call test1 contains subroutine test1() real :: array(6) namelist /list/array read (*, nml=list) write (*, nml=list) end $ gfortran test.f95 $ ./a.out list array(1:5)=1.5 output $ LIST ARRAY= 1.50, 0.00, 2.5253750E-29, 1.4012985E-45, 1.5694543E-43,131089.0, / Shouldn't this set all the elements of array(1:6) to 1.5 value? $ gfortran -v gcc version 4.2.0 20051206 (experimental) -- Summary: namelist error Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25319
[Bug fortran/25321] New: array shape conformance error
$ cat program test integer ::a(2,2) real :: b(4,4) a=1 b=2.0 b = b + a end program test gfortran doesn't give a shapes not conformable error. There is a PR #19754 and fix for the similar problem when arrays are of the same type. In this particular case arrays are of different types. -- Summary: array shape conformance error Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25321
[Bug regression/25252] New: ICE on invalid code
Hi, Following invalid code (association stmt sint=sreal) causes an ICE. $ cat test.f90 MODULE gswap TYPE points REAL :: x, y END TYPE points INTERFACE swap MODULE PROCEDURE sreal, schar, sint = sreal END INTERFACE swap CONTAINS SUBROUTINE sreal(a,b) real, intent(inout) :: a,b real :: temp temp=a a=b b=temp END SUBROUTINE sreal END MODULE gswap program test_swap USE gswap integer :: i = 2, j=3 call swap(i,j) end program test_swap $ gfortran test.f90 In file test.f90:6 MODULE PROCEDURE sreal, schar, sint = sreal 1 Error: Syntax error in MODULE PROCEDURE statement at (1) test.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. gdb output (gdb) r Program received signal SIGSEGV, Segmentation fault. 0x1001c2d8 in show_locus (offset=0, loc=0x10773018) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/error.c:137 137 error_printf (In file %s:%d\n, f-filename, (gdb) bt #0 0x1001c2d8 in show_locus (offset=0, loc=0x10773018) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/error.c:137 #1 0x1001c4c4 in show_loci (l1=Variable l1 is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/error.c:270 #2 0x22000442 in ?? () #3 0x1001b9a4 in error_print (type=0x1054d4b4 Error:, format0=0x1054e254 Procedure '%s' in %s at %L is neither function nor subroutine, argp=Variable argp is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/error.c:381 #4 0x1001bd30 in gfc_error ( nocmsgid=0x1054e254 Procedure '%s' in %s at %L is neither function nor subroutine) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/error.c:595 #5 0x1001fd88 in check_interface0 (p=Variable p is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/interface.c:880 #6 0x10022134 in check_sym_interfaces (sym=0x10772bb8) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/interface.c:960 #7 0x1005ba50 in traverse_ns (st=0x10772b98, func=0x100220b0 check_sym_interfaces) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/symbol.c:2416 #8 0x10021c20 in gfc_check_interfaces (ns=0x107726c0) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/interface.c:1015 #9 0x28000422 in ?? () #10 0x10050af4 in gfc_resolve (ns=0x107726c0) ---Type return to continue, or q return to quit--- at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/resolve.c:5436 #11 0x24000482 in ?? () #12 0x10046aa4 in gfc_parse_file () at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/parse.c:2659 #13 0x10066c04 in gfc_be_parse_file (set_yydebug=Variable set_yydebug is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/f95-lang.c:286 #14 0x1034584c in toplev_main (argc=Variable argc is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/toplev.c:990 #15 0x10093900 in main (argc=Variable argc is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/main.c:35 (gdb) -- Summary: ICE on invalid code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
[Bug regression/24978] New: ICE in gfc_assign_data_value_range
Following code is causing the internal compiler error. $ cat test.f90 real:: a(5,5) data a/25*1.0/ data a(1,1), a(3,1), a(1,2), a(3,3) /2*1.0, 2*2.0/ data a(2:5,4) /4*1.0/ end $ gfortran test.f90 t38.f90:0: internal compiler error: in gfc_assign_data_value_range, at fortran/data.c:423 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. $ gfortran -v Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_trunk_anonsvn/trunk/configure --prefix=/opt/gcc-nightly/trunk-20051117 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/trunk-20051117/bin/as --with-ld=/opt/gcc-nightly/trunk-20051117/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,java,objc,obj-c++ --enable-checking --with-mpfr=/opt/gcc-nightly/trunk-20051117 Thread model: posix gcc version 4.1.0 20051117 (experimental) -- Summary: ICE in gfc_assign_data_value_range Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
[Bug fortran/24936] New: Internal error
Following code causing the ice in fortran/trans.c at line 152 $ cat test_forall.f90 program test_forall type element character(32), pointer :: name end type element type(element) :: charts(50) character(32), target :: names(50) forall(i=1:50) charts(i)%name = names(i) end forall end $ gfortran -v test_forall.f90 Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_trunk_anonsvn/trunk/configure --prefix=/opt/gcc-nightly/trunk-20051117 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/trunk-20051117/bin/as --with-ld=/opt/gcc-nightly/trunk-20051117/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,java,objc,obj-c++ --enable-checking --with-mpfr=/opt/gcc-nightly/trunk-20051117 Thread model: posix gcc version 4.1.0 20051117 (experimental) /home/gcc-nightly/trunk-20051117/bin/../libexec/gcc/powerpc64-linux/4.1.0/f951 forall.f90 -quiet -dumpbase forall.f90 -auxbase forall -version -o /tmp/ccFvW4R8.s GNU F95 version 4.1.0 20051117 (experimental) (powerpc64-linux) compiled by GNU C version 4.1.0 20051117 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 forall.f90: In function MAIN__: forall.f90:1: internal compiler error: in gfc_add_modify_expr, at fortran/trans.c:152 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: Internal error Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24936
[Bug fortran/24886] another runtime error goes undetected
--- Comment #2 from uttamp at us dot ibm dot com 2005-11-16 17:33 --- Any error which indicates something like, dummy argument defined to be larger than actual argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24886
[Bug fortran/24878] New: subroutine getting called illegally as a function
This test is taken from, http://ftp.cac.psu.edu/pub/ger/fortran/test/test10.for $ cat test.f90 INTEGER X, Y, SUBA EXTERNAL SUBA X=-1 Y=-2 CALL ANY(SUBA,X,Y) WRITE(*,*)'Did NOT catch this error' PAUSE STOP END SUBROUTINE ANY(FNC,X,Y) INTEGER Y,X, FNC !---FNC is not a Function subprogram so calling it ! as a function is an error. Y=FNC(X) RETURN END SUBROUTINE SUBA(X) INTEGER X X=12345 RETURN END $ gfrotran test.f90 $ ./a.out in suba Did NOT catch this error PAUSE To resume execution, type go. Other input will terminate the job. go RESUMED In this test case, a subroutine SUBA is getting called as a function which should have been caught at runtime. -- Summary: subroutine getting called illegally as a function Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24878
[Bug fortran/24884] New: compiles invalid-code
This test is taken from http://ftp.cac.psu.edu/pub/ger/fortran/test/ $ cat test.f90 MODULE all_sub PRIVATE PUBLIC :: test1,test2 CONTAINS SUBROUTINE test1(a,n) IMPLICIT NONE INTEGER,INTENT(in) :: n REAL,INTENT(out), DIMENSION(n) :: a REAL :: b WRITE(*,*) 'Problem with intent(out) checkable at compile time' !---Elements of array, a, have not yet been defined within Subroutine ! test1. The following line violates Fortran 90 Standard 5.1.2.3 ! Intent Attribute. b=a(2) WRITE(*,*) b a(:)=4. END SUBROUTINE test1 SUBROUTINE test2(a,n,code) IMPLICIT NONE INTEGER,INTENT(in) :: n REAL, INTENT(out), DIMENSION(n) :: a LOGICAL, INTENT(in) :: code REAL :: b IF (code) THEN WRITE(*,*) 'Problem with intent(out) checkable at run time' !---Elements of array, a, have not yet been defined within Subroutine ! test1. The following line violates Fortran 90 Standard 5.1.2.3 ! Intent Attribute. b=a(2) WRITE(*,*) b END IF a(:)=4. END SUBROUTINE test2 END MODULE all_sub PROGRAM tintent2 USE all_sub, ONLY : test1, test2 IMPLICIT NONE INTEGER, PARAMETER :: n=7 REAL, DIMENSION(n) :: a a(:)=10. CALL test1(a,n) CALL test2(a,n,.TRUE.) pause END PROGRAM tintent2 $ gfortran test.f90 $ ./a.out Problem with intent(out) checkable at compile time 10.0 Problem with intent(out) checkable at run time 4.00 PAUSE To resume execution, type go. Other input will terminate the job. go RESUMED This should have given following error (compile time) The variable (a(2)) has an undefined value. -- Summary: compiles invalid-code Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24884
[Bug fortran/24885] New: fails to report runtime error
Following code fails to report the runtime error. The program goes into infinite loop. $ cat test.f90 program modify_by_include implicit none integer i do i = 1, 10 call dangerous_inclusion write(*,'(a,i0)') ' i = ', i end do contains subroutine dangerous_inclusion i = i+2 end subroutine dangerous_inclusion end program modify_by_include $ gfortran test.f90 $ ./a.out i = 3 i = 6 i = 9 i = 12 i = 15 i = 18 i = 21 i = 24 i = 27 i = 30 i = 33 i = 36 i = 39 i = 42 i = 45 i = 48 i = 51 i = 54 i = 57 i = 60 ... Infinite loop -- Summary: fails to report runtime error Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24885
[Bug fortran/24886] New: another runtime error goes undetected
Following code should print the runtime error, shouldn't it? This test is taken from http://ftp.cac.psu.edu/pub/ger/fortran/test $ cat test.f90 subroutine foo(y) character(len=20) :: y y = 'hello world' end program test character(len=10) :: x call foo(x) write(*,*) 'X=',x pause end $ gfortran test.f90 $./a.out X=hello worl PAUSE To resume execution, type go. Other input will terminate the job. go RESUMED -- Summary: another runtime error goes undetected Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24886
[Bug fortran/24866] New: internal compiler error
Following program cause internal compiler error. I wasn't sure if this has been seen/filed before. $ cat test_module.f90 module test_module contains subroutine sub_module(str) external :: str end subroutine sub_module subroutine str() end subroutine str end module test_module $ gfortran -v -c test_module.f90 test_module.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_trunk_anonsvn/trunk/configure --prefix=/opt/gcc-nightly/trunk-20051110 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/trunk-20051110/bin/as --with-ld=/opt/gcc-nightly/trunk-20051110/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,java,objc,obj-c++ --enable-checking --with-mpfr=/opt/gcc-nightly/trunk-20051110 Thread model: posix gcc version 4.1.0 20051110 (experimental) /home/gcc-nightly/trunk-20051110/bin/../libexec/gcc/powerpc64-linux/4.1.0/f951 test_module.f90 -quiet -dumpbase test_module.f90 -auxbase test_module -version -o /tmp/ccUJBiuf.s GNU F95 version 4.1.0 20051110 (experimental) (powerpc64-linux) compiled by GNU C version 4.1.0 20051110 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 backtrace is 142 if (sym-result-ts.type == BT_UNKNOWN) (gdb) p sym $1 = (gfc_symbol *) 0x1075be20 (gdb) p sym-result $2 = (struct gfc_symbol *) 0x0 (gdb) bt #0 resolve_formal_arglist (proc=0x1075bda0) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/resolve.c:142 #1 0x10059c70 in traverse_ns (st=0x107408b0, func=0x1004a310 find_arglists) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/symbol.c:2416 #2 0x1004f008 in gfc_resolve (ns=0x1075b670) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/resolve.c:267 #3 0x24000482 in ?? () #4 0x10045244 in gfc_parse_file () at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/parse.c:2664 #5 0x10064e04 in gfc_be_parse_file (set_yydebug=Variable set_yydebug is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/f95-lang.c:286 #6 0x10340a5c in toplev_main (argc=Variable argc is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/toplev.c:990 #7 0x10092540 in main (argc=Variable argc is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/main.c:35 -- Summary: internal compiler error Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24866
[Bug fortran/24806] New: accepts invalid DO construct code
Mainline gfortran accepts following invalid code. $ cat do_test.f90 program test_do j = 0 loop: do 100 i = 1, 2 j = j + 1 100 continue end program test_do $ gfortran do_test.f90 $ gfortran -v Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_trunk_anonsvn/trunk/configure --prefix=/opt/gcc-nightly/trunk-20051110 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/trunk-20051110/bin/as --with-ld=/opt/gcc-nightly/trunk-20051110/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,java,objc,obj-c++ --enable-checking --with-mpfr=/opt/gcc-nightly/trunk-20051110 Thread model: posix gcc version 4.1.0 20051110 (experimental) -- Summary: accepts invalid DO construct code Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powepc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24806
[Bug fortran/24640] New: ice with invalid label
$ cat test.f90 10: a=10 end $ gfortran test.f90 In file ice.f90:1 20:a=10 1 Warning: Ignoring bad statement label at (1) ice.f90: In function MAIN__: ice.f90:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. $ gfortran -v Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_trunk_anonsvn/trunk/configure --prefix=/opt/gcc-nightly/trunk-20051101 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/trunk-20051101/bin/as --with-ld=/opt/gcc-nightly/trunk-20051101/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95 --enable-checking --with-mpfr=/opt/gcc-nightly/trunk-20051101 Thread model: posix gcc version 4.1.0 20051101 (experimental) stack trace shows, Program received signal SIGSEGV, Segmentation fault. 0x1006fe18 in gfc_set_decl_location (decl=0x40298700, loc=0x1072fb44) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/trans-decl.c:226 226 DECL_SOURCE_LINE (decl) = loc-lb-linenum; (gdb) bt #0 0x1006fe18 in gfc_set_decl_location (decl=0x40298700, loc=0x1072fb44) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/trans-decl.c:226 #1 0x10071870 in gfc_get_label_decl (lp=0x1072fb30) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/trans-decl.c:256 #2 0x1008a188 in gfc_trans_label_here (code=Variable code is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/trans-stmt.c:78 #3 0x1006360c in gfc_trans_code (code=0x1074aa18) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/trans.c:482 #4 0x1007527c in gfc_generate_function_code (ns=0x1074a120) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/trans-decl.c:2594 #5 0x22000482 in ?? () #6 0x10062cd4 in gfc_generate_code (ns=Variable ns is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/trans.c:659 #7 0x100432c8 in gfc_parse_file () at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/parse.c:2680 #8 0x100624b4 in gfc_be_parse_file (set_yydebug=Variable set_yydebug is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/f95-lang.c:286 #9 0x10336d6c in toplev_main (argc=Variable argc is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/toplev.c:990 #10 0x1008e860 in main (argc=Variable argc is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/main.c:35 -- Summary: ice with invalid label Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24640
[Bug fortran/24641] New: rejecting valid code
$ cat test_cmt.f90 program test_comments real :: a end program test_comments $ This is a valid code (i think) checked against Lahey's syntax checker, getting rejected by gfortran. $ gfortran test_cmt.f90 In file test_cmt.f90:2 real :: 1 Error: Syntax error in data declaration at (1) In file test_cmt.f90:4 a 1 Error: Unclassifiable statement at (1) $ gfortran -v is gcc version 4.1.0 20051101 (experimental) -- Summary: rejecting valid code Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24641
[Bug fortran/24646] New: accepting invalid label
$ cat tst.f program test 19 real :: a=5 end program test $ gfortran tst.f In file ice.f90:2 19 a=5 1 Warning: Ignoring bad statement label at (1) I think the compiler should give hard error with error message something like label must be less than or equal to five digits, or Statement label contains more than 5 digits.. -- Summary: accepting invalid label Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24646
[Bug regression/24565] New: facerec performance regression
There has been a performance drop of approx. 8% in facerec benchmark with at -O2 optimizatio level, since 2005-10-17 on ppc. After doing little regression hunt, found following patch causing the drop, http://gcc.gnu.org/ml/gcc-cvs/2005-10/msg00586.html As this patch has two parts, one fixes bug #23714 and other removes the call to mark_array_ref_addressable() and related definitions. As you can tell these two set of changes does two different things. First one fixes pr #23714. I have verified that, the second set of changes causing the performance drop. After reverting only the second part from the above patch and running facerec benchmark at -O2, I could recover the old better numbers (~+8%). Any thoughts on this? I could revert the change (only second part) with the new patch unless there is a reason (which for the moment I'm not able to understand) for removing the call to mark_array_ref_addressable(). -- Summary: facerec performance regression Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24565
[Bug fortran/24447] New: dimag_ undefined error with -std=f95
Following program fails to link with -std=f95 option, even though dimag() is supported intrinsic function. It compiles, links fine without -std or with -std=gnu option. $ cat dimag.f90 program test_dimag complex(8) c8 real*8 result c8 = cmplx(1.e0_8, 0.e0_8) print *, dimag(c8) end program test_dimag $ gfortran -std=f95 dimag.f90 /tmp/cc0aHEPk.o: In function `MAIN__': dimag.f90:(.text+0x74): undefined reference to `dimag_' collect2: ld returned 1 exit status $ gfortran -v Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_mline_anoncvs/gcc/configure --prefix=/opt/gcc-nightly/mline-20051018 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/mline-20051018/bin/as --with-ld=/opt/gcc-nightly/mline-20051018/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,java,objc,obj-c++ --enable-checking --with-mpfr=/opt/gcc-nightly/mline-20051018 Thread model: posix gcc version 4.1.0 20051018 (experimental) -- Summary: dimag_ undefined error with -std=f95 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24447
[Bug fortran/24447] dimag_ undefined error with -std=f95
--- Comment #2 from uttamp at us dot ibm dot com 2005-10-19 22:25 --- (In reply to comment #1) dimag is part of the fortran 95 standard, right? If not this is not a bug (or really a dup another one which says that gfortran is not constainate with other fortran compilers with intrinsics). Yes, dimag is part of fortran95. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24447
[Bug fortran/24447] dimag_ undefined error with -std=f95
--- Comment #7 from uttamp at us dot ibm dot com 2005-10-20 01:10 --- Finally I found the f95 standard document (1539-1-1997) and did not see dimag() mentioned in there. I was looking at PGI Fortran Reference document all this time and there was not comment about dimag() as an extension. my apologies for causing all the extra work to cross-verify it. I was just too quick to send patch to gcc-patches mailing list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24447
[Bug fortran/24336] New: fortran variable name exceeds the maximum limit per standard
As per the standard for fortran 95, the maximum length of a variable is 31 characters. But gfortran doesn't truncate, complain or warn (is it platform dependent?) when that is not true like in following case, $ cat test.f90 program test_name integer abcdefghijklmnopqrstuvwxyz123456 abcdefghijklmnopqrstuvwxyz123456 = 10 print *, abcdefghijklmnopqrstuvwxyz123456 print *, abcdefghijklmnopqrstuvwxyz12345 end program $ gfortran test.f90 $ ./a.out 10 2.5261893E-29 $ gfortran -v Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_mline_anoncvs/gcc/configure --prefix=/opt/gcc-nightly/mline-20051011 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/mline-20051011/bin/as --with-ld=/opt/gcc-nightly/mline-20051011/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,java,objc,obj-c++ --enable-checking --with-mpfr=/opt/gcc-nightly/mline-20051011 Thread model: posix gcc version 4.1.0 20051010 (experimental) -- Summary: fortran variable name exceeds the maximum limit per standard Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64_linux GCC host triplet: powerpc64_linux GCC target triplet: powerpc64_linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24336
[Bug fortran/24337] New: Syntax error in data declaration
$ cat vartest.f90 program test_name integer _var end program $ gfortran -c vartest.f90 In file names.f90:2 integer _var 1 Error: Syntax error in data declaration at (1) as per the standard, R301 character is alphanumeric character or special character R302 alphanumeric character is letter or digit or inderscore $ gfortran -v Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_mline_anoncvs/gcc/configure --prefix=/opt/gcc-nightly/mline-20051011 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/mline-20051011/bin/as --with-ld=/opt/gcc-nightly/mline-20051011/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,java,objc,obj-c++ --enable-checking --with-mpfr=/opt/gcc-nightly/mline-20051011 Thread model: posix gcc version 4.1.0 20051010 (experimental) -- Summary: Syntax error in data declaration Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64_linux GCC host triplet: powerpc64_linux GCC target triplet: powerpc64_linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24337
[Bug fortran/24110] INTERVAL: Error: Unclassifiable statement
--- Additional Comments From uttamp at us dot ibm dot com 2005-09-29 16:24 --- My apologies if INTERVAL is not a reserved keyword as part of fortran 95 standard? I thought it is part of the standard, or is it an extension to it? Please close it appropriately if this is invalid. Sorry for the inconvenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24110
[Bug fortran/24110] New: INTERVAL: Error: Unclassifiable statement
$ cat test.f95 INTERVAL(4):: X = [2,3] END $ gfortran -c test.f95 In file 2.f95:1 INTERVAL(4):: X = [2,3] 1 Error: Unclassifiable statement at (1) $ gfortran -v Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_mline_anoncvs/gcc/configure --prefix=/opt/gcc-nightly/mline-20050922 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/mline-20050922/bin/as --with-ld=/opt/gcc-nightly/mline-20050922/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,java,objc,obj-c++ --enable-checking --with-mpfr=/opt/gcc-nightly/mline-20050922 Thread model: posix gcc version 4.1.0 20050922 (experimental) -- Summary: INTERVAL: Error: Unclassifiable statement Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24110
[Bug middle-end/23785] 197.parser performance drop
-- What|Removed |Added CC||uttamp at us dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23785
[Bug middle-end/23785] 197.parser performance drop
--- Additional Comments From uttamp at us dot ibm dot com 2005-09-21 01:13 --- With the latest (05-19-2005) mainline cvs tree, following are the benchmark numbers with and without ipa-inline patch (http://gcc.gnu.org/ml/gcc-cvs/2005-07/msg01016.html) compiled with flags -O3 -m32 -mcpu=power4 -ffast-math -fpeel-loops -ftree-loop-linear -funroll-loops Benchmark with_patch without_patch 164.gzip 401.82 404.29 175.vpr513.52 514.93 176.gcc677.31 682.95 181.mcf733.14 735.16 186.crafty 492.28 493.37 197.parser 423.06 430.35 252.eon529.79 536.55 253.perlbmk361.01 365.51 254.gap455.51 459.00 255.vortex 625.22 611.80 256.bzip2 536.58 535.21 300.wolf 709.13 709.86 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23785
[Bug rtl-optimization/23785] New: 197.parser performance drop
-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23785
[Bug fortran/23661] New: 'print fmt' is unclassifiable statement in gfortran
test case: $ cat print_fmt.f95 PROGRAM print_fmt_test IMPLICIT NONE character(len=5) :: fmt = ( a) integer:: i print fmt, (=, i=1, 2) END PROGRAM print_fmt_test $ gfortran -c print_fmt.f95 In file print_fmt.f95:5 print fmt, (=, i=1, 2) 1 Error: Unclassifiable statement at (1) $ gfortran -v Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_mline_anoncvs/gcc/configure --prefix=/opt/gcc-nightly/mline-20050823 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/mline-20050823/bin/as --with-ld=/opt/gcc-nightly/mline-20050823/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,java,objc,obj-c++ --enable-checking --with-mpfr=/opt/gcc-nightly/mline-20050823 Thread model: posix gcc version 4.1.0 20050823 (experimental) print fmt statement is part of fortran 95 standard. -- Summary: 'print fmt' is unclassifiable statement in gfortran Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23661
[Bug tree-optimization/23234] New: ICE in verify_flow_info()
Following test program causes an internal compiler error,
$ cat y.c
double func ( double a, double b, double c)
{
double x0, x1, y0, y1;
int type = 0;
double ar;
if(b==0.0){
x0 = -c/a;
return( x0 1.0? 1.0 : ( x0 0.0 ? 0.0: x0));
}
if(a==0.0) {
y0 = -c/b;
return( y0 1.0? 1.0 : ( y0 0.0 ? 0.0: y0));
}
x0 = -c/a;
y0 = -c/b;
type = ((y0=1.0)(y1=1.0) ? 16 : type);
switch(type){
case 3: ar = (0.5*(y0+y1)); break;
}
return ar;
}
$ /opt/mline-20050802/bin/gcc -c -ffast-math -O2 y.c
$ y.c: In function âfuncâ:
y.c:2: error: control flow in the middle of basic block 0
y.c:2: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
This test case works with gcc_cvs code till 20050801. This is also a reason to
fail eon benchmark.
--
Summary: ICE in verify_flow_info()
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uttamp at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23234
[Bug tree-optimization/23234] [4.1 Regression] ICE in verify_flow_info()
--- Additional Comments From uttamp at us dot ibm dot com 2005-08-04 17:57
---
(In reply to comment #1)
Confirmed, reduced testcase:
double func ( double a, double b, double c)
{
double y0;
if(a==0.0) {
y0 = -c/b;
return y0;
}
y0 = -c/b;
return y0;
}
nice. ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23234
[Bug fortran/19754] Shape conformance not checked
--- Additional Comments From uttamp at us dot ibm dot com 2005-08-02 17:20 --- (In reply to comment #7) Fixed. Shouldn't the following test fail too with the shape conformance error message? program test integer ::a(2,2) real :: b(4,4) a=1 b=2.0 b = b + a end program test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19754
[Bug fortran/23209] New: array shape conformance not checked
Compiler doesn't produce valid error message for the following test case, where two arrays are not comformable. program test integer ::a(2,2) real :: b(4,4) a=1 b=2.0 b = b + a end program test There is a PR #19754 and a patch in this regard but the patch emits the correct error message only when both arrays are of same type but with different shapes but not in the above case. -- Summary: array shape conformance not checked Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23209
[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name
--- Additional Comments From uttamp at us dot ibm dot com 2005-07-29 18:16
---
I belive, till g++ 3.3.4, the mangled string used have that '_' as hown by
following example,
templateclass T struct S {
S(int i=0);
};
templateSint s void f13();
extern Sint s13;
int main(void)
{
f13s13();
return 0;
}
With nm, I get
U __gxx_personality_v0
T main
U _Z3f13IXL_Z3s13EEEvv
Which I believe is the default and correct behavior. But with g++ 3.4 (which
doesn't support abi-version=3) by default produces mangled string as
U __gxx_personality_v0
T main
U _Z3f13ILZ3s13EEvv
And with g++ 3.5.x user has to specify -fabi-version=3 as specified by Mark,
to get the correct string.
So there is a binary compatibility problem between object code created by older
g++ version 3.3.4 and later version till g++ version 3.5.
Do you see my dilemma? Or am I still missing something very basic here?
Sorry for any/all repetition over this subject. I would really appreciate the
reply for better understanding and clarification of this issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16240
[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name
--- Additional Comments From uttamp at us dot ibm dot com 2005-07-28 18:10 --- (In reply to comment #15) In comment #7 Giovanni was saying that the compiler was generating the wrong string. The correct string is the one in the quote from the C++ ABI. The compiler has now been fixed the generate the correct string. The demangler only handles the correct string. Does this means C++ ABI always (previous versions 1 and 2) had that '_'Z for the template name mangling? If it is true, then how does adding '_' would cause an ABI change, as you said in comment #5? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16240
[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name
--- Additional Comments From uttamp at us dot ibm dot com 2005-07-27 22:48 --- (In reply to comment #7) Agreed. This is quoted by the C++ ABI: void foo(char); // mangled as _Z3fooc templatevoid ()(char) struct CB; // CBfoo is mangled as 2CBIL_Z3foocEE Given this: void foo(CBfoo*); we generate: T _Z3fooP2CBILZ3foocEE but c++filt _Z3fooP2CBILZ3foocEE, just returns the same string. But if I add '_' as _Z3fooP2CBIL_Z3foocEE and then do c++filt on that string, returns foo(CBfoo(char)*) as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16240
[Bug tree-optimization/22504] [4.1 Regression] benchmark - galgel fails at runtime with miscompare output
--- Additional Comments From uttamp at us dot ibm dot com 2005-07-26 17:27 --- Steven's patch has fixed the galgel failure. I've verified it on Powerpc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22504
[Bug tree-optimization/22560] New: internal compiler error: in create_tmp_var, at gimplify.c:368 c++ testcase
Test case:
$ cat test.cc
class ggF3 {
public:
ggF3() {}
};
class ggHM3 {
public:
ggHM3();
ggHM3(const ggHM3 m);
double e[4][4];
};
inline ggHM3 makeCRHM(void)
{
ggHM3 r;
return r;
}
const ggHM3 crm(makeCRHM());
ggF3 ggFI(const ggF3 keyframe[])
{
return keyframe[1];
}
$ /opt/gcc-nightly/mline-20050717/bin/g++ -c -O3 test.cc
test.cc: In function #8216;void __static_initialization_and_destruction_0(int,
int)#8217;:
test.cc:23: internal compiler error: in create_tmp_var, at gimplify.c:368
$ /opt/gcc-nightly/mline-20050717/bin/g++ -v
Target: powerpc64-linux
Configured with: /home/gccbuild/gcc_mline_anoncvs/gcc/configure
--prefix=/opt/gcc-nightly/mline-20050719 --build=powerpc64-linux
--host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32
--with-as=/opt/gcc-nightly/mline-20050719/bin/as
--with-ld=/opt/gcc-nightly/mline-20050719/bin/ld --enable-threads=posix
--enable-shared --enable-__cxa_atexit
--enable-languages=c,c++,f95,java,objc,obj-c++ --enable-checking
--with-mpfr=/opt/gcc-nightly/mline-20050719
Thread model: posix
gcc version 4.1.0 20050719 (experimental)
--
Summary: internal compiler error: in create_tmp_var, at
gimplify.c:368 c++ testcase
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uttamp at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22560
[Bug c/22504] New: benchmark - galgel fails at runtime with miscompare output
With the recent change went in tree-complex.c causing the galgel's runtime failure with miscompare output. http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00767.html -- Summary: benchmark - galgel fails at runtime with miscompare output Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org,uttamp at us dot ibm dot com GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22504
[Bug c/21774] mainline internal compiler error: verify_flow_info failed
--- Additional Comments From uttamp at us dot ibm dot com 2005-06-02 17:46 --- This bug seems to be fixed with the mainline gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21774
[Bug target/21761] [4.1 Regression] mainline gcc causing internal compiler error.
--- Additional Comments From uttamp at us dot ibm dot com 2005-06-01 23:31 --- I've verified that this bug has been fixed in mainline gcc. -- What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21761
[Bug target/21761] [4.1 Regression] mainline gcc causing internal compiler error.
--- Additional Comments From uttamp at us dot ibm dot com 2005-05-26 18:23
---
(In reply to comment #0)
test case:
$ cat bug1.c
void f1()
{
long bit=0, exponent;
exponent = -exponent;
for (bit = 1; exponent; bit = 1)
if (exponent bit)
exponent ^= bit;
}
# Compilation parameters
$ gcc -c -O3 -m64 bug1,c
gcc gives internal compiler error on Powerpc platform.
bug1.c: In function #8216;f1#8217;:
bug1.c:8: error: could not split insn
(insn:TI 13 11 14 (parallel [
(set (reg:CC 75 7 [125])
(compare:CC (neg:DI (reg/v:DI 0 0 [orig:119 exponent ] [119]))
(const_int 0 [0x0])))
(set (reg/v:DI 0 0 [orig:118 exponent.1 ] [118])
(neg:DI (reg/v:DI 0 0 [orig:119 exponent ] [119])))
]) 76 {*rs6000.md:1653} (nil)
(nil))
bug1.c:8: internal compiler error: in final_scan_insn, at final.c:2419
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Compiler works with all other optimization flags.
I didn't mean to mislead anybody with my earlier comment. But actually compiler
fails with all optimization flags (-O2 and above). And a test case also has one
change to make it more generic type. In the original test case 'exponent' was
just a local and unitialized variable.
void f1(long exponent)
{
long bit=0;
exponent = -exponent;
for (bit = 1; exponent; bit = 1)
if (exponent bit)
exponent ^= bit;
}
After doing reghunt I found a patch, which may not necessarily have caused the
above failure but compiler started failing after application of this patch,
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00232.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21761
[Bug c/21774] New: mainline internal compiler error: verify_flow_info failed
GCC mainline gets an internal compiler error compiling following minimized code
with either -O2 -m32 or -O2 -m64.
struct estruct
{
int co;
int or;
char ma;
};
void f1 (int pos1, int pos2, struct estruct *ed)
{
int k;
for (k = 0; k == 0; k++)
if (ed[pos2].co == ed[pos1].co (!ed[pos2].ma || !ed[pos1].ma))
f1 (pos2, 0, ed);
}
$ /opt/gcc-nightly/mline-20050525/bin/gcc -O2 -c bug.c
-- OR --
$ /opt/gcc-nightly/mline-20050525/bin/gcc -O2 -m64 -c bug.
bug.c: In function #8216;f1#8217;:
bug.c:15: error: Wrong amount of branch edges after unconditional jump 0
bug.c:15: error: verify_flow_info: Incorrect blocks for fallthru 0-6
bug.c:15: internal compiler error: verify_flow_info failed
The failures start with this patch from dnovillo:
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00529.html
--
Summary: mainline internal compiler error: verify_flow_info
failed
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uttamp at us dot ibm dot com
CC: dnovillo at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
dot org
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21774
[Bug c/21761] New: mainline gcc causing internal compiler error.
test case:
$ cat bug1.c
void f1()
{
long bit=0, exponent;
exponent = -exponent;
for (bit = 1; exponent; bit = 1)
if (exponent bit)
exponent ^= bit;
}
# Compilation parameters
$ gcc -c -O3 -m64 bug1,c
gcc gives internal compiler error on Powerpc platform.
bug1.c: In function #8216;f1#8217;:
bug1.c:8: error: could not split insn
(insn:TI 13 11 14 (parallel [
(set (reg:CC 75 7 [125])
(compare:CC (neg:DI (reg/v:DI 0 0 [orig:119 exponent ] [119]))
(const_int 0 [0x0])))
(set (reg/v:DI 0 0 [orig:118 exponent.1 ] [118])
(neg:DI (reg/v:DI 0 0 [orig:119 exponent ] [119])))
]) 76 {*rs6000.md:1653} (nil)
(nil))
bug1.c:8: internal compiler error: in final_scan_insn, at final.c:2419
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Compiler works with all other optimization flags.
After doing reghunt I found a patch, which may not necessarily have caused the
above failure but compiler started failing after application of this patch,
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00232.html
--
Summary: mainline gcc causing internal compiler error.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uttamp at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org,geoffk at gcc dot gnu
dot org,uttamp at us dot ibm dot com
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21761
