Ira Rosen wrote:
Here is the documentation for the data dependence analysis.
I can add a description of data-refs creation/analysis if it is useful.
That's a good idea, thanks.
Sebastian
It is probably too late to get this resolved before gcc trunk branches
but we have an outstanding patch for building gcj on Darwin/386 awaiting
on Sandro Tolaini's paperwork being processed. He told me that he scanned
the form back to [EMAIL PROTECTED] but still hasn't heard back yet.
The
The snapshot gcc-4.2.0-20060902 stops compiling jikes-1.22.tar.bz2.
The snapshot gcc-4.2.0-20060906 stops compiling jikes-1.22.tar.bz2 too.
It doesn't ocurr with gcc-3.3.6, gcc-4.1.2-20060901 and
gcc-4.0.4-20060831, they are OK.
$ gcc -v
Using built-in specs.
Target: i486-slackware-linux
On Fri, 2006-09-08 at 15:40 +0200, Anny Blackyew wrote:
The snapshot gcc-4.2.0-20060902 stops compiling jikes-1.22.tar.bz2.
The snapshot gcc-4.2.0-20060906 stops compiling jikes-1.22.tar.bz2 too.
I think I just fixed this last night. Can you try again?
Thanks,
Andrew Pinski
Sorry for my own slow response -- I've been doing more digging through
code, and didn't want to respond without a reasonable understanding...
Richard Kenner wrote:
However, in the case where we're passing the address of a temp slot to a
function, it doesn't make sense to me that this is the
I am confused with gcc configuration, and I cannot determine if I have a bug
or if I am misconfiguring the compiler. Here is the situation:
gcc sources: 4.2 snapshot of 20060905
If compiler is configured with:
--target=powerpc-*-linux-gnualtivec
then I have the following libraries and
On Fri, 8 Sep 2006, Edmar Wienskoski wrote:
So the key questions are:
1 - What should I expect in regards to __lttf2 (and similar symbols).
(like, when they should be defined, referenced, and when not)
They should not be defined or used at all. IBM long double should use
__gcc_*, and IEEE
Soft-float implementation of long double support is in development
but not complete. Long double requires double precision registers, so it
only will work with e500 double. It also requires floating point
multiply-subtract (fmsub), which e500 double does not appear to
implement. This is
Hello ALL!
I'm working in a project to automatic create parallel code for anthill
program model
http://homepages.dcc.ufmg.br/~dorgival/artigos/sbac2005.pdf
the goal is to translate a C uniq source into various C source files
that represent the parallelized code. I've been looking for a compiler
GCC accepts the -Tscript command line option and
passes this to the linker as -Tscript, as well as
suppressing any passing the linker the default linker script.
Unfortunately, -T script gets passed to the assembler.
The option doesn't appear in the GCC docs or in gcc -help.
I also can't locate
On Fri, 8 Sep 2006, David Edelsohn wrote:
Soft-float implementation of long double support is in development
but not complete. Long double requires double precision registers, so it
only will work with e500 double. It also requires floating point
multiply-subtract (fmsub), which e500
Ok. I am starting to see the whole picture now.
So the whole thing appears to work with --disable-shared, just because
the way the linker
loads symbols in presence of libgcc_s.so versus libgcc.a.
Follow up question:
The e500 abi actualy defines long double to be 128bits floats.
On rs6000.c,
On Fri, 8 Sep 2006, Edmar Wienskoski wrote:
Ok. I am starting to see the whole picture now.
So the whole thing appears to work with --disable-shared, just because the way
the linker
loads symbols in presence of libgcc_s.so versus libgcc.a.
Follow up question:
The e500 abi actualy defines
Michael Eager [EMAIL PROTECTED] writes:
GCC accepts the -Tscript command line option and
passes this to the linker as -Tscript, as well as
suppressing any passing the linker the default linker script.
Unfortunately, -T script gets passed to the assembler.
The option doesn't appear in the
Snapshot gcc-4.1-20060908 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060908/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hallo,
I sent to binutils the patch for the new x86_64-pc-mingw64 as cross
target.I was asked to post about this patch also to you. May this new
target is of some interest to you and you can help me to verify this
patch, because at the binutils there are not much windows users :|
Best
Hi...
[EMAIL PROTECTED] wrote on 08.09.2006 10:33:04:
Hallo,
I sent to binutils the patch for the new x86_64-pc-mingw64 as cross
target.I was asked to post about this patch also to you. May this new
target is of some interest to you and you can help me to verify this
patch, because at the
Andrew Pinski wrote:
On Wed, 2006-09-06 at 15:00 -0700, Michael Eager wrote:
GCC passes a linker script to the linker for some
targets (e.g., powerpc-eabi with -mads). If you specify a
linker script using -Wl,-T,script.ld, you get both
passed to the linker and there may be conflicts.
Is there
Kenny Simpson wrote:
What is the status of the 4.1 branch? Any word on 4.1.2?
My current plan is to do a 4.1.2 along with 4.2.0. My concern has been
that with 4.2.0 moving slowly, trying to organize another release might
just distract the developer community.
However, I realize that's a
I don't know if this is related to Eric's checkins tonight
but I can no longer build libgfortran on Darwin PPC. The build fails
at...
/bin/sh ./libtool --mode=compile /sw/src/fink.build/gcc4-4.1.999-20060908/darwin
_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir
To correct the typo in the last message, I am now rebuilding
without the reduced TImode patch to confirm it is not at fault.
As I said, since the build craps out in the 32-bit sections, I
doubt it is the source of the libgfortran build failure.
Jack
I should add that the last good build I have is from last
night at revision r116774.
Jack
Okay. The problem with the libgfortran build failing is
unrelated to the remaining sections of the TImode patch.
I see the same failure with an unpatched version of current
gcc trunk. Time to file a PR.
Jack
ps I am currently building (for the last couple of days)
with
I notice a warning in the Darwin PPC build of gcc trunk against
libiconv 1.10. There appears to be a duplicate symbol for _locale_charset
in both ./../intl/libintl.a(localcharset.o) and
/sw/lib/libiconv.dylib(localcharset.o).
Shouldn't the presence of duplicate symbols in the linkage of
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00667.html
-- Pinski
--- Comment #15 from jason at gcc dot gnu dot org 2006-09-08 07:14 ---
The bug is in expand_builtin_setjmp_receiver:
/* Now put in the code to restore the frame pointer, and argument
pointer, if needed. */
[...]
emit_move_insn (virtual_stack_vars_rtx, hard_frame_pointer_rtx);
--- Comment #16 from jason at gcc dot gnu dot org 2006-09-08 07:37 ---
The line in question dates back to when __builtin_setjmp was first added in
1996.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28493
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-09-08 07:40
---
Only fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
g++ version: 4.1.1
target platform: linux kernel 2.6.13-15
with option pedantic the following line does not compile outside main:
int array3[(const unsigned short) (20.5 * 3)];
error message from compiler is:
error: array bound is not an integer constant
to me this is wrong because the
If reload decides to create an automodification reload (POST_MODIFY, etc.),
inc_for_reload will not deal correctly with any reloads for the base and
index registers. This problem is related to:
2006-03-29 Paul Brook [EMAIL PROTECTED]
* reload1.c (choose_reload_regs): Check for all
--- Comment #1 from rsandifo at gcc dot gnu dot org 2006-09-08 08:37
---
Created an attachment (id=12211)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12211action=view)
Testcase
This brute-force test fails with -O2 -mfloat-abi=softfp.
--
rsandifo at gcc dot gnu dot org
Well, i want to create a new pass for gcc. i do all passes an introduce my pass
in passes.c
p = pass_tree_loop.sub;
NEXT_PASS (pass_tree_loop_init);
NEXT_PASS (pass_tree_blocking);
I do the tree-blocking.c
static void
main_tree_blocking (void)
{ struct loops loops
--- Comment #6 from pluto at agmk dot net 2006-09-08 12:48 ---
any idea how to fix this? i can test proposals.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
--- Comment #13 from tausq at debian dot org 2006-09-08 15:04 ---
Works for me on the original test case (ACE package) and on the reduced test
case in #3. Tested on hppa-linux native.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-08 15:51 ---
This is the wrong place to report a problem about your own pass if you have not
done any debugging yourself.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-09-08 15:51
---
Then fixed on the mainline, marking as such and changing back to new for the
other branches.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from daknhro at hotmail dot com 2006-09-08 16:28 ---
can i have a debugging?(In reply to comment #1)
This is the wrong place to report a problem about your own pass if you have
not
done any debugging yourself.
how i do a debugginh
--
--- Comment #4 from mkoeppe at gmx dot de 2006-09-08 16:41 ---
(In reply to comment #3)
And the other question is how did you get passed PR 15212?
I now tested make bootstrap on native i586-pc-interix3.
This bug (PR 28968) occurs there, too, when building the stage1. I think it is
--- Comment #15 from jason at gcc dot gnu dot org 2006-09-08 16:52 ---
Subject: Bug 26957
Author: jason
Date: Fri Sep 8 16:52:40 2006
New Revision: 116781
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116781
Log:
PR c++/26957
* method.c (use_thunk): Clear
--- Comment #16 from jason at gcc dot gnu dot org 2006-09-08 16:54 ---
Subject: Bug 26957
Author: jason
Date: Fri Sep 8 16:53:55 2006
New Revision: 116782
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116782
Log:
PR c++/26957
* method.c (use_thunk): Clear
--- Comment #17 from jason at gcc dot gnu dot org 2006-09-08 16:54 ---
Applied to 4.0 and 4.1 as well.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-09-08 17:26 ---
I suppose this accepts-invalid problem is related:
struct I
{
int i;
} i = { 0 };
int
f (int i, int j = i.i)
{
return i + j;
}
--
amylaar at gcc dot gnu dot org changed:
What|Removed
The following code violates clause 4 of 3.4.5
class C {};
void
f ()
{
C o;
class C {};
o.C::~C ();
}
--
Summary: class member access using a qualified-id fails to check
for match of classes
Product: gcc
Version: 4.2.0
g++ doesn't diagnose the overflow (clause 5 paragraph 5) in the following
constant expression:
#include limits.h
long l = LONG_MAX+1;
--
Summary: Failure to diagnose overflow in constant expression
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
--- Comment #2 from jsm28 at gcc dot gnu dot org 2006-09-08 18:51 ---
Working on a fix.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
The following code is accepted, contrary to clause 5.2.4:
typedef int C;
typedef double D;
void
f ()
{
C o;
o.D::~C ();
}
--
Summary: g++ does not check first type name in pseudo-destructor-
name
Product: gcc
Version: 4.2.0
--- Comment #7 from janis at gcc dot gnu dot org 2006-09-08 19:11 ---
A regression hunt on powerpc-linux, using the reduced testcase from comment #4
with no options, identified this patch for which that test starts compiling
cleanly:
http://gcc.gnu.org/viewcvs?view=revrev=116450
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-08 19:14 ---
So the ICE in tree_low_cst has been fixed in the next releases of GCC 4.1.x and
4.0.x, that is good news but we still have the ICE in
loc_descriptor_from_tree_1 now.
--
pinskia at gcc dot gnu dot org changed:
void
f()
{
bool i = 0;
i++ = 6;
}
--
Summary: post-increment of bool variable accepted as lvalue
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-08 19:33 ---
Confirmed, though in 3.0.4 to 3.4.0 we gave a weird error for this code:
t.cc: In function `void f()':
t.cc:5: error: assignment of read-only location
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #4 from tromey at gcc dot gnu dot org 2006-09-08 19:34 ---
Also see PR 28892
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
The following is accepted despite the requirements of 5.3.4 paragraph 15
of a user-defined constructor:
class B
{
public:
B ();
};
class C : B {};
const C *
f ()
{
const C *p = new const C[1];
return p;
}
--
Summary: const new: Inherited constructor accepted in lieu of
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-09-08 20:30 ---
g++ also fails to check the accessibility of the destructor:
class C
{
private:
void operator delete (void *p) throw ();
};
void
f ()
{
C *p = new C;
}
class D
{
private:
~D ();
};
void
g ()
{
D *p =
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-08 20:32 ---
See http://gcc.gnu.org/wiki/DebuggingGCC
Please stop asking questions here and try to figure out something for yourself,
from the wiki, from the documentation, by experimenting, or when all else
fails, on the
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-09-08 20:45
---
The approach looks OK but the fix should use invalidate_any_buried_refs.
Post the revised version to gcc-patches if it works (read the guidelines on
http://gcc.gnu.org/contribute.html) and I'll formally approve
() {};
};
void (*T::handler)() = func;
int main()
{
T t;
return 0;
}
gcc version 4.2.0 20060908 (experimental) emits:
08048416 t global constructors keyed to _ZN1T7handlerE
08049664 B T::handler
4.1.1 and 3.4.6 emit:
0804962c D T::handler
--
Summary: Static constructor emitted
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-08 21:00 ---
Hmm, this worked in 4.2.0 20060821
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28991
--- Comment #2 from adam at os dot inf dot tu-dresden dot de 2006-09-08
21:07 ---
gcc version 4.2.0 20060903 (experimental) also gives:
080483f2 t global constructors keyed to _ZN1T7handlerE
08049650 B T::handler
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28991
--- Comment #17 from jason at gcc dot gnu dot org 2006-09-08 22:37 ---
Hmm, it seems things are a bit more complicated than I thought. Without my
change to expand_builtin_setjmp_receiver, Janis's test passes at -O0 and fails
at -O1; the adjustment of r31 at -O0 is actually correct.
$ cat bad_if.cc
#include stdio.h
int main() {
if (0); { /* Semicolon accidentally added between condition and brace. */
printf(Not intended to be printed\n);
}
return 0;
}
$ .../i686-unknown-linux-gnu-g++ --version
i686-unknown-linux-gnu-g++ (GCC) 4.1.0
$
--- Comment #18 from jason at gcc dot gnu dot org 2006-09-08 22:52 ---
Janis: the most part of the -fstack-protector patch that seems plausible for
causing this problem was the change to expand_function_end to call
sjlj_emit_function_exit_after at a different point. But that section of
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-09-08 22:56
---
Subject: Bug 28858
Author: reichelt
Date: Fri Sep 8 22:56:44 2006
New Revision: 116788
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116788
Log:
PR c++/28858
* parser.c
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-09-08 23:28
---
Fixed on mainline.
Won't backport to 4.1 and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-08 23:28 ---
This is a dup of bug 5520 which was fixed in 4.2.0.
*** This bug has been marked as a duplicate of 5520 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-08 23:28
---
*** Bug 28992 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
gfortran -v -save-temps -c Diags.f95
Using built-in specs.
Target: powerpc-apple-darwin8.7.0
Configured with: ../gcc-4.0.3/configure --prefix=/usr/local
--enable-languages=c,c++,f95,java --with-gmp=/usr/local/lib
--with-mpfr=/usr/local/lib
Thread model: posix
gcc version 4.0.3
--- Comment #10 from reichelt at gcc dot gnu dot org 2006-09-08 23:33
---
The fix is incomplete. The following testcase still fails:
==
struct A
{
static void foo();
};
void bar()
{
A().foo;
}
==
--
reichelt at gcc dot gnu dot
--- Comment #3 from jsm28 at gcc dot gnu dot org 2006-09-08 23:41 ---
Subject: Bug 28504
Author: jsm28
Date: Fri Sep 8 23:41:21 2006
New Revision: 116789
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116789
Log:
PR c/28504
* c-tree.h (struct c_arg_info): Add
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-08 23:45
---
(In reply to comment #10)
The fix is incomplete. The following testcase still fails:
Can you file a new bug report since the orginal testcase here was fixed, even
though your testcase is very closely related it
--- Comment #1 from jsm28 at gcc dot gnu dot org 2006-09-09 00:03 ---
This was fixed by
2005-12-13 Mark Mitchell [EMAIL PROTECTED]
Jakub Jelinek [EMAIL PROTECTED]
* g++.dg/compat/struct-layout-1.exp: Do not link with libiberty.
*
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-09 00:16 ---
Related to PR 20039.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
When configuring and bootstrapping with
#!/bin/tcsh
/bin/rm -rf *; env CC='gcc -mcpu=970 -m64' ../configure
--prefix=/pkgs/gcc-test-64 --enable-languages=c --disable-checking; make -j 16
bootstrap BOOT_CFLAGS='-O2 -g -mcpu=970 -m64' build.log
bootstrap fails with
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-09-09 01:02 ---
Patch doesn't apply cleanly to 4.1 branch.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from vnasardinov at gmail dot com 2006-09-09 01:05 ---
PR 28892 reminded me that I had forgotten to mention one thing. The
attached program (attachment 12208) runs fine under gij.
To be more precise, it does more or less the same thing it does under
Sun's JDK. Under
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-09-09 01:17
---
Please upgarde to at least 4.1 version of gfortran. This compiles fine for me
with latest gfortran 4.2. 100's of bugs have been fixed since 4.0 series.
--
jvdelisle at gcc dot gnu dot org changed:
--- Comment #2 from danp57 at optonline dot net 2006-09-09 01:19 ---
There is a syntax error in the code: the function tqli() declaration is missing
the terminal ')'
Dan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28993
--- Comment #3 from danp57 at optonline dot net 2006-09-09 01:20 ---
I will upgrade...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28993
Bradley,
I would think it would only make sense to try to build 64-bit only using
the --enable-multilib=no and then some incantation of the configure for
a ppc64 target of darwin (which doesn't exist). This really doesn't make
sense to do since, unlike x86_64, Darwin's default libs on both ppc
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-09-09 02:26 ---
Subject: Re: New: Problem creating a new pass
Then i do make and make install without problems,but when i try to compiler a
c
code..
I'd highly suggest you email gcc@, use the current development
version,
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-09-09 03:17
---
The case in Comment #8 is now broken on 4.1/4.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-09 04:10 ---
Confirmed, a regression from 3.3.3 which gave:
t.cc: In function `void f()':
t.cc:10: error: lookup of `C' in the scope of `class C' (`class C') does not
match lookup in the current scope (`class f()::C')
To me
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-09 04:14 ---
Confirmed, not a regression and only happens with the C++ front-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Somewhere between r116775 and r116795, the build of libgfortran has become
broken on Darwin PPC. The build now fails with...
/bin/sh ./libtool --mode=compile
/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./gcc/
-B/sw/lib
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-09 04:16 ---
Confirmed, another regression from 3.3.3:
t.cc: In function `void f()':
t.cc:9: qualified type `double' does not match destructor name `~C'
t.cc:9: type of `o' does not match destructor type `double' (type was `C'
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-09 04:22 ---
This is obviously caused by:
* config/darwin.c (machopic_select_section): Support literal16.
(machopic_select_rtx_section): Ditto.
Is a new cctools needed now?
--
pinskia at gcc dot gnu dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-09 04:28 ---
(In reply to comment #1)
Hmm, this worked in 4.2.0 20060821
But it was broke in 4.2.0 20060831.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.0.4 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28588
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-09 05:03 ---
This looks like it was caused by PR 28588.
In store_init_value, we have a BASELINK.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-09 05:23 ---
If we have another function in the overloaded set for the BASELINK:
class T
{
static void (* handler)();
static void func();
static void func(int);
};
void (*T::handler)() = func;
We don't get the
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-09 05:39 ---
I cannot figure out which function should be stripping the BASELINK expression.
OVERLOADS work because perform_implicit_conversion strips it after going
through the overloaded set to figure out which function is
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-09 05:42 ---
This is also related to PR 20039.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-09 05:48 ---
For x86, 3.4.0 produces:
movl4(%esp), %edx
movsbl a+1(%edx),%eax
movsbl b+1(%edx),%edx
addl%edx, %eax
ret
While 4.0.0 produced:
movl4(%esp), %edx
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-09 05:50 ---
Confirmed, the size of the struct is too small to cause it to be returned by
reference.
See the patch at
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00051.html
for a fix.
--
pinskia at gcc dot gnu dot org
93 matches
Mail list logo
