On Thu, Oct 26, 2023 at 12:48 PM Christophe Lyon <christophe.l...@linaro.org> wrote: > > On Thu, 26 Oct 2023 at 18:18, Lewis Hyatt <lhy...@gmail.com> wrote: > > > > On Thu, Oct 26, 2023 at 4:49 AM Christophe Lyon > > <christophe.l...@linaro.org> wrote: > > > We have noticed that the new tests fail on aarch64 with: > > > .../aarch64-unknown-linux-gnu/libc/usr/lib/crt1.o: in function `_start': > > > .../sysdeps/aarch64/start.S:110:(.text+0x38): undefined reference to > > > `main' > > > > > > Looking at the test, I'd say it lacks a dg-do compile (to avoid > > > linking), but how does it work on other targets? > > > > Thanks for pointing it out. I am definitely under the impression that > > { dg-do compile } is the default and doesn't need to be specified, I > > have never seen it not be the case before... Is that just not correct? > > I tried it out on the cfarm (gcc185) for aarch64-redhat-linux and it > > works for me there too, I tried the test individually and also as part > > of the whole check-gcc-c++ target. > > > > I do see that there are target-dependent functions in > > testsuite/lib/*.exp that will change dg-do-what-default under some > > circumstances... but I also see in dg-pch.exp (which is the one > > relevant for this test g++.dg/pch/pr36887.C) that dg-do-what-default > > is set to compile explicitly. > > Indeed, thanks for checking. > > > Note sure what the best next step is, should I just add { dg-do > > compile } since it's harmless in any case, or is there something else > > worth looking into here? I'm not sure why I couldn't reproduce the > > issue on the compile farm machine either, maybe you wouldn't mind > > please check if adding this line fixes it for you anyway? Thanks... > > Can you share the compile line for this test in g++.log? >
Sure, here is what I got on aarch64 for make RUNTESTFLAGS=pch.exp=pr36887.C check-gcc-c++ For making the PCH: xg++ -B/dev/shm/lhyatt/build/gcc/testsuite/g++/../../ ./pr36887.H -fdiagnostics-plain-output -nostdinc++ -I/dev/shm/lhyatt/build/aarch64-unknown-linux-gnu/libstdc++-v3/include/aarch64-unknown-linux-gnu -I/dev/shm/lhyatt/build/aarch64-unknown-linux-gnu/libstdc++-v3/include -I/dev/shm/lhyatt/src/libstdc++-v3/libsupc++ -I/dev/shm/lhyatt/src/libstdc++-v3/include/backward -I/dev/shm/lhyatt/src/libstdc++-v3/testsuite/util -fmessage-length=0 -g -o pr36887.H.gch For compiling the test: xg++ -B/dev/shm/lhyatt/build/gcc/testsuite/g++/../../ /dev/shm/lhyatt/src/gcc/testsuite/g++.dg/pch/pr36887.C -fdiagnostics-plain-output -nostdinc++ -I/dev/shm/lhyatt/build/aarch64-unknown-linux-gnu/libstdc++-v3/include/aarch64-unknown-linux-gnu -I/dev/shm/lhyatt/build/aarch64-unknown-linux-gnu/libstdc++-v3/include -I/dev/shm/lhyatt/src/libstdc++-v3/libsupc++ -I/dev/shm/lhyatt/src/libstdc++-v3/include/backward -I/dev/shm/lhyatt/src/libstdc++-v3/testsuite/util -fmessage-length=0 -g -I. -Dwith_PCH -S -o pr36887.s (and then it repeats with -O2 added, or with -g removed as well) > Actually I'm seeing several similar errors in our g++.log, not > reported before because they were "pre-existing" failures. > So something is confusing the testsuite and puts it into link mode. > > I am currently building from scratch, without our CI scripts to get > some additional logs in a setup that probably matches yours. Then I > should be able to add more traces a dejagnu level to understand what's > happening. > > Thanks, > > Christophe