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.
Regards,
Renlin
