diff mbox

Fix 70278 (LRA split_regs followup patch)

Message ID CAKdteObLoHHfMzzrPz4qOfHp+OJC25wQgJyZmX3txTQhconu9Q@mail.gmail.com
State New
Headers show

Commit Message

Christophe Lyon March 22, 2016, 9:24 a.m. UTC 
On 18 March 2016 at 17:51, Jeff Law <law@redhat.com> wrote:
> On 03/18/2016 06:25 AM, Bernd Schmidt wrote:
>>
>> This fixes an oversight in my previous patch here. I used biggest_mode
>> in the assumption that if the reg was used in the function, it would be
>> set to something other than VOIDmode, but that fails if we have a
>> multiword access - only the first hard reg gets its biggest_mode
>> assigned in that case.
>>
>> Bootstrapped and tested on x86_64-linux, ran (just) the new arm testcase
>> manually with arm-eabi. Ok?
>>
>> (The testcase seems to be from glibc. Do we keep the copyright notices
>> on the reduced form)?
>
> I don't recall specific guidance on including the copyright notice on a
> reduced/derived test.
>
> Given the actual copyright on the original code, ISTM the safest thing to do
> is keep the notice intact.
>
> A long long time ago I receive guidance from the FSF WRT what could be
> included in the testsuite -- unfortunately I didn't keep that message. I
> probably should have.
>
>>
>> Bernd
>>
>> 70278.diff
>>
>>
>>         PR rtl-optimization/70278
>>         * lra-constraints.c (split_reg): Handle the case where
>> biggest_mode is
>>         VOIDmode.
>>
>> testsuite/
>>         * gcc.dg/torture/pr70278.c: New test.
>>         * gcc.target/arm/pr70278.c: New test.
>

The ARM test isn't sufficiently protected against non-compliant configurations,
and fails if GCC is configured for arm*linux-gnueabihf for instance
(see http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/234342/report-build-info.html)

The attached small patch fixes that by requiring arm_arch_v4t_multilib
effective target.

I used arm_arch_v4t_multilib instead of arm_arch_v4t because, as I
reported a long time ago
the later does not complain in some unsupported configuration because
the sample effective
target test does not contain actual code. In particular it's not
sufficient to reject thumb-1 with
hard-float.

OK?

Thanks,

Christophe.

> OK.
> jeff
>
2016-03-22  Christophe Lyon  <christophe.lyon@linaro.org>

	* gcc.target/arm/pr70278.c: Require arm_arch_v4t_multilib
	effective target.

Comments

Bernd Schmidt March 22, 2016, 12:14 p.m. UTC | #1 
On 03/22/2016 10:24 AM, Christophe Lyon wrote:
>
> The ARM test isn't sufficiently protected against non-compliant configurations,
> and fails if GCC is configured for arm*linux-gnueabihf for instance
> (see http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/234342/report-build-info.html)
>
> The attached small patch fixes that by requiring arm_arch_v4t_multilib
> effective target.
>
> I used arm_arch_v4t_multilib instead of arm_arch_v4t because, as I
> reported a long time ago
> the later does not complain in some unsupported configuration because
> the sample effective
> target test does not contain actual code. In particular it's not
> sufficient to reject thumb-1 with
> hard-float.
>
> OK?

No objections from me, but I copied all this from the existing testcase 
ftest-armv4t-thumb.c, so I'm puzzled why that one doesn't fail.


Bernd
Christophe Lyon March 22, 2016, 1:03 p.m. UTC | #2 
On 22 March 2016 at 13:14, Bernd Schmidt <bschmidt@redhat.com> wrote:
> On 03/22/2016 10:24 AM, Christophe Lyon wrote:
>>
>>
>> The ARM test isn't sufficiently protected against non-compliant
>> configurations,
>> and fails if GCC is configured for arm*linux-gnueabihf for instance
>> (see
>> http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/234342/report-build-info.html)
>>
>> The attached small patch fixes that by requiring arm_arch_v4t_multilib
>> effective target.
>>
>> I used arm_arch_v4t_multilib instead of arm_arch_v4t because, as I
>> reported a long time ago
>> the later does not complain in some unsupported configuration because
>> the sample effective
>> target test does not contain actual code. In particular it's not
>> sufficient to reject thumb-1 with
>> hard-float.
>>
>> OK?
>
>
> No objections from me, but I copied all this from the existing testcase
> ftest-armv4t-thumb.c, so I'm puzzled why that one doesn't fail.
>

It's similar to why I tried to explain above: ftest-armv4t-thumb.c contains
only preprocessor tests, no actual code.

When the program contains code (or even a single global variable definition),
the compiler complains that" Thumb-1 hard-float VFP ABI" is not
implemented.

A long time ago, I submitted a patch to add some code to the
arm_arch_FUNC_ok effective target, but it was not accepted.

Christophe.

>
> Bernd
diff mbox

Patch

diff --git a/gcc/testsuite/gcc.target/arm/pr70278.c b/gcc/testsuite/gcc.target/arm/pr70278.c
index c44c07b..889f626 100644
--- a/gcc/testsuite/gcc.target/arm/pr70278.c
+++ b/gcc/testsuite/gcc.target/arm/pr70278.c
@@ -2,6 +2,7 @@ 
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-march=*" } { "-march=armv4t" } } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" } { "" } } */
 /* { dg-options "-mthumb" } */
+/* { dg-require-effective-target arm_arch_v4t_multilib } */
 /* { dg-add-options arm_arch_v4t } */
 /*
  * ====================================================