On 13 January 2017 at 13:26, Renlin Li <renlin...@foss.arm.com> wrote: > Hi Christophe, > > > On 13/01/17 11:14, Christophe Lyon wrote: >> >> On 13 January 2017 at 11:22, Renlin Li <renlin...@foss.arm.com> wrote: >>> >>> Hi Christophe, >>> >>> Thanks for testing the patch! >>> I check the test case gcc.dg/lto/pr54709, it seems the test case is not >>> properly written. >>> >>> It add extra ld option -shared without checking the target support for >>> that. >>> After the change, this compilation will fail as a regression. >>> IIUC, '-shared' option is required, it should be gated with corresponding >>> target selector. >>> >>> "g++.dg/ipa/devirt-28a.C" now is skipped because of the target selector >>> there. >>> // { dg-do link { target { { gld && fpic } && shared } } } >>> >>> perhaps "gcc.dg/lto/pr54709" should do similar things like this: >>> // { dg-do link { target { shared } } } >> >> Quite likely, indeed. >> >>> >>> >>> As far as I know, with different cpu/arch configurations, different >>> relocations are generated in the library, some of the relocations are not >>> allowed to be used in shared >>> object. >>> >>> With -march=armv7-a (and the --with-cpu=cortex-a9 option you mentioned), >>> the >>> linking stage of the test will fail because of this error: >>> "relocation XXX against external symbol `YYY' can not be used when making >>> a >>> shared object" >>> for instance: crtbegin.o: relocation R_ARM_MOVW_ABS_NC against `a local >>> symbol` can not be used when making a shared object; recompile with -fPIC >>> >>> If you are luck enough, for example with arm7tdmi cpu, no such relocation >>> is >>> generated in startup files. The "shared" target support check will pass >>> for >>> simple and naive code. >>> "--with-cpu=cortex-m3" should be this case. But the test cases which >>> require >>> shared object support will fail. >>> >>> >>> So this "shared" target checking mechanism is not reliable. The patch is >>> to >>> change this. >>> >> Shouldn't your patch imply that several tests move from "fail" to >> "unsupported" on armv7-a ? I'm surprised not to see any difference in the >> results. >> >>> > > Oops, I reordered the explanation paragraphs in my last email, making it > obscure. > > The "shared" target check will fail on armv7-a architecture because of the > reason > mentioned below. So they are already been ignored. After the change, they > are still > marked as "unsupported", but with a different reason. "crtbeginS.o cannot be > found" > > The deja-gnu test framework will compose a small program to test whether the > toolchain > supports "shared" option. > >>> With -march=armv7-a (and the --with-cpu=cortex-a9 option you mentioned), >>> the >>> linking stage of the test will fail because of this error: >>> "relocation XXX against external symbol `YYY' can not be used when making >>> a >>> shared object" >>> for instance: crtbegin.o: relocation R_ARM_MOVW_ABS_NC against `a local >>> symbol` can not be used when making a shared object; recompile with -fPIC >>> > > So the check won't pass, and the test case is marked as "unsupported". > >>> If you are luck enough, for example with arm7tdmi cpu, no such relocation >>> is >>> generated in startup files. The "shared" target support check will pass >>> for >>> simple and naive code. >>> "--with-cpu=cortex-m3" should be this case. But the test cases which >>> require >>> shared object support will fail. > > So for the same test case, > With "--with-cpu=cortex-m3", > The "shared" target support check will pass. It is marked as supported, but > fail to produce binary. > with --with-cpu=cortex-a9", > The "shared" target support check will fail. it is marked as "unsupported" > and skipped. > > After the change, the test case will marked as "unsupported" regardless of > the > cpu/arch configuration. > OK thanks for the clarification.
> Regards, > Renlin