This is the mail archive of the gcc-patches@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: RFA: Use .opt files for the m68k port


Gunther Nikl <gni@gecko.de> writes:
>   I just had another look at the m68k change and I noticed that
>   TARGET_DEFAULT_TARGET_FLAGS contains MASK_STRICT_ALIGNMENT. I must
>   admit that I never noticed the strange old defintions for it. Do
>   I read that correctly that this is the old default value?

I know Andreas already addressed this, but further to what he said:
yes, the sense of MASK_STRICT_ALIGNMENT used to be reversed.
It was called MASK_NO_STRICT_ALIGNMENT, was off by default,
and was set by -mno-strict-alignment.

>   BTW, there seems to be a bug in handle_option/OPT_mshared_library_id_:
>   the error message passes arg but should pass value.

You mean this:

	error ("-mshared-library-id=%s is not between 0 and %d",
	       arg, MAX_LIBRARY_ID);

?  No, it's correct.  (I did test it before posting, honest. ;)
ARG is the string value of the argument and VALUE is the integer
value.  Specifically, ARG is always the string argument of a
Joined option and VALUE is always the integer value of a
UInteger option.

Stylistically, it's probably better to use ARG instead of VALUE
in error messages so that the message will say exactly what the
user typed.  (I seem to remember I used VALUE upthread, sorry.)
It doesn't matter much either way though.

>   And I have further question: Is it possible to have an option (switch?)
>   that clears several other flags at once?

Yes.  See m68k_handle_option.  Options like -m68000 are already
doing this.

>   And how is a subtarget supposed to handle own options? With
>   something like a SUBTARGET_OPTIONS call in the target option
>   handler?

There's no prescribed way.  Whatever the target maintainers think
is best, basically.  Using something like SUBTARGET_OPTIONS would
certainly be one way.  Another would be to add the code to the main
handle_option function and guard it with ifdefs.

FWIW, none of the targets that I've patched have needed
subtarget-specific code in handle_option so I've no real
advice to offer.  ISTR Aldy's using the ifdef approach
for RS6000 though.

Richard


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