On 5/12/2026 4:34 AM, Luis Silva wrote: > The LTO testsuite lacked support for testing expected link-time errors and > examining assembly output from the ltrans phase. This made it difficult to > write tests for LTO features that detect conflicts at link time or need to > verify code generation in specific LTRANS units. > > This patch adds two capabilities to the LTO testsuite: > > The dg-lto-error directive allows tests to specify expected link-time errors. > When present, lto.exp expects the link to fail and marks the test as PASS if > it > fails with matching diagnostics, or FAIL if the link unexpectedly succeeds. > This parallels the existing dg-lto-warning and dg-lto-message directives. > > The new scan-ltrans-assembler procedures provide a way to examine the assembly > output (.ltrans*.s files) generated during the ltrans phase. The > scan-ltrans-assembler procedure checks for pattern presence, while > scan-ltrans-assembler-times verifies exact occurrence counts. > > Future patches will make use of this support for link-time diagnostics and > ltrans code generation testing. > > gcc/testsuite/ChangeLog: > > * lib/lto.exp (lto-link-and-maybe-run): Add dg_lto_has_error > handling to expect link failures when dg-lto-error is present. > Pass test when link fails as expected, fail when link succeeds > despite errors. > (lto-can-handle-directive): Add dg-lto-error to recognized > directive list. > (lto-execute-1): Initialize dg_lto_has_error flag. > * lib/scanltrans.exp (scan-ltrans-assembler): New procedure to > scan for patterns in .ltrans*.s assembly files. > (scan-ltrans-assembler-times): New procedure to verify pattern > count across all ltrans assembly files. > * g++.dg/lto/scan-ltrans-asm-1_0.C: New test. > * g++.dg/lto/scan-ltrans-asm-1_1.C: New test. > * gcc.dg/lto/dg-lto-error-1_0.c: New test. > * gcc.dg/lto/dg-lto-error-1_1.c: New test. > * gcc.dg/lto/dg-lto-error-2_0.c: New test. > * gcc.dg/lto/dg-lto-error-2_1.c: New test. > * gcc.dg/lto/scan-ltrans-asm-1_0.c: New test. > * gcc.dg/lto/scan-ltrans-asm-1_1.c: New test. > > Signed-off-by: Luis Silva <[email protected]> > > diff --git a/gcc/testsuite/lib/lto.exp b/gcc/testsuite/lib/lto.exp > index 64b7d992272..fdaecf4decf 100644 > --- a/gcc/testsuite/lib/lto.exp > +++ b/gcc/testsuite/lib/lto.exp > > @@ -419,6 +420,54 @@ proc lto-link-and-maybe-run { testname objlist dest > optall optfile optstr } { > # Prune unimportant visibility warnings before checking output. > set comp_output [lto_prune_warns $comp_output] > > + # Handle dg-lto-error: expect link failure and check pattern if > specified. > + if { [info exists dg_lto_has_error] && $dg_lto_has_error } { > + verbose "lto.exp: dg-lto-error present, expecting link failure" 2 > + set link_failed [expr {![file_on_host exists $dest] || $comp_output != > ""}] So this seems like an indirect way to test for link failure. Would it make more sense to capture the process exit status and check that?
It would also seem to do the wrong thing in the linker emitted warnings rather than fatal errors. Though maybe this is desired behavior (I can imagine scenarios where we might want to check for such diagnostics). In which case all we have here would be poor naming since we're not really looking for hard errors, but instead any linker diagnostic. It's overall pretty sensible to the extent I do TCL/dejagnu with any regularity. I'm inclined to ACK once we nail down the two questions above. jeff
