On Thu, 26 Oct 2023 at 19:44, Lewis Hyatt <lhy...@gmail.com> wrote:
>
> 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)
OK, thanks.
Our CI harness adds a few linker options to g++
(-Wl,--dynamic-linker=XXX, -Wl-,-rpath...)
which seem to force the GCC driver to invoke the linker.
So, nothing to fix on the testsuite side ;-)
I'll have a look to check if this is a driver bug, or if it can be
fixed in our scripts.
Sorry for the false alarm,
Christophe
>
> > 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
