[PATCH] D34158: For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is available

[Joerg Sonnenberger via Phabricator via cfe-commits]

joerg added a comment.

In https://reviews.llvm.org/D34158#836026, @jyknight wrote:

> In https://reviews.llvm.org/D34158#827178, @joerg wrote:
>
> > (2) It adds magic behavior that can make debugging more difficult. Partially preprocessed sources for example could be compiled with plain -c before, now they need a different command line.
>
>
> If this is a problem, making it be Linux-only does _nothing_ to solve it. But I don't actually see how this is a substantively new problem? Compiling with plain -c before
>  would get #defines for those predefined macros that the compiler sets, even though you may not have wanted those. Is this fundamentally different?


It makes it a linux-only problem. As such, it is something *I* only care about secondary. A typical use case I care about a lot is pulling the crash report sources from my (NetBSD) build machine,
extracting the original command line to rerun the normal compilation with -save-temps. I don't necessarily have the (same) system headers on the machine I use for debugging and that's exactly
the kind of use case this change breaks. All other predefined macros are driven by the target triple and remain stable.

>> (3) It seems to me that the GNU userland (and maybe Windows) is the exception to a well integrated tool chain. Most other platforms have a single canonical
>>  libc, libm and libpthread implementation and can as such directly define all the relevant macros directly in the driver.
> 
> I don't think this is accurate. There's many platforms out there, and for almost none of them do we have exact knowledge of the features of the libc encoded
>  into the compiler. I'd note that not only do you need this for every (OS, libc) combination, you'd need it for every (OS, libc-VERSION) combination.

Not really. The feature set is rarely changing and generally will have only a cut-off version.

>> Given that many of the macros involved are already reflected by the compiler behavior anyway, they can't be decoupled. I.e. the questionable
>>  concept of locale-independent wchar_t is already hard-coded in the front end as soon as any long character literals are used.
> 
> AFAICT, this example is not actually the case. The frontend only needs to know *a* valid encoding for wide-character literals in some
>  implementation-defined locale (for example, it might always emit them as unicode codepoints, as clang does).  Standard says:
>  "the array elements [...] are initialized with the sequence of wide characters corresponding to the multibyte character sequence, as
>  defined by the mbstowcs function with an implementation defined current locale."

I know what the standard says. It doesn't make much sense if you do not have a fixed wchar_t encoding.

> On the other hand, I believe the intent of this macro is to guarantee that _no matter what_ the locale is,
>  that a U+0100 character (say, translated with mbrtowc from the locale encoding) gets represented as 0x100.

Yes, so it is essentially "we have screwed up by creating a language mechanism that adds a major constraint, so let's go all the way".

> Thus, it's "fine" for the frontend to always emit wchar_t literals as unicode, yet, the libc may sometimes use an arbitrary different
>  internal encoding, depending on the locale used at runtime. (Obviously using wide character literals with such a libc would be a poor 
>  user experience, and such a libc probably ought to reconsider its choices, but that's a different discussion.)

One of the biggest opponents of that was Itojun. It's not a decision that should be made here as it is only indirectly related to this discussion.

>> As such, please move the command line additions back into the target-specific files for targets that actually want to get this behavior.
> 
> Without even a suggestion of a better solution to use for other targets, I find it is to be a real shame to push for this to be linux-only,
>  and leave everyone else hanging. I find that that _most_ of these defines are effectively library decisions. I further would claim that these
>  are likely to vary over the lifetime of even a single libc, and that as such we would be better served by allowing the libc to set them directly, rather than encoding it into the compiler.
> 
> TTBOMK, no targets except linux/glibc/gcc actually comply with this part of the C99/C11 standard today, and so this feature would be useful to have available across all targets.
> 
> (I very much dislike that the C standard has started adding all these new predefined macros, instead of exposing them from a header, but there's not much to be done about that...)

Exactly. It's not like this is a lot of target logic. It should be a single call for targets that want to get this functionality. But that's my point -- it should be opt-in, not opt-out.


https://reviews.llvm.org/D34158