[Bug rtl-optimization/31021] New: gfortran 20% slower than ifort on CP2K computational kernel
I've extracted the computational kernel of CP2K (see PR 29975) for easier benchmarking. Together with required utility routines to turn it into a self-contained program and data to test it, I have made it available here: http://www.pci.unizh.ch/vandevondele/tmp/extracted_collocate.tgz the summary is that (yesterday's trunk) gfortran is about 20% slower than ifort (ifort (IFORT) 9.1 20060707) on my machine. To reproduce, untar the above link, and use (after specifying the relevant FC in the Makefile) make make run a run takes a few seconds, and yields gfortran '-O3 -march=native -ffast-math -ffree-form -ftree-vectorize': # of primitives 154502 # computational kernel timings5 Kernel time 4.612288 Kernel time 4.616289 [...] ifort -xP -O3 -free # of primitives 154502 # computational kernel timings5 Kernel time 3.796237 Kernel time 3.800237 [...] which is in this case 21.5% slower. I haven't found any options that made gfortran much faster (in fact timings are very unsensitive to the options used), and it is unrelated to any IPO (I actually notice ifort now that is slightly faster at -O2). Since this might be relevant, timings are on: vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping: 6 The computational time is ~80% due to a single routine (collocate_core in grid_fast.F), which in turn is dominated by the inner loops in the select case statement, and of those, the one over ig is (should be) dominant. For example, the loop starting at line 216 of grid_fast.F. If I look at the asm for this loop (with my best guess of what that loop might be, I have little experience), my main observation is that it contains 36 mov* instructions with intel and 51 mov* instructions with gfortran (and the same number of mulsd and addsd), which could explain the slowdown. I'll attach the respective asm. I'm of course happy to try other compile flags for gfortran, and also hints on how to rewrite the kernels in order to get better performance with gfortran would be much appreciated. -- Summary: gfortran 20% slower than ifort on CP2K computational kernel Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31021
[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel
--- Comment #1 from jv244 at cam dot ac dot uk 2007-03-02 08:39 --- Created an attachment (id=13131) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13131action=view) gfortran kernel asm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31021
[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel
--- Comment #2 from jv244 at cam dot ac dot uk 2007-03-02 08:39 --- Created an attachment (id=13132) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13132action=view) ifort kernel asm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31021
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #73 from jv244 at cam dot ac dot uk 2007-03-02 08:41 --- I've added PR 31021 to track some performance issue with gfortran on one of CP2K's kernels. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/31022] New: [SH4] internal compiler error with inline
When I compile a testcase that includes float and inline, it asserts internal
compiler error if it is optimized with -O2. If it is optimized with -O, this
error is not asserted.
% gcc -c test.c -O2 -m4
test.c: In function 'fff':
test.c:19: internal compiler error: in reg_overlap_mentioned_p, at
rtlanal.c:1382
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
-test case
typedef union { float f; int i; } fi_type;
static __inline__ float LOG2(float val)
{
fi_type num;
int i;
num.f = val;
i = num.i 23;
num.i++;
return num.f + i;
}
float f;
float fff()
{
return LOG2(f);
}
--
Summary: [SH4] internal compiler error with inline
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: saito at densan dot co dot jp
GCC build triplet: sh4-linux
GCC host triplet: sh4-linux
GCC target triplet: sh4-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31022
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #41 from rguenth at gcc dot gnu dot org 2007-03-02 09:02 --- Thaks for the detective work! I sort of expected the fold patch to be weird or have no effect - but it was needed only (for the testcase) to get rid of the target_first == 128 comparison, as that is confusing VRP. Basically after this comparison we conclude target_first != 128 and drop the earlier target_first != 10 assertion which is the one we can use to optimize the later comparisons. So the other solution is to simply not record out-of-bounds assertions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug c/20459] Warning for variables that are set but not used
--- Comment #3 from dcb314 at hotmail dot com 2007-03-02 09:07 --- (In reply to comment #1) Created an attachment (id=8382) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8382action=view) [edit] A patch that implements this feature (with some false positives) For fun, I tried out your patch on gcc 4.3 It doesn't seem to patch and bootstrap ok anymore. Does the patch need some work to remain up to date ? -- dcb314 at hotmail dot com changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20459
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #42 from baldrick at free dot fr 2007-03-02 09:16 --- Subject: Re: VRP fails to eliminate range checks in Ada code Thaks for the detective work! I sort of expected the fold patch to be weird or have no effect - but it was needed only (for the testcase) to get rid of the target_first == 128 comparison, as that is confusing VRP. Basically after this comparison we conclude target_first != 128 and drop the earlier target_first != 10 assertion which is the one we can use to optimize the later comparisons. So the other solution is to simply not record out-of-bounds assertions. I think fold needs to be fixed, whether or not your fold patch goes in. After all, fold is clearly willing to do create objects like X^Y which take values outside of the range of the type. Once such objects are floating around, any serious use of TYPE_MAX_VALUE or TYPE_MIN_VALUE (when they are non-trivial) will almost certainly give wrong results, as shown by your fold patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug middle-end/31015] infinite loop during compilation on x86_64 architecture
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-02 09:38 --- You can attach a compressed version or provide a URL to download from. The mail didn't seem to get through. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31015
[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-02 09:38 --- On my AMD Athlon(tm) 64 X2 Dual Core Processor 4800+, gfortran is in x86_64 mode only 13% slower: gfortran: Kernel time 5.872366, real 0m33.121s; user 0m32.898s; sys 0m0.088s. Ifort:Kernel time 5.244328, real 0m28.893s, user 0m28.758s, sys 0m0.076s. Options: ifort -xP -O3 -xW -free and gfortran -O3 -march=native -ffast-math -ffree-form -ftree-vectorize -funroll-loops. For grid_fast.F, one difference is which loops are vectorized; ifort vectorizes the loops in line 44, 469, 483 and 496, gfortran only vectorizes the loops in line 496 and 469; for the other ones: grid_fast.F:44: note: not vectorized: complicated access pattern. DO lz=1,lz_max(lxy) lxyz=lxyz+1 pyx(1,lxy)=pyx(1,lxy)+pzyx(lxyz)*polz(lxyz,kg) pyx(2,lxy)=pyx(2,lxy)+pzyx(lxyz)*polz(lxyz,kg2) ENDDO grid_fast.F:483: note: not vectorized: can't determine dependence between (*coef_447)[D.1967_2320] and (*coef_447)[D.1967_2320] DO icoef=1,coef_max coef(icoef,1)=coef(icoef,1)+alpha(icoef,lx)*g1 coef(icoef,2)=coef(icoef,2)+alpha(icoef,lx)*g2 coef(icoef,3)=coef(icoef,3)+alpha(icoef,lx)*g1k coef(icoef,4)=coef(icoef,4)+alpha(icoef,lx)*g2k ENDDO -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31021
[Bug target/31019] Microoptimization of the i386 and x86_64 compilers
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-02 09:42 --- I count 5 and one such use in i386.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31019
[Bug middle-end/31023] New: Fold is agnostic of integer sub-types
Transformations in fold do not properly handle integer types with value ranges (defined by TYPE_MIN_VALUE and TYPE_MAX_VALUE) that do not correspond to the types precision. Citing from PR30911 comment #40 The problem is in this transformation: /* Fold (X C) op (Y C) as (X ^ Y) C op 0, and symmetries. */ X^Y may not be in the range of the type. In this case C=7 and op=NE_EXPR. The type of X and Y has range 4..5. Thus X^Y is either 0 or 2 (neither of which is in the range 4..5). Since the type of X^Y has range 4..5, the new fold code deduces that X^Y NE 0 is always true. I think the thing to do, as Richard Kenner suggested, is to convert each type to its base type right at the start of fold_comparison, at least if it has a base type (the same goes for other routines in fold). This unfortunately neutralizes your patch, since as it is right now you will only ever see base types. Thus this kind of check needs to happen at the start of fold_comparison, before the conversion to the base type. another source of problems is fold_convert and its siblings that happily create out-of-bounds constants or strip conversions to the base type. -- Summary: Fold is agnostic of integer sub-types Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org OtherBugsDependingO 30911 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31023
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #43 from rguenth at gcc dot gnu dot org 2007-03-02 09:53 --- I agree. Let's create another bug for this issue. PR31023. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|31023 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel
--- Comment #4 from jv244 at cam dot ac dot uk 2007-03-02 09:55 --- (In reply to comment #3) On my AMD Athlon(tm) 64 X2 Dual Core Processor 4800+, gfortran is in x86_64 mode only 13% slower: gfortran: Kernel time 5.872366, real 0m33.121s; user 0m32.898s; sys 0m0.088s. Ifort:Kernel time 5.244328, real 0m28.893s, user 0m28.758s, sys 0m0.076s. Options: ifort -xP -O3 -xW -free and gfortran -O3 -march=native -ffast-math -ffree-form -ftree-vectorize -funroll-loops. For grid_fast.F, one difference is which loops are vectorized; ifort vectorizes the loops in line 44, 469, 483 and 496, gfortran only vectorizes the loops in line 496 and 469; for the other ones: grid_fast.F:44: note: not vectorized: complicated access pattern. DO lz=1,lz_max(lxy) lxyz=lxyz+1 pyx(1,lxy)=pyx(1,lxy)+pzyx(lxyz)*polz(lxyz,kg) pyx(2,lxy)=pyx(2,lxy)+pzyx(lxyz)*polz(lxyz,kg2) ENDDO this might matter a bit, but this is not in an inner loop, so I don't think it accounts for a lot of time. Having it vectorized would be good of course. grid_fast.F:483: note: not vectorized: can't determine dependence between (*coef_447)[D.1967_2320] and (*coef_447)[D.1967_2320] DO icoef=1,coef_max coef(icoef,1)=coef(icoef,1)+alpha(icoef,lx)*g1 coef(icoef,2)=coef(icoef,2)+alpha(icoef,lx)*g2 coef(icoef,3)=coef(icoef,3)+alpha(icoef,lx)*g1k coef(icoef,4)=coef(icoef,4)+alpha(icoef,lx)*g2k ENDDO This part, which is in the default part of the switch statement should only be executed in rare cases. I doubt it matters much in the overall timings. Also, this loop has very short trips (i.e. coef_max should, for the provided input, be at most 5). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31021
[Bug fortran/31009] Use memcpy when assigning whole arrays
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-03-02 09:57 --- Tobias, do the cases given in PR31016 include the one above? If yes, this PR could be closed as dupe?! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31009
[Bug target/31019] Microoptimization of the i386 and x86_64 compilers
--- Comment #2 from ubizjak at gmail dot com 2007-03-02 10:12 --- Mine, I have a patch in testing. And this is _definitelly_ not a microoptimization. I'll post the patch shortly to gcc-patches, please look at some suprising numbers below... size cc1 textdata bss dec hex filename 7632793 18876 574516 8226185 7d8589 cc1 size cc1-patched textdata bss dec hex filename 6731749 18876 574516 7325141 6fc5d5 cc1 Yes, it lowers cc1 text size for i686 host by 901k. -- 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-03-02 10:12:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31019
[Bug c/31024] New: segfault for SPEC CPU2000 vortex with -O2
Using GCC 4.1.2 and compiling with -static -O2, the SPEC CPU2000 benchmark vortex segfaults on my system (Fedora Core 4, Intel Pentium 4). This issue was reported before (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23449), and seem to be resolved in GCC 4.1.1. Using -fno-strict-aliasing solves this, but I wonder why -fno-strict-aliasing was not required with GCC 4.1.1, but is crucial (again) in GCC 4.1.2. Any further details will be provided as needed. -- Summary: segfault for SPEC CPU2000 vortex with -O2 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kenneth dot hoste at elis dot ugent dot be GCC target triplet: x86/linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31024
[Bug middle-end/31015] infinite loop during compilation on x86_64 architecture
--- Comment #4 from bernd dot speiser at uni-tuebingen dot de 2007-03-02 10:26 --- Subject: Re: infinite loop during compilation on x86_64 architecture rguenth at gcc dot gnu dot org wrote: --- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-02 09:38 --- You can attach a compressed version or provide a URL to download from. The mail didn't seem to get through. This is another try. I attach the compressed version of the *.ii file. Hope this works. Thanks Bernd -- === Bernd Speiser Institut für Organische Chemie Auf der Morgenstelle 18 D-72076 Tübingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) fax: +49-7071-295518 e-mail: [EMAIL PROTECTED] Internet: http://www.uni-tuebingen.de/speiser === -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31015
[Bug fortran/31009] Use memcpy when assigning whole arrays
--- Comment #5 from burnus at gcc dot gnu dot org 2007-03-02 10:43 --- Tobias, do the cases given in PR31016 include the one above? If yes, this PR could be closed as dupe?! Actually not. PR 31016 (and related PR 31014) are about cases where one actually knows that the memory is contiguous (with the size known either at compile time or only at run time). There using memcpy or memset should always be a win (except, maybe, for a one-element array). This PR is about cases were the memory might not be contiguous; thus one needs create code for both the contiguous and non-contiguous case and a check whether either case is present. I believe this needs some thinking (and testing) to make sure that the size of the generated code does not increase too much (at least not for -Os) and that it is an overall gain without loosing to much speed for real-world code with on non-contiguous arrays (strides). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31009
[Bug target/31019] Microoptimization of the i386 and x86_64 compilers
--- Comment #3 from ubizjak at gmail dot com 2007-03-02 11:03 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00115.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||03/msg00115.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31019
[Bug target/31019] Microoptimization of the i386 and x86_64 compilers
--- Comment #4 from uros at gcc dot gnu dot org 2007-03-02 12:27 --- Subject: Bug 31019 Author: uros Date: Fri Mar 2 12:26:55 2007 New Revision: 122473 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122473 Log: PR target/31019 * config/i386/i386.h (TUNEMASK): Redefine to use ix86_tune_mask. (ARCHMASK): Define. (TARGET_CMOVE): Use ARCHMASK. (TARGET_CMPXCHG): Ditto. (TARGET_CMPXCHG8B): Ditto. (TARGET_XADD): Ditto. (TARGET_BSWAP): Ditto. * config/i386/i386.c (ix86_tune_mask): New global variable. (ix86_arch_mask): Ditto. (override_options): Initialize ix86_tune_mask and ix86_arch_mask. Use ARCHMASK to clear MASK_NO_FANCY_MATH_387 in target_flags. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31019
[Bug rtl-optimization/31025] New: [dataflow] Crash in caller-save.c due to x87 math
reduced testcase: real*8 function f(x) t1 = g(0) if(x .eq. 0) then f = 0 else if(x .eq. 1) then f = t1 *log( t1 ) end if end dlarnd.f90: In function 'f': dlarnd.f90:3: internal compiler error: in insert_save, at caller-save.c:731 -- Summary: [dataflow] Crash in caller-save.c due to x87 math Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonzini at gnu dot org GCC target triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31025
[Bug c/20459] Warning for variables that are set but not used
--- Comment #4 from manu at gcc dot gnu dot org 2007-03-02 14:24 --- (In reply to comment #3) Does the patch need some work to remain up to date ? The patch is from 2005, so I guess it is outdated. You would need to examine what are the conflicts and try to fix them. I find easier to do this by updating update a subversion working copy to 'Mar 2005', apply the patch, then 'svn up' and examine the conflicts. Even if the patch applies, there is no guarantee that it actually compiles or works. For example, 'warning' now has an additional parameter, so you would need to replace it with 'warning (0,'. Anyway, I am not sure whether a whole pass to implement this warning is actually needed or worth of it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20459
[Bug middle-end/31015] infinite loop during compilation on x86_64 architecture
--- Comment #5 from bernd dot speiser at uni-tuebingen dot de 2007-03-02 14:32 --- I tried to resend the attachment (*.ii file) in compressed form as an e-mail attachment to gcc-bugs@gcc.gnu.org, after the uncompressed attachment was supposedly also too big and the earlier mail didn't get through. Hope this works ... This is the first time, I had to use the bug reporting facility, (fortunately!), so I'm not too familiar with your procedures. Sorry about any inconvenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31015
[Bug middle-end/31015] infinite loop during compilation on x86_64 architecture
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-02 14:38 --- Looks like e-mails with attachments are dropped. Please try attaching it via bugzilla to the bug again (compressed). Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31015
[Bug target/31019] Microoptimization of the i386 and x86_64 compilers
--- Comment #5 from ubizjak at gmail dot com 2007-03-02 14:51 --- Patch committed, with somehow smaller code-size saves as per http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00122.html. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31019
[Bug middle-end/30667] [4.3 Regression] ICE in immed_double_const, at emit-rtl.c:468
--- Comment #5 from ubizjak at gmail dot com 2007-03-02 14:53 --- Fixed in mainline. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.3.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30667
[Bug target/30970] Register zeroing by xor N,N should be moved out of loop
--- Comment #5 from ubizjak at gmail dot com 2007-03-02 14:54 --- Fixed in mainline. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30970
[Bug middle-end/31015] infinite loop during compilation on x86_64 architecture
--- Comment #7 from bernd dot speiser at uni-tuebingen dot de 2007-03-02 15:02 --- Created an attachment (id=13133) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13133action=view) preprocessed source (compressed) next try to attach ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31015
[Bug target/30413] %z produces ICE for char operands
--- Comment #6 from ubizjak at gmail dot com 2007-03-02 15:02 --- Fixed in mainline. IMO this is not worth to fix on branches due to comment #5. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30413
[Bug bootstrap/19420] make install fails if not preceded by make all
--- Comment #4 from ubizjak at gmail dot com 2007-03-02 15:09 --- Still fails on 4.3.0 mainline. IMO it would be OK if 'make install' exited with a message that 'make all' should be run before 'make install' instead of uninformative error about something called fixincludes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19420
[Bug middle-end/31015] infinite loop during compilation on x86_64 architecture
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-03-02 15:16 --- That worked. Dup of PR29512. We might consider a backport... *** This bug has been marked as a duplicate of 29512 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31015
[Bug target/29512] compile time hog / deadloop.
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-03-02 15:16 --- *** Bug 31015 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||bernd dot speiser at uni- ||tuebingen dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug libgomp/28926] FAIL: libgomp.c/ordered-1.c execution test
--- Comment #2 from ubizjak at gmail dot com 2007-03-02 15:16 --- Closed as WORKSFORME as RH 8.0 is kind of obsolete (I don't have this OS anymore). -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28926
[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code
--- Comment #13 from ubizjak at gmail dot com 2007-03-02 15:34 --- Any news about this problem? Current mainline still has severe problems: -msse3 -O2 -mfpmath=sse -ffast-math GCC 4.3 -ffast-math double performance: ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.288 1499.91 -msse3 -O2 -mfpmath=sse GCC 4.3 double performance: ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.192 2249.86 -msse3 -O2 -mfpmath=sse -ffast-math GCC 4.3 -ffast-math single performance: ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.304 1420.96 -msse3 -O2 -mfpmath=sse GCC 4.3 single performance: ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.172 2511.48 Please consider the fact that all benchmarks are using -ffast-math nowadays. ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug middle-end/30666] [4.3 Regression] warning: canonical types differ for identical types double __complex__ and double __complex__
--- Comment #7 from ubizjak at gmail dot com 2007-03-02 15:37 --- (In reply to comment #6) This looks like a straightforward fix to build_common_tree_nodes2. Is it possible to provide a patch for this? This warning is generated during povray compilation, and povray is part of SPEC2006 package. (I'm self-confirming the bug, as the problem can be shown by compiling attached testcase.) -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-02 15:37:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30666
[Bug c++/31026] New: ICE on invalid code
The invalid code (missing '{' in second line)
template class T class A{
template class T1 void B() (static_castvoid (0)); }
};
creates an ICE with gcc-4.1.2:
crash.cc:2: internal compiler error: in grokfield, at cp/decl2.c:896
--
Summary: ICE on invalid code
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: axel-freyn at gmx dot de
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31026
[Bug c++/31026] ICE on invalid code
--- Comment #1 from axel-freyn at gmx dot de 2007-03-02 15:47 --- Created an attachment (id=13134) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13134action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31026
[Bug fortran/30922] IMPORT fails for same symbol in multiple interface bodies of same interface block
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-02 16:14 --- Another thing which currently fails in gfortran (and g95) is: module x implicit none integer, parameter :: d=8 interface real(d) function y() import end function end interface end module x real(d) function y() 1 Error: Parameter 'd' at (1) has not been declared or is a variable, which does not reduce to a constant expression -- burnus 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-03-02 16:14:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
[Bug fortran/30922] IMPORT fails for same symbol in multiple interface bodies of same interface block
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-02 16:16 --- (Example for the latter is: http://users.erols.com/dnagle/pub/pthread.f03, which also needs ISO_C_BINDING) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
[Bug libstdc++/28080] header dependencies
--- Comment #18 from paolo at gcc dot gnu dot org 2007-03-02 16:21 --- Subject: Bug 28080 Author: paolo Date: Fri Mar 2 16:21:30 2007 New Revision: 122478 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122478 Log: 2007-03-02 Paolo Carlini [EMAIL PROTECTED] * testsuite/thread/pthread1.cc: Include pthread.h. * testsuite/thread/pthread2.cc: Likewise. * testsuite/thread/pthread3.cc: Likewise. * testsuite/thread/pthread4.cc: Likewise. * testsuite/thread/pthread5.cc: Likewise. * testsuite/thread/pthread6.cc: Likewise. * testsuite/thread/pthread7-rope.cc: Likewise. 2007-03-02 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/28080 (partial) * include/tr1/random (class random_device): Rework to use simple cstdio input, do not include fstream. * include/tr1/random.tcc (all inserters and extractors): Refer to ios_base as base class of basic_istream or basic_ostream. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1/random trunk/libstdc++-v3/include/tr1/random.tcc trunk/libstdc++-v3/testsuite/thread/pthread1.cc trunk/libstdc++-v3/testsuite/thread/pthread2.cc trunk/libstdc++-v3/testsuite/thread/pthread3.cc trunk/libstdc++-v3/testsuite/thread/pthread4.cc trunk/libstdc++-v3/testsuite/thread/pthread5.cc trunk/libstdc++-v3/testsuite/thread/pthread6.cc trunk/libstdc++-v3/testsuite/thread/pthread7-rope.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug tree-optimization/14052] Combiner weakness
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-02 16:23 --- VRP can do this on the mainline. Fixed. (I'll add a testcase) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14052
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #34 from michael dot klein at fazi dot de 2007-03-02 16:25 --- Could the be related to http://sources.redhat.com/ml/binutils/2004-08/msg00187.html? I'm getting those linker errors with both gcc 4.1.1 and gcc 4.1.2 on x86-Solaris with GNU ld from binutils-070227, but only when compiling with -O2 or -O3, but not with -O0. The referenced symbols shows up (gnm -a *.o) in several objects like this: t .gnu.linkonce.t._ZN10otl_streamlsEj W _ZN10otl_streamlsEj But in the object mentioned in the error messages like this: r .gnu.linkonce.r._ZN10otl_streamlsEj t .gnu.linkonce.t._ZN10otl_streamlsEj W _ZN10otl_streamlsEj One possible workaround is to reorder the objects during link, so that those with .gnu.linkonce.r.* come first. If this a compiler or a linker bug? (I'd blame the linker ;)) -- michael dot klein at fazi dot de changed: What|Removed |Added CC||michael dot klein at fazi ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug c++/31027] New: Compiler segfaults in simple virtual inheritance situation
Compiler segfaults in simple virtual inheritance situation. If inheritance is changed to non-virtual then code compiles correctly. Also code compiles correctly if seemingly irrelevant bits of code are removed. No headers are required for the code to trigger the bug and none are provided. -- Summary: Compiler segfaults in simple virtual inheritance situation Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: v dot lesk at ic dot ac dot uk GCC build triplet: i586-mandriva-linux-gnu GCC host triplet: i586-mandriva-linux-gnu GCC target triplet: i586-mandriva-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
[Bug target/31028] New: Microoptimization of the i386 and x86_64 compilers
There are a lot of feature test macros in the i386/x86_64 compiler of the form: (x86_some_var (1 ix86_arch)) These tests could be micro-optimized, either by storing 1 ix86_arch into a global variable, or by having a global variable that is the result of the and and the shift, so that a simple != 0 can be done. -- Summary: Microoptimization of the i386 and x86_64 compilers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot meissner at amd dot com GCC build triplet: x86_64-pc-gnu-linux GCC host triplet: x86_64-pc-gnu-linux GCC target triplet: x86_64-pc-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31028
[Bug c++/31027] Compiler segfaults in simple virtual inheritance situation
--- Comment #1 from v dot lesk at ic dot ac dot uk 2007-03-02 17:02 ---
//Couldnt include attachment so attaching (short) code here. See next comment
for compiler output.
class A
{
private:
protected:
public:
};
templatetypename T
class C:
virtual public A
{
private:
protected:
public:
C();
templatetypename T_OTHERC(const CT_OTHER);
C func(const class Clong)const;
operator bool(void)const;
};
templatetypename T
CT::
C()
{
}
templatetypename T
templatetypename T_OTHER
CT::
C(const CT_OTHERa)
{
}
templatetypename T
CT
CT::
func(const class Clong)const
{
CTresult;
return result;
}
templatetypename T
class D:
public CT
{
private:
protected:
public:
void func2(void);
};
templatetypename T
void
DT::
func2(void)
{
Cinta;
a.func(a);
}
void func3(void)
{
Cinta;
a.func(a);
}
int
main(int argc,const char*const*argv)
{
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
[Bug c++/31027] Compiler segfaults in simple virtual inheritance situation
--- Comment #2 from v dot lesk at ic dot ac dot uk 2007-03-02 17:03 --- Compiler command and output for this bug : g++ -v -save-temps -c -O0 ./source.C Using built-in specs. Target: i586-mandriva-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --enable-languages=c,c++,ada,fortran,objc,obj-c++,java --host=i586-mandriva-linux-gnu --with-cpu=generic --with-system-zlib --enable-long-long --enable-__cxa_atexit --enable-clocale=gnu --disable-libunwind-exceptions --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo --enable-ssp --disable-libssp Thread model: posix gcc version 4.1.1 20060724 (prerelease) (4.1.1-3mdk) /usr/lib/gcc/i586-mandriva-linux-gnu/4.1.1/cc1plus -E -quiet -v -D_GNU_SOURCE ./source.C -mtune=generic -O0 -fpch-preprocess -o source.ii ignoring nonexistent directory /bmm/home/vil/build/qt/include ignoring nonexistent directory /usr/lib/gcc/i586-mandriva-linux-gnu/4.1.1/../../../../i586-mandriva-linux-gnu/include #include ... search starts here: #include ... search starts here: /bmm/home/vil/include /bmm/soft/Linux_2.4/include/ /usr/lib/gcc/i586-mandriva-linux-gnu/4.1.1/../../../../include/c++/4.1.1 /usr/lib/gcc/i586-mandriva-linux-gnu/4.1.1/../../../../include/c++/4.1.1/i586-mandriva-linux-gnu /usr/lib/gcc/i586-mandriva-linux-gnu/4.1.1/../../../../include/c++/4.1.1/backward /usr/local/include /usr/lib/gcc/i586-mandriva-linux-gnu/4.1.1/include /usr/include End of search list. /usr/lib/gcc/i586-mandriva-linux-gnu/4.1.1/cc1plus -fpreprocessed source.ii -quiet -dumpbase source.C -mtune=generic -auxbase source -O0 -version -o source.s GNU C++ version 4.1.1 20060724 (prerelease) (4.1.1-3mdk) (i586-mandriva-linux-gnu) compiled by GNU C version 4.1.1 20060724 (prerelease) (4.1.1-3mdk). GGC heuristics: --param ggc-min-expand=96 --param ggc-min-heapsize=125369 Compiler executable checksum: 60e98b6becb426227e419ae6a431d9b1 ./source.C: In constructor CT::C(const CT_OTHER) [with T_OTHER = int, T = long int]: ./source.C:70: instantiated from here ./source.C:33: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:https://qa.mandriva.com/ for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-03-02 17:42 --- Please consider the fact that all benchmarks are using -ffast-math nowadays. ;) Please also consider the fact that the register allocator has been broken since 20 years ago :) :) :) :). And I repeat again, this has nothing to do with -ffast-math, see my comment #6 and #7 where I prove -ffast-math is not the issue and it is just the register allocator going wrong. If anyone disables reassociation at the tree level, I am going to object loudly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug target/31028] Microoptimization of the i386 and x86_64 compilers
--- Comment #1 from ubizjak at gmail dot com 2007-03-02 17:45 --- *** This bug has been marked as a duplicate of 31019 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31028
[Bug target/31019] Microoptimization of the i386 and x86_64 compilers
--- Comment #6 from ubizjak at gmail dot com 2007-03-02 17:45 --- *** Bug 31028 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31019
[Bug c++/31027] Compiler segfaults in simple virtual inheritance situation
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel
--- Comment #5 from jv244 at cam dot ac dot uk 2007-03-02 18:15 --- grid_fast.F:483: note: not vectorized: can't determine dependence between (*coef_447)[D.1967_2320] and (*coef_447)[D.1967_2320] DO icoef=1,coef_max coef(icoef,1)=coef(icoef,1)+alpha(icoef,lx)*g1 coef(icoef,2)=coef(icoef,2)+alpha(icoef,lx)*g2 coef(icoef,3)=coef(icoef,3)+alpha(icoef,lx)*g1k coef(icoef,4)=coef(icoef,4)+alpha(icoef,lx)*g2k ENDDO This part, which is in the default part of the switch statement should only be executed in rare cases. I doubt it matters much in the overall timings. Also, this loop has very short trips (i.e. coef_max should, for the provided input, be at most 5). I verified that the default branch is indeed not called frequently enough for this to matter. However, by deleting all other cases (equivalent, but specialized code), I can time that case, and find: gfortran: 6.636415 ifort: 5.252329 which means ifort is about 26% faster for the 'case default' branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31021
[Bug target/30970] Register zeroing by xor N,N should be moved out of loop
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30970
[Bug target/30413] %z produces ICE for char operands
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30413
[Bug objc/31013] [4.3 Regression] objc PCH is broken on powerpc-darwin again
--- Comment #1 from geoffk at gcc dot gnu dot org 2007-03-02 18:59 --- This is because gccspec.c is adding -shared-libgcc when it sees an Objective-C file, but inconsistently; it doesn't handle -x options, it doesn't handle the -objC flag. On Darwin, it's wrong to add -shared-libgcc like this because the objective-C runtime uses setjmp/longjmp exceptions and some versions of Darwin don't have a shared libgcc to use. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-02 18:59:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31013
[Bug tree-optimization/31029] New: missed otimization
the following is tiny missed optimization, as it fails to link at -O3 read(5,*) igmin DO ig=igmin,0 ig2=1-ig if (ig.EQ.ig2) CALL link_error() ENDDO END since ig can only have values in the interval [-huge,0], ig2 can only have values in [1,huge] and so ig can never be equal to ig2. Code similar to this appears in PR 31021 -- Summary: missed otimization Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31029
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #35 from hjl at lucon dot org 2007-03-02 19:43 --- (In reply to comment #34) Could the be related to http://sources.redhat.com/ml/binutils/2004-08/msg00187.html? I'm getting those linker errors with both gcc 4.1.1 and gcc 4.1.2 on x86-Solaris with GNU ld from binutils-070227, but only when compiling with -O2 or -O3, but not with -O0. The referenced symbols shows up (gnm -a *.o) in several objects like this: t .gnu.linkonce.t._ZN10otl_streamlsEj W _ZN10otl_streamlsEj But in the object mentioned in the error messages like this: r .gnu.linkonce.r._ZN10otl_streamlsEj t .gnu.linkonce.t._ZN10otl_streamlsEj W _ZN10otl_streamlsEj One possible workaround is to reorder the objects during link, so that those with .gnu.linkonce.r.* come first. If this a compiler or a linker bug? (I'd blame the linker ;)) It is most likely a Solaris specific compiler bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug tree-optimization/31029] missed optimization
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-02 20:04 --- *** This bug has been marked as a duplicate of 30965 *** -- 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=31029
[Bug tree-optimization/30965] Fails to tree-combine conditions in COND_EXPRs
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-02 20:04 --- *** Bug 31029 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30965
[Bug preprocessor/19541] need another option to support what -I- did just besides -iquote
--- Comment #6 from levengcc at pleetveern dot com 2007-03-02 21:58 --- (In reply to comment #4) Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01197.html This patch would meet my needs if the -I- option is removed from gcc. Without it or the -I- option, I would have to find a new compiler to work with my codebase (it makes extensive use of VPATHs similar to the nmake's viewpathing feature and it would be impractical to edit all header file references to change them from to ). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
[Bug c++/28253] [4.0/4.1/4.2/4.3 regression] ICE with invalid covariant return
--- Comment #4 from simartin at gcc dot gnu dot org 2007-03-02 22:09 --- Subject: Bug 28253 Author: simartin Date: Fri Mar 2 22:09:20 2007 New Revision: 122490 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122490 Log: 2007-03-02 Simon Martin [EMAIL PROTECTED] PR c++/28253 * class.c (update_vtable_entry_for_fn): Properly handle invalid overriders for thunks. Added: trunk/gcc/testsuite/g++.dg/inherit/covariant16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28253
[Bug c++/28253] [4.0/4.1/4.2 regression] ICE with invalid covariant return
--- Comment #5 from simartin at gcc dot gnu dot org 2007-03-02 22:14 --- Fixed on the mainline -- simartin at gcc dot gnu dot org changed: What|Removed |Added CC||simartin at gcc dot gnu dot ||org Summary|[4.0/4.1/4.2/4.3 regression]|[4.0/4.1/4.2 regression] ICE |ICE with invalid covariant |with invalid covariant |return |return http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28253
[Bug target/29983] Out of range offset for ldrd/strd intruction.
--- Comment #8 from pbrook at gcc dot gnu dot org 2007-03-02 22:51 --- Fixed. trunk r122437 http://gcc.gnu.org/ml/gcc-cvs/2007-03/msg00020.html 4.2 r122489 http://gcc.gnu.org/ml/gcc-cvs/2007-03/msg00072.html -- pbrook at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29983
[Bug fortran/30873] [4.1 and 4.2 only] ENTRY without explict RESULT does not work for recursive functions
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-20 16:24:01 |2007-03-02 23:07:25 date|| Summary|ENTRY without explict RESULT|[4.1 and 4.2 only] ENTRY |does not work for recursive |without explict RESULT does |functions |not work for recursive ||functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30873
[Bug fortran/30873] ENTRY without explict RESULT does not work for recursive functions
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-02 23:03 --- Subject: Bug 30873 Author: burnus Date: Fri Mar 2 23:03:26 2007 New Revision: 122495 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122495 Log: 2007-03-02 Paul Thomas [EMAIL PROTECTED] Tobias Burnus [EMAIL PROTECTED] PR fortran/30873 * decl.c (gfc_match_entry): Remove erroneous entry result check. 2007-03-02 Paul Thomas [EMAIL PROTECTED] Tobias Burnus [EMAIL PROTECTED] PR fortran/30873 * gfortran.dg/entry_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/entry_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30873
[Bug middle-end/19430] Missing uninitialized warning
--- Comment #12 from skunk at iskunk dot org 2007-03-02 23:36 ---
Here's my minimal test case. Compile with -O3 -Wall -c:
#include stdio.h
void frob(int *pi);
int main(void)
{
int i;
printf(i = %d\n, i);
frob(i);
return 0;
}
No warning from 4.0.3 nor 4.1.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
[Bug tree-optimization/29902] [4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:644
--- Comment #10 from rakdver at gcc dot gnu dot org 2007-03-03 00:39 --- Subject: Bug 29902 Author: rakdver Date: Sat Mar 3 00:38:56 2007 New Revision: 122501 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122501 Log: PR tree-optimization/29902 * tree-ssa-loop-manip.c (can_unroll_loop_p): Return false if any involved ssa name appears in abnormal phi node. * g++.dg/tree-ssa/pr29902.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/tree-ssa/pr29902.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/tree-ssa-loop-manip.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29902
[Bug tree-optimization/29902] [4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:644
--- Comment #11 from rakdver at gcc dot gnu dot org 2007-03-03 00:41 --- Can this patch be backported to 4.2? Done. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29902
[Bug fortran/30873] [4.1 and 4.2 only] ENTRY without explict RESULT does not work for recursive functions
--- Comment #5 from patchapp at dberlin dot org 2007-03-03 03:01 --- Subject: Bug number PR30873 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-03/msg00110.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30873
[Bug fortran/30882] size with initialization expression value for dim= is rejected
--- Comment #3 from patchapp at dberlin dot org 2007-03-03 03:01 --- Subject: Bug number PR30882 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-03/msg00111.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30882
