On Jun 9, 2020, Iain Sandoe <idsan...@googlemail.com> wrote: > That means that the intermediate objects proceed all the way to .s > output - and thus the ‘final’ pass is run (producing the extra files seen).
> You can mimic this with x86 Linux by appending -ffat-lto-objects to an > LTO command line. I see, thanks. > I have an ugly patch that makes this work for Darwin (essentially, by > having two versions of the LTO tests We could deal with that in a similar way to how .dwo files are handled, namely, with explicit handling in the main test procedure. Or, even better, we could introduce an alternate syntax, using a nested list/pair with condition and file, that would require the file only if the condition holds. This could then be used for dwo, for lto, and possibly for other situations. > and I was wondering (as an aside) if the -ffat-lto-objects case should > be tested on targets which default to thin LTO anyway? The purpose of this testset was to check the new aux and dump file naming was implemented correctly. I don't see that -ffat-lto-objects adds to that: it just runs the compilation phase of an lto build all the way to the end and thus creating dump files for passes that would otherwise be skipped. Alas, some of the naming logic is only exercised when certain features are present/enabled, so expanding the testset to cover those when required conditions are met is in line with the original purpose. Thus dwo conditionals, lto with or without plugin, (missing) offloading target testing, ... [insert other unforeseen issues here] :-) All that said, I don't object to putting this test machinery to other uses (hey!, it's Free Software! :-), so if you feel that would be useful, let's go for it. -- Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo/ Free Software Evangelist Stallman was right, but he's left :( GNU Toolchain Engineer Live long and free, and prosper ethically
