--- Comment #5 from matz at suse dot de 2009-05-07 15:13 ---
Subject: Re: [4.5 Regression] casts loose alignment
info
On Thu, 7 May 2009, rguenth at gcc dot gnu dot org wrote:
> And if something should look through conversions it is get_pointer_alignment
Yes, this is actually u
--- Comment #21 from matz at suse dot de 2009-05-06 21:39 ---
Subject: Re: [4.5 Regression] Revision 146817 caused
unaligned access in gcc.dg/torture/pr26565.c
On Wed, 6 May 2009, rguenther at suse dot de wrote:
> > + tree ret;
> > + if (TYPE_PACKED (t))
>
--- Comment #9 from matz at suse dot de 2007-11-22 14:03 ---
Subject: Re: [4.3 Regression] SCCVN breaks
gettext
[sorry for the breakage in last response]
It does not. The RPO algorithm (the one proven) uses hash table deletes
per iteration. About the SCC algorithm they have to
--- Comment #7 from matz at suse dot de 2007-11-22 13:58 ---
Subject: Re: [4.3 Regression] SCCVN breaks
gettext
Hi,
On Thu, 22 Nov 2007, dberlin at dberlin dot org wrote:
> Right, but this is the optimistic set of hash tables, so that is okay.
I initially thought so too, but
--- Comment #5 from matz at suse dot de 2006-05-03 17:54 ---
Created an attachment (id=11368)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11368&action=view)
patch relative to 4.1
This is the same patch adjusted for 4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27409
--- Comment #4 from matz at suse dot de 2006-05-03 17:53 ---
Yes. I'm testing it for trunk and 4.1 on a couple platforms.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27409
--- Comment #12 from matz at suse dot de 2006-05-03 15:48 ---
It's bug 27409 now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26678
RMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27409
--- Comment #10 from matz at suse dot de 2006-05-03 15:40 ---
We also got a bugreport about an ICE in get_constraint_for_component_ref,
but have a C testcase. In the hope that it's the same reason I paste it
here:
-
/* compile with gcc -c -O2 -o
--- Comment #6 from matz at suse dot de 2006-03-25 21:10 ---
The sequence of what happens is a bit involved, and breaks a very old
invariant in reload.c which doesn't seem to hold anyway since a long
time, as there is already much code handling this non-holding, namely
that subreg
--- Comment #29 from matz at suse dot de 2006-03-25 01:07 ---
There is a minor glitch in the patch from Richard, which went in when
cleaning it up. This line:
+ __asm__ (".symver pthread_create, pthread_create@@" GC_PTHREAD_SYM_VERSION);
which creates the right vers
--- Comment #5 from matz at suse dot de 2006-03-21 13:59 ---
There is no such thing as a hidden reference. A symbol can be hidden,
then it's not exported and all references from inside DSO are directly bound
to it. That's not the situation we have here. We have a globa
--- Comment #9 from matz at suse dot de 2006-03-13 08:57 ---
-fno-ivopts fixes it. The problem is how bitfield refs are dealt with it
seems. With -fno-ivopts the final_cleanup pass looks like so at the
interesting point:
D.2180 = BIT_FIELD_REF <*pdev, 32, 544> &
--- Comment #53 from matz at suse dot de 2006-02-15 12:24 ---
So, it's fixed. I'm not able to actually change the state to FIXED, so
someone has to do this for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #1 from matz at suse dot de 2006-02-13 16:53 ---
Created an attachment (id=10836)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10836&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26260
ssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
GCC host triplet: ppc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26260
--- Comment #47 from matz at suse dot de 2006-02-12 03:59 ---
What do you mean with 6 (as making more sense)? The size of the struct?
Anyway, even ignoring that we talk about structs which are packed in various
ways (as you rightly noticed) even the old (IMHO more sensible behaviour
--- Comment #20 from matz at suse dot de 2006-02-02 16:56 ---
I've put the patch to testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996
--- Comment #42 from matz at suse dot de 2006-01-23 11:28 ---
Created an attachment (id=10711)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10711&action=view)
Testprogram
This program generates the following output for 3.3-hammer-branch on x86-64:
S_normal_i
--- Comment #41 from matz at suse dot de 2006-01-23 11:23 ---
Created an attachment (id=10710)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10710&action=view)
candidate patch
This patch contains some commented out test code I had in for playing around.
--
http://gcc.
--- Comment #40 from matz at suse dot de 2006-01-23 11:21 ---
Mark, re your comment #38: (my comment #39 actually came before, but I forgot
to press "Commit" :-/ ) the #pragma pack(1) does not influence DECL_PACKED.
It is only set by attribute(packed). That's why th
--- Comment #39 from matz at suse dot de 2006-01-23 10:32 ---
Gnah! It's even worse. I spoke too soon, and actually pre-3.4 (3.3 in fact)
has the behaviour _swapped_. I.e. using the example struct I have these
sizes (on i686):
3.3:normal 16, pragma 16, packed 12
4.1+
--- Comment #37 from matz at suse dot de 2006-01-20 16:36 ---
Hmpf. One more difficulty. x86 uses the ADJUST_FIELD_ALIGN macro
to further fiddle with alignments of fields. On x86 this is used to
adjust the alignment of long long to 4 (instead of the natural 8).
This is used only when
--- Comment #36 from matz at suse dot de 2006-01-20 14:01 ---
Yes. Should be done shortly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #32 from matz at suse dot de 2006-01-19 14:44 ---
Mark, I agree that it's saner when both structures (with #pragma pack and
attribute packed) have the same length of 8 on i686 and x86_64 (because
the bitfield was declared 'int' in difference to 'long
--- Comment #28 from matz at suse dot de 2006-01-17 22:31 ---
And indeed with this testcase:
typedef int BOOL;
typedef unsigned int UINT;
typedef struct {
BOOL fFullPathTitle:1;
BOOL fSaveLocalView:1;
BOOL fNotShell:1
--- Comment #27 from matz at suse dot de 2006-01-17 22:12 ---
Funnily I've also looked at stor-layout.c a bit, and basically came to
a similar conclusion and patch like Steven. I agree that as per documentation
PCC_BITFIELD_TYPE_MATTERS overrides EMPTY_FIELD_BOUNDARY. But tha
--- Comment #23 from matz at suse dot de 2006-01-16 15:14 ---
The x86-64 ABI itself doesn't talk about zero-sized bitfields. So both
behaviours are correct regarding the ABI. It talks about unnamed bitfields
(which zero-sized ones must be) not influencing the overall alignme
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
GCC host triplet: ia64-linux
http://gcc.gnu.org/bugzilla
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
GCC host triplet: i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25329
--- Comment #6 from matz at suse dot de 2005-11-21 14:25 ---
Something is fishy. Iff registers are used for passing then it would have to
be %rdi and %rsi (not %rax)! So the high part of this struct (where the
bitfield lies) is not passed at all here. Per ABI this whole struct
should
--- Comment #11 from matz at suse dot de 2005-11-09 15:32 ---
You mean ABI change, because the input register seems to be f8, instead of
in0 (as would be need for this union)? I'm not sure, but it looks fishy
at least.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24661
--- Comment #9 from matz at suse dot de 2005-11-09 14:49 ---
A shorter testcase (which at least breaks on SuSEs 3.3-hammer compiler) is:
---
typedef union value {
long double d;
} Value;
double ld2d(Value v) {
return v.d
--- 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
--- Comment #5 from matz at suse dot de 2005-11-04 14:45 ---
While 4.0 had this fixed, trunk still uses the 'mt' allocator by default
on linux, and hence is incompatible with 3.4 and 4.0 by default. Is that
really intended, or shouldn't also trunk default back to the
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23691
--- Additional Comments From matz at suse dot de 2005-09-02 16:14 ---
Yes, I also got the boost error. And I got that with a 4.0 CVS version
from today. Reverting Marks patch also solves the boost problem
described in PR23691.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23699
breaks glibmm
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: mark at codesourcery dot com
ReportedBy: matz at suse dot de
CC: gcc-bugs at gcc dot
--- Additional Comments From matz at suse dot de 2005-09-01 15:11 ---
This still isn't in the 4.0 branch. Perhaps ping it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23326
--- Additional Comments From matz at suse dot de 2005-08-19 01:36 ---
Still a problem in the current hammer branch. CCing Honza.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23472
--- Additional Comments From matz at suse dot de 2005-08-11 16:13 ---
I don't think this is actually fixed in reload1.c. Perhaps it is hidden
by other changes, so that the particular miscompilation doesn't happen
anymore, but even HEAD reload1.c contains the questiona
--- Additional Comments From matz at suse dot de 2005-07-27 13:46 ---
Because these symbols indeed are not defined anywhere. On linux this happens
to work, but on darwin you need to link against something which provides them.
So you would need to create a library which
--- Additional Comments From matz at suse dot de 2005-07-22 12:46 ---
I don't understand. The code itself is perfectly valid C++, I don't think
you mean that it's invalid, right? Yes, operator== is also hidden, but
there is no definition for it in this unit, hence GC
c
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
CC: gcc-bugs at gcc dot gnu dot org,jh at suse dot cz
G
--- Additional Comments From matz at suse dot de 2005-07-20 14:20 ---
This still happens with 4.1. I also can't make it use two cmovs, by changing
the source a bit, e.g. like:
typedef unsigned long ulong;
extern ulong use (ulong, ulong);
ulong f(ulong a, ulong b)
{
ulon
--- Additional Comments From matz at suse dot de 2005-07-13 13:55 ---
I was going to add this text to PR22453, when I noticed that it was closed
as duplicate to this one. So putting it here for reference, although
everything seems to be analyzed already:
The reload happens, because
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21388
--- Additional Comments From matz at suse dot de 2005-06-30 15:23 ---
Ah, I see. Note that you must compile the reduced testcase (thanks for
that) with -O0, or with -fno-inline, otherwise the A::A ctor will be inlined
in use.cc (making the warning about the non-availability of it even
--- Additional Comments From matz at suse dot de 2005-06-30 15:01 ---
Andrew: that's not a diagnostic issue. While the diagnostic (the warning)
indeed is wrong and misleading (and probably points to the underlying cause
of this issue), the actual error I'm complaining abo
rity: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
CC: gcc-bugs at gcc dot gnu dot org,schwab at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22252
--- Additional Comments From matz at suse dot de 2005-06-27 13:50 ---
Hmm, sort of. The call of g(i) also warns with "is used", although I
think it might deserve only a "may be used". But anyway I think that
this nevertheless has different causes. It's n
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22197
--- Additional Comments From matz at suse dot de 2005-06-21 20:31 ---
This patch seems to be the reason for warnings like:
In file included from ../../gcc/gcov-io.h:239,
from ../../gcc/libgcov.c:51:
./auto-host.h:23:1: warning: "DEFAULT_USE_CXA_A
--- Additional Comments From matz at suse dot de 2005-06-14 16:13 ---
No. The vtable itself (as all methods of class foo) is implemented in
libfoo.so with default visibility, i.e. exported just fine:
25: 17d812 OBJECT WEAK DEFAULT 20 vtable for foo
Then there is
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22063
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21721
--- Additional Comments From matz at suse dot de 2005-06-10 11:50 ---
Thanks. Sorry, I couldn't revert as you suggested, as I became ill the day
after noticing the problem :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19768
--- Additional Comments From matz at suse dot de 2005-06-06 07:48 ---
Created an attachment (id=9035)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9035&action=view)
New patch
This fixes a problem in HJs patch (which doesn't look at the fndecl
of the builtin, but at t
--- Additional Comments From matz at suse dot de 2005-06-06 06:35 ---
I know. Andrew: when you backported this patch:
PR tree-optimization/21085
* fold-const (fold): Don't change X % -C to X % C if C has
overflowed.
you accidentally also checked in a chan
--- Additional Comments From matz at suse dot de 2005-06-06 06:19 ---
20050512 was the working one, I meant.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19768
--- Additional Comments From matz at suse dot de 2005-06-06 06:18 ---
This happens again. I've seen it in a 20050603 4.0 compiler (compiled
with --enable-checking). It was not happening with the 20040512 compiler
from the 4.0 branch.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Additional Comments From matz at suse dot de 2005-06-03 14:56 ---
There are some maybe-uninitialized vars warnings. But if I fix them by
zeroing the vars it still ICEs. I can't find other uninitialized vars.
It might be, that there are uninitialized struct members, but
--- Additional Comments From matz at suse dot de 2005-06-01 20:59 ---
Yes. I think this is because the compiler needs to see the definition and the
use site
to exhibit this bug. Without the def it will correctly emit the code walking
the table
to get to the member.
--
http
--- Additional Comments From matz at suse dot de 2005-05-23 16:52 ---
Created an attachment (id=8953)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8953&action=view)
tarball showing the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21722
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC target triplet: i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21722
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
--- Additional Comments From matz at suse dot de 2005-04-29 19:03 ---
This is now fixed, but it seems, even though I'm logged in, I can't change the
state
of this report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21144
--- Additional Comments From matz at suse dot de 2005-04-28 09:24 ---
Yes, I determined that already in the initial report; to cite myself:
> It's invalid for two reasons I think, first the missing definition, instead
> of the declaration.
[the second reason being the
--
Bug 20912 depends on bug 21089, which changed state.
Bug 21089 Summary: [4.0/4.1 Regression] C++ front-end does not "inline" the
static const double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
What|Old Value |New Value
--- Additional Comments From matz at suse dot de 2005-04-28 02:46 ---
Uhm, wait. Perhaps the optimization would be invalid for your changed example
from comment #5, but see below. But it will not be invalid for my initial
testcase,
where it missed to propagate 20.0 into setPosition
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21239
--- Additional Comments From matz at suse dot de 2005-04-25 13:26 ---
Created an attachment (id=8734)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8734&action=view)
Patch for above problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21144
--- Additional Comments From matz at suse dot de 2005-04-25 13:20 ---
The problem is in reload_cse_move2add. It has such a loop:
for (narrow_mode = GET_CLASS_NARROWEST_MODE (MODE_INT);
narrow_mode != GET_MODE (reg
--- Additional Comments From matz at suse dot de 2005-04-19 16:51 ---
I agree with most of what Jim said. Except for the part that we maybe don't
have to fix the reload issue, when we fix usage of the uninitialized register
for piecewise struct initialization. The latter wil
--- Additional Comments From matz at suse dot de 2005-04-18 17:59 ---
With -O0 we also don't inline 'a'. I thought in the past this already
was done in the frontend, so the -O option didn't matter? If yes, this
has changed (if not, well, I'm wrong ;-) ).
--- Additional Comments From matz at suse dot de 2005-04-18 17:40 ---
Indeed. Okay, but then this really is an optimization regression compared
to gcc 3.3.x which compiled this just fine. As it's only rejected with
-pedantic (and I think it's a sensible extension), shouldn
atic const double members with
initializer
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
--- Additional Comments From matz at suse dot de 2005-04-18 14:51 ---
>From
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01508.html
where I submitted the patch:
the problem in khtml. I've bootstrapped it with gcc 4.0 on
i686,x86_64,ppc,ppc64,ia64,s390 (s390x was brea
--- Additional Comments From matz at suse dot de 2005-04-18 14:22 ---
This patch fixes the regressions in khtml for us.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
--- Additional Comments From matz at suse dot de 2005-04-18 12:50 ---
Oh, and just annotating the testcase with the visibility push/pop #pragma
is not enough, probably because of the problem in the c++ frontend, HJ noted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--- Additional Comments From matz at suse dot de 2005-04-18 12:49 ---
So, any progress on this whole issue? I don't see either the pragmas in the
C++ headers, nor HJs changes to the c++ frontend (despite testcase) in CVS.
Just for the record, I see these problems (linkproblem
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
--- Additional Comments From matz at suse dot de 2005-04-15 08:20 ---
Forgot to say, the preprocessed file is for s390x. On s390 the same happens,
though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
--- Additional Comments From matz at suse dot de 2005-04-15 08:19 ---
Created an attachment (id=8641)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8641&action=view)
Preprocessed source for the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
Component: target
AssignedTo: uweigand at de dot ibm dot com
ReportedBy: matz at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: {s390,s390x}-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
--- Additional Comments From matz at suse dot de 2005-04-15 06:51 ---
Perhaps due to the IPA infrastructure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
--- Additional Comments From matz at suse dot de 2005-04-15 06:21 ---
Created an attachment (id=8640)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8640&action=view)
Tarball with the testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21039
cpp incorrectly handles different headers with same
name
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21039
--- Additional Comments From matz at suse dot de 2005-04-15 03:16 ---
One strange thing is, that the call to getWidth() in B is already in .generic:
if (retval.1)
{
getWidth (&i_bnds);
}
while the call to getWidth() in isEmpty() (which is inlined later
--- Additional Comments From matz at suse dot de 2005-04-15 02:40 ---
We see this error in blender. I was able to reduce it quite a bit to this:
struct IMG_Rect {
virtual inline int getWidth() const;
virtual inline bool isEmpty() const;
virtual int getVisibility(int) const
--- Additional Comments From matz at suse dot de 2005-04-12 19:47 ---
I have a patch for reload, which fixes the bug, when looking at the dumps.
At least now find_reg is used for the insn in question, which also evicts
pseudos using the same reg as the chosen final reg_rtx. I have
--- Additional Comments From matz at suse dot de 2005-04-12 19:05 ---
The problem is in reload.c:find_dummy_reload. It tries to use the input reg
as reload register for an in-out reload and has certain conditions when it
can't do so:
/* Consider using IN if OUT was not accep
--- Additional Comments From matz at suse dot de 2005-04-12 17:37 ---
Another mail:
I think the dust settles a bit. We have this situation in
.t69.final_cleanup (excerpt from applyRule):
struct Length D.83927;
:;
D.83927.D.21947.l.value = (int) primitiveValue->m_value.
--- Additional Comments From matz at suse dot de 2005-04-12 17:34 ---
Here some mails we exchanged:
Adding something complex seems to change how
things are allocated or REG_DEAD notes distributed or something like this.
If we add 'kdDebug( 6080 ) << "applying
--- Additional Comments From matz at suse dot de 2005-04-12 17:30 ---
Created an attachment (id=8610)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8610&action=view)
the preprocessed source showing the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
iority: P2
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20949
--- Additional Comments From matz at suse dot de 2005-02-17 22:06 ---
I think that #19566 is a real bug. The ABI specifies to pass 16byte
structs in registers. Anyway MAX_FIXED_MODE_SIZE doesn't influence
the calling convention, only how such struct is handled by transforming
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
at gcc dot gnu dot org
ReportedBy: matz at suse dot de
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC host triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
1 - 100 of 107 matches
Mail list logo
