[cfe-commits] r68363 - in /cfe/trunk: include/clang/Basic/TargetInfo.h lib/Basic/Targets.cpp lib/CodeGen/CodeGenModule.cpp test/CodeGen/darwin-string-literals.c

[Eli Friedman]

On Thu, Apr 2, 2009 at 10:45 PM, Daniel Dunbar <daniel at zuster.org> wrote:
>> Also, I'm kind of curious, why does this matter?  It's an internal
>> symbol, nothing should be able to see it...
>
> You'd think! It matters because the name of the internal symbol on Darwin
> influences the linker. Symbols prefixed with L have special behavior, which
> I don't claim to fully understand...

Wow, that's nasty... good to know, though.

>> > +  if (isUTF16) {
>> > +    unsigned Align = getContext().getTypeAlign(getContext().ShortTy)/8;
>> > +    GV->setAlignment(Align);
>> > +  }
>>
>> Would it be more natural to make UTF-16 strings arrays of i16's
>> instead of manually messing with the alignment?
>
> Currently we match llvm-gcc, which is somewhat of a good thing. Although
> that seems reasonable, I don't really know anything about Unicode strings.
> For example, I can't even say whether it is correct that we output them in
> the host endianness!

It's pretty clearly wrong that we output in host endianness... it
means that a C file with a Unicode CFString targeting x86 will compile
differently on x86 and PPC hosts, no?  The other reason I was
suggesting using an i16 array is that it solves the endianness issues
without an explicit check.  That said, there is some value to matching
llvm-gcc.

-Eli