On 15/11/2024 10:15, Christophe Lyon wrote:
> On Thu, 14 Nov 2024 at 18:33, Torbjorn SVENSSON
> <torbjorn.svens...@foss.st.com> wrote:
>>
>>
>>
>> On 2024-11-14 16:53, Christophe Lyon wrote:
>>> On Sun, 10 Nov 2024 at 17:44, Torbjörn SVENSSON
>>> <torbjorn.svens...@foss.st.com> wrote:
>>>>
>>>> Ok for trunk and releases/gcc-14?
>>>>
>>>> --
>>>>
>>>> When the feature "needs_status_wrapper" in dejagnu is used, the
>>>> resulting gcc_tg.o file is a regular object file and thus the following
>>>> warning will be emitted if doing an incremental link:
>>>>
>>>> .../ld: warning: incremental linking of LTO and non-LTO objects; using
>>>> which will bypass whole program optimization
>>>>
>>>> Since the warning causes test cases, like pr61123-enum-size, to fail,
>>>> prune it.
>>>
>>> This makes sense. Just to be sure that -flinker-output=nolto-rel does
>>> not avoid the problem described in PR61123,
>>> any chance you could try revering SVN r211832 (well just remove "LTO"
>>> from short-enums entry in c.opt) and see the original bug with the
>>> warning (pruned)?
>>
>> If I build r15-5047-g7e1d9f58858 with the following change (I obviously
>> have my patch applied when testing it...):
>>
>> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
>> index 9b9f5e744f6..80d934b516d 100644
>> --- a/gcc/c-family/c.opt
>> +++ b/gcc/c-family/c.opt
>> @@ -2277,7 +2277,7 @@ C++ ObjC++ Optimization Var(flag_rtti) Init(1)
>> Generate run time type descriptor information.
>>
>> fshort-enums
>> -C ObjC C++ ObjC++ LTO Optimization Var(flag_short_enums)
>> +C ObjC C++ ObjC++ Optimization Var(flag_short_enums)
>> Use the narrowest integer type possible for enumeration types.
>>
>> fshort-wchar
>>
>>
>>
>> For Cortex-A7, Cortex-M0/3/4/7/33/55/85, I get the following failure:
>>
>> FAIL: object-readelf Tag_ABI_enum_size size is incorrect.
>>
>> I suppose this is what you wanted to get confirmed, right?
>>
>> We could, instead of pruning, add the -flonker-output=nolto-rel, but
>> that fails to link as there is no main function etc.
>>
>> I'm not sure that this answers you question, so if it's not what you had
>> in mind, please let me know. :)
>>
>
> Yes exactly: I wanted to make sure that we'd still have caught the
> original bug even when using the status_wrapper (and that
> -flinker-output=nolto-rel didn't have the side effect of hiding the
> bug).
>
> Thanks for the clarification.
I wonder if we could address this by building the wrapper as a fat LTO object.
It would then be compatible with both LTO and non-LTO compilations.
We could experiment with this by setting [target_info wrap_compile_flags] to
return "-flto -ffat-lto-objects".
R.
>
> Christophe
>
>>
>> Kind regards,
>> Torbjörn
>>
>>>
>>> Thanks,
>>>
>>> Christophe
>>>
>>>>
>>>> gcc/testsuite/ChangeLog:
>>>>
>>>> * gcc.target/arm/lto/lto.exp: Prune incremental link warning if
>>>> status wrapper is used.
>>>>
>>>> Signed-off-by: Torbjörn SVENSSON <torbjorn.svens...@foss.st.com>
>>>> ---
>>>> gcc/testsuite/gcc.target/arm/lto/lto.exp | 9 +++++++++
>>>> 1 file changed, 9 insertions(+)
>>>>
>>>> diff --git a/gcc/testsuite/gcc.target/arm/lto/lto.exp
>>>> b/gcc/testsuite/gcc.target/arm/lto/lto.exp
>>>> index 4ccb0737253..3f8377bdd3e 100644
>>>> --- a/gcc/testsuite/gcc.target/arm/lto/lto.exp
>>>> +++ b/gcc/testsuite/gcc.target/arm/lto/lto.exp
>>>> @@ -43,6 +43,14 @@ if { ![check_effective_target_lto] } {
>>>> return
>>>> }
>>>>
>>>> +# This variable should only apply to tests called in this exp file.
>>>> +global dg_runtest_extra_prunes
>>>> +set dg_runtest_extra_prunes ""
>>>> +if { ![check_effective_target_unwrapped] } {
>>>> + # The status wrapper is a regular object file
>>>> + lappend dg_runtest_extra_prunes "warning: incremental linking of LTO
>>>> and non-LTO objects"
>>>> +}
>>>> +
>>>> gcc_init
>>>> lto_init no-mathlib
>>>>
>>>> @@ -60,4 +68,5 @@ foreach src [lsort [find $srcdir/$subdir *_0.c]] {
>>>> lto-execute $src $sid
>>>> }
>>>>
>>>> +set dg_runtest_extra_prunes ""
>>>> lto_finish
>>>> --
>>>> 2.25.1
>>>>
>>
