[llvm-dev] [ARM] [C++ standard] Correct linkage type for string literals in extern inline functions

[Hubert Tong via llvm-dev]

Please refer to
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1823.

-- HT

On Tue, Mar 21, 2017 at 9:02 PM, Sameer AbuAsal via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
>
>
> I came across this behavior irregularity in LLVM for ARM backend  (-target
> arm-linux-gnueabi) with the constant promotion optimization in arm
> (-arm-promote-constant=true).
>
> For the attached source files compiling with the following:
>
>
>
> clang++  -target arm-linux-gnueabi A.cpp B.cpp –o a.out
>
> The addresses returned from bar() and foo() are not the same (string
> literals live in different memory locations) however, when we turn off the
> constant pool optimization
>
>
>
> clang-arm-x++ -Ofast -mllvm -arm-promote-constant=false   A.cpp B.cpp -o
> test_case.exe –o a.out
>
> we are getting the same addresses for string literals.
>
>
>
> Looking into the ll files , the strings are created as  “private
> unnamed_addr constant” so the constant pool optimization pass is promoting
> them to constant pools and causing them to have different addresses, which
> seems fine.
>
>
>
> Is this behavior in line with the C++ standard for strings in extern
> inline functions? If not, what should be the correct linkage type emitted
> for this constant? Is this a potential clang bug?
>
>
>
> Thank you,
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170322/cea959cd/attachment.html>