On Sat, 12 Dec 2015, Jakub Jelinek wrote:
On Sat, Dec 12, 2015 at 09:51:23AM -0500, Jason Merrill wrote:
On 12/11/2015 06:52 PM, H.J. Lu wrote:
On Thu, Dec 10, 2015 at 3:24 AM, Richard Biener
<richard.guent...@gmail.com> wrote:
On Wed, Dec 9, 2015 at 10:31 PM, Markus Trippelsdorf
<mar...@trippelsdorf.de> wrote:
On 2015.12.09 at 10:53 -0800, H.J. Lu wrote:
Empty C++ class is a corner case which isn't covered in psABI nor C++ ABI.
There is no mention of "empty record" in GCC documentation. But there are
plenty of "empty class" in gcc/cp. This change affects all targets. C++ ABI
should specify how it should be passed.
About this patch, aren't we supposed to enable new C++ ABIs with
-fabi-version=42 (or whatever the next number is)?
There is a C++ ABI mailinglist, where you could discuss this issue:
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
Yep. As long as the ABI doesn't state how to pass those I'd rather _not_ change
GCCs way.
It is agreed that GCC is wrong on this:
http://sourcerytools.com/pipermail/cxx-abi-dev/2015-December/002876.html
Yes, I think this is just a (nasty) bug on some GCC targets.
Well, the argument in that thread is weird, because C and C++ empty structs
are different, so it isn't surprising they are passed differently.
C++ makes those sizeof == 1, while C has them sizeof == 0.
Maybe it isn't surprising, but it isn't particularly helpful either. It
increases the number of places where the 2 are incompatible.
(I personally don't care about empty C structs)
So I rather think clang should change rather than GCC.
Passing empty arguments (with trivial copy constructor, etc) is a complete
waste. Not passing them is strictly superior. The only reason to prefer
passing them is that that's what gcc does and changing would break the
ABI. I could understand clang being unhappy if they have to both break ABI
compatibility with their older versions and move towards an inferior
ABI... (arguably they could have copied the de facto gcc ABI to begin
with) They might be willing to do it on linux-x86, but not on ios/mac
where they dominate and compatibility with their own earlier versions
matters more than compatibility with gcc?
--
Marc Glisse
