[llvm-bugs] [Bug 27853] New: incompatibility w/gcc re: ODR, template instantiation, optimization across translation units

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=27853

            Bug ID: 27853
           Summary: incompatibility w/gcc re: ODR, template instantiation,
                    optimization across translation units
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: wallstprog at gmail.com
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 16403
  --> https://llvm.org/bugs/attachment.cgi?id=16403&action=edit
demonstration of described behavior

We've noticed a major incompatability between clang & gcc in the way that
template classes are instantiated when optimization is in effect across
multiple translation units.

There's not much to be found in a Google search, but this post
(https://whatofhow.wordpress.com/2015/03/17/odr-rtti-dso/) seems to suggest
that this incompatibility is intentional.  

This recently bit us with code similar to attached, which was attempting to
define a single using a local static object.  The code works as expected with
g++ (4.3.3, 4.8.2, 5.3.0) at all optimization levels.  Also works as expected
with clang at -O0, but at -O3 the instance() method (and associated local
static) appear to be inlined, which appears to violate ODR(?).  The results are
consistent with clang 3.7.0, trunk(r264914) and trunk(r269323).

The results of running the attached code with different compilers and
optimization levels:

$ CXX=g++ ./test.sh -O0
test1.so:0000000000000717 W Singleton<Test>::instance()
test2.so:0000000000000717 W Singleton<Test>::instance()
test1.so:0000000000200a80 u Singleton<Test>::instance()::obj
test2.so:0000000000200a80 u Singleton<Test>::instance()::obj
$ CXX=g++ ./test.sh -O1
test1.so:0000000000200910 u Singleton<Test>::instance()::obj
test2.so:0000000000200910 u Singleton<Test>::instance()::obj
$ CXX=g++ ./test.sh -O2
test1.so:0000000000200910 u Singleton<Test>::instance()::obj
test2.so:0000000000200910 u Singleton<Test>::instance()::obj
$ CXX=g++ ./test.sh -O3
test1.so:0000000000200910 u Singleton<Test>::instance()::obj
test2.so:0000000000200910 u Singleton<Test>::instance()::obj
$ CXX=clang++ ./test.sh -O0
test1.so:0000000000000770 W Singleton<Test>::instance()
test2.so:0000000000000770 W Singleton<Test>::instance()
test1.so:0000000000200af0 V Singleton<Test>::instance()::obj
test2.so:0000000000200af0 V Singleton<Test>::instance()::obj
$ CXX=clang++ ./test.sh -O1
test1.so:0000000000000740 W Singleton<Test>::instance()
test2.so:0000000000000740 W Singleton<Test>::instance()
test1.so:0000000000200a90 V Singleton<Test>::instance()::obj
test2.so:0000000000200a90 V Singleton<Test>::instance()::obj
$ CXX=clang++ ./test.sh -O2
$ CXX=clang++ ./test.sh -O3
$

So, I have the following questions:
- Is this behavior intended?
- Is this behavior correct?

Any references to rationale for this discrepancy would be much appreciated.

Thanks!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160524/faf5b33c/attachment.html>