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.
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
> >>
>
