[cfe-users] ABI change with unused function argument

Gael Guennebaud gael.guennebaud at gmail.com
Mon Feb 24 09:36:54 PST 2014

If you have libsuitesparse installed, then that's easy to reproduce,
otherwise this will take me some times to prepare a selfcontained

hg clone http://bitbucket.org/eigen/eigen
cd eigen
hg up ee16e48
mkdir build
cd build
CXX=clang++ cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
cd test
make cholmod_support_1 -j 4 && ./cholmod_support_1

This triggers and assertion, and running cholmod_support_1 into
valgrind will more clearly show the problem.

In the meantime, we found that using a template function like this:

template<class T> void ignore( const T& ) { }

to discard unused variable warnings also fixed this aggressive
optimization issue. However this solution seems hazardous because the
other tricks did not work, that is:
a = a;
a += 0;


On Mon, Feb 24, 2014 at 6:18 PM, David Blaikie <dblaikie at gmail.com> wrote:
> Clang should only be doing this to internal symbols (or it should be making
> the symbol internal so it can perform such an optimization). Do you have a
> standalone (at least complete, ideally minimal) example of this issue?
> On Mon, Feb 24, 2014 at 8:58 AM, Gael Guennebaud <gael.guennebaud at gmail.com>
> wrote:
>> Hi,
>> I've observed that clang changes the ABI when a function argument is not
>> used.
>> This is a nice optimization, but the downside is that this introduces
>> segfaults when an argument is conditionally used with respect to
>> compilation options (e.g., -DNDEBUG) and that both the application and
>> a library instantiate this function, but only one is compiled with
>> Here is an example of how could look like such a function:
>> template<int A, typename T>
>> void foo(int a, T &t) {
>>   assert(A!=0 || a==0);
>>   if(A==0) { /* code making use of both a and t */ }
>>   else { /* code making use of t and A only */ }
>> }
>> and you can see a real-world example with a very ugly workaround there:
>> https://bitbucket.org/eigen/eigen/commits/1e19a9cb83f0/
>> Does clang proposes a cleaner and more general workaround for such an
>> issue?
>> Thanks,
>> Gael
>> _______________________________________________
>> cfe-users mailing list
>> cfe-users at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-users

More information about the cfe-users mailing list