[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#837444, @jyknight wrote:

> Now, the "/tmp/foo-XXX.sh" also has a line labeled "Driver args: " with the original command-line on it. If I understand correctly, you then like to take this
>  simpler Driver command-line, and edit it manually: add -save-temps, and change the input filename  to the "/tmp/foo-XXX.c" file, and run that, instead
>  of actually invoking the reproducer foo-XXX.sh.


It's not so much that it is simpler, but the only reasonable easy way for forcing preprocessor output to written. That one is much nicer for passing to creduce for example (after stripping the remaining # lines).

> Since stdc-predef.h is included automatically, it will now be present twice -- first, it will read the one from your system's /usr/include, and then the copy inlined into the
>  /tmp/foo-XXX.c file. That's not what you desired. You wanted nothing from your /usr/include to be used.

Correct. Worse, the include may file depending on the host system and give different results from the original build, resulting in annoying debugging seasons.

> The fix for the end-user here is easy: you can add -nostdinc which will suppress all the default include paths, and thus it will not find this predef file from your system include dir.

Yeah, except you have to remember that when it was never needed before.

> I'll note that you'd also have had an issue if the original driver command-line had a "-include" option in it, which you would have needed to edit out
>  manually as well. (But I understand that is less common.)

Yes, -include is rarely used in the wild.

> Have I correctly described the situation? I guess my feeling here is that this is somewhat of an edge-case, and that the workaround (-nostdinc) is a sufficient fix.
> 
>>>> (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.
> 
> Yes, but this is information that the compiler has no real need to know, and that for many platforms would be difficult and problematic to coordinate.

That's kind of my point. There is little coordination involved for almost all platforms since they provide a consistent user environment as a single package. Pushing the changes into Clang (or GCC for that matter) is trivial if you do not have to deal with multiple different versions of libc, the kernel and whatever in a mix-and-match scenario.


https://reviews.llvm.org/D34158