On 5/30/23 11:43, Vineet Gupta wrote:
On 5/26/23 16:38, Vineet Gupta wrote:
On 5/25/23 13:26, Thomas Schwinge wrote:
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".
The full log files are humongous - even xz compressed is ~ 7 MB - how
can I share that w/o the list dropping it.
I guess I can try emailing it you directly on work email - if that's OK.
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".
Seems likely. So back to good old printf style debugging: I added
dumping of the dup options to see what exactly was leaking.
setup #1
- riscv.exp: Added torture-init/finish
- Deleted rvv.exp (to isolate the problem)
...
Setup #2
- riscv.exp: Added torture-init/finish
- riscv.exp: commented away ADDITIONAL_TORTURE_OPTIONS line
- rvv.exp remains, unchanged
...
In the 3rd setup, I've removed riscv.exp and rvv.exp and running the
testsuite: errors still show.
So we are iterating over multilib combinations.
Things are fine for the first one. The initial flags comprise of
DG_TORTURE_OPTIONS from gcc-dg.exp (-O0, -O1 ....)
However when the 2nd multilib runs, it seems the old ones are not
getting cleared, hence the splat.
I've posted the fix [1] . printf/send_user() to the rescue !
@Thomas I fat fingered the send and missed CC'ing you on the patches.
Thx,
-Vineet
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620263.html
