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

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

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

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 = add_co

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

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 10.0.0):

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

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] rs6000: ICE when using an MMA type as a function param

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 (rs6000_promote_funct

Re: RFC: Monitoring old PRs, new dg directives

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 be

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

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 clean?

Re: Fix remove_predictions_associated_with_edge

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.

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

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 fro

Simplify X * C1 == C2 with wrapping overflow

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.

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 in

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

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, fortran] PR96102 - ICE in check_host_association, at fortran/resolve.c:5994

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 same

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

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, fortran] PR96312 - [10/11 Regression] Reallocation on assignment uses undefined variables

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 allocatio

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

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 th