CDImode in reg

CDImode in reg

[Aurelien Buhrig]

Hi,

I'm trying to get the gcc testsuite passing for my new target port.
The last ICE deals with complex long long (gcc.c-torture/compile/20000804-1.c).
My target has 16-bit wide int, and regs can hold DImode max.

code:

  __complex__ long long v;
  asm("": "+r" (v) : "r" (0), "r" (1));

Is such the testcase an expected fail or not ?
Operations on complex are often split into DI operations. But the
target cannot hold a whole CDI into one register, but could hold 2 DI
into 2 distinct DI regs.

If it is an xfail, is there a way handle such a case at higher level
to prevent an ICE and generate a more user friendly error message ?

If it is a fail, I have no idea how to fix this (pb with
init_move_cost(CDImode), with a gcc_assert
(have_regs_of_mode[CDImode]))

Thanks,
Aurélien

Re: CDImode in reg

[Ian Lance Taylor]

Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> writes:

> I'm trying to get the gcc testsuite passing for my new target port.
> The last ICE deals with complex long long (gcc.c-torture/compile/20000804-1.c).

As you can see from the test file, several targets skip this test using
dg-skip-if.

Ian

Re: CDImode in reg

[Aurelien Buhrig]

So it should be skipped and the ICE is the normal behavior for such
irrelevant test cases ?

Thanks for your help,
Aurélien


2011/10/4 Ian Lance Taylor <iant@google.com>:
> Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> writes:
>
>> I'm trying to get the gcc testsuite passing for my new target port.
>> The last ICE deals with complex long long (gcc.c-torture/compile/20000804-1.c).
>
> As you can see from the test file, several targets skip this test using
> dg-skip-if.
>
> Ian
>

Re: CDImode in reg

[Segher Boessenkool]

> So it should be skipped and the ICE is the normal behavior for such
> irrelevant test cases ?

It should be skipped, but no input should ICE the compiler.


Segher

Re: CDImode in reg

[Ian Lance Taylor]

Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> writes:

> So it should be skipped and the ICE is the normal behavior for such
> irrelevant test cases ?

Personally, I don't really think an ICE is ever an acceptable result
from the compiler.  However, there are practical considerations.  Nobody
is ever going to write code like that for your processor.  If gets an
ICE, no real programmer is ever going to notice.  And if it didn't get
an ICE it would get an error instead.  So it's really up to you how much
effort you want to put in to generating a proper error message rather
than an ICE.

Ian


> 2011/10/4 Ian Lance Taylor <iant@google.com>:
>> Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> writes:
>>
>>> I'm trying to get the gcc testsuite passing for my new target port.
>>> The last ICE deals with complex long long (gcc.c-torture/compile/20000804-1.c).
>>
>> As you can see from the test file, several targets skip this test using
>> dg-skip-if.
>>
>> Ian
>>

Re: CDImode in reg

[Aurelien Buhrig]

>> So it should be skipped and the ICE is the normal behavior for such
>> irrelevant test cases ?
>
> Personally, I don't really think an ICE is ever an acceptable result
> from the compiler.  However, there are practical considerations.  Nobody
> is ever going to write code like that for your processor.  If gets an
> ICE, no real programmer is ever going to notice.  And if it didn't get
> an ICE it would get an error instead.  So it's really up to you how much
> effort you want to put in to generating a proper error message rather
> than an ICE.

I agree. BTW, I wonder how I could handle such an ICE from my backend
if I wanted to.

Thanks
Aurélien

Re: CDImode in reg

[Ian Lance Taylor]

Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> writes:

>>> So it should be skipped and the ICE is the normal behavior for such
>>> irrelevant test cases ?
>>
>> Personally, I don't really think an ICE is ever an acceptable result
>> from the compiler.  However, there are practical considerations.  Nobody
>> is ever going to write code like that for your processor.  If gets an
>> ICE, no real programmer is ever going to notice.  And if it didn't get
>> an ICE it would get an error instead.  So it's really up to you how much
>> effort you want to put in to generating a proper error message rather
>> than an ICE.
>
> I agree. BTW, I wonder how I could handle such an ICE from my backend
> if I wanted to.

I don't know--I don't know exactly what is causing the ICE.

Ian

Re: CDImode in reg

[Aurelien Buhrig]

The ICE is caused by a gcc_assert(have_regs_of_mode[CDImode])) in
init_move_cost(CDImode)...

Aurélien
2011/10/4 Ian Lance Taylor <iant@google.com>:
> Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> writes:
>
>>>> So it should be skipped and the ICE is the normal behavior for such
>>>> irrelevant test cases ?
>>>
>>> Personally, I don't really think an ICE is ever an acceptable result
>>> from the compiler.  However, there are practical considerations.  Nobody
>>> is ever going to write code like that for your processor.  If gets an
>>> ICE, no real programmer is ever going to notice.  And if it didn't get
>>> an ICE it would get an error instead.  So it's really up to you how much
>>> effort you want to put in to generating a proper error message rather
>>> than an ICE.
>>
>> I agree. BTW, I wonder how I could handle such an ICE from my backend
>> if I wanted to.
>
> I don't know--I don't know exactly what is causing the ICE.
>
> Ian
>

Re: CDImode in reg

[Ian Lance Taylor]

Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> writes:

> The ICE is caused by a gcc_assert(have_regs_of_mode[CDImode])) in
> init_move_cost(CDImode)...

Sounds like IRA needs to check have_regs_of_mode itself and give a
better error message when using an asm instruction.  I doubt this can be
fixed strictly in your backend.

Ian