Simplify X * C1 == C2 with wrapping overflow

2020-08-09 Thread Marc Glisse
Odd numbers are invertible in Z / 2^n Z, so X * C1 == C2 can be rewritten as X == C2 * inv(C1) when overflow wraps. mod_inv should probably be updated to better match the other wide_int functions, but that's a separate issue. Bootstrap+regtest on x86_64-pc-linux-gnu. 2020-08-10 Marc Glisse

Re: [PATCH] middle-end: Correct calculation of mul_widen_cost and mul_highpart_cost.

2020-08-09 Thread Richard Biener via Gcc-patches
On August 9, 2020 12:30:32 PM GMT+02:00, Roger Sayle wrote: > >This patch fixes a subtle bug in the depths of GCC's synth_mult, >where the middle-end queries whether (how well) the target supports >widening and highpart multiplications by calling targetm.rtx_costs. >The code in init_expmed and

Re: [PATCH] [AVX512]For vector compare to mask register, UNSPEC is needed instead of comparison operator [PR96243]

2020-08-09 Thread Hongtao Liu via Gcc-patches
On Fri, Aug 7, 2020 at 11:02 PM Kirill Yukhin wrote: > > Hello, > > On 05 авг 09:29, Hongtao Liu wrote: > > On Tue, Aug 4, 2020 at 6:28 PM Kirill Yukhin > > wrote: > > > > > > On 04 авг 13:26, Kirill Yukhin wrote: > > > > Could you please clarify, how your patch relared to [1]? > > > > I see

Re: Fix remove_predictions_associated_with_edge

2020-08-09 Thread Martin Liška
On 8/2/20 3:02 PM, Jan Hubicka wrote: Hi, remove_predictions_associated_with_edge currently calls filter_predicitons passing it equal_edge_p. Becase filter_predictions removes all edges where filter returns false, the function does exact oposite. Fixed thus. Bootstrapped/regtested x86_64-linux.

[PATCH] rs6000: ICE when using an MMA type as a function param

2020-08-09 Thread Peter Bergner via Gcc-patches
PR96506 shows a problem where we ICE on illegal usage, namely using MMA types for function arguments and return values. The solution is to flag these illegal usages as errors early, before we ICE. The patch below is currently bootstrapping and regtesting. Ok for trunk once that comes back

Re: RFC: Monitoring old PRs, new dg directives

2020-08-09 Thread Martin Liška
On 8/5/20 12:22 AM, Marek Polacek wrote: On Thu, Jul 30, 2020 at 11:08:03AM +0200, Martin Liška wrote: Hello. I support the initiative! What would be nice to add leading 'PR component/12345' to a git commit so that these test additions are linked to bugzilla issues. Thanks! Yes, it should

Re: [PATCH] rs6000: ICE when using an MMA type as a function param

2020-08-09 Thread Peter Bergner via Gcc-patches
On 8/9/20 10:03 PM, Peter Bergner wrote: > gcc/ > PR target/96506 > * config/rs6000/rs6000-call.c (rs6000_promote_function_mode): > (rs6000_function_arg): Oops, missed the ChangeLog entries: gcc/ PR target/96506 * config/rs6000/rs6000-call.c

Re: [PATCH] rs6000: MMA built-ins reject typedefs of MMA types

2020-08-09 Thread Peter Bergner via Gcc-patches
On 8/8/20 11:59 AM, Peter Bergner wrote: > Testing was clean, so I pushed this to trunk. Will wait before > backporting. Thanks! Scanning through Bill Seurer's testsuite runs for POWER, I see no fallout, so I have pushed this to the GCC 10 branch. Peter

Re: [patch] multi-range implementation for value_range (irange)

2020-08-09 Thread Martin Liška
On 8/5/20 4:27 PM, Gerald Pfeifer wrote: Hi Aldy, On Fri, 31 Jul 2020, Aldy Hernandez via Gcc-patches wrote: Jeff approved this patch off-list. I will re-run tests once again and commit by Monday. I believe this has broken the bootstrap with clang (specifically FreeBSD clang version

[pushed] testsuite, Darwin: XFAIL runs for two timode conversion tests.

2020-08-09 Thread Iain Sandoe
Hi, X86 Darwin fails two TI mode conversions at present, because (to work around PR80556) we insert libSystem ahead of libgcc. The libSystem implementation has a similar bug to one that was fixed for GCC. We need to fix 80556 properly, and then this issue will go away - we will be able to use

[Patch, fortran] PR96312 - [10/11 Regression] Reallocation on assignment uses undefined variables

2020-08-09 Thread Paul Richard Thomas via Gcc-patches
Hi All, trans-expr.c(fcncall_realloc_result) unconditionally compared the shapes of the function result and the lhs. This is clearly wrong when the lhs is not allocated since the bounds could be used uninitialized as found by the reporter. The patch does the obvious thing by checking the

Re: [Patch, fortran] PR96102 - ICE in check_host_association, at fortran/resolve.c:5994

2020-08-09 Thread Thomas Koenig via Gcc-patches
Hi Paul, Dominique has kindly pointed out that the error message in the patch does not correspond to the errors in the testcase. This came about because the submitted patch was an earlier version of that on my tree. Please find attached the correct version of the patch. The principle is the

Re: [Patch, fortran] PR96312 - [10/11 Regression] Reallocation on assignment uses undefined variables

2020-08-09 Thread Thomas Koenig via Gcc-patches
Hi Paul, Regtests OK on FC31/x86_64 - OK for master? OK. This bug is also exposed by a matmul optimization that I introduced quite a long time ago, so a backport would also be good (I can do that if you prefer). Best regards Thomas

[PATCH] middle-end: Correct calculation of mul_widen_cost and mul_highpart_cost.

2020-08-09 Thread Roger Sayle
This patch fixes a subtle bug in the depths of GCC's synth_mult, where the middle-end queries whether (how well) the target supports widening and highpart multiplications by calling targetm.rtx_costs. The code in init_expmed and init_expmed_one_mode iterates over various RTL patterns querying the

Re: [PATCH 3/4] ivopts: Consider cost_step on different forms during unrolling

2020-08-09 Thread Kewen.Lin via Gcc-patches
Hi Bin, Thanks for the review!! on 2020/8/8 下午4:01, Bin.Cheng wrote: > Hi Kewen, > Sorry for the late reply. > The patch's most important change is below cost computation: > >> @@ -5890,6 +5973,10 @@ determine_iv_cost (struct ivopts_data *data, struct >> iv_cand *cand) >> cost_step =

[PATCH] options: Make --help= to emit values post-overrided

2020-08-09 Thread Kewen.Lin via Gcc-patches
Hi Segher, on 2020/8/7 下午10:42, Segher Boessenkool wrote: > Hi! > > On Fri, Aug 07, 2020 at 10:44:10AM +0800, Kewen.Lin wrote: >>> I think this makes a lot of sense. >>> btw, not sure whether it's a good idea to move target_option_override_hook call into print_specific_help and use one