Quantcast

Clang and glibc 2.25 incompatibilities?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Clang and glibc 2.25 incompatibilities?

Brian Cain via cfe-dev
I'm running into a weird situation with Clang 3.9.1 and glibc 2.25
(on Arch Linux). With this file:

    #include <assert.h>

    int main(void)
    {
        assert(1);
        return 0;
    }

I run Clang as such:

    clang -pedantic test.c

and I get this warning:

    test.c:4:5: warning: use of GNU statement expression extension
                [-Wgnu-statement-expression]
        assert(1);
        ^
    /usr/include/assert.h:95:6: note: expanded from macro 'assert'
        ({                                                                  \
         ^
    1 warning generated.

I don't have this warning with glibc 2.24. The difference is that in
glibc 2.24, assert.h contains:

    # define assert(expr) \
      ((expr) \
       ? __ASSERT_VOID_CAST (0) \
       : __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION))

whereas in glibc 2.25, assert.h contains:

    # if !defined __GNUC__ || defined __STRICT_ANSI__
    #  define assert(expr) \
        ((expr) \
         ? __ASSERT_VOID_CAST (0) \
         : __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION))
    # else
    #  define assert(expr) \
        ({ \
          if (expr) \
            ; /* empty */ \
          else \
            __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION); \
        })
    # endif

And it looks like Clang defines __GNUC__, so it reaches the statement
expression. A workaround is:

    clang -pedantic -U__GNUC__ test.c

Why does Clang define __GNUC__ by default?

What's the real solution here?

Thank you for your time,
Phil
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Clang and glibc 2.25 incompatibilities?

Brian Cain via cfe-dev
On Sat, Apr 01, 2017 at 10:31:54AM -0400, Philippe Proulx via cfe-dev wrote:
> Why does Clang define __GNUC__ by default?

Because it creates less problems than the alternatives. There is a lot
of code in the wild that essentially assumes a random version of gcc for
a lot of code. Given that Clang is implementing almost all the GCC
extensions of GCC 4.2.1, it claims to be that version. It means a bit
more work for newer code, but avoids breaking a lot of older code.

> What's the real solution here?

Create a bug report against glibc.

Joerg
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Clang and glibc 2.25 incompatibilities?

Brian Cain via cfe-dev
On Sat, Apr 1, 2017 at 12:42 PM, Joerg Sonnenberger via cfe-dev
<[hidden email]> wrote:

> On Sat, Apr 01, 2017 at 10:31:54AM -0400, Philippe Proulx via cfe-dev wrote:
>> Why does Clang define __GNUC__ by default?
>
> Because it creates less problems than the alternatives. There is a lot
> of code in the wild that essentially assumes a random version of gcc for
> a lot of code. Given that Clang is implementing almost all the GCC
> extensions of GCC 4.2.1, it claims to be that version. It means a bit
> more work for newer code, but avoids breaking a lot of older code.
>
>> What's the real solution here?
>
> Create a bug report against glibc.

Is it really a glibc issue? The header uses a GNU statement expression
when __GNUC__ is defined. Clang defines __GNUC__, but with -pedantic
it complains that I'm using a GNU extension. In other words Clang pretends
to be GCC by default, but complains when exposed to GCC extensions.

I don't think glibc is doing anything wrong here.

Phil

>
> Joerg
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Clang and glibc 2.25 incompatibilities?

Brian Cain via cfe-dev
On Sat, Apr 01, 2017 at 12:58:37PM -0400, Philippe Proulx wrote:

> On Sat, Apr 1, 2017 at 12:42 PM, Joerg Sonnenberger via cfe-dev
> <[hidden email]> wrote:
> > On Sat, Apr 01, 2017 at 10:31:54AM -0400, Philippe Proulx via cfe-dev wrote:
> >> Why does Clang define __GNUC__ by default?
> >
> > Because it creates less problems than the alternatives. There is a lot
> > of code in the wild that essentially assumes a random version of gcc for
> > a lot of code. Given that Clang is implementing almost all the GCC
> > extensions of GCC 4.2.1, it claims to be that version. It means a bit
> > more work for newer code, but avoids breaking a lot of older code.
> >
> >> What's the real solution here?
> >
> > Create a bug report against glibc.
>
> Is it really a glibc issue? The header uses a GNU statement expression
> when __GNUC__ is defined. Clang defines __GNUC__, but with -pedantic
> it complains that I'm using a GNU extension. In other words Clang pretends
> to be GCC by default, but complains when exposed to GCC extensions.
>
> I don't think glibc is doing anything wrong here.

The compiler identification macro has nothing to do with the language
mode. __STRICT_ANSI__ is not the right check, that's what applies only
for -std=cXX.

Joerg
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Clang and glibc 2.25 incompatibilities?

Brian Cain via cfe-dev
In reply to this post by Brian Cain via cfe-dev
On 1 Apr 2017 6:59 am, "Philippe Proulx via cfe-dev" <[hidden email]> wrote:
On Sat, Apr 1, 2017 at 12:42 PM, Joerg Sonnenberger via cfe-dev
<[hidden email]> wrote:
> On Sat, Apr 01, 2017 at 10:31:54AM -0400, Philippe Proulx via cfe-dev wrote:
>> Why does Clang define __GNUC__ by default?
>
> Because it creates less problems than the alternatives. There is a lot
> of code in the wild that essentially assumes a random version of gcc for
> a lot of code. Given that Clang is implementing almost all the GCC
> extensions of GCC 4.2.1, it claims to be that version. It means a bit
> more work for newer code, but avoids breaking a lot of older code.
>
>> What's the real solution here?
>
> Create a bug report against glibc.

Is it really a glibc issue? The header uses a GNU statement expression
when __GNUC__ is defined. Clang defines __GNUC__, but with -pedantic
it complains that I'm using a GNU extension. In other words Clang pretends
to be GCC by default, but complains when exposed to GCC extensions.

I don't think glibc is doing anything wrong here.

It is. This is also an incorrect definition for C++11, where assert(true) is required to be a constant expression.

Phil

>
> Joerg
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...