On 2025-02-27 16:36, Richard Earnshaw wrote:
On 17/12/2024 15:04, Richard Earnshaw (lists) wrote:
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".
After discussing this on IRC I pushed a different patch. Since the warning
we're trying to prune tells us what it's falling back to, we might as well just
tell it to do that anyway, then we won't get the warning.
R.
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/676548.html
I just tested this approach and it works fine for me.
Thanks for fixing it Richard!
Kind regards,
Torbjörn
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
