[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #116 from jv244 at cam dot ac dot uk 2007-06-22 05:56 --- There is currently a new ICE [EMAIL PROTECTED]:/scratch/vondele/gcc_test/gfortran/test/src> gfortran -Os all.f90 all.f90: In function ‘compute_screening_matrices’: all.f90:305498: internal compiler error: in build2_stat, at tree.c:3074 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED]:/scratch/vondele/gcc_test/gfortran/test/src> gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /scratch/vondele/gcc_trunk/gcc/configure --prefix=/scratch/vondele/gcc_trunk/build --with-mpfr_include=/scratch/vondele/mpfr-2.2.0/ --with-mpfr_lib=/scratch/vondele/mpfr-2.2.0/ --with-gmp=/users/vondele/ --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070620 (experimental) but the compiler is now two days old, so I'll check if it is reproducable by something more recent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/32406] [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3
--- Comment #4 from daney at gcc dot gnu dot org 2007-06-22 04:55 --- Fixed by this patch: http://gcc.gnu.org/viewcvs?view=rev&revision=125941 Unfortunately I botched the PR number in the ChangeLog with my first commit, so the magic patch description did not show up here. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32406
[Bug fortran/32046] [4.3 Regression] wrong code with -O2 for gfortran.dg/interface_12.f90 & result_in_spec_1.f90
--- Comment #11 from daney at gcc dot gnu dot org 2007-06-22 04:46 --- Subject: Bug 32046 Author: daney Date: Fri Jun 22 04:46:08 2007 New Revision: 125941 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125941 Log: PR target/32046 * config/mips/mips.md (define_constants): Rename UNSPEC_EH_RECEIVER to UNSPEC_NONLOCAL_GOTO_RECEIVER globally. (exception_receiver): Renamed to ... (nonlocal_goto_receiver): ... this. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32046
[Bug libfortran/31726] minloc/maxloc: wrong results with empty array (F2003 only)
--- Comment #8 from patchapp at dberlin dot org 2007-06-22 02:05 --- Subject: Bug number PR31726 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01583.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31726
[Bug fortran/31162] missing warning for real do-loops with implicit typed variables
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-06-22 02:01 --- Fixed on trunk. closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31162
[Bug fortran/31162] missing warning for real do-loops with implicit typed variables
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-06-22 01:54 --- Subject: Bug 31162 Author: jvdelisle Date: Fri Jun 22 01:54:27 2007 New Revision: 125939 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125939 Log: 2007-06-21 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/31162 * gfortran.dg/assign.f90: Update test. * gfortran.dg/real_do_1.f90: Update test. * gfortran.dg/gomp/omp_do1.f90: Update test. * gfortran.dg/warnings_are_errors_1.f: Update test. * gfortran.dg/g77/20010519-1.f: Update test. * gfortran.dg/g77/pr9258.f: Update test. * gfortran.dg/g77/960317-1.f: Update test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/assign.f90 trunk/gcc/testsuite/gfortran.dg/g77/20010519-1.f trunk/gcc/testsuite/gfortran.dg/g77/960317-1.f trunk/gcc/testsuite/gfortran.dg/g77/pr9258.f trunk/gcc/testsuite/gfortran.dg/gomp/omp_do1.f90 trunk/gcc/testsuite/gfortran.dg/real_do_1.f90 trunk/gcc/testsuite/gfortran.dg/warnings_are_errors_1.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31162
[Bug fortran/31162] missing warning for real do-loops with implicit typed variables
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-06-22 01:50 --- Subject: Bug 31162 Author: jvdelisle Date: Fri Jun 22 01:50:09 2007 New Revision: 125938 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125938 Log: 2007-06-21 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/31162 * resolve.c (gfc_resolve_iterator_expr): Add check for REAL using gfc_notify_standard. (gfc_resolve_iterator): Remove check. (resolve_branch): Change "Obsolete" to "Deleted feature". * io.c (resolve_tag): Ditto. * match.c (gfc_match_pause, gfc_match_assign, gfc_match_goto): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31162
[Bug middle-end/32417] [4.3 Regression] 416.gamess ICEs
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-22 00:36 ---
Here is the patch which fixes this testcase (note IV-OPTS is still messed up
but I will work on that later):
Index: tree-affine.c
===
--- tree-affine.c (revision 125927)
+++ tree-affine.c (working copy)
@@ -130,6 +130,7 @@
aff_combination_add_elt (aff_tree *comb, tree elt, double_int scale)
{
unsigned i;
+ tree type;
scale = double_int_ext_for_comb (scale, comb);
if (double_int_zero_p (scale))
@@ -169,17 +170,26 @@
return;
}
+ type = comb->type;
+ if (POINTER_TYPE_P (type))
+type = sizetype;
+
if (double_int_one_p (scale))
-elt = fold_convert (comb->type, elt);
+elt = fold_convert (type, elt);
else
-elt = fold_build2 (MULT_EXPR, comb->type,
- fold_convert (comb->type, elt),
- double_int_to_tree (comb->type, scale));
+elt = fold_build2 (MULT_EXPR, type,
+ fold_convert (type, elt),
+ double_int_to_tree (type, scale));
if (comb->rest)
-comb->rest = fold_build2 (PLUS_EXPR, comb->type, comb->rest, elt);
+{
+ if (!POINTER_TYPE_P (comb->type))
+ comb->rest = fold_build2 (PLUS_EXPR, comb->type, comb->rest, elt);
+ else
+ comb->rest = fold_build2 (POINTER_PLUS_EXPR, comb->type, comb->rest,
elt);
+}
else
-comb->rest = elt;
+comb->rest = fold_convert (comb->type, elt);
}
/* Adds CST to C. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32417
[Bug middle-end/32417] [4.3 Regression] 416.gamess ICEs
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-22 00:22 --- Reduced testcase: SUBROUTINE ONEINTS() COMMON /INFOA / NAT,NUM DIMENSION TINT(NUM*NUM,NAT,3,3,3),TINTM(NUM,NUM,NAT,3,3,3) CALL TINTS(IC) DO ID=1,3 DO IC=1,NAT TINTM(J,I,IC,IAN,INU,ID) = TINT((I-1)*NUM+J,IC,IAN,INU,ID) ENDDO ENDDO END -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-22 00:22:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32417
[Bug tree-optimization/32421] [4.3 Regression] -ftree-vectorize -msse2 ICEs in build2_stat when vectorizing POINTER_PLUS_EXPR
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-22 00:01 --- Patch which fixes the ICE: Index: tree-vect-transform.c === --- tree-vect-transform.c (revision 125927) +++ tree-vect-transform.c (working copy) @@ -2968,6 +2968,12 @@ operation = GIMPLE_STMT_OPERAND (stmt, 1); code = TREE_CODE (operation); + + /* For pointer addition, we should use the normal plus for + the vector addition. */ + if (code == POINTER_PLUS_EXPR) +code = PLUS_EXPR; + optab = optab_for_tree_code (code, vectype); /* Support only unary or binary operations. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32421
[Bug regression/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #2 from danglin at gcc dot gnu dot org 2007-06-21 23:49 --- The patch mentioned in PR 32296 fixes the return pointer breakage reported in comment #2. However, configure still fails at exactly the same point due to a segmentation fault in def_fn_type(): (gdb) ignor 5 156 Will ignore next 156 crossings of breakpoint 5. (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /test/gnu/gcc/objdir/gcc/cc1 -iprefix /test/gnu/gcc/objdir/gcc/../lib/gcc/hppa64-hp-hpux11.11/4.3.0/ -isystem ./include -isystem ./include-fixed xxx.c -dumpbase xxx.c -auxbase-strip xxx.s -version -o xxx.s Breakpoint 3 at 0xc000b310 Breakpoint 4 at 0x8001bbf0 Breakpoint 3 at 0x83fffef4f620 Breakpoint 4 at 0x83fffefa7a78 GNU C version 4.3.0 20070621 (experimental) (hppa64-hp-hpux11.11) compiled by GNU C version 4.3.0 20070621 (experimental), GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 options passed: -iprefix /test/gnu/gcc/objdir/gcc/../lib/gcc/hppa64-hp-hpux11.11/4.3.0/ -isystem ./include -isystem ./include-fixed xxx.c -auxbase-strip xxx.s options enabled: -fPIC -falign-loops -fargument-alias -fauto-inc-dec -fbranch-count-reg -fcommon -fearly-inlining -feliminate-unused-debug-types -femit-class-debug-always -ffunction-cse -fgcse-lm -fident -finline-functions-called-once -fivopts -fkeep-static-consts -fleading-underscore -fmath-errno -fmove-loop-invariants -fpeephole -freg-struct-return -fsched-interblock -fsched-spec -fsched-stalled-insns-dep -fshow-column -fsigned-zeros -fsplit-ivs-in-unroller -ftoplevel-reorder -ftrapping-math -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize -ftree-scev-cprop -ftree-vect-loop-version -fvar-tracking -fzero-initialized-in-bss -mbig-switch -mgas -mspace-regs Breakpoint 5, 0x40185a14 in def_fn_type ( def=BT_FN_INT_STRING_SIZE_INT_SIZE_CONST_STRING_VALIST_ARG, ret=BT_INT, var=0 '\0', n=6) at ../../gcc/gcc/c-common.c:3384 3384 t = builtin_types[a]; (gdb) p i $25 = 4 (gdb) p/x $ret0 $26 = 0x20 (gdb) p/x $r7 $27 = 0x800100058728 (gdb) c Continuing. Breakpoint 5, 0x40185a14 in def_fn_type ( def=BT_FN_INT_STRING_SIZE_INT_SIZE_CONST_STRING_VALIST_ARG, ret=BT_INT, var=0 '\0', n=6) at ../../gcc/gcc/c-common.c:3384 3384 t = builtin_types[a]; (gdb) p i $28 = 5 (gdb) p/x $ret0 $29 = 0xfeda2c60 (gdb) p/x $r7 $30 = 0x800100058728 (gdb) p/x $pc $31 = 0x40185a14 (gdb) disass 0x40185a04 0x40185a24 Dump of assembler code from 0x40185a04 to 0x40185a24: 0x40185a04 : ldo -30(sp),r5 0x40185a08 : ldd -c8(sp),r31 0x40185a0c : ldd 0(r6),r26 0x40185a10 : ldw 4(r31),ret0 0x40185a14 : ldd,s ret0(r7),r25 0x40185a18 : cmpb,*= r25,r26,0x40185a84 0x40185a1c : ldo 8(r31),r19 0x40185a20 : std r19,-c8(sp) End of assembler dump. (gdb) bt #0 0x40185a14 in def_fn_type ( def=BT_FN_INT_STRING_SIZE_INT_SIZE_CONST_STRING_VALIST_ARG, ret=BT_INT, var=0 '\0', n=6) at ../../gcc/gcc/c-common.c:3384 #1 0x4018c1a4 in c_common_nodes_and_builtins () at builtin-types.def:403 #2 0x4014dda4 in c_init_decl_processing () at ../../gcc/gcc/c-decl.c:2772 #3 0x401b2034 in c_objc_common_init () at ../../gcc/gcc/c-objc-common.c:128 #4 0x4046f264 in toplev_main (argc=, argv=) at ../../gcc/gcc/toplev.c:2037 #5 0x401d7af4 in main (argc=-19249376, argv=0x0) at ../../gcc/gcc/main.c:35 (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x40185a14 in def_fn_type ( def=BT_FN_INT_STRING_SIZE_INT_SIZE_CONST_STRING_VALIST_ARG, ret=BT_INT, var=0 '\0', n=6) at ../../gcc/gcc/c-common.c:3384 3384 t = builtin_types[a]; (gdb) p/x &builtin_types $32 = 0x800100058728 (gdb) p n $33 = 6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug tree-optimization/32378] can't determine dependence (distinct sections of an array)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-21 23:32:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32378
[Bug fortran/32376] can't determine dependence (array with variable initial index)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-21 23:26 --- After PR 32075 was fixed, this was also fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32376
[Bug target/32431] [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4066
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||build, ice-on-valid-code Summary|ICE in df_refs_verify, at |[4.3 Regression] ICE in |df-scan.c:4066 |df_refs_verify, at df- ||scan.c:4066 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32431
[Bug middle-end/32399] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-21 23:11 --- Mine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-06-19 08:26:50 |2007-06-21 23:11:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug regression/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||build Summary|checking for suffix of |[4.3 Regression] checking |object files... configure: |for suffix of object |error: cannot compute suffix|files... configure: error: |of f object files: cannot |cannot compute suffix of f |compile |object files: cannot compile Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug middle-end/32370] [4.3 Regression] Segfault after rejecting bogus assembler
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32370
[Bug target/32441] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:7109
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | Keywords||build, ice-on-valid-code Summary|ICE in expand_expr_real_1, |[4.3 Regression] ICE in |at expr.c:7109 |expand_expr_real_1, at ||expr.c:7109 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32441
[Bug target/32413] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32413
[Bug target/32337] [4.3 Regression] Error: Register number out of range 0..1
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32337
[Bug target/32338] [4.3 Regression] Error: .prologue within prologue
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32338
[Bug c++/32425] -O breaks executable (/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found)
--- Comment #3 from lionelb dot nospam at gmail dot com 2007-06-21 22:43 --- (In reply to comment #2) > (In reply to comment #1) > > BTW what are the implications for exceptions of linking with -static-libgcc? Ok, that was a RTFM, got it now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32425
[Bug bootstrap/32334] Bootstrap comparison failure when comparing stage 2 and 3
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-21 22:41 --- This issue has already been worked around in 4.3 (and IIRC 4.2.1.) so closing as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32334
[Bug middle-end/32370] [4.3 Regression] Segfault after rejecting bogus assembler
--- Comment #5 from sje at cup dot hp dot com 2007-06-21 22:38 --- The non-optimized infinite loop problem looks like some kind of memory corruption problem. At the end of bitmap_element_allocate I put a line "gcc_assert (element != head);" which should never trigger because head exists before the call and element is being newly allocated. But it does trigger with the test case and this winds up putting us into an infinite loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32370
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug fortran/32446] F0.n output format fails with large numbers
--- Comment #9 from John dot Harper at mcs dot vuw dot ac dot nz 2007-06-21 22:07 --- Subject: Re: F0.n output format fails with large numbers On Thu, 21 Jun 2007, burnus at gcc dot gnu dot org wrote: > Date: 21 Jun 2007 06:16:53 - > From: burnus at gcc dot gnu dot org <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: [Bug fortran/32446] F0.n output format fails with large numbers > > > > --- Comment #7 from burnus at gcc dot gnu dot org 2007-06-21 06:16 > --- >> Host triplet is: processor - platform - os >> So depending on your processor it would be something like, >> i686-pc-linux-gnu >> x86-64-unknown-linux > >> You can get this from the command uname >> Try uname -p -i -o > > Easier is of cause: gfortran -v > That prints (among other things): Target: x86_64-unknown-linux-gnu On my system gfortran -v and uname -p -i -o give these results: [EMAIL PROTECTED] test system: ~ 2 >gfortran -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.1 20070105 (Red Hat 4.1.1-52) [EMAIL PROTECTED] test system: ~ 3 >uname -p -i -o i686 i386 GNU/Linux [EMAIL PROTECTED] test system: ~ 4 > When I'm composing a gfortran bug report I'm asked for 3 different sorts of triplet: host, target and build. From the above and burnus's reply it seems that my host triplet might be one of these two: i386-redhat-linux (from gfortran -v saying --host=i386-redhat-linux) i686 i386 GNU/Linux (from uname -p -i -o saying that) and my target triplet might be i386-redhat-linux (from gfortran -v saying Target: i386-redhat-linux) but I still have no idea what my build triplet is nor how to find it. IMHO your web page needs to explain more clearly what these triplets are and how to find them. I'm a Fortran programmer, not a C programmer or a systems programmer. Those terms are not defined in the Fortran standard and I had never seen them until reporting a suspected bug in gfortran. When googling "build triplet" I found some questions from others as confused as myself, but no answers. -- John Harper, School of Mathematics, Statistics and Computer Science, Victoria University, PO Box 600, Wellington 6140, New Zealand e-mail [EMAIL PROTECTED] phone (+64)(4)463 5341 fax (+64)(4)463 5045 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32446
[Bug fortran/31221] Elemental (MODULO) in array initialization expression
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-21 22:04 --- (In reply to comment #2) > this one seems to work now. > I agree - it works on amd64 and x86_ia64. Closing it. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31221
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #5 from spop at gcc dot gnu dot org 2007-06-21 21:38 --- Subject: Re: [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize) Thanks for pointing me to this bug. I'll have a look. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug fortran/32446] F0.n output format fails with large numbers
--- Comment #8 from John dot Harper at mcs dot vuw dot ac dot nz 2007-06-21 21:37 --- Subject: Re: F0.n output format fails with large numbers On Thu, 21 Jun 2007, jvdelisle at gcc dot gnu dot org wrote: > Date: 21 Jun 2007 04:22:47 - > From: jvdelisle at gcc dot gnu dot org <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: [Bug fortran/32446] F0.n output format fails with large numbers > > > > --- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-06-21 04:22 > --- > Host triplet is: processor - platform - os > > So depending on your processor it would be something like, > > i686-pc-linux-gnu > > or > > x86-64-unknown-linux > > You can get this from the command uname > > Try uname -p -i -o Output of uname -p -i -o is i686 i386 GNU/Linux -- John Harper, School of Mathematics, Statistics and Computer Science, Victoria University, PO Box 600, Wellington 6140, New Zealand e-mail [EMAIL PROTECTED] phone (+64)(4)463 5341 fax (+64)(4)463 5045 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32446
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #30 from spop at gcc dot gnu dot org 2007-06-21 21:25 --- Subject: Bug 20623 Author: spop Date: Thu Jun 21 21:25:27 2007 New Revision: 125929 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125929 Log: PR middle-end/20623 * tree.h (debug_fold_checksum): Declared. * fold-const.c (build_fold_addr_expr_with_type_1): New. (build_fold_addr_expr_with_type, build_fold_addr_expr): Use build_fold_addr_expr_with_type_1. (fold_addr_expr, debug_fold_checksum): New. (fold_checksum_tree): Don't fold TREE_CHAIN of an SSA_NAME. (fold_unary, fold_comparison, split_address_to_core_and_offset): Use fold_addr_expr. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #11 from malitzke at metronets dot com 2007-06-21 21:13 --- After you solve that there is that little matter of udivdi3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug tree-optimization/32075] can't determine dependence between p->a[x+i] and p->a[x+i+1] where x is invariant but defined in the function
--- Comment #6 from ubizjak at gmail dot com 2007-06-21 21:05 --- (In reply to comment #4) > Author: spop > Date: Wed Jun 20 23:42:28 2007 > New Revision: 125900 This commit causes PR32457. -- ubizjak at gmail dot com changed: What|Removed |Added OtherBugsDependingO||32457 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32075
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #4 from ubizjak at gmail dot com 2007-06-21 20:58 --- Bisection points to: Author: spop Date: Wed Jun 20 23:42:28 2007 New Revision: 125900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125900 Log: PR tree-optimization/32075 * tree-data-ref.c (subscript_dependence_tester_1, analyze_miv_subscript, analyze_overlapping_iterations, add_distance_for_zero_overlaps, build_classic_dist_vector, subscript_dependence_tester_1, analyze_overlapping_iterations, subscript_dependence_tester, access_functions_are_affine_or_constant_p, compute_affine_dependence, compute_all_dependences): Pass loop_nest to evolution_function_is_affine_multivariate_p. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-data-ref.c -- ubizjak at gmail dot com changed: What|Removed |Added CC||spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #29 from spop at gcc dot gnu dot org 2007-06-21 20:55 --- Subject: Re: ICE: fold check: original tree changed by fold with --enable-checking=fold So, the last patch bootstrapped, and tests passed with exactly the same fails as on trunk. I'm going to commit that patch to trunk. I'll also send a message with the patch to the [EMAIL PROTECTED] Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #3 from daney at gcc dot gnu dot org 2007-06-21 20:52 --- I haven't yet looked in detail at the RTL dumps, but in the assembly output the store of the new return value was missing. It didn't seem to be in the wrong place, but missing entirely. I just hacked up the patch to see what would happen, and it seemed to fix the problem. I will look at the RTL dumps some more tonight and try to determine where things went wrong. I did however do a cross compiler test run on a remote mipsel-linux board, and the patch fixes all 89 FAILs in the g++ testsuite. So with the patch I am back to zero failures in g++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug fortran/31214] User-defined operator using entry leads to ICE
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-21 20:48 --- (In reply to comment #4) > the original testcase fails (again/still?) > Hmmm - it no longer ICEs but gives an error. I'll have a look. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31214
[Bug c++/32458] __attribute((section(".myname"))) is not working as expected in G++ but works ni GCC
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-21 20:34 --- You forgot to mark the variables as being used. You mark the variable used with the attribute used. Once you do that, the variables are emitted. This is not a bug but by design that GCC can optimize out unused variables, even the ones marked with a different section. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32458
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #22 from dir at lanl dot gov 2007-06-21 20:11 --- This version has all the variables that are actually used intialized. I will have to try the windows version later, but g95 has switched the way that it is wrong again - [dranta:~/tests] dir% g95 -Wall -O3 -o g95Test03 g95Test03.f [dranta:~/tests] dir% g95Test03 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 iprec = 1 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #21 from dir at lanl dot gov 2007-06-21 20:06 --- Created an attachment (id=13761) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13761&action=view) All Used Variables intialized -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #3 from ubizjak at gmail dot com 2007-06-21 19:52 --- Confirmed, for some reason we hit STOP in line 544 (subroutine KEEL). I'm not familiar with Fortran, so perhaps someone who knows it should step through KEEL to find what went wrong. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-21 19:52:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #28 from rguenther at suse dot de 2007-06-21 19:33 --- Subject: Re: ICE: fold check: original tree changed by fold with --enable-checking=fold On Thu, 21 Jun 2007, spop at gcc dot gnu dot org wrote: > --- Comment #26 from spop at gcc dot gnu dot org 2007-06-21 18:21 --- > Subject: Re: ICE: fold check: original tree changed by fold with > --enable-checking=fold > > Just to sum it up, and for asking for advice, > attached is the patch that I'm bootstrapping and testing now. > > > Another thing would be to note where we call this helper from fold() > > routines > > and not set the flag only for those callers which should be safe. We'd need > > another flag argument to the function or another wrapper. > > > > In another version of this patch, I replaced all the callers from the > folder, to use a gcc_assert (TREE_ADDRESSABLE (base) == 1), and this > failed because some calls from the C front-end used that function and > did not have set their addressable flag (yet?). This resulted in all > the fails left in the second part of the bug. > > With the attached patch, fold functions do not set that flag, and this > solves the remaining fails. I'm bootstrapping and testing all > languages again with fold checking. This looks good (again ;)). Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug fortran/31820] Warning if case label value exceeds maximum value for type
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-06-21 19:05 --- > * An INTEGER SELECT construct has a CASE that can never be matched as its >lower value is greater than its upper value. In these cases, no error is shown (integer(kind=1) :: i): select case (i) case (300) case (301:399) case (400) end select But: select case (i) case (400:300) end select results in: case (400:300) 1 Error: Arithmetic overflow converting INTEGER(4) to INTEGER(1) at (1) (and an "Internal Error" as a follow-up). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31820
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #15 from geoffk at gcc dot gnu dot org 2007-06-21 18:31 --- Doesn't fail on powerpc-darwin (nor apparently on powerpc-aix). -- geoffk at gcc dot gnu dot org changed: What|Removed |Added CC|geoffk at geoffk dot org| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #26 from spop at gcc dot gnu dot org 2007-06-21 18:21 --- Subject: Re: ICE: fold check: original tree changed by fold with --enable-checking=fold Just to sum it up, and for asking for advice, attached is the patch that I'm bootstrapping and testing now. > Another thing would be to note where we call this helper from fold() routines > and not set the flag only for those callers which should be safe. We'd need > another flag argument to the function or another wrapper. > In another version of this patch, I replaced all the callers from the folder, to use a gcc_assert (TREE_ADDRESSABLE (base) == 1), and this failed because some calls from the C front-end used that function and did not have set their addressable flag (yet?). This resulted in all the fails left in the second part of the bug. With the attached patch, fold functions do not set that flag, and this solves the remaining fails. I'm bootstrapping and testing all languages again with fold checking. Sebastian --- Comment #27 from spop at gcc dot gnu dot org 2007-06-21 18:21 --- Created an attachment (id=13760) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13760&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug target/32418] ICE in global_alloc, at global.c:514
--- Comment #11 from rask at sygehus dot dk 2007-06-21 18:19 --- Disregard the comment about the code label use count. They have LABEL_PRESERVE_P (/s) set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug libfortran/31726] minloc/maxloc: wrong results with empty array (F2003 only)
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-21 18:14 --- This fixes Tobias' testcase of comment #4. Note that it is a diff relative to the patch for 32298. I'll resubmit the latter in this new form. Paul Index: gcc/fortran/trans-intrinsic.c === *** gcc/fortran/trans-intrinsic.c (révision 125706) --- gcc/fortran/trans-intrinsic.c (copie de travail) *** gfc_conv_intrinsic_minmaxloc (gfc_se * s *** 1928,1933 --- 1928,1934 tree tmp; tree elsetmp; tree ifbody; + tree offset; gfc_loopinfo loop; gfc_actual_arglist *actual; gfc_ss *arrayss; *** gfc_conv_intrinsic_minmaxloc (gfc_se * s *** 2045,2059 /* Assign the value to the limit... */ gfc_add_modify_expr (&ifblock, limit, arrayse.expr); ! /* Remember where we are. */ ! gfc_add_modify_expr (&ifblock, pos, loop.loopvar[0]); ifbody = gfc_finish_block (&ifblock); ! /* If it is a more extreme value or pos is still zero. */ ! tmp = build2 (TRUTH_OR_EXPR, boolean_type_node, ! build2 (op, boolean_type_node, arrayse.expr, limit), ! build2 (EQ_EXPR, boolean_type_node, pos, gfc_index_zero_node)); tmp = build3_v (COND_EXPR, tmp, ifbody, build_empty_stmt ()); gfc_add_expr_to_block (&block, tmp); --- 2046,2068 /* Assign the value to the limit... */ gfc_add_modify_expr (&ifblock, limit, arrayse.expr); ! /* Remember where we are. An offset must be added to the loop ! counter to obtain the required position. */ ! if (loop.temp_dim) ! offset = build_int_cst (type, 1); ! else ! offset =fold_build2 (MINUS_EXPR, gfc_array_index_type, !gfc_index_one_node, loop.from[0]); ! offset = gfc_evaluate_now (offset, &block); ! ! tmp = build2 (PLUS_EXPR, TREE_TYPE (pos), ! loop.loopvar[0], offset); ! gfc_add_modify_expr (&ifblock, pos, tmp); ifbody = gfc_finish_block (&ifblock); ! /* If it is a more extreme value. */ ! tmp = build2 (op, boolean_type_node, arrayse.expr, limit); tmp = build3_v (COND_EXPR, tmp, ifbody, build_empty_stmt ()); gfc_add_expr_to_block (&block, tmp); *** gfc_conv_intrinsic_minmaxloc (gfc_se * s *** 2098,2109 } gfc_cleanup_loop (&loop); ! /* Return a value in the range 1..SIZE(array). */ ! tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type, loop.from[0], !gfc_index_one_node); ! tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type, pos, tmp); ! /* And convert to the required type. */ ! se->expr = convert (type, tmp); } static void --- 2107,2113 } gfc_cleanup_loop (&loop); ! se->expr = convert (type, pos); } static void -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-04-27 13:16:34 |2007-06-21 18:14:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31726
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #19 from pault at gcc dot gnu dot org 2007-06-21 18:12 --- (In reply to comment #18) > Due to huge time constraints, I won't be able to > do anything with this for the next few weeks. Unassigning > myself for the time. > If anybody wants to look over my partial patch and fly with it, > he's welcome :-) My patch to 31726 fixes the inline stuff, or it does not break it, at least. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug fortran/31820] Warning if case label value exceeds maximum value for type
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-21 17:49 --- http://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html -Wsurprising [...] This currently produces a warning under the following circumstances: * An INTEGER SELECT construct has a CASE that can never be matched as its lower value is greater than its upper value. * A LOGICAL SELECT construct has three CASE statements. The latter is implemented and gives: Warning: Logical SELECT CASE block at (1) has more that two cases but the former? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31820
mjpegtools-1.9.0rc2 - internal compiler error - in a PowerPC
* the exact version of GCC; gcc -v Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --enable-checking=release powerpc-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) * the system type; uname -a Linux ... 2.6.18-4-powerpc #1 Wed Apr 18 01:52:23 UTC 2007 ppc GNU/Linux * the complete command line that triggers the bug; cd mjpegtools-1.9.0rc2; ./configure; make Hi, GCC devs, This file: http://sourceforge.net/project/downloading.php?group_id=5776&use_mirror=ufpr&filename=mjpegtools-1.9.0rc2.tar.gz&46187108 ...generate this GCC error when we try make (allways): make[2]: Entrando no diretĂłrio `/tmp/mjpegtools-1.9.0rc2/y4mdenoise' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/local/include -I../utils -DNDEBUG -finline-functions -g -O2 -pthread -DHAVE_ALTIVEC_H=1 -maltivec -mabi=altivec -MT newdenoise.o -MD -MP -MF ".deps/newdenoise.Tpo" -c -o newdenoise.o newdenoise.cc; \ then mv -f ".deps/newdenoise.Tpo" ".deps/newdenoise.Po"; else rm -f ".deps/newdenoise.Tpo"; exit 1; fi MotionSearcher.hh: In instantiation of 'MotionSearcher, ReferencePixel >, ReferenceFrame >, short int, int> >::MatchThrottleFloodFillControl': MotionSearcher.hh:507: instantiated from 'MotionSearcher, ReferencePixel >, ReferenceFrame >, short int, int> >' newdenoise.cc:32: instantiated from here MotionSearcher.hh:2444: internal compiler error: in tsubst, at cp/pt.c:7226 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. I wait that it helps. Aurium
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #2 from burnus at gcc dot gnu dot org 2007-06-21 17:22 --- Further note: -march=pentium2 works -march=pentium3 fails -march=pentium2 -msse fails -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #20 from burnus at gcc dot gnu dot org 2007-06-21 17:14 --- > as far as I can tell none of them are initialized. This is why I'm eagerly waiting for Asher fixing PR20441 and why g95 has -fzero. > Tracing what is wrong with this code explains why so many people don't like > fortran! Well, modern Fortran code should be much better manageable; and initializing all variables by (signalling) NaN helps finding these errors for real/complex variables. Initializing all variables by zero circumvents these errors (and may yield the correct result if zero is the correct number for the initialization ;-). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug middle-end/32370] [4.3 Regression] Segfault after rejecting bogus assembler
--- Comment #4 from sje at cup dot hp dot com 2007-06-21 17:13 --- With optimization, it looks like we die because df_insn_change_bb can handle insn_info being NULL but it can't handle insn_info->defs (or uses or eq_uses) being NULL and that is what is happening with -O2. When no optimization is being done then the failure looks different. I believe this is due to the dataflow merge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32370
[Bug middle-end/32370] [4.3 Regression] Segfault after rejecting bogus assembler
--- Comment #3 from sje at cup dot hp dot com 2007-06-21 17:10 ---
Slightly shorter test case:
unsigned char inb_local(unsigned long port)
{
unsigned char value;
__asm__ __volatile__("in" "b" " %w1, %" "b" "0" : "=a"(value) :
"Nd"(port));
return value;
}
void
x_inb(unsigned short port)
{
unsigned char val;
val = inb_local(port);
}
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-06-21 17:10:20
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32370
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #16 from spop at gcc dot gnu dot org 2007-06-21 17:06 --- Subject: Bug 19590 Author: spop Date: Thu Jun 21 17:06:05 2007 New Revision: 125925 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125925 Log: PR tree-optimization/19590 * tree-vrp.c (adjust_range_with_scev): Set the range when the result of scev is a constant. * gcc/testsuite/gcc.dg/tree-ssa/pr19590.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr19590.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #19 from dominiq at lps dot ens dot fr 2007-06-21 17:04 --- > Subscript 1 of IA (value 2) is out of range (1:1) I don't think it really matter as dimension ia(1),a(20) is the old style for passing arrays. However there are many uninitialized variables: call vr2 ( intp, ivg, cc, ns, it) as far as I can tell none of them are initialized. On ppc-darwin7 latest 4.3 snapshot the new code gives the expected result as does xlf, but not g95. Tracing what is wrong with this code explains why so many people don't like fortran! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug fortran/27589] Add compiler flag to check for uninitalized values at runtime
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-21 16:58 --- Dump a valid program which contains equivalence to show a harder case for the checks (NAG f95 chokes on it). program main implicit none integer :: i, it, jt real:: tt equivalence(jt,tt) dimension it(10) do i=1,10 tt=i print *, tt, jt it(i)=jt end do end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27589
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #18 from burnus at gcc dot gnu dot org 2007-06-21 16:48 --- > Created an attachment (id=13759) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13759&action=view) [edit] > Warning free version Thanks, it finally compiles with NAG "f95 -dusty", which finds directly one problem: Subscript 1 of IA (value 2) is out of range (1:1) In PRMX, line 134 of test.f I changed ia(1) to ia(20) - then it works. Actually, it works on my system (x86_64-unknown-linux-gnu, 4.3.0 20070621) up to the option -O3 -ffast-math -ftree-vectorize -funroll-all-loops It also works now with ifort -O3 -xW, NAG f95, sunf95 and gfortran 4.1.0. Interestingly, both gfortran 4.2.0 and g95 now produce (no options) for the first matrix: row 10.E+00 row 20.1000E+01 0.2000E+01 row 30.3000E+01 0.4000E+01 0.5000E+01 g95 produces the same result as the others using "-fzero". Using NAG f95 with -nan the program crashes with an arithmetic exception, which means that either cc or sum in vr2 must be uninitialized when calling scprod. (-nan initializes the variables with signalling NaN.) Thus there is still a bug lurking in the source code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug c/31537] duplicate weakref emitted with IMA
--- Comment #5 from aldot at gcc dot gnu dot org 2007-06-21 16:44 --- Without combine, the attribute is ignored: $ gcc-4.3.orig-HEAD -c pr.c -o /dev/null pr.c: In function 'f1': pr.c:3: warning: '__weakref__' attribute ignored pr.c: In function 'f2': pr.c:7: warning: '__weakref__' attribute ignored while with combine and the original testcase, current trunk still gives: $ gcc-4.3.orig-HEAD -c f1.i f2.i -combine -o /dev/null /tmp/ccmg6Twk.s: Assembler messages: /tmp/ccmg6Twk.s:3: Error: symbol `__gthrw_pthread_once' is already defined -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31537
[Bug middle-end/32370] [4.3 Regression] Segfault after rejecting bogus assembler
--- Comment #2 from sje at cup dot hp dot com 2007-06-21 16:30 ---
Here is a preprocessed test case"
typedef __builtin_va_list __gnuc_va_list;
typedef __gnuc_va_list va_list;
unsigned char inb_local(unsigned long port) { unsigned char value; __asm__
__vol
atile__("in" "b" " %w1, %" "b" "0" : "=a"(value) : "Nd"(port)); return value; }
void
printk(const char *fmt, ...)
{
va_list argptr;
__builtin_va_start(argptr,fmt);
__builtin_va_end(argptr);
}
void
x_inb(unsigned short port)
{
unsigned char val;
val = inb_local(port);
}
--
sje at cup dot hp dot com changed:
What|Removed |Added
CC||sje at cup dot hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32370
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #17 from dir at lanl dot gov 2007-06-21 16:29 --- I have attached version that generates no warnings with gfortran or g95. As I reduced, it the bug changed - that is the problem with optmization bugs - they are hard to trap. Anyway there is still a bug for some compilers. gfortran on the Macintosh and Linux are Ok. g77 is happy and gets the correct answer - [dranta:~/tests] dir% g77 -o g95Test02 g95Test02.f [dranta:~/tests] dir% g95Test02 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 iprec = 1 1 lower triangular matrix with 3 rows row 10.1600E+02 row 20.9000E+01 0.2000E+02 row 30.1100E+02 0.1200E+02 0.2600E+02 g95 cannot decide which wrong answer it likes - [dranta:~/tests] dir% g95 -Wall -g -o g95Test02 g95Test02.f [dranta:~/tests] dir% g95Test02 1 lower triangular matrix with 3 rows row 1 -0.2000E+01 row 20.1000E+01 0.2000E+01 row 30.3000E+01 0.4000E+01 0.5000E+01 iprec = 1 1 lower triangular matrix with 3 rows row 1 -0.3999E+01 row 20.1000E+01 0.4000E+01 row 30.3000E+01 0.4000E+01 0.1000E+02 [dranta:~/tests] dir% g95 -Wall -O3 -o g95Test02 g95Test02.f [dranta:~/tests] dir% g95Test02 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 iprec = 1 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 gfortran (i386-pc-mingw32) on windows now gets the wrong answer with -O3 - [EMAIL PROTECTED] ~/tests $ gfortran -g -o g95Test02 g95Test02.f [EMAIL PROTECTED] ~/tests $ g95Test02 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 iprec = 1 1 lower triangular matrix with 3 rows row 10.1600E+02 row 20.9000E+01 0.2000E+02 row 30.1100E+02 0.1200E+02 0.2600E+02 [EMAIL PROTECTED] ~/tests $ gfortran -O3 -o g95Test02 g95Test02.f [EMAIL PROTECTED] ~/tests $ g95Test02 1 lower triangular matrix with 3 rows row 10.E+00 row 20.1000E+01 0.2000E+01 row 30.3000E+01 0.4000E+01 0.5000E+01 iprec = 1 1 lower triangular matrix with 3 rows row 10.E+00 row 20.1000E+01 0.4000E+01 row 30.3000E+01 0.4000E+01 0.1000E+02 [EMAIL PROTECTED] ~/tests $ gfortran --v Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared --enable-libgomp Thread model: win32 gcc version 4.3.0 20070522 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug c++/32458] New: __attribute((section(".myname"))) is not working as expected in G++ but works ni GCC
I used the simple program provided in the gcc help pages.
i am using gcc-4.2.0 cross compiler for ARM (I think the problem
should persist in native compilers as well)
a.c
#include
int main(void) {
static int a __attribute__ ((section (".offsets"))) = 0;
static int myname __attribute__ ((section (".offsets"))) = 0 ;
//static char stack[1] __attribute__ ((section (".stack"))) =
{ 0 };
static int init_data __attribute__ ((section (".prems"))) = 0;
printf("Hellow world %d\n", 0);
return 0;
}
---
---a.cc
#include
int main(void) {
static int a __attribute__ ((section (".offsets"))) = 0;
static int myname __attribute__ ((section (".offsets"))) = 0 ;
//static char stack[1] __attribute__ ((section (".stack"))) =
{ 0 };
static int init_data __attribute__ ((section (".prems"))) = 0;
printf("Hellow world %d\n", 0);
return 0;
}
-
The files 'a.c' and 'a.cc' are the same except that the 'a.cc' is
treated as c++ file.
in a.o created from 'a.c' has the sections. but the a.o created from
'a.cc' doesn't have
command used:
arm-none-linux-gnueabi-gcc -c a.c
arm-none-linux-gnueabi-gcc -c a.cc
Please let me know if I am wrong here, or let me know if there is a
workaround to make the 'a.cc' to have the sections compiled in.
/Prem
--
Summary: __attribute((section(".myname"))) is not working as
expected in G++ but works ni GCC
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: prem dot mallappa at gmail dot com
GCC build triplet: x86_64-pc-linux
GCC host triplet: x86_64-pc-linux
GCC target triplet: x86_64-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32458
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #16 from dir at lanl dot gov 2007-06-21 16:16 --- Created an attachment (id=13759) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13759&action=view) Warning free version -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug target/32418] ICE in global_alloc, at global.c:514
--- Comment #10 from rask at sygehus dot dk 2007-06-21 16:15 ---
Created an attachment (id=13758)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13758&action=view)
Preprocessed source code for the problem in comment 9.
$ ./xgcc -B./ -S -dp -o /dev/null ~/complex_io.cc
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:
In function 'std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::complex<_Tp>&)
[with _Tp = long double, _CharT = char, _Traits = std::char_traits]':
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:527:
error: unable to find a register to spill in class 'A_REGS'
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:527:
error: this is the insn:
(insn 228 230 229 6 (set (reg:HI 84)
(reg:HI 4 a0)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 4 a0)
(nil)))
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:527:
internal compiler error: in spill_failure, at reload1.c:2002
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug target/32418] ICE in global_alloc, at global.c:514
--- Comment #9 from rask at sygehus dot dk 2007-06-21 15:59 ---
I tried this on top of the patch in comment 3 of bug 32441:
Index: gcc/config/m32c/m32c.c
===
--- gcc/config/m32c/m32c.c (revision 125892)
+++ gcc/config/m32c/m32c.c (working copy)
@@ -1143,7 +1143,7 @@ m32c_eh_return_stackadj_rtx (void)
{
rtx sa;
- sa = gen_reg_rtx (Pmode);
+ sa = gen_rtx_REG (Pmode, R0_REGNO);
cfun->machine->eh_stack_adjust = sa;
}
return cfun->machine->eh_stack_adjust;
The build then ends with a reload failure in libstdc++.
Spilling for insn 228.
reload failure for reload 0
Reloads for insn # 228
Reload 0: reload_in (HI) = (plus:HI (reg/f:HI 7 fb)
(const_int 0 [0x0]))
A_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0)
reload_in_reg: (plus:HI (reg/f:HI 7 fb)
(const_int 0 [0x0]))
The lreg dump shows some insn sequences which use up both registers in
A_REGS:
(jump_insn 237 235 238 5 (set (pc)
(label_ref 236)) 163 {jump} (nil))
(barrier 238 237 227)
(code_label/s 227 238 230 6 56 "" [1 uses])
(note 230 227 228 6 [bb 6])
(insn 228 230 229 6 (set (reg:HI 84)
(reg:HI 4 a0)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 4 a0)
(nil)))
(insn 229 228 102 6 (set (reg:HI 83)
(reg:HI 5 a1)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 5 a1)
(nil)))
...
(jump_insn 243 241 244 13 (set (pc)
(label_ref 242)) 163 {jump} (nil))
(barrier 244 243 223)
(code_label/s 223 244 226 14 55 "" [1 uses])
(note 226 223 224 14 [bb 14])
(insn 224 226 225 14 (set (reg:HI 84)
(reg:HI 4 a0)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 4 a0)
(nil)))
(insn 225 224 166 14 (set (reg:HI 83)
(reg:HI 5 a1)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 5 a1)
(nil)))
(note/s 166 225 168 14 "" 52)
...
(insn 203 197 231 15
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:527
(use (reg/i:HI 0 r0)) -1 (nil))
(code_label/s 231 203 234 16 57 "" [1 uses])
(note 234 231 232 16 [bb 16])
(insn 232 234 233 16 (set (reg:HI 84)
(reg:HI 4 a0)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 4 a0)
(nil)))
(insn 233 232 185 16 (set (reg:HI 83)
(reg:HI 5 a1)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 5 a1)
(nil)))
(code_label/s 185 233 186 17 53 "" [3 uses])
(note 186 185 187 17 [bb 17])
The usage count is one too high for all the code labels shown above. In
other words, the code that is causing reload problems is dead code. The code
first appears in the "eh" pass and refers to a0 and a1 from the beginning.
int
m32c_eh_return_data_regno (int n)
{
switch (n)
{
case 0:
return A0_REGNO;
case 1:
return A1_REGNO;
default:
return INVALID_REGNUM;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-21 15:58 --- Missed to say that yesterday's version (r125874) was ok. Occurs here with 125909 (bootstrapped) and 125922 (only build). svn status shows no changes in my tree. However, it could not be reproduced by Uros with 125920 on i686. (Mine was x86-64 with -m32.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug tree-optimization/32451] [4.3 Regression] ICE in verify_flow_info after DOM2
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-06-21 14:56 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32451
[Bug tree-optimization/32453] [4.3 Regression] ICE in build2_stat, at tree.c:3074 (extract_range_from_assert)
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-21 14:56 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32453
[Bug tree-optimization/32453] [4.3 Regression] ICE in build2_stat, at tree.c:3074 (extract_range_from_assert)
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-21 14:54 --- Subject: Bug 32453 Author: rguenth Date: Thu Jun 21 14:54:47 2007 New Revision: 125922 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125922 Log: 2007-06-21 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/32453 * tree-vrp.c (extract_range_from_assert): Build POINTER_PLUS_EXPR for pointer anti-range. * gcc.c-torture/compile/pr32453.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32453.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32453
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #10 from rguenther at suse dot de 2007-06-21 14:52 --- Subject: Re: [4.3 Regression] cannot take address of bit field On Thu, 21 Jun 2007, hubicka at ucw dot cz wrote: > > > --- Comment #9 from hubicka at ucw dot cz 2007-06-21 14:39 --- > Subject: Re: [4.3 Regression] cannot take address of bit field > > > > > > > --- Comment #8 from rguenth at gcc dot gnu dot org 2007-06-21 11:19 > > --- > > Ping? > > I tought the bug is long fixed by moving the folding from fold into > Gimple fold_stmt. We probably should not emit frontend warnings/errors > that late, I will check if I can get it done earlier at gimplification > time. Otherwise Andrew's patch to avoid the folding for bit_field_type > is probably way to go. The bug is still there and we fail to build the kernel because of it still. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug target/32457] New: [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
This is with the polyhedron test gas_dyn.f90 http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html It only occurs for gas_dyn.f90 and only with -m32 (-m64 is ok). This is with gcc-Version 4.3.0 20070621 on x86_64-unknown-linux-gnu. gfortran -m32 -march=opteron -ftree-vectorize -O1 gas_dyn.f90 time ./a.out real0m0.005s -- Summary: [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: major Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org GCC target triplet: i586-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug target/32455] internal compiler error: in convert_move, at expr.c:362
--- Comment #1 from frederic dot schuh at neuf dot fr 2007-06-21 14:49 --- Created an attachment (id=13757) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13757&action=view) preprocessed file in attachment -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32455
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #9 from hubicka at ucw dot cz 2007-06-21 14:39 --- Subject: Re: [4.3 Regression] cannot take address of bit field > > > --- Comment #8 from rguenth at gcc dot gnu dot org 2007-06-21 11:19 > --- > Ping? I tought the bug is long fixed by moving the folding from fold into Gimple fold_stmt. We probably should not emit frontend warnings/errors that late, I will check if I can get it done earlier at gimplification time. Otherwise Andrew's patch to avoid the folding for bit_field_type is probably way to go. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug middle-end/32447] without-decimal-float needed
--- Comment #3 from malitzke at metronets dot com 2007-06-21 14:33 --- Thanks for helping out again. Enjoy Japan. I was there quite often, dealing with NEC and Mitsubishi, but as a buyer representative for for multi-million $ projects. At that level it was pleasure to do business, even enduring sitting cross-legged on the floor; washing down raw fish with japanese whiskey on the rocks. But to matters at hand. What is called a compiler is actually a crime against traditional usage of the term. "compilare to plunder; 1: to collect into a volume 2: to compose out of materials from other documents" this more accurately describes the function of a traditional loader. A, so-called, compiler is really a translator. In the case of GCC the Italian saying "tradutore; traditore" translator; traitor seems appropriate. I know how hard it is to do technical translation, but that was my first well-paid career at about 15 years of age. My third career was being a real-time assembly language programmer. I received a letter of commendation as a super-programmer for committing the following programming crimes 1) jumping into the middle of instructions; 2) writing self-modifying code. You do what you have to do to put food on the table. I actually jeopardized a three month engagement by showing with the help of simple queuing theory that the project (in-spite of the above tricks) was doomed to fail. The COBOL manager assured me that I was doing a marvelous job squeezing code into 128 byte overlays and not to worry about over-all design. They bought back that contract. In my fourth career I was termed by the company president to-be "our secret weapon" for writing specifications, contracts, and inter-national standards that with-stood the test of legality but were blatantly uni-sided in favor of my employer (very good money). Now, being retired and considering the C and FORTRAN compilers as quite important tools in my UNIX tool-chest; I am trying to prevent GCC being destroyed by mis-interpretation and mis-use of standards legal shenanigans, etc. My loyalty is to "my" tools and not to the people involved with GCC or even GCC as now interpreted. See PR32347. Incidentally, two quotes from K&R "Again because the language reflects the capabilities of current computers, C programs tend to be efficient enough that there is no compulsion to write assembly language instead" (Intro 1st ed). '(ANSI) established a committee whose goal was to produce "and unambiguous and machine-independent definition of the language C" while still _retaining_ its _spirit_'. Preface 2nd Ed, emphasis added. Ritchie got a "Turing Award" and the current crop of people should respect the creator's wishes. If they want to make changes against that original design and call it something else; just as Ritchie acknowledges BCPL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32447
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #3 from jv244 at cam dot ac dot uk 2007-06-21 14:28 --- this is the list of options I have tested, the comment indicates if this yields a failure or not, basically, you need -O2 and -march=native to trigger the bug using '-O1 -march=native -pg' or '-O2 -pg' are not sufficient # OK FCFLAGS="-O3 -ffast-math -ftree-vectorize -funroll-loops -march=native" # wrong FCFLAGS="-O3 -ffast-math -ftree-vectorize -march=native -funroll-loops -pg" # OK FCFLAGS="-O1 -march=native -pg" # OK FCFLAGS="-O1 -march=native -ftree-vectorize -pg" # wrong FCFLAGS="-O2 -march=native -ftree-vectorize -pg" # wrong FCFLAGS="-O2 -march=native -pg" # OK FCFLAGS="-O2 -pg" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug libfortran/32456] New: IO error message should show Unit/Filename
! echo "z" > foo.dat program test implicit none integer :: i open(99,file="foo.dat") read(99,*) i print *, i end program gfortran: At line 5 of file x.f90 Fortran runtime error: Bad integer for item 1 in list input Expected: gfortran prints out the filename and/or unit as other compilers do; especially useful for users which don't have the source code. g95: At line 5 of file x.f90 (Unit 99 "foo.dat") Fortran runtime error: Bad integer for item 1 in list input NAG f95: Invalid input for integer editing Program terminated by I/O error on unit 99 (File="foo.dat",Formatted,Sequential) ifort: forrtl: severe (59): list-directed I/O syntax error, unit 99, file /dev/shm/foo.dat sunf95: Error 1083: unexpected character in integer value Location: the READ statement at line 5 of "x.f90" Unit: 99 File: foo.dat Input: z For stdin * they show (g95,NAG f95, ifort, sunf95): At line 4 of file x.f90 (Unit 5) Program terminated by I/O error on unit 5 (Input_Unit,Formatted,Sequential) forrtl: severe (59): list-directed I/O syntax error, unit -4, file /dev/pts/0 Unit: * File: standard input -- Summary: IO error message should show Unit/Filename Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32456
[Bug target/32455] internal compiler error: in convert_move, at expr.c:362
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c |target GCC target triplet||hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32455
[Bug c/32455] New: internal compiler error: in convert_move, at expr.c:362
HARDWARE: - System: HP-UX B.11.00 Machine: 9000/785 COMPILATION: /usr/local/bin/gcc -v -save-temps -c TP.c -o TP_c.o Using built-in specs. Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure Thread model: posix gcc version 4.1.2 /usr/local/libexec/gcc/hppa2.0w-hp-hpux11.11/4.1.2/cc1 -E -quiet -v TP.c -fpch-preprocess -o TP.i ignoring nonexistent directory "NONE/include" ignoring nonexistent directory "/usr/local/hppa2.0w-hp-hpux11.11/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/lib/gcc/hppa2.0w-hp-hpux11.11/4.1.2/include /usr/include End of search list. /usr/local/libexec/gcc/hppa2.0w-hp-hpux11.11/4.1.2/cc1 -fpreprocessed TP.i -quiet -dumpbase TP.c -auxbase-strip TP_c.o -version -o TP.s GNU C version 4.1.2 (hppa2.0w-hp-hpux11.11) compiled by GNU C version 4.1.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 74aa6c12f75acdb1c74c59fde58fd82f In file included from TP.c:130: atu.inc: In function 'CONCAT_STR_C': atu.inc:264: warning: second parameter of 'va_start' not last named argument atu.inc:264: internal compiler error: in convert_move, at expr.c:362 I try to compil a source code comes from a library target chpgnu of TestRealTime -- Summary: internal compiler error: in convert_move, at expr.c:362 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: frederic dot schuh at neuf dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32455
[Bug fortran/32439] f951: out of memory with '-O1 -fbounds-check'
--- Comment #2 from jv244 at cam dot ac dot uk 2007-06-21 13:50 --- (In reply to comment #1) > Can you run the compile inside gdb and check periodically where it wastes its > time? > I have a few gdb backtraces, but it looks like it is just writing the .s file. At the point where f951 dies the .s file is about 53Mb in size. The last few gdb traces I collected are: #0 shorten_branches (first=0x2ad9a29700) at /scratch/vondele/gcc_trunk/gcc/gcc/final.c:1081 #1 0x0056fca1 in rest_of_handle_shorten_branches () at /scratch/vondele/gcc_trunk/gcc/gcc/final.c:4046 #2 0x0061b396 in execute_one_pass (pass=0xcfa400) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1125 #3 0x0061b55c in execute_pass_list (pass=0xcfa400) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1178 #4 0x0061b56e in execute_pass_list (pass=0xcfaae0) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1179 #5 0x0061b56e in execute_pass_list (pass=0xcfaa80) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1179 #6 0x006e6358 in tree_rest_of_compilation (fndecl=0x2a96cf2300) at /scratch/vondele/gcc_trunk/gcc/gcc/tree-optimize.c:406 #7 0x0082ba30 in cgraph_expand_function (node=0x2a96cf2500) at /scratch/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1073 #8 0x0082de12 in cgraph_optimize () at /scratch/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1142 #0 0x0061d09d in pointer_set_insert (pset=0x26b622f0, p=0x2ae2aebea0) at /scratch/vondele/gcc_trunk/gcc/gcc/pointer-set.c:68 #1 0x00698881 in verify_stmts () at /scratch/vondele/gcc_trunk/gcc/gcc/tree-cfg.c:3573 #2 0x0079c317 in verify_ssa (check_modified_stmt=1 '\001') at /scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa.c:614 #3 0x0061b1a5 in execute_function_todo (data=Variable "data" is not available. ) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:972 #4 0x0061aeef in execute_todo (flags=Variable "flags" is not available. ) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:996 #5 0x0061b3ee in execute_one_pass (pass=0xcfcd40) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1147 #6 0x0061b55c in execute_pass_list (pass=0xcfcd40) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1178 #7 0x0061b56e in execute_pass_list (pass=0xcfc1a0) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1179 #0 0x00669b9e in refers_to_regno_p (regno=17, endregno=18, x=0x2aba886640, loc=0x0) at /scratch/vondele/gcc_trunk/gcc/gcc/rtlanal.c:1285 #1 0x0099c4e9 in record_value_for_reg (reg=0x2aba8864e0, insn=0x2ad6f2db40, value=0x2aba886640) at /scratch/vondele/gcc_trunk/gcc/gcc/combine.c:11194 #2 0x009ae29a in rest_of_handle_combine () at /scratch/vondele/gcc_trunk/gcc/gcc/combine.c:1069 #3 0x0061b396 in execute_one_pass (pass=0xcfed60) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1125 #0 0x004ff2f0 in df_lr_bb_local_compute (bb_index=64) at /scratch/vondele/gcc_trunk/gcc/gcc/df-problems.c:1379 #1 0x00500bbf in df_lr_verify_transfer_functions () at /scratch/vondele/gcc_trunk/gcc/gcc/df-problems.c:1905 #2 0x004fbcde in df_verify () at /scratch/vondele/gcc_trunk/gcc/gcc/df-core.c:1514 #3 0x004fc809 in df_analyze () at /scratch/vondele/gcc_trunk/gcc/gcc/df-core.c:1106 #4 0x009d5757 in move_loop_invariants () at /scratch/vondele/gcc_trunk/gcc/gcc/loop-invariant.c:641 #5 0x009d3d57 in rtl_move_loop_invariants () at /scratch/vondele/gcc_trunk/gcc/gcc/loop-init.c:238 #6 0x0061b396 in execute_one_pass (pass=0xcff4e0) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1125 #0 0x0063ed17 in init_subregs_of_mode () at /scratch/vondele/gcc_trunk/gcc/gcc/regclass.c:2410 #1 0x0061b396 in execute_one_pass (pass=0xcfb340) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1125 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32439
[Bug target/32441] ICE in expand_expr_real_1, at expr.c:7109
--- Comment #5 from pinskia at gmail dot com 2007-06-21 13:47 --- Subject: Re: ICE in expand_expr_real_1, at expr.c:7109 > You shouldn't introduce calls to langhooks. Why not use mode_for_size? I was just copying code from fold-const.c. I have the mode already, I need an integer tree type that matches that mode. So really mode_for_size will not give me any more information. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32441
[Bug target/32423] gcc.c-torture/compile/20020604-1.c ICEs
--- Comment #1 from zadeck at naturalbridge dot com 2007-06-21 13:37 --- What is the configure string that i use to recreate this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32423
[Bug tree-optimization/32435] ICE in build2_stat for -O2 -ftree-vectorize -maltivec
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-21 13:32 --- Yes this is the same issue, we have POINTER_PLUS_EXPR and we are trying to create it with a vector type. *** This bug has been marked as a duplicate of 32421 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32435
[Bug tree-optimization/32421] [4.3 Regression] -ftree-vectorize -msse2 ICEs in build2_stat when vectorizing POINTER_PLUS_EXPR
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-21 13:32 --- *** Bug 32435 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32421
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #15 from dir at lanl dot gov 2007-06-21 13:23 --- >BTW I do not see (beside obfuscation) the interest of the constructs: It is the construct: jt=t(j2) tt=tt+tt t(j2)=jt that is being optmized away or done incorrectly when the second matrix stays the same. The obfuscation is required because the program is doing virtual memory management and at this point floating point data is in one of the raw integer virtual arrays and so that is the game that is played to do the floating point add. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug fortran/30381] [4.1 only] ISHFTC() constant folding is broken.
--- Comment #7 from bardeau at iram dot fr 2007-06-21 13:08 --- (In reply to comment #6) > Fixed on mainline and 4.2. Unless you really want to backport it to 4.1.3, I'm > closing this bug. > The bug still appears under cygwin with gcc 4.3: program test integer*4 a a=1 print *,"a = ", a print *,"ISHFTC(a,2,32) = ", ISHFTC(a,2,32) print *,"ISHFTC(a,2) = ", ISHFTC(a,2) end ~> ./test.exe a =1 ISHFTC(a,2,32) =1 ISHFTC(a,2) =4 This happens only if A is INTEGER*4 or 8, and if 3rd argument is present. Also, no problem under Linux. ~> uname -a CYGWIN_NT-5.1 dhcp-bardeau 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin ~> gfortran -v Using built-in specs. Target: i686-pc-cygwin Configured with: ../gcc43/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --enable-bootstrap --enable-threads=posix --enable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-nls --disable-libmudflap --disable-shared --disable-win32-registry --with-system-zlib --enable-checking=release --enable-werror --without-included-gettext --without-x --enable-libgomp Thread model: posix gcc version 4.3.0 20070512 (experimental) Cheers, Sebastien -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30381
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #14 from dir at lanl dot gov 2007-06-21 12:57 --- >What is actually the expected result? Depending on the compiler and compiler >setting, I get completely different results for the second triangular matrix. >(The first matrix remains always the same.) What the program does in this section is multiply the diagonal of the matrix by 2 with the line - tt=tt+tt and so (0.8000E+01 -> 0.1600E+02), (0.1000E+02 -> 0.2000E+02) and (0.1300E+02 -> 0.2600E+02 ) and the other three elememts should stay the same. In debug mode, most compilers will give the correct answer, but the addition is sometimes being optmized away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug target/32369] [frv] macro "DF_LIVE_IN" passed 2 arguments, but takes just 1
--- Comment #5 from zadeck at naturalbridge dot com 2007-06-21 12:49 --- this was fixed with the commit. -- zadeck at naturalbridge dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32369
[Bug fortran/32454] Bounds-check misses overflow of lhs array
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-21 12:33 --- I forgot to mention: I think this file is valid Fortran 2003 and only invalid Fortran 95. Maybe using: integer, dimension(4) :: y is a better test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32454
[Bug fortran/32454] New: Bounds-check misses overflow of lhs array
Should give with -fbounds-check something like the following (NAG f95 -C=all): Rank 1 of array operand has extent 8 instead of 4 Program terminated by fatal error In BOUNDSERROR, line 7 of test.f90 I think it might a duplicate of some PR, though I couldn't find it. program boundsError implicit none integer :: i integer, dimension(:), allocatable :: y allocate(y(4)) y = 0.0 print *, size(y) y = [y, (99,i=1,4)] print *, size(y) end program boundsError -- Summary: Bounds-check misses overflow of lhs array Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 27766 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32454
[Bug target/32431] ICE in df_refs_verify, at df-scan.c:4066
--- Comment #2 from zadeck at naturalbridge dot com 2007-06-21 12:29
---
Subject: Re: ICE in df_refs_verify, at df-scan.c:4066
rask at sygehus dot dk wrote:
> --- Comment #1 from rask at sygehus dot dk 2007-06-20 16:58 ---
> Created an attachment (id=13747)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13747&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13747&action=view)
> Preprocessed testcase
>
>
>
:ADDPATCH MIDDLE-END:
The underlying problem is that the later phases of compilation on the
m68hc11 create shared rtl. The reorg phase needs df and also needs the
rtl to be unshared. This causes problems because the unsharing process
changes insns in ways that mess up df's scanning information.
There are two ways to solve this problem:
1) Go in and fix the places that create shared rtl in this back end.
2) Make the rtl unsharing df-ready.
I chose plan (2) because I know how to do this and do not know how to do
(1).
The astute middle end/gwp maintainer may say that (1) is the right thing
to do and so the sharing police (namely honza) should investigate this
pr. If that is the proper plan of action, then this patch may go into
the trash.
I tested this on x86-64 which does call unshare_all_rtl_again (from
ifcvt) to verify that this does not cause any problems and it does fix
the immediate bug here.
Ok for trunk?
Kenny
2007-06-21 Kenneth Zadeck <[EMAIL PROTECTED]>
PR middle-end/32431
* emit-rtl.c (unshare_all_rtl_in_chain): Now rescans insns and
notes if unsharing happens.
(copy_rtx_if_shared_1): Returns true if sharing was found.
config/m68hc11/m68hc11.c: (m68hc11_reorg): Move reinitialization
of cfg to before unsharing rtl.
Index: emit-rtl.c
===
--- emit-rtl.c (revision 125916)
+++ emit-rtl.c (working copy)
@@ -184,7 +184,7 @@ static int reg_attrs_htab_eq (const void
static reg_attrs *get_reg_attrs (tree, int);
static tree component_ref_for_mem_expr (tree);
static rtx gen_const_vector (enum machine_mode, int);
-static void copy_rtx_if_shared_1 (rtx *orig);
+static bool copy_rtx_if_shared_1 (rtx *orig);
/* Probability of the conditional branch currently proceeded by try_split.
Set to -1 otherwise. */
@@ -2350,8 +2350,20 @@ unshare_all_rtl_in_chain (rtx insn)
for (; insn; insn = NEXT_INSN (insn))
if (INSN_P (insn))
{
- PATTERN (insn) = copy_rtx_if_shared (PATTERN (insn));
- REG_NOTES (insn) = copy_rtx_if_shared (REG_NOTES (insn));
+ rtx orig = PATTERN (insn);
+
+if (copy_rtx_if_shared_1 (&orig))
+ {
+ PATTERN (insn) = orig;
+ df_insn_rescan (insn);
+ }
+
+ orig = REG_NOTES (insn);
+ if (copy_rtx_if_shared_1 (&orig))
+ {
+ REG_NOTES (insn) = orig;
+ df_notes_rescan (insn);
+ }
}
}
@@ -2383,10 +2395,11 @@ copy_rtx_if_shared (rtx orig)
return orig;
}
-/* Mark *ORIG1 as in use, and set it to a copy of it if it was already in
- use. Recursively does the same for subexpressions. */
+/* Mark *ORIG1 as in use, and set it to a copy of it if it was already
+ in use. Recursively does the same for subexpressions. Return true
+ if copies were made. */
-static void
+static bool
copy_rtx_if_shared_1 (rtx *orig1)
{
rtx x;
@@ -2396,13 +2409,15 @@ copy_rtx_if_shared_1 (rtx *orig1)
const char *format_ptr;
int copied = 0;
int length;
+ bool changed = false;
+
/* Repeat is used to turn tail-recursion into iteration. */
repeat:
x = *orig1;
if (x == 0)
-return;
+return changed;
code = GET_CODE (x);
@@ -2421,15 +2436,15 @@ repeat:
case CC0:
case SCRATCH:
/* SCRATCH must be shared because they represent distinct values. */
- return;
+ return changed;
case CLOBBER:
if (REG_P (XEXP (x, 0)) && REGNO (XEXP (x, 0)) < FIRST_PSEUDO_REGISTER)
- return;
+ return changed;
break;
case CONST:
if (shared_const_p (x))
- return;
+ return changed;
break;
case INSN:
@@ -2438,7 +2453,7 @@ repeat:
case NOTE:
case BARRIER:
/* The chain of insns is not being copied. */
- return;
+ return changed;
default:
break;
@@ -2451,6 +2466,7 @@ repeat:
{
x = shallow_copy_rtx (x);
copied = 1;
+ changed = true;
}
RTX_FLAG (x, used) = 1;
@@ -2469,7 +2485,7 @@ repeat:
{
case 'e':
if (last_ptr)
-copy_rtx_if_shared_1 (last_ptr);
+changed |= copy_rtx_if_shared_1 (last_ptr);
last_ptr = &XEXP (x, i);
break;
@@ -2488,7 +2504,7 @@ repeat:
for (j = 0; j < len; j++)
{
if (last_ptr)
- copy_rtx_if_shared_1 (last_ptr);
+ changed |= copy_rtx_if_shared_1 (last_ptr);
last_ptr = &XVECEXP (x,
[Bug middle-end/32362] ICE: in lookup_decl_in_outer_ctx, at omp-low.c:1508
--- Comment #4 from jakub at gcc dot gnu dot org 2007-06-21 12:24 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32362
[Bug tree-optimization/31866] [4.3 Regression] ICE with tree check error: expected ssa_name, have var_decl in create_outofssa_var_map
--- Comment #4 from jakub at gcc dot gnu dot org 2007-06-21 12:23 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31866
[Bug tree-optimization/31866] [4.3 Regression] ICE with tree check error: expected ssa_name, have var_decl in create_outofssa_var_map
--- Comment #3 from jakub at gcc dot gnu dot org 2007-06-21 12:21 --- Subject: Bug 31866 Author: jakub Date: Thu Jun 21 12:20:42 2007 New Revision: 125919 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125919 Log: PR tree-optimization/31866 * tree-ssa-coalesce.c (create_outofssa_var_map): Do nothing if ASM_EXPR's input is not a SSA_NAME. * gcc.dg/pr31866.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr31866.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-coalesce.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31866
[Bug middle-end/32362] ICE: in lookup_decl_in_outer_ctx, at omp-low.c:1508
--- Comment #3 from jakub at gcc dot gnu dot org 2007-06-21 12:16 --- Subject: Bug 32362 Author: jakub Date: Thu Jun 21 12:15:53 2007 New Revision: 125918 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125918 Log: PR middle-end/32362 * omp-low.c (lookup_decl_in_outer_ctx): Don't ICE if t is NULL, but decl is a global var, instead return decl. * gimplify.c (gimplify_adjust_omp_clauses_1): Add shared clauses even for is_global_var decls, if they are private in some outer context. * testsuite/libgomp.c/pr32362-1.c: New test. * testsuite/libgomp.c/pr32362-2.c: New test. * testsuite/libgomp.c/pr32362-3.c: New test. Added: branches/gcc-4_2-branch/libgomp/testsuite/libgomp.c/pr32362-1.c branches/gcc-4_2-branch/libgomp/testsuite/libgomp.c/pr32362-2.c branches/gcc-4_2-branch/libgomp/testsuite/libgomp.c/pr32362-3.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/gimplify.c branches/gcc-4_2-branch/gcc/omp-low.c branches/gcc-4_2-branch/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32362
[Bug middle-end/32362] ICE: in lookup_decl_in_outer_ctx, at omp-low.c:1508
--- Comment #2 from jakub at gcc dot gnu dot org 2007-06-21 12:11 --- Subject: Bug 32362 Author: jakub Date: Thu Jun 21 12:11:00 2007 New Revision: 125917 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125917 Log: PR middle-end/32362 * omp-low.c (lookup_decl_in_outer_ctx): Don't ICE if t is NULL, but decl is a global var, instead return decl. * gimplify.c (gimplify_adjust_omp_clauses_1): Add shared clauses even for is_global_var decls, if they are private in some outer context. * testsuite/libgomp.c/pr32362-1.c: New test. * testsuite/libgomp.c/pr32362-2.c: New test. * testsuite/libgomp.c/pr32362-3.c: New test. Added: trunk/libgomp/testsuite/libgomp.c/pr32362-1.c trunk/libgomp/testsuite/libgomp.c/pr32362-2.c trunk/libgomp/testsuite/libgomp.c/pr32362-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/omp-low.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32362
[Bug tree-optimization/32451] [4.3 Regression] ICE in verify_flow_info after DOM2
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-06-21 12:00 --- Subject: Bug 32451 Author: rguenth Date: Thu Jun 21 12:00:47 2007 New Revision: 125916 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125916 Log: 2007-06-21 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/32451 * tree-ssa-threadupdate.c (thread_single_edge): Fixup edge flags. * g++.dg/torture/20070621-1.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/20070621-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadupdate.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32451
[Bug tree-optimization/32453] [4.3 Regression] ICE in build2_stat, at tree.c:3074 (extract_range_from_assert)
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-21 11:38 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-21 11:38:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32453
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #6 from rob1weld at aol dot com 2007-06-21 11:30 --- Thanks for everyones input. The only issues related to this 'bug' are: 1): printf _sometimes_ prints "-0.000" and sometimes prints "+0.000" - the reason it is even showing the "+" or "-" is because I enabled them using "%+f", this I understand. My 2 cents is that the correct answer is "+0.000" and never "-0.000" - UNLESS, that is related to _accuracy_ and nothing to do with "printf"; in which cause that is a different bug. 2): Using a "sprintf()" to print the answer to a char string (which itself is never even used!) "fixes" the bug. This suggests to me that something is upsetting the folding. It can't be an optimization issue since this occurs at any optimization level (even -O0, none) so unless it is the parsing it may be the folding. Sometimes GCC goes "crazy" (see 6, 8, and 9). If indeed GCC is operating "correctly" it should do the SAME thing everytime - Correct ? If GCC want to convert it to an INT, fine. the correct answer is ZERO and not: a): -16522743262502092537856.000 b): +60316137357217275485696900081464849817...(many more digits)... c): -25531721305534761946185249871767754587...(many more digits)... Cygwin gives the same (ridiculous) answer _everytime_ which is better though it ought to be ZERO. If GCC thinks it is doing the correct thing (there is NO BUG) then why doesn't it do the SAME thing - it is saying that the previous time it was wrong and wants to give a different answer, when it ought to give the same answer. 3): If this belongs on http://gcc.gnu.org/bugs.html#nonbugs then this is a documentation bug. Thanks for considering this report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #5 from ubizjak at gmail dot com 2007-06-21 11:27 --- (In reply to comment #3) > GCC printed no warning about disliking a conversion. It just happens that gcc is not like microwave oven that has to include warnings about not drying animals in it. > Sometimes the answer is _positive_ zero and sometimes the answer is _negative_ > zero. http://en.wikipedia.org/wiki/Floating-point -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug tree-optimization/32453] [4.3 Regression] ICE in build2_stat, at tree.c:3074 (extract_range_from_assert)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32453
[Bug tree-optimization/32453] [4.3 Regression] ICE in build2_stat, at tree.c:3074 (extract_range_from_assert)
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-21 11:26 --- Created an attachment (id=13756) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13756&action=view) testcase testcase from glibc, build with -O2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32453
