--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-06 06:14 ---
Yes this is just a stack overflow, I don't know if there is anything that cane
be done here since this is one of the reasons why -ftemplate-depth was added.
I don't know what the standard says about how this limit
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 06:17 ---
embedded ia64, that is a new one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27051
hi
I've got a problem when I try to make a cross compilation of the gSOAP toolkit
from a i686-pc-cygwin to i586-hadhat-linux.
I downloaded the gSOAP toolkit from
here:http://sourceforge.net/project/showfiles.php?group_id=52781package_id=68161release_id=394790
it's the version : gSOAP 2.7.6e
static const double coeff[] = { +854513.0l /138 };
compiles as C almost everywhere, except ppc* with -mlong-double-128
-mabi=ibmlongdouble.
const_binop refuses to compute this:
/* Don't constant fold this floating point operation if the
result may dependent upon the run-time
--- Comment #3 from bonzini at gnu dot org 2006-04-06 10:56 ---
For 4.1 I'd surely go with Ulrich's patch. And for 4.2 I think that it starts
being too expensive to have two vsplat and two adds.
vspltisw 0,15
vspltisw 1,1
vadduwm 0,0,0
vadduwm 0,0,1
--- Comment #36 from guillaume dot melquiond at ens-lyon dot fr 2006-04-06
10:59 ---
The generated code is getting both better and worse. I just tested with GCC
4.1, and there is now a byte-by-byte (!) copy instead of memcpy. So not only
does GCC use superfluous copies, but it
I tried the following testcase with various GCC versions available as Debian
packages. With 3.3.5, the copy from *a to the stack frame of g is done
word-by-word with rep movsl. With 3.4.4, it is done by memcpy. Both previous
methods are fine. With 3.4.6, the copy is done byte-by-byte without
On the attached testcase with today's gcc-4_1-branch
-m32 -g -O2 I get ICE during copy propagation. Unfortunately, even doing minor
changes in different routines makes the problem go away.
What I see in the dumps is:
1) at *t26.ssa, in draw_digit, there are two SSA_NAMEs with version 2:
...
--- Comment #1 from jakub at gcc dot gnu dot org 2006-04-06 11:51 ---
Created an attachment (id=11216)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11216action=view)
188125.ii.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27056
--- Comment #1 from gdr at integrable-solutions dot net 2006-04-06 12:03
---
Subject: Re: New: Structures are copied byte by byte into function arguments
guillaume dot melquiond at ens-lyon dot fr [EMAIL PROTECTED] writes:
[...]
| With 3.4.6, the copy is done byte-by-byte without
--- Comment #4 from gcc at magfr dot user dot lysator dot liu dot se
2006-04-06 12:08 ---
The standard says the limit have to be more than 17, the g++ default is 500 in
order, I assume, to be nice to users.
The reason I reported the bug was that the compiler terminated with an
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
--- Comment #5 from gdr at integrable-solutions dot net 2006-04-06 12:23
---
Subject: Re: When using excessive -ftemplate-depth g++ overflows the stack
gcc at magfr dot user dot lysator dot liu dot se [EMAIL PROTECTED]
writes:
| The standard says the limit have to be more than 17,
// { dg-do compile }
// { dg-options -g -feliminate-dwarf2-dups }
namespace N
{
}
struct A
{
void foo ();
};
void A::foo ()
{
using namespace N;
}
ICEs with gcc-4_{0,1}-branch and HEAD in build_abbrev_table, as
DW_TAG_namespace
die that is being referenced doesn't have die_symbol.
--
--- Comment #2 from pluto at agmk dot net 2006-04-06 12:49 ---
for -march=i{345}86 I get:
f:
pushl %ebp
movl%esp, %ebp
subl$4008, %esp
movl%esp, %eax
pushl %edx
pushl $4000
pushl 8(%ebp)
pushl %eax
--- Comment #6 from gcc at magfr dot user dot lysator dot liu dot se
2006-04-06 12:52 ---
(In reply to comment #5)
gcc at magfr dot user dot lysator dot liu dot se [EMAIL PROTECTED]
writes:
| The standard says the limit have to be more than 17,
No, the standard did not say
--- Comment #3 from guillaume dot melquiond at ens-lyon dot fr 2006-04-06
13:05 ---
for -march=i{345}86 I get
for -march=i686,pentium2,... I get
Thanks to your tests, I noticed that the change of behavior between GCC 3.4
versions was actually caused by the addition of
gcc at magfr dot user dot lysator dot liu dot se [EMAIL PROTECTED] writes:
| ( As an aside that suggests that you could have a strictly conforming
| implementation where the max limit is 0, but that discussion is more fitting
on
| comp.std.c++)
That is technically correct; but it is beside the
--- Comment #7 from gdr at integrable-solutions dot net 2006-04-06 13:09
---
Subject: Re: When using excessive -ftemplate-depth g++ overflows the stack
gcc at magfr dot user dot lysator dot liu dot se [EMAIL PROTECTED]
writes:
| ( As an aside that suggests that you could have a
--
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
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mmitchel at gcc dot gnu dot
|dot org
--- Comment #30 from jakub at gcc dot gnu dot org 2006-04-06 13:30 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
int
foo (void)
{
if (0)
{
static union
{
long i;
char c[8];
} u;
u.i = 0x01020304;
return u.c[0] == 0x01 u.c[1] == 0x02;
}
return 0;
}
ICEs at -g -O0 in dwarf2out_finish, because the UNION_TYPE has TYPE_CONTEXT
set, but not to some
%T originally allowed to move between registers and memory, using an anadorned
operand for the piece that comes first in memory, and using %T for the second
part.
This does not work with the SH4 floating point registers for little endian
code.
The #ifdef __LITTLE_ENDIAN__ sequences in
--- Comment #2 from bonzini at gnu dot org 2006-04-06 13:53 ---
The ICE was probably exposed by my changes for PR26830, but if I understand
right it was causing a wrong code before that?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2006-04-06 13:59 ---
I get the same ICE also with
gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)
which is much older than your PR26830 fix.
So those 2 seem to be unrelated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27056
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-04-06 14:00 ---
I intend to introduce a new modifier for the first part of a 64 bit value -
I suppose %t is best suited for that - and change %T for little endian to be
equivalent to %S.
--
amylaar at gcc dot gnu dot org
--- Comment #4 from uweigand at gcc dot gnu dot org 2006-04-06 14:03
---
(In reply to comment #3)
Ulrich, can you prepare a patch or should I do so?
It would be great if you could do that, I don't yet
have a proper setup for ppc testing ...
--
The new sped-optimized division library functions are larger than the functions
that were originally used; unsigned and signed division are implemented in a
modulte which has an object text size of 1060 bytes.
This could cause problems with specialized embedded applications that are
supposed to
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-04-06 14:14 ---
This can be fixed by providing an additional library, which provides
udivsi3_i4i and sdivsi3_i4i implementations that are comparable in speed and
size to what we had before, and which is linked in in preference to
--- Comment #5 from bonzini at gnu dot org 2006-04-06 14:47 ---
Created an attachment (id=11217)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11217action=view)
patch to fix the bug
Patch untested but quite trivial.
--
bonzini at gnu dot org changed:
What
When the folliwng program is compiled:
template typename T void f(T x) {}
int main()
{
class A{} a;
f(a);
}
g++ syas:
test.cc: In function 'int main()':
test.cc:5: error: no matching function for call to 'f(main()::A)'
but if you move the class definition outside the main
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-04-06 15:26 ---
This does not actually affect lib1funcs.asm, since we don't have access to
gcc's output modifiers there anyway.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-04-06 15:33 ---
Created an attachment (id=11218)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11218action=view)
untested patch
If this is not blocking the fix for some more serious bug, maybe we should wait
with this till
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-06 16:13
---
*** This bug has been marked as a duplicate of 26757 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-04-06 16:13
---
*** Bug 27056 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 16:13 ---
This is a dup of bug 26374.
*** This bug has been marked as a duplicate of 26374 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-06 16:13 ---
*** Bug 27054 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
On Thu, 2006-04-06 at 11:49 +, jakub at gcc dot gnu dot org wrote:
On the attached testcase with today's gcc-4_1-branch
-m32 -g -O2 I get ICE during copy propagation. Unfortunately, even doing
minor
changes in different routines makes the problem go away.
What I see in the dumps is:
1)
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-04-06 16:15 ---
Subject: Re: New: ICE in loop_depth_of_name
On Thu, 2006-04-06 at 11:49 +, jakub at gcc dot gnu dot org wrote:
On the attached testcase with today's gcc-4_1-branch
-m32 -g -O2 I get ICE during copy
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 16:21 ---
*** This bug has been marked as a duplicate of 26881 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-06 16:21 ---
*** Bug 27058 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 16:24 ---
The code is invalid as you cannot use a template with a local class as it has
local linkage.
I don't know if the error message could be improved or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27061
If you download only the gcc-core-4.2 snapshot, for example
ftp://ftp.uvsq.fr/pub/gcc/snapshots/4.2-20060401/gcc-core-4.2-20060401.tar.bz2
and do a ../configure --enable-languages=c make
make will stop complaining about some objC file that is not in the package:
make[2]: *** No rule to make
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 16:45 ---
3.2.1 is over 3 years old. Can you try a newer compiler like 4.0.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27053
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 16:46 ---
This is just a packing issue. There was a thread on gcc@ about this issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Most of options in gcc/fortran/lang.opt, like -fmax-stack-var-size=N, aren't
documented in the gcc manual.
--
Summary: Fortran compiler options aren't documented
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from kargl at gcc dot gnu dot org 2006-04-06 17:53 ---
All of these options are documented in the gfortran manual.
Is there really a needed for duplicating these options in
the gcc manual?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27064
--- Comment #2 from hjl at lucon dot org 2006-04-06 18:24 ---
I think the gcc manual should at least have a line like,
-fmax-stack-var-size=N, see gfortran manual since gcc can be used
to compile Fortran code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27064
a code below:
struct foo {
void (*pf)(struct foo (*ptr)[2]); /* error */
};
causes to report the following error:
ts.c:4: error: array type has incomplete element type
Isn't the compiler too restrictive ?
Even a typedef is rejected by compiler:
struct foo;
typedef struct
--- Comment #3 from kargl at gcc dot gnu dot org 2006-04-06 18:32 ---
None of g77 specific options that I checked are documented
in pre 4.0 gcc. As far as front-ends are concerned, the gcc
manual documents the C family of languages options. I don't
see any ada, java, or other
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 18:42 ---
This is invalid code, yes it might had been accepted before 4.1.0 but it was
still invalid code. The array to pointer decay happens after the type is
completed for functions so the element of the array type has to
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-06 18:43 ---
This is the way it has been for years now. If you don't like it, propose a
patch to combine all four manuals (GCC, Ada, Fortran, and Java) into one big
one.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from rdabrowa at poczta dot onet dot pl 2006-04-06 19:09
---
(In reply to comment #1)
This is invalid code, yes it might had been accepted before 4.1.0 but it was
still invalid code. The array to pointer decay happens after the type is
completed for functions so the
Java Sockets do not know on creation if they will be used for IPv6 or IPv4, so
the gnu::java::net::PlainSocketImpl::create method should use PF_INET6 instead
of AF_INET. The other methods - bind and connect - must then translate IPv4
addresses to IPv4-in-IPv6. Behavior with HAVE_INET6 not defined
--- Comment #1 from cjw at daneel dot dyndns dot org 2006-04-06 19:43
---
Created an attachment (id=11219)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11219action=view)
Example patch to fix IPv6 support
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27066
--- Comment #2 from mckinlay at redhat dot com 2006-04-06 20:08 ---
I'm not sure I follow this. create() does not get called until the socket is
bound. Don't we know at that point whether we're binding to an IPV4 or IPV6
address?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27066
--- Comment #12 from hubicka at gcc dot gnu dot org 2006-04-06 20:33
---
Subject: Bug 20815
Author: hubicka
Date: Thu Apr 6 20:33:21 2006
New Revision: 112738
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112738
Log:
PR profile/20815
PR profile/26399
*
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-04-06 20:33 ---
Subject: Bug 26399
Author: hubicka
Date: Thu Apr 6 20:33:21 2006
New Revision: 112738
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112738
Log:
PR profile/20815
PR profile/26399
*
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-06 20:58 ---
I am working on this again :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from amacleod at redhat dot com 2006-04-06 21:05 ---
using the program from comment #5, I get IL for load_background_image that
looks like:
void load_background_image() ()
{
int D.1767;
int D.1766;
struct Config * cfg.2;
int D.1764;
int D.1763;
struct Config
When the sample code snippet (below) is compiled, errors (below) occur. This
issue breaks the compilation of wxWidgets' Media Library. The same problem
occurs with the latest snapshot (20060331, used in the example below) of GCC
4.1.1, on both CygWin and MinGW.
The sample code (virt-test.ii):
--- Comment #3 from cjw at daneel dot dyndns dot org 2006-04-06 22:38
---
AFAICT create() is called in Socket's getImpl() method, which in turn is called
from e.g. setTcpNoDelay() and calling that after a plain new Socket() means
no bind was done yet... Anyway, the address is not
gcc -c -I/home/shackle/rcslib/src/ada -g nml_test_server_ada.adb
+===GNAT BUG DETECTED==+
| 4.1.0 20060304 (Red Hat 4.1.0-3) (x86_64-redhat-linux-gnu) Storage_Error
stack overflow (or erroneous memory access)|
| Error detected at a-tags.adb:448:7
gfortran crashes when I use -ffast-math in this subroutine:
C ==
SUBROUTINE GRADEN(RHOE,V,GRAD,VTMP)
C ==--==
C == SMOOTHING OF THE DENSITY AND
--- Comment #1 from kargl at gcc dot gnu dot org 2006-04-06 23:47 ---
Don't use --fast-math.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
--- Comment #2 from nuno dot bandeira at ist dot utl dot pt 2006-04-06
23:56 ---
Subject: Re: -ffast-math crash
kargl at gcc dot gnu dot org wrote:
--- Comment #1 from kargl at gcc dot gnu dot org 2006-04-06 23:47 ---
Don't use --fast-math.
Is there a valid reason for it
nuno dot bandeira at ist dot utl dot pt wrote:
--- Comment #2 from nuno dot bandeira at ist dot utl dot pt 2006-04-06
23:56 ---
Subject: Re: -ffast-math crash
kargl at gcc dot gnu dot org wrote:
--- Comment #1 from kargl at gcc dot gnu dot org 2006-04-06 23:47 ---
Don't
--- Comment #3 from jvdelisle at verizon dot net 2006-04-07 00:06 ---
Subject: Re: -ffast-math crash
nuno dot bandeira at ist dot utl dot pt wrote:
--- Comment #2 from nuno dot bandeira at ist dot utl dot pt 2006-04-06
23:56 ---
Subject: Re: -ffast-math crash
kargl at
--- Comment #4 from kargl at gcc dot gnu dot org 2006-04-07 00:07 ---
(In reply to comment #2)
kargl at gcc dot gnu dot org wrote:
Don't use --fast-math.
Is there a valid reason for it or is the implementation of the
-ffast-math still uncertain ?
Does your code work correctly
--- Comment #5 from nuno dot bandeira at ist dot utl dot pt 2006-04-07
00:10 ---
Subject: Re: -ffast-math crash
jvdelisle at verizon dot net wrote:
-ffast-math is uncertain, not related to gfortran.
I notice speedups of up to 50% for my binary at the cost of some
numerical
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-07 00:18 ---
What do you mean by crash? Aka What is the error you get?
Also this source is no where near compilable by itself because of the includes.
Also what is the exact version of GCC you are using? (use gcc -v to get
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-07 00:20 ---
What are the full options you are passing to gcc anyways since I see you have
some openmp markers here too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
--- Comment #8 from nuno dot bandeira at ist dot utl dot pt 2006-04-07
00:32 ---
Subject: Re: -ffast-math crash
This is what I get from the compiler:
$ gfortran -I../SOURCE -c -fdefault-real-8 -O3 -fforce-addr
-march=pentium4 -fcray-pointer -ffast-math ./graden.f -o ./graden.o
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-07 00:34 ---
Still need the version number?
gfortran -v will give it to you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-04-07 00:37
---
I bet this is a dup of bug 26717 which was fixed a week or so ago.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
--- Comment #11 from nuno dot bandeira at ist dot utl dot pt 2006-04-07
00:38 ---
Subject: Re: -ffast-math crash
kargl at gcc dot gnu dot org wrote:
Does your code work correctly if you omit -ffast-math?
Yes it does albeit slower. The code also compiles well if I omit the
--- Comment #12 from nuno dot bandeira at ist dot utl dot pt 2006-04-07
00:42 ---
Subject: Re: -ffast-math crash
pinskia at gcc dot gnu dot org wrote:
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-07 00:34
---
Still need the version number?
gfortran -v
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-04-07 00:53
---
Still not enough to compile it, we need you to attach (not copy and paste) the
following files:
system.h
cnst.inc
fft.inc
cppt.inc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
--- Comment #23 from geoffk at gcc dot gnu dot org 2006-04-07 00:55 ---
(In reply to comment #22)
The PCH problem with get_file_function_name is independent of the question of
giving anonymous namespace members internal linkage. We still need to give
them distinct names; we are
gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu3)
Different partial template specialization result with different optimization
options?
1. right result without optimization
$g++ -O0 -g3 -c test.cpp
$g++ -O0 -g3 -c a.cpp
$g++ -O0 -g3 -o
--- Comment #1 from meter dot ten at gmail dot com 2006-04-07 02:37 ---
this is not a bug.
--
meter dot ten at gmail dot com changed:
What|Removed |Added
--- Comment #4 from ned at bike-nomad dot com 2006-04-07 02:50 ---
Tried 4.0.3 (compiled from source via Darwinports); works OK there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27044
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-07 03:17 ---
Closing as fixed pre the reporter.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27053
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-07 03:19 ---
Please attach the files.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from patchapp at dberlin dot org 2006-04-07 04:00 ---
Subject: Bug number PR26766
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00249.html
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-07 05:23 ---
The patch which exposed this issue was reverted so this is no longer a
regression though it is still a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-07 05:26 ---
The patch which exposed the regression was reverted but this is still a bug as
shown by comment #6.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-07 05:26 ---
This is no longer a regression but it still is a bug as shown by comment #2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from roger at eyesopen dot com 2006-04-07 05:30 ---
This appears to be a problem with instruction attributes in the x86 backend,
and looks to be still present (but latent?) on mainline.
The problem is that i386.c's memory define_attr tries to determine whether
an insn is
92 matches
Mail list logo
