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
> 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
>> 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
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.
cfe-commits mailing list