On Thu, 2020-02-13 at 10:42 -0700, Martin Sebor wrote: > 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. Jakub, let's defer any cleanups unless there's a reported bug. We can come back to this stuff for gcc-11.
jeff > > Martin >
