On Tue, 30 Aug 2016, Uros Bizjak wrote: > IIUC, trying to solve this issue in the front-end would bring us to > float->double promotion rules for variable arguments. The compiler > doesn't convert va-args automatically, it only warns for undefined > situation, e.g.:
No, those would be unchanged. The hook would mean two things: * When generating the call, a promotion is inserted for _Float32 like it would be for float (if that's the appropriate ABI for this case on this architecture). * When expanding va_arg (ap, _Float32) - which is perfectly valid, unlike va_arg (ap, float) - the front end changes the call to look like (_Float32) va_arg (ap, _Float64). > Maybe better way forward would be to introduce a backend hook to > generate target-dependant load of the argument from the save area. > This way, it would be possible to emit some kind of builtin that > expands to some RTX sequence. Sure, if you can make the back end do the right thing so that plain __builtin_va_arg (ap, _Float32) works without the front end needing to change the type and insert a promotion at the call site and a conversion back to _Float32 at the va_arg site, that's even better. -- Joseph S. Myers jos...@codesourcery.com
