alias attributes in clang on darwin

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

alias attributes in clang on darwin

Jack Howarth-2
   While looking into a failing LTO testcase on FSF gcc trunk
on darwin, I noticed that clang appears to tolerate the code
whereas llvm-gcc-4.2 (like FSF gcc trunk doesn't). The simple
testcase is...

cat 20081222_0.h
int x();

cat 20081222_1.c
#include "20081222_0.h"

/* Actually, call "x" "INT_X", and make it hidden.  */
extern __typeof (x) x
        __asm__ ("INT_x")
        __attribute__ (( __visibility__ ("hidden")));

int x ()
{
  return 7;
}

/* Make an externally-visible symbol "X" that's an alias for INT_x.  */
extern __typeof (x) EXT_x
        __asm__ ("x")
        __attribute__ (( __alias__ ("INT_x")));

which in FSF gcc 4.4.4, 4.5.0, trunk, Apple gcc 4.2.1 and llvm-gcc produce...

gcc -O0 -c -o c_lto_20081222_1.o 20081222_1.c
20081222_1.c:16: error: only weak aliases are supported in this configuration

Clang however compiles this without complaint. Is this an enhancement in clang
on the alias attribute handling on darwin or a bug? If it is that latter,
can this enhancement be backported into llvm-gcc-4.2?
          Jack
ps I would also note that if I change the last line of 20081222_1.c to...

        __attribute__ (( weak, __alias__ ("INT_x")));

Apple's gcc-4.2.1 and llvm-gcc-4.2 both produce the compilation failure...

llvm-gcc -O0 -c -o c_lto_20081222_1.o 20081222_1.c
20081222_1.c:16: error: ‘EXT_x’ aliased to undefined symbol ‘INT_x’



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: alias attributes in clang on darwin

Chris Lattner

On May 10, 2010, at 4:40 PM, Jack Howarth wrote:
> Clang however compiles this without complaint. Is this an enhancement in clang
> on the alias attribute handling on darwin or a bug?

I don't know.

> If it is that latter, can this enhancement be backported into llvm-gcc-4.2?

No, in general, we don't plan to backport any clang enhancements into llvm-gcc.

-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: alias attributes in clang on darwin

Jack Howarth-2
On Mon, May 10, 2010 at 09:28:14PM -0700, Chris Lattner wrote:
>
> On May 10, 2010, at 4:40 PM, Jack Howarth wrote:
> > Clang however compiles this without complaint. Is this an enhancement in clang
> > on the alias attribute handling on darwin or a bug?
>
> I don't know.

Chris,
   Peter O'Gorman pointed out that Mac OS X prepends an underscore to C symbols
while whereas many linux systems don't. So, for Apple's gcc-4.2, if I change
the testcase to...

cat 20081222_0.h
int x();

cat 20081222_1.c
#include "20081222_0.h"

/* Actually, call "x" "INT_X", and make it hidden.  */
extern __typeof (x) x
        __asm__ ("_INT_x")
        __attribute__ (( __visibility__ ("hidden")));

int x ()
{
  return 7;
}

/* Make an externally-visible symbol "X" that's an alias for INT_x.  */
extern __typeof (x) EXT_x
        __asm__ ("_x")
        __attribute__ (( weak, __alias__ ("INT_x")));

by prepending "_" for the __asm__(), it also produces the expected warning of...

gcc-4.2 -O0 -c -o c_lto_20081222_1.o 20081222_1.c
20081222_1.c:16: warning: alias definitions not supported in Mach-O; ignored

Interestingly, clang accepts both the original and the modified test
case without complaint. Considering that Mach-O doesn't support alias
definitions this should probably be looked into as a potential bug in
clang on darwin.
                   Jack
ps Unless I am confused, these issues were addressed by Geoff Keating
with weakref's but it is unclear if a bug-free implementation was ever
achieved...

http://gcc.gnu.org/ml/gcc/2005-12/msg00009.html

Note the comment "I couldn't fully test this patch because weakrefs
still don't seem to be working properly on Darwin".


>
> > If it is that latter, can this enhancement be backported into llvm-gcc-4.2?
>
> No, in general, we don't plan to backport any clang enhancements into llvm-gcc.
>
> -Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev