--- Additional Comments From pierre42d at 9online dot fr 2004-10-25 06:06 ---
I used ./configure --enable-shared --enable-threads --enable-nls
--with-system-zlib --with-x --enable-gtk-cairo --enable-java-awt=gtk,xlib
# export|grep CFLAGS
declare -x CFLAGS=-s -O3 -march=i686
--
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-25 06:09
---
This is the same problem as on Solaris. I should have done my homework...
--
What|Removed |Added
--
What|Removed |Added
BugsThisDependsOn||18139
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18107
Starting at least as earily as 2004-10-20, GCC will miscompile libcpp/charset.c,
causing the built GCC to ICE when parsing a wide character literal.
This causes bootstrap to fail while attempting to compile a libjava source file
that uses wide character literals. The only work-around that I have
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-25 06:31
---
For what its worth, this bug wasn't introduced recently. It was failing at
least since June 1st, 2004. I'll continue to search for offending changes.
This may take a few days.
--
--- Additional Comments From bonzini at gcc dot gnu dot org 2004-10-25 07:39
---
--enable-bootstrap would build libcpp and libiberty with the newly-built GCC.
It is correct that the host compiler is used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18139
--- Additional Comments From dannysmith at users dot sourceforge dot net
2004-10-25 08:14 ---
Compiling charset.c with -O2 -fno-unit-at-a-time with newly built cc1.exe also
avoids the bug.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18139
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-25 09:01
---
Subject: Bug 18138
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-25 09:01:15
Modified files:
gcc/testsuite : ChangeLog
libffi :
gcc incorrectly rejects the following template code - seems to be a bug in the
new (gcc 3.4) C++ parser.
g++-4.0 -Wall -W x.cpp
x.cpp:6: error: spurious '', use '' to terminate a template argument list
x.cpp:6: error: expected primary-expression before S
x.cpp:6: error: expected %;% before S
* the options given when GCC was configured/built;
Configured with: /home/niva/src/gcc-3.4-binutils/configure
--with-headers=/home/vxuser/oc2000/mips/src/include
--without-libs --enable-generated-files-in-srcdir
--enable-threads=posix -with-dwarf2 --disable-shared
--target=mips64-none-elf
--- Additional Comments From bangerth at dealii dot org 2004-10-25 11:31 ---
Confirmed, a regression in 3.4 and mainline.
W.
--
What|Removed |Added
Keywords|
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 11:41
---
*** This bug has been marked as a duplicate of 17526 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 11:41
---
*** Bug 18139 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
Bug 18107 depends on bug 18139, which changed state.
Bug 18139 Summary: [4.0 Regression] GCC miscompiles libcpp/charset.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18139
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 11:45
---
Looks like caused by the new parser
: Search converges between 2003-12-18-trunk (#431) and 2003-12-24-trunk (#432).
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 11:51
---
Can you try without setting the CFLAGS?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18132
--- Additional Comments From kgardas at objectsecurity dot com 2004-10-25 12:03
---
Subject: Re: [4.0 Regression] [tree-ssa] Many
C++ compile-time regression in 4.0-tree-ssa 040120
Sure! Here we go: http://gcc.gnu.org/ml/gcc/2004-10/msg00952.html
and results are really promissing,
Gcc head has been failing to bootstrap for me for weeks now.
I'm astounded to find this going on, and not finding a match in bugzilla;
I don't think I have anything special in my set-up. This is a vanilla Mac G$
running OS X 10.3.5 Panther. Is nobody else seeing this?
No options to configure
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 12:41
---
You need a new cctools see:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01222.html
for details.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 12:55
---
Rewording summary because now we are only 23%:
File342-O0 400-O0 Delta% 342-O1 400-O1 Delta% 342-O2 400-O2 Delta%
typecode.cc 9.097.6518.82 13.53 17.73 -23.69 32.95
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de
2004-10-25 13:02 ---
Subject: Re: [4.0 Regression] [tree-ssa] Many
C++ compile-time regression in 4.0-tree-ssa 040120
And
http://gcc.gnu.org/ml/gcc/2004-10/msg00955.html
--
--- Additional Comments From kgardas at objectsecurity dot com 2004-10-25 13:06
---
Subject: Re: [4.0 Regression] 24% C++ compile-time regression
in comparison with 3.4.1 at -O1 optimization level
Yes, but this only apply to typecode.cc. If you consider ir.cc, you will
need to
For the code listed below, GCC 4.0 (20041010) emits duplicated virtual
destructor thunk, so assembler fails to compile.
The size of c3::m member does matter there - test fails with magic value
0x3fffd or above and passes with any value below.
$ cat go.cpp
struct c0 {
virtual void foo(){};
--- Additional Comments From kgardas at objectsecurity dot com 2004-10-25 13:12
---
Subject: Re: [4.0 Regression] 24% C++ compile-time regression
in comparison with 3.4.1 at -O1 optimization level
Please have a look into http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
for
--- Additional Comments From bothner at gcc dot gnu dot org 2004-10-25 13:18
---
I think this should remain open as long as we don't have a configure-time check
to warn about an invalid assembler. Otherwise the support burden will be
intolerable. Kelley's configure patch to check the
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 13:20
---
I get an ICE on the mainline without disabling checking:
pr18143.cc:20: internal compiler error: in make_thunk, at cp/method.c:127
Please submit a full bug report,
with preprocessed source if appropriate.
--- Additional Comments From kgardas at objectsecurity dot com 2004-10-25 13:20
---
Subject: Re: [4.0 Regression] [tree-ssa] Many
C++ compile-time regression in 4.0-tree-ssa 040120
Updated table with GCC 3.4.2 and 4.0.0-041024 results is available here:
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 13:21
---
It was reverted because it made a cross compiler to powerpc-darwin imposiable if you
only wantted a
cc1 and not a full fledge compiler (which is useful when debuging bugs).
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-25 13:27
---
Subject: Bug 17407
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-25 13:27:33
Modified files:
gcc: ChangeLog c-decl.c tree.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-25 13:27
---
Subject: Bug 18121
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-25 13:27:33
Modified files:
gcc: ChangeLog c-decl.c tree.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 13:28
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 13:28
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pcarlini at suse dot de 2004-10-25 14:03 ---
There is agreement among library maintainers that the analysis in libstdc++/13537
(Comment #3) is correct. See also http://tinyurl.com/52oro
*** This bug has been marked as a duplicate of 13537 ***
--
--- Additional Comments From pcarlini at suse dot de 2004-10-25 14:03 ---
*** Bug 18080 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 14:07
---
For ir.cc, does -fno-threadsafe-statics help if so this is a non bug (in that c++
front-end has changed
to output more functions so what does the middle-end/back-end expect but slower
compile time for
--- Additional Comments From bangerth at dealii dot org 2004-10-25 14:24 ---
Here is a short testcase:
--
struct X {
bool init;
void foo() { if (!init) init = true; }
void bar() { foo(); }
};
typedef unsigned long long int
--- Additional Comments From uros at kss-loka dot si 2004-10-25 14:35 ---
The problem here is triggered in reload() function around line 950, this part
(#ifdef'd part was added by me:):
for (i = FIRST_PSEUDO_REGISTER; i max_regno; i++)
if (reg_renumber[i] 0
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 14:56
---
It also works in 3.3.3.
--
What|Removed |Added
Known to work|4.0.0
--- Additional Comments From dje at gcc dot gnu dot org 2004-10-25 15:46 ---
GCC is using fix_truncdfdi2 because no unsfix_truncdfsi2 pattern is defined and
clock_t is an unsigned long. A short-term workaround is to implement an
unsfix_truncdfsi2 pattern for PPC64 that uses fctid and
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-25 15:54
---
David Edelsohn wrote:
One could view this problem as reload not obeying CANNOT_CHANGE_MODE_CLASS
because it should not try to spill just the SImode SUBREG instead of creating a
DImode temporary on the
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-25 16:20
---
Does this patch help?
Index: gcc/simplify-rtx.c
===
RCS file: /cvs/gcc/gcc/gcc/simplify-rtx.c,v
retrieving revision 1.206
diff -c -p -r1.206
The following code, that compiles well with 3.3.4, doesn't compile with 3.4.2,
complaining that toto hasn't been declared.
template typename T
class Miyeu
{
public:
T* toto;
};
template typename T
class Fin : public Miyeu T
{
public:
int taille;
protected:
void allouer( int p_taille )
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 16:30
---
Read the release notes.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 16:31
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2004-10-25 16:31:39 |2004-10-25 16:32:16
date|
--- Additional Comments From steven at gcc dot gnu dot org 2004-10-25 16:34
---
I think the brute-force approach of just updating
current_function_has_computed_jump in a FOR_EACH_BB loop
after calling make_edges is a good enough fix for this
problem. We can figure out if we have
See FIXME in avr.c, function avr_file_start.
--
Summary: Do not emit __do_copy_data or __do_clear_bss if .data or
.bss is empty.
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Consider:
int
foo (int a)
{
switch (a)
{
case 1:
case 3:
case 5:
return 1;
default:
return 0;
}
}
./cc1 -O2 -fomit-frame-pointer -mregparm=3 -march=athlon-xp generates
foo:
cmpl$5, %eax
movl%eax, %ecx
ja .L2
movl
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 16:47
---
Subject: Re: ICE cause by reload
uweigand at gcc dot gnu dot org writes:
Ulrich Does this patch help?
It changes the error, but I'm not sure if it helps.
pr15286.c: In function 'GMRESSolver':
--- Additional Comments From guillaume dot lemaitre33 at wanadoo dot fr
2004-10-25 16:54 ---
sorry for the annoyment
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18144
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 17:01
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 17:03
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-25 17:17
---
Well, as I understand it, SUBREG (MEM) is *supposed* to be generated
for the case of SUBREG (pseudo) where the pseudo gets a stack slot.
The scan_paradoxical_subregs mechanism was supposed to have
The code reduces to:
struct QgsScaleCalculator
{
QgsScaleCalculator(int dpi = 0,
QgsScaleCalculator mapUnits = 0);
};
struct CanvasProperties
{
CanvasProperties (): scaleCalculator (new QgsScaleCalculator) {}
QgsScaleCalculator * scaleCalculator;
};
But this code is
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 18:04
---
Subject: Re: ICE cause by reload
With both patches, the testcase works. This probably is a correct
fix for reload.
The code is a little messy and is cleaned up by implementing
--- Additional Comments From dje at gcc dot gnu dot org 2004-10-25 18:33 ---
Correction. While the reload changes fix the crash, it looks like there still
is a bug because the resulting code does not access the correct SUBREG. It
does not access the LSW.
--
--- Additional Comments From fjahanian at apple dot com 2004-10-25 18:39 ---
I applied the last two patch, but it didn;t help:
% mygccf -O2 -mcpu=G5 -c loader_obj.i
loader_obj.c: In function 'load_obj':
loader_obj.c:92: error: unrecognizable insn:
(insn 1395 601 1396 50 (set (subreg:DI
If you declare an object within an instance initializer, you cannot declare
another object of the same name in a different instance initializer.
This description seems pretty opaque, so an example of correct code that GCJ
rejects is probably better:
-- init.java --
import java.util.HashMap;
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 18:49
---
Confirmed, a workaround is to do something like this:
import java.util.HashMap;
class init
{
{{
Object foo = new Object();}
}
{
Object foo = new Object();
}
}
The reduced testcase:
import
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-25 18:55
---
As a workaround you can put an extra block inside the
instance initializers:
{{ Object foo = ... }}
The bug here seems to be that gcj chains the statements
of each initializer block together when making
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 19:07
---
Subject: Re: ICE cause by reload
I applied the last two patch, but it didn;t help:
The simplify-rtx.c patch is not *two* patches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15286
--- Additional Comments From fjahanian at apple dot com 2004-10-25 19:12 ---
You referred to them as 'both patches' in comment #21.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15286
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 19:14
---
The second patch has to due with However, cleanup_subreg_operands first recognizes
the insn, and
this is
where it presumably fails; due to this weird piece of code in general_operand:
--
gcj computes the type of the `itable' field of Class
differently from how the runtime declares this type.
This is confusing to the maintainer and potentially
fragile (depending on the vagaries of struct layout).
See http://gcc.gnu.org/ml/java-patches/2004-q4/msg00286.html
--
Summary:
this is a regression since I was already able to bootstrap gcc-4.0 on OD 7.2.1/x86
successfully:
http://gcc.gnu.org/ml/gcc/2004-09/msg00757.html
The procedure for bootstrapping was similar to the one described in the message above,
the only
difference is that I used
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 19:40
---
Confirmed, (here is the ironic part): it was caused by the patch which made cctools
528.5 required:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01222.html
--
What|Removed
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-25 19:48
---
I also don't think this is a C++ bug: its a bug in whatever compiled libcpp,
which probably wasn't a C++ compiler.
Also, does this affect all x86 targets? Does it affect i?86-pc-linux*?
The testcase can
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 19:55
---
I also note I can reproduce this when using the C compiler so it definitely has
nothing to do with the
C++ compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17526
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 19:59
---
I should note that it does not effect i686-pc-linux-gnu for some reason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17526
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 20:06
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18149
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 20:19
---
This is basically is already fixed on the mainline, the only thing left is left is
documentation.
See PR 15145.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 20:21
---
Actually only part of the documenation is needed to change see:
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg02356.html.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 20:23
---
Oh, I had forgot to commit the patch which removed the inaccurate part will do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18150
Building and running fixincludes for the avr target is not necessary with the
current canonical toolset of binutils, gcc and avr-libc:
http://savannah.nongnu.org/projects/avr-libc/
Building fixincludes currently fails for host=mingw32 host, which being
corrected with bug #17832. But building
--
What|Removed |Added
CC||denisc at overta dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18151
--
What|Removed |Added
CC||marekm at amelek dot gda dot
||pl
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18151
--- Additional Comments From ericw at evcohs dot com 2004-10-25 20:33 ---
I've added the AVR mainters to the CC list of this bug.
Would one of the AVR maintainers (Denis, Marek) be willing to approve such a
change since this is a new feature?
Thanks
Eric
--
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-25 20:38
---
David Edelsohn wrote: Correction. While the reload changes fix the crash, it looks
like there still is a bug because the resulting code does not access the correct
SUBREG. It does not access the
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-25 20:42
---
(My last message got messed up somehow, I'm trying again.)
David Edelsohn wrote:
Correction. While the reload changes fix the crash, it looks like there still
is a bug because the resulting code
--- Additional Comments From fjahanian at apple dot com 2004-10-25 20:58 ---
You need to replace GET_MODE_SIZE (x) with GET_MODE_SIZE (GET_MODE (x)), etc. for a
clean
compile. But as I mentioned in last comment, I still get the ICE with or without this
patch (along
with the previous
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-25 21:04
---
well, as pointed out by David you do need in addition the change I
described in comment #20.
If you prefer a patch:
Index: gcc/recog.c
===
--- Additional Comments From steven at gcc dot gnu dot org 2004-10-25 21:10
---
I have a patch that fixes this. I need to figure out a way to do it in a way
that doesn't require you to pass -fno-crossjumping -fno-gcse but I'll figure
out something...
--
What
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 21:11
---
Subject: Re: ICE cause by reload
With the earlier *two* patches from Ulrich, the compiler no longer
ICE.
The latest patch to alter_subreg() (with the missing GET_MODEs)
does not fix the
--- Additional Comments From fjahanian at apple dot com 2004-10-25 21:14 ---
By mistake, I applied the test for !reload_completed to you earlier patch (which was
worng).
In any case,
after correcting the patch and with your latest patch, all my test cases passed. Now,
I need
to do a
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 21:42
---
Oh, it looks like the powerpc bug was different from the avr one and for the avr bug
it looks like a
target problem and nothing else, the rtl looks small.
--
What|Removed
Hi,
When trying to compile a file compiled with optimized flag, I got the following
error :
gcc -DHAVE_CONFIG_H -I.-O3 -DDBUG_OFF -Wimplicit -Wreturn-type -Wswitch
-Wtrigraphs -Wcomment -W -Wchar-subscripts -Wformat -Wparentheses -Wsign-compare
-Wwrite-strings -Wunused -mtune=athlon-mp
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 21:52
---
How did you compile the one which you are profiling?
--
What|Removed |Added
--- Additional Comments From joc at presence-pc dot com 2004-10-25 21:53 ---
Created an attachment (id=7409)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7409action=view)
c/h files and gcda file to reproduce -fprofile-use bug
--
--- Additional Comments From joc at presence-pc dot com 2004-10-25 21:56 ---
The file has been compiled with
gcc -DHAVE_CONFIG_H -I. -O3 -DDBUG_OFF -Wimplicit -Wreturn-type -Wswitch
-Wtrigraphs -Wcomment -W -Wchar-subscripts -Wformat -Wparentheses -Wsign-compare
-Wwrite-strings
--- Additional Comments From joc at presence-pc dot com 2004-10-25 22:03 ---
Note also that occurs when trying to compile MySQL with -fprofile-use flag, and
several other files are affected by the problem (but now all the files).
For example, an other error during compilation :
[EMAIL
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-25 22:23
---
Subject: Bug 16667
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-25 22:23:08
Modified files:
gcc: ChangeLog c-parse.in
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-25 23:22
---
The code has been removed for 4.0.
--
What|Removed |Added
Status|NEW
--
Bug 17278 depends on bug 17707, which changed state.
Bug 17707 Summary: [4.0 Regression] O(N^2) in cgraph_reset_static_var_maps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17707
What|Old Value |New Value
--
Bug 15678 depends on bug 17707, which changed state.
Bug 17707 Summary: [4.0 Regression] O(N^2) in cgraph_reset_static_var_maps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17707
What|Old Value |New Value
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 23:43
---
Subject: Re: ICE cause by reload
Try again with what patch? I have all patches applied and I
consistently get the output I emailed earlier with a native Mac OS X
compiler.
David
--
--- Additional Comments From wilson at tuliptree dot org 2004-10-25 23:54 ---
Subject: Re: bad unwind info due to multiple returns
(missing epilogue)
On Fri, 2004-10-22 at 03:57, davidm at hpl dot hp dot com wrote:
It looks to
me as if expect sometimes fails to notice the
--- Additional Comments From fjahanian at apple dot com 2004-10-25 23:58 ---
I tried the last patch and for the following statement built with -O2 -mcpu=G5
(aaple's mixed mode)
I get the following instruction sequence. It looks OK to me. But David's case might be
different
than what I
--- Additional Comments From wilson at tuliptree dot org 2004-10-26 00:06 ---
Subject: Re: bad unwind info due to multiple returns
(missing epilogue)
On Thu, 2004-10-21 at 11:03, davidm at hpl dot hp dot com wrote:
OK, I tried this patch on the CVS gcc-3_4_branch (the 4.0
1 - 100 of 112 matches
Mail list logo
