| Message ID | edd41e60-3090-4318-1823-cca43bcf8005@gmail.com |
|---|---|
| State | New |
| Headers | show |
On 11/04/2016 06:26 PM, Martin Sebor wrote: > While experimenting with -Walloca and cross-referencing the manual > I noticed a few minor nits that I thought could stand to corrected > and/or clarified. Attached is a patch. > > In the update I mentioned that the alloca argument must have integer > type for the bounds checking to be recognized to make it clear that > for example floating point arguments are not considered to be bounded > even if they are constrained. (Apparently VRP doesn't handle those.) Right. VRP doesn't handle floating point. THere's been some talk of starting to track a few key values so we can say things like "this is not a NaN". The patch is OK for the trunk. Thanks, Jeff
On Sat, Nov 5, 2016 at 3:25 AM, Jeff Law <law@redhat.com> wrote: > On 11/04/2016 06:26 PM, Martin Sebor wrote: >> >> While experimenting with -Walloca and cross-referencing the manual >> I noticed a few minor nits that I thought could stand to corrected >> and/or clarified. Attached is a patch. >> >> In the update I mentioned that the alloca argument must have integer >> type for the bounds checking to be recognized to make it clear that >> for example floating point arguments are not considered to be bounded >> even if they are constrained. (Apparently VRP doesn't handle those.) > > Right. VRP doesn't handle floating point. THere's been some talk of > starting to track a few key values so we can say things like "this is not a > NaN". Yup. Basically add sth along SSA_NAME_RANGE_INFO for floats and track answers to isnan, isnormal, etc. -- basically record fpclassify () for each SSA name. I'd do this conveniently in tree-ssa-forwprop.c which iterates in RPO order, folding all stmts. The actual worker would be a int gimple_fpclassify (gimple *stmt) function classifying the result of stmt (using that SSA info on arguments). Or if you want it really fancy do it decomposed, int op_fpclassify (enum tree_code code, tree arg1 [, tree arg2 [, tree arg3]]) int op_fpclassify (enum built_in_function, tree arg1 [, tree arg2 [, tree arg3]]) Wherever we test stuff like HONOR_NANS we can replace it with sth operand specific that also evaluates the SSA info. It shouldn't be much work to start sth along this line. Richard. > > The patch is OK for the trunk. > > Thanks, > Jeff
gcc/ChangeLog: * doc/invoke.texi (Warning Options): Correct typos in -Walloca documentation. Index: gcc/doc/invoke.texi =================================================================== --- gcc/doc/invoke.texi (revision 241863) +++ gcc/doc/invoke.texi (working copy) @@ -4997,8 +4997,10 @@ This option warns on all uses of @code{alloca} in @item -Walloca-larger-than=@var{n} This option warns on calls to @code{alloca} that are not bounded by a -controlling predicate limiting its size to @var{n} bytes, or calls to -@code{alloca} where the bound is unknown. +controlling predicate limiting its argument of integer type to at most +@var{n} bytes, or calls to @code{alloca} where the bound is unknown. +Arguments of non-integer types are considered unbounded even if they +appear to be constrained to the expected range. For example, a bounded case of @code{alloca} could be: @@ -5014,13 +5016,13 @@ void func (size_t n) @} @end smallexample -In the above example, passing @code{-Walloca=1000} would not issue a -warning because the call to @code{alloca} is known to be at most 1000 -bytes. However, if @code{-Walloca=500} was passed, the compiler would -have emitted a warning. +In the above example, passing @code{-Walloca-larger-than=1000} would not +issue a warning because the call to @code{alloca} is known to be at most +1000 bytes. However, if @code{-Walloca-larger-than=500} were passed, +the compiler would emit a warning. Unbounded uses, on the other hand, are uses of @code{alloca} with no -controlling predicate verifying its size. For example: +controlling predicate constraining its integer argument. For example: @smallexample void func () @@ -5030,8 +5032,8 @@ void func () @} @end smallexample -If @code{-Walloca=500} was passed, the above would trigger a warning, -but this time because of the lack of bounds checking. +If @code{-Walloca-larger-than=500} were passed, the above would trigger +a warning, but this time because of the lack of bounds checking. Note, that even seemingly correct code involving signed integers could cause a warning: @@ -5048,7 +5050,7 @@ void func (signed int n) @end smallexample In the above example, @var{n} could be negative, causing a larger than -expected argument to be implicitly casted into the @code{alloca} call. +expected argument to be implicitly cast into the @code{alloca} call. This option also warns when @code{alloca} is used in a loop.