On 03/12/14 15:03, Andrew Stubbs wrote:
>> The tools have always allowed us to drop down the arch to
>> march=armv5te along with using -mfpu=neon. We are now changing command
>> line behaviour, so an inform in terms of diagnostics to the user would
>> be useful as it states that we don't really have mfpu=neon generating
>> neon code any more because of this particular case. If we are to do
>> this then the original patch is probably not enough as it then doesn't
>> handle the case of TARGET_VFP3 / TARGET_VFP5 / TARGET_NEON_FP16 /
>> TARGET_FP16 / TARGET_FPU_ARMV8 etc. etc. etc.
>
> I'll take a look at those shortly.

Or, not so shortly.

It seems that, on ARM, the arch/CPU setting is basically orthogonal to 
the FPU setting, and the compiler doesn't even try to match the one to 
the other. The assembler does the same. In fact, the testcases that 
James refers to, that have hard-coded -march options, really do emit 
armv4 code with Neon, say, although most probably don't have 
vectorizable code. They only work because they're most likely executed 
on Neon hardware.

This means that there's no obvious patch to fix the issue, in the 
compiler. It's easy to reject Neon for pre-v7 CPUs, but that has 
consequences, as we've seen. We'd have to have a table of fall-back FPUs 
or something, and that doesn't seem straight-forward (and anyway, I'm 
not sure what values to enter into that table).

So, I've attacked the problem from the other end, and updated the 
compiler check.

OK to commit?

Andrew