Hi!
On 2023-05-24T15:13:19-0700, Vineet Gupta <vine...@rivosinc.com> wrote:
> On 5/24/23 13:34, Thomas Schwinge wrote:
>> Yeah, at this point I'm not sure whether my recent changes really are
>> related/relevant here.
>>
>>> Apparently in addition to Kito's patch below, If I comment out the
>>> additional torture options, failures go down drastically.
>> Meaning that *all* those ERRORs disappear?
>
> No but they reduced significantly. Anyhow I think the issue should be
> simple enough for someone familiar with how the tcl stuff works...
I'm here to help -- but you'll have to help me to help you, please.
>>> diff --git a/gcc/testsuite/gcc.target/riscv/riscv.exp
>>> b/gcc/testsuite/gcc.target/riscv/riscv.exp
>>>
>>> -lappend ADDITIONAL_TORTURE_OPTIONS {-Og -g} {-Oz}
>>> +#lappend ADDITIONAL_TORTURE_OPTIONS {-Og -g} {-Oz}
>>>
>>> @Thomas, do you have some thoughts on how to fix riscv.exp properly in
>>> light of recent changes to exp files.
>> I'm trying to understand this, but so far don't. Can I please see a
>> complete 'gcc.log' file where the ERRORs are visible?
> So we are at bleeding edge gcc from today
> 2023-05-24 ec2e86274427 Fortran: reject bad DIM argument of SIZE
> intrinsic in simplification [PR104350]
>
> With an additional fix from Kito along the lines of..
>
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/rvv.exp
> b/gcc/testsuite/gcc.target/riscv/rvv/rvv.exp
>
> dg-init
> +torture-init
>
> # All done.
> +torture-finish
> dg-finish
That shouldn't be necessary here?
> I'm pasting a snippet of gcc.log. Issue is indeed triggered by rvv.exp
> which needs some love.
I'd intentionally asked to "see a complete 'gcc.log' file where the
ERRORs are visible".
On 2023-05-24T16:12:20-0700, Vineet Gupta <vine...@rivosinc.com> wrote:
> On 5/24/23 15:13, Vineet Gupta wrote:
>>
>> PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
>> -fno-fat-lto-objects (test for excess errors)
>> PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
>> -fno-fat-lto-objects scan-assembler-times mul\t 1
>> PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
>> -fno-fat-lto-objects scan-assembler-not div\t
>> PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
>> -fno-fat-lto-objects scan-assembler-not rem\t
>> testcase
>> /scratch/vineetg/gnu/toolchain-upstream/gcc/gcc/testsuite/gcc.target/riscv/riscv.exp
>>
>> completed in 60 seconds
>> Running
>> /scratch/vineetg/gnu/toolchain-upstream/gcc/gcc/testsuite/gcc.target/riscv/rvv/rvv.exp
>>
>> ...
>> ERROR: tcl error sourcing
>> /scratch/vineetg/gnu/toolchain-upstream/gcc/gcc/testsuite/gcc.target/riscv/rvv/rvv.exp.
>> ERROR: tcl error code NONE
>> ERROR: torture-init: torture_without_loops is not empty as expected
I'd seen this before, in your earlier emails.
> Never mind. Looks like I found the issue - with just trial and error and
> no idea of how this stuff works.
Instead of "magic", let's please try to properly work this out.
> The torture-{init,finish} needs to be in riscv.exp not rvv.exp
> Running full tests now.
I still don't understand this.
My current theory would be that some other '*.exp' file runs
'torture-init' and then prematurely ends without 'torture-finish', and
thus the torture testing state bleeds into the next '*.exp' file(s). I'd
hoped that I could pinpoint that via "a complete 'gcc.log' file where the
ERRORs are visible".
Grüße
Thomas
