http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
extern C int printf(const char*, ...);
struct B { };
struct X : public B { long p; };
struct Y : public B { X q; };
Y foo( Y y )
{
Y temp;
temp = y;
return temp;
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #5 from David Greene greened at obbligato dot org ---
(In reply to Jonathan Wakely from comment #4)
Clang uses the same registers as GCC:
Ok, but that still doesn't explain why. Can you point me to wording in either
the x86-64 ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #6 from David Greene greened at obbligato dot org ---
Bug filed against clang to see what they have to say.
http://llvm.org/bugs/show_bug.cgi?id=19675
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||hjl.tools at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #8 from David Greene greened at obbligato dot org ---
(In reply to H.J. Lu from comment #7)
It is the matter of if the size of
---
struct B { };
struct X : public B { long p; };
---
is size of long or not.
I don't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com ---
Y is returned as {NO_CLASS, INTEGER} in register. psABI doesn't
explicitly say how NO_CLASS should be handled in this case. GCC
simply skips NO_CLASS when assigning it to a register.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #10 from David Greene greened at obbligato dot org ---
(In reply to H.J. Lu from comment #9)
Y is returned as {NO_CLASS, INTEGER} in register. psABI doesn't
explicitly say how NO_CLASS should be handled in this case. GCC
simply
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to David Greene from comment #10)
So Y should be classified as INTEGER and returned in (RAX, RDX).
That is correct and Y is classified as INTEGER with 2 fields:
NO_CLASS,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #12 from David Greene greened at obbligato dot org ---
(In reply to H.J. Lu from comment #11)
That is correct and Y is classified as INTEGER with 2 fields:
NO_CLASS, INTEGER. The question is how NO_CLASS should be handled.
Since
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #13 from David Greene greened at obbligato dot org ---
I see that 3.2.3 4 (b) is talking about considering adjacent fields in an
eightbyte. Is the intent to classify each eightbyte in an aggregate and then
consider each eightbyte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #14 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to David Greene from comment #13)
I see that 3.2.3 4 (b) is talking about considering adjacent fields in an
eightbyte. Is the intent to classify each eightbyte in an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #15 from David Greene greened at obbligato dot org ---
(In reply to H.J. Lu from comment #14)
I think GCC is correct.
I agree. Thanks for working through the explanation with me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #1 from David Greene greened at obbligato dot org ---
This is on Linux/SuSE/SLES 11.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org ---
Y is a non-POD.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #3 from David Greene greened at obbligato dot org ---
(In reply to Andrew Pinski from comment #2)
Y is a non-POD.
So...?
The ABI doesn't talk about POD vs. non-POD. It talks about copy constructors
and destructors.
Can you explain
16 matches
Mail list logo
