[Bug tree-optimization/19910] [4.2/4.3 regression] ICE with -ftree-loop-linear
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-06-18 06:01 --- This no longer crashes for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
[Bug tree-optimization/21485] [4.0/4.1/4.2/4.3 Regression] codegen regression due to PRE increasing register pressure (missing load PRE really)
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-06-18 06:12 --- This is basically fixed by the pointer_plus except we still have some combinable code (though this is not PRE's fault); see http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01996.html for how to fix that issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug middle-end/30784] [4.3 regression] ICE on loop vectorization (-O1 -march=athlon-xp -ftree-vectorize)
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-18 06:16 --- *** Bug 30958 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30784
[Bug tree-optimization/30958] [4.3 Regression] ice for legal code with -ftree-vectorize -Os (-m64)
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-18 06:16 --- *** This bug has been marked as a duplicate of 30784 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30958
[Bug tree-optimization/32383] [4.3 regression] ICE with reciprocals and -ffast-math
--- Comment #2 from ubizjak at gmail dot com 2007-06-18 06:41 --- Patch in testing. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-18 06:41:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32383
[Bug middle-end/32176] [4.3 Regression] ICE tree-type mismatch: expected integer_cst, have plus_expr in int_cst_value, at tree.c:7720
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-18 06:42 --- There is a cast which confuses SCEV. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32176
[Bug libstdc++/32354] libstdc++.so.6 missing RPATH
--- Comment #5 from stephan dot bergmann at sun dot com 2007-06-18 06:54 --- Re #3: http://gcc.gnu.org/onlinedocs/libstdc++/install.html#usage is not relevant here. That info is about how client code can find libstdc++.so. This issue is about how libstdc++.so can find the libraries it itself depends on. Re #4: Not sure I understand you completely. If you move libstdc++.so and libgcc_s.so somewhere else but keep their relative locations intact (i.e., both in the same directory), RPATH=$ORIGIN in libstdc++.so still works to locate the matching libgcc_s.so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32354
[Bug middle-end/20983] [4.0/4.1/4.2/4.3 Regression] varargs functions force va_list variable to stack unnecessarily
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-18 06:55 --- For -O1, it is even worse. I think we need to mark va_start/va_end as cannot call clober their inputs at the tree level. This should at least fix the -O1 issue. It might also help code gen in other cases which I am not thinking of currently. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20983
[Bug bootstrap/32334] Bootstrap comparison failure when comparing stage 2 and 3
--- Comment #2 from redriver at korea dot ac dot kr 2007-06-18 07:40 --- (In reply to comment #1) What version of GCC are you starting with? This works for me on an i686-linux-gnu machine (a pentium 4D). I think I found the problem. Previously, I use the gcc-3.2.2 to bootstrap the gcc-4.2.0. But when I used higher version of gcc (gcc-4.1.2) to bootstrap then there was no error. I think there is some incompatible between the two versions 3.2.2 and 4.2.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32334
[Bug tree-optimization/30175] [4.3 Regression] Runtime regressions with mem-ssa merge in Polyhedron and tramp3d-v4
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-18 07:54 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30175
[Bug fortran/20373] INTRINSIC symbols can be given the wrong type
--- Comment #13 from patchapp at dberlin dot org 2007-06-18 08:00 --- Subject: Bug number PR20373 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/msg01216.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20373
[Bug tree-optimization/32383] [4.3 regression] ICE with reciprocals and -ffast-math
--- Comment #3 from uros at gcc dot gnu dot org 2007-06-18 08:31 --- Subject: Bug 32383 Author: uros Date: Mon Jun 18 08:30:47 2007 New Revision: 125790 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125790 Log: PR tree-optimization/32383 * targhooks.c (default_builtin_reciprocal): Add new bool argument. * targhooks.h (default_builtin_reciprocal): Update prototype. * target.h (struct gcc_target): Update builtin_reciprocal. * doc/tm.texi (TARGET_BUILTIN_RECIPROCAL): Update description. * tree-ssa-math-opts (execute_cse_reciprocals): Skip statements where arg1 is not SSA_NAME. Pass true to targetm.builtin_reciprocal when fndecl is in BUILT_IN_MD class. (execute_convert_to_rsqrt): Ditto. * config/i386/i386.c (ix86_builtin_reciprocal): Update for new bool argument. Convert IX86_BUILTIN_SQRTPS code only when md_fn is true. Convert BUILT_IN_SQRTF code only when md_fn is false. testsuite/ChangeLog: PR tree-optimization/32383 * testsuite/g++.dg/opt/pr32383.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr32383.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/doc/tm.texi trunk/gcc/target.h trunk/gcc/targhooks.c trunk/gcc/targhooks.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32383
[Bug tree-optimization/32383] [4.3 regression] ICE with reciprocals and -ffast-math
--- Comment #4 from ubizjak at gmail dot com 2007-06-18 08:33 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32383
[Bug middle-end/31723] Use reciprocal and reciprocal square root with -ffast-math
--- Comment #29 from ubizjak at gmail dot com 2007-06-18 08:56 --- Patch was committed to SVN, so closing as fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723
[Bug target/32369] [frv] macro DF_LIVE_IN passed 2 arguments, but takes just 1
--- Comment #2 from patchapp at dberlin dot org 2007-06-18 09:55 --- Subject: Bug number PR target/32369 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/msg01225.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32369
[Bug tree-optimization/18219] [4.0/4.1/4.2/4.3 Regression] bloats code by 31%
--- Comment #25 from ubizjak at gmail dot com 2007-06-18 10:17 --- (In reply to comment #24) MEM[index: ivtmp.39, offset: 0x0fffc] = (MEM[index: ivtmp.35, offset: 0x0fffc] + 1 1) - MEM[index: ivtmp.39, offset: 0x0fffc]; We still get an offset of -4. PR target/24669 -- ubizjak at gmail dot com changed: What|Removed |Added BugsThisDependsOn||24669 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18219
[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 #2 from dorit at il dot ibm dot com 2007-06-18 11:03 ---
I see this in the vectorizer dump file (with mainline from a few days ago):
(compute_affine_dependence
(stmt_a =
D.3027_19 = p_7-a[D.3026_18])
(stmt_b =
p_7-a[D.3025_17] = D.3027_19)
Data ref a:
(Data Ref:
stmt: D.3027_19 = p_7-a[D.3026_18];
ref: p_7-a[D.3026_18];
base_object: p_7-a[0];
Access function 0: {x1_5 + 1, +, 1}_2
Access function 1: 0B
)
Data ref b:
(Data Ref:
stmt: p_7-a[D.3025_17] = D.3027_19;
ref: p_7-a[D.3025_17];
base_object: p_7-a[0];
Access function 0: {x1_5, +, 1}_2
Access function 1: 0B
)
affine dependence test not usable: access function not affine or constant.
(dependence classified: scev_not_known)
)
(In reply to comment #1)
Ok, I have a patch for this issue, I am going to test it with -ftree-vectorize
so how is that coming along? do you think it will also address PRs
32375/6/7/8/9 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32075
[Bug tree-optimization/32378] can't determine dependence (distinct sections of an array)
--- Comment #4 from dorit at il dot ibm dot com 2007-06-18 11:08 ---
I see this in the vectorizer dump file (with mainline from a few days ago):
(compute_affine_dependence
(stmt_a =
D.1423_50 = (*a_49(D))[D.1422_48])
(stmt_b =
(*a_49(D))[D.1420_51] = D.1425_54)
Data ref a:
(Data Ref:
stmt: D.1423_50 = (*a_49(D))[D.1422_48];
ref: (*a_49(D))[D.1422_48];
base_object: (*a_49(D))[0];
Access function 0: {pretmp.48_45 + 1, +, 1}_1
Access function 1: 0B
)
Data ref b:
(Data Ref:
stmt: (*a_49(D))[D.1420_51] = D.1425_54;
ref: (*a_49(D))[D.1420_51];
base_object: (*a_49(D))[0];
Access function 0: {0, +, 1}_1
Access function 1: 0B
)
affine dependence test not usable: access function not affine or constant.
(dependence classified: scev_not_known)
)
(compute_affine_dependence
(stmt_a =
D.1424_53 = (*b_52(D))[D.1420_51])
(stmt_b =
(*a_49(D))[D.1420_51] = D.1425_54)
)
(the IR looks a bit different than PR32075, but the data-rependence analysis
fails with the same problem). pinskia - are you still planning to address this
issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32378
[Bug c++/32350] Very high compile times for template code
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-18 11:26 --- Execution times (seconds) preprocessing : 0.09 ( 0%) usr 0.07 (20%) sys 0.18 ( 0%) wall 376 kB ( 1%) ggc parser: 0.26 ( 0%) usr 0.12 (34%) sys 0.45 ( 0%) wall 33574 kB (81%) ggc name lookup : 0.15 ( 0%) usr 0.13 (37%) sys 0.23 ( 0%) wall 3842 kB ( 9%) ggc tree gimplify : 13.72 (14%) usr 0.00 ( 0%) sys 13.71 (14%) wall 555 kB ( 1%) ggc expand: 81.23 (85%) usr 0.01 ( 3%) sys 81.26 (85%) wall 338 kB ( 1%) ggc varconst : 0.00 ( 0%) usr 0.01 ( 3%) sys 0.01 ( 0%) wall 128 kB ( 0%) ggc global alloc : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 36 kB ( 0%) ggc flow 2: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 34 kB ( 0%) ggc TOTAL : 95.48 0.3595.90 41385 kB -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||compile-time-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32350
[Bug tree-optimization/32353] [4.1/4.2 Regression] Miscompilation with RESULT_DECL
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-18 11:26:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32353
[Bug rtl-optimization/32366] [4.3 Regression] Segfault in significand_size with -ftree-vectorize
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-06-18 11:28 --- 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=32366
[Bug tree-optimization/32390] New: tree-ssa-math-opts.c performs too many IL scans
In tree-ssa-math-opts.c we already had a pass to cse sin and cos. The new reciprocal sqrt pass is mechanically similar to that one. It does a linear scan over the CFG applying these peephole transformations. This new pass should not be doing a separate IL scan to do its job. Perhaps it would be a good idea to do a single scan that calls back to all these transformations on every statement? I realize that each pass requires its own setup and may need to do things a bit differently, but perhaps we can save ourselves multiple IL scans if we generalize it a bit. -- Summary: tree-ssa-math-opts.c performs too many IL scans Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dnovillo at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32390
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #25 from dnovillo at gcc dot gnu dot org 2007-06-18 12:30 --- Fixed symptoms with http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01081.html. Real fix still being discussed. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added CC||amacleod at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug rtl-optimization/32372] [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4065
--- Comment #1 from zadeck at naturalbridge dot com 2007-06-18 12:33 --- I believe that the failure is due to a an insn illegally sharing with a reg_equal note. Insn 8 is modified in regmove. When this happens, the reg_equal note in insn 22 magically changes. That reg_equal note was changed last in cse. -- zadeck at naturalbridge dot com changed: What|Removed |Added AssignedTo|zadeck at naturalbridge dot |bonzini at gnu dot org |com | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-18 12:33:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32372
[Bug rtl-optimization/32372] [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4065
--- Comment #2 from zadeck at naturalbridge dot com 2007-06-18 12:35 --- s/cse/cse1/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32372
[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508
--- Comment #7 from patchapp at dberlin dot org 2007-06-18 12:40 --- Subject: Bug number PR target/32335 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/msg01233.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
[Bug target/32369] [frv] macro DF_LIVE_IN passed 2 arguments, but takes just 1
--- Comment #3 from zadeck at naturalbridge dot com 2007-06-18 13:18 --- Subject: Re: [frv] macro DF_LIVE_IN passed 2 arguments, but takes just 1 :reviewmail: patchapp at dberlin dot org wrote: --- Comment #2 from patchapp at dberlin dot org 2007-06-18 09:55 --- Subject: Bug number PR target/32369 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/msg01225.html ok for commit. thanks kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32369
[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508
--- Comment #8 from aesok at gcc dot gnu dot org 2007-06-18 13:33 --- Im working on patch for avr target. Anatoly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
[Bug tree-optimization/32390] tree-ssa-math-opts.c performs too many IL scans
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-18 13:56 --- All three transformations are done at different stages of the optimization pipeline due to various reasons. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32390
[Bug tree-optimization/32390] tree-ssa-math-opts.c performs too many IL scans
--- Comment #2 from dnovillo at google dot com 2007-06-18 14:00 --- Subject: Re: tree-ssa-math-opts.c performs too many IL scans On 6/18/07 9:56 AM, rguenth at gcc dot gnu dot org wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-18 13:56 --- All three transformations are done at different stages of the optimization pipeline due to various reasons. We need a better explanation than this. Uros agreed to summarize the IRC discussion to close this issue. It'd be useful if we keep that same discussion on the source code itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32390
[Bug fortran/32391] New: Default optimization (level 1) bug of loop optimization (maybe)
This bug occurs on gfortran 4.1 and 4.2 . I think it is not a gfortran specific bug; I checked g77 and g95 on gcc 3.4.6.. I had compiled a legacy fortran77 code and foud a bug; $ gfortran -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali Aligned length= 89, RMSD= 6.41, TM-score= 0.24257, ID=0.042 $ gfortran -O0 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali Aligned length= 91, RMSD= 6.35, TM-score=0.24762 , ID=0.024 $ pgf77 -O1 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali Aligned length= 91, RMSD= 6.35, TM-score=0.24762, ID= 0.024 $ pgf77 -O0 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali Aligned length= 91, RMSD= 6.35, TM-score=0.24762, ID=0.024 That optimization error is on a bellow subroutine; * Dynamic programming for alignment. * Input: score(i,j), and gap_open * Output: invmap(j) SUBROUTINE DP(NSEQ1,NSEQ2) PARAMETER(nmax=5000) LOGICAL*1 DIR common/dpc/score(nmax,nmax),gap_open,invmap(nmax) dimension DIR(0:nmax,0:nmax),VAL(0:nmax,0:nmax) REAL H,V *** initialize the matrix: val(0,0)=0 do i=1,nseq1 dir(i,0)=.false. val(i,0)=0 enddo do j=1,nseq2 dir(0,j)=.false. val(0,j)=0 invmap(j)=-1 enddo *** decide matrix and path: DO j=1,NSEQ2 DO i=1,NSEQ1 D=VAL(i-1,j-1)+SCORE(i,j) H=VAL(i-1,j) if(DIR(i-1,j))H=H+GAP_OPEN V=VAL(i,j-1) if(DIR(i,j-1))V=V+GAP_OPEN IF(( D.GE.H).AND.(D.GE.V)) THEN DIR(I,J)=.true. VAL(i,j)=D ELSE DIR(I,J)=.false. if(V.GE.H)then val(i,j)=v else val(i,j)=h end if ENDIF ENDDO ENDDO *** extract the alignment: i=NSEQ1 j=NSEQ2 DO WHILE((i.GT.0).AND.(j.GT.0)) IF(DIR(i,j))THEN invmap(j)=i i=i-1 j=j-1 ELSE H=VAL(i-1,j) if(DIR(i-1,j))H=H+GAP_OPEN V=VAL(i,j-1) if(DIR(i,j-1))V=V+GAP_OPEN IF( V.GE.H) THEN j=j-1 ELSE i=i-1 ENDIF ENDIF ENDDO c^^^Dynamical programming done ^^^ return END Files; http://zhang.bioinformatics.ku.edu/TM-align/TMalign.f http://zhang.bioinformatics.ku.edu/TM-align/benchmark/1aquA.pdb http://zhang.bioinformatics.ku.edu/TM-align/benchmark/1avaC.pdb -- Summary: Default optimization (level 1) bug of loop optimization (maybe) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sunjoong at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug c/25575] some uninitialized warning disappear when compile without -O
--- Comment #2 from matze at braunis dot de 2007-06-18 14:17 --- Why don't you turn on dataflow computation to get the warning even with -O0? -O0 is typically used for developing/debugging, so as a user I want to see all possible warnings... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25575
[Bug fortran/32391] Default optimization (level 1) bug of loop optimization (maybe)
--- Comment #1 from sunjoong at gmail dot com 2007-06-18 14:18 --- Created an attachment (id=13727) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13727action=view) A legacy fortran77 program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug fortran/32391] Default optimization (level 1) bug of loop optimization (maybe)
--- Comment #2 from sunjoong at gmail dot com 2007-06-18 14:19 --- Created an attachment (id=13728) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13728action=view) A input data file of TMalign -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug fortran/32391] Default optimization (level 1) bug of loop optimization (maybe)
--- Comment #3 from sunjoong at gmail dot com 2007-06-18 14:20 --- Created an attachment (id=13729) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13729action=view) A input data file of TMalign -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug target/32392] New: Support using -mrecip w/o additional Newton-Raphson run
Paolo Bonzini wrote: That said, there is a whole bunch of applications that would kill for -mrecip, even for 11bit ones. Games are one of them, for sure ;) What about -mrecip=0/1/2 for the number of NR steps? Or would two steps be slower than divss? I was thinking of adding this as a follow-up patch ;) Just look how the operations are grouped together. As Richard pointed out: Having two NR does not make sense. For some cases doing with out Newton-Raphson is enough. (Example: Games -- or SPEC CPU 2006: http://www.hpcwire.com/hpc/1556972.html) Other compilers have this option, e.g. Pathscale's -OPT:rsqrt=2 [yes, this is used for SPEC runs ;-)] -- Summary: Support using -mrecip w/o additional Newton-Raphson run Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org GCC target triplet: x86_64-*-* i686-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32392
[Bug fortran/32393] New: gfortran - incorrect run time results
This program runs Ok on the Macintosh versions of gfortran. It runs Ok on the i386-pc-mingw32 version of gfortran using -g, but fails using -O3. It always fails on the cygwin version of gfortran - gfortran -o g95Test01 g95Test01.f ./g95Test01 1 lower triangular matrix with 3 rows row 10.3214E-38 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.6428E-38 row 20.1000E+01 0.4000E+01 row 30.3000E+01 0.4000E+01 0.1000E+02 STOP 0 cat g95Test01.f *deck vr2 subroutine vr2 ( intp, ivg, ccrans, cc, ns, stdb, stdm, t, $ k2, nlin, istab ) save c+-+ c| master foutine for| c| second variation of the strain energy | c| at an integration point | c| | c| output quantities | c|t local accumulator for elt second variation| c|w global accumulator for elt second variatio| c+-+ c+-+ c| t y p ed i m e n s i o n | c+-+ character its1*4 character title*72 integert real cc, ctrans, dprod2, sdb, sdm, $ stdb, stdm, sum, ttt, uf, $ vf, wsf real tgc dimension cc(1),ccrans(1),ivg(1), stdb(1), stdm(1), $ t(100) c+-+ c| e q u i v a l e n c e s | c+-+ equivalence(jt,tt) c+-+ c| c o m m o ng l o b a l s | c+-+ common/comvd1/ jelt, jntp common/comvd2/ plva, plvb, lpr, iulpr,wplv(8) common/comvd3/ wsf(12,9),uf(20), vf(20) common/con5 / dmy(3), icom(18) common/corot1/ iadcor(30), lcor, kcor common/corot8/ ctrans(150) common/fmloc / jf(6),js(6),jp(6),l1, l2, $ l3, l4, l5, l6 common/forms / mtrans(40), itrans(150),sdb(540), $ sdm(1008),npform common/hybcom/ ihyb, ihres(9), ttt(78) common/nitnot/ nit, not common/prec / iprec common/scrat1/ w(600) common/test / ktest common/titcom/ title common/vr410c/ tgc(3,3,4) common/vrdat / np, np1, np2, np3, np4, $ np5, np6, np7, np8, np9, $ np10 common/vrdat1/ nmsh, ntyp, nods, neta, nitp, $ nst, ntr, nmp, nth, nvg, $ nvl, nvb, nvm, nvr2, idvr, $ ifab common a(100) c+-+ c| d a t a | c+-+ data its1 / 'dbug' / c+-+ c| l o g i c | c+-+ ielt=jelt npr=iprec npd=3-npr nvr2 = 1 if(intp.gt.1) go to 20 c+-+ c| begin new element | c+-+ nj=nvg+5 nn=nvg+4+(nvg*nvg+nvg)/npd nnl=nvg+4+(nvl*nvl+nvl)/npd t(1)=nvg t(4)=1 call mover (ivg,1,t(5),1,nvg) if(k2.eq.0.or.nvr2.gt.0) go to 5 if(istab.eq.1.or.nlin.eq.1) go to 5 return 5 continue c+-+ c| clear t for element stiffness matrix| c+-+ call mover (0.,0,t,1,nnl) t(1)=nvg t(4)=1 call mover (ivg,1,t(5),1,nvg) c nl1 = nvl if(lpr+iulpr.gt.0) nl1=nvl 20 continue
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #1 from dir at lanl dot gov 2007-06-18 14:48 --- Here are the mingw32 results - $ gfortran -g -o g95Test01 g95Test01.f [EMAIL PROTECTED] ~/tests $ g95Test01 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 g95Test01 g95Test01.f [EMAIL PROTECTED] ~/tests $ g95Test01 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 $ cat g95Test01.f *deck vr2 subroutine vr2 ( intp, ivg, ccrans, cc, ns, stdb, stdm, t, $ k2, nlin, istab ) save c+-+ c| master foutine for| c| second variation of the strain energy | c| at an integration point | c| | c| output quantities | c|t local accumulator for elt second variation| c|w global accumulator for elt second variatio| c+-+ c+-+ c| t y p ed i m e n s i o n | c+-+ character its1*4 character title*72 integert real cc, ctrans, dprod2, sdb, sdm, $ stdb, stdm, sum, ttt, uf, $ vf, wsf real tgc dimension cc(1),ccrans(1),ivg(1), stdb(1), stdm(1), $ t(100) c+-+ c| e q u i v a l e n c e s | c+-+ equivalence(jt,tt) c+-+ c| c o m m o ng l o b a l s | c+-+ common/comvd1/ jelt, jntp common/comvd2/ plva, plvb, lpr, iulpr,wplv(8) common/comvd3/ wsf(12,9),uf(20), vf(20) common/con5 / dmy(3), icom(18) common/corot1/ iadcor(30), lcor, kcor common/corot8/ ctrans(150) common/fmloc / jf(6),js(6),jp(6),l1, l2, $ l3, l4, l5, l6 common/forms / mtrans(40), itrans(150),sdb(540), $ sdm(1008),npform common/hybcom/ ihyb, ihres(9), ttt(78) common/nitnot/ nit, not common/prec / iprec common/scrat1/ w(600) common/test / ktest common/titcom/ title common/vr410c/ tgc(3,3,4) common/vrdat / np, np1, np2, np3, np4, $ np5, np6, np7, np8, np9, $ np10 common/vrdat1/ nmsh, ntyp, nods, neta, nitp, $ nst, ntr, nmp, nth, nvg, $ nvl, nvb, nvm, nvr2, idvr, $ ifab common a(100) c+-+ c| d a t a | c+-+ data its1 / 'dbug' / c+-+ c| l o g i c | c+-+ ielt=jelt npr=iprec npd=3-npr nvr2 = 1 if(intp.gt.1) go to 20 c+-+ c| begin new element | c+-+ nj=nvg+5 nn=nvg+4+(nvg*nvg+nvg)/npd nnl=nvg+4+(nvl*nvl+nvl)/npd t(1)=nvg t(4)=1 call mover (ivg,1,t(5),1,nvg) if(k2.eq.0.or.nvr2.gt.0) go to 5 if(istab.eq.1.or.nlin.eq.1) go to 5 return 5
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #2 from dominiq at lps dot ens dot fr 2007-06-18 14:52 --- Compiling your code with g95 gives a lot of warnings. You should probably check the use of the different subroutines. In file pr32393.f:189 subroutine clect2 1 In file pr32393.f:155 call clect2 (t(nj),w(nj),nvg,nl1,mtrans,ctrans,itrans) 2 Warning (154): Inconsistent number of arguments in reference to 'clect2' at (1) and (2) In file pr32393.f:168 call prmx(t(nj),nvg) 1 In file pr32393.f:201 subroutine prmx (a,n) 2 Warning (155): Inconsistent types (INTEGER(4)/REAL(4)) in actual argument lists at (1) and (2) In file pr32393.f:156 call prmx(t(nj),nvg) 1 In file pr32393.f:201 subroutine prmx (a,n) 2 Warning (155): Inconsistent types (INTEGER(4)/REAL(4)) in actual argument lists at (1) and (2) In file pr32393.f:140 if (title(1:4).eq.its1 .and. ielt.le.4) call prmx(t(nj),nvg) 1 In file pr32393.f:201 subroutine prmx (a,n) 2 Warning (155): Inconsistent types (INTEGER(4)/REAL(4)) in actual argument lists at (1) and (2) In file pr32393.f:133 call prmx (t(nj),nvl) 1 In file pr32393.f:201 subroutine prmx (a,n) 2 Warning (155): Inconsistent types (INTEGER(4)/REAL(4)) in actual argument lists at (1) and (2) In file pr32393.f:195 subroutine mover 1 In file pr32393.f:154 call mover (0.,0,t(nj),1,nj1) 2 Warning (154): Inconsistent number of arguments in reference to 'mover' at (1) and (2) In file pr32393.f:192 subroutine mid2 1 In file pr32393.f:139 call mid2 (4,tgc,t(nj),t(nj)) 2 Warning (154): Inconsistent number of arguments in reference to 'mid2' at (1) and (2) In file pr32393.f:198 subroutine penal 1 In file pr32393.f:120 if(ntyp.eq.411) call penal(a(ll),istab,t(nj)) 2 Warning (154): Inconsistent number of arguments in reference to 'penal' at (1) and (2) In file pr32393.f:230 subroutine scprod 1 In file pr32393.f:101 call scprod (ns*ns,1,1,cc,cc,sum) 2 Warning (154): Inconsistent number of arguments in reference to 'scprod' at (1) and (2) In file pr32393.f:227 subroutine scopu 1 In file pr32393.f:152 210 call scopu (nnl,t,w) 2 Warning (154): Inconsistent number of arguments in reference to 'scopu' at (1) and (2) In file pr32393.f:236 subroutine vr22d 1 In file pr32393.f:112 if (idvr.eq.2) call vr22d (cc,ns,stdb,stdm,nlin,istab,t,t(nj)) 2 Warning (154): Inconsistent number of arguments in reference to 'vr22d' at (1) and (2) In file pr32393.f:233 subroutine vr21d 1 In file pr32393.f:108 if (idvr.eq.1) call vr21d (cc,ns,stdb,nlin,istab,t) 2 Warning (154): Inconsistent number of arguments in reference to 'vr21d' at (1) and (2) In file pr32393.f:185 call vr2 ( intp, ivg, ccrans, cc, ns, stdb, stdm, t, 1 In file pr32393.f:2 cc, ns, stdb, stdm, t, 2 Warning (155): Inconsistent types (REAL(4)/INTEGER(4)) in actual argument lists at (1) and (2) In file pr32393.f:239 subroutine vr23d 1 In file pr32393.f:116 if (idvr.eq.3) call vr23d (cc,ns,stdm,nlin,istab,t) 2 Warning (154): Inconsistent number of arguments in reference to 'vr23d' at (1) and (2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug other/32351] Wrong DFP format is used in libdecnumber
--- Comment #1 from hjl at lucon dot org 2007-06-18 15:02 --- Fixed by http://gcc.gnu.org/ml/gcc-cvs/2007-06/msg00569.html -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32351
[Bug target/32392] Support using -mrecip w/o additional Newton-Raphson run
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-18 15:03 --- Initial suggestion, see: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01068.html Richard's remark: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01224.html Two NR steps don't make sense, they wouldn't improve accuracy because of the extra roundings we get for the NR. And of course it would be slower. (However, two NR are said to be enough for double precision. I don't know whether doing rsqrt+(2x NR) is faster than 1/sqrt() for double or not.) Related - closed - PRs: PR 31723 - Use reciprocal and reciprocal square root with -ffast-math (FIXED) PR 32352 - Using rsqrt, Polyhedron's aermod test crashes (WONTFIX) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32392
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #3 from dir at lanl dot gov 2007-06-18 15:05 --- The only subroutine actually used is prmx. The rest are dummies to make the linker happy. With g95, you get the correct results with -g and incorrect results with -O3 - [QuadG5:~/junk] dir% g95 -O3 -d8 -fstatic -Wno=121,155,154 -o g95Test01 g95Test01.f [QuadG5:~/junk] dir% g95Test01 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 [QuadG5:~/junk] dir% g95 -g -d8 -fstatic -Wno=121,155,154 -o g95Test01 g95Test01.f [QuadG5:~/junk] dir% g95Test01 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 [QuadG5:~/junk] dir% g95 --v Using built-in specs. Target: Configured with: ../configure --enable-languages=c Thread model: posix gcc version 4.0.3 (g95 0.91!) Jun 4 2007 [QuadG5:~/junk] dir% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug fortran/32391] Generate wrong optimization code from fortran 77
--- Comment #4 from sunjoong at gmail dot com 2007-06-18 15:08 --- Thank you, Tobias I had missunderstood the default optimization level for gfortran but the issue exists, I think. I had traced side effects of optimization levels for the legacy program; -O0 level and -O1 level were different but from -O1 to -O3 gave same (wrong) results on gfortran, g77 and g95. I tested it with pgi fortran and got same (right) results. I checked gfortran 4.0.4, 4.1.2 and 4.2.0. I did not check gfortran 4.3. 2007/6/18, Tobias Burnus [EMAIL PROTECTED]: Sunjoong Lee wrote: I had compiled a legacy fortran77 code and foud a bug; $ gfortran -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali Aligned length= 89, RMSD= 6.41, TM-score= 0.24257, ID=0.042 $ gfortran -O0 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali Aligned length= 91, RMSD= 6.35, TM-score=0.24762 , ID=0.024 I find this difference very odd as -O0 is the default optimization for gfortran. Other than that I get always the same result (91) with all -O levels I tried with gfortran 4.3, 4.2.0, 4.1.3 and ifort. Which version of the compiler are you using on which platform. (Use gfortran -v to shows this information.) Can you also show what alias gfortran (or type gfortran) shows? Just to make sure there is no alias which adds options. Tobias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #4 from dominiq at lps dot ens dot fr 2007-06-18 15:29 --- The only subroutine actually used is prmx. The rest are dummies to make the linker happy. One thing which is obviously wrong is that 't' is declared as integer in vr2, but is real in the calling program and in the prmx subroutine. Now I don't know how the compiler is supposed to behave when there is a mismatch between the arguments in the subroutines and their call. I suspect that the code is badly invalid and as such can produce any result (as it is the case). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug fortran/32391] Generate wrong optimization code on fortran 77
--- Comment #5 from dominiq at lps dot ens dot fr 2007-06-18 15:38 --- I did not make as many tests as Tobias, but it works for me on PPC with g77, xlf, g95, and gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug fortran/32391] Generate wrong optimization code on fortran 77
--- Comment #6 from sunjoong at gmail dot com 2007-06-18 16:07 --- Thanks again, Tobias $ uname -a Linux newton 2.6.12-gentoo-r10 #1 Sun Sep 4 13:29:37 KST 2005 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --enable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2) I had tested it with this step; $ gfortran -O0 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali $ gfortran -O1 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali $ wget -O - http://ftp.g95.org/g95-x86-linux.tgz | tar xvfz - $ export PATH=$PATH:./g95-install/bin $ g95 -O0 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali $ g95 -O1 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali $ emerge =sys-devel/gcc-4.2.0 # install gcc-4.2.0 and gfortran $ gcc-config i686-pc-linux-gnu-4.2.0 $ source /etc/profile $ epm -e =sys-devel/gcc-4.1.2 # remove gcc-4.1.2 $ gfortran -O0 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali $ gfortran -O1 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali $ emerge =sys-devel/gcc-4.0.4 # install gcc-4.0.4 and gfortran $ gcc-config i686-pc-linux-gnu-4.0.4 $ source /etc/profile $ epm -e =sys-devel/gcc-4.2.0 # remove gcc-4.2.0 $ gfortran -O0 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali $ gfortran -O1 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali After then, I loged in another machine; $ uname -a Linux gene.kias.re.kr 2.6.3-gene #3 SMP Wed Jan 19 00:10:01 KST 2005 i686 unknown unknown GNU/Linux $ g77 -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.2/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,ada,f77,objc,java,pascal --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk) $ g77 -O0 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali $ g77 -O1 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali $ pgf77 -O0 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali $ pgf77 -O1 -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali Which do you think the reson for this difference be for fortran compiler or c compiler? 2007/6/19, Tobias Burnus [EMAIL PROTECTED]: As said: It works here with 4.1.3 20070521, 4.2.1 20070604 and 20070618, 4.3.0 20070618. It also work with my g95, Intel Fortran and sunf95 compilers. In all cases I get: Aligned length= 91, RMSD= 6.35, TM-score=0.24762, ID=0.024 I'm on x86_64-unknown-linux-gnu (openSUSE Factory) and it works both in 32 and 64 bit mode with no option, -O0, -O1, -O2, -O3, -O3 -ffast-math. What is your platform (CPU type and operating system) and what is your exact version of gfortran? (Both information is shown by gfortran -v.) (You are really only using -O1 and not any other flags, are you?) Tobias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #5 from burnus at gcc dot gnu dot org 2007-06-18 16:15 --- Now I don't know how the compiler is supposed to behave when there is a mismatch between the arguments in the subroutines and their call. Well it is always said that it may do anything such as starting the third world war; however, I think the program is only allowed to produce wrong results, to overwrite/delete any file and to crash ;-) NAG f95 fails to compile the program with the errors: Error: g95Test01.f, line 86: Inconsistent datatype for arg 1 in call to MOVER Error: g95Test01.f, line 152: Inconsistent datatype for arg 2 in call to SCOPU Error: g95Test01.f, line 154: Inconsistent datatype for arg 1 in call to MOVER For gfortran such a whole-file check is planned (http://gcc.gnu.org/wiki/GFortran43). Close as INVALID. If the problem also occurs with a valid Fortran program, feel free to re-open this bug. (Please attach longer programs, if you include them inline the report gets a bit messy.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug fortran/20441] -finit-local-zero is missing from gfortran
-- langton at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |langton at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-12-18 01:54:45 |2007-06-18 16:23:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20441
[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu
--- Comment #7 from burnus at gcc dot gnu dot org 2007-06-18 16:38 --- $ gfortran -v Target: i686-pc-linux-gnu gcc version 4.1.2 (Gentoo 4.1.2) I can reproduce this on my Pentium M (openSUSE 10.2) with Target: i586-suse-linux gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) and with FX's Target: i386-pc-linux-gnu gcc version 4.3.0 20070618 (experimental) Interestingly, it works on x86_64-unknown-linux-gnu even with -m32. (I somehow fail to run FX's i386 compiler on x86-64.) I think this could be a middle-end or target problem as it is that target dependent. On the other hand, gfortran (and g95) could simply produce a wrong generic code. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.2 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-06-18 16:38:39 date|| Summary|Generate wrong optimization |Wrong code with optimization |code on fortran 77 |on i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug rtl-optimization/32355] [4.3 Regression] ICE in df_lr_verify_transfer_functions, at df-problems.c:1924
--- Comment #3 from zadeck at gcc dot gnu dot org 2007-06-18 16:47 --- Subject: Bug 32355 Author: zadeck Date: Mon Jun 18 16:47:05 2007 New Revision: 125812 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125812 Log: 2007-06-18 Kenneth Zadeck [EMAIL PROTECTED] PR middle-end/32355 * gcse (rest_of_handle_gcse): Add call to df_finish_pass after cse_main. * df-problems.c (df_note_bb_compute): Fix dumping info. 2007-06-18 Kenneth Zadeck [EMAIL PROTECTED] * gcc.c-torture/compile/pr32355.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32355.c Modified: trunk/gcc/ChangeLog trunk/gcc/df-problems.c trunk/gcc/gcse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32355
[Bug rtl-optimization/32355] [4.3 Regression] ICE in df_lr_verify_transfer_functions, at df-problems.c:1924
--- Comment #4 from zadeck at naturalbridge dot com 2007-06-18 16:48
---
Subject: Re: [4.3 Regression] ICE in df_lr_verify_transfer_functions,
at df-problems.c:1924
committed as revision 125812
zadeck at naturalbridge dot com wrote:
--- Comment #1 from zadeck at naturalbridge dot com 2007-06-17 20:13
---
Subject: Re: [4.3 Regression] ICE in df_lr_verify_transfer_functions,
at df-problems.c:1924
There are possibly two problems here. Fixing the first one fixes this ice.
The first problem is that after a call to cse_main, a call to
df_finish_pass is needed to get out of deferred rescanning mode and get
everything up to date.
The possible second problem is that something in one of
delete_trivially_dead_insns
rebuild_jump_labels
cleanup_cfg
may not work in deferred rescanning mode. This will wait for another
bug report.
It is too hard to debug this without first cleaning up what cse_main did
and that makes the bug go away.
ok to commit?
Kenny
2007-06-17 Kenneth Zadeck [EMAIL PROTECTED]
PR middle-end/32355
* gcse (rest_of_handle_gcse): Add call to df_finish_pass after
cse_main.
* df-problems.c (df_note_bb_compute): Fix dumping info.
2007-06-17 Kenneth Zadeck [EMAIL PROTECTED]
* gcc.c-torture/compile/pr32355.c: New testcase.
Index: testsuite/gcc.c-torture/compile/pr32355.c
===
--- testsuite/gcc.c-torture/compile/pr32355.c (revision 0)
+++ testsuite/gcc.c-torture/compile/pr32355.c (revision 0)
@@ -0,0 +1,33 @@
+/* { dg-options -O3 } */
+
+typedef struct
+{
+}
+__sigset_t;
+typedef struct
+{
+char coredump;
+}
+EMode;
+extern EMode Mode;
+struct sigaction
+{
+ __sigset_t sa_mask;
+ int sa_flags;
+};
+doSignalsSetup (void)
+{
+ static const int signals[] = {
+1, 2 , 3, 4, 6, 8, 11, 13, 14, 15, 10, 12, 17, 7
+ };
+ unsigned int i, sig;
+ struct sigaction sa;
+ for (i = 0; i sizeof (signals) / sizeof (int); i++)
+{
+ sig = signals[i];
+ if (Mode.coredump (sig == 4 || sig == 8))
+continue;
+ sa.sa_flags = (sig == 17);
+ sigemptyset (sa.sa_mask);
+}
+}
Index: gcse.c
===
--- gcse.c (revision 125777)
+++ gcse.c (working copy)
@@ -6704,6 +6704,7 @@ rest_of_handle_gcse (void)
{
timevar_push (TV_CSE);
tem2 = cse_main (get_insns (), max_reg_num ());
+ df_finish_pass ();
purge_all_dead_edges ();
delete_trivially_dead_insns (get_insns (), max_reg_num ());
timevar_pop (TV_CSE);
Index: df-problems.c
===
--- df-problems.c (revision 125777)
+++ df-problems.c (working copy)
@@ -3867,8 +3867,10 @@ df_note_bb_compute (unsigned int bb_inde
for (def_rec = df_get_artificial_defs (bb_index); *def_rec; def_rec++)
{
struct df_ref *def = *def_rec;
+#ifdef REG_DEAD_DEBUGGING
if (dump_file)
fprintf (dump_file, artificial def %d\n, DF_REF_REGNO (def));
+#endif
if ((DF_REF_FLAGS (def) DF_REF_AT_TOP) == 0)
bitmap_clear_bit (live, DF_REF_REGNO (def));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32355
[Bug rtl-optimization/32355] [4.3 Regression] ICE in df_lr_verify_transfer_functions, at df-problems.c:1924
--- Comment #5 from zadeck at naturalbridge dot com 2007-06-18 16:50 --- fixed,revision 125812 -- zadeck at naturalbridge dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32355
[Bug rtl-optimization/32394] New: some operations to not work properly in df_deferred_rescan mode.
At least one of these three calls do not work properly in deferred rescanning mode. delete_trivially_dead_insns rebuild_jump_labels cleanup_cfg The most likely cause of the failure is that we are not keeping enough information around in the deferred scanning mode to properly track all of the kinds of changes that these functions make. Currently we only track, changed insns, changed eq notes, and deleted insns. Basicblock renaming, creation and destruction is always done in real time. However it is likely that this gets out of sync with the deferred operations. With the resolution of pr32355, these calls are only made in regular mode. -- Summary: some operations to not work properly in df_deferred_rescan mode. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: bonzini at gnu dot org ReportedBy: zadeck at naturalbridge dot com GCC host triplet: any http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32394
[Bug c++/32395] New: false positive warning about use of uninitialized variable.
gcc-4.1 produces a warning for the following testcase.
(testcase uses headers from boost-1.34.0).
$ cat multi_index_test.cpp
#include boost/multi_index_container.hpp
#include boost/multi_index/ordered_index.hpp
#include boost/multi_index/identity.hpp
#include boost/multi_index/member.hpp
#include vector
using namespace boost;
using namespace boost::multi_index;
struct X
{
int value;
bool operator ( X const e) const;
};
typedef multi_index_container
X,
indexed_by
ordered_unique identity X ,
ordered_non_unique member X, int, X::value
C;
extern
C f( std::vector X const v )
{
return C( v.begin(), v.end() );
}
$ x86_64-gnu-linux-g++ \
-I/local/devel/buildenv41/x86_64-gnu-linux/boost-stdc++-1.34.0/include \
multi_index_test.cpp -O1 -Wall --save-temps -c
/local/devel/buildenv41/x86_64-gnu-linux/boost-stdc++-1.34.0/include/boost/multi_index/ordered_index.hpp:
In member function 'std::pairtypename
boost::multi_index::detail::multi_index_base_typeValue, IndexSpecifierList,
Allocator::type::node_type*, bool
boost::multi_index::multi_index_containerValue, IndexSpecifierList,
Allocator::insert_(const Value, typename
boost::multi_index::detail::multi_index_base_typeValue, IndexSpecifierList,
Allocator::type::node_type*) [with Value = X, IndexSpecifierList =
boost::multi_index::indexed_byboost::multi_index::ordered_uniqueboost::multi_index::identityX,
mpl_::na, mpl_::na,
boost::multi_index::ordered_non_uniqueboost::multi_index::memberX, int,
X::value, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, Allocator =
std::allocatorX]':
/local/devel/buildenv41/x86_64-gnu-linux/boost-stdc++-1.34.0/include/boost/multi_index/ordered_index.hpp:566:
warning:
'inf.boost::multi_index::detail::ordered_indexboost::multi_index::identityX,
std::lessX, boost::multi_index::detail::nth_layer1, X,
boost::multi_index::indexed_byboost::multi_index::ordered_uniqueboost::multi_index::identityX,
mpl_::na, mpl_::na,
boost::multi_index::ordered_non_uniqueboost::multi_index::memberX, int,
X::value, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, std::allocatorX
, boost::mpl::vector0mpl_::na,
boost::multi_index::detail::ordered_unique_tag::link_info::side' may be used
uninitialized in this function
as far i can the warning comes from:
bool link_point(key_param_type k,link_info inf,ordered_unique_tag)
{
(...)
else{
inf.pos=yy-impl(); == partial initialziation of link_info.
return false;
}
}
in fact, all use cases of link_point use only inf.pos
when {hinted_,}link_point returns false.
(...)
if(!link_point(key(v),inf,Category())){
return node_type::from_impl(inf.pos);
(...)
node_type* insert_(value_param_type v,node_type* position,node_type* x)
{
link_info inf;
if(!hinted_link_point(key(v),position,inf,Category())){
return node_type::from_impl(inf.pos);
(...)
gcc-3.4.5 and 4.2 works fine (no warning), but 4.1.2 fails.
4.0 and 4.3 wasn't tested.
--
Summary: false positive warning about use of uninitialized
variable.
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
[Bug c++/32395] false positive warning about use of uninitialized variable.
--- Comment #1 from pluto at agmk dot net 2007-06-18 17:25 --- Created an attachment (id=13730) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13730action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu
--- Comment #8 from sunjoong at gmail dot com 2007-06-18 17:26 --- I checked which part of TMalign.f make optimizaton wrong; In DP subroutine, DO j=1,NSEQ2 DO i=1,NSEQ1 D=VAL(i-1,j-1)+SCORE(i,j) H=VAL(i-1,j) if(DIR(i-1,j))H=H+GAP_OPEN V=VAL(i,j-1) if(DIR(i,j-1))V=V+GAP_OPEN IF((D.GE.H).AND.(D.GE.V)) THEN DIR(I,J)=.true. VAL(i,j)=D ELSE DIR(I,J)=.false. if(V.GE.H)then val(i,j)=v else val(i,j)=h end if ENDIF ENDDO ENDDO -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #9 from daney at gcc dot gnu dot org 2007-06-18 17:36 --- Subject: Bug 32313 Author: daney Date: Mon Jun 18 17:36:42 2007 New Revision: 125818 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125818 Log: PR target/32313 * config/mips/mips.c (mips_expand_call): Mark $gp as used by local function call. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug tree-optimization/32390] tree-ssa-math-opts.c performs too many IL scans
--- Comment #3 from ubizjak at gmail dot com 2007-06-18 17:40 --- (In reply to comment #2) We need a better explanation than this. Uros agreed to summarize the IRC discussion to close this issue. It'd be useful if we keep that same discussion on the source code itself. The need for separate IL passes could be explained by: We have reciprocal pass (in fact CSE recip pass) that CSEs 1.0/z from x/z, y/z, .../z. This is done by scanning function for RDIV_EXPR, where denominator (z) is the same. If 1.0/func() - rfunc() conversion is done before recip pass, we loose the ability to scan for RDIV_EXPRs and the ability to CSE the division. By putting 1.0/func()-rfunc() after recip pass, we simply run another scan for RDIV_EXPRs with function as their argument. Note that we already CSE'd 1.0/func(), so the conversion into rfunc() is trivial. This is the reason why function recip pass needs to run after recip (aka CSE recip) pass. Next convesion is sqrt(a/b) - rsqrt(b/a) conversion that runs after rfunc recip pass as a separate pass (so, in the function granulartiy). If this pass is run together or before rfunc pass, then rsqrt pass would convert expressions like 1.0/sqrt(a/b) into 1.0/rsqrt(b/a). There is no point for rfunc pass (that would follow) to convert this to sqrt(b/a). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32390
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #10 from daney at gcc dot gnu dot org 2007-06-18 17:41 --- The ability to bootstrap is fixed by the patch. There are other dataflow regressions that will be fixed by follow up patches. -- 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=32313
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #6 from dir at lanl dot gov 2007-06-18 18:13 --- Now I don't know how the compiler is supposed to behave when there is a mismatch between the arguments in the subroutines and their call. I do - since the beginning of FORTRAN, well, at least since FORTRAN 2, it simply passes the starting address down for simple data types. I have worked several commercial finite element codes over the years and at least half of them call routines with wrong data type for various reasons - to do extremely efficient low cost dynamic memory management, to create objects, to overload modules, to do multiple inheritance, etc... Fortran 90 has not always been around to do these things legally. That is all not relevant anyway, if you would look at the output, you would realize that the only this wrong is that the loop - do 242 i=1,nvg j2=jj+iprec*(i-1) c+-+ c| multiply main diagonals by 2| c+-+ jt=t(j2) tt=tt+tt t(j2)=jt 242 jj=jj+iprec*i does not compile correctly - The program prints the data before and after the loop. If you look at the assembly language output for that loop, it is incorrect for O2. I make a quick try at pulling it out of the routine, but that fail - so I just submitted the whole routine as I had already spent several hours eliminated the other 100,000 lines of code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu
--- Comment #9 from sunjoong at gmail dot com 2007-06-18 18:31 --- I cut the bellow and made a new subroutine, then another part did not change on '-O0' and '-O1'; D=VAL(i-1,j-1)+SCORE(i,j) H=VAL(i-1,j) if(DIR(i-1,j))H=H+GAP_OPEN V=VAL(i,j-1) if(DIR(i,j-1))V=V+GAP_OPEN IF((D.GE.H).AND.(D.GE.V)) THEN DIR(I,J)=.true. VAL(i,j)=D ELSE DIR(I,J)=.false. if(V.GE.H)then val(i,j)=v else val(i,j)=h end if ENDIF -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu
--- Comment #10 from kargl at gcc dot gnu dot org 2007-06-18 18:36 --- There are literal hundreds of warning given by ftnchek, and there appears to be an array bounds problem. troutmask:sgk[231] gfc4x -o z -O -fbounds-check TMalign.f troutmask:sgk[232] ./z 1aquA.pdb 1avaC.pdb | grep RMSD At line 2122 of file TMalign.f Fortran runtime error: Array reference out of bounds for array 'w', upper bound +of dimension 1 exceeded -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #7 from dominiq at lps dot ens dot fr 2007-06-18 18:44 --- I do ... I am not in the position to argue about what f90 compilers are supposed to do with the original code. I just attach a modified one I hope is valid: g95 does not complain and gives: karma] f90/bug% bg95 pr32393_db.f [karma] f90/bug% a.out 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 [karma] f90/bug% bg95 -O3 pr32393_db.f [karma] f90/bug% a.out 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 as does xlf. On the other hand gfortran gives: [karma] f90/bug% gfc pr32393_db.f [karma] f90/bug% a.out 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 [karma] f90/bug% gfc -O3 pr32393_db.f [karma] f90/bug% a.out 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 So if the attached code is deemed valid there is indeed a bug in gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #8 from dominiq at lps dot ens dot fr 2007-06-18 18:46 --- Created an attachment (id=13731) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13731action=view) valid test case(?) I have removed the dummy subroutines and type mismatch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu
--- Comment #11 from sunjoong at gmail dot com 2007-06-18 18:47 --- Yes, I agree that program is not beautiful and I know the the array 'w' of 'u3b' subroutine problem; I think the author of u3b use w(1) as pointer. However, the wrong generation of optimized code occurs in 'DP' subroutine. The array of DP have fixed boundary. (In reply to comment #10) There are literal hundreds of warning given by ftnchek, and there appears to be an array bounds problem. troutmask:sgk[231] gfc4x -o z -O -fbounds-check TMalign.f troutmask:sgk[232] ./z 1aquA.pdb 1avaC.pdb | grep RMSD At line 2122 of file TMalign.f Fortran runtime error: Array reference out of bounds for array 'w', upper bound +of dimension 1 exceeded -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug fortran/20373] INTRINSIC symbols can be given the wrong type
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-06-18 19:02 --- Updated patch. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||06/msg01263.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20373
[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu
--- Comment #12 from kargl at gcc dot gnu dot org 2007-06-18 19:16 --- (In reply to comment #11) Yes, I agree that program is not beautiful and I know the the array 'w' of 'u3b' subroutine problem; I think the author of u3b use w(1) as pointer. Change the 1 to *. However, the wrong generation of optimized code occurs in 'DP' subroutine. The array of DP have fixed boundary. Do you get wrong results if you add the -ffloat-store option? Can you also try the -fdefault-real-8 option? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #11 from daney at gcc dot gnu dot org 2007-06-18 19:35 --- Subject: Bug 32313 Author: daney Date: Mon Jun 18 19:35:05 2007 New Revision: 125824 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125824 Log: Revert: 2007-06-18 David Daney [EMAIL PROTECTED] PR target/32313 * config/mips/mips.c (mips_expand_call): Mark $gp as used by local function call. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #12 from daney at gcc dot gnu dot org 2007-06-18 19:35 --- That fix was incorrect. Sorry. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #13 from daney at gcc dot gnu dot org 2007-06-18 19:39 --- This is the same problem as: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01165.html I am currently bootstrapping the patch in that e-mail thread and will probably commit that version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726
--- Comment #7 from spark at gcc dot gnu dot org 2007-06-18 20:02 --- Subject: Bug 32339 Author: spark Date: Mon Jun 18 20:02:33 2007 New Revision: 125825 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125825 Log: gcc/ChangeLog: 2007-06-18 Seongbae Park [EMAIL PROTECTED] PR rtl-optimization/32339 * df-scan.c (df_uses_record): Don't modify flags but just add to it for df_ref_record. gcc/testsuite/ChangeLog: 2007-06-18 Martin Michlmayr [EMAIL PROTECTED] PR rtl-optimization/32339 * gcc.c-torture/compile/pr32339.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32339.c Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32339
[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu
--- Comment #13 from sunjoong at gmail dot com 2007-06-18 20:24 --- The '-ffloat-store' option works! Thank you. However that gave me some quenstions; Is that feature or bug? There is many floating point operations of course. Why the only one specific resion make problem? That is not set when optimize. So, what's the disadvantage and why the 'fortran' with many floating point operation dosn't take it when optimize? Why x86 need that option but x86_64 or PPC do not need? (In reply to comment #12) Do you get wrong results if you add the -ffloat-store option? Can you also try the -fdefault-real-8 option? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
Size of C/C++ data type from GNU GCC/g++ compiled ELF 64-bit LSB executable, AMD x86-64 vs. ELF 32-bit LSB executable, Intel 80386
Hi, I need experts to shed light on C/C++ data type size inconsistencies when running 64-bit and 32-bit ELF executables compiled by GNU/GCC g++/gcc Following are results of C/C++ data type size from code cout data type sizeof(data type) endl : | 32-bit | 64-bit --- int |4 |4 --- long int |4 |8 --- signed long int |4 |4 --- ulong |4 |8 (sys/types.h) --- long double |12 |16 Thank in advance, Tom -- View this message in context: http://www.nabble.com/Size-of-C-C%2B%2B-data-type-from-GNU-GCC-g%2B%2B-compiled-ELF-64-bit-LSB-executable%2C-AMD-x86-64-vs.-ELF-32-bit-LSB-executable%2C-Intel-80386-tf3942710.html#a11183699 Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu
--- Comment #14 from kargl at gcc dot gnu dot org 2007-06-18 20:47 --- (In reply to comment #13) The '-ffloat-store' option works! Thank you. However that gave me some quenstions; Is that feature or bug? It is a 'feature' of the i386 class of cpu. See PR 323 for details. There is many floating point operations of course. Why the only one specific resion make problem? The floating point operations are done with 80-bit precision and the intermediate results that are left in a register have the extra precision. Double precision has 53 bits of precision and single precision has 24 bits. The mixed mode arithmetic that ftnchek warns about can cause the type of problem you are seeing. The -ffloat-store option forces the contents in a register after a floating pointing operation to be written to main memory and then re-read. This removes the extra precision. That is not set when optimize. So, what's the disadvantage and why the 'fortran' with many floating point operation dosn't take it when optimize? You'll need to review the code. I'd suggest first eliminating the warns produced by ftnchek. If the problems disappear, then be happy. If the problems are still present, you'll need to review the floating point operations in the code. Why x86 need that option but x86_64 or PPC do not need? These cpus do not store intermediate results in 80-bit register. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug middle-end/32321] [4.3 Regression] ICE in df_refs_verify with -fgcse-sm
--- Comment #3 from spark at gcc dot gnu dot org 2007-06-18 20:49 --- Subject: Bug 32321 Author: spark Date: Mon Jun 18 20:49:23 2007 New Revision: 125827 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125827 Log: 2007-06-18 Seongbae Park [EMAIL PROTECTED] PR rtl-optimization/32321 * gcse.c (replace_store_insn): Update the note before calling emit_insn_after. Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32321
[Bug middle-end/32396] New: [PPC/Altivec, regression?] gcc uses 0 as altivec load/store index
In altivec load/store instructions (lvx, stvx, ...) and lsvl/lsvr, when address
is supplied as pointer + well-known constant, gcc always calculates the actual
address in scalar unit and does not use sum in those instructions (puts 0 as
index). This slows-down some simple altivec loops.
Sample code:
vector unsigned char *vDst = dst;
vector unsigned char vSetTo = {}; /* zero */
do {
vec_st( vSetTo, 0, vDst );
vec_st( vSetTo, 16, vDst );
vDst += 2;
} while (--len);
gcc 4.1.2, 4.2.0, 4.3-20070615 produces:
.L3:
addi %r11,%r9,16
stvx %v0,0,%r9
addi %r9,%r9,32
stvx %v0,0,%r11
bdnz .L3
while, ideally, it should be:
li %r11,16
.L3:
stvx %v0,0,%r9
stvx %v0,%r11,%r9
addi %r9,%r9,32
bdnz .L3
gcc 3.3, with -O2, behaves quite well in this case (should use 0 instead of
r10):
li %r10,0
li %r11,16
.L13:
stvx %v0,%r10,%r9
stvx %v0,%r11,%r9
addi %r9,%r9,32
bdnz .L13
--
Summary: [PPC/Altivec, regression?] gcc uses 0 as altivec
load/store index
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sparky at pld-linux dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32396
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #9 from burnus at gcc dot gnu dot org 2007-06-18 21:04 --- valid test case(?) I have removed the dummy subroutines and type mismatch. Still not fully valid as NAG f95 complains Error: yyy.f: Argument IVG (no. 2) in reference to VR2 from MAIN is not an array [...] However, ignoring this issue (-dusty), NAG f95 shows another issue: Subscript 1 of A (value 2) is out of range (1:1) in PRMX, line 191 (gfortran -fbounds-check finds it also.) Otherwise on x86_64-unknown-linux-gnu I get the same result with all my compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug middle-end/32396] [PPC/Altivec, regression?] gcc uses 0 as altivec load/store index
--- Comment #1 from sparky at pld-linux dot org 2007-06-18 21:11 --- Created an attachment (id=13732) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13732action=view) simple testcase and benchmark on 1.3GHz iBook built without USE_ASM runs in 2.335s, with USE_ASM runs in 1.815s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32396
[Bug c/31331] ICE on invalid function attribute syntax for main()
--- Comment #2 from eweddington at cso dot atmel dot com 2007-06-18 22:00 --- Created an attachment (id=13733) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13733action=view) Patch to fix bug, written by Anatoly Sokolov -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31331
[Bug c/31331] ICE on invalid function attribute syntax for main()
--- Comment #3 from eweddington at cso dot atmel dot com 2007-06-18 22:01 --- The attached patch, written by Anatoly Sokolov, fixes the bug. -- eweddington at cso dot atmel dot com changed: What|Removed |Added CC||aesok at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-18 22:01:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31331
[Bug c++/31923] g++ accepts a storage-class-specifier on a template explicit specialization
--- Comment #3 from simonb at gcc dot gnu dot org 2007-06-18 22:09 --- Subject: Bug 31923 Author: simonb Date: Mon Jun 18 22:09:14 2007 New Revision: 125829 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125829 Log: gcc/cp/ChangeLog 2007-06-15 Simon Baldwin [EMAIL PROTECTED] PR c++/31923 * parser.c (cp_parser_single_declaration): Added check for storage class other than sc_none in parsed declaration, and a flag to indicate if the call is part of an explicit template specialization parse. * (cp_parser_explicit_specialization): Specialization check flag added to call to cp_parser_single_declaration(), set true. * (cp_parser_template_declaration_after_export): Specialization check flag added to call to cp_parser_single_declaration(), set false. * pt.c (check_explicit_specialization): Added code to copy visiblity and linkage from the templated function to the explicit specialization. gcc/testsuite/ChangeLog 2007-06-15 Simon Baldwin [EMAIL PROTECTED] PR c++/31923 * g++.dg/template/error25.C: New. * g++.dg/template/spec35.C: New. Added: trunk/gcc/testsuite/g++.dg/template/error25.C trunk/gcc/testsuite/g++.dg/template/spec35.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31923
[Bug target/32389] [4.1/4.2/4.3 Regression] ICE in extract_constrain_insn_cached when using -msse
--- Comment #2 from uros at gcc dot gnu dot org 2007-06-18 22:33 --- Subject: Bug 32389 Author: uros Date: Mon Jun 18 22:32:56 2007 New Revision: 125830 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125830 Log: PR target/32389 * config/i386/i386.h (enum ix86_stack_slot): Add SLOT_VIRTUAL. * config/i386/i386.c (assign_386_stack_local): Assert that SLOT_VIRTUAL is valid only before virtual regs are instantiated. (ix86_expand_builtin) [IX86_BUILTIN_LDMXCSR, IX86_BUILTIN_STMXCSR]: Use SLOT_VIRTUAL stack slot instead of SLOT_TEMP. * config/i386/i386.md (truncdfsf2, truncxfmode2): Ditto. testsuite/ChangeLog: PR target/32389 * gcc.target/i386/pr32389.c New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr32389.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32389
[Bug target/32389] [4.1/4.2 Regression] ICE in extract_constrain_insn_cached when using -msse
--- Comment #3 from ubizjak at gmail dot com 2007-06-18 22:35 --- Fixed in mainline. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||06/msg01281.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||patch Known to fail|4.1.2 4.2.0 4.3.0 |4.1.2 4.2.0 Known to work|3.4.6 4.0.4 |3.4.6 4.0.4 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-06-18 22:35:45 date|| Summary|[4.1/4.2/4.3 Regression] ICE|[4.1/4.2 Regression] ICE in |in |extract_constrain_insn_cache |extract_constrain_insn_cache|d when using -msse |d when using -msse | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32389
[Bug rtl-optimization/32374] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #4 from ubizjak at gmail dot com 2007-06-18 22:36 --- (In reply to comment #3) I don't know if this is data flow related any more, due to the reporting of PR 32389. No, this one is caused by dataflow. -- ubizjak at gmail dot com changed: What|Removed |Added BugsThisDependsOn|32389 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32374
[Bug fortran/32386] Pure function not allowed in specification expression
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-18 22:49 --- John, 5.1 .many snips. If a specification-expr involves a reference to a specification function (7.1.6.2), the expression is considered to be a nonconstant expression. If the data object being declared depends on the value of such a nonconstant expression and is not a dummy argument, such an object is called an automatic data object. I can see why you should think that this is OK. However, this section of the standard says otherwise. In fact, there is a practical consideration, which probably drives the standard: This character length cannot be computed at compilation time because the specification function is needed. Automatic objects in procedures have their variable properties calculated in the interface, which is not available for the main program. Thus, even were this legal code, I would not have the slightest idea how to implement it. My vote is that this is invalid. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32386
[Bug target/20082] unrecognizable insn
--- Comment #6 from pault at gcc dot gnu dot org 2007-06-18 23:04 --- Subject: Bug 20082 Author: pault Date: Mon Jun 18 23:04:28 2007 New Revision: 125831 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125831 Log: 2007-06-19 Paul Thomas [EMAIL PROTECTED] PR fortran/20863 PR fortran/20082 * resolve.c (resolve_code): Use gfc_impure_variable as a condition for rejecting derived types with pointers, in pure procedures. (gfc_impure_variable): Add test for dummy arguments of pure procedures; any for functions and INTENT_IN for subroutines. PR fortran/32236 * data.c (gfc_assign_data_value): Change the ICE on an array reference initializer not being an array into an error and clear init to prevent a repetition of the error. 2007-06-19 Paul Thomas [EMAIL PROTECTED] PR fortran/20863 PR fortran/20082 * gfortran.dg/impure_assignment_2.f90 : New test. PR fortran/32236 * gfortran.dg/data_initialized_2.f90 : New test. * gfortran.dg/equiv_7.f90 : Test for endianess and call the appropriate version of 'dmach'. Added: trunk/gcc/testsuite/gfortran.dg/data_initialized_2.f90 trunk/gcc/testsuite/gfortran.dg/impure_assignment_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/data.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/equiv_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20082
[Bug fortran/20863] Pointer problems in PURE procedures
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-18 23:04 --- Subject: Bug 20863 Author: pault Date: Mon Jun 18 23:04:28 2007 New Revision: 125831 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125831 Log: 2007-06-19 Paul Thomas [EMAIL PROTECTED] PR fortran/20863 PR fortran/20082 * resolve.c (resolve_code): Use gfc_impure_variable as a condition for rejecting derived types with pointers, in pure procedures. (gfc_impure_variable): Add test for dummy arguments of pure procedures; any for functions and INTENT_IN for subroutines. PR fortran/32236 * data.c (gfc_assign_data_value): Change the ICE on an array reference initializer not being an array into an error and clear init to prevent a repetition of the error. 2007-06-19 Paul Thomas [EMAIL PROTECTED] PR fortran/20863 PR fortran/20082 * gfortran.dg/impure_assignment_2.f90 : New test. PR fortran/32236 * gfortran.dg/data_initialized_2.f90 : New test. * gfortran.dg/equiv_7.f90 : Test for endianess and call the appropriate version of 'dmach'. Added: trunk/gcc/testsuite/gfortran.dg/data_initialized_2.f90 trunk/gcc/testsuite/gfortran.dg/impure_assignment_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/data.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/equiv_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20863
[Bug fortran/32236] internal compiler error: in gfc_assign_data_value, at fortran/data.c:288
--- Comment #6 from pault at gcc dot gnu dot org 2007-06-18 23:04 --- Subject: Bug 32236 Author: pault Date: Mon Jun 18 23:04:28 2007 New Revision: 125831 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125831 Log: 2007-06-19 Paul Thomas [EMAIL PROTECTED] PR fortran/20863 PR fortran/20082 * resolve.c (resolve_code): Use gfc_impure_variable as a condition for rejecting derived types with pointers, in pure procedures. (gfc_impure_variable): Add test for dummy arguments of pure procedures; any for functions and INTENT_IN for subroutines. PR fortran/32236 * data.c (gfc_assign_data_value): Change the ICE on an array reference initializer not being an array into an error and clear init to prevent a repetition of the error. 2007-06-19 Paul Thomas [EMAIL PROTECTED] PR fortran/20863 PR fortran/20082 * gfortran.dg/impure_assignment_2.f90 : New test. PR fortran/32236 * gfortran.dg/data_initialized_2.f90 : New test. * gfortran.dg/equiv_7.f90 : Test for endianess and call the appropriate version of 'dmach'. Added: trunk/gcc/testsuite/gfortran.dg/data_initialized_2.f90 trunk/gcc/testsuite/gfortran.dg/impure_assignment_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/data.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/equiv_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236
[Bug fortran/20882] PURE procedure containing pointer assignment to dummy with pointer component
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-18 23:07 --- Subject: Bug 20882 Author: pault Date: Mon Jun 18 23:07:32 2007 New Revision: 125832 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125832 Log: 2007-06-19 Paul Thomas [EMAIL PROTECTED] PR fortran/20882 Correct the PR number from 20082 to 20882. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20882
[Bug fortran/20863] Pointer problems in PURE procedures
--- Comment #6 from pault at gcc dot gnu dot org 2007-06-18 23:08 --- Fixed on trunk Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20863
[Bug fortran/20882] PURE procedure containing pointer assignment to dummy with pointer component
--- Comment #4 from pault at gcc dot gnu dot org 2007-06-18 23:09 --- Fixed on trunk Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20882
[Bug fortran/32236] internal compiler error: in gfc_assign_data_value, at fortran/data.c:288
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-18 23:10 --- Fixed on trunk Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236
Wrong PR listed in your recent ChangeLog
Hi Paul, In your recent checkin: http://gcc.gnu.org/viewcvs?view=revrevision=125831 You list PR fortran/20082 as one of the bugs fixed. PR 20082 is a target bug for the AVR target and was resolved as invalid. So it looks like you have the wrong PR number in your ChangeLog. Thanks, Eric Weddington
[Bug c/32397] New: wrong instruction order generated
this C code line
{(((Cyg_libm_ieee_double_shape_type *)x)-parts.msw) =
(hx0x800f)|(k20); return x;}
causes this assembler code to be generated:
bic r3, ip, #2130706432
bic r3, r3, #15728640
ldmia sp, {r0-r1}
orr r3, r3, r2, asl #20
str r3, [r5, #0]
b .L6
The ldmia instruction loads the value to be returned from memory before the
calculation is finished and the result is stored there. Rearranging the
instructions by hand in the resulting binary makes the program work.
gcc output:
Using built-in specs.
Target: arm-elf
Configured with: /usr/local/src/gcc-4.2.0/configure --target=arm-elf
--prefix=/usr/local --with-gnu-as --with-gnu-ld --disable-hosted-libstdcxx
--disable-__cxa_atexit --enable-languages=c,c++
Thread model: single
gcc version 4.2.0
/usr/local/libexec/gcc/arm-elf/4.2.0/cc1 -E -quiet -v
-I/tmp/ecos/whz2292_install/include
-I/usr/local/share/ecos/packages/language/c/libm/current
-I/usr/local/share/ecos/packages/language/c/libm/current/src
-I/usr/local/share/ecos/packages/language/c/libm/current/tests -I.
-I/usr/local/share/ecos/packages/language/c/libm/current/src/double/portable-api/
-D__USES_INITFINI__ -MD src/double/portable-api/s_scalbn.tmp
/usr/local/share/ecos/packages/language/c/libm/current/src/double/portable-api/s_scalbn.c
-mcpu=arm7tdmi -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef
-finline-limit=7000 -ffunction-sections -fdata-sections -fno-exceptions
-fworking-directory -O2 -fpch-preprocess -o s_scalbn.i
ignoring nonexistent directory
/usr/local/lib/gcc/arm-elf/4.2.0/../../../../arm-elf/sys-include
#include ... search starts here:
#include ... search starts here:
/tmp/ecos/whz2292_install/include
/usr/local/share/ecos/packages/language/c/libm/current
/usr/local/share/ecos/packages/language/c/libm/current/src
/usr/local/share/ecos/packages/language/c/libm/current/tests
.
/usr/local/share/ecos/packages/language/c/libm/current/src/double/portable-api/
/usr/local/lib/gcc/arm-elf/4.2.0/include
/usr/local/lib/gcc/arm-elf/4.2.0/../../../../arm-elf/include
End of search list.
/usr/local/libexec/gcc/arm-elf/4.2.0/cc1 -fpreprocessed s_scalbn.i -quiet
-dumpbase s_scalbn.c -mcpu=arm7tdmi -auxbase-strip
src/double/portable-api/language_c_libm_s_scalbn.o -g -O2 -Wall -Wpointer-arith
-Wstrict-prototypes -Winline -Wundef -version -finline-limit=7000
-ffunction-sections -fdata-sections -fno-exceptions -o s_scalbn.s
GNU C version 4.2.0 (arm-elf)
compiled by GNU C version 4.1.2 20061021 prerelease (NetBSD nb3
20061125).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=65415
Compiler executable checksum: f21aa8a15d6feeb6af69912bd33e6003
/usr/local/lib/gcc/arm-elf/4.2.0/../../../../arm-elf/bin/as -mcpu=arm7tdmi -o
src/double/portable-api/language_c_libm_s_scalbn.o s_scalbn.s
source file:
# 1
/usr/local/share/ecos/packages/language/c/libm/current/src/double/portable-api/s_scalbn.c
# 1 /tmp/ecos/whz2292_build/language/c/libm/current//
# 1 built-in
# 1 command-line
# 1
/usr/local/share/ecos/packages/language/c/libm/current/src/double/portable-api/s_scalbn.c
# 56
/usr/local/share/ecos/packages/language/c/libm/current/src/double/portable-api/s_scalbn.c
# 1 /tmp/ecos/whz2292_install/include/pkgconf/libm.h 1
# 12 /tmp/ecos/whz2292_install/include/pkgconf/libm.h
# 1 /tmp/ecos/whz2292_install/include/pkgconf/system.h 1
# 13 /tmp/ecos/whz2292_install/include/pkgconf/libm.h 2
typedef enum {
CYGNUM_LIBM_COMPAT_UNINIT= 0,
CYGNUM_LIBM_COMPAT_POSIX = 1,
CYGNUM_LIBM_COMPAT_IEEE = 2,
CYGNUM_LIBM_COMPAT_XOPEN = 3,
CYGNUM_LIBM_COMPAT_SVID = 4
} Cyg_libm_compat_t;
# 57
/usr/local/share/ecos/packages/language/c/libm/current/src/double/portable-api/s_scalbn.c
2
# 83
/usr/local/share/ecos/packages/language/c/libm/current/src/double/portable-api/s_scalbn.c
# 1
/usr/local/share/ecos/packages/language/c/libm/current/src/mathincl/fdlibm.h
1
# 66
/usr/local/share/ecos/packages/language/c/libm/current/src/mathincl/fdlibm.h
# 1 /tmp/ecos/whz2292_install/include/cyg/infra/cyg_type.h 1
# 58 /tmp/ecos/whz2292_install/include/cyg/infra/cyg_type.h
# 1 /tmp/ecos/whz2292_install/include/stddef.h 1
# 64 /tmp/ecos/whz2292_install/include/stddef.h
# 1 /usr/local/lib/gcc/arm-elf/4.2.0/include/stddef.h 1 3 4
# 152 /usr/local/lib/gcc/arm-elf/4.2.0/include/stddef.h 3 4
typedef long int ptrdiff_t;
# 214 /usr/local/lib/gcc/arm-elf/4.2.0/include/stddef.h 3 4
typedef long unsigned int size_t;
# 326 /usr/local/lib/gcc/arm-elf/4.2.0/include/stddef.h 3 4
typedef int wchar_t;
# 65 /tmp/ecos/whz2292_install/include/stddef.h 2
# 59 /tmp/ecos/whz2292_install/include/cyg/infra/cyg_type.h 2
# 83 /tmp/ecos/whz2292_install/include/cyg/infra/cyg_type.h
# 1 /tmp/ecos/whz2292_install/include/cyg/hal/basetype.h 1
# 84 /tmp/ecos/whz2292_install/include/cyg/infra/cyg_type.h 2
# 160 /tmp/ecos/whz2292_install/include/cyg/infra/cyg_type.h
typedef int bool;
# 202 /tmp/ecos/whz2292_install/include/cyg/infra/cyg_type.h
typedef unsigned char cyg_uint8 ;
typedef signed char
[Bug fortran/32386] Pure function not allowed in specification expression
--- Comment #8 from John dot Harper at mcs dot vuw dot ac dot nz 2007-06-19 01:13 --- Subject: Re: Pure function not allowed in specification expression On Tue, 18 Jun 2007, pault at gcc dot gnu dot org wrote: Date: 18 Jun 2007 22:49:37 - From: pault at gcc dot gnu dot org [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug fortran/32386] Pure function not allowed in specification expression --- Comment #7 from pault at gcc dot gnu dot org 2007-06-18 22:49 --- John, 5.1 .many snips. If a specification-expr involves a reference to a specification function (7.1.6.2), the expression is considered to be a nonconstant expression. If the data object being declared depends on the value of such a nonconstant expression and is not a dummy argument, such an object is called an automatic data object. I can see why you should think that this is OK. However, this section of the standard says otherwise. In fact, there is a practical consideration, which probably drives the standard: This character length cannot be computed at compilation time because the specification function is needed. Automatic objects in procedures have their variable properties calculated in the interface, which is not available for the main program. Thus, even were this legal code, I would not have the slightest idea how to implement it. My vote is that this is invalid. I now agree the code was invalid - I had found 7.1.6.2 but overlooked 5.1 before sending the bug report. You may be amused to know that some compilers do implement that type of automatic data object: g95 and Sun f95. However Compaq f95 and NAG f95 disallow it. I don't think a bug report to g95 or Sun is warranted though: the part of 5.1 that the program violates is not in a Constraint. -- 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=32386
[Bug regression/32398] New: checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
checking for hppa64-hp-hpux11.11-gcc... /test/gnu/gcc/objdir/./gcc/xgcc -B/test/ gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/ -B/opt /gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.3.0/ hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.1 1/sys-include checking for suffix of object files... configure: error: cannot compute suffix o f object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage2-target-libgcc] Error 1 make[2]: Leaving directory `/test/gnu/gcc/objdir' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/test/gnu/gcc/objdir' make: *** [bootstrap] Error 2 Mon Jun 18 21:08:30 EDT 2007 -- Summary: checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug regression/32398] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #1 from danglin at gcc dot gnu dot org 2007-06-19 02:39 --- This appears to be another problem in handling return pointer: 0x403e5644 lshift_significand+148:extrd,u ret0,63,32,rp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug fortran/32386] Pure function not allowed in specification expression
--- Comment #9 from kargl at gcc dot gnu dot org 2007-06-19 03:50 --- John, With your acknowledgment of pault's comment, I think this can be closed. Thanks for the reports. These types of potential corner cases keep us on our toes. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32386
[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726
--- Comment #8 from spark at gcc dot gnu dot org 2007-06-19 04:30 --- (In reply to comment #7) Subject: Bug 32339 Author: spark Date: Mon Jun 18 20:02:33 2007 New Revision: 125825 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125825 Log: gcc/ChangeLog: 2007-06-18 Seongbae Park [EMAIL PROTECTED] PR rtl-optimization/32339 * df-scan.c (df_uses_record): Don't modify flags but just add to it for df_ref_record. gcc/testsuite/ChangeLog: 2007-06-18 Martin Michlmayr [EMAIL PROTECTED] PR rtl-optimization/32339 * gcc.c-torture/compile/pr32339.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32339.c Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c trunk/gcc/testsuite/ChangeLog Please ignore this commit - this patch is for another bug fix, although the testcase is the correct one. I'll commit the testcase in a separate patch. Sorry for the confusion. Anyway, since this bug has been fixed by my earlier commit, I'm marking it as fixed. -- spark at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32339
[Bug middle-end/32321] [4.3 Regression] ICE in df_refs_verify with -fgcse-sm
--- Comment #4 from spark at gcc dot gnu dot org 2007-06-19 04:38 --- Fixed. -- spark at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32321
