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 looking into this. To avoid the big download and having to wait for a lot of packages to be build with your 'riscv-gnu-toolchain' recipe: <https://inbox.sourceware.org/44506218-70bd-0b7b-a560-744bb2437...@rivosinc.com>, I intended to do just a quick GCC build on compile farm gcc92, which (a) didn't turn out to be quick, and (b) eventually failed due to <https://gcc.gnu.org/PR106271> "Bootstrap on RISC-V on Ubuntu 22.04 LTS: bits/libc-header-start.h: No such file or directory"... (I'm now running 'riscv-gnu-toolchain' to verify this, and another thing.) Before we push your patch, let me please verify that it indeed doesn't change any 'gcc.misc-tests/i386-prefetch.exp' semantics, and: On 2023-05-31T19:13:01+0100, Iain Sandoe via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: >> On 31 May 2023, at 18:57, Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> >> 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 on anyone's >> priority list yet (most developers aren't working on targets that make heavy >> use of multilibs). So I regularely do build x86_64 GNU/Linux with default '-m64' plus '-m32' multilib -- but of course, there's no "early exit" for those, as there's no 'string match "* -march=*" " [board_info target multilib_flags] "'... >> 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 be the case for those, too? In other words: the problem only shows up if '-march=[...]' appears in the flags, which indeed may not be a common thing? I'll cross-verify this with x86_64 and '-march=[...]' flags. And, I still intend to figure out why this issue apparently disappears with my recent 'LTO_TORTURE_OPTIONS' patches reverted: <https://inbox.sourceware.org/ad8a98da-0231-7a95-017b-ea5d8ae65...@rivosinc.com>. Otherwise: > 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 multilib options. > > (testing anyway) No, this is really a separate issue. I understand what's happening, and have an idea about how to address this that I'll post later. 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
