[cfe-dev] name compatibility with llvm-gcc?

[Chris Lattner]

On Jul 9, 2008, at 4:18 AM, Nuno Lopes wrote:

>>> 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.. :)

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