search

Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

Enable GNU inline semantics selectively in C99 mode #3147

Open Quuxplusone opened 14 years ago

Quuxplusone commented 14 years ago
Bugzilla Link PR5960
Status NEW
Importance P normal
Reported by Douglas Gregor (dgregor@apple.com)
Reported on 2010-01-06 11:17:11 -0800
Last modified on 2013-06-18 06:02:05 -0700
Version trunk
Hardware PC other
CC anders.furuhed@pantor.com, csdavec@swan.ac.uk, efriedma@quicinc.com, fellswalker@gmail.com, geek4civic@gmail.com, ismail@i10z.com, llvm-bugs@lists.llvm.org, mattiase@acm.org, pipping@exherbo.org, rafael@espindo.la, rich@pennware.com, richard@tiptree.demon.co.uk
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

Per David Chisnall's comments in PR 3989, some platforms have glibc headers that expect GNU inline semantics even in C99 mode, which causes linking problems when building with Clang.

Implementing -fgnu89-inline works around part of the problem (and is probably a good idea in general), but that's a big hammer: we really want only those functions defined in the glibc headers to get GNU inline semantics.

Quuxplusone commented 14 years ago

Note that -fgnu89-inline doesn't completely fix this, because it will still break C99 code that has functions declared inline (they will expect the C99 semantics and get the GNU89 semantics).

Another possible work around is to treat inline as providing GNU semantics and inline as providing C99 semantics. The headers all use inline, but C99 code should be using inline because it's now part of the standard. This is probably simpler than working out which headers are affected.

Quuxplusone commented 14 years ago

Unless our behavior isn't consistent with gcc's -std=gnu99 mode, I'm tempted to say the correct solution here is "upgrade glibc".

Quuxplusone commented 14 years ago

This is the latest version of glibc packaged with some distributions (e.g. Red Hat Enterprise Linux / Centos). The problem manifests itself with glibc 2.5, which under three years old and so still in use on long-term-support GNU platforms.

Our behaviour is not consistent with GCC in -std=c99 mode, as I said. GCC tests the version of glibc and activates this hack if it's one of the affected versions. The user's C99 code is compiled with C99 rules, but the functions declared in the GCC headers use the gnu89 rules.

Quuxplusone commented 14 years ago

Oh; eww... can you look up how exactly gcc detects this? (I have a feeling the answer is a fixincludes, but I'd like to be sure.)

Quuxplusone commented 14 years ago

Yes, it's in fixincludes. There's a mailing list thread from November 2006 discussing implementing this.

'eww' is an understatement...

Quuxplusone commented 14 years ago 
The idea of treating __inline and inline differently seems to make sense.

However, for now I've taken the 'upgrade glibc' route ... though that has meant
that I had to build glibc from source since there is no sufficiently recent
package available for centos/redhat.
I don't like replacing system libraries (especially something as critical as
glibc) with home-built versions, and I don't think it's a reasonable thing to
ask people to do generally, so a change to clang to make it more gcc compatible
would be good.
Quuxplusone commented 13 years ago

Eli, did you fix this recently?

Quuxplusone commented 13 years ago

No, haven't touched this particular issue.

Quuxplusone commented 13 years ago

I'd love some assistance with this problem. I'm stuck using a Red Hat Enterprise Linux 5 system that someone else administers. Upgrading glibc is not in the cards.

Quuxplusone commented 12 years ago

We also implement attribute ((__gnu_inline__)), so if you have code that depends on c99 inline and uses a glibc that depends on gnu89 inline, you might be able to just add that attribute to the glibc headers.