[Bug fortran/24784] Warning about unused routine argument should not read unused variable
--- Comment #5 from patchapp at dberlin dot org 2007-07-04 06:00 --- Subject: Bug number PR24784 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-07/msg00326.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24784
[Bug fortran/29651] Subroutine: Kind convertion of intent(out) value: signal
--- Comment #5 from jv244 at cam dot ac dot uk 2007-07-04 06:19 --- (In reply to comment #4) Subject: Bug number PR29651 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-05/msg02108.html patch ping? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29651
[Bug fortran/29606] Internal Error: Derived type I/O should have been handled via the frontend
--- Comment #2 from jv244 at cam dot ac dot uk 2007-07-04 06:25 --- (In reply to comment #1) This is a general problem for gfortran. A pointer to a component of an array of derived types cannot, at the moment be represented. Some brave soul need to come up with a proposal as to how to do it and then to change every single client for array descriptors in gfortran. I periodically contemplate how to do it and recoil in horror at the size of the job. If this would require an ABI change, 4.3.0 would be the right time to fix this. This looks like rather important functionality. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29606
[Bug fortran/29389] Statement functions are not recognized as pure when they are
--- Comment #7 from jv244 at cam dot ac dot uk 2007-07-04 06:29 --- list link: http://gcc.gnu.org/ml/fortran/2007-01/msg00361.html this suggests that it is now an accepts-invalid bug with an easy fix (Bug reporter / assignee should change keyword) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29389
[Bug fortran/30625] Array pointers to components of derived type arrays do not work
--- Comment #8 from jv244 at cam dot ac dot uk 2007-07-04 06:33 --- target milestone 4.3.0 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30625
[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking
--- Comment #4 from jv244 at cam dot ac dot uk 2007-07-04 06:35 --- patch ping ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31119
[Bug fortran/29651] Subroutine: Kind convertion of intent(out) value: signal
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-04 06:40 --- patch ping? Still working on this (that is, shunning it for the work involved). It does not yet work correctly with actual arguments that are optional dummy arguments. Thanks for the reminder :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29651
[Bug libgcj/32619] -static-libgcj includes entire gnu classpath (30MB executable from 95byte source)
--- Comment #3 from mtrudel at gmx dot ch 2007-07-04 06:59 --- This is an old discussion and comes up in the mailinglist regularly. The most promising approach is to explicitly exclude parts of the class library. JNC (http://jnc.mtsystems.ch/) supports excluding the GUI stuff (AWT/Swing) and JCE what already leads to a great size reduction (since these will be pulled into every binary). BTW, here the FAQ entry for your question from the JNC website: Why are the binaries so big? As JNC evolves, it supports more and more classes of the Java API. The problem now is, that the Java API classes are heavily interconnected; a simple Hello World application uses the security manager which uses AWT which uses... Because of this, you will always have a big part of the classlibrary in your binaries. For Java, this is not a problem. Endusers require to have the JVM, thus having all classes anyway. For native compilation, this is a bigger problem because it's not just a bug that can be fixed. The design of Java doesn't fit into the concept of native compilation (concerning the size of binaries). Since JNC 0.9, you can exclude parts of the class library if you don't need them and thus drastically reduce the size of your binaries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32619
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #19 from spop at gcc dot gnu dot org 2007-07-04 07:04 --- Subject: Bug 32457 Author: spop Date: Wed Jul 4 07:04:31 2007 New Revision: 126305 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126305 Log: PR middle-end/32457 * tree-data-ref.c (analyze_siv_subscript_cst_affine, compute_overlap_steps_for_affine_1_2, analyze_subscript_affine_affine, init_omega_for_ddr_1): Use non conservative number of iterations estimations. (analyze_subscript_affine_affine): Use HOST_WIDE_INT instead of int. (analyze_siv_subscript): Remove FIXME and reinitialization of last_conflicts to chrec_dont_know. * testsuite/gfortran.dg/vect/pr32457.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/vect/pr32457.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/tree-data-ref.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #20 from spop at gcc dot gnu dot org 2007-07-04 07:08 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug libfortran/32611] Print sign of negative zero
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-04 07:08 --- Jerry, I think this is something for you. y = -0.0 is printed as 0.E+00 instead of -0.E+00 I think the problem is in io/write.c's output_float. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-07-04 07:08:52 date|| Summary|signed zero |Print sign of negative zero Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32611
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #17 from bonzini at gnu dot org 2007-07-04 07:11 --- I'm working on this, but don't hold your breath (hence not assigning to myself). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug target/25216] -fpic/-fPIC failure in gcc.target/i386/pr21291.c
--- Comment #5 from bonzini at gnu dot org 2007-07-04 07:12 --- *** This bug has been marked as a duplicate of 32004 *** -- bonzini at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25216
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #18 from bonzini at gnu dot org 2007-07-04 07:12 --- *** Bug 25216 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug target/23224] [meta-bug] Outages with -fPIC
--- Comment #7 from bonzini at gnu dot org 2007-07-04 07:13 --- PR25216 is a dup of PR32004. -- bonzini at gnu dot org changed: What|Removed |Added BugsThisDependsOn|25216 |32004 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23224
[Bug fortran/30939] Run-time check if dummy array sizes is larger than actual array size
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-04 07:19 --- Related to -fbounds-check, isn't it? As my initial bug is fixed: Warnung: Actual argument contains too few elements for dummy argument 'in' (10/11) at (1) and the missing parts are in PR30939, I dedicate it to the run time test. Test: Place program and subroutine in different files, compile and run them. NAG f95 -C=all shows then: Actual argument for dummy array IN too small - 10 elements instead of 11 Program terminated by fatal error In COPY, line 1 of aa.f90 Called by MAIN, line 4 of ab.f90 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|Report if dummy array sizes |Run-time check if dummy |is larger than actual array |array sizes is larger than |size|actual array size http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30939
[Bug tree-optimization/32377] can't determine dependence (source/destination overlap without more than size)
--- Comment #10 from sebpop at gmail dot com 2007-07-04 07:21 --- Subject: Re: can't determine dependence (source/destination overlap without more than size) I can submit a patch for merging that part of code in trunk if you need this flag to test if you are in one or the other case. I guess we can't vectorize the loop in this PR without it, since we have to distinguish between the cases in comment #7 (the first loop should not be vectorized and the second one should). I have committed the attached patch to trunk. Sebastian --- Comment #11 from sebpop at gmail dot com 2007-07-04 07:21 --- Created an attachment (id=13841) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13841action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug fortran/31198] wrong code: Max() with optional arguments
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:25 --- Subject: Bug 31198 Author: fxcoudert Date: Wed Jul 4 07:25:39 2007 New Revision: 126307 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126307 Log: PR fortran/31198 * trans-intrinsic.c (trans-intrinsic.c): Handle optional arguments correctly for MIN and MAX intrinsics. * gfortran.dg/min_max_optional_1.f90: New test. * gfortran.dg/min_max_optional_2.f90: New test. * gfortran.dg/min_max_optional_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/min_max_optional_1.f90 trunk/gcc/testsuite/gfortran.dg/min_max_optional_2.f90 trunk/gcc/testsuite/gfortran.dg/min_max_optional_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31198
[Bug fortran/31198] wrong code: Max() with optional arguments
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:27 --- Fixed on mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.2.0 4.1.3 Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31198
[Bug bootstrap/32622] New: BOOT_CFLAGS is not passed to stage2 and stage3 compile
Hello! .../configure was invoked with: .../configure --with-mpfr=/usr/local --enable-languages=c,c++,fortran BOOT_CFLAGS=-O3 -march=nocona -msse3 -funroll-loops -ftree-vectorize -ffast-math -g as suggested in gccinstall.info. However, BOOT_CFLAGS were not passed to stage2 or stage3 compile, default -O2 -g -fomit-frame-pointer flags were used instead. -- Summary: BOOT_CFLAGS is not passed to stage2 and stage3 compile Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak 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=32622
[Bug fortran/32035] 'anonymous' may be used uninitialized in this function
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-22 11:15:35 |2007-07-04 07:34:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32035
[Bug fortran/31688] Bogus may be used uninitialized warning
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:43 --- *** This bug has been marked as a duplicate of 29459 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31688
[Bug fortran/29459] Spurious warning about uninitialized optional arguments
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:43 --- *** Bug 31688 has been marked as a duplicate of this bug. *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29459
[Bug fortran/29459] Spurious warning about uninitialized optional arguments
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:44 --- (In reply to comment #2) *** Bug 31688 has been marked as a duplicate of this bug. *** Code from PR31688: MODULE test IMPLICIT NONE CONTAINS SUBROUTINE overlap(s, lds, pab, force_a) INTEGER, INTENT(IN) :: lds REAL, DIMENSION(lds, lds, *), INTENT(INOUT) :: s REAL, DIMENSION(:), INTENT(IN), OPTIONAL:: pab REAL, INTENT(OUT) :: force_a if(.not.present(pab)) return force_a = pab(1)*s(1,1,1) END SUBROUTINE END MODULE test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29459
[Bug fortran/32594] INDEX is not simplified, leads to ICE
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:47 --- I think it's due to the fact that there is no simplification done for INDEX (in simplify.c). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2007-07-02 19:31:03 |2007-07-04 07:47:17 date|| Summary|ICE: bus error with attached|INDEX is not simplified, |code and June 28 MacOSX |leads to ICE |Intel binary) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32594
[Bug libfortran/32611] Print sign of negative zero
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:49 --- IIRC, F95 requires not to print the minus sign but F2003 allows to do it (and we should probably do it since we handle negative zeros well on most other counts). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32611
[Bug fortran/29459] Spurious warning about uninitialized optional arguments
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:50
---
Updated partial patch:
Index: trans-array.c
===
--- trans-array.c (revision 126249)
+++ trans-array.c (working copy)
@@ -1695,6 +1695,7 @@
desc = ss-data.info.descriptor;
offset = gfc_index_zero_node;
offsetvar = gfc_create_var_np (gfc_array_index_type, offset);
+ TREE_NO_WARNING (offsetvar) = 1;
TREE_USED (offsetvar) = 0;
gfc_trans_array_constructor_value (loop-pre, type, desc, c,
offset, offsetvar, dynamic);
Index: trans-decl.c
===
--- trans-decl.c(revision 126249)
+++ trans-decl.c(working copy)
@@ -633,20 +633,31 @@
for (dim = 0; dim GFC_TYPE_ARRAY_RANK (type); dim++)
{
if (GFC_TYPE_ARRAY_LBOUND (type, dim) == NULL_TREE)
-GFC_TYPE_ARRAY_LBOUND (type, dim) = create_index_var (lbound, nest);
+ {
+ GFC_TYPE_ARRAY_LBOUND (type, dim) = create_index_var (lbound,
nest);
+ TREE_NO_WARNING (GFC_TYPE_ARRAY_LBOUND (type, dim)) = 1;
+ }
/* Don't try to use the unknown bound for assumed shape arrays. */
if (GFC_TYPE_ARRAY_UBOUND (type, dim) == NULL_TREE
(sym-as-type != AS_ASSUMED_SIZE
|| dim GFC_TYPE_ARRAY_RANK (type) - 1))
-GFC_TYPE_ARRAY_UBOUND (type, dim) = create_index_var (ubound, nest);
+ {
+ GFC_TYPE_ARRAY_UBOUND (type, dim) = create_index_var (ubound,
nest);
+ TREE_NO_WARNING (GFC_TYPE_ARRAY_UBOUND (type, dim)) = 1;
+ }
if (GFC_TYPE_ARRAY_STRIDE (type, dim) == NULL_TREE)
-GFC_TYPE_ARRAY_STRIDE (type, dim) = create_index_var (stride, nest);
+ {
+ GFC_TYPE_ARRAY_STRIDE (type, dim) = create_index_var (stride,
nest);
+ TREE_NO_WARNING (GFC_TYPE_ARRAY_STRIDE (type, dim)) = 1;
+ }
}
if (GFC_TYPE_ARRAY_OFFSET (type) == NULL_TREE)
{
GFC_TYPE_ARRAY_OFFSET (type) = gfc_create_var_np (gfc_array_index_type,
offset);
+ TREE_NO_WARNING (GFC_TYPE_ARRAY_OFFSET (type)) = 1;
+
if (nest)
gfc_add_decl_to_parent_function (GFC_TYPE_ARRAY_OFFSET (type));
else
@@ -655,7 +666,10 @@
if (GFC_TYPE_ARRAY_SIZE (type) == NULL_TREE
sym-as-type != AS_ASSUMED_SIZE)
-GFC_TYPE_ARRAY_SIZE (type) = create_index_var (size, nest);
+{
+ GFC_TYPE_ARRAY_SIZE (type) = create_index_var (size, nest);
+ TREE_NO_WARNING (GFC_TYPE_ARRAY_SIZE (type)) = 1;
+}
if (POINTER_TYPE_P (type))
{
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29459
[Bug bootstrap/32622] BOOT_CFLAGS is not passed to stage2 and stage3 compile
--- Comment #1 from ubizjak at gmail dot com 2007-07-04 08:02 --- I misread the documentation, BOOT_CFLAGS should be added to make. However, having something like --default-boot-cflags=... would be a nice addition to configure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32622
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #19 from bonzini at gnu dot org 2007-07-04 08:16 --- Created an attachment (id=13843) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13843action=view) patch under testing QED (Quite Easily Done :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug bootstrap/32622] BOOT_CFLAGS is not passed to stage2 and stage3 compile
--- Comment #2 from spop at gcc dot gnu dot org 2007-07-04 08:12 --- Subject: Re: BOOT_CFLAGS is not passed to stage2 and stage3 compile Ok, here is the mini patch that captures BOOT_CFLAGS from configure line and pass it to the makefile machinery. Not tested yet, it's just an idea. --- Comment #3 from spop at gcc dot gnu dot org 2007-07-04 08:12 --- Created an attachment (id=13842) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13842action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32622
[Bug tree-optimization/32377] can't determine dependence (source/destination overlap without more than size)
--- Comment #12 from irar at il dot ibm dot com 2007-07-04 08:34 --- (In reply to comment #10) I have committed the attached patch to trunk. Sebastian Thanks a lot! Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #15 from pault at gcc dot gnu dot org 2007-07-04 08:50 --- is this still correct ? Adding Paul, so he can see this question and hopefully answer affirmatively. The patch was posted to the list 0615; whilst functional, in that it fixed the bugs, bootstrapped and regtested OK, it was not the whole job. The intention was to sort out some of the fundamental problems with characters and to get rid of some of the kludges in translation. The patch was also judged to be untimely relative to the 4.3 release schedule so I agreed to hold back. I am, in fact, working on it this week and hope to get it out of the door this weekend. I am contemplating breaking the patch up into stages, of which the fix to this PR would be one. What do you think? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)
--- Comment #5 from eres at il dot ibm dot com 2007-07-04 08:57 --- You can also try to tune --param max-variable-expansions-in-unroller. The default is to add one expansion (which seems to be the most helpful due to the fact that adding more expansions can increase register pressure). -- eres at il dot ibm dot com changed: What|Removed |Added CC||eres at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
[Bug fortran/32526] [4.3 regression] Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y'
--- Comment #5 from pault at gcc dot gnu dot org 2007-07-04 08:58 ---
(In reply to comment #4)
Adding Paul as CC.
This is indeed my doing - sorry. The cause is
PR fortran/31494
* match.c (gfc_match_call): If a host associated symbol is not
a subroutine, build a new symtree/symbol in the current name
space.
I have not understood why this is happening yet, in spite of hanging
diagnostics on both versions of gfc_match_call. The following fixes the
problem and bootstrap/regtests OK:
Index: gcc/fortran/module.c
===
*** gcc/fortran/module.c(revision 126214)
--- gcc/fortran/module.c(working copy)
*** read_module (void)
*** 3574,3580
if (st != NULL)
{
/* Check for ambiguous symbols. */
! if (st-n.sym != info-u.rsym.sym)
st-ambiguous = 1;
info-u.rsym.symtree = st;
}
--- 3574,3581
if (st != NULL)
{
/* Check for ambiguous symbols. */
! if (st-n.sym != info-u.rsym.sym
!!st-n.sym-attr.generic)
st-ambiguous = 1;
info-u.rsym.symtree = st;
}
However, I want to understand the necessity of this before submitting it. I
think that I am 24 hours away from this.
Paul
PS Michael, that's a very pretty fortran OO example - thanks for the report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32526
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #16 from jv244 at cam dot ac dot uk 2007-07-04 09:09 --- (In reply to comment #15) The patch was also judged to be untimely relative to the 4.3 release schedule so I agreed to hold back. since it is a regression wrt 4.1 , a fix could go in at 'anytime' ? If it is very invasive, one should fix 4.2 before 4.2.1 though... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #17 from jv244 at cam dot ac dot uk 2007-07-04 09:09 --- since it is a regression wrt 4.1 , a fix could go in at 'anytime' ? If it is very invasive, one should fix 4.2 before 4.2.1 though... one should *not* fix 4.2 of course -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)
--- Comment #6 from jv244 at cam dot ac dot uk 2007-07-04 09:23 --- (In reply to comment #5) You can also try to tune --param max-variable-expansions-in-unroller. The default is to add one expansion (which seems to be the most helpful due to the fact that adding more expansions can increase register pressure). there seems to be no effect from --param max-variable-expansions-in-unroller, I get the same timings for all values. I do notice that ifort is twice as fast as gfortran on the original loop on my machine (core2): gfortran -O3 -ffast-math -ftree-vectorize -march=native -funroll-loops -fvariable-expansion-in-unroller --param max-variable-expansions-in-unroller=4 pr25621.f90 ./a.out default loop 0.8680540 hand optimized loop 0.8640540 ifort -xT -O3 pr25621.f90 pr25621.f90(32) : (col. 0) remark: LOOP WAS VECTORIZED. pr25621.f90(33) : (col. 0) remark: LOOP WAS VECTORIZED. pr25621.f90(9) : (col. 2) remark: LOOP WAS VECTORIZED. ./a.out default loop 0.4400270 hand optimized loop 0.8760550 and it looks like ifort vectorizes the first loop (whereas gfortran does not ' unsupported use in stmt'). As a reference : gfortran -O3 -ffast-math -ftree-vectorize -march=native -funroll-loops pr25621.f90 ./a.out default loop 1.296081 hand optimized loop 0.8600540 the code actually used for testing is : ! simple loop ! assume N is even SUBROUTINE S31(a,b,c,N) IMPLICIT NONE integer :: N real*8 :: a(N),b(N),c integer :: i c=0.0D0 DO i=1,N c=c+a(i)*b(i) ENDDO END SUBROUTINE ! 'improved' loop SUBROUTINE S32(a,b,c,N) IMPLICIT NONE integer :: N real*8 :: a(N),b(N),c,tmp integer :: i c=0.0D0 tmp=0.0D0 DO i=1,N,2 c=c+a(i)*b(i) tmp=tmp+a(i+1)*b(i+1) ENDDO c=c+tmp END SUBROUTINE integer, parameter :: N=1024 real*8 :: a(N),b(N),c,tmp,t1,t2 a=0.0_8 b=0.0_8 DO i=1,200 CALL S31(a,b,c,N) ENDDO CALL CPU_TIME(t1) DO i=1,100 CALL S31(a,b,c,N) ENDDO CALL CPU_TIME(t2) write(6,*) default loop, t2-t1 CALL CPU_TIME(t1) DO i=1,100 CALL S32(a,b,c,N) ENDDO CALL CPU_TIME(t2) write(6,*) hand optimized loop,t2-t1 END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
[Bug other/32508] g++ emits concept checks instantiations (code size blows up).
--- Comment #2 from pluto at agmk dot net 2007-07-04 09:25 --- 4.3.0 20070703 fails to. -- pluto at agmk dot net changed: What|Removed |Added Known to fail|4.1.2 4.2.1 |4.1.2 4.2.1 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32508
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #18 from pault at gcc dot gnu dot org 2007-07-04 09:26 --- (In reply to comment #17) since it is a regression wrt 4.1 , a fix could go in at 'anytime' ? If it is very invasive, one should fix 4.2 before 4.2.1 though... one should *not* fix 4.2 of course All this argues for breaking it up into chunks. I'll spend this afternoon on it, rather than going on the conference excursion. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug tree-optimization/32544] gcc 4.2.1 miscompiles Mesa's r300 DRI driver with -ftree-vrp
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-04 09:49 --- Sorry, I can't see what is wrong. There is no effective difference in assembly with/without -ftree-vrp. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32544
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #19 from jv244 at cam dot ac dot uk 2007-07-04 10:05 --- (In reply to comment #18) I'll spend this afternoon on it, rather than going on the conference excursion. depending on location/weather, I'd go for the conference excursion ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug tree-optimization/32500] [4.2 Regression] Loop optimization limits range to size of array used inside loop
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-07-04 10:16
---
This is SCEV. From
L2:;
i_7 = ASSERT_EXPR i_20, i_20 4;
i.10_10 = (unsigned int) i_7;
D.2489_11 = i.10_10 - 7;
if (D.2489_11 = 2) goto L3; else goto L4;
we have
Found new range for i.10_10: [5, 12]
Visiting statement:
D.2489_11 = i.10_10 - 7;
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = D.2489_11)
(get_scalar_evolution
(scalar = D.2489_11)
(scalar_evolution = {4294967290, +, 1}_1))
(set_scalar_evolution
(scalar = D.2489_11)
(scalar_evolution = {4294967290, +, 1}_1))
)
(instantiate_parameters
(loop_nb = 1)
(chrec = {4294967290, +, 1}_1)
(res = {4294967290, +, 1}_1))
Found new range for D.2489_11: [4294967290, +INF]
which is wrong. The new range should be ~[5, 4294967290].
scev_probably_wraps_p() returns false for the above chrec because for
the loop in question estimated_nb_iterations is 4(!) which is derived
from infer_loop_bounds_from_undefined. On the trunk this is fixed
by rewriting number of iterations analysis. On the 4.2 branch we
can fix this conservatively by
Index: tree-ssa-loop-niter.c
===
--- tree-ssa-loop-niter.c (revision 126260)
+++ tree-ssa-loop-niter.c (working copy)
@@ -1747,6 +1747,12 @@ infer_loop_bounds_from_undefined (struct
{
bb = bbs[i];
+ /* If BB is not executed in each iteration of the loop, we cannot
+use the operations in it to infer reliable upper bound on the
+# of iterations of the loop. */
+ if (!dominated_by_p (CDI_DOMINATORS, loop-latch, bb))
+ continue;
+
for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (bsi))
{
tree stmt = bsi_stmt (bsi);
I'm going to test this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2007-06-26 10:45:47 |2007-07-04 10:16:51
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
[Bug c/30595] gcc3.4.6 generates incorrect ppc32 code for combination of bitfields and shifts
--- Comment #1 from clemens dot koller at anagramm dot de 2007-07-04 10:34 --- Cannot reproduce this problem on PPC32 with gcc-4.2.0. The result is with all -Ox correct: 234500 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30595
[Bug c++/30854] [4.3 Regression] Wrong number of arguments printed for constructor
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-02-23 00:09:52 |2007-07-04 10:37:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30854
[Bug target/32623] New: m68k: Inaccurate multiply cost on some V2 ColdFire CPUs.
When building for a ColdFire V2 CPU, GCC will prefer using shift-and-add over multiply, even if multiply would generate code that is smaller and as fast, if not faster, on the target CPU in question. This happens because the multiply cost is based on ColdFire version rather than the capabilities. Basing the multiply cost on the presence of a MAC (or EMAC) unit on the target CPU would be more accurate, at least on ColdFire V2. See the definitions of MULL_COST and MULW_COST in gcc/config/m68k/m68k.c, at about line 2138. -- Summary: m68k: Inaccurate multiply cost on some V2 ColdFire CPUs. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: betheking at spray dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32623
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #20 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-07-04 10:51 --- Subject: Re: [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings jv244 at cam dot ac dot uk wrote: --- Comment #19 from jv244 at cam dot ac dot uk 2007-07-04 10:05 --- (In reply to comment #18) I'll spend this afternoon on it, rather than going on the conference excursion. depending on location/weather, I'd go for the conference excursion ;-) Warsaw, 18.5 C, overcast. Of course, Paul's work on gfortran is more important than anything else :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)
--- Comment #7 from dorit at gcc dot gnu dot org 2007-07-04 11:14 --- The vectorizer reports: pr25621.f90:7: note: reduction used in loop. pr25621.f90:7: note: Unknown def-use cycle pattern. because of the seemingly redundant assignment: c__lsm.63_30 = D.1361_38; which uses the reduction variable D.1361_38 inside the loop (only to be used outside the loop). Need to teach the vectorizer to ignore this assignment or clean it away before the vectorizer. bb 4: # prephitmp.57_5 = PHI storetmp.55_34(3), D.1361_38(5) # i_3 = PHI 1(3), i_40(5) D.1357_31 = i_3 + -1; D.1358_33 = (*a_32(D))[D.1357_31]; D.1359_36 = (*b_35(D))[D.1357_31]; D.1360_37 = D.1359_36 * D.1358_33; D.1361_38 = prephitmp.57_5 + D.1360_37; c__lsm.63_30 = D.1361_38; i_40 = i_3 + 1; if (i_3 == D.1339_28) goto bb 6; else goto bb 5; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #30 from dnovillo at google dot com 2007-07-04 11:22 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code On 7/3/07 11:28 PM, mmitchel at gcc dot gnu dot org wrote: --- Comment #29 from mmitchel at gcc dot gnu dot org 2007-07-04 03:28 --- Diego, does this problem still exist on the 4.2 branch? I see that you checked in a patch, which you suggest may not be a complete fix, but does this test case still fail? Yes, the problem still exists on 4.2 and mainline. The patch is valid in that it fixes a codegen deficiency, but it only works around this bug. The test case does not fail anymore, and getting another one to fail may be tricky (it's a fairly rare bug, unfortunately). A real fix is in the works, but it's not clear when it might be ready. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)
--- Comment #8 from eres at il dot ibm dot com 2007-07-04 11:24 --- I think c__lsm.63_30 is created during the store motion optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #21 from pault at gcc dot gnu dot org 2007-07-04 11:32 --- Warsaw, 18.5 C, overcast. Of course, Paul's work on gfortran is more important than anything else :-) There is also the question of what I am expected to do over the weekend after three weeks away from home. Catching up with gfc will not even be on the list. P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug tree-optimization/32482] [4.3 Regression] ICE verify_ssa failed
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-04 11:45 --- Subject: Bug 32482 Author: rguenth Date: Wed Jul 4 11:44:58 2007 New Revision: 126314 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126314 Log: 2007-07-04 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/32482 * tree-ssa-ifcombine.c (recognize_single_bit_test): Use the original ssa name if we didn't find a shift expression. Fix shift constant for bit zero test. * gcc.c-torture/compile/pr32482.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32482.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ifcombine.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32482
[Bug tree-optimization/32482] [4.3 Regression] ICE verify_ssa failed
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-07-04 11:46 --- 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=32482
[Bug target/31897] [4.3 Regression] 30% speed regression with -m32 on Opteron with rnflow
--- Comment #2 from jakub at gcc dot gnu dot org 2007-07-04 11:57 --- Can't reproduce this, gcc 4.3 actually seems to be faster (tests done on Intel quadcore Core2): /usr/src/gcc-4.2/obj/gcc/gfortran -B /usr/src/gcc-4.2/obj/gcc/ -L /usr/src/gcc-4.2/obj/x86_64-unknown-linux-gnu/32/libgfortran/.libs/ -Wl,-rpath,/usr/src/gcc-4.2/obj/x86_64-unknown-linux-gnu/32/libgfortran/.libs/ -m32 -march=opteron -ffast-math -funroll-loops -ftree-vectorize -ftree-loop-linear -O3 rnflow.f90 -o rnflow42 /usr/src/gcc/obj/gcc/gfortran -B /usr/src/gcc/obj/gcc/ -L /usr/src/gcc/obj/x86_64-unknown-linux-gnu/32/libgfortran/.libs/ -Wl,-rpath,/usr/src/gcc/obj/x86_64-unknown-linux-gnu/32/libgfortran/.libs/ -m32 -march=opteron -ffast-math -funroll-loops -ftree-vectorize -ftree-loop-linear -O3 rnflow.f90 -o rnflow43 gfortran -m32 -march=opteron -ffast-math -funroll-loops -ftree-vectorize -ftree-loop-linear -O3 rnflow.f90 -o rnflow41 for i in 1 2 3; do time ./rnflow4$i /dev/null; time ./rnflow4$i /dev/null; done real0m30.003s user0m29.601s sys 0m0.399s real0m29.811s user0m29.436s sys 0m0.370s real0m29.875s user0m29.468s sys 0m0.403s real0m29.824s user0m29.441s sys 0m0.378s real0m26.007s user0m25.627s sys 0m0.376s real0m25.822s user0m25.403s sys 0m0.415s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31897
[Bug tree-optimization/32500] [4.2 Regression] Loop optimization limits range to size of array used inside loop
--- Comment #13 from ed at fxq dot nl 2007-07-04 12:06 --- Hello Richard, I can confirm that the patch fixes this regression. I just installed a patch compiler on my FreeBSD box and I get a proper binary, even when I build it with '-O2 -ftree-vrp' (just to be sure). Thanks! Any chance this patch will make it into 4.2.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
[Bug target/31897] [4.3 Regression] 30% speed regression with -m32 on Opteron with rnflow
--- Comment #3 from ubizjak at gmail dot com 2007-07-04 12:29 --- (In reply to comment #2) Can't reproduce this, gcc 4.3 actually seems to be faster (tests done on Intel quadcore Core2): On core2 the bug doesn't trigger, but it shows on FC4 with: vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 3.60GHz stepping: 10 cpu MHz : 3600.970 cache size : 2048 KB This is one of most mysterious bugs I've ever seen. The _idamax routine is exactly the same for both builds, but it shows such a difference. I have analyzed this with cachegrind but nothing sticks out there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31897
[Bug tree-optimization/32032] [4.3 Regression] Inliner not setting has_volatile_ops
--- Comment #4 from jakub at gcc dot gnu dot org 2007-07-04 12:31 --- This doesn't ICE any longer on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32032
[Bug target/31897] [4.3 Regression] 30% speed regression with -m32 on Opteron with rnflow
--- Comment #4 from ubizjak at gmail dot com 2007-07-04 12:32 --- (In reply to comment #1) gfortran -ffast-math -funroll-loops -O3 -msse3 -mfpmath=387 rnflow.f90 time ./a.out user0m37.982s gfortran -ffast-math -funroll-loops -O3 -msse3 -mfpmath=387 -ftree-vectorize rnflow.f90 time ./a.out user0m55.031s This is on XEON as in Comment #3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31897
[Bug tree-optimization/32500] [4.2 Regression] Loop optimization limits range to size of array used inside loop
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-07-04 12:38 --- Subject: Bug 32500 Author: rguenth Date: Wed Jul 4 12:38:23 2007 New Revision: 126315 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126315 Log: 2007-07-04 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/32500 * tree-ssa-loop-niter.c (infer_loop_bounds_from_undefined): Only use basic blocks that are always executed to infer loop bounds. * gcc.c-torture/execute/pr32500.c: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr32500.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-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
[Bug tree-optimization/32500] [4.2 Regression] Loop optimization limits range to size of array used inside loop
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-07-04 12:40 --- 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=32500
[Bug tree-optimization/32500] [4.2 Regression] Loop optimization limits range to size of array used inside loop
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-07-04 12:39 --- Subject: Bug 32500 Author: rguenth Date: Wed Jul 4 12:39:42 2007 New Revision: 126316 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126316 Log: 2007-07-04 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/32500 * gcc.c-torture/execute/pr32500.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr32500.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
[Bug fortran/30929] -pedantic-error and -Werror don't produce errors!
--- Comment #6 from manu at gcc dot gnu dot org 2007-07-04 13:08 --- (In reply to comment #4) No idea how to untangle -pedantic from -Wtabs or -Wampersand if -pedantic-errors has been given, but -Werror has not. What gfortran should do is that if pedantic enables Wtabs, then the warnings should be of the form: if (pedantic warn_tabs) pedantic(whatever); else if (warn_tabs) warning(whatever); pedantic() emits errors if -pedantic-errors, otherwise it emits warnings. warning() emits errors if -Werror, otherwise it emits warnings. I guess there would be similar functions in gfortran. (It would be great to integrate the diagnostics machinery but making things work in a similar way is already a step forward). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929
[Bug target/32622] BOOT_CFLAGS is not passed to stage2 and stage3 compile
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-04 13:27 --- Actually this is caused by config/mh-x86omitfp. If you disable BOOT_CFLAGS in that file, it will just work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32622
[Bug target/32558] v850: unrecognizable insn compiling libgcc2 on 64-bit CPU
--- Comment #3 from nickc at redhat dot com 2007-07-04 13:28 --- Hi Rask, Well the patch is definitely an improvement, so I have applied it. I will try to find time to look at the regressions in the next week or two. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32558
[Bug other/31349] [4.3 Regression] gcc -v --help returns no options for C, C++
--- Comment #7 from nickc at redhat dot com 2007-07-04 13:40 --- Subject: Re: [4.3 Regression] gcc -v --help returns no options for C, C++ Hi Brooks, So, if I understand correctly: all of the options are listed somewhere, but we no longer provide any information about which of the shared options under language related options are supported by a given language's front end? Correct. Well by default anyway. See below. While this may have been intentional, I do not think it counts as a feature - the listing of the common options without definitions at the top of the option listing did not take up a significant amount of space, and it provided very useful information that's now absent. OK. (On the other hand, moving the _descriptions_ of the shared options to a single listing is a good thing, IMO -- I want to make it clear that I'm not objecting to the bulk of this change!) You can find out all the options supported by a given language, including the ones that it shares with other languages and including those that do not have a description by using the --help=language feature. For example: % gcc --help=java The following options are supported by the language Java: -I This switch lacks documentation -M This switch lacks documentation -MD_This switch lacks documentation -MF This switch lacks documentation -MM This switch lacks documentation -MMD_ This switch lacks documentation -MP This switch lacks documentation -MT This switch lacks documentation -Wall This switch lacks documentation -Wall-deprecation This switch lacks documentation -Wall-javadoc This switch lacks documentation -Wassert-identifier This switch lacks documentation -Wchar-concat This switch lacks documentation -Wcondition-assign This switch lacks documentation -Wconstructor-name This switch lacks documentation -Wdep-ann This switch lacks documentation -WdeprecatedWarn if a deprecated compiler feature, class, method, or field is used [etc...] So I think that the bone of contention here is what should be listed by --help -v. I think that leaving out options which have no description is a good default. If for no other reason than to encourage people to write descriptions for the options so that they are then listed in the --help output. Do you still feel that --help -v should list undocumented options ? Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #20 from bonzini at gnu dot org 2007-07-04 13:54 --- The attached patch makes PR30311 resurface; this seems like a minor problem because that code is dubious, and can be worked around by not doing the transformation when the modes mismatch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug target/32622] BOOT_CFLAGS is not passed to stage2 and stage3 compile
--- Comment #5 from spop at gcc dot gnu dot org 2007-07-04 13:42 --- Subject: Re: BOOT_CFLAGS is not passed to stage2 and stage3 compile Actually this is caused by config/mh-x86omitfp. If you disable BOOT_CFLAGS in that file, it will just work. Right, that's also what I saw, and the fix that I'm testing now is to replace that line from mh-x86omitfp by BOOT_CFLAGS += -fomit-frame-pointer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32622
[Bug rtl-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360
--- Comment #18 from rakdver at gcc dot gnu dot org 2007-07-04 13:32 --- (In reply to comment #0) The fix to PR31360 has caused significant code size regressions on ARM-EABI. An example of this is from zlib (adler32.c) and is attached, compile with -Os -mcpu=arm7tdmi -fno-short-enums -w The new code: 1) Hoists a register containing 0 out of the loop 2) Uses that *only* as a copy into another register (mov reg, #0 costs exactly the same as mov reg, reg) Actually, rtx_cost claims that mov reg, #0 costs 20, while mov reg, reg costs 16. Fixing this (assuming that is indeed wrong) will not fix the problem (without further changes to the invariant motion), but it is the first step. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
[Bug fortran/32526] [4.3 regression] Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y'
--- Comment #6 from pault at gcc dot gnu dot org 2007-07-04 14:05 --- (In reply to comment #5) OK, I now have it understood. The patch in the previous comment is the clue. The patch for pr31494 was marking generic interfaces as subroutines, thereby screwing up the mechanism for detecting ambiguity. The correct solution is regtesting, right now. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-06-27 21:05:26 |2007-07-04 14:05:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32526
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #9 from ubizjak at gmail dot com 2007-07-04 14:11 --- (In reply to comment #1) Most likely -pg is changing the alignment of the stack which is incorrect. Oh -pg code is emitted by the target specific code so this is a target issue. Hm, on x86_64 pg inserts: fprintf (file, \tleaq\t%sP%d@(%%rip),%%r11\n, LPREFIX, labelno); fprintf (file, [EMAIL PROTECTED](%%rip)\n, MCOUNT_NAME); So, it loads %r11 and calls mcount. The only thing that can go wrong is, that some value in %r11 gets rewritten. Could you look what happens with %r11 around the point of failure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #10 from ubizjak at gmail dot com 2007-07-04 14:16 --- (In reply to comment #9) So, it loads %r11 and calls mcount. The only thing that can go wrong is, that some value in %r11 gets rewritten. Not even that because x86_64 is a NO_PROFILE_COUNTERS by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
Re: [Bug tree-optimization/32328] [4.2/4.3 Regression] -fstrict-aliasing causes skipped code
On 4 Jul 2007 03:29:25 -, mmitchel at gcc dot gnu dot org [EMAIL PROTECTED] wrote: -- Just as an update: I have been working with richi (I code, he tests :P) diligently on a patch for mainline, and have one that fixes the dealii regression (and thus, should fix this as well).
[Bug tree-optimization/32328] [4.2/4.3 Regression] -fstrict-aliasing causes skipped code
--- Comment #14 from dberlin at gcc dot gnu dot org 2007-07-04 14:16 --- Subject: Re: [4.2/4.3 Regression] -fstrict-aliasing causes skipped code On 4 Jul 2007 03:29:25 -, mmitchel at gcc dot gnu dot org [EMAIL PROTECTED] wrote: -- Just as an update: I have been working with richi (I code, he tests :P) diligently on a patch for mainline, and have one that fixes the dealii regression (and thus, should fix this as well). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug tree-optimization/32606] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1026
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-04 14:24 ---
Here is a reduced testcase which has only one function in it:
int inb(int);
void is870(unsigned int wkport, unsigned char j)
{
unsigned int tmport;
unsigned char i;
for (i = 0; i 16; i++)
{
tmport = wkport + 0x18;
tmport += 0x07;
while ((inb(tmport) 0x80) == 0)
{
if ((inb(tmport) 0x01) != 0)
{
tmport -= 0x06;
tmport += 0x06;
}
}
tmport = wkport + 0x14;
tmport += 0x04;
tmport += 0x07;
widep_in1:
if ((j 0x01) != 0)
{
tmport -= 0x06;
tmport += 0x06;
goto widep_in1;
}
while ((inb(tmport) 0x80) == 0) {}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32606
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #11 from ubizjak at gmail dot com 2007-07-04 14:26 ---
Hm...
--cut here--
// just a stupid testcase, don't bother with source
long long test(long long a, long long b)
{
return a / b;
}
--cut here--
cc1 -O2:
test:
.LFB2:
movq%rdi, %rdx
movq%rdi, %rax
sarq$63, %rdx
idivq %rsi
ret
cc1 -O1 -p:
test:
.LFB2:
pushq %rbp
.LCFI0:
movq%rsp, %rbp
.LCFI1:
callmcount
movq%rdi, %rdx
movq%rdi, %rax
sarq$63, %rdx
idivq %rsi
leave
ret
cc1 -O2 -p
test:
.LFB2:
pushq %rbp
.LCFI0:
movq%rsp, %rbp
.LCFI1:
callmcount
leave
movq%rdi, %rdx
movq%rdi, %rax
sarq$63, %rdx
idivq %rsi
ret
Just a wild guess, could this depend on PR32450? Could you check if there is an
access to stack after leave insn?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug fortran/32594] INDEX is not simplified, leads to ICE
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-07-04 14:36
---
Please forget comment #3. The reason for the ICE is that substring
simplification was written without taking into account the possibility of
foo(14:) or foo(:14), ie one of the substring bounds being implicit. The
following patch fixes it, I'm regtesting and will try to write a few more
testcases before submitting it for review:
Index: expr.c
===
--- expr.c (revision 126249)
+++ expr.c (working copy)
@@ -1503,9 +1503,19 @@ gfc_simplify_expr (gfc_expr *p, int type
char *s;
int start, end;
- gfc_extract_int (p-ref-u.ss.start, start);
- start--; /* Convert from one-based to zero-based. */
- gfc_extract_int (p-ref-u.ss.end, end);
+ if (p-ref-u.ss.start)
+ {
+ gfc_extract_int (p-ref-u.ss.start, start);
+ start--; /* Convert from one-based to zero-based. */
+ }
+ else
+ start = 0;
+
+ if (p-ref-u.ss.end)
+ gfc_extract_int (p-ref-u.ss.end, end);
+ else
+ end = p-value.character.length - 1;
+
s = gfc_getmem (end - start + 2);
memcpy (s, p-value.character.string + start, end - start);
s[end - start + 1] = '\0'; /* TODO: C-style string. */
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Keywords||patch
Last reconfirmed|2007-07-04 07:47:17 |2007-07-04 14:36:19
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32594
[Bug middle-end/32624] New: [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify
The following part of r126198 causes a 5% slowdown of tramp3d for the non-leafify tests (with leafify it makes it run faster): 2007-07-02 Richard Guenther [EMAIL PROTECTED] * fold-const.c (fold_convert): Revert fix for PR15988. * tree-inline.c (setup_one_parameter): Instead fix it here by using fold_build1 instead of fold_convert and checking for error_mark_node. Convert only if the conversion is necessary. Index: fold-const.c === --- fold-const.c(revision 126197) +++ fold-const.c(revision 126198) @@ -2262,9 +2262,7 @@ fold_convert (tree type, tree arg) || TREE_CODE (orig) == ERROR_MARK) return error_mark_node; - if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (orig) - || lang_hooks.types_compatible_p (TYPE_MAIN_VARIANT (type), - TYPE_MAIN_VARIANT (orig))) + if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (orig)) return fold_build1 (NOP_EXPR, type, arg); switch (TREE_CODE (type)) Index: tree-inline.c === --- tree-inline.c (revision 126197) +++ tree-inline.c (revision 126198) @@ -1278,10 +1278,15 @@ setup_one_parameter (copy_body_data *id, tree init_stmt; tree var; tree var_sub; - tree rhs = value ? fold_convert (TREE_TYPE (p), value) : NULL; + tree rhs = value; tree def = (gimple_in_ssa_p (cfun) ? gimple_default_def (id-src_cfun, p) : NULL); + if (value + value != error_mark_node + !useless_type_conversion_p (TREE_TYPE (p), TREE_TYPE (value))) +rhs = fold_build1 (NOP_EXPR, TREE_TYPE (p), value); + /* If the parameter is never assigned to, has no SSA_NAMEs created, we may not need to create a new variable here at all. Instead, we may be able to just use the argument value. */ I am investigating why. -- Summary: [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: middle-end AssignedTo: rguenth at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #12 from jv244 at cam dot ac dot uk 2007-07-04 14:51 --- (In reply to comment #11) Just a wild guess, could this depend on PR32450? Could you check if there is an access to stack after leave insn? Hi Uros, thanks for looking into this, but I'm afraid I don't really understand what you're asking for. Also the PR mentioned in the above comment is a circular reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug libfortran/32611] Print sign of negative zero
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-07-04 15:23 --- OK, you talked me into it. :) -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-04 07:08:52 |2007-07-04 15:23:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32611
[Bug libstdc++/31906] -Xcompiler is inserted after -Xlinker when building libstdc++
--- Comment #5 from pcarlini at suse dot de 2007-07-04 15:34 --- Therefore, can we close the PR? -- pcarlini at suse dot de changed: What|Removed |Added CC||zackw at panix dot com Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
[Bug middle-end/32624] [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-04 16:11 --- This seems to be an aliasing problem. Somehow we do not prune SMTs enough after the patch. MPT grouping doesn't trigger in. An example function to look at is (x86_64) _ZN14MultiArgKernelI9MultiArg4I5FieldI22UniformRectilinearMeshI10MeshTraitsILi3Ed21UniformRectilinearTag12CartesianTagLi3EEEd10BrickViewUES9_S9_S9_E15EvaluateLocLoopIN6Forgas5CentYILi3EEELi3EEE3runEv if you look at the alias6 dump (the one before lim which does no longer move invariant integer loads out of the inner loop) you can see: without the patch: # VUSE SMT.21607_161(D) D.852018_33 = op$multiArg_m_7-a1_m.fieldEngine_m.data_m.blockControllerPtr_m.ptr_m; with the patch (only the tree-inline.c part is actually necessary): # VUSE SMT.21592_132(D), SMT.21595_227 D.854673_30 = op$multiArg_m_19-a1_m.fieldEngine_m.data_m.blockControllerPtr_m.ptr_m; it doesn't make sense that there is a difference in pruning. Really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug middle-end/32624] [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-04 16:12 --- Created an attachment (id=13844) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13844action=view) alias6 dump of the function without the patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug libstdc++/30264] libstdc++-v3 compile error - conflicts with previous using declaration
--- Comment #4 from pcarlini at suse dot de 2007-07-04 16:16 --- Feedback not forthcoming. -- pcarlini at suse dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30264
[Bug fortran/32613] [4.2 regression] Different results depending on unnecessary variable declaration
--- Comment #2 from kargl at gcc dot gnu dot org 2007-07-04 16:24 ---
I've compared the output of -fdump-tree-original for 4.2 and trunk, and
the only significant difference is
internal (j)
{
int4 k;
+ int4 i;
logical4 __result_internal;
That is, the implicitly typed 'i' in trunk is not being host associated
with the 'i' in the procedure INTERNAL, so INTERNAL gets a local
variable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug fortran/32613] [4.2 regression] Different results depending on unnecessary variable declaration
--- Comment #3 from kargl at gcc dot gnu dot org 2007-07-04 16:25 --- I thought I had confirmed this as a bug. Let's try again. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-07-03 16:24:15 |2007-07-04 16:25:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug fortran/32613] [4.2 regression] Different results depending on unnecessary variable declaration
--- Comment #4 from kargl at gcc dot gnu dot org 2007-07-04 16:27 --- Add wrong-code keyword. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug middle-end/32624] [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-04 16:12 --- Created an attachment (id=13845) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13845action=view) alias6 dump of the function with the patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug middle-end/32624] [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-04 16:31 --- So, the following patch brings performance back in-line: Index: tree-inline.c === --- tree-inline.c (revision 126325) +++ tree-inline.c (working copy) @@ -1283,8 +1283,7 @@ setup_one_parameter (copy_body_data *id, ? gimple_default_def (id-src_cfun, p) : NULL); if (value - value != error_mark_node - !useless_type_conversion_p (TREE_TYPE (p), TREE_TYPE (value))) + value != error_mark_node) rhs = fold_build1 (NOP_EXPR, TREE_TYPE (p), value); /* If the parameter is never assigned to, has no SSA_NAMEs created, which doesn't make sense, as it is then just unconditionally adding a temporary and a conversion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug target/32337] [4.3 Regression] Error: Register number out of range 0..1
--- Comment #1 from jakub at gcc dot gnu dot org 2007-07-04 16:35 --- Created an attachment (id=13846) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13846action=view) gcc43-pr32337.patch The problem seems to be caused by the addition of the emitted_frame_related_regs array, there are several issues I found (see this patch) and in the end two of the 3 saved registers (RP, PFS, FP) were saved in the same register, which caused severe havoc. I'll try to bootstrap/regtest this on ia64-linux, so far I have only tested that it cures the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32337
[Bug tree-optimization/16913] [4.0/4.1/4.2/4.3 Regression] restrict does not make a difference
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-07-04 17:02 --- Which is almost the best you can do :). Well except to use store with update but that is an IV-OPTs issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16913
[Bug fortran/32526] [4.3 regression] Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y'
--- Comment #7 from patchapp at dberlin dot org 2007-07-04 17:15 --- Subject: Bug number PR32526 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-07/msg00381.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32526
[Bug target/31388] ICE building libiberty multilib for mips16 multilibs
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-07-04 17:18 --- Subject: Bug 31388 Author: mmitchel Date: Wed Jul 4 17:18:22 2007 New Revision: 126329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126329 Log: PR c++/31388 * cp-tree.h (ARITHMETIC_TYPE): Include COMPLEX_TYPE. * typeck.c (type_after_usual_arithmetic_conversions): Adjust, as COMPLEX_TYPE is now an ARITHMETIC_TYPE. * init.c (build_zero_init): Adjust, as COMPLEX_TYPE is now a SCALAR_TYPE. * typeck2.c (digest_init): Allow brace-enclosed initializers for COMPLEX_TYPE, even though that is now a SCALAR_TYPE. PR c++/31338 * g++.dg/ext/complex2.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/ext/complex2.C - copied unchanged from r124172, trunk/gcc/testsuite/g++.dg/ext/complex2.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/cp-tree.h branches/gcc-4_2-branch/gcc/cp/init.c branches/gcc-4_2-branch/gcc/cp/typeck.c branches/gcc-4_2-branch/gcc/cp/typeck2.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31388
[Bug c++/31338] [4.1/4.2 regression] Cannot apply ! to complex constants
--- Comment #8 from mmitchel at gcc dot gnu dot org 2007-07-04 17:18 --- Subject: Bug 31338 Author: mmitchel Date: Wed Jul 4 17:18:22 2007 New Revision: 126329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126329 Log: PR c++/31388 * cp-tree.h (ARITHMETIC_TYPE): Include COMPLEX_TYPE. * typeck.c (type_after_usual_arithmetic_conversions): Adjust, as COMPLEX_TYPE is now an ARITHMETIC_TYPE. * init.c (build_zero_init): Adjust, as COMPLEX_TYPE is now a SCALAR_TYPE. * typeck2.c (digest_init): Allow brace-enclosed initializers for COMPLEX_TYPE, even though that is now a SCALAR_TYPE. PR c++/31338 * g++.dg/ext/complex2.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/ext/complex2.C - copied unchanged from r124172, trunk/gcc/testsuite/g++.dg/ext/complex2.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/cp-tree.h branches/gcc-4_2-branch/gcc/cp/init.c branches/gcc-4_2-branch/gcc/cp/typeck.c branches/gcc-4_2-branch/gcc/cp/typeck2.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
[Bug c++/31338] [4.1 regression] Cannot apply ! to complex constants
--- Comment #9 from mmitchel at gcc dot gnu dot org 2007-07-04 17:27 --- Fixed in 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.1/4.2 regression] Cannot |[4.1 regression] Cannot |apply ! to complex|apply ! to complex |constants |constants http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
[Bug tree-optimization/32500] [4.2 Regression] Loop optimization limits range to size of array used inside loop
--- Comment #17 from ed at fxq dot nl 2007-07-04 17:35 --- Sorry if I'm being a nitpick... The committed testcase contains a small error; it has an off-by-one bug that causes a small buffer overflow. The line: foo(numbers[i]); should be replaced with: foo(numbers[i - 1]); It shouldn't cause any real problems, because it's just a testcase, but maybe some quite intelligent new optimizer might trip on that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
[Bug fortran/32613] [4.2 regression] Different results depending on unnecessary variable declaration
--- Comment #5 from pault at gcc dot gnu dot org 2007-07-04 17:44 --- This is my doing - that makes two this week. *groan* The regression is caused by the patch for pr31204, which goes back to April. For some reason that I do not yet see, the variable i in the statement function is being treated as if it were an implied do-loop iterator. I'm on to it. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-07-04 16:25:56 |2007-07-04 17:44:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer
--- Comment #18 from pinskia at gcc dot gnu dot org 2007-07-04 17:58 --- Yep this was fixed by Pointer_plus. The load of hmm-tsc is no longer in the inner most loop. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] |Tree loop optimizer does|Tree loop optimizer does |worse job than RTL loop |worse job than RTL loop |optimizer |optimizer http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643
[Bug bootstrap/32625] New: Bootstrap comparison failure!
cat ../gcc/LAST_UPDATED Wed Jul 4 19:21:37 CEST 2007 Wed Jul 4 17:21:37 UTC 2007 (revision 126328) rm -f stage_current make[3]: Leaving directory `/data/vondele/gcc_trunk/obj' Comparing stages 2 and 3 tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtbeginS.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtbeginT.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtfastmath.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtbegin.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtprec32.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtprec64.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtprec80.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtendS.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtend.o' for reading: No such file or directory Bootstrap comparison failure! ./32/crtbeginS.o differs ./32/crtbeginT.o differs ./32/crtfastmath.o differs ./32/crtbegin.o differs ./32/crtprec32.o differs ./32/crtprec64.o differs ./32/crtprec80.o differs ./32/crtendS.o differs ./32/crtend.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/data/vondele/gcc_trunk/obj' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/data/vondele/gcc_trunk/obj' make: *** [bootstrap] Error 2 -- Summary: Bootstrap comparison failure! Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32625
[Bug bootstrap/32625] Bootstrap comparison failure!
--- Comment #1 from jv244 at cam dot ac dot uk 2007-07-04 18:00 --- could be due to an interupted restarted build. I'm trying again with a clean build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32625
[Bug fortran/32613] [4.3 regression] Different results depending on unnecessary variable declaration
--- Comment #6 from burnus at gcc dot gnu dot org 2007-07-04 18:10 --- This a regression with respect to 4.2. I read this as: Works in 4.2.x, fails in 4.3, which is also what I get; I therefore changed the summary from 4.2 regression to 4.3 regression. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 Known to work||4.2.1 Summary|[4.2 regression] Different |[4.3 regression] Different |results depending on|results depending on |unnecessary variable|unnecessary variable |declaration |declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug fortran/32626] New: Run-time check for recursive functions
We probably need:
-fcheck-*
with
all
bounds
pointers
recursive
The recursive test is simple. C example:
bla(...)
{
static recursive = 0;
if(recursive)
exit_with_error
recursive = 1
...
recursive = 0; // Last statement
}
--
Summary: Run-time check for recursive functions
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32626
