rjmccall added a comment.

I'm not sure your new wording is any clearer; a

In D118804#3304337 <https://reviews.llvm.org/D118804#3304337>, @urnathan wrote:

> In D118804#3304280 <https://reviews.llvm.org/D118804#3304280>, @aaron.ballman 
> wrote:
>
>> In D118804#3304261 <https://reviews.llvm.org/D118804#3304261>, @urnathan 
>> wrote:
>>
>>> While C2X has blessed such smaller alignments, the x86_64 ABI (in 
>>> particular), has not.  However, using that ABI to justify 'It. Is. 16. 
>>> Bytes.', is really an exercise in reality denial at this point.  just 
>>> thought I'd make it clear we have conflicting standards and practicality to 
>>> attend to.
>>
>> Do we want me to report back to WG14 with information that N2293 might not 
>> suitable for adoption into C2x?
>
> I think N2293 is fine for C2x.  It is blessing an implementation of lower 
> alignment allocations.  Putting the programmer on notice that they can no 
> longer assume some things.
>
> As a compiler I think we need to deal with the reality that there are non-ABI 
> conforming [system-dependent] allocators out there, and not simply say 'But 
> the ABI says ...'

If a platform's ABI guarantees something, and the platform's system allocator 
actually does it, then that's the required behavior there, and replacement 
allocators that don't live up to it are non-conformant.  But if the system 
allocator intentionally *doesn't* do it, and the platform's ABI is a generic 
ABI, then yeah, we have to understand that as an intent to declare a 
platform-specific deviation from the generic ABI.

> There is already at least one thing the ABI says that is not valid on some 
> systems [sret return behaviour and Swift], for equally good reasons.  The 
> compiler deals with that.

Can you explain what you mean here?  Swift's conventions are not really bound 
by the C ABI.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118804/new/

https://reviews.llvm.org/D118804

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to