name compatibility with llvm-gcc?

Hi,

I noticed that struct and union LLVM type names generated by clang and llvm-gcc don't follow the same naming convention, which is causing me some headaches.
llvm-gcc uses the following convention: struct.struct_name; struct.union_name
while clang uses: struct._struct_name; union._union_name.

Can we change clang so that clang respects llvm-gcc's ABI? I would appreciate this change (I'm using clang, while my colleague is using llvm-gcc..).

Thanks,
Nuno

Sounds fine with me, it should be an easy change.

-Chris

Hi,

I noticed that struct and union LLVM type names generated by clang and
llvm-gcc don't follow the same naming convention, which is causing me some
headaches.
llvm-gcc uses the following convention: struct.struct_name;
struct.union_name
while clang uses: struct._struct_name; union._union_name.

Okay... I suppose we could try to follow llvm-gcc's convention. That
said, LLVM type names aren't really reliable in the first place, since
identical types are merged. And we don't always generate struct types
in quite the same way as llvm-gcc (clang generates padding and unions
quite differently).

Can we change clang so that clang respects llvm-gcc's ABI? I would
appreciate this change (I'm using clang, while my colleague is using
llvm-gcc..).

This has nothing to do with the ABI, and in fact it doesn't affect the
code's semantics at all; using the term ABI just confuses the issue.

-Eli

I noticed that struct and union LLVM type names generated by clang and
llvm-gcc don't follow the same naming convention, which is causing me some
headaches.
llvm-gcc uses the following convention: struct.struct_name;
struct.union_name
while clang uses: struct._struct_name; union._union_name.

Can we change clang so that clang respects llvm-gcc's ABI? I would
appreciate this change (I'm using clang, while my colleague is using
llvm-gcc..).

Sounds fine with me, it should be an easy change.

Arg, actually my analysis was wrong.
The problem is that function decls save the canonical type. E.g.:

typedef struct _zend_op_array zend_op_array;
struct _zend_op_array { ... };

zend_op_array *foo() { return 0; }

When codegening the function foo I get the 'struct _zend_op_array', instead of zend_op_array. This is the reason why I was getting the 'struct._struct_name' style names.

So this problem isn't that easy to "fix". It would require saving the non-canonical type instead of the canonic one (that I think you don't want to do?).

> Can we change clang so that clang respects llvm-gcc's ABI? I would
> appreciate this change (I'm using clang, while my colleague is using
> llvm-gcc..).

This has nothing to do with the ABI, and in fact it doesn't affect the
code's semantics at all; using the term ABI just confuses the issue.

I called it ABI just in the sense that I wanted to link code generated by the 2 different frontends. I need to fill in structures at runtime that were compiled with either llvm-gcc or clang (I need a StructType* out of a name). Anyway just forget the ABI thing.. :slight_smile:

Nuno

I noticed that struct and union LLVM type names generated by clang and
llvm-gcc don't follow the same naming convention, which is causing me some
headaches.
llvm-gcc uses the following convention: struct.struct_name;
struct.union_name
while clang uses: struct._struct_name; union._union_name.

Can we change clang so that clang respects llvm-gcc's ABI? I would
appreciate this change (I'm using clang, while my colleague is using
llvm-gcc..).

Sounds fine with me, it should be an easy change.

Arg, actually my analysis was wrong.
The problem is that function decls save the canonical type. E.g.:

typedef struct _zend_op_array zend_op_array;
struct _zend_op_array { ... };

zend_op_array *foo() { return 0; }

When codegening the function foo I get the 'struct _zend_op_array', instead of zend_op_array. This is the reason why I was getting the 'struct._struct_name' style names.

So this problem isn't that easy to "fix". It would require saving the non-canonical type instead of the canonic one (that I think you don't want to do?).

Why do you need this info? It sounds like a bad design somewhere.

I called it ABI just in the sense that I wanted to link code generated by the 2 different frontends. I need to fill in structures at runtime that were compiled with either llvm-gcc or clang (I need a StructType* out of a name). Anyway just forget the ABI thing.. :slight_smile:

Regardless of whether it is part of the ABI, names are just entries in a symbol table. You can completely remove those names without affecting the semantics of the LLVM IR.

-Chris