sob., 6 maj 2023 o 19:30 Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Saturday, 6 May 2023 04:33:13 PDT Marcin Jaczewski via Std-Proposals wrote:
> > https://gcc.godbolt.org/z/Gxqs6v331
> > Interesting old MSVC reconginse this attribute but fails on assertion, new
> > one will say that it does not recognize this attribute.
>
> The assertion is your making an assumption of what the attribute will do, like
> assuming that code after a [[noreturn]] will get dead-code-eliminated or that
> [[assume]] informs the optimiser.
>
> But that's not the question I understood you'd asked. I thought you'd wanted
> to make sure that the user of your code wouldn't accidentally get an ABI
> mismatch when compiling their code against a pre-compiled yours. If the
> compiler isn't changing ABI, then there's nothing wrong with the test I
> supplied.
>
> If you want to achieve a particular layout, then you're making assumptions
> about the ABI. In that case, you can just do a more extensive #if to accept or
> reject, because you've certainly stepped far outside the standard. Or, like
> you've shown, you can test for the effects and either reject that compiler or
> use an alternative solution (like EBO).
>
> Can you tell me off the top of your head what the size of TypeAndFlags is?
> (let's assume a 64-bit little-endian architecture)
> enum class Type : unsigned short {};
> struct TypeAndFlags {
> uintptr_t isExtended : 1;
> Type type : 15;
> uintptr_t reserved : sizeof(void*) * 8 - 16;
> };
>

My whole point is I do not want to know this, I only want to guarantee
that ALL compilers that
target the same ABI have exactly the same result, and best would be if
it would work
same on old, current and future compilers.
Now if I use NUA, I do not have this, as some old MSVC compilers miss
report availability of NUA,
and GCC MinGW compiles it making output incompatible with one from old MSVC.
And this is very bad.


> > If we `__has_cpp_attribute` interpreted as "I implement this attribute
> > functionality", then yes, we could use this macro.
> > But if it means "I know that attribute exists" like older MSVS did,
> > then we could not use it.
>
> But it *does* implement the functionality. It applied all of the ABI changes
> that the ABI documents required of it. All zero of them.
>
> As I said above: you want a way to test that the ABI has a visible effect with
> the attribute. And you showed code that can detect it.
>

Yes, if the owner of ABI says that NUA should have no effect then all
compilers targeting this ABI
should obey this, and this is not QoI.

More I think about this, the more I think that Sebastian's solution
with `!!` is the correct one.
The Best part is that `[[!!xxx]]` is ill-formed C++ code today. This
means we have for free
protection from miss compiling using older compilers.
New compilers will recognize it as "required" attribute, and quote
from standard point:

"""
any such attribute-token that is not recognized by the implementation
is ignored.
"""

will not apply to attributes that start with `!!`, if the compiler
does not know what it is, then the program is ill-formed.
not optional warning or diagnostic, it should be a hard error.

Any workarounds with `#if` or `statc_assert` are more a symptom of
using the wrong tool for the job.

I think all attributes like `[[no_unique_address]]`,
`[[trivially_relocatable]]` or potential `[[tail_call]]`,
`[[fastcall]]` should only
be allowed in form `[[!!no_unique_address]]`,
`[[!!trivially_relocatable]]`, `[[!!tail_call]]`, `[[!!fastcall]]`.
As ignoring any of them could cause a lot of UB.

> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DCAI Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals