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]

Re: builtin_constant_p


	The biggest flaw I saw in the patch is that it doesn't care for
	side effects of expressions.  So __builtin_constant_p(i++) would
	return false, but i would still be incremented.

So you are saying that side-effects should not be performed?  Why?

I see that the current code does not perform side-effects, but I would call
that a bug in the current code.  This is a fairly common bug with built-in
functions, as it is an easy thing to miss when writing code to handle built-in
functions.  I think all built-in functions should perform side-effects,
because that is what the programmer will expect.  Note that some built-ins
must perform side-effects, because they are just substitutes for normal
C language function calls.  I think it would be confusing to have
some built-in functions performing side-effects and some ignoring them.
Programmers won't remember which is which.

Incidentally, you don't need a function to test whether a tree has side
effects. All you need to do is check the TREE_SIDE_EFFECTS bit.  This bit is
valid for all trees.

	It doesn't seem likely that __builtin_constant_p will be used in addresses.
	I see it most often used in

	__builtin_constant_p(x) ? compile_time_expr(x) : run_time_expr(x)

The more useful we make __builtin_constant_p, the more places people will
try to use it.  I agree that this is something we can worry about later
though, if it turns out to be necessary.

	So given the above expectation, do we still need to modify ports?  Or
	is updating CONSTANT_P sufficient?

I'd suggest we try it, and see what kinds of problems show up, keeping in
mind that we may need to make further changes.  I suspect that fixing
CONSTANT_P will handle the vast majority of the cases, and that the rest
won't be important enough to worry about.

Jim


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