Daniel Berlin wrote:
Hi guys, I have merged all patches touching lto/ into the new lto branch
Thank you! Did you also pull over Kenny's LTO-writer code?
I'll try to get it compiling soon.
I will perform merges from mainline to branch every week or two,
unless you guys see a good reason not
On 6/18/07, Brooks Moses [EMAIL PROTECTED] wrote:
Giovanni Bajo wrote:
Both our goals are legitimate. But that's not the point. The point is
what -ffast-math semantically means (the simplistic list of suboptions
activated by it is of couse unsufficiente because it doesn't explain how
to
On Tue, 2007-06-19 at 01:50 +, Joseph S. Myers wrote:
The ARM EABI says that only standard entries under aeabi should affect
link-compatibility of object files, not vendor entries such as gnu, but
in the absence of corresponding standards for other processors I don't
think we can avoid
OTOH, if we start to produce NaN for sqrt(0.0) that is of course simply
'wrong', not inaccurate ;)
I still support the introduction of a special switch for this kind of
transformation, -fwrong-math-optimizations. :-)
Paolo
I would like to get some more information about pr32374.
I do not know what virtual_stack_vars are and there is no documentation
in the doc directory.
It is documented:
@findex VIRTUAL_STACK_VARS_REGNUM
@cindex @code{FRAME_GROWS_DOWNWARD} and virtual registers
@item VIRTUAL_STACK_VARS_REGNUM
On 6/19/07, Paolo Bonzini [EMAIL PROTECTED] wrote:
OTOH, if we start to produce NaN for sqrt(0.0) that is of course simply
'wrong', not inaccurate ;)
I still support the introduction of a special switch for this kind of
transformation, -fwrong-math-optimizations. :-)
Probably as useful and
On Mon, Jun 18, 2007 at 08:28:25PM -0400, Kenneth Zadeck wrote:
I would like to get some more information about pr32374.
I do not know what virtual_stack_vars are and there is no documentation
in the doc directory.
less -p 'Virtual registers ' gcc/rtl.h
less -p 'enum global_rtl_index'
Hi all,
In case someone is interested, we just made a new patch available for gcc to
enable
run-time multiple option exploration and to enable run-time adaptation for
various constraints
on heterogeneous systems using function cloning. More information and a patch
are avilable here:
Rask Ingemann Lambertsen wrote:
On Tue, Jun 19, 2007 at 11:11:54AM +0200, Uros Bizjak wrote:
On 6/19/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote:
It is possible to mess up the substitution that the vregs pass performs.
IIRC, it happened to me once because I accidentally
On 6/19/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Daniel Berlin wrote:
Hi guys, I have merged all patches touching lto/ into the new lto branch
Thank you! Did you also pull over Kenny's LTO-writer code?
Yup.
I have the complete list of revisions merged with their log entries if
you'd like
On Tue, Jun 19, 2007 at 08:33:52AM -0400, Kenneth Zadeck wrote:
Since it sounds like you understand this, are either of you willing/able
to attack the problem at it's source?
Uros is already at it
URL:http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01317.html.
--
Rask Ingemann Lambertsen
Hello,
While testing a patch on current trunk (r 125640) I've noticed that g++'s
cp_compat_x_tst.o-cp_compat_y_tst testcase fails with unexpected failure
on x86_64 with the vanilla version but passes OK with the patched version
(-O2). On ppc64 and i486 the test passes both with the vanilla and
Hi,
m68k currently doesn't bootstrap, which I think is dataflow related, the
whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but
the small test below should be enough to demonstrate the problem
(although it doesn't crash):
int fi1(int);
int fi2(int);
void *fp1(int, void
Roman Zippel wrote:
Hi,
m68k currently doesn't bootstrap, which I think is dataflow related, the
whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but
the small test below should be enough to demonstrate the problem
(although it doesn't crash):
int fi1(int);
int
On powerpc-apple-darwin7 with 4.3.0 20070615, the compilation time
of the polyhedron test suite increased by 35% compared to the
previous snapshot and by 41% compared to the Apr 13 one:
compile execute
06/15
On 6/19/07, Dominique Dhumieres [EMAIL PROTECTED] wrote:
On powerpc-apple-darwin7 with 4.3.0 20070615, the compilation time
of the polyhedron test suite increased by 35% compared to the
previous snapshot and by 41% compared to the Apr 13 one:
I did not see this change. What flags are you
Hi,
On Tue, 19 Jun 2007, Kenneth Zadeck wrote:
roman do i need any patches to apply before trying this.
None should be needed, but this one can't hurt:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01247.html
also what are
the config options i need?
I use --target=m68k-linux-gnu
I did not see this change. What flags are you using?
gfortran -w -O3 -ffast-math -funroll-loops
Dominique
On Mon, 2007-06-18 at 10:04 -0700, Mark Mitchell wrote:
I suspect that the realview compiler accepts
this as an oversight or a bug, not as an intentional feature.
Let's ask.
Richard E., is the fact that RealView 3.0SP1 accepts:
class __declspec(notshared) S {
On Tue, Jun 19, 2007 at 04:26:46PM +0300, Revital1 Eres wrote:
While testing a patch on current trunk (r 125640) I've noticed that g++'s
cp_compat_x_tst.o-cp_compat_y_tst testcase fails with unexpected failure
on x86_64 with the vanilla version but passes OK with the patched version
(-O2). On
Hello all:
I am reading codes of gcc front end. But I can not find the implementation
of sizeof. How does gcc front end calculate size of UNION and STRUCT?
Where is the codes for these work. Can anybody give me some advices? Thank
you so much !
On 19 June 2007 16:35, bjzheng wrote:
Hello all:
I am reading codes of gcc front end. But I can not find the implementation
of sizeof. How does gcc front end calculate size of UNION and STRUCT?
Where is the codes for these work. Can anybody give me some advices? Thank
you so much !
grep
[EMAIL PROTECTED] wrote:
Hello all:
I am reading codes of gcc front end. But I can not find the implementation
of sizeof. How does gcc front end calculate size of UNION and STRUCT?
Where is the codes for these work. Can anybody give me some advices? Thank
you so much !
The code is heavily
On 6/19/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote:
..
Hmm, how do you handle arg_pointer_rtx, frame_pointer_rtx and the like?
The are all uninitialized until the prologue is emitted, which is some time
after reload.
ARG_POINTER_REGNUM is included in the artificial defs of all
michael.a wrote:
Since I'm already posting, now I'm seeing:
/home/users/michael/gcc.obj/gcc/f951: symbol lookup error:
/home/users/michael/gcc.obj/gcc/f951: undefined symbol:
__gmp_get_memory_functions
I was able to find this:
Roman Zippel wrote:
Hi,
m68k currently doesn't bootstrap, which I think is dataflow related, the
whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but
the small test below should be enough to demonstrate the problem
(although it doesn't crash):
int fi1(int);
int
On Jun 18, 2007, at 6:50 PM, Joseph S. Myers wrote:
Any comments on either the general approach or the details?
Sounds fine to me. In mips land we were previously using named
sections to solve this, but as long as the approach allows arbitrarily
long sets of attributes I think it sounds
Mark Mitchell wrote:
One advantage of having some SC members who are not GCC developers (and
thus seem less involved) is that they are more independent. They have
no commercial stake in which companies have maintainers,
The funny part in the discussion on the SC is that most contributors
Hello,
I am looking into writing scalar expansion and array privatization
passes for loop distribution with Sebastian.
Has scalar expansion and/or array privatization been implemented in gcc?
If so, how have they been implemented and also to what extent?
Does anyone have any pointers on where I
- 2 new attributes far_data (to use external memory for data
storage) and far_rodata will be added.
I'd prefer just one far attribute. GCC knows (usually better than
the user ;) what data is read-only and what data is not.
- By default, LDE instructions will be used to access the entire
On Fri, Jun 08, 2007 at 01:27:39PM -0700, Mark Mitchell wrote:
Joseph S. Myers wrote:
On Thu, 7 Jun 2007, Mark Mitchell wrote:
I am aware of three remaining projects which are or might be appropriate
for Stage 1:
Do we at this point believe that the people who were working on
Hi,
gcc's docs states that at -fstrict-aliasing:
In particular, an object of one type is assumed never to reside at the
same address as an object of a different type, unless the types are almost
the same.
I have problems with this:
struct A {
float x, y;
};
struct B {
float
This may have been fixed by a recent patch to -Wstrict-aliasing. Let me
try to run the latest version of pre4.3 and will get back to you.
Herman Geza wrote:
Hi,
gcc's docs states that at -fstrict-aliasing:
In particular, an object of one type is assumed never to reside at the
same address
On 6/19/07, Sunzir Deepur [EMAIL PROTECTED] wrote:
hello,
when I compile with -dv -fdump-rtl-* I somtimes see in the VCG files
some edges that have no meaning in the flow of the program.
these edges are always green and class 3.
what are those edges ? what is their purposes ?
thank you
sunzir
I have a -m option that I am handling in a LIB_SPEC that I do not want
passed down to cc1. It seems that by default, the driver passes all -m
options to cc1. Is there a way to prevent that on a per-option basis?
Thanks, Ben
On 6/16/07, Ross Ridge [EMAIL PROTECTED] wrote:
Robert Dewar writes:
The only time that it is reasonable to extend is when there are clear
signals from the standards committee that it is likely that a feature
will be added, in which case there may be an argument for adding the
feature
Lawrence Crowl writes:
On the specific topic of unions, there is a proposal before the
committee to extend unions in this direction. Let me caution you
that this proposal has not been reviewed by a significant fraction
of the committee, and hence has a small chance of being accepted
and an even
On Wed, 2007-06-20 at 10:44 +1000, Ben Elliston wrote:
I have a -m option that I am handling in a LIB_SPEC that I do not want
passed down to cc1. It seems that by default, the driver passes all -m
options to cc1. Is there a way to prevent that on a per-option basis?
To now answer my own
Michael Meissner wrote:
I've looked at the changes, and I think with a minor bit of abstraction, we
can
modify the backends so that they don't care how the arguments are implemented.
Thanks for working on this!
However, I think changing the representation of the arguments is a much more
ARG_POINTER_REGNUM is included in the artificial defs of all blocks
(which I think is overly conservative - just having them
in the entry block def should be enough).
Hence, from dataflow point of view, they are always considered initialized.
I think we should probably do something similar
for
Hello,
Current function declaration of __bswapdi2 in libgcc2.h is:
DItype __bswapdi2 (DItype u)
Since this declaration does not check if DItype is supported, it is
bound for compilation failure for targets that do not support DItype.
Would it be ok to change the DItype to DWtype as in:
--- Comment #1 from marcus at jet dot franken dot de 2007-06-19 06:24
---
Created an attachment (id=13734)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13734action=view)
vertexbuffer.i
gcc -O2 -c vertexbuffer.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
new regression, likely caused by pointer-plus branch merge
extracted from Wine
/home/marcus/projects/gcc/BIN/bin/gcc -m32 -O2 -c vertexbuffer.i
vertexbuffer.i: In function 'f':
vertexbuffer.i:1: internal compiler error: in build2_stat, at tree.c:3074
--
Summary: ICE in
--- Comment #4 from tbm at cyrius dot com 2007-06-19 06:39 ---
(In reply to comment #3)
I tested the patch on IA64 HP-UX and Linux and verified that it fixed the bug
and caused no regressions. Jim, do you want to check this patch in?
Given that Jim hasn't answered yet, maybe you can
--- Comment #3 from pluto at agmk dot net 2007-06-19 06:44 ---
(In reply to comment #2)
At variance with c++/32256, this one apparently happens as C code too...
Probably should be not categorized as C++-only...
these little bugs (PR32368, PR32256) are treated as blockers
by people
--- Comment #115 from pinskia at gcc dot gnu dot org 2007-06-19 07:56
---
*** Bug 32397 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-19 07:56 ---
((Cyg_libm_ieee_double_shape_type *)x)-part is ovbiously an aliasing
violation.
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-19 08:10 ---
This is caused by two things, jump threading and inlining. If we jump thread
more, we no longer get the warning which is what you are seeing in 4.2.1.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-19 08:21 ---
This is IV-opts going funny I think as we get pointer+pointer (and yes real
pointer SSA_NAMES and no casts).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-19 08:26 ---
This code itself is very weird and I don't know if it is really defined or not.
We have basically:
char *f(char *a, char *b)
{
return a + (int)b;
}
How can that even be defined.
Anyways the following fixes the
--- Comment #97 from pinskia at gcc dot gnu dot org 2007-06-19 08:11
---
*** Bug 32391 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-06-19 08:11
---
So this is just a dup of bug 323 so closing as such.
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ubizjak at gmail dot com 2007-06-19 08:27 ---
(In reply to comment #4)
No, this one is caused by dataflow.
Dataflow uncovered generic middle-end (RTL?) problem:
We have this comment in instantiate_virutal_regs():
/* Scan through all the insns, instantiating
--- Comment #6 from ubizjak at gmail dot com 2007-06-19 08:58 ---
FWIW, this shoot-in-the-dark patch fixes ICE:
Index: expr.c
===
--- expr.c (revision 125789)
+++ expr.c (working copy)
@@ -5062,8 +5062,10 @@
--- Comment #2 from jakub at gcc dot gnu dot org 2007-06-19 09:08 ---
Subject: Bug 32353
Author: jakub
Date: Tue Jun 19 09:08:39 2007
New Revision: 125841
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125841
Log:
PR tree-optimization/32353
*
--- Comment #3 from jakub at gcc dot gnu dot org 2007-06-19 09:11 ---
Subject: Bug 32353
Author: jakub
Date: Tue Jun 19 09:11:22 2007
New Revision: 125842
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125842
Log:
PR tree-optimization/32353
*
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-19 09:15 ---
Confirmed. For 2 NR steps to reach double precision (we'd miss it by some more
ulps than the 2.5 for float precision) we would need to do at least the second
NR in double precision. Note that this would make sense
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-19 09:17 ---
The testcase indeed looks undefined (but valid).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
--- Comment #4 from jakub at gcc dot gnu dot org 2007-06-19 09:18 ---
Subject: Bug 32353
Author: jakub
Date: Tue Jun 19 09:18:13 2007
New Revision: 125843
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125843
Log:
PR tree-optimization/32353
*
--- Comment #5 from jakub at gcc dot gnu dot org 2007-06-19 09:19 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #43 from rguenth at gcc dot gnu dot org 2007-06-19 09:24
---
Subject: Bug 30252
Author: rguenth
Date: Tue Jun 19 09:24:35 2007
New Revision: 125844
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125844
Log:
2007-06-19 Richard Guenther [EMAIL PROTECTED]
--- Comment #4 from rearnsha at gcc dot gnu dot org 2007-06-19 09:41
---
Confirmed. This is a bug in the negscc pattern in arm.md. It's only been
there since 1994!
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #44 from rguenth at gcc dot gnu dot org 2007-06-19 09:45
---
Fixed on the 4.2 branch. Danny will fix this in a different way on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rosenfeld at grumpf dot hope-2000 dot org 2007-06-19
10:52 ---
Subject: Re: wrong instruction order generated
On Tue, Jun 19, 2007 at 07:56:01AM -, pinskia at gcc dot gnu dot org wrote:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-19 07:56
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-06-19 11:16 ---
Subject: Bug 31950
Author: rguenth
Date: Tue Jun 19 11:16:43 2007
New Revision: 125846
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125846
Log:
2007-06-19 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-06-19 11:17 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from rask at sygehus dot dk 2007-06-19 11:27 ---
You can use memcpy (int, float, min (sizeof (int), sizeof (float))) and vice
versa. I suppose you can also memcpy() into or out of a char array of the right
size.
If you were to use the GCC extension of using a union, it
--- Comment #7 from ubizjak at gmail dot com 2007-06-19 11:54 ---
Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01317.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32374
svn snapshot from r125847
--
Summary: [4.3 Regression] ICE in expand_or_defer_fn, at
cp/semantics.c:3220
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
--- Comment #1 from jojelino at gmail dot com 2007-06-19 12:10 ---
Created an attachment (id=13735)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13735action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
--- Comment #10 from dominiq at lps dot ens dot fr 2007-06-19 12:48 ---
Even the code in comment #8 is invalid: several variables are used but not set:
at least intp and sum.
If I set them to 0, gfortran gives the same results with or without -O3. (tests
done on PPC Darwin7).
In my
With altivec enabled gcc prepares additional space on the stack. Unlike earlier
versions gcc 4.3 removes stack modification instructions if it isn't used. With
just -maltivec or with -mabi=altivec when altivec isn't used it works very
well. But with -mabi=altivec and altivec used gcc produces code
The compiler thinks we're allocating the actual abstract objects instead of an
array of pointers and reports the following error: cannot allocate an object
of abstract type '...'. Since we're actual allocating an array of pointers,
this should not be an error.
The following code (reproduce.cpp)
--- Comment #1 from p dot vestjens at gmail dot com 2007-06-19 14:47
---
Created an attachment (id=13736)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13736action=view)
Sourcefile demonstrating the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
NOTE: Defaulting component because reported component no longer exists
Environment:
System: Linux marko2 2.6.15-28-686 #1 SMP PREEMPT Thu Feb 1 16:14:07 UTC 2007
i686 GNU/Linux
Architecture: i686
host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: m68hc11-unknown-none
configured with:
Spin off from PR 32236.
ftp://ftp.icess.ucsb.edu/pub/esrg/sbdart/sbdart_2.4.tar.gz (33181 lines of
code)
Unpack source and do:
- Delete in tauaero.f:1601 the line
data wlbaer/0.,0./
- Insert around drt.f:951 the lines
weq = 0.0_kr
wfull = 0.0_kr
If one compiles (-O0) the program with
--- Comment #8 from burnus at gcc dot gnu dot org 2007-06-19 15:30 ---
Bob,
Can you please tell me why the compiler flags tauaero.f:1517 while
the problem seems to be associated with the data statement at line
1601?
The line number shown when an internal compiler error occurs
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-19 16:02 ---
blah
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rask at gcc dot gnu dot org 2007-06-19 16:30 ---
Subject: Bug 32369
Author: rask
Date: Tue Jun 19 16:30:03 2007
New Revision: 125851
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125851
Log:
2007-06-19 Rask Ingemann Lambertsen [EMAIL PROTECTED]
PR
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-19 16:30 ---
Tobias points out to me that this is not a regression - closed and out.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-19 16:32 ---
Sorry for my screw-up on the PR number - it was 20882 that was fixed.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20082
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-19 16:32 ---
This is not a regression, so that is it.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from daney at gcc dot gnu dot org 2007-06-19 16:36 ---
Subject: Bug 32313
Author: daney
Date: Tue Jun 19 16:36:42 2007
New Revision: 125852
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125852
Log:
PR target/32313
* config/mips/mips.md
--- Comment #15 from daney at gcc dot gnu dot org 2007-06-19 16:43 ---
The second time is the charm.
There are still regressions caused by the dataflow merge, but at least we can
bootstrap now.
--
daney at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pault at gcc dot gnu dot org 2007-06-19 16:44 ---
This is not a regression so no backport.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from rob1weld at aol dot com 2007-06-19 17:11 ---
The goal of the tests is not to measure some time, but to check that
intervals are properly ordered, i.e., t1=dat1=t1a and t2a=dat2-dat1= t2.
If that is the goal then could we eliminate all influence of time (midnight /
--- Comment #26 from rth at gcc dot gnu dot org 2007-06-19 17:26 ---
(In reply to comment #10)
Talked to Dan Berlin and Diego Novillo here at Google. They told me
that all locals are promoted to function scope.
That *only* applies to register variables, not stack variables.
We very
--- Comment #9 from rask at gcc dot gnu dot org 2007-06-19 17:35 ---
Subject: Bug 32335
Author: rask
Date: Tue Jun 19 17:35:16 2007
New Revision: 125853
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125853
Log:
2007-06-19 Rask Ingemann Lambertsen [EMAIL PROTECTED]
PR
--- Comment #27 from dnovillo at google dot com 2007-06-19 17:39 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing
causing removal of live code
On 6/19/07 1:26 PM, rth at gcc dot gnu dot org wrote:
--- Comment #26 from rth at gcc dot gnu dot org 2007-06-19 17:26 ---
The following 2 testcases began failing for an xtensa-elf target when the
dataflow branch was merged:
gcc.c-torture/execute/920501-6.c
gcc.c-torture/execute/930921-1.c
Both tests fail at -O3 with internal compiler error: in get_biv_step,
at loop-iv.c:792. Neither the Xtensa port nor the
Build from svn r125825 with:
http://gcc.gnu.org/viewcvs?view=revrevision=125852
applied.
Configured: ../trunk/configure --target=mipsel-linux
--with-sysroot=/usr/local/mipsel-linux-test
--prefix=/usr/local/mipsel-linux-test --with-arch=mips32 --with-float=soft
--disable-java-awt --without-x
--- Comment #2 from jojelino at gmail dot com 2007-06-19 18:13 ---
Created an attachment (id=13737)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13737action=view)
source file that causes ICE
reduced. just three line for ICE
--
jojelino at gmail dot com changed:
--- Comment #3 from jojelino at gmail dot com 2007-06-19 18:18 ---
(From update of attachment 13737)
removing static keyword at the top resolves problem.
but is it workaround?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
--- Comment #13 from spop at gcc dot gnu dot org 2007-06-19 18:35 ---
Subject: Bug 32367
Author: spop
Date: Tue Jun 19 18:35:39 2007
New Revision: 125855
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125855
Log:
PR tree-optimization/32367
* tree-chrec.h
--- Comment #28 from amacleod at redhat dot com 2007-06-19 18:57 ---
Won't solve the problem currently, but I think the long term solution is to do
stack analysis when out-of-ssa and expand have been merged into a single
entity. The live range info out-of-ssa calculates can be used to
The detailed content of the log is shown below.
splitting
/home/voax/linux/build-4.3.0/gcc/testsuite/ada/acats/tests/cd/cd92001.a into:
cd92001.adb
BUILD cd92001.adb
gnatmake --GCC=/home/voax/linux/build-4.3.0/gcc/xgcc
-B/home/voax/linux/build-4.3.0/gcc/ -gnatws -O2
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-19
19:56 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
We need to know that the return pointer (r2) is not used and that
the function is a leaf function (i.e., that the incoming value
--- Comment #15 from hjl at lucon dot org 2007-06-19 20:10 ---
(In reply to comment #14)
The linux problem is wierd. In stage2, I get the following
failure:
/bin/sh: line 1: 4487 Segmentation fault (core dumped) ./xsinfo
../../sinf
o.h
make[3]: *** [ada/sinfo.h] Error
GCC may have a defective template parsing routine which seems to mistake the
'' token in an expression for the beginning of a template argument. The error
only seems to happen when a templated function evaluates a member of a
templated class or struct with a '' symbol.
Here is a simple code
GCC may have a defective template parsing routine which seems to mistake the
'' token in an expression for the beginning of a template argument. The error
only seems to happen when a templated function evaluates a member of a
templated class or struct with a '' symbol.
Here is a simple code
1 - 100 of 127 matches
Mail list logo
