--- Comment #9 from jakub at gcc dot gnu dot org 2005-11-07 08:02 ---
Subject: Bug 23567
Author: jakub
Date: Mon Nov 7 08:01:54 2005
New Revision: 106585
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106585
Log:
PR rtl-optimization/23567
* ifcvt.c
--- Comment #10 from jakub at gcc dot gnu dot org 2005-11-07 08:28 ---
Subject: Bug 23567
Author: jakub
Date: Mon Nov 7 08:28:01 2005
New Revision: 106586
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106586
Log:
PR rtl-optimization/23567
* ifcvt.c
--- Comment #7 from rth at gcc dot gnu dot org 2005-11-07 08:48 ---
I stand by my statement. This cannot go in libgcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-07 10:16 ---
Paolo, the only viable way to get these inlined looks like a libstdc++
configure-time choice to say --disable-i386-support or sth like that. You then
build libstdc++ against the atomic builtin primitives and at
--- Comment #9 from pcarlini at suse dot de 2005-11-07 10:23 ---
(In reply to comment #8)
Paolo, the only viable way to get these inlined looks like a libstdc++
configure-time choice to say --disable-i386-support or sth like that. You
then
build libstdc++ against the atomic
--- Comment #7 from thebohemian at gmx dot net 2005-11-07 10:34 ---
Created an attachment (id=10161)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10161action=view)
preliminary patch - just for review
As andrew suggested I tried preparing a closure that is stored in the atable
and
--- Comment #27 from bonzini at gcc dot gnu dot org 2005-11-07 10:39
---
Subject: Bug 24230
Author: bonzini
Date: Mon Nov 7 10:39:36 2005
New Revision: 106588
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106588
Log:
2005-11-07 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #8 from aph at gcc dot gnu dot org 2005-11-07 10:40 ---
It's not possibe from this description to tell when this problem occurs, nor
which kind of error it is. What does crash mean? When does it occur?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
--- Comment #28 from bonzini at gcc dot gnu dot org 2005-11-07 10:41
---
patch committed
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
Error while compiling an OpenMP code that uses schedule(dynamic) clause:
$ gcc -fopenmp -c -lgomp ompparfor.c
ompparfor.c: In function â:
ompparfor.c:6: error: â undeclared (first use in this function)
ompparfor.c:6: error: (Each undeclared identifier is reported only once
ompparfor.c:6: error:
__gnu_cxx::__exchange_and_add shows up in profiles of the PowerDNS recursor,
which is single threaded. I'm somewhat amazed this is an out-of-line function
(there are 40 cycles to be gained by inlining it, and this function gets called
a lot), but I'm worried more about the 1000 cycle overhead even
--- Comment #7 from bonzini at gcc dot gnu dot org 2005-11-07 12:14 ---
patch committed to trunk, it's a bit different for 4.0 branch so it'll take a
while to test it.
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ahu at ds9a dot nl 2005-11-07 12:39 ---
that would be http://wiki.powerdns.com - not sure how I mistyped that.
Also, the application in question is rather string-happy, which is probably why
the exchange_and_add thing shows up so much.
--
--- Comment #9 from thebohemian at gmx dot net 2005-11-07 12:51 ---
Ok, more details:
With my patch applied I run the test application in lazylinker.tar.bz2. Set up
the variable CLASSPATH to point to lib/java/lazylinker.jar, start gdb with gij,
set a breakpoint at link.cc:743 and run
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-07 12:58 ---
I'm marking this ice-on-invalid-code, as it is not valid Fortran 95 and the bug
is unrelated to the use of IMPORT, the following ICEs the same way:
module gfcbug29_import
interface
subroutine foo (x)
--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-07 13:07 ---
(In reply to comment #3)
Thank you Salvatore and Andrew.
The proposed patch is about to be posted on the fortran and gcc-patches list.
I just have a couple more minutes of testing other, completely off-the-wall
--- Comment #1 from tobi at gcc dot gnu dot org 2005-11-07 13:09 ---
Is this still the case? No other platform seems to be affected.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
character (6) :: c
c = f1 ()
if (c .ne. 'abcdef') call abort
contains
function f1 ()
character (*) :: f1
f1 = 'abcdef'
end function f1
end
causes ICE, while it should be diagnosed as error.
--
Summary: ICE on asterisk char-len-param-value on result
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-07 13:17
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
subroutine foo (n)
integer :: n
type bar
integer :: x (n)
end type bar
type (bar) :: q
q%x = 6
end subroutine foo
should be rejected. If an array in derived type doesn't have POINTER
attribute,
it shall be explicit shape with constant bounds, if it has POINTER attribute,
it must be
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-07 13:17
---
Fixed at least on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from uros at kss-loka dot si 2005-11-07 13:20 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00438.html
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 13:25 ---
Confirmed.
Blocks PR 15809 because a related testcase is referenced in comment #13.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 13:27 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 13:36 ---
Actually IIRC Koenig lookup only finds functions and not variables. If that is
the case we have two issues here. One is we accept invalid and another is that
error message is wrong.
Note ICC rejects this:
This problem occured when compiling linux-2.6.14-mm1 tree on a Red Hat Linux
release 9 with a gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5). The
compilation of a linux-2.6.14 tree is ok. Here is the message (I added -v
option in arch/i386/kernel/Makefile):
$ make O=/home/guill/build/k2614-mm1
When running g++ -O1 -c t3.cc on the attached preprocessed C++ source file
with 4.1.0 HEAD as of 2005-11-07 with enable-checking I get the error message
as attached.
The problem does neither happen with diable-checking nor with -O0. It does
happen with enable-checking and all optimization levels
--- Comment #1 from rschiele at uni-mannheim dot de 2005-11-07 14:24
---
Created an attachment (id=10162)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10162action=view)
gzipped preprocessed source code
the preprocessed source code that triggers the problem --- yes, it is large
--- Comment #2 from rschiele at uni-mannheim dot de 2005-11-07 14:25
---
Created an attachment (id=10163)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10163action=view)
gzipped error message
the gzipped error message when building with -O1
--
--- Comment #10 from green at redhat dot com 2005-11-07 14:47 ---
This patch seems overly complicated to me. I don't think we need the
trampoline function and the ffi_call. Since we're just planning on throwing
an exception, it seems like you should just be able to pass the class
--- Comment #5 from tobi at gcc dot gnu dot org 2005-11-07 14:49 ---
While the original problem seems to have been fixed, we have a regression here:
if we comment out the line marked as this works everything compiles fine and
we get an executable that works (doesn't segfault), if we
--- Comment #11 from aph at gcc dot gnu dot org 2005-11-07 14:52 ---
You're not describing this clearly. :-)
We need to point the execution vector at a piece of code that throws an
exception with the appropriate args. Now, how should we do that?
--
The following code snippet produces an incorrect error message (since gcc 3.0):
==
templatetypename T struct A {};
templatetypename U void foo(AU);
templatetypename T AT bar() { x; }
template Aint barint();
==
The
--- Comment #12 from green at redhat dot com 2005-11-07 15:06 ---
(In reply to comment #11)
You're not describing this clearly. :-)
We need to point the execution vector at a piece of code that throws an
exception with the appropriate args. Now, how should we do that?
The
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 15:09 ---
All I can say for this one is that was fixed in 3.3.6 as 3.2.x is no longer
being updated (even 3.3.6 was the last release of 3.3.x). If you need support
for 3.2.x with the compiler version you have, you should
I did a fresh down of gfortran this morning and the build fails at -
make \
CFLAGS=-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Wmissing-format-attribute -fno-common \
CONFIG_H=tconfig.h
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 15:13 ---
Isn't this really PR 99?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24711
--- Comment #2 from neroden at gcc dot gnu dot org 2005-11-07 15:15 ---
True, enhancement request.
--
neroden at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 15:16 ---
Are you building in a clean object directory? If not can you try that as from
the looks of it, you configured for 10.4.2 and not 10.4.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-07 15:26 ---
Reducing (which means I can reproduce it).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24709
This is Debian bug #336114:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336114
I don't claim to be able to understand it all, but apparently (for example)
kdebase built with 4.0.2 doesn't work with arts built with 4.0.1. Symbol
changes in arts between building with 4.0.1 and pre-4.0.2 look
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 15:35 ---
This looks like it was caused by the patches to fix the following PRs:
PR libstdc++/19265
PR libstdc++/22309
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from reichelt at gcc dot gnu dot org 2005-11-07 15:38
---
You're probably right, Andrew.
This looks like a duplicate of PR99.
*** This bug has been marked as a duplicate of 99 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from reichelt at gcc dot gnu dot org 2005-11-07 15:38
---
*** Bug 24711 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dir at lanl dot gov 2005-11-07 16:11 ---
It failed under 10.4.2 from a completely new down load - then I upgraded to
10.4.3 to see if that would help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
--- Comment #3 from olh at suse dot de 2005-11-07 16:17 ---
ping
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
See:
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00320.html
--
Summary: objc/execute/exceptions/foward-1.m fails on sh-elf with
-O3
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code, EH
See:
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00317.html
This looks like libobjc and objc not agreeing on the layout of a class.
--
Summary: objc/execute/bf-10.m and others fail on sh64-elf
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
--- Comment #17 from r dot emrich at de dot tecosim dot com 2005-11-07
16:25 ---
Sorry, for the delay.
I had a machine fault on the weekend.
So, I'm trying the snapshot from 5th of november now!
Look's good so far, already in stage 2.
--
--- Comment #3 from dir at lanl dot gov 2005-11-07 16:47 ---
Here is another try from another complete download under 10.4.3 -
# When builting multilibbed target libraries, all the required
# When builting multilibbed target libraries, all the required
# libraries are expected to
--- Comment #4 from andreast at gcc dot gnu dot org 2005-11-07 16:54
---
On which target do you build? G4/5?
What are the config options you use?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
--- Comment #2 from pcarlini at suse dot de 2005-11-07 16:59 ---
I have to add a comment: all those crashing KDE applications (I looked at the
KDE PRs) are evidently using mt_allocator. Now, mt_allocator is not the alloc
which FSF gcc4.0.x uses by default, the only one for which ABI
--- Comment #3 from ahu at ds9a dot nl 2005-11-07 17:00 ---
I've now verified that even when the entire compiler is compiled with
--enable-threads=single, the resulting libstdc++ does the full 'lock; xadd'
thing in __exchange_and_add, which I consider a bug (and more importantly, so
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-07 17:05 ---
Linking to the orginal thread:
http://gcc.gnu.org/ml/libstdc++/2004-02/msg00372.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-07 17:06 ---
This is a regression too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #6 from pcarlini at suse dot de 2005-11-07 17:07 ---
(In reply to comment #3)
I've now verified that even when the entire compiler is compiled with
--enable-threads=single, the resulting libstdc++ does the full 'lock; xadd'
thing in __exchange_and_add,
This is well
--- Comment #14 from steven at gcc dot gnu dot org 2005-11-07 17:19 ---
As an interesting data point: Intel's ICC 8.0 does what GCC 3.3 and earlier do,
but it seems that ICC 9.0 follow GCC 3.4 and later...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-07 17:32 ---
Actually the real issue is not even here and there is no performance problems
with the out of line/non threaded calls but the real issue is that we are just
calling them too much.
--
pinskia at gcc dot gnu dot
__gnu_cxx::__exchange_and_add shows up in profiles of the PowerDNS recursor.
http://wiki.powerdns.com
The issue here is that __exchange_and_add is called too much and not it is
inlined. Now someone should go and figure out why this is called too much (I
don't have a profile).
--
--- Comment #8 from pcarlini at suse dot de 2005-11-07 17:36 ---
(In reply to comment #7)
Actually the real issue is not even here and there is no performance problems
with the out of line/non threaded calls but the real issue is that we are just
calling them too much.
Andrew, in
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-07 17:38 ---
(In reply to comment #8)
Andrew, in some sense you are right, given the current reference-counted
nature
of std::string. However, let's not close this PR: submitter has a point that
the user should be enabled
--- Comment #1 from pcarlini at suse dot de 2005-11-07 17:38 ---
.. on the other hand, I think we should close this one, sorry ;) As long as we
have a reference counted string and the user cannot disable the use of atomic
operations when single threaded, there isn't much we can do.
--- Comment #17 from rnewman at compubrite dot com 2005-11-07 17:39 ---
I concede the argument.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24680
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-07 17:39 ---
I actually disagree with that. We really need more info (I don't have the
profiles to see why we are calling this too much but we really need to figure
it out).
--
--- Comment #3 from pcarlini at suse dot de 2005-11-07 17:41 ---
(In reply to comment #2)
I actually disagree with that. We really need more info (I don't have the
profiles to see why we are calling this too much but we really need to figure
it out).
Whatever... ;)
--
--- Comment #2 from rwcrocombe at raytheon dot com 2005-11-07 17:59 ---
Bootstrapping 4.0.2 via older 3.4.4 appears to work. I'll give the test suite
a whirl if I get the chance.
Thanks for the suggestion (I was a little leery of trying older gccs after my
problems with a different
--- Comment #5 from uweigand at gcc dot gnu dot org 2005-11-07 18:03
---
Alternatively, the PR is also fixed by rth's patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00424.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24621
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #8 from bonzini at gcc dot gnu dot org 2005-11-07 18:17 ---
Subject: Bug 24599
Author: bonzini
Date: Mon Nov 7 18:17:35 2005
New Revision: 106600
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106600
Log:
2005-11-07 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #9 from bonzini at gcc dot gnu dot org 2005-11-07 18:18 ---
fixed on 4.0 branch too
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from bonzini at gcc dot gnu dot org 2005-11-07 18:19 ---
it works now
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from bonzini at gcc dot gnu dot org 2005-11-07 18:22
---
Is this a 4.0 regression too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
--- Comment #3 from sje at cup dot hp dot com 2005-11-07 18:26 ---
It looks like this is fixed on the mainline and on the 4.0 branch by the
addition of
bypass = __GNUG__;
This patch was done in revision 90550 by jsm28. We should do this for the 3.4
branch as well.
--
sje at cup
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|sco_math fixincl breaks |[3.4 Regression] sco_math
|math.h
In a large application, a certain routine from the UMFPACK library is
miscompiled when -O is specified. Without optimisation, the routine works
fine. This triggers an assertion failure in the code.
I use gcc (GCC) 4.1.0 20051030 (experimental). The problem can be reproduced
with the attached
--- Comment #4 from sje at cup dot hp dot com 2005-11-07 18:40 ---
Original patch submittal is at
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00985.html
I will apply this to the 3.4 branch and test it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24688
--- Comment #20 from ian at airs dot com 2005-11-07 18:41 ---
By the way, Richard, I just want to note that while this is obviously a
compiler bug, it is only being triggered for the original test case because of
the uninitialized variable i in sha1_update:
void
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Summary|Wrong code generated when |[4.1
--- Comment #1 from schnetter at aei dot mpg dot de 2005-11-07 18:42
---
Created an attachment (id=10165)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10165action=view)
Tarball with source code demonstrating the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
--- Comment #21 from mueller at kde dot org 2005-11-07 18:45 ---
its an error in the testcase, the original code initializes i:
if((j + len) 63) {
562 memcpy(context-buffer[j], data, (i = 64-j));
563 transform(context-state,
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-07 18:49 ---
(In reply to comment #0)
The error seems to be specific to powerpc; it does not happen on i386.
It does fail for me on i686 with 4.1.0 20051026.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
--- Comment #22 from ian at gcc dot gnu dot org 2005-11-07 18:52 ---
Subject: Bug 24683
Author: ian
Date: Mon Nov 7 18:52:24 2005
New Revision: 106601
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106601
Log:
./:
PR rtl-optimization/24683
* config/i386/i386.c
--- Comment #23 from ian at gcc dot gnu dot org 2005-11-07 18:55 ---
Subject: Bug 24683
Author: ian
Date: Mon Nov 7 18:55:03 2005
New Revision: 106602
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106602
Log:
./:
PR rtl-optimization/24683
* config/i386/i386.c
--- Comment #24 from ian at airs dot com 2005-11-07 18:58 ---
Fixed on 4.0 branch and on mainline.
The 3.4 branch breaks in a slightly different way. I'm not going to worry
about it since you can only create this problem by building implausible
addresses that include offsets of more
enum A{a,b,c};
templatetypename T, int i, A x, typename U void f(const U, int) {}
templatetypename T, int i, typename U void f(const U, int) {}
templatetypename U void f(const U, int) {}
templatetypename T, A x, typename U void f(const U, int, int) {}
templatetypename T, typename U void f(const U,
--- Comment #2 from dnovillo at gcc dot gnu dot org 2005-11-07 19:06
---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00458.html
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dir at lanl dot gov 2005-11-07 19:17 ---
I do the get with -
[dranta:~/utlib] dir% cat gfortranGet
cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gcc co gcc
I do the configure with -
[dranta:~/utlib] dir% cat gfortranConfig
configure --prefix=/Users/dir/gfortran
--- Comment #6 from dir at lanl dot gov 2005-11-07 19:19 ---
I have a dual 2.5 GHZ PowerPC G5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
I've built gcc-3.4.3 for HP-UX 11.23/IA-64 and used the pre-compiled
gcc-3.4.4 binary from the http://www.hp.com/go/gcc site. Both exhibit
the same problem. While trying to build Perl 5.8.6:
$ gmake
...
gcc -v -o libperl.so -shared -fPIC perl.o gv.o toke.o perly.o op.o
pad.o regcomp.o
--- Comment #24 from jason at gcc dot gnu dot org 2005-11-07 19:35 ---
This is a bug in the generic thunk support; it doesn't show up on x86 because
it uses asm thunks. Continuing to investigate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
--- Comment #17 from wilson at gcc dot gnu dot org 2005-11-07 19:49 ---
Subject: Bug 15220
Author: wilson
Date: Mon Nov 7 19:49:04 2005
New Revision: 106608
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106608
Log:
Fix problem with -MM -MG and missing system header files.
PR
--- Comment #18 from wilson at gcc dot gnu dot org 2005-11-07 19:51 ---
Mine.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #19 from wilson at gcc dot gnu dot org 2005-11-07 19:52 ---
Fixed on gcc-3.4.x branch, gcc-4.0.x branch, and mainline.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from matz at suse dot de 2005-11-07 19:59 ---
Of course not. But unaware people trying trunk currently on distros which
provided 3.4 or 4.0 will get non-obvious problems, and I'm not sure if that's
a good idea (ignoring this problem 4.0 and trunk are nearly compatible,
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-07 20:03 ---
Can you try first by not building in the source directory?
Second that CVS repro is no longer being updated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
--- Comment #13 from thebohemian at gmx dot net 2005-11-07 20:03 ---
anthony you're right. It should work without ffi_call invocation.
Thanks for the review. I try to find out whether this fixes my segfault too,
tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
--- Comment #5 from pault at gcc dot gnu dot org 2005-11-07 20:14 ---
Did this patch ever get posted?
Tobi, that's a coincidence; I just found it whilst working on dot_product!
I'll submit in the next 24 hours. I've found another patch that I just forgot
about too
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-07 20:39 ---
A little more info, umf_analyze.i is being miscompiled. I don't know which one
yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
1 - 100 of 171 matches
Mail list logo
