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]
Other format: [Raw text]

Re: [PATCH, rtl-optimization]: Fix PR37997: ICE shifting byte to the right with constant > 7FFFFFFF


> I fail to see any problem.  build_binary_op earlier converted all shift
> counts to type int, but there is no problem with that since it will only
> change the value in cases of undefined behavior and you need to handle
> shifts by INT_MIN anyway. 

I have no problem with that.

> There is no indication I can see in anything you have posted in this
> dicussion that the front end is generating any invalid trees or GIMPLE; it's
> for the expanders to handle arbitrary constant or nonconstant shift counts
> whose type may be unrelated to the type of the expression being shifted
> (where if it is known that the count  is negative or >= width of type, the
> result is arbitrary). 

I think it's a pure matter of convention, but I see no reason to make a 
questionable change in the middle-end because of a hole in the handling of 
non-sensical code in a front-end.

             /* We can shorten only if the shift count is less than the
                number of bits in the smaller type size.  */
             && compare_tree_int (op1, TYPE_PRECISION (TREE_TYPE (arg0))) < 0

obviously overlooks the negative case.

Note that the C++ compiler doesn't crash on the same code:

eric@atlantis:~/build/gcc/native32> gcc/cc1plus -quiet pr39779.c
pr39779.c: In function 'int test(char)':
pr39779.c:3:10: warning: right shift count >= width of type
pr39779.c:4:10: warning: right shift count >= width of type

-- 
Eric Botcazou


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