Hi Thomas, On Wed, 10 May 2023 at 09:52, Thomas Schwinge wrote: > Hi Christophe! > > On 2023-05-09T21:14:07+0200, Christophe Lyon > wrote: > > On Tue, 9 May 2023 at 17:17, Christophe Lyon > > > wrote: > >> On Tue, 9 May 2023 at 11:00, Thomas Schwinge > >> wrote: > >>> On 2023-05-09T09:32:55+0200, Christophe Lyon < > christophe.lyon@linaro.org> > >>> wrote: > >>> > On Wed, 3 May 2023 at 13:47, Richard Biener via Gcc-patches < > >>> gcc-patches@gcc.gnu.org> wrote: > >>> >> On Wed, 3 May 2023, Thomas Schwinge wrote: > >>> >> > "Let each 'lto_init' determine the default 'LTO_OPTIONS', and > >>> 'torture-init' the 'LTO_TORTURE_OPTIONS'"? > >>> > > >>> > This is causing issues on arm/aarch64, including: > >>> > > >>> > ERROR: can't read "LTO_TORTURE_OPTIONS": no such variable > >>> > in gcc.target/arm/acle/acle.exp: > >>> > > >>> > ERROR: torture-init: LTO_TORTURE_OPTIONS is not empty as expected > >>> > in gcc.target/aarch64/sls-mitigation/sls-mitigation.exp, > >>> > gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp, > >>> > gcc.target/aarch64/sve2/acle/aarch64-sve2-acle-asm.exp, > >>> > gcc.target/aarch64/torture/aarch64-torture.exp > >>> > > >>> > and maybe others > >>> > > >>> > Are other targets affected too? > >>> > >>> Sorry for that -- it means, the safe-guards I added are working as > >>> expected. > >>> > >>> Please test whether all these issues are gone with the attached > >>> "Testsuite: Add missing 'torture-init'/'torture-finish' around > >>> 'LTO_TORTURE_OPTIONS' usage"? > >> > >> Your patch seemed reasonable, but it doesn't work :-( > >> > >> Well now I get: > >> ERROR: torture-init: LTO_TORTURE_OPTIONS is not empty as expected > >> because gcc-dg-runtest itself calls torture-init > >> > >> but I'm not sure where LTO_TORTURE_OPTIONS is set > > > > Just checking, are you able to test your changes on arm (a cross > toolchain > > is OK) ? > > Sorry, I don't currently have an arm/aarch64 toolchain built. > > > The problem shows up even if running only acle.exp, so it's quick once > you > > have built the toolchain once. > > I did a quick hack: > > --- gcc/testsuite/gcc.target/aarch64/sls-mitigation/sls-mitigation.exp > +++ gcc/testsuite/gcc.target/aarch64/sls-mitigation/sls-mitigation.exp > @@ -22,3 +21,0 @@ > -if {![istarget aarch64*-*-*] } then { > - return > -} > --- gcc/testsuite/gcc.target/arm/acle/acle.exp > +++ gcc/testsuite/gcc.target/arm/acle/acle.exp > @@ -20,3 +19,0 @@ > -if ![istarget arm*-*-*] then { > - return > -} > > ..., and confirm to run into the DejaGnu/TCL ERRORs in my > x86_64-pc-linux-gnu testing. > > > I spent some time looking at it, and the conflict is that the .exp file > > calls torture-init and gcc-dg-runtest, which in turn calls torture-init > > again, leading to the error. > > I see, thanks -- and sorry, once again. > > > I haven't checked the details of why there are similar failures on > aarch64. > > I now understand that the problem is the following: most of all '*.exp' > files have 'torture-init' followed by 'set-torture-options' before > 'gcc-dg-runtest' etc., and therefore don't run into the latter's > "Some callers set torture options themselves; don't override those." > code. Some '*.exp' files however do 'torture-init' but not > 'set-torture-options', and therefore we can't any longer conditionalize > the implicit 'torture-init' by '![torture-options-exist]'. > Please in addition to the earlier > "Testsuite: Add missing 'torture-init'/'torture-finish' around > 'LTO_TORTURE_OPTIONS' usage" > also apply the attached > "Testsuite: Add 'torture-init-done', and use it to conditionalize implicit > 'torture-init'". > That hopefully should restore sanity -- if not, I'll get arm/aarch64 > toolchains built. > > Thanks for the patch, it seems to work! Christophe > > Grüße > Thomas > > > ----------------- > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, > 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: > Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; > Registergericht München, HRB 106955 >