There is [[gnu::fastcall]]   According to the note in the standard, the unsupporting compilers should ignore it.     Options:   a) Was it a bad decision to provide it (as typically non-ignorable attribute) in C++ standard attribute syntax? [[gnu::fastcall]] should not be an attribute at all, and be changed to a different syntax, e.g. __gnu_fastcall__ and for attributes, you sometimes want to ignore, both vastly different syntaxes (the mentioned one and [[gnu::fastcall]] would have to be supported   b) [[gnu::fastcall]] is not known or recognized to old or different compilers. To always except it from the ignore-rule (not adhering to the standard) is not even a practical option.   c) [[gnu::fastcall]] could be ignorable and __attribute__((fastcall))__ not -> typically unknown __attribute__ attributes need a high warning level to get a warning at all, so not good   d) Always use feature test macros All vendor-specific attributes would need feature test macros   e) Change the rule in the standard to that unknown attributes always fail -> not practical for many 'hint attributes'     Anybody know the state of the related P2565 which looks for solutions against accidentally misspelled attributes. Ignored misspellings (per standard) are difficult to detect.   The suggestion here would solve that, too. As misspelled non-required attributes have less of an implication and misspelled required attributes would fail.   -----Ursprüngliche Nachricht----- Von:Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 07.05.2023 07:03 Betreff:Re: [std-proposals] [Draft Proposal] Required attribute syntax An:std-proposals_at_[hidden]; marcinjaczewski86_at_[hidden]; CC:Thiago Macieira <thiago_at_[hidden]>; On Saturday, 6 May 2023 16:32:49 PDT Marcin Jaczewski wrote: > 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. And you have any evidence that they don't? That's the point: the ABI decides what should happen and all compilers adhere to it. If a compiler decides they can't yet implement the necessary ABI rules, then they should simply say they don't support this attribute yet. And my point is that the MSVC ABI decided that this attribute means nothing. All compiler do adhere to it. > 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. MSVC's C++ ABI is not compatible with GCC's at all. You can only compare compilers that follow the ABI. > And this is very bad. I agree this attribute shouldn't have been one. But I don't see what the problem is right now. > 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: I disagree, but only mildly. Can you give three examples where this would be useful? NUA doesn't count because it's not a good attribute in the first place and, if we're going to change the language, we may as well fix this (IMO) mistake. > 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. Is there any proposal to standardise tail_call or fastcall? -- 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