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: proposal: extend TARGET_OPTIONS structure



> I'd prefer that we create a different form of TARGET_SWITCHES
> that contains pointers to booleans.  I think that the concept
> of on/off switches is common enough to warrant special handling.

Allowing a string lets you simulate booleans but also allows you to
have N-way "on/off" switches and TARGET_SWITCHES that can have boolean
as well as specified options.

	-mno-align	(provides default of 2)
	-malign		(provides default of 16)
	-malign=4
	-malign=8

	-mhard-float	(provides default of "")
	-msoft-float	(provides default of " ")
	-msoft-float=-lfloat

While boolean options certainly are common enough *now* (but
non-booleans are getting more popular), it's the "let's special case
this common situation" mentality that caused this problem in the first
place.

What I've seen other implementations do (X11 comes to mind) is add yet
another field that specifies the type of the variable pointed to -
boolean, integer, string, float, etc.  But then it becomes complex to
set the defaults right, because the various types may not be the same
size (sizeof(int) != sizeof(double) etc).

For integer options (alignment, etc) we can read the string options in
override_options and set an integer variable.  We can even provide
macros to make that easy for backends if warranted.  This isn't needed
with boolean options since we can just look at string[0].


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