Hi Segher,
Thanks for the comments!
on 2022/7/22 06:09, Segher Boessenkool wrote:
> On Wed, Jul 20, 2022 at 05:32:01PM +0800, Kewen.Lin wrote:
>> As the failure of test case gcc.target/powerpc/pr92398.p9-.c in
>> PR106345 shows, some test sources for some powerpc effective
>> targets use empty translation unit wrongly. The test sources
>> could go with options like "-ansi -pedantic-errors", then those
>> effective target checkings will fail unexpectedly with the
>> error messages like:
>>
>> error: ISO C forbids an empty translation unit [-Wpedantic]
>>
>> This patch is to fix empty TUs with one dummy variable definition
>> accordingly.
>
> You can also use
> enum{a};
> which is shorter, but more importantly does not generate any code.
> You can also do
> extern int dummy;
> of course -- same idea, no definitions, only declarations.
>
The used "int dummy" follows some existing practices, IMHO in this
context it doesn't matter that it will generate code or not, any of
these alternatives still generates an assembly or object file, but
the generated file gets removed after the checking.
May I still keep this "int dummy" to align with existing practices?
>> I'll push this soon if no objections.
>
>> @@ -6523,6 +6531,7 @@ proc check_effective_target_ppc_float128 { } {
>> #ifndef __FLOAT128__
>> nope no good
>> #endif
>> + int dummy;
>
> At least put it in #else then? Or just do things a bit more elegantly
> (do a dummy function around this for example).
>
OK, since it can still emit error even without "#else", I didn't bother
to add it. I will add it, and update the "nope no good" to "#error
doesn't have float128 support".
BR,
Kewen
