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