Patch ping

[Martin Sebor]

On 2/13/20 2:54 AM, Jakub Jelinek wrote:
> On Wed, Feb 12, 2020 at 02:39:05PM -0700, Jeff Law wrote:
>> On Mon, 2020-02-10 at 10:24 +0100, Jakub Jelinek wrote:
>>> Hi!
>>>
>>> I'd like to ping a couple of patches:
>>>
>>> PR target/91913 - arm movsi + cmpsi -> movsi_compare0 peephole2 ICE fix
>>>     https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00010.html
>> Letting the ARM guys deal with this.
> 
> Yes, that is resolved now (Richard E. committed his patch and I've
> committed the testcase).
> 
>>> PR preprocessor/92319 - partially implement P1042R1: __VA_OPT__ wording clarifications
>>>     https://gcc.gnu.org/ml/gcc-patches/2020-01/msg02104.html
>> Jason for this one.
> 
> Of course; I just chose to send a ping for all my pending patches and
> add to To: all relevant maintainers.
> 
>>> PR target/93069 - avx512* rejects-valid fix (rejected by assembler)
>>>     http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01606.html
>> This is in my queue :-)
> 
> Ok.
> 
>>> PR tree-optimization/92868 - compute_objsize/gimple_call_alloc_size
>>>                               /maybe_warn_overflow fixes
>>>     http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01164.html
>> Martin's patch should have addressed all the issues and should include
>> your tests (tweaked, but supposed to be equivalent).
> 
> No, this is something different, this isn't what has been covered by the
> testcases, but something found by code inspection, mainly inconsistencies
> in the APIs, e.g. the ranges represented as sizetype most of the time,
> but with one exception where it could be some other type (wider or
> narrower), or sometimes the range being incorrect (if there is possible
> overflow and we punt, we didn't change the ranges effectively to VARYING,
> but just capped the maximum), or INTEGER_CSTs compared by pointer equality
> rather than operand_equal_p.

As I said repeatedly in my comments on the patch, I'm not in favor
of these changes.  I don't think they hurt anything but they also
don't fix anything that I can see.  There's is no bug the change
fixes (PR 92868 is closed as resolved) or a test case included in
the patch that verifies the improvement.  The changes are also not
in the direction I'd like to see this code evolve.

Martin