[PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

Multilib testing on trunk is currently busted (and surprisingly this affects any/all targets but it seems nobody cares). We currently get the following splat: | ERROR: tcl error code NONE | ERROR: torture-init: torture_without_loops is not empty as expected And this takes down pretty much all of

Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

On 5/31/23 10:25, Vineet Gupta wrote: Multilib testing on trunk is currently busted (and surprisingly this affects any/all targets but it seems nobody cares). We currently get the following splat: I wouldn't say that nobody cares, it just hasn't bubbled up on anyone's priority list yet (most

Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

> On 31 May 2023, at 18:57, Jeff Law via Gcc-patches > wrote: > > > > On 5/31/23 10:25, Vineet Gupta wrote: >> Multilib testing on trunk is currently busted (and surprisingly this >> affects any/all targets but it seems nobody cares). We currently get the >> following splat: > I wouldn't sa

Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

On 5/31/23 10:57, Jeff Law wrote: On 5/31/23 10:25, Vineet Gupta wrote: Multilib testing on trunk is currently busted (and surprisingly this affects any/all targets but it seems nobody cares). We currently get the following splat: I wouldn't say that nobody cares, it just hasn't bubbled up

Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

On 5/31/23 11:13, Iain Sandoe wrote: I do have a multilib problem [with libgomp] on Darwin (which has been noticed :https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951) but it is not obvious how the fix proposed would solve this - unless it’s some subtle change in global content for the mult

Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

Hi! First, Vineet, great that you've now tracked this down! :-) Indeed "early exit" vs. 'torture-finish' was exactly the issue that I suspected. It may not be what you originally intended, but I hope at least you've learned some things about DejaGnu/TCL... ;-P Yesterday, I actually had begun l

Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

Hi! On 2023-06-01T09:24:20+0200, I wrote: > First, Vineet, great that you've now tracked this down! :-) Indeed > "early exit" vs. 'torture-finish' was exactly the issue that I suspected. > > It may not be what you originally intended, but I hope at least you've > learned some things about DejaGnu

Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

On 6/1/23 01:24, Thomas Schwinge wrote: But probably more importantly, this problem seems to not be triggering on all multilib targets. For example, I just examined my tester's build logs and couldn't see this on the H8/300 or V850 ports. Which begs the question, why? ..., which may b

Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

On 5/31/23 10:25, Vineet Gupta wrote: Multilib testing on trunk is currently busted (and surprisingly this affects any/all targets but it seems nobody cares). We currently get the following splat: | ERROR: tcl error code NONE | ERROR: torture-init: torture_without_loops is not empty as expect