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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
