Mike Stump [EMAIL PROTECTED] wrote:
Also, with svn 1.4 dev (all i have on this machine)
Cool, fixed in 1.4 dev. Now I'm curious if it is fixed in 1.3.x. I
really want to update, but, the fortunes of a large company with lots
of revenue are predicated on this stuff actually working. :-)
Daniel Jacobowitz a écrit :
On Tue, May 02, 2006 at 07:21:24PM -0700, Mike Stump wrote:
Otherwise, would it be possible to generate the DWARF Tables and
add those tables dynamically to the running program?
Yes (could require OS changes).
Under windows, Microsoft provides an
Andrew Pinski [EMAIL PROTECTED] writes:
On May 2, 2006, at 6:34 PM, Mike Stump wrote:
Also, with svn 1.4 dev (all i have on this machine)
Cool, fixed in 1.4 dev. Now I'm curious if it is fixed in 1.3.x. I
really want to update, but, the fortunes of a large company with lots
of revenue
Daniel Jacobowitz writes:
On Tue, May 02, 2006 at 07:21:24PM -0700, Mike Stump wrote:
Otherwise, would it be possible to generate the DWARF Tables and
add those tables dynamically to the running program?
Yes (could require OS changes).
Under windows, Microsoft provides an
On Wed, May 03, 2006 at 10:14:23AM +0100, Andrew Haley wrote:
Adding an entry point to register debug info should not be a big deal.
We're going to need it for gcj when we add a JIT.
Another interesting possibility would be runtime extensions to
MD_FALLBACK_FRAME_STATE_FOR. That would be
Jakub Jelinek writes:
On Wed, May 03, 2006 at 10:14:23AM +0100, Andrew Haley wrote:
Adding an entry point to register debug info should not be a big deal.
We're going to need it for gcj when we add a JIT.
Another interesting possibility would be runtime extensions to
4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very
long time. I'm seeing the same problem as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27121
It would be nice if this were remedied. I do try to test gcc
versions before release.
Brad
Mark,
I'm trying to figure out whether we can get the SEE and
Autovectorization improvements into 4.2.
And please do not forget:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00689.html (fwprop and
PR/26821)
because, as you yourself wrote:
I don't think I can competently review these
Does anyone find the use of #line in insn-recog.c actually useful? It
seems to make debugging recog() impossible.
Bernd
Andrew Haley writes:
Jakub Jelinek writes:
On Wed, May 03, 2006 at 10:14:23AM +0100, Andrew Haley wrote:
Adding an entry point to register debug info should not be a big deal.
We're going to need it for gcj when we add a JIT.
Another interesting possibility would be
On May 2, 2006, at 9:21 PM, Mike Stump wrote:
On May 2, 2006, at 4:23 AM, jacob navia wrote:
To get to the corresponding catch, the runtime should skip through
the intermediate frames in assembler generated by the JIT. We
would like to know how should be the interface with gcc to do this.
I'm experiencing ACATS failures that manifest in
splitting
/abuild/rguenther/obj4/gcc/testsuite/ada/acats/tests/a/ada101a.ada into:
ada101a.adb
BUILD
FAIL: ada101a
BUILD
FAIL: c760009
splitting
/abuild/rguenther/obj4/gcc/testsuite/ada/acats/tests/cd/cd2a22i.ada into:
cd2a22i.adb
On Wed, May 03, 2006 at 07:12:43AM -0500, Perry Smith wrote:
On May 2, 2006, at 9:21 PM, Mike Stump wrote:
On May 2, 2006, at 4:23 AM, jacob navia wrote:
To get to the corresponding catch, the runtime should skip through
the intermediate frames in assembler generated by the JIT. We
On Wed, May 03, 2006 at 10:36:33AM +0200, jacob navia wrote:
Maybe there is some references somewhere about this?
Which JIT? Is there a source code example or something?
I'm only familiar with proprietary JITs.
Would sljl exceptions work?
This has already been answered. Basically, no.
--
In http://gcc.gnu.org/ml/gcc/2006-05/msg00047.html, you wrote:
Ok, I'll bite. Why are there two of them?!
Well, this is the real reason why we need an API and not just a simple
builtin. GCC uses that table of values to quickly switch the FPU
modes between single and double precision.
Hi Mark,
On Tue, 2 May 2006, Mark Mitchell wrote:
Roger, I know that you reviewed the SEE patches. Is there anything
more than needs to be done to get them committed, in your view?
As far as I'm aware, we're still just waiting for the Haifa folks to
commit them to mainline. There are a
Daniel Berlin wrote:
I wrote a lot of the current zone collector. Before that, Daniel
Berlin did a lot of work on it. I really don't think I have time to
mentor an SoC project (Daniel, do you, maybe?),
I do, in fact, have time to mentor such a project, and would be happy to
mentor it if you
On Tue, May 02, 2006 at 09:34:38PM -0400, Daniel Berlin wrote:
My thoughts are along the lines of Daniel's. I originally believed that
the better data layout of lifetime and object specific pools would help,
but it only helps about 10% in the extreme.
Oh, one of the more interesting results
Hi,
Thanks for your comments. I'm replying to both emails at once, as they
are related.
2006/5/3, Daniel Jacobowitz [EMAIL PROTECTED]:
- Assuming that Boehm GC turns out to be unusable for the compiler,
finish the zone collector. Again, searching mailing list about what's
unfinished was
On Wed, 2006-05-03 at 17:18 +0200, Laurynas Biveinis wrote:
Hi,
Thanks for your comments. I'm replying to both emails at once, as they
are related.
2006/5/3, Daniel Jacobowitz [EMAIL PROTECTED]:
- Assuming that Boehm GC turns out to be unusable for the compiler,
finish the zone
On Wed, May 03, 2006 at 11:31:00AM -0400, Daniel Berlin wrote:
Again, I'm not sure the portability fixes are a real issue.
There is nothing that prevents ggc-zone from being the default on
systems with mmap, and ggc-page the default elsewhere.
One of the reasons that the portability patches
Hi,
I have a proposal for the summer of code. It's quite long, so I'll
simply include a link:
https://www.cs.tcd.ie/~pbiggar/soc/application.txt
Any comments, suggestions or criticisms are welcome.
Thanks
Paul
--
Paul Biggar
[EMAIL PROTECTED]
Well, if changing fpscr and fpscr_values at the same time was your
only concern, you could just call __set_fpscr. That puts the burden
of preserving the SZ / PR bit in fpscr on the caller, though.
(i.e. read the current value of fpscr, modify the bits you want changed,
place that changed
jacob == jacob navia [EMAIL PROTECTED] writes:
jacob This application generates dynamically code and executes it, using a
jacob JIT, a Just In time Compiler. Everything is working OK until the C++
jacob code generates a throw.
Fun!
I looked at this a little bit with libgcj.
In some ways for
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
Andrew Adding an entry point to register debug info should not be a big deal.
Andrew We're going to need it for gcj when we add a JIT.
Or for our already existing JITs :-) (Not that either of those support
dwarf-style unwinding yet.)
Tom
Roger Sayle [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
03/05/2006 05:03 PM
To
Mark Mitchell [EMAIL PROTECTED]
cc
Richard Henderson [EMAIL PROTECTED], gcc mailing list gcc@gcc.gnu.org,
Leehod
Baruch [EMAIL PROTECTED], Mircea Namolaru/Haifa/[EMAIL PROTECTED],
[EMAIL PROTECTED]
On Wed, May 03, 2006 at 12:29:17PM +0200, Bernd Schmidt wrote:
Does anyone find the use of #line in insn-recog.c actually useful? It
seems to make debugging recog() impossible.
Try this patch. It adds #line directives to insn-recog.c and other generated
files to revert the ones already there.
On Tue, May 02, 2006 at 01:23:56PM +0200, jacob navia wrote:
Is there an equivalent API for linux?
__register_frame_info_bases / __deregister_frame_info_bases.
r~
On Wed, May 03, 2006 at 12:29:17PM +0200, Bernd Schmidt wrote:
Does anyone find the use of #line in insn-recog.c actually useful? It
seems to make debugging recog() impossible.
Yes, it makes compile errors go to the right place.
r~
2006/5/3, Daniel Berlin [EMAIL PROTECTED]:
The number of *host* systems we support that don't have mmap is
approaching 0, if it is not there already :)
Uhm, at least DJGPP as a GCC host system is alive and does not support
mmap. But according to the following discussion, that's non-issue.
On May 3, 2006, at 8:58 AM, Daniel Jacobowitz wrote:
On Wed, May 03, 2006 at 07:12:43AM -0500, Perry Smith wrote:
On May 2, 2006, at 9:21 PM, Mike Stump wrote:
On May 2, 2006, at 4:23 AM, jacob navia wrote:
To get to the corresponding catch, the runtime should skip through
the intermediate
On May 3, 2006, at 4:03 PM, Perry Smith wrote:
Can a link be added in the g++ documentation to this page?
You mean as we've done on:
http://gcc.gnu.org/readings.html
under
The V3 multi-vendor standard C++ ABI is used in GCC releases 3.0
and above
and
DWARF Workgroup
? Yes, we
Bradley Lucier writes:
Brad 4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very
Brad long time. I'm seeing the same problem as
Brad http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27121
Brad It would be nice if this were remedied. I do try to test gcc
Brad versions before
| I'd encourage you to work up a solid proposal for ISO/ANSI and
| propose it there.
Being a newbie, I'd appreciate contact/site details for submissions to the
ISO/ANSI standardisation forum (do I email [EMAIL PROTECTED]).
I will be happy to draft and submit a proposal, including a hopefully
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-05-03 08:10
---
This is a blocker for me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from krebbel1 at de dot ibm dot com 2006-05-03 08:25 ---
The similar problem occurs on s390x:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01795.html
The problem (for ia64 and s390x) is fixed on mainline by:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00697.html
which
--- Comment #8 from pluto at agmk dot net 2006-05-03 09:02 ---
Created an attachment (id=11364)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11364action=view)
full 32-bit testcase.
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #9 from pluto at agmk dot net 2006-05-03 09:05 ---
(In reply to comment #7)
The testcase works for me as I don't have the STLport installed (and what is
in
this bug is not enough to reproduce the bug).
so, try latest testcase.
$ make
g++ testDrv.ii -o testDrv
--- Comment #6 from schwab at suse dot de 2006-05-03 09:17 ---
While the C standard says that the result of the conversion is unspecified,
The standard says that the behaviour is undefined (6.3.1.4#1). That is even
true when converting to unsigned.
--
--- Comment #10 from pluto at agmk dot net 2006-05-03 09:19 ---
Created an attachment (id=11365)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11365action=view)
source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27156
--- Comment #11 from pluto at agmk dot net 2006-05-03 09:22 ---
also fails on 64-bit system.
$ g++ testDrv.cpp -o testDrv -pthread -O2 \
-I/usr/include/stlport -nodefaultlibs -lstlport -lc
$ ./testDrv
*** glibc detected *** ./testDrv: munmap_chunk():
--- Comment #5 from martin at mpa-garching dot mpg dot de 2006-05-03 09:46
---
(In reply to comment #4)
We still need a self contained testcase to reproduce this issue.
I tried producing one, but it seems that this would take me much more time
than I can currently afford, especially
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-05-03 10:00
---
Btw, can someone java-capable reduce the testase
import javax.xml.stream.XMLStreamException;
import javax.xml.stream.XMLStreamWriter;
public class StAXWriter
{
XMLStreamWriter writer;
int indent = 0;
public
--- Comment #16 from aph at gcc dot gnu dot org 2006-05-03 10:11 ---
I can certainly do that, but it doesn't fail on HEAD. Are you sure you really
want it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26447
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-05-03 10:14
---
It fails for me on head with -O2 -findirect-dispatch:
trunk-g/gcc ./jc1 -quiet -O2 -findirect-dispatch StAXWriter.java
-fbootclasspath=../i686-pc-linux-gnu/libjava/classpath/lib
StAXWriter.java: In class
--- Comment #18 from aph at gcc dot gnu dot org 2006-05-03 10:22 ---
gcj -findirect-dispatch doesn't work with .java files, only with .class files,
so I didn't try it.
class XMLStreamWriter
{
void writeCharacters(String s) {}
}
class XMLStreamException extends Exception {}
public
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-03 10:34
---
*** Bug 27379 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27309
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-03 10:34
---
Fixed on mainline by Mark's patch for PR 27309:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00066.html
*** This bug has been marked as a duplicate of 27309 ***
--
reichelt at gcc dot gnu dot org changed:
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-03 10:35
---
Fixed on mainline by Mark's patch for PR 27309:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00066.html
*** This bug has been marked as a duplicate of 27309 ***
--
reichelt at gcc dot gnu dot org changed:
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-05-03 10:35
---
*** Bug 27380 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27309
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-05-03 10:36
---
Thanks!
So, the problem is that PRE inserts (and later realifies) fake stores in basic
blocks with abnormal control flow. It would need to do the insertion on the
outgoing edges in this case, or deal with
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-05-03 10:38
---
Mark, do you want to add some of the testcases from PR27379 and PR27380
to the testsuite as their mode of failure is a little bit different
although the underlying problem seems to be the same?
--
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-03 10:56
---
The testcase in comment #3 only crashes on x86_64-unknown-linux-gnu,
but not on i686-pc-linux-gnu.
The testcase below crashes on both archs:
===
char *p, *q;
inline int foo(int
--- Comment #3 from P dot Schaffnit at access dot rwth-aachen dot de
2006-05-03 11:44 ---
Hi!
I believe this could be related: compiling the following with any optimisation
(starting from -O1) causes the following error:
initFeldVonDatei.f90: In function
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-05-03 12:09
---
Created an attachment (id=11366)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11366action=view)
patch
Another patch that implements the suggested basic block splitting by
re-inserting
on the fallthrough
--
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
--- Comment #9 from jakub at gcc dot gnu dot org 2006-05-03 12:23 ---
Reassigning to Richard for the optimizations mentioned in #7.
The code in SVN should be correct, but sometimes suboptimal.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from jakub at gcc dot gnu dot org 2006-05-03 12:31 ---
I think using GOMP_1.1 symver instead of GOMP_1.0 would be preferrable.
I think you probably want to keep the state in the user code (probably
inside of .omp_data_* structure) so sender could zero it, then one
--- Comment #2 from jakub at gcc dot gnu dot org 2006-05-03 12:51 ---
Subject: Bug 27395
Author: jakub
Date: Wed May 3 12:51:33 2006
New Revision: 113494
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113494
Log:
PR fortran/27395
* gimplify.c
--- Comment #24 from mueller at gcc dot gnu dot org 2006-05-03 13:02
---
closing as fixed then. Thanks !
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2006-05-03 13:07 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
03-May-2006 12:37 PM Peter O'Gorman:
g++ -force_flat_namespace dies with multiple definition of symbols in libSystem
and crt3.o on Mac OS X 10.4.
peter$ /opt/gcc_mainline/bin/g++ -force_flat_namespace -o foo foo.cpp
/opt/odcctools/bin/ld: multiple definitions of symbol _atexit
--- Comment #25 from dberlin at gcc dot gnu dot org 2006-05-03 14:15
---
Subject: Re: [4.2 Regression] ICE in in
add_virtual_operand
On Wed, 2006-05-03 at 13:02 +, mueller at gcc dot gnu dot org wrote:
--- Comment #24 from mueller at gcc dot gnu dot org 2006-05-03
--- Comment #7 from mark at codesourcery dot com 2006-05-03 14:51 ---
Subject: Re: [4.0/4.1 regression] ICE on invalid constructor
definition
reichelt at gcc dot gnu dot org wrote:
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-05-03 10:38
---
Mark, do you want
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||geoffk at gcc dot gnu dot
|
--- Comment #10 from matz at suse dot de 2006-05-03 15:40 ---
We also got a bugreport about an ICE in get_constraint_for_component_ref,
but have a C testcase. In the hope that it's the same reason I paste it
here:
-
/* compile with gcc -c -O2 -o foo.o
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-05-03 15:43
---
(In reply to comment #10)
We also got a bugreport about an ICE in get_constraint_for_component_ref,
but have a C testcase. In the hope that it's the same reason I paste it
here:
File as a seperate bug please.
The below testcase ICEs in get_constraint_for_component_ref when compiled
with -O1 or beyond on x86_64. Richard mentions that it also fails with
trunk.
---
/* compile with gcc -c -Os -o foo.o foo.c */
typedef struct {
struct { } z;
} thang_t;
struct
--- Comment #12 from matz at suse dot de 2006-05-03 15:48 ---
It's bug 27409 now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26678
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-05-03 15:53
---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2006-05-03 16:00 ---
This seems to work on the 4.1.x branch, however. So it must be a regression.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27397
--- Comment #1 from bangerth at dealii dot org 2006-05-03 16:01 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-03 16:05 ---
Confirmed. We access a zero-sized part of the structure:
arg 1 field_decl 0x2a959f2180 f type record_type 0x2a959dfb00 thang_t
BLK file t.c line 16 size integer_cst 0x2a958ab750 0 unit size
integer_cst
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-03 16:06 ---
I have a fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC host triplet|x86_64-linux|
Keywords||ice-on-valid-code
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-03 16:13 ---
Created an attachment (id=11367)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11367action=view)
patch
Patch to be tested (Micha, can you do this?).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27409
I just tried to compile Suse package kdbg-2.0.3-12 with a recent
GNU C++ compiler version 4.2 snapshot 20060429.
The compiler snapshot said
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/opt/kde3/include -I/usr/lib/qt3/include
-I/usr/X11R6/include
-DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long
--- Comment #27 from paolo at gcc dot gnu dot org 2006-05-03 17:00 ---
Subject: Bug 6702
Author: paolo
Date: Wed May 3 17:00:18 2006
New Revision: 113498
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113498
Log:
2006-05-03 Paolo Carlini [EMAIL PROTECTED]
*
--- Comment #28 from pcarlini at suse dot de 2006-05-03 17:01 ---
Fixed (again), for 4.1.1.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from kargl at gcc dot gnu dot org 2006-05-03 17:10 ---
Phillipe,
Your code appears to be wrong, or perhaps you've cut down a
larger code too agressively. You use the Fortran ALL intrinsic
on the allocatable NEW_NUMBER, but you have never actually
allocated memory for
--- Comment #1 from geoffk at gcc dot gnu dot org 2006-05-03 17:12 ---
If fixed, this will be fixed in the Darwin linker. In the meantime, don't use
-force_flat_namespace. In fact, it's probably better if you don't use it at
all; the system libraries aren't expecting it and this is
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-03 17:36 ---
*** This bug has been marked as a duplicate of 27210 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-03 17:36 ---
*** Bug 27410 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from amacleod at redhat dot com 2006-05-03 17:13 ---
Subject: Bug 27381
Author: amacleod
Date: Wed May 3 17:13:37 2006
New Revision: 113499
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113499
Log:
2006-05-02 Andrew MacLeod [EMAIL PROTECTED]
PR
--- Comment #4 from matz at suse dot de 2006-05-03 17:53 ---
Yes. I'm testing it for trunk and 4.1 on a couple platforms.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27409
--- Comment #5 from matz at suse dot de 2006-05-03 17:54 ---
Created an attachment (id=11368)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11368action=view)
patch relative to 4.1
This is the same patch adjusted for 4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27409
--- Comment #3 from langel at redhat dot com 2006-05-03 18:36 ---
Fixed
--
langel at redhat dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from sayle at gcc dot gnu dot org 2006-05-03 18:49 ---
Subject: Bug 25309
Author: sayle
Date: Wed May 3 18:49:40 2006
New Revision: 113500
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113500
Log:
PR c/25309
* c-typeck.c (struct spelling): Make I
--- Comment #5 from dann at godzilla dot ics dot uci dot edu 2006-05-03
18:54 ---
IMO Comment #4 does not look close enough at what is actually happening.
IMO tree-ch is the root cause here.
The code looks like this before .ch
Before .ch
goto bb 2 (L1);
L0:;
D.1301_54 =
--- Comment #5 from dann at godzilla dot ics dot uci dot edu 2006-05-03
18:54 ---
IMO Comment #4 does not look close enough at what is actually happening.
IMO tree-ch is the root cause here.
Given the above CFG, critical edge splitting transforms this into:
Given the above
--- Comment #6 from pinskia at physics dot uc dot edu 2006-05-03 19:00
---
Subject: Re: [4.1/4.2 Regression] -ftree-ch generates worse code
--- Comment #5 from dann at godzilla dot ics dot uci dot edu 2006-05-03
18:54 ---
IMO Comment #4 does not look close enough
--- Comment #4 from fitzsim at redhat dot com 2006-05-03 19:24 ---
After a discussion about this with Sven, I think our current implementation is
fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16741
--- Comment #5 from fitzsim at redhat dot com 2006-05-03 19:25 ---
Closing as WONTFIX.
--
fitzsim at redhat dot com changed:
What|Removed |Added
--- Comment #5 from P dot Schaffnit at access dot rwth-aachen dot de
2006-05-03 19:28 ---
Erm... sorry about that, I didn't think about it: I've indeed thrown out a lot
(I do not have the original sources at hand, but they are happily compiled by
quite a few compilers, including lf95,
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-05-03 19:34 ---
Subject: Re: [4.2 Regression] GCC error: in n_of_executions_at_least, at
tree-ssa-loop-niter.c:1772
The problem in this PR should have been fixed by my yesterday's patch,
does this still
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-03
19:39 ---
Subject: Re: [4.2 Regression] GCC error: in n_of_executions_at_least, at
tree-ssa-loop-niter.c:1772
The problem in this PR should have been fixed by my yesterday's patch,
does this still reproduce for
--- Comment #2 from kargl at gcc dot gnu dot org 2006-05-03 21:24 ---
Subject: Bug 26896
Author: kargl
Date: Wed May 3 21:24:11 2006
New Revision: 113502
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113502
Log:
2006-03-30 Steven G. Kargl [EMAIL PROTECTED]
PR
--- Comment #8 from kargl at gcc dot gnu dot org 2006-05-03 21:24 ---
Subject: Bug 20248
Author: kargl
Date: Wed May 3 21:24:11 2006
New Revision: 113502
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113502
Log:
2006-03-30 Steven G. Kargl [EMAIL PROTECTED]
PR
--- Comment #3 from kargl at gcc dot gnu dot org 2006-05-03 21:24 ---
Fixed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from kargl at gcc dot gnu dot org 2006-05-03 21:26 ---
Fixed by the additional of -fall-intrinsics option.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 119 matches
Mail list logo
