[polly] r271128 - Determination of statements that contain matrix multiplication

[Mehdi Amini via llvm-commits]

> On Jun 2, 2016, at 5:46 AM, Michael Kruse <llvm-commits at meinersbur.de> wrote:
> 
> 2016-05-31 23:40 GMT+02:00 Mehdi Amini via llvm-commits
> <llvm-commits at lists.llvm.org>:
> 
>>> +/// @brief Circular shift of output dimensions of the integer map.
>>> +///
>>> +/// @param IslMap The isl map to be modified.
>>> +static __isl_give isl_map *circularShiftOutputDims(__isl_take isl_map *IslMap) {
>>> +  auto InputDimsId = isl_map_get_tuple_id(IslMap, isl_dim_in);
>>> +  auto DimNum = isl_map_dim(IslMap, isl_dim_out);
>>> +  IslMap = isl_map_move_dims(IslMap, isl_dim_in, 0, isl_dim_out, DimNum - 1, 1);
>>> +  IslMap = isl_map_move_dims(IslMap, isl_dim_out, 0, isl_dim_in, 0, 1);
>>> +  return isl_map_set_tuple_id(IslMap, isl_dim_in, InputDimsId);
>>> +}
>> 
>> Coverity is reporting a potential issue here:
>> 
>> *** CID 1356130:  Insecure data handling  (INTEGER_OVERFLOW)
>> /tools/polly/lib/Transform/ScheduleOptimizer.cpp: 469 in circularShiftOutputDims(isl_map *)()
>> 463     /// @param IslMap The isl map to be modified.
>> 464     static __isl_give isl_map *circularShiftOutputDims(__isl_take isl_map *IslMap) {
>> 465       auto InputDimsId = isl_map_get_tuple_id(IslMap, isl_dim_in);
>> 466       auto DimNum = isl_map_dim(IslMap, isl_dim_out);
>> 467       IslMap = isl_map_move_dims(IslMap, isl_dim_in, 0, isl_dim_out, DimNum - 1, 1);
>> 468       IslMap = isl_map_move_dims(IslMap, isl_dim_out, 0, isl_dim_in, 0, 1);
>>>>>    CID 1356130:  Insecure data handling  (INTEGER_OVERFLOW)
>>>>>    Overflowed or truncated value (or a value computed from an overflowed or truncated value) "isl_map_set_tuple_id(IslMap, isl_dim_in, InputDimsId)" used as return value.
>> 469       return isl_map_set_tuple_id(IslMap, isl_dim_in, InputDimsId);
>> 470     }
>> 
>> 
> 
> Can you explain the message? The only integer used in that line is
> isl_dim_in, and its a constant as used elsewhere as well.
> 
> I find a different possible underflow with the expression "DimNum -
> 1", as DimNum is unsigned. Might happen if the map has 0 range
> dimensions which probably never happens.

Yes it seems that it is what Coverity is reporting, feel free to ignore if you think it's fine.

-- 
Mehdi