This is the mail archive of the
mailing list for the GCC project.
Re: MAX_FIXED_MODE_SIZE vs. __attribute__(mode) vs. ABIs
- From: "Giovanni Bajo" <giovannibajo at libero dot it>
- To: "Roger Sayle" <roger at eyesopen dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Mon, 3 Jan 2005 14:13:16 +0100
- Subject: Re: MAX_FIXED_MODE_SIZE vs. __attribute__(mode) vs. ABIs
- References: <Pine.LNX.email@example.com>
Roger Sayle <firstname.lastname@example.org> 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
> (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).