This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Updating fixed-point support for new C constant expression handling
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 30 Jun 2009 19:22:20 +0000 (UTC)
- Subject: Re: Updating fixed-point support for new C constant expression handling
- References: <874otx376b.fsf@talisman.home>
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