Long compile times due mangling of return types in function templates

Avi Kivity avi@cloudius-systems.com
Sun Apr 26 13:33:00 GMT 2015


On 04/26/2015 04:24 PM, Jonathan Wakely wrote:
> On 26 April 2015 at 11:05, Avi Kivity wrote:
>> @@ -526,12 +527,14 @@ public:
>>       }
>>        template <typename Func>
>> -    futurize_t<std::result_of_t<Func(T&&...)>> then(Func&& func) noexcept {
>> +    auto // futurize_t<std::result_of_t<Func(T&&...)>>
>> +    then(Func&& func) noexcept {
>>           return
> This changes the meaning of the code. For the original the function
> will not participate in overload resolution when
> result_of_t<Func(T&&...)> is not a valid type. You have changed that
> so the function can be called with invalid types and might be chosen
> by overload resolution, resulting in a compiler error.
>
> So feel free to do that in your own code if you want to avoid the
> compile-time overhead of SFINAE, but there are very good reasons it
> shouldn't be done in general.

What I don't understand is why the return type is passed to the linker.  
When the compiler is done with the translation unit, either there was 
exactly one overload that survived the compiler's overload resolution 
torture test, or there is no object file at all.

IOW, it is impossible (within ODR) for the linker to see two functions 
that only differ in return types.  So why is the return type encoded in 
the mangled function name, given that it is so detrimental to compile times?

I realize this is an Itanium ABI question, not a gcc question, but I 
don't know of a forum where I can ask questions on the ABI.  And as for 
the second question, are there plans to alleviate the pain somehow?



More information about the Gcc-help mailing list