This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MAX_FIXED_MODE_SIZE vs. __attribute__(mode) vs. ABIs


Roger Sayle <roger@eyesopen.com> wrote:

> typedef int DItype __attribute__ ((mode (DI)));
>
> extern DItype foo();
>
> DItype bar()
> {
>   return foo() + 1;
> }


> The question then is who is responsible to avoiding initial RTL such
> as:
>
> (call_insn 10 9 19 (set (reg:DI 18 r18)
>         (call (mem:HI (symbol_ref:HI ("foo") ...)
>
>
> I'm not clear whether it is the front-ends who should check the
> GET_MODE_BITSIZE on their __attribute__(mode)) specifications against
> MAX_FIXED_MODE_SIZE and either issue a warning or use BLKmode instead,
> or if its the backend for not not explicitly disqualifying DImode in
> HARD_REGNO_MODE_OK (and other macros), or some other interaction.

It would seem to me that it is best to catch this kind of errors early. If
DImode is disallowed on such target, we should not even give the user a way to
create such variables. handle_mode_attribute uses scalar_mode_supported_p. The
default implementation does not seem to care about MAX_FIXED_MODE_SIZE, so I
guess that is the bug.

You could also add some sanity check at startup that scalar_mode_supported_p
obeys MAX_FIXED_MODE_SIZE (that is, for any mode > MAX_FIXED_MODE_SIZE,
scalar_mode_supported_p returns false).

Giovanni Bajo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]