Re: [PATCH PR90240][RFC]Avoid scaling cost overflow by introducing scaling bound
> --
> Sender:Richard Biener
> Sent At:2019 Apr. 29 (Mon.) 20:01
> Recipient:bin.cheng
> Cc:GCC Patches ; mliska
> Subject:Re: [PATCH PR90240][RFC]Avoid scaling cost overflow by introducing
> scaling bound
>
>
> On Sat, Apr 27, 2019 at 6:13 AM bin.cheng wrote:
> >
> > > Hi,
> >
> > This is the draft patch avoiding scaling cost overflow by introducing a
> > scaling bound
> > in IVOPTs. For now the bound is 20, and scaling factor will be further
> > scaled wrto
> > this bound. For example, scaling factor like 1, 1000, 2000(max) would be
> > scaled to
> > 1, 10, 20 correspondingly.
> >
> > HI Martin, I remember you introduced comp_cost/cost_scaling to improve one
> > case
> > in spec2017. Unfortunately I don't have access to the benchmark now, could
> > you help
> > verify that if this patch has performance issue on it please? Thanks
> >
> > Bootstrap and test on x86_64, and this is for further comment/discussion.
>
> + float factor = 1.0f * bfreq / lfreq;
> + if (adjust_factor_p)
> + {
> + factor *= COST_SCALING_FACTOR_BOUND;
> + factor = factor * lfreq / max_freq;
> + }
> + body[i]->aux = (void *)(intptr_t)(int) factor;
>
> float computations on the host shouldn't be done.
Fixed.
>
> I wonder if changing comp_cost::cost to int64_t would help instead? See also
> my
> suggestion to use gmp.
Next patch for PR90078 changes the cost to int64_t.
>
> Otherwise the approach looks sane to me - can we then even assert that
> no overflows
> happen and thus INFTY only appears if we manually set such cost?
Next patch for PR90078 changes to assert on cost overflow.
Attachment is the updated patch. Bootstrap/test on x86_64 along with PR90078
patch.
Is it OK?
Thanks,
bin
2019-05-05 Bin Cheng
PR tree-optimization/90240
* tree-ssa-loop-ivopts.c (get_scaled_computation_cost_at): Scale cost
with respect to scaling factor pre-computed for each basic block.
(try_improve_iv_set): Return bool if best_cost equals to iv_ca cost.
(find_optimal_iv_set_1): Free iv_ca set if it has infinite_cost.
(COST_SCALING_FACTOR_BOUND, determine_scaling_factor): New.
(tree_ssa_iv_optimize_loop): Call determine_scaling_factor. Extend
live range for array of loop's basic blocks. Cleanup aux field of
loop's basic blocks.
2018-05-05 Bin Cheng
PR tree-optimization/90240
* gfortran.dg/graphite/pr90240.f: New test.
0001-pr90240.patch
Description: Binary data
Re: [PATCH, RFC, rs6000] PR80791 Consider doloop in ivopts
on 2019/4/27 上午11:44, Bin.Cheng wrote:
> On Fri, Apr 26, 2019 at 2:44 PM Kewen.Lin wrote:
>> +
>> + /* zero cost use makes it easier to select memory based iv cand
>> + for replacement of non memory based iv and its use. But if
>> + the setup sequence are too costly, loop iv analysis can NOT
>> + easily figure out it's finite, it's possible to stop the
>> + low-overhead loop transformation and get unexpected code. */
>> + if (use->zero_cost_p && cand->iv->base_object && !use->iv->base_object
>> + && elim_cost.cost >= 30)
>> + dont_elim_p = true;
> No, we'd like to avoid such things in general. The conditions look
> like a hack to me. elim_cost is compared to express_cost, adding
> another check on it at different place isn't really good, especially
> 30 itself is a magic number. It's most likely improvement in some
> cases, deterioration in others.
>
Yes, I agree it's too hacky and unacceptable as a formal fix. And I
tried to investigate more whether it's a general issue but never got
exposed.
> Also it punishes one pass (IVOPTs here) because of other pass' (RTL)
> problem. It does't mean we can't do such transformations, only it has
> to be as precise/conservative as possible. For example, if RTL loop
> iv is improved to handle the case in the future, who would remember to
> come back and adjust this?
>
Good question!
> GCC lacks the capability passing information to later passes. Gimple
> analyzer worked hard collecting various information but discards it
> entering RTL or earlier. Other examples are like runtime alias
> information, non-wrapping information for specific operations, etc.
> IMHO, this is what needs to be done. As for this case, it could be
> finite loop info, or non-wrapping info of the iv_var's increment
> operation. By passing more information, RTL passes can be simplified
> too.
>
Thanks for the information! Is there any under development work for this?
That would be fine if we can pass down those information to downstream
passes based on upcoming feature.
> Thanks,
> bin
>> +
>>/* The bound is a loop invariant, so it will be only computed
>> once. */
>>elim_cost.cost = adjust_setup_cost (data, elim_cost.cost);
>> @@ -5184,7 +5195,7 @@ determine_group_iv_cost_cond (struct ivopts_data *data,
>>express_cost += bound_cost;
>>
>>/* Choose the better approach, preferring the eliminated IV. */
>> - if (elim_cost <= express_cost)
>> + if (elim_cost <= express_cost && !dont_elim_p)
>> {
>>
>>
>> I was thinking whether this zero cost change just exposed
>> an existing problem, then this kind of check should be for all
>> cases not only for zero cost use, similar to
>> expression_expensive_p? But why doesn't it happen before?
>> Need more investigation.
>>
>>>
Btw, this is for GCC10.
>>>
>>> *Phew* ;-)
>>>
>>>
>>> Some trivial comments:
>>>
+static bool
+invalid_insn_for_doloop_p (struct loop *loop)
+{
+ basic_block *body = get_loop_body (loop);
+ unsigned num_nodes = loop->num_nodes;
+ gimple_stmt_iterator gsi;
+ unsigned i;
+
+ for (i = 0; i < num_nodes; i++)
>>>
>>> for (unsigned i = 0; i < num_nodes; i++)
>>>
>>> (and maybe you can just say loop->num_nodes here; I don't know if that
>>> generates worse code, or if that even matters).
>>
>> Good idea, will fix it.
>>
>>>
+if (dump_file && (dump_flags & TDF_DETAILS))
+ fprintf (
+dump_file,
+"predict doloop failure due to finding computed jump.\n");
>>>
>>> We don't normally end lines in (. There are other solutions to why you
>>> did that here; you can use string pasting, to break the string into two,
>>> or factor out (some part of) the loop body to reduce indentation.
>>>
>>
>> Will adjust it.
>>
>>>
>>> Segher
>>>
>>
>
Re: [PATCH, RFC, rs6000] PR80791 Consider doloop in ivopts
On Sun, May 5, 2019 at 11:23 AM Kewen.Lin wrote:
>
> Hi Bin,
>
> Sorry for late response (just back from vacation).
>
> Thanks very much for your comments.
>
> on 2019/4/27 上午11:20, Bin.Cheng wrote:
> > For such non-trivial patch, we can improve review process by splitting
> > to smaller patches which can be reviewed/approved independently.
>
> Good idea! I'll split it.
>
> > Below are some general comments specific to IVOPTs change.
>
> >> for (j = 0; j < group->vuses.length (); j++)
> >> {
> >> - rewrite_use_compare (data, group->vuses[j], cand);
> >> - update_stmt (group->vuses[j]->stmt);
> >> + rewrite_use_compare (data, group->vuses[j], cand);
> >> + update_stmt (group->vuses[j]->stmt);
> > Wrong formatting change? Also we can run contrib/check_GNU_style.sh
> > for coding style issues.
> >
>
> Good catch!
>
> >> + /* Some compare iv_use is probably useless once the doloop optimization
> >> + performs. */
> >> + if (tailor_cmp_p)
> >> +tailor_cmp_uses (data);
> > Function tailor_cmp_uses sets iv_use->zero_cost_p under some
> > conditions. Once the flag is set, though the iv_use participates cost
> > computation in determine_group_iv_cost_cond, the result cost is
> > hard-wired to ZERO (which means cost computation for such iv_use is
> > waste of time).
>
> Yes, it can be improved by some early check and return.
> But it's still helpful to make it call with may_eliminate_iv.
> gcc.dg/no-strict-overflow-6.c is one example, with may_eliminate_iv
> consideration it exposes more opportunities for downstream optimization.
Hmm, I wasn't suggesting early check and return, on the contrary, we
can better integrate doloop/cost stuff in the overall model. See more
in following comments.
>
> > Also iv_use rewriting process is skipped for related
> > ivs preserved explicitly by preserve_ivs_for_use.
> > Note IVOPTs already adds candidate for original ivs. So why not
> > detecting doloop iv_use, adjust its cost with the corresponding
> > original iv candidate, then let the general cost model make the
> > decision? I believe this better fits existing infrastructure and
> > requires less change, for example, preserve_ivs_for_use won't be
> > necessary.
> I agree adjusting the cost of original iv candidate of the iv_use
> requires less change, but on one hand, I thought to remove interest
> cmp iv use or make it zero cost is close to the fact. Since it's
> eliminated eventually in doloop optimization, it should not
> considered in cost modeling. This way looks more exact.
Whether doloop transformation should be considered or be bypassed in
cost model isn't a problem. Actually we can bind doloop iv_cand to
cmp iv_use in order to force the transformation. My concern is the
patch specially handles doloop by setting the special flag, then
checking it. We generally avoid such special-case handling since it
hurts long time maintenance. The pass was very unstable in the pass
because of such issues.
> One the other hand, I assumed your suggestion is to increase the
> cost for the pair (original iv cand, cmp iv use), the increase cost
> seems to be a heuristic value? It seems it's possible to sacrifice
Decrease the cost so that the iv_cand is preferred? The comment
wasn't made on top of implementing doloop in ivopts. Anyway, you can
still bypass cost model by binding the "correct" iv_cand to cmp
iv_use.
> performance for some worst cases? Although it's integrated to the
> existing framework, it probably introduces other cost adjust issues.
> For example, the original iv cand is inclined not to be selected after
> this change, but without considering the cmp iv use, it's better to
> be selected. It looks highly depend on the cost tuning?
>
> Does my understanding above make sense?
>
> But I will follow your suggestion to update and check the regression
> testing result etc. I just updated the code to increase the cost for
> the pair (original iv cand, cmp iv use) with 5 (to balance the original
> iv 4 vs other 5), the failure case in PR80791 was fixed. I assumed
> IP_ORIGINAL for cand->pos to check original iv cand is enough.
>
>
> > It has other advantages too, for example, 1) candidate of
> > original iv can be preferred for other iv_uses with doloop cost
>
> I think the patch way is not intrusive either.
>
> > tuning; 2) the doloop decision can still be canceled by cost model if
> > it's really not beneficial. With current patch, it can't be undo once
> > the decision is made (at very early stage in IVOPTs.).
>
> I can't really follow this. If it's predicted to be transformed to doloop,
> I think it should not be undoed any more, since it's useless to consider
> this cmp iv use. Whatever IVOPTS does, the comp at loop closing should not
> be changed (although possible to use other iv), right? Do I miss something?
As mentioned, the previous comment wasn't made on top of implementing
doloop in ivopts. That would be
Re: [PATCH, RFC, rs6000] PR80791 Consider doloop in ivopts
on 2019/4/27 上午12:59, Segher Boessenkool wrote: > On Fri, Apr 26, 2019 at 10:26:52PM +0800, Kewen.Lin wrote: >> on 2019/4/26 下午3:16, Richard Biener wrote: >>> We should think about possible ways of encoding doloop at IVOPTs >>> time rather than trying to re-analyze at RTL. I suppose we can >>> easily set a flag in struct loop but I'm not familiar enough with >>> the doloop pass to tell whether that is good enough. Also we >>> can maybe move doloop to GIMPLE completely? I remember some >>> targets have loop size constraints here as well, so I guess >>> that isn't easily possible. > >> It's a very good point, but I'm afraid that it's impossible to move the >> whole doloop analysis pass to GIMPLE. When I implemented this hook >> rs6000_predict_doloop_p, I went through all the checks in doloop_optimize. >> I found it looks impossible to imitate all of them at GIMPLE, especially >> for gen_doloop_end check, jump insn check and register liveness clobber >> check. Even if we can make hook to check expanded RTL insn sequence in >> GIMPLE, but it happens too early, some information may not be exact enough, >> many following passes could update what the analysis is based on. > > But you could set a flag in gimple, and have the RTL pass only do the > final mechanics of making things a counted loop -- including generating > the code for when it cannot do the doloop, which indeed will happen for > many different reasons, many target-specific, but it is probably pretty > easy to predict when we *can* use one, and we can do that optimistically, > it's not so very much worse code to have to do it with a few instructions > instead of e.g. a bdnz; there are many optimisation passes after this > that can still improve the code (cprop, cse, combine). > Yes, we can set a flag to indicate this loop was predicted as doloop, which implicitly says we have checked some doloop criteria that are able to be checked in middle end. It can be well defined later. One question in mind is whether there are some other passes suffering the pain that the pass doesn't know the loop can be transformed to doloop or not and can't perform some optimization. I guess it decides what's the value and priority to make this non-trivial change. Do you happen to know some existing PRs? > So, make it a doloop in gimple, and still have the rtl pass, but that > only reverts it to a non-doloop if it turns out it has to. Does that > sound like a good plan? > Sounds good! Thanks Segher! > > Segher >
Re: [PATCH, RFC, rs6000] PR80791 Consider doloop in ivopts
Hi Bin,
Sorry for late response (just back from vacation).
Thanks very much for your comments.
on 2019/4/27 上午11:20, Bin.Cheng wrote:
> For such non-trivial patch, we can improve review process by splitting
> to smaller patches which can be reviewed/approved independently.
Good idea! I'll split it.
> Below are some general comments specific to IVOPTs change.
>> for (j = 0; j < group->vuses.length (); j++)
>> {
>> - rewrite_use_compare (data, group->vuses[j], cand);
>> - update_stmt (group->vuses[j]->stmt);
>> + rewrite_use_compare (data, group->vuses[j], cand);
>> + update_stmt (group->vuses[j]->stmt);
> Wrong formatting change? Also we can run contrib/check_GNU_style.sh
> for coding style issues.
>
Good catch!
>> + /* Some compare iv_use is probably useless once the doloop optimization
>> + performs. */
>> + if (tailor_cmp_p)
>> +tailor_cmp_uses (data);
> Function tailor_cmp_uses sets iv_use->zero_cost_p under some
> conditions. Once the flag is set, though the iv_use participates cost
> computation in determine_group_iv_cost_cond, the result cost is
> hard-wired to ZERO (which means cost computation for such iv_use is
> waste of time).
Yes, it can be improved by some early check and return.
But it's still helpful to make it call with may_eliminate_iv.
gcc.dg/no-strict-overflow-6.c is one example, with may_eliminate_iv
consideration it exposes more opportunities for downstream optimization.
> Also iv_use rewriting process is skipped for related
> ivs preserved explicitly by preserve_ivs_for_use.
> Note IVOPTs already adds candidate for original ivs. So why not
> detecting doloop iv_use, adjust its cost with the corresponding
> original iv candidate, then let the general cost model make the
> decision? I believe this better fits existing infrastructure and
> requires less change, for example, preserve_ivs_for_use won't be
> necessary.
I agree adjusting the cost of original iv candidate of the iv_use
requires less change, but on one hand, I thought to remove interest
cmp iv use or make it zero cost is close to the fact. Since it's
eliminated eventually in doloop optimization, it should not
considered in cost modeling. This way looks more exact.
One the other hand, I assumed your suggestion is to increase the
cost for the pair (original iv cand, cmp iv use), the increase cost
seems to be a heuristic value? It seems it's possible to sacrifice
performance for some worst cases? Although it's integrated to the
existing framework, it probably introduces other cost adjust issues.
For example, the original iv cand is inclined not to be selected after
this change, but without considering the cmp iv use, it's better to
be selected. It looks highly depend on the cost tuning?
Does my understanding above make sense?
But I will follow your suggestion to update and check the regression
testing result etc. I just updated the code to increase the cost for
the pair (original iv cand, cmp iv use) with 5 (to balance the original
iv 4 vs other 5), the failure case in PR80791 was fixed. I assumed
IP_ORIGINAL for cand->pos to check original iv cand is enough.
> It has other advantages too, for example, 1) candidate of
> original iv can be preferred for other iv_uses with doloop cost
I think the patch way is not intrusive either.
> tuning; 2) the doloop decision can still be canceled by cost model if
> it's really not beneficial. With current patch, it can't be undo once
> the decision is made (at very early stage in IVOPTs.).
I can't really follow this. If it's predicted to be transformed to doloop,
I think it should not be undoed any more, since it's useless to consider
this cmp iv use. Whatever IVOPTS does, the comp at loop closing should not
be changed (although possible to use other iv), right? Do I miss something?
> Sorry didn't bring out this earlier, I only realized this after
> reading your code.
It doesn't matter indeed! Thanks again!
Re: [PATCH][PR89341]Fix ICE on function definition with weakref/alias attributes attached
在 2019/3/26 下午7:40, JunMa 写道: Hi According to gnu document of function attributes, neither weakref nor alias could be attached to a function defined in current translation unit. Although GCC checks the attributes under some circumstances, it still fails on some cases and even causes ICE. This patch checks whether alias/weakref attribute attaches on a function declaration which has body, and removes the attribute later. This also avoid the ICE. Bootstrapped/regtested on x86_64-linux, ok for GCC10? Regards JunMa gcc/ChangeLog 2019-03-26 Jun Ma PR89341 * cgraphunit.c (handle_alias_pairs): Check whether alias attribute attaches on a function declaration which has body. gcc/testsuite/ChangeLog 2019-03-26 Jun Ma PR89341 * gcc.dg/attr-alias-6.c: New test. * gcc.dg/attr-weakref-5.c: Likewise. Ping. Regards JunMa
Re: [PATCH][Tree-optimization/PR89772]fold memchr builtins for character not in constant nul-padded string
在 2019/3/21 下午12:51, JunMa 写道: Hi For now, gcc can not fold code like: const char a[5] = "123" __builtin_memchr (a, '7', sizeof a) It tries to avoid folding out of string length although length of a is 5. This is a bit conservative, it's safe to folding memchr/bcmp/memcmp builtins when constant string stores in array with some trailing nuls. This patch folds these cases by exposing additional length of trailing nuls in c_getstr(). Bootstrapped/regtested on x86_64-linux, ok for trunk? Regards JunMa gcc/ChangeLog 2019-03-21 Jun Ma PR Tree-optimization/89772 * fold-const.c (c_getstr): Add new parameter to get length of additional trailing nuls after constant string. * gimple-fold.c (gimple_fold_builtin_memchr): consider trailing nuls in out-of-bound accesses checking. * fold-const-call.c (fold_const_call): Likewise. gcc/testsuite/ChangeLog 2019-03-21 Jun Ma PR Tree-optimization/89772 * gcc.dg/builtin-memchr-4.c: New test. Ping. Regards JunMa
Re: [PATCH] Add simplification rule tanh (x) * cosh (x) -> sinh (x)
Hi On 04/30, Jeff Law wrote: > On 4/30/19 8:00 AM, Jakub Jelinek wrote: > > On Tue, Apr 30, 2019 at 07:57:20AM -0600, Jeff Law wrote: > >>> Just curious, do we want to add math identities like above to match.pd ? > >> I'd think so. > >> > >> > >>> In practice, I am not sure how often we'd see "tanh * cosh" instead > >>> of sinh directly in source, > >> We're often surprised when what ultimately shows up in sources :-) And > >> a transformation that allows us to turn two transcendentals and a > >> multiplication into a single transcendental is going to be a big win. > > I wonder why these kind of optimization are not in the EasyHacks page. It is somewhat easy to add it and can give huge performance improvements. There is a blogpost that I wrote about the previous patches I submitted here. I tried to be didadic, discussing from the mathematical standpoint, to floating point numbers, and GCC implementation. Although there may be several english errors, I think it is still useful: https://flusp.ime.usp.br/gcc/2019/03/26/making-gcc-optimize-some-trigonometric-functions/ > > I guess an important question is if such transformations need to be guarded > > by some -ffast-math suboptions, whether those transformations work properly > > for signed zeros, NaNs, sNaNs, infinities, guarantee the same ulp, have the > > same -ferrno-math behavior etc. > Yes. If you look at the discussion with Gualiano for the first set in > this space that was the hardest part. And for Barbara's we know there's > at least one issue in this space as well -- in particular it looks like > the long double handling is incorrect in the sign bit for very small > inputs. The question is precisely where that's gone wrong :-) > > jeff Giuliano.
RE: [PATCH] improve ifcvt optimization (PR rtl-optimization/89430)
Hi Jeff, Yes. The latter one "[PATCH] improve ifcvt optimization (PR rtl-optimization/89430)" supersedes the earlier one " Fixing ifcvt issue as exposed by BZ89430". Thanks, -Jiangning -Original Message- From: Jeff Law Sent: Tuesday, April 30, 2019 11:54 PM To: JiangNing OS ; gcc-patches@gcc.gnu.org Subject: Re: [PATCH] improve ifcvt optimization (PR rtl-optimization/89430) On 3/14/19 10:46 PM, JiangNing OS wrote: > This patch is to fix a missing ifcvt opportunity in back-end. For the > simple case below, > > if (...) > x = a; /* x is memory */ > /* no else */ > > We can generate conditional move and remove the branch as below if the target > cost is acceptable. > > r1 = x > r2 = a > cmp ... > csel r3, r1, r2, cond > x = r3 > > This could be safe if x is a stack variable, and there isn't any address > taken in current function, so the store speculation can be avoided. > > In practice, this optimization can improve a real application performance by > %4 on aarch64. [ ... ] I notice that a couple weeks you'd sent a similar patch under the heading "Fixing ifcvt issue as exposed by BZ89430". Does this patch supersede the earlier patch? Jeff
Re: [PATCH][AArch64] Emit TARGET_DOTPROD-specific sequence for sadv16qi
Kyrill Tkachov writes:
> @@ -764,6 +780,13 @@ (define_insn "aarch64_adalp_3"
> ;; UABAL tmp.8h, op1.16b, op2.16b
> ;; UADALPop3.4s, tmp.8h
> ;; MOV op0, op3 // should be eliminated in later passes.
> +;;
> +;; For TARGET_DOTPROD we do:
> +;; MOV tmp1.16b, #1 // Can be CSE'd and hoisted out of loops.
> +;; UABD tmp2.16b, op1.16b, op2.16b
> +;; UDOT op3.4s, tmp2.16b, tmp1.16b
> +;; MOV op0, op3 // RA will tie the operands of UDOT appropriately.
> +;;
> ;; The signed version just uses the signed variants of the above
> instructions.
It looks like the code does what the comment says, and uses SDOT for the
signed optab. Doesn't it need to be UDOT for both? The signedness of the
optab applies to the inputs (and so to SABD vs. UABD), but the absolute
difference is always unsigned.
>
> (define_expand "sadv16qi"
> @@ -773,6 +796,18 @@ (define_expand "sadv16qi"
> (use (match_operand:V4SI 3 "register_operand"))]
>"TARGET_SIMD"
>{
> +if (TARGET_DOTPROD)
> + {
> + rtx ones = gen_reg_rtx (V16QImode);
> + emit_move_insn (ones,
> + aarch64_simd_gen_const_vector_dup (V16QImode,
> + HOST_WIDE_INT_1));
Easier as:
rtx ones = force_reg (V16QImode, CONST1_RTX (V16QImode));
> + rtx abd = gen_reg_rtx (V16QImode);
> + emit_insn (gen_abdv16qi_3 (abd, operands[1], operands[2]));
> + emit_insn (gen_aarch64_dotv16qi (operands[0], operands[3],
> +abd, ones));
Nit: indented too far.
Thanks,
Richard
> + DONE;
> + }
> rtx reduc = gen_reg_rtx (V8HImode);
> emit_insn (gen_aarch64_abdl2v16qi_3 (reduc, operands[1],
> operands[2]));
> diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
> index
> 16e4dbda73ab928054590c47a4398408162c0332..5afb692493c6e9fa31355693e7843e4f0b1b281c
> 100644
> --- a/gcc/config/aarch64/iterators.md
> +++ b/gcc/config/aarch64/iterators.md
> @@ -1059,6 +1059,9 @@ (define_code_attr f16mac [(plus "a") (minus "s")])
> ;; Map smax to smin and umax to umin.
> (define_code_attr max_opp [(smax "smin") (umax "umin")])
>
> +;; Same as above, but louder.
> +(define_code_attr MAX_OPP [(smax "SMIN") (umax "UMIN")])
> +
> ;; The number of subvectors in an SVE_STRUCT.
> (define_mode_attr vector_count [(VNx32QI "2") (VNx16HI "2")
> (VNx8SI "2") (VNx4DI "2")
> diff --git a/gcc/testsuite/gcc.target/aarch64/ssadv16qi-dotprod.c
> b/gcc/testsuite/gcc.target/aarch64/ssadv16qi-dotprod.c
> new file mode 100644
> index
> ..e08c33785303e86815554e67a300189a67dfc1da
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/ssadv16qi-dotprod.c
> @@ -0,0 +1,31 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target arm_v8_2a_dotprod_neon_ok } */
> +/* { dg-add-options arm_v8_2a_dotprod_neon } */
> +/* { dg-additional-options "-O3" } */
> +
> +#pragma GCC target "+nosve"
> +
> +#define N 1024
> +
> +signed char pix1[N], pix2[N];
> +
> +int foo (void)
> +{
> + int i_sum = 0;
> + int i;
> +
> + for (i = 0; i < N; i++)
> +i_sum += __builtin_abs (pix1[i] - pix2[i]);
> +
> + return i_sum;
> +}
> +
> +/* { dg-final { scan-assembler-not {\tsshll\t} } } */
> +/* { dg-final { scan-assembler-not {\tsshll2\t} } } */
> +/* { dg-final { scan-assembler-not {\tssubl\t} } } */
> +/* { dg-final { scan-assembler-not {\tssubl2\t} } } */
> +/* { dg-final { scan-assembler-not {\tabs\t} } } */
> +
> +/* { dg-final { scan-assembler {\tsabd\t} } } */
> +/* { dg-final { scan-assembler {\tsdot\t} } } */
> +
> diff --git a/gcc/testsuite/gcc.target/aarch64/ssadv16qi.c
> b/gcc/testsuite/gcc.target/aarch64/ssadv16qi.c
> index
> 40b28843616e84df137210b45ec16abed2a37c75..85a867a113013f560bfd0a3142805b9c95ad8c5a
> 100644
> --- a/gcc/testsuite/gcc.target/aarch64/ssadv16qi.c
> +++ b/gcc/testsuite/gcc.target/aarch64/ssadv16qi.c
> @@ -1,7 +1,7 @@
> /* { dg-do compile } */
> /* { dg-options "-O3" } */
>
> -#pragma GCC target "+nosve"
> +#pragma GCC target "+nosve+nodotprod"
>
> #define N 1024
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/usadv16qi-dotprod.c
> b/gcc/testsuite/gcc.target/aarch64/usadv16qi-dotprod.c
> new file mode 100644
> index
> ..ea8de4d69758bd6bc9af9e33e1498f838b706949
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/usadv16qi-dotprod.c
> @@ -0,0 +1,30 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target arm_v8_2a_dotprod_neon_ok } */
> +/* { dg-add-options arm_v8_2a_dotprod_neon } */
> +/* { dg-additional-options "-O3" } */
> +
> +#pragma GCC target "+nosve"
> +
> +#define N 1024
> +
> +unsigned char pix1[N], pix2[N];
> +
> +int foo (void)
> +{
> + int i_sum = 0;
> + int i;
> +
> + for (i = 0; i < N; i++)
> +i_sum += __builtin_abs (pix1[i] - pix2[i]);
> +
> + return
Re: [PATCH] Improve API docs for header
On 04/05/19 17:43 +0200, Daniel Krügler wrote: Am Sa., 4. Mai 2019 um 16:37 Uhr schrieb Jonathan Wakely : * include/std/system_error (error_category, error_code) (error_condition): Improve docs. * libsupc++/exception: Add missing @addtogroup Doxygen command. * libsupc++/exception_ptr.h (exception_ptr): Link equality operators to class documentation. Suppress documentation for implementation details. * libsupc++/nested_exception.h (throw_with_nested, rethrow_if_nested): Suppress documentation for implementation details. Committed to trunk. The new docs for error_category say now: "An error category defines a context that give meaning to the integer * stored in an `error_code` or `error_category` object." The last "or `error_category`" looks misleading to me, did you mean "or `error_condition`" instead? I did, thanks. Fixed by the attached patch. commit b971ba70dce2532f14478f9beea173bb0180bd08 Author: Jonathan Wakely Date: Sat May 4 16:52:18 2019 +0100 Fix reference to wrong class in comment * include/std/system_error (error_category): Fix comment. diff --git a/libstdc++-v3/include/std/system_error b/libstdc++-v3/include/std/system_error index 768eddaefd1..3685348ee4d 100644 --- a/libstdc++-v3/include/std/system_error +++ b/libstdc++-v3/include/std/system_error @@ -77,7 +77,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION /** Abstract base class for types defining a category of error codes. * * An error category defines a context that give meaning to the integer - * stored in an `error_code` or `error_category` object. For example, + * stored in an `error_code` or `error_condition` object. For example, * the standard `errno` constants such a `EINVAL` and `ENOMEM` are * associated with the "generic" category and other OS-specific error * numbers are associated with the "system" category, but a user-defined
Re: [PATCH] Improve API docs for header
Am Sa., 4. Mai 2019 um 16:37 Uhr schrieb Jonathan Wakely : > > * include/std/system_error (error_category, error_code) > (error_condition): Improve docs. > * libsupc++/exception: Add missing @addtogroup Doxygen command. > * libsupc++/exception_ptr.h (exception_ptr): Link equality operators > to class documentation. Suppress documentation for implementation > details. > * libsupc++/nested_exception.h (throw_with_nested, rethrow_if_nested): > Suppress documentation for implementation details. > > Committed to trunk. The new docs for error_category say now: "An error category defines a context that give meaning to the integer * stored in an `error_code` or `error_category` object." The last "or `error_category`" looks misleading to me, did you mean "or `error_condition`" instead? - Daniel
[PATCH] PR libstdc++/90299 make filesystem::absolute overloads consistent
In this implementation it is an error to pass the empty path to absolute,
because the empty path doesn't represent any file in the filesystem so
the function cannot meet its postcondition.
Currently the absolute(const path&, error_code&) overload reports an
error for the empty path, but using errc::no_such_file_or_directory, and
the other overload does not report an error. This patch makes them
consistntly report an errc::invalid_argument error for the empty path.
PR libstdc++/90299
* src/c++17/fs_ops.cc (absolute(const path&)): Report an error if the
argument is an empty path.
(absolute(const path&, error_code&)): Use invalid_argument as error
code instead of no_such_file_or_directory.
* testsuite/27_io/filesystem/operations/absolute.cc: Check handling
of non-existent paths and empty paths with both overloads of absolute.
Tested powerpc64le-linux, committed to trunk.
I'll backport this to gcc-9-branch too.
commit 84eda927e0c194fd2d405a283c54b5456e425a45
Author: redi
Date: Sat May 4 14:35:33 2019 +
PR libstdc++/90299 make filesystem::absolute overloads consistent
In this implementation it is an error to pass the empty path to absolute,
because the empty path doesn't represent any file in the filesystem so
the function cannot meet its postcondition.
Currently the absolute(const path&, error_code&) overload reports an
error for the empty path, but using errc::no_such_file_or_directory, and
the other overload does not report an error. This patch makes them
consistntly report an errc::invalid_argument error for the empty path.
PR libstdc++/90299
* src/c++17/fs_ops.cc (absolute(const path&)): Report an error if
the
argument is an empty path.
(absolute(const path&, error_code&)): Use invalid_argument as error
code instead of no_such_file_or_directory.
* testsuite/27_io/filesystem/operations/absolute.cc: Check handling
of non-existent paths and empty paths with both overloads of
absolute.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@270874
138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
index 5ca523826cb..2d13b172d69 100644
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -72,6 +72,9 @@ fs::absolute(const path& p)
ec));
return ret;
#else
+ if (p.empty())
+_GLIBCXX_THROW_OR_ABORT(filesystem_error("cannot make absolute path", p,
+ make_error_code(std::errc::invalid_argument)));
return current_path() / p;
#endif
}
@@ -82,7 +85,7 @@ fs::absolute(const path& p, error_code& ec)
path ret;
if (p.empty())
{
- ec = make_error_code(std::errc::no_such_file_or_directory);
+ ec = make_error_code(std::errc::invalid_argument);
return ret;
}
ec.clear();
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/operations/absolute.cc
b/libstdc++-v3/testsuite/27_io/filesystem/operations/absolute.cc
index 45f66ac96c5..156e68ac87d 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/absolute.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/absolute.cc
@@ -67,9 +67,37 @@ test02()
#endif
}
+void
+test03()
+{
+ // PR libstdc++/90299
+ const path p = __gnu_test::nonexistent_path();
+ std::error_code ec;
+ const path pabs = absolute(p, ec);
+ VERIFY( !ec );
+ VERIFY( pabs.is_absolute() );
+
+ const path pabs2 = absolute(p);
+ VERIFY( pabs2 == pabs );
+
+ const path eabs = absolute(path{}, ec);
+ VERIFY( ec == std::errc::invalid_argument );
+ VERIFY( eabs.empty() );
+
+ try {
+absolute(path{});
+VERIFY( false );
+ } catch (const std::filesystem::filesystem_error& e) {
+VERIFY( e.code() == std::errc::invalid_argument );
+VERIFY( e.path1().empty() );
+VERIFY( e.path2().empty() );
+ }
+}
+
int
main()
{
test01();
test02();
+ test03();
}
[PATCH] Improve API docs for header
* include/std/system_error (error_category, error_code)
(error_condition): Improve docs.
* libsupc++/exception: Add missing @addtogroup Doxygen command.
* libsupc++/exception_ptr.h (exception_ptr): Link equality operators
to class documentation. Suppress documentation for implementation
details.
* libsupc++/nested_exception.h (throw_with_nested, rethrow_if_nested):
Suppress documentation for implementation details.
Committed to trunk.
commit e6af564ce9bab326e0a9693d374c37c95c8ad39d
Author: Jonathan Wakely
Date: Sat May 4 14:56:35 2019 +0100
Improve API docs for header
* include/std/system_error (error_category, error_code)
(error_condition): Improve docs.
* libsupc++/exception: Add missing @addtogroup Doxygen command.
* libsupc++/exception_ptr.h (exception_ptr): Link equality operators
to class documentation. Suppress documentation for implementation
details.
* libsupc++/nested_exception.h (throw_with_nested,
rethrow_if_nested):
Suppress documentation for implementation details.
diff --git a/libstdc++-v3/include/std/system_error
b/libstdc++-v3/include/std/system_error
index a60c96accb2..768eddaefd1 100644
--- a/libstdc++-v3/include/std/system_error
+++ b/libstdc++-v3/include/std/system_error
@@ -44,6 +44,10 @@ namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
+ /** @addtogroup diagnostics
+ * @{
+ */
+
class error_code;
class error_condition;
class system_error;
@@ -70,7 +74,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#endif // C++17
inline namespace _V2 {
- /// error_category
+ /** Abstract base class for types defining a category of error codes.
+ *
+ * An error category defines a context that give meaning to the integer
+ * stored in an `error_code` or `error_category` object. For example,
+ * the standard `errno` constants such a `EINVAL` and `ENOMEM` are
+ * associated with the "generic" category and other OS-specific error
+ * numbers are associated with the "system" category, but a user-defined
+ * category might give different meanings to the same numerical values.
+ */
class error_category
{
public:
@@ -131,18 +143,31 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
};
// DR 890.
- _GLIBCXX_CONST const error_category& system_category() noexcept;
+
+ /// Error category for `errno` error codes.
_GLIBCXX_CONST const error_category& generic_category() noexcept;
+ /// Error category for other error codes defined by the OS.
+ _GLIBCXX_CONST const error_category& system_category() noexcept;
+
} // end inline namespace
error_code make_error_code(errc) noexcept;
- template
-struct hash;
-
- /// error_code
- // Implementation-specific error identification
+ /** Class error_code
+ *
+ * This class is a value type storing an integer error number and a
+ * category that gives meaning to the error number. Typically this is done
+ * close the the point where the error happens, to capture the original
+ * error value.
+ *
+ * An `error_code` object can be used to store the original error value
+ * emitted by some subsystem, with a category relevant to the subsystem.
+ * For example, errors from POSIX library functions can be represented by
+ * an `errno` value and the "generic" category, but errors from an HTTP
+ * library might be represented by an HTTP response status code (e.g. 404)
+ * and a custom category defined by the library.
+ */
struct error_code
{
error_code() noexcept
@@ -198,6 +223,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
};
// 19.4.2.6 non-member functions
+
+ /// @relates error_code @{
+
inline error_code
make_error_code(errc __e) noexcept
{ return error_code(static_cast(__e), generic_category()); }
@@ -215,10 +243,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
operator<<(basic_ostream<_CharT, _Traits>& __os, const error_code& __e)
{ return (__os << __e.category().name() << ':' << __e.value()); }
+ // @}
+
error_condition make_error_condition(errc) noexcept;
- /// error_condition
- // Portable error identification
+ /** Class error_condition
+ *
+ * This class represents error conditions that may be visible at an API
+ * boundary. Different `error_code` values that can occur within a library
+ * or module might map to the same `error_condition`.
+ *
+ * An `error_condition` represents something that the program can test for,
+ * and subsequently take appropriate action.
+ */
struct error_condition
{
error_condition() noexcept
@@ -272,10 +309,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
};
// 19.4.3.6 non-member functions
+
+ /// Create an `error_condition` representing a standard `errc` condition.
+ /// @relates error_condition
inline error_condition
make_error_condition(errc __e) noexcept
{ return
Re: [PATCH] Implement LWG 2686, hash
On 03/05/19 23:42 +0100, Jonathan Wakely wrote:
On 23/03/17 17:49 +, Jonathan Wakely wrote:
On 12/03/17 13:16 +0100, Daniel Krügler wrote:
The following is an *untested* patch suggestion, please verify.
Notes: My interpretation is that hash should be
defined outside of the _GLIBCXX_COMPATIBILITY_CXX0X block, please
double-check that course of action.
That's right.
I noticed that the preexisting hash did directly refer to
the private members of error_code albeit those have public access
functions. For consistency I mimicked that existing style when
implementing hash.
I see no reason for that, so I've removed the friend declaration and
used the public member functions.
I'm going to do the same for hash too. It can also use the
public members instead of being a friend.
Although this is a DR, I'm treating it as a new C++17 feature, so I've
adjusted the patch to only add the new specialization for C++17 mode.
We're too close to the GCC 7 release to be adding new things to the
default mode, even minor things like this. After GCC 7 is released we
can revisit it and decide if we want to enable it for all modes.
We never revisited that, and it's still only enabled for C++17 and up.
I guess that's OK, but we could enabled it for C++11 and 14 on trunk
if we want. Anybody care enough to argue for that?
Here's what I've tested and will be committing.
commit 90ca0fd91f5c65af370beb20af06bdca257aaf63
Author: Jonathan Wakely
Date: Thu Mar 23 11:47:39 2017 +
Implement LWG 2686, std::hash, for C++17
2017-03-23 Daniel Kruegler
Implement LWG 2686, Why is std::hash specialized for error_code,
but not error_condition?
* include/std/system_error (hash): Define for C++17.
* testsuite/20_util/hash/operators/size_t.cc (hash):
Instantiate test for error_condition.
* testsuite/20_util/hash/requirements/explicit_instantiation.cc
(hash): Instantiate hash.
diff --git a/libstdc++-v3/include/std/system_error
b/libstdc++-v3/include/std/system_error
index 6775a6e..ec7d25f 100644
--- a/libstdc++-v3/include/std/system_error
+++ b/libstdc++-v3/include/std/system_error
@@ -373,14 +373,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace
-#ifndef _GLIBCXX_COMPATIBILITY_CXX0X
-
#include
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
+#ifndef _GLIBCXX_COMPATIBILITY_CXX0X
// DR 1182.
/// std::hash specialization for error_code.
template<>
@@ -394,12 +393,27 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return std::_Hash_impl::__hash_combine(__e._M_cat, __tmp);
}
};
+#endif // _GLIBCXX_COMPATIBILITY_CXX0X
+
+#if __cplusplus > 201402L
+ // DR 2686.
+ /// std::hash specialization for error_condition.
+ template<>
+struct hash
+: public __hash_base
+{
+ size_t
+ operator()(const error_condition& __e) const noexcept
+ {
+ const size_t __tmp = std::_Hash_impl::hash(__e.value());
+ return std::_Hash_impl::__hash_combine(__e.category(), __tmp);
When I changed this from using __e._M_cat (as in Daniel's patch) to
__e.category() I introduced a bug, because the former is a pointer to
the error_category (and error_category objects are unique and so can
be identified by their address) and the latter is the object itself,
so we hash the bytes of an abstract base class instead of hashing the
pointer to it. Oops.
Patch coming up to fix that.
Here's the fix. Tested powerpc64le-linux, committed to trunk.
I'll backport this to 7, 8 and 9 as well.
commit 43b5da521c2857f60eaaad90bbaf149ee6704797
Author: Jonathan Wakely
Date: Sat May 4 14:50:20 2019 +0100
Fix std::hash
The hash value should be based on the identity (i.e. address) of the
error_category member, not its object representation (i.e. underlying
bytes).
* include/std/system_error (error_code): Remove friend declaration
for hash.
(hash::operator()): Use public member functions to access
value and category.
(hash::operator()): Use address of category, not
its object representation.
* src/c++11/compatibility-c++0x.cc (hash::operator()):
Use public member functions to access value and category.
* testsuite/19_diagnostics/error_condition/hash.cc: New test.
diff --git a/libstdc++-v3/include/std/system_error b/libstdc++-v3/include/std/system_error
index b7891cbaa86..a60c96accb2 100644
--- a/libstdc++-v3/include/std/system_error
+++ b/libstdc++-v3/include/std/system_error
@@ -193,8 +193,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// DR 804.
private:
-friend class hash;
-
int _M_value;
const error_category* _M_cat;
};
@@ -394,13 +392,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
size_t
operator()(const error_code& __e) const noexcept
{
- const size_t __tmp = std::_Hash_impl::hash(__e._M_value);
- return
[wwwdocs] Clarify what "TBB" means and link to the project website
Committed to CVS. Index: htdocs/gcc-9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v retrieving revision 1.65 diff -u -r1.65 changes.html --- htdocs/gcc-9/changes.html 3 May 2019 12:26:31 - 1.65 +++ htdocs/gcc-9/changes.html 4 May 2019 14:25:49 - @@ -649,7 +649,8 @@ The C++17 implementation is no longer experimental. Parallel algorithms and execution -(requires TBB 2018 or newer). +(requires https://www.threadingbuildingblocks.org/;>Thread +Building Blocks 2018 or newer). memory_resource.
[PATCH] maintainer-scripts: create proper snapshots for GCC 9 and 10 (was: GCC 9.1 Released)
On Fri, 3 May 2019, Jakub Jelinek wrote: > We are proud to announce the next, major release of the > GNU Compiler Collection. I noticed that the latest GCC 9 snapshot actually identifies itself as GCC 10 since it's been carved from trunk, not the release branch. The update below, which I committed and also activated on gcc.gnu.org, should address this. We can then play with the days of the week the (now) four different snapshots run, but at least after tonight GCC 9 will have a proper snapshot again, and after tomorrow we'll start seeing ones for GCC 10. Gerald 2019-05-04 Gerald Pfeifer * crontab: Snapshots from trunk are now GCC 10 related. Add GCC 9 snapshots from the respective branch. Index: crontab === --- crontab (revision 270870) +++ crontab (working copy) @@ -3,4 +3,5 @@ 55 0 * * * sh /home/gccadmin/scripts/update_web_docs_libstdcxx_svn 32 22 * * 4 sh /home/gccadmin/scripts/gcc_release -s 7:branches/gcc-7-branch -l -d /sourceware/snapshot-tmp/gcc all 32 22 * * 5 sh /home/gccadmin/scripts/gcc_release -s 8:branches/gcc-8-branch -l -d /sourceware/snapshot-tmp/gcc all -32 22 * * 7 sh /home/gccadmin/scripts/gcc_release -s 9:trunk -l -d /sourceware/snapshot-tmp/gcc all +32 22 * * 6 sh /home/gccadmin/scripts/gcc_release -s 9:branches/gcc-9-branch -l -d /sourceware/snapshot-tmp/gcc all +32 22 * * 7 sh /home/gccadmin/scripts/gcc_release -s 10:trunk -l -d /sourceware/snapshot-tmp/gcc all
Re: Fix make check-debug RUNTESFLAGS=prettyprinters.exp
On 04/05/19 09:31 +0200, François Dumont wrote: Hi This patch allows to run pretty printer tests in _GLIBCXX_DEBUG mode. If accepted we could even integrate the pretty printers tests within the check-debug target like it is done for the check target. * python/libstdcxx/v6/printers.py (add_one_template_type_printer): Add type printer for container types in std::__debug namespace. * testsuite/lib/gdb-test.exp (whatis-regexp-test): New. (gdb-tests): Use distinct parameters for the type of test and use of regex. (gdb-test): Check for regex test even if 'whatis' test. * testsuite/libstdc++-prettyprinters/80276.cc: Adapt for _GLIBCXX_DEBUG mode. * testsuite/libstdc++-prettyprinters/cxx11.cc: Likewise. * testsuite/libstdc++-prettyprinters/cxx17.cc: Likewise. * testsuite/libstdc++-prettyprinters/libfundts.cc: Likewise. * testsuite/libstdc++-prettyprinters/simple.cc: Likewise. * testsuite/libstdc++-prettyprinters/simple11.cc: Likewise. * testsuite/libstdc++-prettyprinters/whatis.cc: Likewise. * testsuite/libstdc++-prettyprinters/whatis2.cc: Likewise. Looks good, I'm glad the actual printers.py file isn't made more complicated to support this. Tested under Linux x86_64 normal and debug modes. I only have 1 failure left in both normal and debug modes: got: type = std::unique_ptrstd::char_traits, std::allocator >>[]>>[99]> FAIL: libstdc++-prettyprinters/80276.cc whatis p4 But I think it is because of the usage of the C++11 abi std::string. That's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 Ok to commit ? OK for trunk, thanks.
Re: [PATCH][GCC][AArch64] Vectorise __builtin_signbit on aarch64
Przemyslaw Wirkus writes:
> Hi Richard,
> New patch adds a new IFN_SIGNBIT internal function that maps
> to signbit_optab.
Thanks.
> gcc/ChangeLog:
>
> 2019-05-05 Przemyslaw Wirkus
>
> * gcc/internal-fn.def (SIGNBIT): New.
> * gcc/config/aarch64/aarch64-simd.md (signbitv4sf2): New expand
> defined.
Sorry for the nitpicks (I'm not really a fan of ChangeLogs), but:
the filenames are relative to the changelog file, so no "gcc/" here and
> gcc/testsuite/ChangeLog:
>
> 2019-05-05 Przemyslaw Wirkus
>
> * gcc/testsuite/gcc.target/aarch64/signbitv4sf.c: New test.
no "gcc/testsuite/" here.
> diff --git a/gcc/config/aarch64/aarch64-simd.md
> b/gcc/config/aarch64/aarch64-simd.md
> index
> e3852c5d182b70978d7603225fce55c0b8ee2894..3374ce95b912cceaca49660df0579467f758974d
> 100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarch64-simd.md
> @@ -935,6 +935,21 @@
>[(set_attr "type" "neon_ins")]
> )
>
> +(define_expand "signbitv4sf2"
> + [(use (match_operand:V4SI 0 "register_operand"))
> + (use (match_operand:V4SF 1 "register_operand"))]
> + "TARGET_SIMD"
> +{
> + int shift_amount = GET_MODE_UNIT_BITSIZE (V4SImode) - 1;
> + rtx shift_vector = aarch64_simd_gen_const_vector_dup (V4SImode,
> + shift_amount);
> + operands[1] = lowpart_subreg (V4SImode, operands[1], V4SFmode);
> +
> + emit_insn (gen_aarch64_simd_lshrv4si (operands[0], operands[1],
> + shift_vector));
Formatting nit: argument should be indented to the column after the
innermost unclosed "(".
> + DONE;
> +})
> +
Looks good, but I think it can be generalised to handle v2sf if you use:
- :VDQSF instead of :V4SF
- instead of other instances of V4SF (and instead of v4sf)
- instead of V4SI (and instead of v4si)
E.g. this will handle SLP instances like:
void
f (int *i, float *f)
{
i[0] = __builtin_signbitf (f[0]);
i[1] = __builtin_signbitf (f[1]);
}
It could also be used for epilogue loop vectorisation, if we ever
turn that on by default for AArch64.
Thanks,
Richard
New Russian PO file for 'gcc' (version 9.1-b20190414)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Russian team of translators. The file is available at: https://translationproject.org/latest/gcc/ru.po (This file, 'gcc-9.1-b20190414.ru.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH] Fix PR90316
Richard Biener writes:
> On Fri, 3 May 2019, Richard Biener wrote:
>
>>
>> I am testing the following patch to remove the code determining
>> the target virtual operand to walk to and instead compute it
>> based on the immediate dominator which we will reach anyways
>> (or a dominating block) during maybe_skip_until.
>>
>> More simplifying might be possible but I'm trying to keep the
>> patch small and suitable for backporting up to the GCC 8 branch
>> where this regressed.
>>
>> Note this will handle even more CFG shapes now and seems to
>> expose some uninit warnings in dwarf2out.c (at least).
>
> I can't seem to find an initializer that would "trap" on use
> so I'm going to do
>
> Index: gcc/dwarf2out.c
> ===
> --- gcc/dwarf2out.c (revision 270849)
> +++ gcc/dwarf2out.c (working copy)
> @@ -15461,7 +15461,7 @@ mem_loc_descriptor (rtx rtl, machine_mod
>if (mode != GET_MODE (rtl) && GET_MODE (rtl) != VOIDmode)
> return NULL;
>
> - scalar_int_mode int_mode, inner_mode, op1_mode;
> + scalar_int_mode int_mode = SImode, inner_mode, op1_mode;
>switch (GET_CODE (rtl))
> {
> case POST_INC:
>
> unless somebody comes up with something clever over the weekend...
Nothing clever, but something rare like BImode is probably safer than
SImode, in case doing this masks real "uninitialised" uses in future.
Thanks,
Richard
[PATCH] Add myself to MAINTAINERS
Already committed, as per https://www.gnu.org/software/gcc/svnwrite.html. 2019-05-04 Roland Illig * MAINTAINERS (Write After Approval): Add myself. Index: MAINTAINERS === --- MAINTAINERS (Revision 270868) +++ MAINTAINERS (Revision 270869) @@ -427,6 +427,7 @@ Andrew John Hughes Dominique d'Humieres Andy Hutchinson Naveen H.S +Roland Illig Meador Inge Bernardo Innocenti Alexander Ivchenko
Fix make check-debug RUNTESFLAGS=prettyprinters.exp
Hi
This patch allows to run pretty printer tests in _GLIBCXX_DEBUG
mode. If accepted we could even integrate the pretty printers tests
within the check-debug target like it is done for the check target.
* python/libstdcxx/v6/printers.py (add_one_template_type_printer):
Add type printer for container types in std::__debug namespace.
* testsuite/lib/gdb-test.exp (whatis-regexp-test): New.
(gdb-tests): Use distinct parameters for the type of test and use of
regex.
(gdb-test): Check for regex test even if 'whatis' test.
* testsuite/libstdc++-prettyprinters/80276.cc: Adapt for _GLIBCXX_DEBUG
mode.
* testsuite/libstdc++-prettyprinters/cxx11.cc: Likewise.
* testsuite/libstdc++-prettyprinters/cxx17.cc: Likewise.
* testsuite/libstdc++-prettyprinters/libfundts.cc: Likewise.
* testsuite/libstdc++-prettyprinters/simple.cc: Likewise.
* testsuite/libstdc++-prettyprinters/simple11.cc: Likewise.
* testsuite/libstdc++-prettyprinters/whatis.cc: Likewise.
* testsuite/libstdc++-prettyprinters/whatis2.cc: Likewise.
Tested under Linux x86_64 normal and debug modes.
I only have 1 failure left in both normal and debug modes:
got: type =
std::unique_ptrstd::char_traits, std::allocator >>[]>>[99]>
FAIL: libstdc++-prettyprinters/80276.cc whatis p4
But I think it is because of the usage of the C++11 abi std::string.
Ok to commit ?
François
diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 8f16b53c953..19d367295df 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -1565,6 +1565,11 @@ def add_one_template_type_printer(obj, name, defargs):
"""
printer = TemplateTypePrinter('std::'+name, defargs)
gdb.types.register_type_printer(obj, printer)
+
+# Add type printer for same type in debug namespace:
+printer = TemplateTypePrinter('std::__debug::'+name, defargs)
+gdb.types.register_type_printer(obj, printer)
+
if _versioned_namespace:
# Add second type printer for same type in versioned namespace:
ns = 'std::' + _versioned_namespace
diff --git a/libstdc++-v3/testsuite/lib/gdb-test.exp b/libstdc++-v3/testsuite/lib/gdb-test.exp
index a6ae44b8283..bd35d478b7e 100644
--- a/libstdc++-v3/testsuite/lib/gdb-test.exp
+++ b/libstdc++-v3/testsuite/lib/gdb-test.exp
@@ -55,7 +55,7 @@ proc get_line_number {filename marker} {
proc note-test {var result} {
global gdb_tests
-lappend gdb_tests $var $result 0
+lappend gdb_tests $var $result print 0
}
# A test that uses a regular expression. This is like note-test, but
@@ -64,14 +64,22 @@ proc note-test {var result} {
proc regexp-test {var result} {
global gdb_tests
-lappend gdb_tests $var $result 1
+lappend gdb_tests $var $result print 1
}
# A test of 'whatis'. This tests a type rather than a variable.
proc whatis-test {var result} {
global gdb_tests
-lappend gdb_tests $var $result whatis
+lappend gdb_tests $var $result whatis 0
+}
+
+# A test of 'whatis' that uses a regular expression. This tests a type rather
+# than a variable.
+proc whatis-regexp-test {var result} {
+global gdb_tests
+
+lappend gdb_tests $var $result whatis 1
}
# Utility for testing variable values using gdb, invoked via dg-final.
@@ -136,13 +144,14 @@ proc gdb-test { marker {selector {}} {load_xmethods 0} } {
puts $fd "info share"
set count 0
-foreach {var result kind} $gdb_tests {
+foreach {var result kind rexp} $gdb_tests {
incr count
set gdb_var($count) $var
set gdb_expected($count) $result
if {$kind == "whatis"} {
if {$do_whatis_tests} {
set gdb_is_type($count) 1
+ set gdb_is_regexp($count) $rexp
set gdb_command($count) "whatis $var"
} else {
unsupported "$testname"
@@ -151,7 +160,7 @@ proc gdb-test { marker {selector {}} {load_xmethods 0} } {
}
} else {
set gdb_is_type($count) 0
- set gdb_is_regexp($count) $kind
+ set gdb_is_regexp($count) $rexp
set gdb_command($count) "print $var"
}
puts $fd $gdb_command($count)
@@ -179,9 +188,9 @@ proc gdb-test { marker {selector {}} {load_xmethods 0} } {
if {$expect_out(1,string) != "type"} {
error "gdb failure"
}
- set match [expr {![string compare $first \
- $gdb_expected($test_counter)]}]
- } elseif {$gdb_is_regexp($test_counter)} {
+ }
+
+ if {$gdb_is_regexp($test_counter)} {
set match [regexp -- $gdb_expected($test_counter) $first]
} else {
set match [expr {![string compare $first \
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc b/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
index fde652e1635..fd67aaf3b70 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
@@ -41,10 +41,10 @@ main()
unique_ptr*>>[]> p2;
