I believe there is an off-by-one typo in the examples for -floop-strip-mine and
-floop-block, see the attached patch.
--
Summary: typo in the example for -floop-strip-mine
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: trivial
--- Comment #1 from kasal at ucw dot cz 2008-10-01 07:57 ---
Created an attachment (id=16437)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16437action=view)
patch for the typos
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37690
--- Comment #8 from bonzini at gnu dot org 2008-10-01 08:01 ---
Subject: Re: [4.4 regression] Building 64-bit libada fails
on Solaris/x86: alignment error
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01990.html
Ok.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37681
--- Comment #5 from dodji at gcc dot gnu dot org 2008-10-01 09:31 ---
Created an attachment (id=16438)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16438action=view)
Second version of the patch
@Jakub: Please find attached a second version of the patch that should address
your
--- Comment #27 from dannysmith at users dot sourceforge dot net
2008-10-01 10:22 ---
(In reply to comment #13)
Created an attachment (id=16425)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16425action=view) [edit]
Revised patch with correct section switching
That patch
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-01 10:52 ---
Dup of PR37285?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-01 10:54 ---
Preprocessed source?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from laurent at guerby dot net 2008-10-01 11:14 ---
I checked and the bahviour hasn't changed in the past three years, libada is
not rebuilt when the backend is.
If it's accepted as normal (Paolo?) I'll close this report.
--
laurent at guerby dot net changed:
--- Comment #5 from bonzini at gnu dot org 2008-10-01 11:20 ---
I don't think they ever did; indeed toplevel bootstrap was enabled on
2005-12-14 which is after this bugreport was started. You can make
clean-target; make all or make restrap.
--
bonzini at gnu dot org changed:
--- Comment #2 from sposelenov at emcraft dot com 2008-10-01 11:28 ---
Found the cause of the problem - it's binutils 2.17.50. Using ld version 2.18
or even 2.17.90 creates workable libstdc++.so.
Could please someone responsible close this bug with correct resolution?
--
--- Comment #6 from dominiq at lps dot ens dot fr 2008-10-01 12:09 ---
Reduced code:
program three_body
real, parameter :: n = 2, d = 2
real, dimension(n,d) :: x
x(1,:) = (/ 1.0, 0.0 /)
end program three_body
gives
pr36192_ice.f90:3.18:
real, dimension(n,d) :: x
--- Comment #4 from pdemarco at ppg dot com 2008-10-01 12:10 ---
any chance of getting this fixed on 3.4.4 ???
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207
--- Comment #7 from bonzini at gnu dot org 2008-10-01 12:23 ---
Subject: Bug 37662
Author: bonzini
Date: Wed Oct 1 12:22:17 2008
New Revision: 140809
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140809
Log:
2008-09-30 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #5 from bonzini at gnu dot org 2008-10-01 12:24 ---
committing patch as obvious, thanks.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #6 from bonzini at gnu dot org 2008-10-01 12:26 ---
committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from bonzini at gnu dot org 2008-10-01 12:27 ---
Subject: Bug 37683
Author: bonzini
Date: Wed Oct 1 12:26:02 2008
New Revision: 140810
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140810
Log:
2008-09-30 H.J. Lu [EMAIL PROTECTED]
PR c++/37683
*
Extracted from pr36192, the following code
program three_body
real, parameter :: n = 2, d = 2
! real, dimension(n), parameter :: m = (/ 1.0, 1.0 /)
real, dimension(n,d) :: x, v
! real, dimension(n,d) :: x, v, x_n, v_n, x_hq, v_hq
end program three_body
yields the following errors
--- Comment #2 from luisgpm at linux dot vnet dot ibm dot com 2008-10-01
13:10 ---
Created an attachment (id=16439)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16439action=view)
Preprocessed source for reduced bzip2.c
Preprocessed source.
--
--- Comment #3 from luisgpm at linux dot vnet dot ibm dot com 2008-10-01
13:10 ---
Created an attachment (id=16440)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16440action=view)
Reduced source for bzip2.c
Source reduced with delta
--
--- Comment #4 from luisgpm at linux dot vnet dot ibm dot com 2008-10-01
13:13 ---
Created an attachment (id=16441)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16441action=view)
Reduced source for bzip2.c
Indented reduced source.
--
luisgpm at linux dot vnet dot ibm dot com
--- Comment #5 from luisgpm at linux dot vnet dot ibm dot com 2008-10-01
13:19 ---
I'm still trying to minimize even further the source. Will attach when i have
something better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-01 13:20 ---
Note that after tuples we always have a default label again, just the default
label isn't a default label. I have a patch to fix that, sort of
Index: tree-vrp.c
--
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
--- Comment #4 from mycae at yahoo dot com 2008-10-01 13:34 ---
Created an attachment (id=16442)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16442action=view)
.i and .s file for menu
I also experience this problem when compiling with the latest wine 1.1.5
sources. I have
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-01 13:44 ---
Indeed. This exposes a bug as we do not fold VIEW_CONVERT_EXPR char * (0.0).
As we never initialize NEW_SETS for FRE we should not try to add to it.
--
rguenth at gcc dot gnu dot org changed:
What
This happens in testcases gfortran.dg/vect/vect-[2,3,4].f90 -
On the alias branch we can't tell that subroutine arguments don't alias. e.g.,
X,Y in SUBROUTINE SAXPY(X,Y,A).
As a result the vectorizer applies loop-versioning with runtime aliasing test,
which also means it will handle misalignment
This happens in testcase gfortran.dg/vect/pr32377.f90:
On the alias branch can't prove that number of iteratios is non zero:
Analyzing # of iterations of loop 1
exit condition [2, + , 1](no_overflow) D.1554_60
bounds on difference of bases: -2147483650 ... 2147483645
result:
zero if
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 14:12 ---
Doesn't ICE for me with a cross from x86_64,
./cc1 -quiet bzip2-reduced.i -O3 -ffast-math -funroll-loops -ftree-loop-linear
-fpeel-loops -mcpu=power4 {,-m32,-m64}
--
This happens in testcases gcc.dg/vect/no-scevccp-outer-6.c and
gcc.dg/vect/vect-multitypes-6.c:
On the alias branch we can't tell that a read through a (restrict) pointer
(which is a function argument) does not overlap with write to a local arrays.
As a result we try to vectorize the loop using
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-01 14:17 ---
Mine. The alias-oracle doesn't use PTA information yet.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dave dot korn at artimi dot com 2008-10-01 14:19
---
Sorry mate, all 3.x compilers are way past end-of-life now; there will never be
another release.
Your best bet is to hand-edit the header files in your local install. I don't
remember the exact recipe, but of
This happens in gcc.dg/vect/vect-42.c:
On the alias branch we can't tell that a write through a restrict pointer
(which is a function argument) does not overlap with reads from local
arrays. As a result we vectorize using loop-versioning controled by a
run-time aliasing test. This in turn forces
Add PRs in the Depends on field. All dependent bugs are latent on the trunk
in case partitioning would chose a pessimizing partitioning.
--
Summary: [meta-bug] PRs blocking adoption of the alias-
improvements branch
Product: gcc
Version:
Compiled -fno-rtti, g2 and g3 are faulted but g1 is not. Code for g1
(on ARM target) shows use of RTTI which we have asserted is absent.
struct B1 { virtual int f(); };
struct B2 { virtual int g(); };
struct D: B1, B2 { };
/* These should be allowed even with -fno-rtti */
B1 *f2(B1 *p) { return
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-01 14:24 ---
restricted pointers are still not properly handled by the middle-end, neither
are they dealt with by the alias-oracle.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
This happens in testcase gcc.dg/vect/vect-62.c:
looks like on the alias branch pre is more powerful, as it moves the load into
the latch block; as a result the latch block is not empty, and we fail to
vectorize (with -fno-tree-pre vectorization succeeds).
Related non-empty-latch PRs that
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-10-01 14:28
---
Only two_restrict_pointers is valid. This is a dup of PR14187.
*** This bug has been marked as a duplicate of 14187 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 14:28 ---
*** Bug 14192 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rth at gcc dot gnu dot org 2008-10-01 14:29 ---
Subject: Bug 35737
Author: rth
Date: Wed Oct 1 14:28:04 2008
New Revision: 140812
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140812
Log:
PR tree-opt/35737
* tree-complex.c
--- Comment #5 from rth at gcc dot gnu dot org 2008-10-01 14:32 ---
Subject: Bug 35737
Author: rth
Date: Wed Oct 1 14:30:37 2008
New Revision: 140813
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140813
Log:
PR tree-opt/35737
* tree-complex.c
This happens in gcc.dg/vect/vect-96.c and gcc.dg/vect/no-vfa-vect-43.c.
In the first, we can't distinguish between a write through a (local) pointer to
a global array (which is a field in a struct), and a read from a local array. s
a result we vectorize the loop using loop-versioning controled by
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-10-01 14:32 ---
*** Bug 16306 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-10-01 14:32 ---
This is effectively a dup of PR14187. We fail to track what pointers are
based on a restrict pointer.
*** This bug has been marked as a duplicate of 14187 ***
--
rguenth at gcc dot gnu dot org changed:
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-10-01 14:33
---
This is a dup of PR14187 - we simply fail to implement restrict properly.
*** This bug has been marked as a duplicate of 14187 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-10-01 14:33 ---
*** Bug 16913 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-10-01 14:34
---
*** Bug 28030 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-01 14:34 ---
*** This bug has been marked as a duplicate of 14187 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
This happens in testcase gcc.dg/vect/slp-19.c:
The problem is with the loop at line 17: with trunk we detect that one of
the elements of array 'in' is read twice, so we generate overall 8 loads
(reusing one of them). On the alias branch we do not eliminate the extra
load. All the reads and write
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-10-01 14:35 ---
This boils down to restrict being implemented as a different alias-set instead
of as points-to information. Dup of PR14187.
*** This bug has been marked as a duplicate of 14187 ***
--
rguenth at gcc dot gnu
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-10-01 14:35
---
*** Bug 29239 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 14:35 ---
PR14187 again.
*** This bug has been marked as a duplicate of 14187 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-10-01 14:35
---
*** Bug 32273 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-10-01 14:30 ---
Note that C restrict semantics make it necessary to properly track what
pointer is based on what other pointer. For this we miss both annotations
and a (simple) propagator that propagates this information, maybe as
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-01 14:38 ---
The implementation detail of restrict makes the alias-oracle not work properly.
Dup of PR14187 - restrict should be a PTA thing.
*** This bug has been marked as a duplicate of 14187 ***
--
rguenth at gcc dot
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-10-01 14:38
---
*** Bug 33272 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-01 14:31 ---
Depends on proper restrict implementation.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-10-01 14:40
---
*** Bug 33705 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-01 14:40 ---
This is because restrict is implemented as regular alias-sets.
*** This bug has been marked as a duplicate of 14187 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from rth at gcc dot gnu dot org 2008-10-01 14:42 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-01 14:54 ---
Proper restrict implementation is required.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-10-01 15:01
---
This is not solely a tree issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 15:09 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-10-01 15:11 ---
Subject: Bug 37285
Author: rguenth
Date: Wed Oct 1 15:09:26 2008
New Revision: 140814
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140814
Log:
2008-10-01 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #10 from sparky at pld-linux dot org 2008-10-01 15:29 ---
In that case the bug report is incorrect.
The problem lays in glibc, in function lroundl which does not save cr3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37154
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-01 15:33 ---
Smaller testcase, FRE should remove the redundancy but doesn't.
unsigned int out[16];
unsigned int in[16];
unsigned int ia[16];
int
foo (void)
{
unsigned int i;
for (i = 0; i 16; ++i)
{
out[i] =
Compiled -fno-rtti, g2 and g3 are faulted but g1 is not. Code for g1
(on ARM target) shows use of RTTI which we have asserted is absent.
struct B1 { virtual int f(); };
struct B2 { virtual int g(); };
struct D: B1, B2 { };
/* These should be allowed even with -fno-rtti */
B1 *f2(B1 *p) { return
--- Comment #1 from algrant at acm dot org 2008-10-01 15:35 ---
*** Bug 37701 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37697
--- Comment #1 from algrant at acm dot org 2008-10-01 15:35 ---
*** This bug has been marked as a duplicate of 37697 ***
--
algrant at acm dot org changed:
What|Removed |Added
Configuring stage 2 in ./intl
configure: creating cache ./config.cache
checking whether make sets $(MAKE)... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether NLS is requested... no
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
--- Comment #1 from James dot W dot Mckelvey at jpl dot nasa dot gov
2008-10-01 16:14 ---
Created an attachment (id=16443)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16443action=view)
config.log from bootstrap
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37702
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-01 16:24 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 16:24 ---
Subject: Bug 37617
Author: rguenth
Date: Wed Oct 1 16:23:23 2008
New Revision: 140816
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140816
Log:
2008-10-01 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from aran at 100acres dot us 2008-10-01 16:30 ---
Created an attachment (id=16444)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16444action=view)
patch for svn trunk
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
As I found while testing a patch for PR ada/37681, all parts of the Ada
testsuite
lack proper multilib support:
* ada/acats isn't multilib-aware at all (i.e. runs only for the default
multilib), and
* gnat.dg at least runs the tests for all multilibs, but fails to pass the
proper
--RTS
--- Comment #2 from algrant at acm dot org 2008-10-01 16:40 ---
Bug report in error.
--
algrant at acm dot org changed:
What|Removed |Added
--- Comment #7 from edwintorok at gmail dot com 2008-10-01 16:43 ---
Thanks, gcc4.4 doesn't crash anymore now.
--
edwintorok at gmail dot com changed:
What|Removed |Added
--- Comment #11 from sparky at pld-linux dot org 2008-10-01 16:47 ---
Note: glibc problem have been detected and fixed already:
- bug: https://bugzilla.redhat.com/show_bug.cgi?id=450790
- fix: http://www.sourceware.org/ml/libc-hacker/2008-06/msg1.html
--
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-10-01 17:11
---
GCC is doing the correct thing. Glibc is broken so closing as invalid as glibc
has already been fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
As seen in PR ada/37681, lack of multilib support in a specific target library
can break bootstrap. To avoid this without having to disable multilib support
completely, it would be useful to have either a --disable-libada-multilib or
(better yet) a generic --disable-multilib[=liba,libb].
--
Graphite calls limit_scops() to ensure, that every SCoP contains a single
surrounding loop, as graphite - at the moment - is not able to handle SCoPs
with two outermost loops or a bb not contained in any loop.
In theory that is possible without problems, only some little bugs are in the
way.
So
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #9 from ro at techfak dot uni-bielefeld dot de 2008-10-01
17:17 ---
Subject: Re: [4.4 regression] Building 64-bit libada fails on Solaris/x86:
alignment error
bonzini at gnu dot org writes:
No, there is not yet an extra configure switch for that, but I'll add it. You
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-01 17:25 ---
From C99 6.5.2.5/8:
String literals, and compound literals with const-qualified types, need not
designate distinct objects
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37303
--- Comment #7 from luisgpm at linux dot vnet dot ibm dot com 2008-10-01
17:44 ---
I still can ICE it with the same flags in a native system. Any other info you'd
like to have available?
I have a more reduced source, will post it soon.
--
--- Comment #6 from pdemarco at ppg dot com 2008-10-01 18:04 ---
(In reply to comment #5)
Sorry mate, all 3.x compilers are way past end-of-life now; there will never
be
another release.
okay, but I wish that you wouldn't freeze 3.x when 4.x is still in Alpha. If I
could upgrade to
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-01 18:05 ---
This is maybe fixed with the patch for PR37285?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jason at redhat dot com 2008-10-01 18:01 ---
Subject: Re: DW_TAG_imported_module is not in its DW_TAG_lexical_block
Please send patches to gcc-patches for review (and CC me) rather than
attaching them to the PR. (It would be nice if a bot would notice
relevant
--- Comment #7 from paolo dot carlini at oracle dot com 2008-10-01 18:17
---
(In reply to comment #6)
okay, but I wish that you wouldn't freeze 3.x when 4.x is still in Alpha.
Alpha?!? What do you mean, exactly? Certainly we have a very stable 4.3.x
release series, and previously we
--- Comment #8 from pdemarco at ppg dot com 2008-10-01 18:19 ---
(In reply to comment #7)
(In reply to comment #6)
okay, but I wish that you wouldn't freeze 3.x when 4.x is still in Alpha.
Alpha?!? What do you mean, exactly? Certainly we have a very stable 4.3.x
release series, and
When the deck below is compiled with gfortran, an ICE occurs.
Gfortran version:
Using built-in specs.
Target: i586-pc-linux-gnu
Configured with: /home/fx/gfortran_nightbuild/trunk/configure
--prefix=/home/fx/gfortran_nightbuild/irun-20080925
--enable-languages=c,fortran --build=i586-pc-linux-gnu
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-01 20:10 ---
Reduced testcase:
module data_C
integer, dimension(200) :: l
integer ::v
equivalence ( l(1), l0 )
end module data_C
subroutine nudata(a, l)
USE data_C, only: v
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-10-01 20:13 ---
I can reproduce this even with a stage1 compiler.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-10-01 20:13 ---
#0 0x10195c2c in single_exit (loop=0xf7b31930) at
/home/apinski/src/other/gcc/gcc/cfgloop.c:1618
#1 0x106a1208 in number_of_latch_executions (loop=0xf7b31930) at
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-10-01 20:14
---
This was with:
GNU C (GCC) version 4.4.0 20080929 (experimental) [trunk revision 140763]
(powerpc64-unknown-linux-gnu)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-10-01 20:23
---
If I change the GC Parameters, I get a different backtrace:
#0 0x105c9abc in gsi_stmt (i=Cannot access memory at address 0x4
) at /home/apinski/src/other/gcc/gcc/gimple.h:4392
#1 0x105dd4fc in verify_stmts () at
--- Comment #9 from brian at dessent dot net 2008-10-01 20:25 ---
Subject: Re: Spurious 'might be used uninitialized'
warnings in STL headers with -O2
You are confusing the state of the Cygwin port of gcc with gcc in
general.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207
--- Comment #2 from dominiq at lps dot ens dot fr 2008-10-01 20:26 ---
Confirmed, reduced code:
module data_C
integer, dimension(200) :: l
integer :: l0
integer :: l24, l27, l28, l29
equivalence ( l(1), l0 )
end module data_C
subroutine
The following program:
type s
integer m
integer n
end type s
type(s) :: a(3)
character*80 :: l = ' namlis a%m=1,2, a%n=5,6, /'
namelist /namlis/ a
a%m=[87,88,89]
a%n=[97,98,99]
print*,a%m
print*,a%n
read(l,namlis)
write(*,namlis)
end
prints:
87 88 89
--- Comment #3 from dominiq at lps dot ens dot fr 2008-10-01 21:24 ---
The ICE also disappears if 'l' is replaced by say 'l1' in the module data_C.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37706
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-01 21:32 ---
Confirmed.
SCC consists of: MPT.765_6816(ab) ...[5000 others snipped]... code_6815
MPT.765_6793
Danny has some speedup ideas, apart from that you can tune
--parm sccvn-max-scc-size. A value of 5000 shrinks
1 - 100 of 126 matches
Mail list logo
