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: Updating fixed-point support for new C constant expression handling


On Tue, 30 Jun 2009, Richard Sandiford wrote:

> The 4.5 C constant expressions patch:
> 
>     http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01061.html
> 
> stopped us from emitting the warnings expected by gcc.dg/fixed-point/addsub.c.
> We used to handle the warnings in parser_build_binary_op, but now that
> fixed-point constant folding is delayed until c_fully_fold, we no longer
> know at that stage whether overflow has taken place.
> 
> What's the correct fix here?  Should build_binary_op treat fixed-point
> constants like integer constants?  Should c_fully_fold emit warnings in
> some cases?  Should we just drop the warnings?  Or something else?

If the warnings are because this is a static initializer, 
constant_expression_warning should deal with them and it should be 
sufficient for TREE_OVERFLOW to be set.  (But such warnings are 
deliberately conditioned on -pedantic.)

If the warnings are simply a warning from overflow_warning desired whether 
or not this is a static initializer, then the appropriate point to give 
them would be the point of lowering - that is, c_fully_fold.

Since TR 18037 says that fixed-point constants (like floating constants) 
in integer constant expressions must be the immediate operands of casts, 
folding expressions of fixed point constants into a single FIXED_CST the 
way expressions of integer constants are folded into a single INTEGER_CST 
would be inappropriate at parse time; it would lead to expressions 
involving some more complicated expression of fixed-point constants, cast 
to an integer type, wrongly being accepted as integer constant 
expressions.

In general it's preferable for the trees created at parse time to 
correspond more closely to the source code, meaning that diagnostic checks 
requiring lowering should happen at the time of lowering (or be changed 
not to rely on lowering) if possible.

-- 
Joseph S. Myers
joseph@codesourcery.com


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