Unexpected pure-gen output on Fedora 17 and above

[Michel Alexandre Salim]

Hi Albert,

On Fedora 15 and 16, pure-gen works as expected. On Fedora 17 and above, though (with LLVM 3.0), the generated *.pure files contain additional definitions:

On 32-bit x86:
 $diff dummy.pure - > /dev/null <<EOF
 /* dummy.h: */
+const i386 = 1;
+const linux = 1;
+const unix = 1;
 const DUMMY = 99;
 extern int rand();
 EOF

On x86_64:
 $diff dummy.pure - > /dev/null <<EOF
 /* dummy.h: */
+const linux = 1;
+const unix = 1;
 const DUMMY = 99;
 extern int rand();
 EOF

I'm currently adjusting run-tests, since the changes do not appear harmful (and Fedora 17 is not even in beta yet, anyway), but is this something to be concerned about?

Thanks,

--
Michel Alexandre Salim
Fedora Project

[Albert Graef]

On 02/15/2012 10:44 AM, Michel Alexandre Salim wrote:
> On Fedora 15 and 16, pure-gen works as expected. On Fedora 17 and above,
> though (with LLVM 3.0), the generated *.pure files contain additional
> definitions:
>
> On 32-bit x86:
> $diff dummy.pure - > /dev/null <<EOF
> /* dummy.h: */
> +const i386 = 1;
> +const linux = 1;
> +const unix = 1;
> const DUMMY = 99;
> extern int rand();
> EOF

Hmm, that looks as if some additional #defines in system headers sneaked
in that weren't there previously. I don't think that this is related to
LLVM, it probably has to do with the gcc version or maybe the glibc version.

I'll have to take a look at the pure-gen tests and see whether I can get
rid of those defines so that the test passes successfully.

> I'm currently adjusting run-tests, since the changes do not appear
> harmful (and Fedora 17 is not even in beta yet, anyway), but is this
> something to be concerned about?

I don't think so, but I'm going to take a look anyway. Thanks for
reporting the issue.

Albert

--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag

[Michel Alexandre Salim]

On Thursday, February 16, 2012 12:15:36 AM UTC+1, ag wrote:

On 02/15/2012 10:44 AM, Michel Alexandre Salim wrote:
> On Fedora 15 and 16, pure-gen works as expected. On Fedora 17 and above,
> though (with LLVM 3.0), the generated *.pure files contain additional
> definitions:
>
> On 32-bit x86:
> $diff dummy.pure - > /dev/null <<EOF
> /* dummy.h: */
> +const i386 = 1;
> +const linux = 1;
> +const unix = 1;
> const DUMMY = 99;
> extern int rand();
> EOF

Hmm, that looks as if some additional #defines in system headers sneaked
in that weren't there previously. I don't think that this is related to
LLVM, it probably has to do with the gcc version or maybe the glibc version.

That could well be the case, we're using GCC 4.7.0 (pre-release). I had to revert to building pure with g++ instead of clang++, since the updated libstdc++ headers in this GCC release breaks clang support yet again (more C++0x-ism that clang does not support yet, and we cannot ship LLVM's libc++ since that is currently OS X only)

Fedora actually shifted to a more conservative policy regarding glibc upgrades, so we're now on 2.15 which should not be that different from Fedora 16's glibc 2.14.90 

I'll have to take a look at the pure-gen tests and see whether I can get
rid of those defines so that the test passes successfully.

Thanks for looking into this!

Regards,

[Albert Graef]

On 02/17/2012 08:05 AM, Michel Alexandre Salim wrote:
> That could well be the case, we're using GCC 4.7.0 (pre-release).

Ok. Using that compiler version, can you please send me the output of
the following command when applied to the attached dummy.h file?

gcc -E -fdirectives-only dummy.h

[Michel Alexandre Salim]

Attached; the i686 is done by adding '-m32' to the GCC invocation.

[Albert Graef]

On 02/20/2012 03:39 PM, Michel Alexandre Salim wrote:
> Attached; the i686 is done by adding '-m32' to the GCC invocation.

Ok, so gcc 4.7 makes it look like the built-in #defines came from the
compiled header. That is really bad, as there's no reliable way to work
around it.

In previous gcc versions, the built-in definitions were placed in a
special <built-in> module, which made the output look like this:

# 1 "dummy.h"
# 1 "<built-in>"
#define __STDC__ 1
// lots of built-in definitions follow ...
# 1 "<command-line>"
#define _FORTIFY_SOURCE 2
# 1 "dummy.h"
#define DUMMY 99
extern int rand(void);

This is much better, since it allows a parser to detect the built-in
defines easily. The <command-line> part is still present in the gcc 4.7
output, so I wonder why they dropped <built-in>. I can't find anything
in the ChangeLog. A bug in the gcc 4.7 preprocessor maybe?

Albert

[Albert Graef]

On 02/20/2012 05:55 PM, Albert Graef wrote:
> On 02/20/2012 03:39 PM, Michel Alexandre Salim wrote:
>> Attached; the i686 is done by adding '-m32' to the GCC invocation.
>
> Ok, so gcc 4.7 makes it look like the built-in #defines came from the
> compiled header. That is really bad, as there's no reliable way to work
> around it.

I still think that this is a bug, but maybe we can work around it after
all. Michel, can you please post the output of this command (same as
before, but with the -std=c99 option added):

gcc -E -fdirectives-only -std=c99 dummy.h

This should suppress all built-in macro definitions outside the
"reserved namespace" (i.e., not stropped with a leading underscore),
which should be good enough since pure-gen will by default ignore the
other system macros anyway.

Alas, there are two problems with this approach. First, it will break
headers which presume the unix and linux macros. Second, it will also
break headers which use other gcc-specific syntax. C99 does permit
C++-style line comments, but I'm not sure what other gcc ideosyncrasies
may be found in typical library headers, and what consequences they may
have when parsed as C99 source.

So I'm still looking for a better solution. Any ideas?