>> @@ -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
Hi Jeff,
On exit status — you're right, that's cleaner than what I had. DejaGnu's
target_compile only gives you the output text, not the exit code, so I'd wrap
remote_exec during the link step to pick up the status. Use that to decide
pass/fail; the output is just for matching the error message if there's a
Pattern.
On the warnings point — yeah, the comp_output != "" bit was wrong. A link that
succeeds but prints a warning would look like a failure. dg-lto-error should
only fire on a real failed link (non-zero exit). Warnings that don't fail the
link stay on dg-lto-warning / dg-lto-message like today.
This patch was mainly so I could test the APEX LTO work in 717917 [0]:
dg-lto-error for the cross-TU conflict cases, scan-ltrans-assembler for
checking ltrans output. Richard Biener had some concerns on that side, so the
APEX LTO approach may still change — I'm not sure yet what the final shape
will be. I'll hold off on a v2 until the APEX side settles.
Thanks,
Luis
[0] https://gcc.gnu.org/pipermail/gcc-patches/2026-May/717917.html
