Re: [PATCH] rs6000: Parameterize some const values for density test

[Kewen.Lin via Gcc-patches]

on 2021/9/18 上午6:26, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, Sep 15, 2021 at 04:52:49PM +0800, Kewen.Lin wrote:
>> This patch follows the discussion here[1], where Segher suggested
>> parameterizing those exact magic constants for density heuristics,
>> to make it easier to tweak if need.
>>
>> Since these heuristics are quite internal, I make these parameters
>> as undocumented and be mainly used by developers.
> 
> Okido.
> 
>> +  if (data->nloads > (unsigned int) rs6000_density_load_num_threshold
>> +  && load_pct > (unsigned int) rs6000_density_load_pct_threshold)
> 
> Those variables are unsigned int already.  Don't cast please.
> 

Unfortunately this is required by bootstrapping.  The UInteger for the
param definition is really confusing, in the underlying implementation
it's still "signed".  If you grep "(unsigned) param", you can see a few
examples.  I guess the "UInteger" is mainly for the param value range
checking.

>> +-param=rs6000-density-pct-threshold=
>> +Target Undocumented Joined UInteger Var(rs6000_density_pct_threshold) 
>> Init(85) IntegerRange(0, 99) Param
> 
> So make this and all other percentages (0, 100) please.
> 

I thought 99 is enough for the RHS in ">". just realized it's more clear
with 100.  Will fix!

>> +When costing for loop vectorization, we probably need to penalize the loop 
>> body cost if the existing cost model may not adequately reflect delays from 
>> unavailable vector resources.  We collect the cost for vectorized statements 
>> and non-vectorized statements separately, check the proportion of vec_cost 
>> to total cost of vec_cost and non vec_cost, and penalize only if the 
>> proportion exceeds the threshold specified by this parameter.  The default 
>> value is 85.
> 
> It would be good if we can use line breaks in the source code for things
> like this, but I don't think we can.  This message is mainly used for
> "--help=param", and it is good there to have as short messages as you
> can.  But given the nature of params you need quite a few words often,
> and you do not want to say so little that things are no clear, either.
> 
> So, dunno :-)

I did some testings, the line breaks writing can still survive in the
"--help=param" show, the lines are concatenated with " ".  Although
there seems no this kind of writing practices, I am guessing you want
me to do line breaks for their descriptions?  If so, I will make them
short as the above "Target Undocumented..." line.  Or do you want it
to align source code ColumnLimit 80 (for these cases, it would look
shorter)?

> 
> Oksy for trunk with these fixes and what Bill mentioned in the other
> thread.  Thanks!
> 

OK, thanks again!

BR,
Kewen

Re: [PATCH] Simplify paradoxical subreg extensions of TRUNCATE

[Jeff Law via Gcc-patches]

On 9/20/2021 6:23 PM, Segher Boessenkool wrote:

Hi!

On Sun, Sep 19, 2021 at 09:14:55AM -0600, Jeff Law wrote:

On 9/6/2021 8:24 AM, Segher Boessenkool wrote:

On Mon, Sep 06, 2021 at 12:32:13PM +0100, Roger Sayle wrote:

I think the current documentation is sufficient.  During compilation,
GCC's
combine pass will often substitute a register with an expression defining
it's value, and then attempt to simplify it.  As you point out, this often
produces
(temporary intermediate) expressions with poorly defined semantics.

Not "poorly defined".  The documentation says (in rtl.texi)

@findex subreg
@item (subreg:@var{m1} @var{reg:m2} @var{bytenum})

@code{subreg} expressions are used to refer to a register in a machine
mode other than its natural one, or to refer to one register of
a multi-part @code{reg} that actually refers to several registers.

It goes on to say there also are subregs of mem currently; it
exhaustively lists all things you can take a subreg of, what the
different semantics of those are, how the semantics are further
"modified" (read: completely different) if some RTL flags are set, etc.

The instruction combiner very often creates invalid RTL (only
structurally valid, like, no missing operands).  Invalid RTL is supposed
to never match (because backends will not have patterns that match
these).  combine even creates invalid RTL on purpose (a clobber of
const0_rtx) to ensure its result is deemed invalid, when it wants to
abort a combination attempt for some reason.


The
purpose of my patch is to avoid (constructing) SUBREGs that have TRUNCATE
as an argument (that some folks consider undefined) and instead simplify
them to either a single TRUNCATE or a SUBREG of a REG, both of which are
well defined.  I'm making/helping the implementation match the
documentation.

But this should never make it to simplify-rtx at all.  You can only
validly do such transformations in combine, because you need to know
what insns you started with etc.

simplify-rtx is a part of combine, sure, but it is used from other
contexts as well nowadays.  If you can safely do this from combine,
you can do it in combine.

[ ... ]
So what I think is missing here is some concrete path forward.  If I'm
understanding your objection Segher, you'd like to see Roger look at
where these (subreg (truncate)) expressions came from and address them
earlier than simplify_rtx?

There is no such thing as "earlier than simplify-rtx", that is the
point.  simplify-rtx is not a pass: it is like a library that is used
from all over the RTL routines.
I'm referring to earlier in the call chain, not an earlier pass. Sorry I 
wasn't clear about that.


If we were catching the scenario which led to the creation of (subreg 
(truncate)) in combine and instead of creating (subreg (truncate)) we 
instead created the simplified, correct form would that ease your concerns?




Jeff

[Bug target/102421] [12 Regression] ICE with -march=armv8.2-a+sve -O3

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102421

--- Comment #4 from Andrew Pinski  ---
Created attachment 51488
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51488=edit
trimmed preprocessed source a lot

Re: [PATCH] rs6000: Parameterize some const values for density test

[Kewen.Lin via Gcc-patches]

Hi Bill,

Thanks for the review!

on 2021/9/18 上午12:27, Bill Schmidt wrote:
> Hi Kewen,
> 
> On 9/15/21 3:52 AM, Kewen.Lin wrote:
>> Hi,
>>
>> This patch follows the discussion here[1], where Segher suggested
>> parameterizing those exact magic constants for density heuristics,
>> to make it easier to tweak if need.
>>
>> Since these heuristics are quite internal, I make these parameters
>> as undocumented and be mainly used by developers.
>>
>> The change here should be "No Functional Change".  But I verified
>> it with SPEC2017 at option sets O2-vect and Ofast-unroll on Power8,
>> the result is neutral as expected.
>>
>> Bootstrapped and regress-tested on powerpc64le-linux-gnu Power9.
>>
>> Is it ok for trunk?
>>
>> [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579121.html
>>
>> BR,
>> Kewen
>> -
>> gcc/ChangeLog:
>>
>> * config/rs6000/rs6000.opt (rs6000-density-pct-threshold,
>> rs6000-density-size-threshold, rs6000-density-penalty,
>> rs6000-density-load-pct-threshold,
>> rs6000-density-load-num-threshold): New parameter.
>> * config/rs6000/rs6000.c (rs6000_density_test): Adjust with
>> corresponding parameters.
>>
>> ---
>>   gcc/config/rs6000/rs6000.c   | 22 +++---
>>   gcc/config/rs6000/rs6000.opt | 21 +
>>   2 files changed, 28 insertions(+), 15 deletions(-)
>>
>> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
>> index 9bc826e3a50..4ab23b0ab33 100644
>> --- a/gcc/config/rs6000/rs6000.c
>> +++ b/gcc/config/rs6000/rs6000.c
>> @@ -5284,9 +5284,6 @@ struct rs6000_cost_data
>>   static void
>>   rs6000_density_test (rs6000_cost_data *data)
>>   {
>> -  const int DENSITY_PCT_THRESHOLD = 85;
>> -  const int DENSITY_SIZE_THRESHOLD = 70;
>> -  const int DENSITY_PENALTY = 10;
>>     struct loop *loop = data->loop_info;
>>     basic_block *bbs = get_loop_body (loop);
>>     int nbbs = loop->num_nodes;
>> @@ -5322,26 +5319,21 @@ rs6000_density_test (rs6000_cost_data *data)
>>     free (bbs);
>>     density_pct = (vec_cost * 100) / (vec_cost + not_vec_cost);
>>
>> -  if (density_pct > DENSITY_PCT_THRESHOLD
>> -  && vec_cost + not_vec_cost > DENSITY_SIZE_THRESHOLD)
>> +  if (density_pct > rs6000_density_pct_threshold
>> +  && vec_cost + not_vec_cost > rs6000_density_size_threshold)
>>   {
>> -  data->cost[vect_body] = vec_cost * (100 + DENSITY_PENALTY) / 100;
>> +  data->cost[vect_body] = vec_cost * (100 + rs6000_density_penalty) / 
>> 100;
>>     if (dump_enabled_p ())
>>   dump_printf_loc (MSG_NOTE, vect_location,
>>    "density %d%%, cost %d exceeds threshold, penalizing "
>> - "loop body cost by %d%%\n", density_pct,
>> - vec_cost + not_vec_cost, DENSITY_PENALTY);
>> + "loop body cost by %u%%\n", density_pct,
>> + vec_cost + not_vec_cost, rs6000_density_penalty);
>>   }
>>
>>     /* Check whether we need to penalize the body cost to account
>>    for excess strided or elementwise loads.  */
>>     if (data->extra_ctor_cost > 0)
>>   {
>> -  /* Threshold for load stmts percentage in all vectorized stmts.  */
>> -  const int DENSITY_LOAD_PCT_THRESHOLD = 45;
>> -  /* Threshold for total number of load stmts.  */
>> -  const int DENSITY_LOAD_NUM_THRESHOLD = 20;
>> -
>>     gcc_assert (data->nloads <= data->nstmts);
>>     unsigned int load_pct = (data->nloads * 100) / data->nstmts;
>>
>> @@ -5355,8 +5347,8 @@ rs6000_density_test (rs6000_cost_data *data)
>>     the loads.
>>    One typical case is the innermost loop of the hotspot of SPEC2017
>>    503.bwaves_r without loop interchange.  */
>> -  if (data->nloads > DENSITY_LOAD_NUM_THRESHOLD
>> -  && load_pct > DENSITY_LOAD_PCT_THRESHOLD)
>> +  if (data->nloads > (unsigned int) rs6000_density_load_num_threshold
>> +  && load_pct > (unsigned int) rs6000_density_load_pct_threshold)
>>   {
>>     data->cost[vect_body] += data->extra_ctor_cost;
>>     if (dump_enabled_p ())
>> diff --git a/gcc/config/rs6000/rs6000.opt b/gcc/config/rs6000/rs6000.opt
>> index 0538db387dc..563983f3269 100644
>> --- a/gcc/config/rs6000/rs6000.opt
>> +++ b/gcc/config/rs6000/rs6000.opt
>> @@ -639,3 +639,24 @@ Enable instructions that guard against return-oriented 
>> programming attacks.
>>   mprivileged
>>   Target Var(rs6000_privileged) Init(0)
>>   Generate code that will run in privileged state.
>> +
>> +-param=rs6000-density-pct-threshold=
>> +Target Undocumented Joined UInteger Var(rs6000_density_pct_threshold) 
>> Init(85) IntegerRange(0, 99) Param
>> +When costing for loop vectorization, we probably need to penalize the loop 
>> body cost if the existing cost model may not adequately reflect delays from 
>> unavailable vector resources.  We collect the cost for vectorized statements 
>> and non-vectorized statements separately, check the proportion of vec_cost 
>> to total cost of vec_cost and non vec_cost, and 

Re: [PATCH] rs6000: Modify the way for extra penalized cost

[Kewen.Lin via Gcc-patches]

Hi Segher,

Thanks for the review!

on 2021/9/18 上午6:01, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Sep 16, 2021 at 09:14:15AM +0800, Kewen.Lin wrote:
>> The way with nunits * stmt_cost can get one much exaggerated
>> penalized cost, such as: for V16QI on P8, it's 16 * 20 = 320,
>> that's why we need one bound.  To make it scale, this patch
>> doesn't use nunits * stmt_cost any more, but it still keeps
>> nunits since there are actually nunits scalar loads there.  So
>> it uses one cost adjusted from stmt_cost, since the current
>> stmt_cost sort of considers nunits, we can stablize the cost
>> for big nunits and retain the cost for small nunits.  After
>> some tries, this patch gets the adjusted cost as:
>>
>> stmt_cost / (log2(nunits) * log2(nunits))
> 
> So for  V16QI it gives *16/(4*4) so *1
> V8HI  it gives *8/(3*3)  so *8/9
> V4SI  it gives *4/(2*2)  so *1
> V2DI  it gives *2/(1*1)  so *2
> and for V1TI  it gives *1/(0*0) which is UB (no, does not crash for us,
> just gives wildly wrong answers; the div returns 0 on recent systems).
> 

I don't expected we will have V1TI for strided/elementwise load,
if it's one unit vector, it's the whole vector itself.
Besides, the below assertion should exclude it already.

>> For V16QI, the adjusted cost would be 1 and total penalized
>> cost is 16, it isn't exaggerated.  For V2DI, the adjusted
>> cost would be 2 and total penalized cost is 4, which is the
>> same as before.  btw, I tried to use one single log2(nunits),
>> but the penalized cost is still big enough and can't fix the
>> degraded bmk blender_r.
> 
> Does it make sense to treat V2DI (and V2DF) as twice more expensive than
> other vectors, which are all pretty much equal cost (except those that
> end up with cost 0)?  If so, there are simpler ways to do that.
> 

Yeah, from the SPEC2017 evaluation, it's good with this.  The costing
framework of vectorization doesn't consider the dependent insn chain
and available #unit etc. like local scheduling (it can't either), so
we have to use some heuristics to handle some special cases.  For more
units vector construction, the used instructions are more.  It has more
chances to schedule them better (even run in parallelly when enough
available units at the time), so we don't need to penalize more for them.
For V2DI, the load result is fed into construction directly, the current
stmt_cost is to consider merging and only 2, penalizing it with one is
not enough from the bwaves experiment.

>> +  int nunits_log2 = exact_log2 (nunits);
>> +  gcc_assert (nunits_log2 > 0);
>> +  unsigned int nunits_sq = nunits_log2 * nunits_log2;
> 
>> = 0
> 
> This of course is assuming nunits will always be a power of 2, but I'm
> sure that we have many other places in the compiler assuming that
> already, so that is fine.  And if one day this stops being true we will
> get a nice ICE, pretty much the best we could hope for.
> 

Yeah, exact_log2 returns -1 for non power of 2 input, for example:

input output
0 ->-1
1 ->0
2 ->1
3 ->-1

>> +  unsigned int adjusted_cost = stmt_cost / nunits_sq;
> 
> But this can divide by 0.  Or are we somehow guaranteed that nunits
> will never be 1?  Yes the log2 check above, sure, but that ICEs if this
> is violated; is there anything that actually guarantees it is true?
> 

As I mentioned above, I don't expect we can have nunits 1 strided/ew load,
and the ICE should check this and ensure dividing by zero never happens.  :)

>> +  gcc_assert (adjusted_cost > 0);
> 
> I don't see how you guarantee this, either.
> 

It's mainly to prevent that one day we tweak the cost for construction
in rs6000_builtin_vectorization_cost then make some unexpected values
generated here.  But now these expected values are guaranteed as the
current costs and the formula.

> 
> A magic crazy formula like this is no good.  If you want to make the
> cost of everything but V2D* be the same, and that of V2D* be twice that,
> that is a weird heuristic, but we can live with that perhaps.  But that
> beats completely unexplained (and unexplainable) magic!
> 
> Sorry.
> 

That's all right, thanks for the comments!  let's improve it.  :)
How about just assigning 2 for V2DI and 1 for the others for the
penalized_cost_per_load with some detailed commentary, it should have
the same effect with this "magic crazy formula", but I guess it can
be more clear.

BR,
Kewen

Re: [PATCH] rs6000: Modify the way for extra penalized cost

[Kewen.Lin via Gcc-patches]

Hi Bill,

Thanks for the review!

on 2021/9/18 上午12:34, Bill Schmidt wrote:
> Hi Kewen,
> 
> On 9/15/21 8:14 PM, Kewen.Lin wrote:
>> Hi,
>>
>> This patch follows the discussion here[1], where Segher pointed
>> out the existing way to guard the extra penalized cost for
>> strided/elementwise loads with a magic bound doesn't scale.
>>
>> The way with nunits * stmt_cost can get one much exaggerated
>> penalized cost, such as: for V16QI on P8, it's 16 * 20 = 320,
>> that's why we need one bound.  To make it scale, this patch
>> doesn't use nunits * stmt_cost any more, but it still keeps
>> nunits since there are actually nunits scalar loads there.  So
>> it uses one cost adjusted from stmt_cost, since the current
>> stmt_cost sort of considers nunits, we can stablize the cost
>> for big nunits and retain the cost for small nunits.  After
>> some tries, this patch gets the adjusted cost as:
>>
>>  stmt_cost / (log2(nunits) * log2(nunits))
>>
>> For V16QI, the adjusted cost would be 1 and total penalized
>> cost is 16, it isn't exaggerated.  For V2DI, the adjusted
>> cost would be 2 and total penalized cost is 4, which is the
>> same as before.  btw, I tried to use one single log2(nunits),
>> but the penalized cost is still big enough and can't fix the
>> degraded bmk blender_r.
>>
>> The separated SPEC2017 evaluations on Power8, Power9 and Power10
>> at option sets O2-vect and Ofast-unroll showed this change is
>> neutral (that is same effect as before).
>>
>> Bootstrapped and regress-tested on powerpc64le-linux-gnu Power9.
>>
>> Is it ok for trunk?
>>
>> [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579121.html
>>
>> BR,
>> Kewen
>> -
>> gcc/ChangeLog:
>>
>> * config/rs6000/rs6000.c (rs6000_update_target_cost_per_stmt): Adjust
>> the way to compute extra penalized cost.
>>
>> ---
>>   gcc/config/rs6000/rs6000.c | 28 +---
>>   1 file changed, 17 insertions(+), 11 deletions(-)
>>
>> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
>> index 4ab23b0ab33..e08b94c0447 100644
>> --- a/gcc/config/rs6000/rs6000.c
>> +++ b/gcc/config/rs6000/rs6000.c
>> @@ -5454,17 +5454,23 @@ rs6000_update_target_cost_per_stmt (rs6000_cost_data 
>> *data,
>>   {
>>     tree vectype = STMT_VINFO_VECTYPE (stmt_info);
>>     unsigned int nunits = vect_nunits_for_cost (vectype);
>> -  unsigned int extra_cost = nunits * stmt_cost;
>> -  /* As function rs6000_builtin_vectorization_cost shows, we have
>> - priced much on V16QI/V8HI vector construction as their units,
>> - if we penalize them with nunits * stmt_cost, it can result in
>> - an unreliable body cost, eg: for V16QI on Power8, stmt_cost
>> - is 20 and nunits is 16, the extra cost is 320 which looks
>> - much exaggerated.  So let's use one maximum bound for the
>> - extra penalized cost for vector construction here.  */
>> -  const unsigned int MAX_PENALIZED_COST_FOR_CTOR = 12;
>> -  if (extra_cost > MAX_PENALIZED_COST_FOR_CTOR)
>> -    extra_cost = MAX_PENALIZED_COST_FOR_CTOR;
>> +  /* As function rs6000_builtin_vectorization_cost shows, we
>> + have priced much on V16QI/V8HI vector construction by
>> + considering their units, if we penalize them with nunits
>> + * stmt_cost here, it can result in an unreliable body cost,
> 
> This might be confusing to the reader, since you have deleted the calculation 
> of nunits * stmt_cost.  Could you instead write this to indicate that we used 
> to adjust in this way, and it had this particular downside, so that's why 
> you're choosing this heuristic? It's a minor thing but I think people reading 
> the code will be confused otherwise.
> 

Good point!  I'll update the commentary to explain it, thanks!!

BR,
Kewen 

> I think the heuristic is generally reasonable, and certainly better than what 
> we had before!
> 
> LGTM with adjusted commentary, so recommend maintainers approve.
> 
> Thanks for the patch!
> Bill
>> + eg: for V16QI on Power8, stmt_cost is 20 and nunits is 16,
>> + the penalty will be 320 which looks much exaggerated.  But
>> + there are actually nunits scalar loads, so we try to adopt
>> + one reasonable penalized cost for each load rather than
>> + stmt_cost.  Here, with stmt_cost dividing by log2(nunits)^2,
>> + we can still retain the necessary penalty for small nunits
>> + meanwhile stabilize the penalty for big nunits.  */
>> +  int nunits_log2 = exact_log2 (nunits);
>> +  gcc_assert (nunits_log2 > 0);
>> +  unsigned int nunits_sq = nunits_log2 * nunits_log2;
>> +  unsigned int adjusted_cost = stmt_cost / nunits_sq;
>> +  gcc_assert (adjusted_cost > 0);
>> +  unsigned int extra_cost = nunits * adjusted_cost;
>>     data->extra_ctor_cost += extra_cost;
>>   }
>>   }
>> -- 
>> 2.25.1
> 

[Bug target/102421] [12 Regression] ICE with -march=armv8.2-a+sve -O3

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102421

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE with|[12 Regression] ICE with
   |-march=armv8.2-a+sve -O3|-march=armv8.2-a+sve -O3
   Target Milestone|--- |12.0

[Bug target/102421] ICE with -march=armv8.2-a+sve -O3

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102421

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #3 from Andrew Pinski  ---
Reducing, Can reproduce it with r12-3568.

Re: [PATCH v2] ipa-inline: Add target info into fn summary [PR102059]

[Kewen.Lin via Gcc-patches]

Hi Martin,

on 2021/9/17 下午7:26, Martin Jambor wrote:
> Hi,
> 
> On Fri, Sep 17 2021, Kewen.Lin wrote:
>> on 2021/9/16 下午9:19, Martin Jambor wrote:
>>> On Thu, Sep 16 2021, Kewen.Lin wrote:
 on 2021/9/15 下午8:51, Martin Jambor wrote:
> On Wed, Sep 08 2021, Kewen.Lin wrote:
>>
>
> [...]
>
>> diff --git a/gcc/ipa-fnsummary.h b/gcc/ipa-fnsummary.h
>> index 78399b0b9bb..300b8da4507 100644
>> --- a/gcc/ipa-fnsummary.h
>> +++ b/gcc/ipa-fnsummary.h
>> @@ -193,6 +194,9 @@ public:
>>vec *loop_strides;
>>/* Parameters tested by builtin_constant_p.  */
>>vec GTY((skip)) builtin_constant_p_parms;
>> +  /* Like fp_expressions, but it's to hold some target specific 
>> information,
>> + such as some target specific isa flags.  */
>> +  auto_vec GTY((skip)) target_info;
>>/* Estimated growth for inlining all copies of the function before 
>> start
>>   of small functions inlining.
>>   This value will get out of date as the callers are duplicated, but
>
> Segher already wrote in the first thread that a vector of HOST_WIDE_INTs
> is an overkill and I agree.  So at least make the new field just a
> HOST_WIDE_INT or better yet, an unsigned int.  But I would even go
> further and make target_info only a 16-bit bit-field, place it after the
> other bit-fields in class ipa_fn_summary and pass it to the hooks as
> uint16_t.  Unless you have plans which require more space, I think we
> should be conservative here.
>

 OK, yeah, the consideration is mainly for the scenario that target has
 a few bits to care about.  I just realized that to avoid inefficient
 bitwise operation for mapping target info bits to isa_flag bits, target
 can rearrange the sparse bits in isa_flag, so it's not a deal.
 Thanks for re-raising this!  I'll use the 16 bits bit-field in v3 as you
 suggested, if you don't mind, I will put it before the existing bit-fields
 to have a good alignment.
>>>
>>> All right.
>>>
>>
>> Sorry that I failed to use 16 bit-fields for this, I figured out that
>> the bit-fields can not be address-taken or passed as non-const reference.
>> The gentype also failed to recognize uint16_t if I used uint16_t directly
>> in ipa-fnsummary.h.  Finally I used unsigned int instead.
>>
> 
> well, you could have used:
> 
>   unsigned int target_info : 16;
> 
> for the field (and uint16_t when passed to hooks).
> 
> But I am not sure if it is that crucial.
> 

I may miss something, specifically I tried with:

1)

  unsigned int target_info : 16;
  unsigned inlinable : 1;
  ...

  update_ipa_fn_target_info (uint16_t &, const gimple *)

2)

  unsigned int target_info : 16;
  unsigned inlinable : 1;
  ...

  update_ipa_fn_target_info (uint16_t *, const gimple *)

The above two ways failed due to:

"Because bit fields do not necessarily begin at the beginning of a byte,
address of a bit field cannot be taken. Pointers and non-const references
to bit fields are not possible." as [1].

Although we can change the hook prototype to

  bool update_ipa_fn_target_info (const uint16_t, const gimple*, uint16_t&)

or

  uint16_t update_ipa_fn_target_info (const uint16_t, const gimple*, bool&)

to workaround bit field limitation, it looks weird and inefficient.

3)

  ...
  unsigned int fp_expressions : 1;
  uint16_t target_info;

  update_ipa_fn_target_info (uint16_t &, const gimple *)

it fails due to gengtype erroring:

gcc/ipa-fnsummary.h:171: undefined type `uint16_t'
gengtype: didn't write state file tmp-gtype.state after errors


Then I gave up and guessed it's not so crucial like you said, 
and used unsigned int instead. :)

[1] https://en.cppreference.com/w/cpp/language/bit_field

BR,
Kewen

Re: [PATCH] ipa-fnsummary: Remove inconsistent bp_pack_value

[Kewen.Lin via Gcc-patches]

Hi Richi,

Thanks for the review!

on 2021/9/17 下午6:04, Richard Biener wrote:
> On Fri, Sep 17, 2021 at 12:03 PM Richard Biener
>  wrote:
>>
>> On Fri, Sep 17, 2021 at 11:43 AM Kewen.Lin  wrote:
>>>
>>> Hi,
>>>
>>> When changing target_info with bitfield, I happened to find this
>>> inconsistent streaming in and out.  We have the streaming in:
>>>
>>>   bp_pack_value (, info->inlinable, 1);
>>>   bp_pack_value (, false, 1);
>>>   bp_pack_value (, info->fp_expressions, 1);
>>>
>>> while the streaming out:
>>>
>>>   info->inlinable = bp_unpack_value (, 1);
>>>   info->fp_expressions = bp_unpack_value (, 1)
>>>
>>> The cleanup of Cilk Plus support seemed to miss to remove the bit
>>> streaming out but change with streaming false.
>>>
>>> By hacking fp_expression_p to return true always, I can see it
>>> reads the wrong fp_expressions value (false) out in wpa dumping.
>>>
>>> Bootstrapped and regress-tested on powerpc64le-linux-gnu Power9.
>>>
>>> Is it ok for trunk?
>>
>> OK for trunk and all affected branches (note we need to bump the
>> LTO minor version there).  The issue comes from the removal
>> of cilk+ in r8-4956 which removed the bp_unpack but replaced
>> the bp_pack ...
>>
>> It's a correctness issue as we'll read fp_expressions as always 'false'
> 
> Btw, on branches we could also simply unpack a dummy bit to avoid
> changing the format.
> 

Committed in r12-3721.  Thanks!

As suggested, the patch for branches is listed below.

Is ok for branches 9, 10 and 11 after some trunk burn in time?

BR,
Kewen
-
gcc/ChangeLog:

* ipa-fnsummary.c (inline_read_section): Unpack a dummy bit
to keep consistent with the side of streaming out.

---
diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c
index 18bbae145b9..bf635c1f78a 100644
--- a/gcc/ipa-fnsummary.c
+++ b/gcc/ipa-fnsummary.c
@@ -4403,13 +4403,20 @@ inline_read_section (struct lto_file_decl_data 
*file_data, const char *data,
   bp = streamer_read_bitpack ();
   if (info)
{
-  info->inlinable = bp_unpack_value (, 1);
-  info->fp_expressions = bp_unpack_value (, 1);
+ info->inlinable = bp_unpack_value (, 1);
+ /* On the side of streaming out, there is still one bit
+streamed out between inlinable and fp_expressions bits,
+which was used for cilk+ before but now always false.
+To remove the bit packing need to bump LTO minor version,
+so unpack a dummy bit here to keep consistent instead.  */
+ bp_unpack_value (, 1);
+ info->fp_expressions = bp_unpack_value (, 1);
}
   else
{
-  bp_unpack_value (, 1);
-  bp_unpack_value (, 1);
+ bp_unpack_value (, 1);
+ bp_unpack_value (, 1);
+ bp_unpack_value (, 1);
}

   count2 = streamer_read_uhwi ();

[Bug target/102252] svbool_t with SVE can generate invalid assembly

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252

--- Comment #6 from Gilles Gouaillardet  
---
I am happy to confirm this issue is fixed in the latest 12-20210919 snapshot
:-)

FWIW, I was not yet able to build GROMACS because of an other issue that was
introduced last week. I reported it at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102421

[Bug target/102421] ICE with -march=armv8.2-a+sve -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102421

--- Comment #2 from Gilles Gouaillardet  
---
Created attachment 51487
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51487=edit
a trimmed reproducer (FWIW - include files are missing)

[Bug target/102421] ICE with -march=armv8.2-a+sve -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102421

--- Comment #1 from Gilles Gouaillardet  
---
Created attachment 51486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51486=edit
a (compressed) pre-processed reproducer

[Bug target/102421] New: ICE with -march=armv8.2-a+sve -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102421

Bug ID: 102421
   Summary: ICE with -march=armv8.2-a+sve -O3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

This is a new issue that happens with -march=armv8.2-a+sve -O3 with the latest
snapshot (12-20210919). FWIW, no crash with
 - 12-20210912 (last week snapshot)
 - -march=armv8.2-a+sve -O2
 - -march=armv8.2-a -O3


I tried to trim the file that caused an issue (it is from GROMACS 2021.3) but
was not quite able to do so. The attached reproducer is my best effort at
trimming it.


g++ (GCC) 12.0.0 20210919 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Singularity> g++ -march=armv8.2-a+sve -O3 -c test.i
during GIMPLE pass: vect
test.cpp: In function 'void foo(gmx::PaddedVector >,
gmx::PaddedVector >, int, short unsigned int*, const
int (*)[3])':
test.cpp:12:6: internal compiler error: in dr_misalignment, at
tree-vect-data-refs.c:900
   12 | void foo (
  |  ^~~
0x1d279c7 dr_misalignment(dr_vec_info*)
../.././gcc/tree-vect-data-refs.c:900
0x1d27a07 vect_duplicate_ssa_name_ptr_info
../.././gcc/tree-vect-data-refs.c:4639
0x1d2aa0f vect_create_addr_base_for_vector_ref(vec_info*, _stmt_vec_info*,
gimple**, tree_node*, tree_node*)
../.././gcc/tree-vect-data-refs.c:4750
0x1d2ac9f vect_create_data_ref_ptr(vec_info*, _stmt_vec_info*, tree_node*,
loop*, tree_node*, tree_node**, gimple_stmt_iterator*, gimple**, bool,
tree_node*, tree_node*)
../.././gcc/tree-vect-data-refs.c:4951
0x130b5b7 vectorizable_load
../.././gcc/tree-vect-stmts.c:9370
0x131854b vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
../.././gcc/tree-vect-stmts.c:11044
0x131a7a3 vect_transform_loop_stmt
../.././gcc/tree-vect-loop.c:9343
0x1335717 vect_transform_loop(_loop_vec_info*, gimple*)
../.././gcc/tree-vect-loop.c:9779
0x1365f2b try_vectorize_loop_1
../.././gcc/tree-vectorizer.c:1108
0x13669af vectorize_loops()
../.././gcc/tree-vectorizer.c:1247
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/102280] span's range deduction guide is missing ranges::contiguous_range constraint

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102280

--- Comment #6 from Jonathan Wakely  ---
I.e. please don't mark it as resolved, I'll do that when it's resolved.

[Bug libstdc++/102280] span's range deduction guide is missing ranges::contiguous_range constraint

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102280

--- Comment #5 from Jonathan Wakely  ---
I've set the Target Milestone field to indicate is going to be fixed for 10.4

[Bug middle-end/50724] cmath's floating-point classification implementations inconsistent with math.h

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #36 from Eric Gallager  ---
This bug is part of a large discussion on the llvm mailing lists, about whether
they should do similarly to GCC:
https://lists.llvm.org/pipermail/llvm-dev/2021-September/152530.html

[Bug c/54192] -fno-trapping-math by default?

[gabravier at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192

Gabriel Ravier  changed:

   What|Removed |Added

 CC||gabravier at gmail dot com

--- Comment #5 from Gabriel Ravier  ---
Also of note should be the fact that Clang's current default is
`-fno-trapping-math`.

I'm myself kind of curious about how exactly `-ftrapping-math` is interpreted.
It certainly doesn't seem to remove every single kind of non-trapping
math-based optimization: GCC will remove such statements as `(void)1/x;` even
with `-ftrapping-math`, even though that could fault with `x == 0`, and will
optimize things like `float x = 3412897421;` to not do a conversion even though
that conversion could raise an exception (as 3412897421 cannot be exactly
represented as a float), whereas Clang won't do that kind of optimization and
will keep those operations as-is.

Re: [PATCH] Simplify paradoxical subreg extensions of TRUNCATE

[Segher Boessenkool]

Hi!

On Sun, Sep 19, 2021 at 09:14:55AM -0600, Jeff Law wrote:
> On 9/6/2021 8:24 AM, Segher Boessenkool wrote:
> >On Mon, Sep 06, 2021 at 12:32:13PM +0100, Roger Sayle wrote:
> >>I think the current documentation is sufficient.  During compilation, 
> >>GCC's
> >>combine pass will often substitute a register with an expression defining
> >>it's value, and then attempt to simplify it.  As you point out, this often
> >>produces
> >>(temporary intermediate) expressions with poorly defined semantics.
> >Not "poorly defined".  The documentation says (in rtl.texi)
> >
> >@findex subreg
> >@item (subreg:@var{m1} @var{reg:m2} @var{bytenum})
> >
> >@code{subreg} expressions are used to refer to a register in a machine
> >mode other than its natural one, or to refer to one register of
> >a multi-part @code{reg} that actually refers to several registers.
> >
> >It goes on to say there also are subregs of mem currently; it
> >exhaustively lists all things you can take a subreg of, what the
> >different semantics of those are, how the semantics are further
> >"modified" (read: completely different) if some RTL flags are set, etc.
> >
> >The instruction combiner very often creates invalid RTL (only
> >structurally valid, like, no missing operands).  Invalid RTL is supposed
> >to never match (because backends will not have patterns that match
> >these).  combine even creates invalid RTL on purpose (a clobber of
> >const0_rtx) to ensure its result is deemed invalid, when it wants to
> >abort a combination attempt for some reason.
> >
> >>The
> >>purpose of my patch is to avoid (constructing) SUBREGs that have TRUNCATE
> >>as an argument (that some folks consider undefined) and instead simplify
> >>them to either a single TRUNCATE or a SUBREG of a REG, both of which are
> >>well defined.  I'm making/helping the implementation match the
> >>documentation.
> >But this should never make it to simplify-rtx at all.  You can only
> >validly do such transformations in combine, because you need to know
> >what insns you started with etc.
> >
> >simplify-rtx is a part of combine, sure, but it is used from other
> >contexts as well nowadays.  If you can safely do this from combine,
> >you can do it in combine.
> [ ... ]
> So what I think is missing here is some concrete path forward.  If I'm 
> understanding your objection Segher, you'd like to see Roger look at 
> where these (subreg (truncate)) expressions came from and address them 
> earlier than simplify_rtx?

There is no such thing as "earlier than simplify-rtx", that is the
point.  simplify-rtx is not a pass: it is like a library that is used
from all over the RTL routines.

If something belongs in combine, it should be in combine, not in
simplify-rtx.

> The theory being that the simplification 
> bits could be used from other contexts than just combine and in those 
> other contexts (subreg (truncate)) isn't valid?

Or not actually simplifying (or canonicalising).  Yup.

It also is the case that invalid RTL should simply never be constructed,
we should not (try to) fix it up later.  I'm not sure if that was what
was happening in this case, too much of this stuff recently, everything
blurs together, sorry :-/

I would love to see this all improved.  But if we just poke at it with
a stick we'll be in worse shape instead of better by the time stage 1
closes.  So we need a plan, and/or a topic tree (some devel/* branch or
whatever).


Segher

Re: [PATCH v3] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

[Marek Polacek via Gcc-patches]

On Mon, Sep 20, 2021 at 09:08:09PM +0200, Jakub Jelinek wrote:
> On Mon, Sep 20, 2021 at 02:37:03PM -0400, Marek Polacek wrote:
> > > So, wouldn't be this better specified as
> > > Wno-attributes=
> > > Common Joined RejectNegative
> > > (not sure if RejectNegative is actually needed for an option
> > > starting with Wno- )?
> > 
> > Looks like RejectNegative is not needed.  I could do that, but I think
> > it regresses the diagnostic:
> > 
> > error: unrecognized command-line option '-Wattributes=attr::'
> > vs
> > error: arguments ignored for ‘-Wattributes=’; use ‘-Wno-attributes=’ instead
> > 
> > I prefer the latter.  (I've changed the warning into error.)
> 
> Ok.
> 
> > > > +/* { dg-additional-options "-std=c++11" { target c++ } } */
> > > > +/* { dg-additional-options "-Wno-attributes=company::,yoyodyne::attr" 
> > > > } */
> > > > +/* { dg-additional-options 
> > > > "-Wno-attributes=c1::attr,c1::attr,c1::__attr__" } */
> > > > +/* { dg-additional-options "-Wno-attributes=clang" } */
> > > > +/* { dg-additional-options "-Wno-attributes=c2::,c2::attr" } */
> > > > +/* { dg-additional-options "-Wno-attributes=c3::attr,c3::" } */
> > > > +/* { dg-additional-options "-Wno-attributes=x::," } */
> > > 
> > > Should the above be accepted (I mean trailing , ?)  What does that mean?
> >  
> > I'm thinking it should: the arguments to -Wno-attributes= could be
> > generated by a tool so accepting the trailing , might help, like in
> > enums etc.
> 
> I don't think we allow that for any other options that accept a list of
> something (except maybe -W{p,c,a,l}, those just pass the args through).
> Generating a list that has comma separation only in between items and not
> at the end is trivial.

Hmm, ok, here's a version with that checking added.  Sadly it needs
to be handled before handle_ignored_attributes_option because of
strtok.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
It is desirable for -Wattributes to warn about e.g.

[[deprecate]] void g(); // typo, should warn

However, -Wattributes also warns about vendor-specific attributes
(that's because lookup_scoped_attribute_spec -> find_attribute_namespace
finds nothing), which, with -Werror, causes grief.  We don't want the
-Wattributes warning for

[[company::attr]] void f();

GCC warns because it doesn't know the "company" namespace; it only knows
the "gnu" and "omp" namespaces.  We could entirely disable warning about
attributes in unknown scopes but then the compiler would also miss typos
like

  [[company::attrx]] void f();

or

  [[gmu::warn_used_result]] int write();

so that is not a viable solution.  A workaround is to use a #pragma:

  #pragma GCC diagnostic push
  #pragma GCC diagnostic ignored "-Wattributes"
  [[company::attr]] void f() {}
  #pragma GCC diagnostic pop

but that's a mouthful and awkward to use and could also hide typos.  In
fact, any macro-based solution doesn't seem like a way forward.

This patch implements -Wno-attributes=, which takes these arguments:

company::attr
company::
clang

The last one is a special option to ignore clang-only attributes; in
this patch it is accepted but currently has no effect.

This option should go well with using @file: the user could have a file
containing
-Wno-attributes=vendor::attr1,vendor::attr2
and then invoke gcc with '@attrs' or similar.

I've also added a new pragma which has the same effect:

The pragma along with the new option should help with various static
analysis tools.

PR c++/101940

gcc/ChangeLog:

* attribs.c (struct scoped_attributes): Add a bool member.
(lookup_scoped_attribute_spec): Forward declare.
(register_scoped_attributes): New bool parameter, defaulted to
false.  Use it.
(handle_ignored_attributes_option): New function.
(free_attr_data): New function.
(init_attributes): Call handle_ignored_attributes_option.
(attr_namespace_ignored_p): New function.
(decl_attributes): Check attr_namespace_ignored_p before
warning.
* attribs.h (free_attr_data): Declare.
(register_scoped_attributes): Adjust declaration.
(handle_ignored_attributes_option): Declare.
* common.opt (Wattributes=): New option with a variable.
* doc/extend.texi: Document #pragma GCC diagnostic ignored_attributes.
* doc/invoke.texi: Document -Wno-attributes=.
* opts.c (common_handle_option) : Handle.
* plugin.h (register_scoped_attributes): Adjust declaration.

gcc/c-family/ChangeLog:

* c-pragma.c (handle_pragma_diagnostic): Handle #pragma GCC diagnostic
ignored_attributes.

gcc/c/ChangeLog:

* c-decl.c (c_parse_final_cleanups): Call free_attr_data.

gcc/cp/ChangeLog:

* decl2.c (c_parse_final_cleanups): Call free_attr_data.

gcc/testsuite/ChangeLog:

* c-c++-common/Wno-attributes-1.c: New test.
* c-c++-common/Wno-attributes-2.c: New test.
---
 gcc/attribs.c   

[PATCH] Remove warnings from v0_mangle functions in rust-mangle.cc

[Mark Wielaard]

There were two warnings in rust-mangle.cc

rust-mangle.cc: In function ‘std::string Rust::Compile::v0_mangle_item
(const Rust::TyTy::BaseType*, const Rust::Resolver::CanonicalPath&, const 
string&)’:
rust-mangle.cc:198:1: warning: no return statement in function returning 
non-void

rust-mangle.cc: At global scope:
rust-mangle.cc:201:1: warning: ‘std::string Rust::Compile::v0_mangle_impl_item
(const Rust::TyTy::BaseType*, const Rust::TyTy::BaseType*, const string&, const 
string&)’
 declared ‘static’ but never defined [-Wunused-function]

The first results in undefined behaviour, the second points out that the
function isn't ever called/used.

Fix the first by adding a gcc_unreachable () to turn the calling of the
function into an abort ().  Fix the second by adding the call in
Mangler::mangle_impl_item. And add an implementation simply calling
gcc-unreachable (). This turns the warnings and undefined behaviour into
explicit runtime aborts when these functions are actually called.
---
 gcc/rust/backend/rust-mangle.cc | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=rust-mangle-unreachable

diff --git a/gcc/rust/backend/rust-mangle.cc b/gcc/rust/backend/rust-mangle.cc
index 840acb992e0..0e6643c64ae 100644
--- a/gcc/rust/backend/rust-mangle.cc
+++ b/gcc/rust/backend/rust-mangle.cc
@@ -195,11 +195,15 @@ v0_mangle_item (const TyTy::BaseType *ty, const 
Resolver::CanonicalPath ,
const std::string _name)
 {
   auto ty_prefix = v0_type_prefix (ty);
+  gcc_unreachable ();
 }
 
 static std::string
 v0_mangle_impl_item (const TyTy::BaseType *self, const TyTy::BaseType *ty,
-const std::string , const std::string _name);
+const std::string , const std::string _name)
+{
+  gcc_unreachable ();
+}
 
 std::string
 Mangler::mangle_item (const TyTy::BaseType *ty,
@@ -227,7 +231,7 @@ Mangler::mangle_impl_item (const TyTy::BaseType *self, 
const TyTy::BaseType *ty,
 case Mangler::MangleVersion::LEGACY:
   return legacy_mangle_impl_item (self, ty, name, crate_name);
 case Mangler::MangleVersion::V0:
-  gcc_unreachable ();
+  return v0_mangle_impl_item (self, ty, name, crate_name);
 default:
   gcc_unreachable ();
 }
-- 
2.32.0

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

[Bug c++/94673] [concepts] What is the return type of local parameters of requires expressions?

[gcc-bugs at marehr dot dialup.fu-berlin.de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94673

--- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
I think this bug should be changed to a request to improve the diagnostics.

The diagnostic says:

```
:13:15: note: constraints not satisfied
:8:9:   required by the constraints of 'template concept foo'
:8:15:   in requirements with 't v' [with t = int]
:10:6: note: 'v' does not satisfy return-type-requirement
   10 | {v} -> same_as;
  |  ^
```

If you don't know that `{v}` should be read as `{(v)}`, it is confusing that
the diagnostic says that `'t v' [with t = int]` does not satisfy that the type
of the expression `{ v }` is `t`.

I think the diagnostic for the return-type-requirement should add the reason /
diagnostic why it isn't fulfilled, so basically the same reason that
`static_assert(std::same_as);` would give.

> note: the expression 'is_same_v<_Tp, _Up> [with _Tp = int&; _Up = int]' 
> evaluated to 'false'
>   57 |   concept __same_as = std::is_same_v<_Tp, _Up>;
>  |   ~^~~

[Bug c/102415] [12 Regression] ICE in bb_seq_addr, at gimple.h:1786

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102415

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c++/102414] [12 Regression] ICE in unify_array_domain, at cp/pt.c:23442

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102414

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c++/99811] ICE: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst_pack_expansion, at cp/pt.c:13002

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99811

Andrew Pinski  changed:

   What|Removed |Added

  Known to work|11.1.0  |

--- Comment #2 from Andrew Pinski  ---
The first testcase is fixed in GCC 11+ while the second testcase still ICEs on
the trunk.

[Bug c++/102420] null pointer dereference during constant evaluation not rejected

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102420

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-20
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed, here is a testcase which does not require C++20 (though it does use
a GNU extension):

struct X {
  constexpr int f() { return 0; }
};
constexpr int g() {
return (X*){nullptr}->f();
}

int t = g();
 CUT 
here is one which is invalid C++14 (and does not use the GNU extension):
struct X {
  constexpr int f() { return 0; }
};
constexpr int g() {
X *x = nullptr;
return x->f();
}

int t = g();
 CUT --
I only noticed that clang rejects it while ICC and MSVC accept it also.

[Bug c/79516] [9/10/11/12 Regression] ICE: unspellable token PRAGMA_EOL

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79516

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|ICE: unspellable token  |[9/10/11/12 Regression]
   |PRAGMA_EOL  |ICE: unspellable token
   ||PRAGMA_EOL
   Target Milestone|--- |9.5

--- Comment #2 from Andrew Pinski  ---
(In reply to Martin Liška from comment #1)
> Confirmed, started in between 4.5.2 and 4.5.3.

No 4.4.7 ICEs too. But 4.1.2 does not.

[Bug c/97991] [9/10/11/12 Regression] ICE in c_parser_consume_token, at c/c-parser.c:850

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97991

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=47254
Summary|ICE in  |[9/10/11/12 Regression] ICE
   |c_parser_consume_token, at  |in c_parser_consume_token,
   |c/c-parser.c:850|at c/c-parser.c:850
  Known to fail||10.1.0, 4.4.7
   Target Milestone|--- |9.5
  Known to work||4.1.2

--- Comment #3 from Andrew Pinski  ---
(In reply to G. Steinmetz from comment #1)
> A special case, loosely related :
> 
> 
> $ cat z2.c
> #define foo _Pragma (" ")
> #pragma redefine_extname foo

That is PR 47254.

[Bug c++/102420] null pointer dereference during constant evaluation not rejected

[johelegp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102420

Johel Ernesto Guerrero Peña  changed:

   What|Removed |Added

Summary|null pointer dereference|null pointer dereference
   |constant|during constant evaluation
   ||not rejected
 Blocks||55004

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
See https://godbolt.org/z/r5zxPTcK6.
```C++
struct X {
  constexpr void f() { }
};
int main() {
  []() consteval {
X* x{nullptr};
x->f();
  }();
}
```


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug c++/102420] New: null pointer dereference constant

[johelegp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102420

Bug ID: 102420
   Summary: null pointer dereference constant
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

[Bug c++/96638] [9/10/11/12 Regression] ICE in chainon, at tree.c:3169

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96638

--- Comment #4 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #1)
> Even GCC 6 ICEs.

I suspect GCC 5 did not ICE, see PR 96637 .

[Bug c++/58109] alignas() fails to compile with constant expression

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58109

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[COMMITTED] Use EDGE_EXECUTABLE in ranger and return UNDEFINED for those edges.

[Andrew MacLeod via Gcc-patches]

The patch sets the EXECUTABLE property on edges like VRP does, and then 
removes that flag when an edge is determined to be un-executable.


This information is then used to return UNDEFINED for any requests on 
un-executable edges, and to register equivalencies if all executable 
edges of a PHI node are the same SSA_NAME.


This catches up a number of the cases VRP gets that ranger was missing, 
and reduces the EVRP discrepancies to almost 0.


On a side note,  is there any interest/value in reversing the meaning of 
that flag?  It seems to me that we could assume edges are EXECUTABLE by 
default, then set a NON_EXECUTABLE flag when a pass determines the edge 
cannot be executed.  This would rpevent a number fo passes from having 
to loop through all the edges and set the EXECUTABLE property...   It 
just seems backwards to me.


Anyway, bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.

Andrew

>From 73cf73af2392e00917de042a4692f6a0b6329ee8 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod 
Date: Tue, 24 Aug 2021 12:13:24 -0400
Subject: [PATCH 2/2] Use EDGE_EXECUTABLE in ranger and return UNDEFINED for
 those edges.

If an incoming edge is UNDEFINED, don't process it.  Track if other edges
equate to a single value, and add an equivalence if appropriate.

	gcc/
	* gimple-range-fold.cc (fold_using_range::range_of_phi): Ignore
	undefined edges, apply an equivalence if appropriate.
	* gimple-range-gori.cc (gori_compute::outgoing_edge_range_p): Return
	UNDEFINED if EDGE_EXECUTABLE is not set.
	* gimple-range.cc (gimple_ranger::gimple_ranger): Set all edges
	as EXECUTABLE upon startup.
	(gimple_ranger::range_on_edge): Return UNDEFINED for edges without
	EDGE_EXECUTABLE set.
	* vr-values.c (set_and_propagate_unexecutable): New.
	(simplify_using_ranges::fold_cond): Call set_and_propagate.
	(simplify_using_ranges::simplify_switch_using_ranges): Ditto.
	* vr-values.h: Add prototype.

	gcc/testsuite/
	* gcc.dg/tree-ssa/evrp-ignore.c: New.
---
 gcc/gimple-range-fold.cc| 47 ++---
 gcc/gimple-range-gori.cc| 25 ---
 gcc/gimple-range.cc | 36 +++-
 gcc/testsuite/gcc.dg/tree-ssa/evrp-ignore.c | 28 
 gcc/vr-values.c | 39 -
 gcc/vr-values.h |  1 +
 6 files changed, 140 insertions(+), 36 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/evrp-ignore.c

diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc
index 997d02dd4b9..80cc5c0dc0c 100644
--- a/gcc/gimple-range-fold.cc
+++ b/gcc/gimple-range-fold.cc
@@ -760,6 +760,10 @@ fold_using_range::range_of_phi (irange , gphi *phi, fur_source )
   if (!type)
 return false;
 
+  // Track if all executable arguments are the same.
+  tree single_arg = NULL_TREE;
+  bool seen_arg = false;
+
   // Start with an empty range, unioning in each argument's range.
   r.set_undefined ();
   for (x = 0; x < gimple_phi_num_args (phi); x++)
@@ -767,19 +771,48 @@ fold_using_range::range_of_phi (irange , gphi *phi, fur_source )
   tree arg = gimple_phi_arg_def (phi, x);
   edge e = gimple_phi_arg_edge (phi, x);
 
-  // Register potential dependencies for stale value tracking.
-  if (gimple_range_ssa_p (arg) && src.gori ())
-	src.gori ()->register_dependency (phi_def, arg);
-
   // Get the range of the argument on its edge.
   src.get_phi_operand (arg_range, arg, e);
-  // If we're recomputing the argument elsewhere, try to refine it.
-  r.union_ (arg_range);
+
+  if (!arg_range.undefined_p ())
+	{
+	  // Register potential dependencies for stale value tracking.
+	  r.union_ (arg_range);
+	  if (gimple_range_ssa_p (arg) && src.gori ())
+	src.gori ()->register_dependency (phi_def, arg);
+
+	  // Track if all arguments are the same.
+	  if (!seen_arg)
+	{
+	  seen_arg = true;
+	  single_arg = arg;
+	}
+	  else if (single_arg != arg)
+	single_arg = NULL_TREE;
+	}
+
   // Once the value reaches varying, stop looking.
-  if (r.varying_p ())
+  if (r.varying_p () && single_arg == NULL_TREE)
 	break;
 }
 
+// If the PHI boils down to a single effective argument, look at it.
+if (single_arg)
+  {
+	// Symbolic arguments are equivalences.
+	if (gimple_range_ssa_p (single_arg))
+	  src.register_relation (phi, EQ_EXPR, phi_def, single_arg);
+	else if (src.get_operand (arg_range, single_arg)
+		 && arg_range.singleton_p ())
+	  {
+	// Numerical arguments that are a constant can be returned as
+	// the constant. This can help fold later cases where even this
+	// constant might have been UNDEFINED via an unreachable edge.
+	r = arg_range;
+	return true;
+	  }
+  }
+
   // If SCEV is available, query if this PHI has any knonwn values.
   if (scev_initialized_p () && !POINTER_TYPE_P (TREE_TYPE (phi_def)))
 {
diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index 

[Bug c++/59012] alignas does not support parameter pack expansions

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59012

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.2

[COMMITTED] Use EDGE_EXECUTABLE in ranger and return UNDEFINED for those edges.

[Andrew MacLeod via Gcc-patches]

The patch sets the EXECUTABLE property on edges like VRP does, and then 
removes that flag when an edge is determined to be un-executable.


This information is then used to return UNDEFINED for any requests on 
un-executable edges, and to register equivalencies if all executable 
edges of a PHI node are the same SSA_NAME.


This catches up a number of the cases VRP gets that ranger was missing, 
and reduces the EVRP discrepancies to almost 0.


On a side note,  is there any interest/value in reversing the meaning of 
that flag?  It seems to me that we could assume edges are EXECUTABLE by 
default, then set a NON_EXECUTABLE flag when a pass determines the edge 
cannot be executed.  This would rpevent a number fo passes from having 
to loop through all the edges and set the EXECUTABLE property...   It 
just seems backwards to me.


Anyway, bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.

Andrew

>From 73cf73af2392e00917de042a4692f6a0b6329ee8 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod 
Date: Tue, 24 Aug 2021 12:13:24 -0400
Subject: [PATCH 2/2] Use EDGE_EXECUTABLE in ranger and return UNDEFINED for
 those edges.

If an incoming edge is UNDEFINED, don't process it.  Track if other edges
equate to a single value, and add an equivalence if appropriate.

	gcc/
	* gimple-range-fold.cc (fold_using_range::range_of_phi): Ignore
	undefined edges, apply an equivalence if appropriate.
	* gimple-range-gori.cc (gori_compute::outgoing_edge_range_p): Return
	UNDEFINED if EDGE_EXECUTABLE is not set.
	* gimple-range.cc (gimple_ranger::gimple_ranger): Set all edges
	as EXECUTABLE upon startup.
	(gimple_ranger::range_on_edge): Return UNDEFINED for edges without
	EDGE_EXECUTABLE set.
	* vr-values.c (set_and_propagate_unexecutable): New.
	(simplify_using_ranges::fold_cond): Call set_and_propagate.
	(simplify_using_ranges::simplify_switch_using_ranges): Ditto.
	* vr-values.h: Add prototype.

	gcc/testsuite/
	* gcc.dg/tree-ssa/evrp-ignore.c: New.
---
 gcc/gimple-range-fold.cc| 47 ++---
 gcc/gimple-range-gori.cc| 25 ---
 gcc/gimple-range.cc | 36 +++-
 gcc/testsuite/gcc.dg/tree-ssa/evrp-ignore.c | 28 
 gcc/vr-values.c | 39 -
 gcc/vr-values.h |  1 +
 6 files changed, 140 insertions(+), 36 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/evrp-ignore.c

diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc
index 997d02dd4b9..80cc5c0dc0c 100644
--- a/gcc/gimple-range-fold.cc
+++ b/gcc/gimple-range-fold.cc
@@ -760,6 +760,10 @@ fold_using_range::range_of_phi (irange , gphi *phi, fur_source )
   if (!type)
 return false;
 
+  // Track if all executable arguments are the same.
+  tree single_arg = NULL_TREE;
+  bool seen_arg = false;
+
   // Start with an empty range, unioning in each argument's range.
   r.set_undefined ();
   for (x = 0; x < gimple_phi_num_args (phi); x++)
@@ -767,19 +771,48 @@ fold_using_range::range_of_phi (irange , gphi *phi, fur_source )
   tree arg = gimple_phi_arg_def (phi, x);
   edge e = gimple_phi_arg_edge (phi, x);
 
-  // Register potential dependencies for stale value tracking.
-  if (gimple_range_ssa_p (arg) && src.gori ())
-	src.gori ()->register_dependency (phi_def, arg);
-
   // Get the range of the argument on its edge.
   src.get_phi_operand (arg_range, arg, e);
-  // If we're recomputing the argument elsewhere, try to refine it.
-  r.union_ (arg_range);
+
+  if (!arg_range.undefined_p ())
+	{
+	  // Register potential dependencies for stale value tracking.
+	  r.union_ (arg_range);
+	  if (gimple_range_ssa_p (arg) && src.gori ())
+	src.gori ()->register_dependency (phi_def, arg);
+
+	  // Track if all arguments are the same.
+	  if (!seen_arg)
+	{
+	  seen_arg = true;
+	  single_arg = arg;
+	}
+	  else if (single_arg != arg)
+	single_arg = NULL_TREE;
+	}
+
   // Once the value reaches varying, stop looking.
-  if (r.varying_p ())
+  if (r.varying_p () && single_arg == NULL_TREE)
 	break;
 }
 
+// If the PHI boils down to a single effective argument, look at it.
+if (single_arg)
+  {
+	// Symbolic arguments are equivalences.
+	if (gimple_range_ssa_p (single_arg))
+	  src.register_relation (phi, EQ_EXPR, phi_def, single_arg);
+	else if (src.get_operand (arg_range, single_arg)
+		 && arg_range.singleton_p ())
+	  {
+	// Numerical arguments that are a constant can be returned as
+	// the constant. This can help fold later cases where even this
+	// constant might have been UNDEFINED via an unreachable edge.
+	r = arg_range;
+	return true;
+	  }
+  }
+
   // If SCEV is available, query if this PHI has any knonwn values.
   if (scev_initialized_p () && !POINTER_TYPE_P (TREE_TYPE (phi_def)))
 {
diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index 

[COMMITTED] Relation oracle: Make each def a new equivalency record.

[Andrew MacLeod via Gcc-patches]

The current equivalence oracle is not "killing" back edge equivalence 
sets sometimes.   Missing is that a definition starts a new equivalence 
set at that point, with nothing in it but the def itself.


Creating this new equivalence set will ensure that any subsequent 
comparisons with values live from the back edge will have 
non-symmetrical equivalence sets, and the oracle will no longer pick up 
the equivalence.  This initial set is created lazily, the first time 
that an attempt is made to combine it with another set.


Eventually I may move to a more fine grained location based analysis, 
but for now this takes care of most of the issue.


bootstrapped on x86_64-pc-linux-gnu with no regressions.  pushed.

Andrew

>From 5d110fe90afcd850ea21aee6429f22edd6b1b592 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod 
Date: Fri, 17 Sep 2021 14:58:06 -0400
Subject: [PATCH 1/2] Make each def a new equivalency record.

Create a new equivalency set at each def point killing any equivalencies
coming into the block from back edges.  Do not add equivalences for PHI
arguments defined in this block.

	* value-relation.cc (equiv_oracle::register_initial_def): New.
	(equiv_oracle::register_relation): Call register_initial_def.
	(equiv_oracle::add_equiv_to_block): New.  Split register_relation.
	(relation_oracle::register_stmt): Check def block of PHI arguments.
	* value-relation.h (equiv_oracle): Add new prototypes.
---
 gcc/value-relation.cc | 57 +++
 gcc/value-relation.h  |  3 ++-
 2 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc
index d370f93d128..ac5f3f9afc0 100644
--- a/gcc/value-relation.cc
+++ b/gcc/value-relation.cc
@@ -407,6 +407,24 @@ equiv_oracle::register_equiv (basic_block bb, equiv_chain *equiv_1,
   return b;
 }
 
+// Create an equivalency set containing only SSA in its definition block.
+// This is done the first time SSA is registered in an equivalency and blocks
+// any DOM searches past the definition.
+
+void
+equiv_oracle::register_initial_def (tree ssa)
+{
+  if (SSA_NAME_IS_DEFAULT_DEF (ssa))
+return;
+  basic_block bb = gimple_bb (SSA_NAME_DEF_STMT (ssa));
+  gcc_checking_assert (bb && !find_equiv_dom (ssa, bb));
+
+  unsigned v = SSA_NAME_VERSION (ssa);
+  bitmap_set_bit (m_equiv_set, v);
+  bitmap equiv_set = BITMAP_ALLOC (_bitmaps);
+  bitmap_set_bit (equiv_set, v);
+  add_equiv_to_block (bb, equiv_set);
+}
 
 // Register an equivalence between SSA1 and SSA2 in block BB.
 // The equivalence oracle maintains a vector of equivalencies indexed by basic
@@ -425,6 +443,14 @@ equiv_oracle::register_relation (basic_block bb, relation_kind k, tree ssa1,
 
   unsigned v1 = SSA_NAME_VERSION (ssa1);
   unsigned v2 = SSA_NAME_VERSION (ssa2);
+
+  // If this is the first time an ssa_name has an equivalency registered
+  // create a self-equivalency record in the def block.
+  if (!bitmap_bit_p (m_equiv_set, v1))
+register_initial_def (ssa1);
+  if (!bitmap_bit_p (m_equiv_set, v2))
+register_initial_def (ssa2);
+
   equiv_chain *equiv_1 = find_equiv_dom (ssa1, bb);
   equiv_chain *equiv_2 = find_equiv_dom (ssa2, bb);
 
@@ -456,6 +482,15 @@ equiv_oracle::register_relation (basic_block bb, relation_kind k, tree ssa1,
   if (!equiv_set)
 return;
 
+  add_equiv_to_block (bb, equiv_set);
+}
+
+// Add an equivalency record in block BB containing bitmap EQUIV_SET.
+// Note the internal caller is responible for allocating EQUIV_SET properly.
+
+void
+equiv_oracle::add_equiv_to_block (basic_block bb, bitmap equiv_set)
+{
   equiv_chain *ptr;
 
   // Check if this is the first time a block has an equivalence added.
@@ -786,6 +821,28 @@ relation_oracle::register_stmt (gimple *stmt, relation_kind k, tree op1,
   print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM);
 }
 
+  // If an equivalence is being added between a PHI and one of its arguments
+  // make sure that that argument is not defined in the same block.
+  // This can happen along back edges and the equivalence will not be
+  // applicable as it would require a use before def.
+  if (k == EQ_EXPR && is_a (stmt))
+{
+  tree phi_def = gimple_phi_result (stmt);
+  gcc_checking_assert (phi_def == op1 || phi_def == op2);
+  tree arg = op2;
+  if (phi_def == op2)
+	arg = op1;
+  if (gimple_bb (stmt) == gimple_bb (SSA_NAME_DEF_STMT (arg)))
+	{
+	  if (dump_file && (dump_flags & TDF_DETAILS))
+	{
+	  fprintf (dump_file, "  Not registered due to ");
+	  print_generic_expr (dump_file, arg, TDF_SLIM);
+	  fprintf (dump_file, " being defined in the same block.\n");
+	}
+	  return;
+	}
+}
   register_relation (gimple_bb (stmt), k, op1, op2);
 }
 
diff --git a/gcc/value-relation.h b/gcc/value-relation.h
index 574fdc9efe8..53cefbfa7dc 100644
--- a/gcc/value-relation.h
+++ b/gcc/value-relation.h
@@ -146,7 +146,8 @@ private:
   bitmap register_equiv (basic_block bb, unsigned v, equiv_chain *equiv_1);
   bitmap 

[Bug c++/96637] [9/10/11/12 Regression] ICE in tree check: expected tree_list, have error_mark in cp_check_const_attributes, at cp/decl2.c:1423

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96637

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
Summary|ICE in tree check: expected |[9/10/11/12 Regression] ICE
   |tree_list, have error_mark  |in tree check: expected
   |in  |tree_list, have error_mark
   |cp_check_const_attributes,  |in
   |at cp/decl2.c:1423  |cp_check_const_attributes,
   ||at cp/decl2.c:1423
  Known to work||5.5.0
   Severity|normal  |minor
  Known to fail||6.1.0

--- Comment #2 from Andrew Pinski  ---
In GCC 5.5.0 and before we only got the following error message and no confused
by earlier errors message:
:1:16: error: expected ',' or '...' before 'alignas'
 void foo(int[] alignas[1] alignas(1)){}
^

GCC 6+ changed the error message to:
:1:23: error: expected '(' before '[' token
 void foo(int[] alignas[1] alignas(1)){}
   ^

[Bug c++/54367] [meta-bug] lambda expressions

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 89138, which changed state.

Bug 89138 Summary: typeof VLA in lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89138

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/16994] [meta-bug] VLA and C++

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994
Bug 16994 depends on bug 89138, which changed state.

Bug 89138 Summary: typeof VLA in lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89138

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/60855] ICE provoked by a lambda using the sizeof a captured VLA

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60855

Andrew Pinski  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #6 from Andrew Pinski  ---
*** Bug 89138 has been marked as a duplicate of this bug. ***

[Bug c++/89138] typeof VLA in lambdas

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89138

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Andrew Pinski  ---
Yes this is a dup of bug 60855.  It has been fixed for GCC 10+.

*** This bug has been marked as a duplicate of bug 60855 ***

[Bug c++/92331] ICE on incorrect code with VLA type inside a local struct type

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92331

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE on incorrect code with  |ICE on incorrect code with
   |VLA |VLA type inside a local
   ||struct type
   Keywords|ice-on-invalid-code |ice-on-valid-code

--- Comment #2 from Andrew Pinski  ---
It did not crash in GCC 4.5.3 but there was multiple calls to foo.

Note I used this code instead (removing C++11ism from it):
int foo();

int main() {
  typedef int X[foo()];
  struct S { S() { X x; } } s;
}

Re: [Patch] Fortran: Fix -Wno-missing-include-dirs handling [PR55534]

[Harald Anlauf via Gcc-patches]

Hi Tobias,

Am 20.09.21 um 22:33 schrieb Tobias Burnus:

And v3 – I realized that testcases would be useful. Thus, now with added
testcases. :-)


I was about to recommend a testcase I prepared when your revised patch
arrived.  Will not bother you with it, as you seem to provide really
good coverage.

LGTM.

Thanks for the patch!

Harald


Tobias

On 17.09.21 20:45, Tobias Burnus wrote:

I seemingly messed up a bit in previous patch – corrected version
attached.

OK?

Tobias

PS: Due to now enabling the missing-include-dir warning also for
cpp,the following
warning show up during build. This seems to be specific to libgfortran
building,
libgomp works and real-world code also does not seem to be affected:
: Error: /x86_64-pc-linux-gnu/include: No such file
or directory [-Werror=missing-include-dirs]
: Error: /x86_64-pc-linux-gnu/sys-include: No such
file or directory [-Werror=missing-include-dirs]
: Error: finclude: No such file or directory
[-Werror=missing-include-dirs]

The latter is due to the driver adding '-fintrinsic-modules-path
finclude'
when calling f951. I think the rest is a side effect of running with -B
and other build trickery.

The warnings do not trigger when compiling the Fortran file in libgomp
nor for
a quick real-world case (which uses gfortran in a normal way not with
-B etc.).
Thus, I think it should be fine.
Alternatively, we could think of reducing the noisiness. Thoughts?

PPS: Besides this, the following still applies:

On 17.09.21 15:02, Tobias Burnus wrote:

Short version:
* -Wno-missing-include-dirs  had no effect as the warning was always on
* For CPP-only options like -idirafter, no warning was shown.

This patch tries to address both, i.e. cpp's include-dir diagnostics are
shown as well – and silencing the diagnostic works as well.

OK for mainline?

Tobias

PS:  BACKGROUND and LONG DESCRIPTION

C/C++ by default have disabled the -Wmissing-include-dirs warning.
Fortran by default has that warning enabled.

The value is actually stored at two places (cf. c-family/c.opt):
  Wmissing-include-dirs
  ... CPP(warn_missing_include_dirs)
Var(cpp_warn_missing_include_dirs) Init(0)

For CPP, that value always needs to initialized – and it is used
in gcc/incpath.c as
  cpp_options *opts = cpp_get_options (pfile);
  if (opts->warn_missing_include_dirs &&
cur->user_supplied_p)
    cpp_warning (pfile, CPP_W_MISSING_INCLUDE_DIRS, "%s:
%s",

Additionally, there is cpp_warn_missing_include_dirs which is used by
Fortran – and which consists of
  global_options.x_cpp_warn_missing_include_dirs
  global_options_set._cpp_warn_missing_include_dirs

The flag processing happens as described in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534#c11
in short:
  - First gfc_init_options is called
  - Then for reach command-line option gfc_handle_option
  - Finally gfc_post_options

Currently:
- gfc_init_options: Sets cpp_warn_missing_include_dirs
  (unconditionally as unset)
- gfc_handle_option: Always warns about the missing include dir
- before gfc_post_options: set_option is called, which sets
  cpp_warn_missing_include_dirs – but that's too late.

Additionally, as mentioned above – pfile's warn_missing_include_dirs
is never properly set.

 * * *

This patch fixes those issues:
* Now -Wno-missing-include-dirs does silence the warnings
* CPP now also properly does warn.

Example (initial version):
$ gfortran-trunk ../empty.f90 -c -cpp -idirafter /fdaf/ -I bar/
-Wmissing-include-dirs
f951: Warning: Nonexistent include directory ‘bar//’
[-Wmissing-include-dirs]
: Warning: /fdaf/: No such file or directory
: Warning: bar/: No such file or directory

In order to avoid the double output for -I, I disabled the Fortran
output if
CPP is enabled. Additionally, I had to use the
cpp_reason_option_codes to
print the flag in brackets.
Fixed/final output is:

: Warning: /fdaf/: No such file or directory
[-Wmissing-include-dirs]
: Warning: bar/: No such file or directory
[-Wmissing-include-dirs]


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 
80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: 
Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; 
Registergericht München, HRB 106955

[Bug preprocessor/82469] ICE in _cpp_process_line_notes, at libcpp/lex.c:1066

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82469

--- Comment #1 from Andrew Pinski  ---
I cannot even reproduce this on the FSF released GCC 6.3.0 code ...

[Bug preprocessor/69869] [6 Regression] internal compiler error: Segmentation fault in call to skip_macro_block_comment when using '-traditional-cpp'

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69869

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|6.5 |7.4

[Bug c++/102419] New: [concepts] [regression] return-type-requirement of "Y" does not check that T::type actually exists

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102419

Bug ID: 102419
   Summary: [concepts] [regression] return-type-requirement of
"Y" does not check that T::type
actually exists
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/GWjYYnrnM
template concept Y = true;
template concept X = requires {
{ 1 } -> Y;
};
static_assert(!X);


:8:15: error: static assertion failed
8 | static_assert(!X);
  |   ^~~

Clang and MSVC both appear to have the correct behavior -- or what I believe to
be the consistent/useful/majority behavior, anyway -- which is that since
T::type doesn't exist, the concept shouldn't be satisfied.

This seems to be a regression; according to Godbolt, GCC 10.3 had the correct
behavior but GCC 11.1 lost it. 

I wonder if #92268 could be related somehow, since it seems to be something
like the inverse issue (nonexistent nested type causing a hard error in 10.x),
and it was marked fixed presumably somewhere in the 11.x timeframe.

[Bug c++/94673] [concepts] What is the return type of local parameters of requires expressions?

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94673

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #2 from Arthur O'Dwyer  ---
Yes, this is/was a Clang bug; a return-type-requirement should be applied to
decltype((expr)), but Clang was incorrectly applying the requirement to
decltype(expr).

I think this can now be closed as "not a bug" (the bug was in Clang, not GCC).

[Bug c++/81157] If constexpr does not support Short-circuit evaluation

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81157

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #1 from Arthur O'Dwyer  ---
I'd say neither a bug nor a defect. In `if constexpr (X && Y)`, `X && Y` is an
expression and it must be well-formed, even if it's false -- just like if you
did `static_assert((X && Y) == false)`. GCC is behaving according to the C++
Standard in this case.

Recommend closing as INVALID.

Re: [PATCH v4] c++: Fix cp_tree_equal for template value args using dependent sizeof/alignof/noexcept expressions

[Jason Merrill via Gcc-patches]

On 9/17/21 12:44, Barrett Adair wrote:

I think the patch is in good shape now, thanks for the help.

canon-type*.C fail with trunk and pass with patch, dependent-name*.C are 
regression tests that pass with both. I removed the dg-ice from 
constexpr-52830.C. I didn't dig much into the churn history there, but 
the test code looks valid to me and clang agrees.


I also returned the copyright assignment form yesterday to 
ass...@gnu.org .



+/* Identify any expressions that use function parms */


A comment should end with a period and two spaces.


+static tree
+find_parm_usage_r (tree tp, int *walk_subtrees, void)
+{
+  tree t = *tp;
+  if (PACK_EXPANSION_P (t) || (TREE_CODE (t) == PARM_DECL))


PACK_EXPANSION_P is wrong here; a pack expansion might not involve a 
function parameter (pack) at all.  And walk_tree should already recurse 
into the pattern of a pack expansion, so handling them specifically here 
shouldn't be necessary.



+ else if (!current_function_decl


This needs a comment about why we're checking current_function_decl 
(because we only need structural comparison for redeclaration comparisons)



+  && dependent_template_arg_p (arg)
+  && cp_walk_tree_without_duplicates (,
+   find_parm_usage_r, NULL))


Here the second line of args needs to line up with the args on the 
previous line.  When that's too far to the right, like here, I tend to 
write e.g.


> + && (cp_walk_tree_without_duplicates
> + (, find_parm_usage_r, NULL)))

Jason

[Bug libstdc++/102280] span's range deduction guide is missing ranges::contiguous_range constraint

[joeloser93 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102280

--- Comment #4 from Joe Loser  ---
Johnathan, your fix LGTM. Safe to mark this as resolved, or do you need to do
something to backport it for the 10.4 release branch?

[Bug fortran/77652] Invalid rank error in ASSOCIATED when rank is remapped

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77652

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
Still present on trunk.

Re: [Patch] Fortran: Fix -Wno-missing-include-dirs handling [PR55534]

[Tobias Burnus]

And v3 – I realized that testcases would be useful. Thus, now with added
testcases. :-)

Tobias

On 17.09.21 20:45, Tobias Burnus wrote:

I seemingly messed up a bit in previous patch – corrected version
attached.

OK?

Tobias

PS: Due to now enabling the missing-include-dir warning also for
cpp,the following
warning show up during build. This seems to be specific to libgfortran
building,
libgomp works and real-world code also does not seem to be affected:
: Error: /x86_64-pc-linux-gnu/include: No such file
or directory [-Werror=missing-include-dirs]
: Error: /x86_64-pc-linux-gnu/sys-include: No such
file or directory [-Werror=missing-include-dirs]
: Error: finclude: No such file or directory
[-Werror=missing-include-dirs]

The latter is due to the driver adding '-fintrinsic-modules-path
finclude'
when calling f951. I think the rest is a side effect of running with -B
and other build trickery.

The warnings do not trigger when compiling the Fortran file in libgomp
nor for
a quick real-world case (which uses gfortran in a normal way not with
-B etc.).
Thus, I think it should be fine.
Alternatively, we could think of reducing the noisiness. Thoughts?

PPS: Besides this, the following still applies:

On 17.09.21 15:02, Tobias Burnus wrote:

Short version:
* -Wno-missing-include-dirs  had no effect as the warning was always on
* For CPP-only options like -idirafter, no warning was shown.

This patch tries to address both, i.e. cpp's include-dir diagnostics are
shown as well – and silencing the diagnostic works as well.

OK for mainline?

Tobias

PS:  BACKGROUND and LONG DESCRIPTION

C/C++ by default have disabled the -Wmissing-include-dirs warning.
Fortran by default has that warning enabled.

The value is actually stored at two places (cf. c-family/c.opt):
  Wmissing-include-dirs
  ... CPP(warn_missing_include_dirs)
Var(cpp_warn_missing_include_dirs) Init(0)

For CPP, that value always needs to initialized – and it is used
in gcc/incpath.c as
  cpp_options *opts = cpp_get_options (pfile);
  if (opts->warn_missing_include_dirs &&
cur->user_supplied_p)
cpp_warning (pfile, CPP_W_MISSING_INCLUDE_DIRS, "%s:
%s",

Additionally, there is cpp_warn_missing_include_dirs which is used by
Fortran – and which consists of
  global_options.x_cpp_warn_missing_include_dirs
  global_options_set._cpp_warn_missing_include_dirs

The flag processing happens as described in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534#c11
in short:
  - First gfc_init_options is called
  - Then for reach command-line option gfc_handle_option
  - Finally gfc_post_options

Currently:
- gfc_init_options: Sets cpp_warn_missing_include_dirs
  (unconditionally as unset)
- gfc_handle_option: Always warns about the missing include dir
- before gfc_post_options: set_option is called, which sets
  cpp_warn_missing_include_dirs – but that's too late.

Additionally, as mentioned above – pfile's warn_missing_include_dirs
is never properly set.

 * * *

This patch fixes those issues:
* Now -Wno-missing-include-dirs does silence the warnings
* CPP now also properly does warn.

Example (initial version):
$ gfortran-trunk ../empty.f90 -c -cpp -idirafter /fdaf/ -I bar/
-Wmissing-include-dirs
f951: Warning: Nonexistent include directory ‘bar//’
[-Wmissing-include-dirs]
: Warning: /fdaf/: No such file or directory
: Warning: bar/: No such file or directory

In order to avoid the double output for -I, I disabled the Fortran
output if
CPP is enabled. Additionally, I had to use the
cpp_reason_option_codes to
print the flag in brackets.
Fixed/final output is:

: Warning: /fdaf/: No such file or directory
[-Wmissing-include-dirs]
: Warning: bar/: No such file or directory
[-Wmissing-include-dirs]


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
Fortran: Fix -Wno-missing-include-dirs handling [PR55534]

gcc/fortran/ChangeLog:

	PR fortran/55534
	* cpp.c: Define GCC_C_COMMON_C for #include "options.h" to make
	cpp_reason_option_codes available.
	(gfc_cpp_register_include_paths): Make static, set pfile's
	warn_missing_include_dirs and move before caller.
	(gfc_cpp_init_cb): New, cb code moved from ...
	(gfc_cpp_init_0): ... here.
	(gfc_cpp_post_options): Call gfc_cpp_init_cb.
	(cb_cpp_diagnostic_cpp_option): New. As implemented in c-family
	to match CppReason flags to -W... names.
	(cb_cpp_diagnostic): Use it to replace single special case.
	* cpp.h (gfc_cpp_register_include_paths): Remove as now static.
	* gfortran.h (gfc_check_include_dirs): New prototype.
	(gfc_add_include_path): Add new bool arg.
	* options.c (gfc_init_options): Don't set -Wmissing-include-dirs.
	(gfc_post_options): Set it here after commandline processing. Call
	gfc_add_include_path with defer_warn=false.
	(gfc_handle_option): Call it with 

Re: [PATCH] c++: fix wrong fixit hints for misspelled typedef [PR77565]

[Jason Merrill via Gcc-patches]

On 9/17/21 13:31, Michel Morin wrote:

On Fri, Sep 17, 2021 at 3:23 AM Jason Merrill  wrote:


On 9/16/21 11:50, Michel Morin wrote:

On Thu, Sep 16, 2021 at 5:44 AM Jason Merrill  wrote:


On 9/14/21 04:29, Michel Morin via Gcc-patches wrote:

On Tue, Sep 14, 2021 at 7:14 AM David Malcolm  wrote:


On Tue, 2021-09-14 at 03:35 +0900, Michel Morin via Gcc-patches wrote:

Hi,

PR77565 reports that, with the code `typdef int Int;`, GCC emits
"did you mean 'typeof'?" instead of "did you mean 'typedef'?".

This happens because the typo corrector determines that `typeof` is a
candidate for suggestion (through
`cp_keyword_starts_decl_specifier_p`),
but `typedef` is not.

This patch fixes the issue by adding `typedef` as a candidate. The
patch
additionally adds the `inline` specifier and cv-specifiers as a
candidate.
Here is a patch (tests `make check-gcc` pass on darwin):


Thanks for this patch (and for reporting the bug in the first place).

I notice that, as well as being used for fix-it hints by
lookup_name_fuzzy (indirectly via suggest_rid_p),
cp_keyword_starts_decl_specifier_p is also used by
cp_lexer_next_token_is_decl_specifier_keyword, which is used by
cp_parser_lambda_declarator_opt and cp_parser_constructor_declarator_p.


Ah, you're right! Thank you for pointing this out.
I failed to grep those functions somehow.

One thing that confuses me is that cp_keyword_starts_decl_specifier_p
misses many keywords that can start decl-specifiers (e.g.
typedef/inline/cv-qual and friend/explicit/virtual).
So let's wait C++ frontend maintainers ;)


That is strange.  Let's add all the rest of them as well.


Done. Thanks for your help!

One more thing — cp_keyword_starts_decl_specifier_p includes RID_ATTRIBUTE
(from the beginning; see https://gcc.gnu.org/PR28261 ), but attributes are
not decl-specifiers. Would it be reasonable to remove this?


It looks like the place that PR28261 used
cp_lexer_next_token_is_decl_specifier_keyword specifically exempts
attributes:


   && (!cp_lexer_next_token_is_decl_specifier_keyword (parser->lexer)
   /* GNU attributes can actually appear both at the start of
  a parameter and parenthesized declarator.
  S (__attribute__((unused)) int);
  is a constructor, but
  S (__attribute__((unused)) foo) (int);
  is a function declaration.  */
   || (cp_parser_allow_gnu_extensions_p (parser)
   && cp_next_tokens_can_be_gnu_attribute_p (parser)))


So yes, let's remove RID_ATTRIBUTE and the || clause there.  I'd keep
the comment, but move it to go with the test for C++11 attributes below.


Done. No regressions introduced.


One more thing — cp_keyword_starts_decl_specifier_p includes RID_ATTRIBUTE
(from the beginning; see https://gcc.gnu.org/PR28261 ), but attributes are
not decl-specifiers.


Oh, this is wrong. I thought that, since C++11 attributes are not a
decl-specifier, neither are GNU attributes. But the comment just before
cp_parser_decl_specifier_seq says that GNU attributes are considered as a
decl-specifier. So I'm not confident about the removal of RID_ATTRIBUTE in
cp_keyword_starts_decl_specifier_p...


GNU attributes can appear in lots of places, and the only two callers of 
cp_parser_next_token_is_decl_specifier_keyword don't want to treat 
attributes accordingly.  Let's go with both your patches, and also 
remove the consequently-unnecessary attributes check in 
cp_parser_lambda_declarator_opt:



  if (cp_lexer_next_token_is_decl_specifier_keyword (parser->lexer)
  && !cp_next_tokens_can_be_gnu_attribute_p (parser))


OK with that change.


I've split the patch into two. The first one is for adding missing keywords to
fix PR77565 and the second one is for removing the "attribute" keyword.
Here is the second patch (if this is not applied, that's no problem ;) )

==
c++: adjust the handling of RID_ATTRIBUTE.

gcc/cp/ChangeLog:

* parser.c (cp_keyword_starts_decl_specifier_p): Do not
handle RID_ATTRIBUTE.
(cp_parser_constructor_declarator_p): Remove now-redundant
checks.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 40308d0d33f..d184a3aca7e 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -1062,7 +1062,6 @@ cp_keyword_starts_decl_specifier_p (enum rid keyword)
  case RID_TYPEDEF:
  case RID_INLINE:
/* GNU extensions.  */
-case RID_ATTRIBUTE:
  case RID_TYPEOF:
/* C++11 extensions.  */
  case RID_DECLTYPE:
@@ -30798,23 +30797,22 @@ cp_parser_constructor_declarator_p
(cp_parser *parser, cp_parser_flags flags,
 /* A parameter declaration begins with a decl-specifier,
which is either the "attribute" keyword, a storage class
specifier, or (usually) a type-specifier.  */
-   && (!cp_lexer_next_token_is_decl_specifier_keyword (parser->lexer)
-   /* GNU attributes can actually appear both at the start of
- a parameter and 

Re: [PATCH] c++: consider built-in operator candidates first

[Jason Merrill via Gcc-patches]

On 9/20/21 15:32, Patrick Palka wrote:

On Mon, 20 Sep 2021, Jason Merrill wrote:


On 9/20/21 12:46, Patrick Palka wrote:

During operator overload resolution, we currently consider non-member
candidates before built-in candidates.  This didn't make a difference
before r12-3346, but after this change add_candidates will avoid
computing excess argument conversions if we've already seen a strictly
viable candidate, so it's better to consider built-in candidates first.


Doesn't r12-3346 stop considering conversions after it sees a bad one, and
later return to the bad candidate if there is no strictly viable candidate?
How does this patch change that?


Yes, but add_candidates also looks for a strictly viable candidate among
the already-considered candidates in the 'candidates' list via the line:

   bool seen_strictly_viable = any_strictly_viable (*candidates);

So by considering the built-in candidates first, the subsequent call to
add_candidates that considers the non-member functions in will be aware
of any (built-in) strictly viable candidate.


Ah, I get it, the problem is that the first add_candidates can't see any 
strictly-viable candidates.



Depending on the order of the candidates seems fragile.


Yeah.. :/  I guess in general it'd be better to build up the entire
overload set first and then call add_candidates exactly once (which
would also make the perfect candidate optimization more consistent/effective).
But I'm not sure if we can easily build up such an overload set in this
case since built-in candidates are represented and handled differently
than non-built-in candidates..


Or as another way of getting the same effect, add another possible value 
of shortcut_bad_convs to mean leave bad candidates incomplete in the 
candidates list, and then once we're done adding candidates and still 
don't have a viable one, we can go back and finish processing the bad 
candidates?


Either way, this could also help when there are both member and 
non-member candidates for the operator.



FWIW, although the test case added by this patch is contrived, this
opportunity was found in the real world by instrumenting the 'bad_fns'
mechanism added by r12-3346 to look for situations where we still end up
using it (and thus end up redundantly considering some candidates twice),
and this built-in operator situation was the most common in the
codebases that I tested (although still quite rare in the codebases that
I tested).





Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

gcc/cp/ChangeLog:

* call.c (add_operator_candidates): Consider built-in operator
candidates before considering non-member candidates.

gcc/testsuite/ChangeLog:

* g++.dg/template/conv17.C: Extend test.
---
   gcc/cp/call.c  | 13 +++--
   gcc/testsuite/g++.dg/template/conv17.C |  7 +++
   2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c5601d96ab8..c0da083758f 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6321,7 +6321,6 @@ add_operator_candidates (z_candidate **candidates,
 vec *arglist,
 int flags, tsubst_flags_t complain)
   {
-  z_candidate *start_candidates = *candidates;
 bool ismodop = code2 != ERROR_MARK;
 tree fnname = ovl_op_identifier (ismodop, ismodop ? code2 : code);
   @@ -6333,6 +6332,12 @@ add_operator_candidates (z_candidate **candidates,
 if (rewritten && code != EQ_EXPR && code != SPACESHIP_EXPR)
   flags &= ~LOOKUP_REWRITTEN;
   +  /* Add built-in candidates to the candidate set.  The standard says to
+ rewrite built-in candidates, too, but there's no point.  */
+  if (!rewritten)
+add_builtin_candidates (candidates, code, code2, fnname, arglist,
+   flags, complain);
+
 bool memonly = false;
 switch (code)
   {
@@ -6352,6 +6357,7 @@ add_operator_candidates (z_candidate **candidates,
   /* Add namespace-scope operators to the list of functions to
consider.  */
+  z_candidate *start_candidates = *candidates;
 if (!memonly)
   {
 tree fns = lookup_name (fnname, LOOK_where::BLOCK_NAMESPACE);
@@ -6423,11 +6429,6 @@ add_operator_candidates (z_candidate **candidates,
   if (!rewritten)
   {
-  /* The standard says to rewrite built-in candidates, too,
-but there's no point.  */
-  add_builtin_candidates (candidates, code, code2, fnname, arglist,
- flags, complain);
-
 /* Maybe add C++20 rewritten comparison candidates.  */
 tree_code rewrite_code = ERROR_MARK;
 if (cxx_dialect >= cxx20
diff --git a/gcc/testsuite/g++.dg/template/conv17.C
b/gcc/testsuite/g++.dg/template/conv17.C
index f0f10f2ef4f..87ecefb8de3 100644
--- a/gcc/testsuite/g++.dg/template/conv17.C
+++ b/gcc/testsuite/g++.dg/template/conv17.C
@@ -61,3 +61,10 @@ concept E = requires { T().h(nullptr); };
 

[Bug other/102408] [OpenACC] omp-oacc-neuter-broadcast.cc: random() not available on all platforms

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102408

Thomas Schwinge  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-09-20
 CC||jules at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
   Keywords||openacc
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

--- Comment #1 from Thomas Schwinge  ---
Sorry for the temporary breakage, I'll get this sorted out tomorrow; see
.

[Bug c++/102418] New: [concepts] prefer iterator to range concept failures in ranges (QoI)

[ldalessandro at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102418

Bug ID: 102418
   Summary: [concepts] prefer iterator to range concept failures
in ranges (QoI)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

When interacting with the ranges library I am occasionally presented with
hundreds of lines of circuitous concept failures driven by failing a range
concept. The vast majority of programmers won't find these helpful.

On the other hand, it was pointed out that when the failure is due to one of
the range's dependent iterator concepts, asserting the corresponding iterator
concept produces beautiful and too-the-point failure traces.

>From a QoI perspective, some mechanism to prioritize the iterator concept
failure when it is responsible for a range concept failure would go a long way
to making ranges more usable.

The example I was playing with is at https://godbolt.org/z/fGWcTdEjo, an is the
difference in output when -DITERATOR is defined in the following example.

```
struct Broken {
struct iterator {
int i;
auto operator*() const -> decltype(auto) {
return std::tie(i);
}
auto operator++() -> decltype(auto) {
++i;
return *this;
}
friend bool operator==(iterator const&, iterator const&) = default;
friend auto operator<=>(iterator const&, iterator const&) = default;
};

auto begin() const -> iterator { return {}; }
auto end() const -> iterator { return {}; }
};

#ifdef ITERATOR
static_assert(std::input_iterator);
#else

#include 

int foo() {
Broken r;
std::ranges::for_each(r, [](auto t) { 
auto [i] = t;
printf("%d\n", i);
});
}
#endif
```

[Bug c/102416] [12 Regression] ICE in gimplify_expr, at gimplify.c:15570

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102416

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

Re: [PATCH v2] C++: add type checking for static local vector variable in template

[Jason Merrill via Gcc-patches]

On 9/18/21 01:53, wangpc wrote:

This patch moves verify_type_context from start_decl_1 to cp_finish_decl to
do more type checking such as static local vector variable in C++ template.


Applied, thanks.  Though a couple of issues with the patch formatting:


2021-08-06  wangpc  

gcc/cp/ChangeLog

 * decl.c (start_decl_1): Move verify_type_context to ...
(cp_finish_decl): ... to here.

gcc/testsuite/ChangeLog

 * g++.target/aarch64/sve/static-var-in-template.C: New test.


I needed to adjust the spacing on the ChangeLog entries so that the git 
hook would accept them: lines need to start with a single tab.



diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 90111e4c786..deaa6c56a8f 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5491,13 +5491,6 @@ start_decl_1 (tree decl, bool initialized)
cp_apply_type_quals_to_decl (cp_type_quals (type), decl);
  }
  
-  if (is_global_var (decl))

-{
-  type_context_kind context = (DECL_THREAD_LOCAL_P (decl)
-  ? TCTX_THREAD_STORAGE
-  : TCTX_STATIC_STORAGE);
-  verify_type_context (input_location, context, TREE_TYPE (decl));
-}
if (initialized)


I needed to apply this hunk by hand because there's a missing blank line 
before if (initialized).



  /* Is it valid for this decl to have an initializer at all?  */
  {
@@ -7520,6 +7513,14 @@ cp_finish_decl (tree decl, tree init, bool 
init_const_expr_p,
&& DECL_INITIALIZED_IN_CLASS_P (decl))
  check_static_variable_definition (decl, type);
  
+  if (!processing_template_decl && VAR_P (decl) && is_global_var (decl))

+{
+  type_context_kind context = (DECL_THREAD_LOCAL_P (decl)
+  ? TCTX_THREAD_STORAGE
+  : TCTX_STATIC_STORAGE);
+  verify_type_context (input_location, context, TREE_TYPE (decl));
+}
+
if (init && TREE_CODE (decl) == FUNCTION_DECL)
  {
tree clone;
diff --git a/gcc/testsuite/g++.target/aarch64/sve/static-var-in-template.C 
b/gcc/testsuite/g++.target/aarch64/sve/static-var-in-template.C
new file mode 100644
index 000..74237ff7c57
--- /dev/null
+++ b/gcc/testsuite/g++.target/aarch64/sve/static-var-in-template.C
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+
+#include 
+
+template 
+void f()
+{
+static svbool_t pg = svwhilelt_b64(0, N);
+}
+
+int main(int argc, char **argv)
+{
+f<2>();
+return 0;
+}
+
+/* { dg-error "SVE type 'svbool_t' does not have a fixed size" "" { target 
*-*-* } 0 } */

[Bug c++/102413] [12 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1172

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102413

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

Re: [PATCH] c++: consider built-in operator candidates first

[Patrick Palka via Gcc-patches]

On Mon, 20 Sep 2021, Jason Merrill wrote:

> On 9/20/21 12:46, Patrick Palka wrote:
> > During operator overload resolution, we currently consider non-member
> > candidates before built-in candidates.  This didn't make a difference
> > before r12-3346, but after this change add_candidates will avoid
> > computing excess argument conversions if we've already seen a strictly
> > viable candidate, so it's better to consider built-in candidates first.
> 
> Doesn't r12-3346 stop considering conversions after it sees a bad one, and
> later return to the bad candidate if there is no strictly viable candidate?
> How does this patch change that?

Yes, but add_candidates also looks for a strictly viable candidate among
the already-considered candidates in the 'candidates' list via the line:

  bool seen_strictly_viable = any_strictly_viable (*candidates);

So by considering the built-in candidates first, the subsequent call to
add_candidates that considers the non-member functions in will be aware
of any (built-in) strictly viable candidate.

> 
> Depending on the order of the candidates seems fragile.

Yeah.. :/  I guess in general it'd be better to build up the entire
overload set first and then call add_candidates exactly once (which
would also make the perfect candidate optimization more consistent/effective).
But I'm not sure if we can easily build up such an overload set in this
case since built-in candidates are represented and handled differently
than non-built-in candidates..

FWIW, although the test case added by this patch is contrived, this
opportunity was found in the real world by instrumenting the 'bad_fns'
mechanism added by r12-3346 to look for situations where we still end up
using it (and thus end up redundantly considering some candidates twice),
and this built-in operator situation was the most common in the
codebases that I tested (although still quite rare in the codebases that
I tested).

> 
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> > 
> > gcc/cp/ChangeLog:
> > 
> > * call.c (add_operator_candidates): Consider built-in operator
> > candidates before considering non-member candidates.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/template/conv17.C: Extend test.
> > ---
> >   gcc/cp/call.c  | 13 +++--
> >   gcc/testsuite/g++.dg/template/conv17.C |  7 +++
> >   2 files changed, 14 insertions(+), 6 deletions(-)
> > 
> > diff --git a/gcc/cp/call.c b/gcc/cp/call.c
> > index c5601d96ab8..c0da083758f 100644
> > --- a/gcc/cp/call.c
> > +++ b/gcc/cp/call.c
> > @@ -6321,7 +6321,6 @@ add_operator_candidates (z_candidate **candidates,
> >  vec *arglist,
> >  int flags, tsubst_flags_t complain)
> >   {
> > -  z_candidate *start_candidates = *candidates;
> > bool ismodop = code2 != ERROR_MARK;
> > tree fnname = ovl_op_identifier (ismodop, ismodop ? code2 : code);
> >   @@ -6333,6 +6332,12 @@ add_operator_candidates (z_candidate **candidates,
> > if (rewritten && code != EQ_EXPR && code != SPACESHIP_EXPR)
> >   flags &= ~LOOKUP_REWRITTEN;
> >   +  /* Add built-in candidates to the candidate set.  The standard says to
> > + rewrite built-in candidates, too, but there's no point.  */
> > +  if (!rewritten)
> > +add_builtin_candidates (candidates, code, code2, fnname, arglist,
> > +   flags, complain);
> > +
> > bool memonly = false;
> > switch (code)
> >   {
> > @@ -6352,6 +6357,7 @@ add_operator_candidates (z_candidate **candidates,
> >   /* Add namespace-scope operators to the list of functions to
> >consider.  */
> > +  z_candidate *start_candidates = *candidates;
> > if (!memonly)
> >   {
> > tree fns = lookup_name (fnname, LOOK_where::BLOCK_NAMESPACE);
> > @@ -6423,11 +6429,6 @@ add_operator_candidates (z_candidate **candidates,
> >   if (!rewritten)
> >   {
> > -  /* The standard says to rewrite built-in candidates, too,
> > -but there's no point.  */
> > -  add_builtin_candidates (candidates, code, code2, fnname, arglist,
> > - flags, complain);
> > -
> > /* Maybe add C++20 rewritten comparison candidates.  */
> > tree_code rewrite_code = ERROR_MARK;
> > if (cxx_dialect >= cxx20
> > diff --git a/gcc/testsuite/g++.dg/template/conv17.C
> > b/gcc/testsuite/g++.dg/template/conv17.C
> > index f0f10f2ef4f..87ecefb8de3 100644
> > --- a/gcc/testsuite/g++.dg/template/conv17.C
> > +++ b/gcc/testsuite/g++.dg/template/conv17.C
> > @@ -61,3 +61,10 @@ concept E = requires { T().h(nullptr); };
> > static_assert(!E);
> >   #endif
> > +
> > +// Verify that the strictly viable built-in operator+ candidate precludes
> > +// us from computing all argument conversions for the below non-strictly
> > +// viable non-member candidate.
> > +enum N { n };
> > +int operator+(N&, B);
> > +int f = n + 42;
> > 
> 
> 

[Bug fortran/102417] Wrong error message about character length with -std=f2018

[gscfq--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102417

--- Comment #1 from G. Steinmetz  ---

And obviously, works with a single AC :


$ cat z0.f90
program p
   character :: x = 'a'
   character(4) :: y(3)
   y = [character(4) :: x, 'b', 'c']
   print *, y
end

$ gfortran-12-20210919 z0.f90 -std=f2018 -Wall && ./a.out
 a   b   c

[Bug fortran/102417] New: Wrong error message about character length with -std=f2018

[gscfq--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102417

Bug ID: 102417
   Summary: Wrong error message about character length with
-std=f2018
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

An embedded AC together with option -std=f2018 (or f2008 etc.)
produces a misleading error message. Typespec is explicitly given.
Affects versions down to at least r5.

That unique error message comes from line 1888 in decl.c.
Issue is eventually related to pr102315.


$ cat z1.f90
program p
   character :: x = 'a'
   character(4) :: y(3)
   y = [[character(4) :: x, 'b', 'c']]
   print *, y
end


$ gfortran-12-20210919 -c z1.f90 -std=f2018 -Wall
z1.f90:4:27:

4 |y = [[character(4) :: x, 'b', 'c']]
  |   1
Warning: CHARACTER expression at (1) is being truncated (4/1)
[-Wcharacter-truncation]
z1.f90:4:27: Error: The CHARACTER elements of the array constructor at (1) must
have the same length (4/1)
z1.f90:4:32:

4 |y = [[character(4) :: x, 'b', 'c']]
  |1
Warning: CHARACTER expression at (1) is being truncated (4/1)
[-Wcharacter-truncation]
z1.f90:4:32: Error: The CHARACTER elements of the array constructor at (1) must
have the same length (4/1)

Re: [PATCH] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

[Jakub Jelinek via Gcc-patches]

On Mon, Sep 20, 2021 at 02:37:03PM -0400, Marek Polacek wrote:
> > So, wouldn't be this better specified as
> > Wno-attributes=
> > Common Joined RejectNegative
> > (not sure if RejectNegative is actually needed for an option
> > starting with Wno- )?
> 
> Looks like RejectNegative is not needed.  I could do that, but I think
> it regresses the diagnostic:
> 
> error: unrecognized command-line option '-Wattributes=attr::'
> vs
> error: arguments ignored for ‘-Wattributes=’; use ‘-Wno-attributes=’ instead
> 
> I prefer the latter.  (I've changed the warning into error.)

Ok.

> > > +/* { dg-additional-options "-std=c++11" { target c++ } } */
> > > +/* { dg-additional-options "-Wno-attributes=company::,yoyodyne::attr" } 
> > > */
> > > +/* { dg-additional-options 
> > > "-Wno-attributes=c1::attr,c1::attr,c1::__attr__" } */
> > > +/* { dg-additional-options "-Wno-attributes=clang" } */
> > > +/* { dg-additional-options "-Wno-attributes=c2::,c2::attr" } */
> > > +/* { dg-additional-options "-Wno-attributes=c3::attr,c3::" } */
> > > +/* { dg-additional-options "-Wno-attributes=x::," } */
> > 
> > Should the above be accepted (I mean trailing , ?)  What does that mean?
>  
> I'm thinking it should: the arguments to -Wno-attributes= could be
> generated by a tool so accepting the trailing , might help, like in
> enums etc.

I don't think we allow that for any other options that accept a list of
something (except maybe -W{p,c,a,l}, those just pass the args through).
Generating a list that has comma separation only in between items and not
at the end is trivial.

Jakub

[Bug fortran/102315] ICE tree check: expected integer_cst, have save_expr in gfc_trans_array_constructor_value, at fortran/trans-array.c:2056

[gscfq--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102315

--- Comment #3 from G. Steinmetz  ---

A reduced variant with the same ICE :

$ cat z2.f90
program p
   character :: x = 'a'
   character :: y(5)
   y = [[trim(x), 'b', 'c', 'd', 'e']]
   print *, y
end



But z1 gives additional hints when reduced to four or less
array elements. It compiles and runs correctly, like :

$ cat za1.f90
program p
   character(4) :: x = '123'
   character(8) :: y(4)
   y = [[character(8) :: 'a'//trim(x), 'b', 'c', 'd']]
   print *, y
end

$ gfortran-12-20210919 za1.f90 && ./a.out
 a123b   c   d


And it fails with a wrong runtime error when adding checks via
-fcheck=bounds or -fcheck=all :

$ gfortran-12-20210919 za1.f90 -g -fcheck=all && ./a.out
At line 4 of file za1.f90
Fortran runtime error: Different CHARACTER lengths (4/8) in array constructor

Error termination. Backtrace:
#0  0x4026b7 in p
at .../za1.f90:4
#1  0x4029c9 in main
at .../za1.f90:6


That unique error message comes from line 1787 in trans-array.c

[Bug c/102415] [12 Regression] ICE in bb_seq_addr, at gimple.h:1786

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102415

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2021-09-20
 Ever confirmed|0   |1

[Bug c/102416] New: [12 Regression] ICE in gimplify_expr, at gimplify.c:15570

[gscfq--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102416

Bug ID: 102416
   Summary: [12 Regression] ICE in gimplify_expr, at
gimplify.c:15570
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210523 and 20210530 :


$ cat z1.c
void *f ()
{
  #pragma omp task affinity(f()[2])
  ;
}


$ cat z2.c
void f ()
{
  struct S *x;
  #pragma omp task affinity(*x)
  ;
}


$ gcc-12-20210919 -c z1.c -fopenmp
z1.c: In function 'f':
z1.c:3:32: warning: dereferencing 'void *' pointer
3 |   #pragma omp task affinity(f()[2])
  |^
z1.c:3:28: warning: dereferencing 'void *' pointer
3 |   #pragma omp task affinity(f()[2])
  |^
z1.c:3:28: internal compiler error: in gimplify_expr, at gimplify.c:15570
0x960cc4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:15570
0x9581e4 gimplify_omp_affinity
../../gcc/gimplify.c:8105
0x9581e4 gimplify_scan_omp_clauses
../../gcc/gimplify.c:9924
0x95dbeb gimplify_omp_task
../../gcc/gimplify.c:11814
0x95dbeb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:15062
0x960cf8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:7006
0x961251 gimplify_bind_expr
../../gcc/gimplify.c:1426
0x95ecca gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14769
0x960cf8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:7006
0x961d6b gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:15814
0x9621bf gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:15968
0x7eaf97 cgraph_node::analyze()
../../gcc/cgraphunit.c:670
0x7ed8e7 analyze_functions
../../gcc/cgraphunit.c:1234
0x7ee2ad symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2508

[Bug c/102415] New: [12 Regression] ICE in bb_seq_addr, at gimple.h:1786

[gscfq--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102415

Bug ID: 102415
   Summary: [12 Regression] ICE in bb_seq_addr, at gimple.h:1786
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210808 and 20210822 :


$ cat z1.c
void abort ();
void f ()
{
  #pragma omp scope nowait
  abort ();
}


$ gcc-12-20210919 -c z1.c -fopenmp
during GIMPLE pass: ompexp
z1.c: In function 'f':
z1.c:4:11: internal compiler error: Segmentation fault
4 |   #pragma omp scope nowait
  |   ^~~
0xbdd88f crash_signal
../../gcc/toplev.c:328
0x176a67a bb_seq_addr
../../gcc/gimple.h:1786
0x176a67a gsi_last_bb
../../gcc/gimple-iterator.h:164
0x176a67a gsi_last_nondebug_bb
../../gcc/gimple-iterator.h:306
0x176a67a expand_omp_single
../../gcc/omp-expand.c:8441
0x176a67a expand_omp
../../gcc/omp-expand.c:10246
0x176c63d execute_expand_omp
../../gcc/omp-expand.c:10467

[Bug c++/102413] [12 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1172

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102413

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-09-20

Re: [PATCH v2] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

[Marek Polacek via Gcc-patches]

On Mon, Sep 20, 2021 at 02:37:03PM -0400, Marek Polacek wrote:
> > > +/* { dg-additional-options "-Wno-attributes=yoyodyne::attr_new" } */
> > > +/* { dg-additional-options "-Wno-attributes=c4::__attr__" } */
> > 
> > When writing __attr__, does that imply we won't warn about both
> > c4::attr and c4::__attr__ (and __c4__::attr and __c4__::__attr__) like
> > it would when writing -Wno-attributes=c4::attr ?
> 
> "__attr__" and "attr" ought to be interchangeable.  __c4__:: and c4:: 
> currently
> are not, but I guess they should.  I'll post a v2 with that fixed.

Here's v2 with the documentation enhancement, warning -> error, and
which handles __vendor__:: the same as vendor::.

Regtest/bootstrap running.

-- >8 --
It is desirable for -Wattributes to warn about e.g.

[[deprecate]] void g(); // typo, should warn

However, -Wattributes also warns about vendor-specific attributes
(that's because lookup_scoped_attribute_spec -> find_attribute_namespace
finds nothing), which, with -Werror, causes grief.  We don't want the
-Wattributes warning for

[[company::attr]] void f();

GCC warns because it doesn't know the "company" namespace; it only knows
the "gnu" and "omp" namespaces.  We could entirely disable warning about
attributes in unknown scopes but then the compiler would also miss typos
like

  [[company::attrx]] void f();

or

  [[gmu::warn_used_result]] int write();

so that is not a viable solution.  A workaround is to use a #pragma:

  #pragma GCC diagnostic push
  #pragma GCC diagnostic ignored "-Wattributes"
  [[company::attr]] void f() {}
  #pragma GCC diagnostic pop

but that's a mouthful and awkward to use and could also hide typos.  In
fact, any macro-based solution doesn't seem like a way forward.

This patch implements -Wno-attributes=, which takes these arguments:

company::attr
company::
clang

The last one is a special option to ignore clang-only attributes; in
this patch it is accepted but currently has no effect.

This option should go well with using @file: the user could have a file
containing
-Wno-attributes=vendor::attr1,vendor::attr2
and then invoke gcc with '@attrs' or similar.

I've also added a new pragma which has the same effect:

The pragma along with the new option should help with various static
analysis tools.

PR c++/101940

gcc/ChangeLog:

* attribs.c (struct scoped_attributes): Add a bool member.
(lookup_scoped_attribute_spec): Forward declare.
(register_scoped_attributes): New bool parameter, defaulted to
false.  Use it.
(handle_ignored_attributes_option): New function.
(free_attr_data): New function.
(init_attributes): Call handle_ignored_attributes_option.
(attr_namespace_ignored_p): New function.
(decl_attributes): Check attr_namespace_ignored_p before
warning.
* attribs.h (free_attr_data): Declare.
(register_scoped_attributes): Adjust declaration.
(handle_ignored_attributes_option): Declare.
* common.opt (Wattributes=): New option with a variable.
* doc/extend.texi: Document #pragma GCC diagnostic ignored_attributes.
* doc/invoke.texi: Document -Wno-attributes=.
* opts.c (common_handle_option) : Handle.
* plugin.h (register_scoped_attributes): Adjust declaration.

gcc/c-family/ChangeLog:

* c-pragma.c (handle_pragma_diagnostic): Handle #pragma GCC diagnostic
ignored_attributes.

gcc/c/ChangeLog:

* c-decl.c (c_parse_final_cleanups): Call free_attr_data.

gcc/cp/ChangeLog:

* decl2.c (c_parse_final_cleanups): Call free_attr_data.

gcc/testsuite/ChangeLog:

* c-c++-common/Wno-attributes-1.c: New test.
* c-c++-common/Wno-attributes-2.c: New test.
---
 gcc/attribs.c | 126 +-
 gcc/attribs.h |   5 +-
 gcc/c-family/c-pragma.c   |  22 ++-
 gcc/c/c-decl.c|   2 +
 gcc/common.opt|   9 +-
 gcc/cp/decl2.c|   2 +
 gcc/doc/extend.texi   |  19 +++
 gcc/doc/invoke.texi   |  20 +++
 gcc/opts.c|  14 ++
 gcc/plugin.h  |   4 +-
 gcc/testsuite/c-c++-common/Wno-attributes-1.c |  56 
 gcc/testsuite/c-c++-common/Wno-attributes-2.c |  57 
 12 files changed, 327 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/Wno-attributes-1.c
 create mode 100644 gcc/testsuite/c-c++-common/Wno-attributes-2.c

diff --git a/gcc/attribs.c b/gcc/attribs.c
index 83fafc98b7d..869006e3526 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -87,6 +87,8 @@ struct scoped_attributes
   const char *ns;
   vec attributes;
   hash_table *attribute_hash;
+  /* True if we should not warn about unknown attributes in this NS.  */
+  bool ignored_p;
 };
 
 /* The table of scope 

[Bug c++/102414] New: [12 Regression] ICE in unify_array_domain, at cp/pt.c:23442

[gscfq--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102414

Bug ID: 102414
   Summary: [12 Regression] ICE in unify_array_domain, at
cp/pt.c:23442
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210627 and 20210704 :


$ cat z1.cc
void f ()
{
  int a[3];
  auto (*b)[0/0] = 
}


$ g++-12-20210919 -c z1.cc
z1.cc: In function 'void f()':
z1.cc:4:14: warning: division by zero [-Wdiv-by-zero]
4 |   auto (*b)[0/0] = 
  | ~^~
z1.cc:4:21: internal compiler error: in unify_array_domain, at cp/pt.c:23442
4 |   auto (*b)[0/0] = 
  | ^
0x671a18 unify_array_domain
../../gcc/cp/pt.c:23442
0x8160a5 unify
../../gcc/cp/pt.c:24013
0x815da3 unify
../../gcc/cp/pt.c:24319
0x814b99 unify_one_argument
../../gcc/cp/pt.c:22271
0x8225b6 type_unification_real
../../gcc/cp/pt.c:22390
0x80aea5 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/cp/pt.c:29807
0x732d36 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7948
0x7f3caf cp_parser_init_declarator
../../gcc/cp/parser.c:22665
0x7d1b52 cp_parser_simple_declaration
../../gcc/cp/parser.c:15133
0x7d37c9 cp_parser_declaration_statement
../../gcc/cp/parser.c:14214
0x7d3e4c cp_parser_statement
../../gcc/cp/parser.c:12306
0x7d4cb4 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:12713
0x7d4d6f cp_parser_compound_statement
../../gcc/cp/parser.c:12662
0x7f2e78 cp_parser_function_body
../../gcc/cp/parser.c:24893
0x7f2e78 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:24944
0x7f3326 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:31066
0x7f4247 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:30982
0x7f4247 cp_parser_init_declarator
../../gcc/cp/parser.c:22427
0x7d1b52 cp_parser_simple_declaration
../../gcc/cp/parser.c:15133
0x7f9a1f cp_parser_declaration
../../gcc/cp/parser.c:14819

[Bug c++/102413] New: [12 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1172

[gscfq--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102413

Bug ID: 102413
   Summary: [12 Regression] ICE in cp_lexer_consume_token, at
cp/parser.c:1172
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210627 and 20210704 :


$ cat z1.cc
[[omp::directive(error]];


$ g++-12-20210919 -c z1.cc -fopenmp
z1.cc:1:25: internal compiler error: in cp_lexer_consume_token, at
cp/parser.c:1172
1 | [[omp::directive(error]];
  | ^
0x7b6c27 cp_lexer_consume_token
../../gcc/cp/parser.c:1172
0x7b8966 cp_parser_omp_directive_args
../../gcc/cp/parser.c:28632
0x7e0005 cp_parser_std_attribute
../../gcc/cp/parser.c:28871
0x7e0005 cp_parser_std_attribute_list
../../gcc/cp/parser.c:28961
0x7e0005 cp_parser_std_attribute_spec
../../gcc/cp/parser.c:29049
0x7e0005 cp_parser_std_attribute_spec_seq
../../gcc/cp/parser.c:29142
0x7d1267 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:15516
0x7d19f1 cp_parser_simple_declaration
../../gcc/cp/parser.c:15006
0x7f9a1f cp_parser_declaration
../../gcc/cp/parser.c:14819
0x7fa4ab cp_parser_translation_unit
../../gcc/cp/parser.c:4978
0x7fa4ab c_parse_file()
../../gcc/cp/parser.c:47694
0x8cb652 c_common_parse_file()
../../gcc/c-family/c-opts.c:1236

Re: [PATCH] c++: consider built-in operator candidates first

[Jason Merrill via Gcc-patches]

On 9/20/21 12:46, Patrick Palka wrote:

During operator overload resolution, we currently consider non-member
candidates before built-in candidates.  This didn't make a difference
before r12-3346, but after this change add_candidates will avoid
computing excess argument conversions if we've already seen a strictly
viable candidate, so it's better to consider built-in candidates first.


Doesn't r12-3346 stop considering conversions after it sees a bad one, 
and later return to the bad candidate if there is no strictly viable 
candidate?  How does this patch change that?


Depending on the order of the candidates seems fragile.


Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

gcc/cp/ChangeLog:

* call.c (add_operator_candidates): Consider built-in operator
candidates before considering non-member candidates.

gcc/testsuite/ChangeLog:

* g++.dg/template/conv17.C: Extend test.
---
  gcc/cp/call.c  | 13 +++--
  gcc/testsuite/g++.dg/template/conv17.C |  7 +++
  2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c5601d96ab8..c0da083758f 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6321,7 +6321,6 @@ add_operator_candidates (z_candidate **candidates,
 vec *arglist,
 int flags, tsubst_flags_t complain)
  {
-  z_candidate *start_candidates = *candidates;
bool ismodop = code2 != ERROR_MARK;
tree fnname = ovl_op_identifier (ismodop, ismodop ? code2 : code);
  
@@ -6333,6 +6332,12 @@ add_operator_candidates (z_candidate **candidates,

if (rewritten && code != EQ_EXPR && code != SPACESHIP_EXPR)
  flags &= ~LOOKUP_REWRITTEN;
  
+  /* Add built-in candidates to the candidate set.  The standard says to

+ rewrite built-in candidates, too, but there's no point.  */
+  if (!rewritten)
+add_builtin_candidates (candidates, code, code2, fnname, arglist,
+   flags, complain);
+
bool memonly = false;
switch (code)
  {
@@ -6352,6 +6357,7 @@ add_operator_candidates (z_candidate **candidates,
  
/* Add namespace-scope operators to the list of functions to

   consider.  */
+  z_candidate *start_candidates = *candidates;
if (!memonly)
  {
tree fns = lookup_name (fnname, LOOK_where::BLOCK_NAMESPACE);
@@ -6423,11 +6429,6 @@ add_operator_candidates (z_candidate **candidates,
  
if (!rewritten)

  {
-  /* The standard says to rewrite built-in candidates, too,
-but there's no point.  */
-  add_builtin_candidates (candidates, code, code2, fnname, arglist,
- flags, complain);
-
/* Maybe add C++20 rewritten comparison candidates.  */
tree_code rewrite_code = ERROR_MARK;
if (cxx_dialect >= cxx20
diff --git a/gcc/testsuite/g++.dg/template/conv17.C 
b/gcc/testsuite/g++.dg/template/conv17.C
index f0f10f2ef4f..87ecefb8de3 100644
--- a/gcc/testsuite/g++.dg/template/conv17.C
+++ b/gcc/testsuite/g++.dg/template/conv17.C
@@ -61,3 +61,10 @@ concept E = requires { T().h(nullptr); };
  
  static_assert(!E);

  #endif
+
+// Verify that the strictly viable built-in operator+ candidate precludes
+// us from computing all argument conversions for the below non-strictly
+// viable non-member candidate.
+enum N { n };
+int operator+(N&, B);
+int f = n + 42;

Re: [PATCH] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

[Marek Polacek via Gcc-patches]

On Mon, Sep 20, 2021 at 07:38:59PM +0200, Jakub Jelinek wrote:
> On Mon, Sep 20, 2021 at 01:06:58PM -0400, Marek Polacek via Gcc-patches wrote:
> 
> Not a review, just a few nits:
> 
> I think it would be useful to clarify that -Wno-attributes=list doesn't
> actually imply -Wno-attributes

Agreed, fixed with:

+Note that @option{-Wno-attributes=} does not imply @option{-Wno-attributes}.
 
> > --- a/gcc/common.opt
> > +++ b/gcc/common.opt
> > @@ -88,6 +88,9 @@ void *flag_instrument_functions_exclude_functions
> >  Variable
> >  void *flag_instrument_functions_exclude_files
> >  
> > +Variable
> > +void *flag_ignored_attributes
> > +
> >  ; Generic structs (e.g. templates not explicitly specialized)
> >  ; may not have a compilation unit associated with them, and so
> >  ; may need to be treated differently from ordinary structs.
> > @@ -546,6 +549,10 @@ Wattributes
> >  Common Var(warn_attributes) Init(1) Warning
> >  Warn about inappropriate attribute usage.
> >  
> > +Wattributes=
> > +Common Joined
> > +Do not warn about specified attributes.
> > +
> 
> So, wouldn't be this better specified as
> Wno-attributes=
> Common Joined RejectNegative
> (not sure if RejectNegative is actually needed for an option
> starting with Wno- )?

Looks like RejectNegative is not needed.  I could do that, but I think
it regresses the diagnostic:

error: unrecognized command-line option '-Wattributes=attr::'
vs
error: arguments ignored for ‘-Wattributes=’; use ‘-Wno-attributes=’ instead

I prefer the latter.  (I've changed the warning into error.)
 
> > +/* { dg-additional-options "-std=c++11" { target c++ } } */
> > +/* { dg-additional-options "-Wno-attributes=company::,yoyodyne::attr" } */
> > +/* { dg-additional-options 
> > "-Wno-attributes=c1::attr,c1::attr,c1::__attr__" } */
> > +/* { dg-additional-options "-Wno-attributes=clang" } */
> > +/* { dg-additional-options "-Wno-attributes=c2::,c2::attr" } */
> > +/* { dg-additional-options "-Wno-attributes=c3::attr,c3::" } */
> > +/* { dg-additional-options "-Wno-attributes=x::," } */
> 
> Should the above be accepted (I mean trailing , ?)  What does that mean?
 
I'm thinking it should: the arguments to -Wno-attributes= could be
generated by a tool so accepting the trailing , might help, like in
enums etc.

> > +/* { dg-additional-options "-Wno-attributes=yoyodyne::attr_new" } */
> > +/* { dg-additional-options "-Wno-attributes=c4::__attr__" } */
> 
> When writing __attr__, does that imply we won't warn about both
> c4::attr and c4::__attr__ (and __c4__::attr and __c4__::__attr__) like
> it would when writing -Wno-attributes=c4::attr ?

"__attr__" and "attr" ought to be interchangeable.  __c4__:: and c4:: currently
are not, but I guess they should.  I'll post a v2 with that fixed.

Thanks!
--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

[Bug c++/102412] Template argument deduction fails when using concept as defaulted non-type template parameter

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102412

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Target Milestone|--- |11.3
   Last reconfirmed||2021-09-20
 Ever confirmed|0   |1

--- Comment #1 from Patrick Palka  ---
Confirmed.

Harald Anlauf appointed Fortran Reviewer

[David Edelsohn via Gcc]

I am pleased to announce that the GCC Steering Committee has
appointed Harald Anlauf as a Fortran Reviewer.

Please join me in congratulating Harald on his new role.
Harald, please update your listing in the MAINTAINERS file.

Happy hacking!
David

Re: [PATCH] Factor out `find_a_program` helper around `find_a_file`

[Gerald Pfeifer]

On Sun, 19 Sep 2021, Jeff Law via Gcc-patches wrote:
> On 8/4/2021 12:21 PM, John Ericson wrote:
>> The helper is for `--print-prog-name` and similar things. Since all
>> executable finding goes through it, we can move the default overrides
>> into that path too. This also ensures that if some is looking for a
>> *non*-program that called `as`, `ld`, etc., weird things don't happen.
>> ---
>>   gcc/gcc.c | 59 ---
>>   1 file changed, 34 insertions(+), 25 deletions(-)
> Thanks.  I added a ChangeLog entry and pushed this to the trunk.

|commit 5fee8a0a9223d030c66d53c104fb0a431369248f
|Author: John Ericson 
|Date:   Sun Sep 19 11:08:32 2021 -0400
|
|[PATCH] Factor out `find_a_program` helper around `find_a_file`
|
|gcc/
|* gcc.c (find_a_program): New function, factored out of...
|(find_a_file): Here.
|(execute): Use find_a_program when looking for programs rather
|than find_a_file.

I'm afraid this broke x86_64-unknown-freebsd12*:

.../GCC-HEAD/gcc/gcc.c: In function 'char* find_a_program(const char*)':
/scratch/tmp/gerald/GCC-HEAD/gcc/gcc.c:3086:59: error: 'mode' was not declared 
in this scope; did you mean 'pmode'?
 3086 |   if (! strcmp (name, "as") && access (DEFAULT_ASSEMBLER, mode) == 0)
  |   ^~~~
  |   pmode
/scratch/tmp/gerald/GCC-HEAD/gcc/gcc.c:3091:56: error: 'mode' was not declared 
in this scope; did you mean 'pmode'?
 3091 |   if (! strcmp (name, "ld") && access (DEFAULT_LINKER, mode) == 0)
  |^~~~
  |pmode

Looking at the code in question I see

  static char*
  find_a_program (const char *name)
  {
/* Do not search if default matches query. */

  #ifdef DEFAULT_ASSEMBLER
if (! strcmp (name, "as") && access (DEFAULT_ASSEMBLER, mode) == 0)
  return xstrdup (DEFAULT_ASSEMBLER);
  #endif

where mode is not defined in that function.

Looks like the factoring out did not take the non-default case into
consideration?


I was just going to commit a fix I tested last night, when that patch 
simply "disappeared". Looks like Ian beat me to it with exactly the same 
patch. :-)

Gerald

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[Zack Weinberg via Gcc]

On Fri, Sep 17, 2021, at 9:36 PM, James Y Knight via Libc-alpha wrote:
> Glibc currently implements bcmp as an alias to memcmp -- which is valid,
> but provides more than just the boolean equality semantics. There was
> concern raised that modifying that might break existing binaries. However,
> this concern can be easily addressed in the same way glibc typically
> addresses such compatibility concerns: creating a new symbol-version for
> the new bcmp implementation, with the previous bcmp symbol-version
> remaining as a memcmp alias.

Not speaking for anyone but myself, but IMO this tactic has proven not to 
preserve _enough_ backward compatibility.  Old binaries keep working, but old 
code breaks when recompiled with new glibc.  It's especially troublesome to do 
this for a semantic change that manifests only at runtime; the break can go 
undetected for quite some time and then cause catastrophe when someone finally 
hits the relevant edge case.

zw

Re: [PATCH] x86-64: Remove HAVE_LD_PIE_COPYRELOC

[Fāng-ruì Sòng via Gcc-patches]

PING^5 https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570139.html

On Sat, Sep 4, 2021 at 12:11 PM Fāng-ruì Sòng  wrote:
>
> PING^4 https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570139.html
>
> One major design goal of PIE was to avoid copy relocations.
> The original patch for GCC 5 caused problems for many years.
>
> On Wed, Aug 18, 2021 at 11:54 PM Fāng-ruì Sòng  wrote:
>>
>> PING^3 https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570139.html
>>
>> On Fri, Jun 4, 2021 at 3:04 PM Fāng-ruì Sòng  wrote:
>> >
>> > PING^2 https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570139.html
>> >
>> > On Mon, May 24, 2021 at 9:43 AM Fāng-ruì Sòng  wrote:
>> > >
>> > > Ping https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570139.html
>> > >
>> > > On Tue, May 11, 2021 at 8:29 PM Fangrui Song  wrote:
>> > > >
>> > > > This was introduced in 2014-12 to use local binding for external 
>> > > > symbols
>> > > > for -fPIE. Now that we have H.J. Lu's GOTPCRELX for years which mostly
>> > > > nullify the benefit of HAVE_LD_PIE_COPYRELOC, HAVE_LD_PIE_COPYRELOC
>> > > > should retire now.
>> > > >
>> > > > One design goal of -fPIE was to avoid copy relocations.
>> > > > HAVE_LD_PIE_COPYRELOC has deviated from the goal.  With this change, 
>> > > > the
>> > > > -fPIE behavior of x86-64 will be closer to x86-32 and other targets.
>> > > >
>> > > > ---
>> > > >
>> > > > See https://gcc.gnu.org/legacy-ml/gcc/2019-05/msg00215.html for a list
>> > > > of fixed and unfixed (e.g. gold incompatibility with protected
>> > > > https://sourceware.org/bugzilla/show_bug.cgi?id=19823) issues.
>> > > >
>> > > > If you prefer a longer write-up, see
>> > > > https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected
>> > > > ---
>> > > >  gcc/config.in |  6 ---
>> > > >  gcc/config/i386/i386.c| 11 +---
>> > > >  gcc/configure | 52 ---
>> > > >  gcc/configure.ac  | 48 -
>> > > >  gcc/doc/sourcebuild.texi  |  3 --
>> > > >  .../gcc.target/i386/pie-copyrelocs-1.c| 14 -
>> > > >  .../gcc.target/i386/pie-copyrelocs-2.c| 14 -
>> > > >  .../gcc.target/i386/pie-copyrelocs-3.c| 14 -
>> > > >  .../gcc.target/i386/pie-copyrelocs-4.c| 17 --
>> > > >  gcc/testsuite/lib/target-supports.exp | 47 -
>> > > >  10 files changed, 2 insertions(+), 224 deletions(-)
>> > > >  delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-1.c
>> > > >  delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-2.c
>> > > >  delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-3.c
>> > > >  delete mode 100644 gcc/testsuite/gcc.target/i386/pie-copyrelocs-4.c
>> > > >
>> > > > diff --git a/gcc/config.in b/gcc/config.in
>> > > > index e54f59ce0c3..a65bf5d4176 100644
>> > > > --- a/gcc/config.in
>> > > > +++ b/gcc/config.in
>> > > > @@ -1659,12 +1659,6 @@
>> > > >  #endif
>> > > >
>> > > >
>> > > > -/* Define 0/1 if your linker supports -pie option with copy reloc. */
>> > > > -#ifndef USED_FOR_TARGET
>> > > > -#undef HAVE_LD_PIE_COPYRELOC
>> > > > -#endif
>> > > > -
>> > > > -
>> > > >  /* Define if your PowerPC linker has .gnu.attributes long double 
>> > > > support. */
>> > > >  #ifndef USED_FOR_TARGET
>> > > >  #undef HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE
>> > > > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> > > > index 915f89f571a..5ec3c6fd0c9 100644
>> > > > --- a/gcc/config/i386/i386.c
>> > > > +++ b/gcc/config/i386/i386.c
>> > > > @@ -10579,11 +10579,7 @@ legitimate_pic_address_disp_p (rtx disp)
>> > > > return true;
>> > > > }
>> > > >   else if (!SYMBOL_REF_FAR_ADDR_P (op0)
>> > > > -  && (SYMBOL_REF_LOCAL_P (op0)
>> > > > -  || (HAVE_LD_PIE_COPYRELOC
>> > > > -  && flag_pie
>> > > > -  && !SYMBOL_REF_WEAK (op0)
>> > > > -  && !SYMBOL_REF_FUNCTION_P (op0)))
>> > > > +  && SYMBOL_REF_LOCAL_P (op0)
>> > > >&& ix86_cmodel != CM_LARGE_PIC)
>> > > > return true;
>> > > >   break;
>> > > > @@ -22892,10 +22888,7 @@ ix86_atomic_assign_expand_fenv (tree *hold, 
>> > > > tree *clear, tree *update)
>> > > >  static bool
>> > > >  ix86_binds_local_p (const_tree exp)
>> > > >  {
>> > > > -  return default_binds_local_p_3 (exp, flag_shlib != 0, true, true,
>> > > > - (!flag_pic
>> > > > -  || (TARGET_64BIT
>> > > > -  && HAVE_LD_PIE_COPYRELOC != 
>> > > > 0)));
>> > > > +  return default_binds_local_p_3 (exp, flag_shlib != 0, true, true, 
>> > > > !flag_pic);
>> > > >  }
>> > > >  #endif
>> > > >
>> > > > diff --git a/gcc/configure b/gcc/configure
>> > > > index 

[Bug target/102411] arm/vfp18.c fails with -march=armv7e-m+fp for cortex-m4

[rearnsha at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102411

--- Comment #1 from Richard Earnshaw  ---
The AAPCS tests are executable tests, so rely on a number of features of the
support libraries (ie libraries compatible with the options used for the
compilation).  I don't think they should be adding any options to try and force
the test to compile.  So I think the dg-add-options is just wrong.

Re: [PATCH] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

[Jakub Jelinek via Gcc-patches]

On Mon, Sep 20, 2021 at 01:06:58PM -0400, Marek Polacek via Gcc-patches wrote:

Not a review, just a few nits:

I think it would be useful to clarify that -Wno-attributes=list doesn't
actually imply -Wno-attributes

> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -88,6 +88,9 @@ void *flag_instrument_functions_exclude_functions
>  Variable
>  void *flag_instrument_functions_exclude_files
>  
> +Variable
> +void *flag_ignored_attributes
> +
>  ; Generic structs (e.g. templates not explicitly specialized)
>  ; may not have a compilation unit associated with them, and so
>  ; may need to be treated differently from ordinary structs.
> @@ -546,6 +549,10 @@ Wattributes
>  Common Var(warn_attributes) Init(1) Warning
>  Warn about inappropriate attribute usage.
>  
> +Wattributes=
> +Common Joined
> +Do not warn about specified attributes.
> +

So, wouldn't be this better specified as
Wno-attributes=
Common Joined RejectNegative
(not sure if RejectNegative is actually needed for an option
starting with Wno- )?

> +/* { dg-additional-options "-std=c++11" { target c++ } } */
> +/* { dg-additional-options "-Wno-attributes=company::,yoyodyne::attr" } */
> +/* { dg-additional-options "-Wno-attributes=c1::attr,c1::attr,c1::__attr__" 
> } */
> +/* { dg-additional-options "-Wno-attributes=clang" } */
> +/* { dg-additional-options "-Wno-attributes=c2::,c2::attr" } */
> +/* { dg-additional-options "-Wno-attributes=c3::attr,c3::" } */
> +/* { dg-additional-options "-Wno-attributes=x::," } */

Should the above be accepted (I mean trailing , ?)  What does that mean?

> +/* { dg-additional-options "-Wno-attributes=yoyodyne::attr_new" } */
> +/* { dg-additional-options "-Wno-attributes=c4::__attr__" } */

When writing __attr__, does that imply we won't warn about both
c4::attr and c4::__attr__ (and __c4__::attr and __c4__::__attr__) like
it would when writing -Wno-attributes=c4::attr ?

Jakub

[Bug ipa/102388] [12 Regression] ICE in duplicate, at ipa-prop.c:4436 since r12-2523-g13586172d0b70c9d

[jamborm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102388

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #1 from Martin Jambor  ---
Mine, looks like a lot of fun.

Re: [PATCH] Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*

[Jeff Law via Gcc-patches]

On 9/20/2021 10:46 AM, Richard Biener wrote:

On Mon, 20 Sep 2021, Richard Biener wrote:


On Mon, 20 Sep 2021, Jeff Law wrote:



On 9/20/2021 1:00 AM, Richard Biener wrote:

This obsoletes the 32bit hppa-hpux configurations which only support
STABS as debuginfo format.

As discussed, I'm going to push this (and a changes.html entry) when
it was included in a bootstrap/regtest cycle.

2021-09-20  Richard Biener  

gcc/
  * config.gcc: Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*.

contrib/
  * config-list.mk: --enable-obsolete for hppa2.0-hpux10.1 and
  hppa2.0-hpux11.9.

Is this marking hppa2.0w-hp-hpux11 as obsolete?  That platform is using ELF &
DWARF.

If so then that's by mistake - I had the impression that all 32bit
hpux pa targets are STABS only, but that's from trying to decipher
config.gcc and the comments from you and David ... maybe the
matching pattern needs to be "split"?

Btw, I don't see any elfos.h in the hppa[12]*-*-hpux11* case in config.gcc
and it contains a warning that the target doesn't support DWARF.  But yes,
that pattern matches hppa2.0-hpux11.9 and the hppa*64*-*-hpux11* pattern
doesn't - there's hppa64-hpux11.0 in config-list.mk that does though.
Nuts, I think I steered you wrong.  I forgot that while HP used 
"hppa2.0w" to denote their 64 bit ELF platform, we used "hppa64" for the 
target name.


jeff

[Bug c++/101940] Implement -Wno-attributes=vendor::attr

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101940

--- Comment #5 from Marek Polacek  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579858.html

[PATCH] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

[Marek Polacek via Gcc-patches]

It is desirable for -Wattributes to warn about e.g.

[[deprecate]] void g(); // typo, should warn

However, -Wattributes also warns about vendor-specific attributes
(that's because lookup_scoped_attribute_spec -> find_attribute_namespace
finds nothing), which, with -Werror, causes grief.  We don't want the
-Wattributes warning for

[[company::attr]] void f();

GCC warns because it doesn't know the "company" namespace; it only knows
the "gnu" and "omp" namespaces.  We could entirely disable warning about
attributes in unknown scopes but then the compiler would also miss typos
like

  [[company::attrx]] void f();

or

  [[gmu::warn_used_result]] int write();

so that is not a viable solution.  A workaround is to use a #pragma:

  #pragma GCC diagnostic push
  #pragma GCC diagnostic ignored "-Wattributes"
  [[company::attr]] void f() {}
  #pragma GCC diagnostic pop

but that's a mouthful and awkward to use and could also hide typos.  In
fact, any macro-based solution doesn't seem like a way forward.

This patch implements -Wno-attributes=, which takes these arguments:

company::attr
company::
clang

The last one is a special option to ignore clang-only attributes; in
this patch it is accepted but currently has no effect.

This option should go well with using @file: the user could have a file
containing
-Wno-attributes=vendor::attr1,vendor::attr2
and then invoke gcc with '@attrs' or similar.

I've also added a new pragma which has the same effect:

The pragma along with the new option should help with various static
analysis tools.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

PR c++/101940

gcc/ChangeLog:

* attribs.c (struct scoped_attributes): Add a bool member.
(lookup_scoped_attribute_spec): Forward declare.
(register_scoped_attributes): New bool parameter, defaulted to
false.  Use it.
(handle_ignored_attributes_option): New function.
(free_attr_data): New function.
(init_attributes): Call handle_ignored_attributes_option.
(attr_namespace_ignored_p): New function.
(decl_attributes): Check attr_namespace_ignored_p before
warning.
* attribs.h (free_attr_data): Declare.
(register_scoped_attributes): Adjust declaration.
(handle_ignored_attributes_option): Declare.
* common.opt (Wattributes=): New option with a variable.
* doc/extend.texi: Document #pragma GCC diagnostic ignored_attributes.
* doc/invoke.texi: Document -Wno-attributes=.
* opts.c (common_handle_option) : Handle.
* plugin.h (register_scoped_attributes): Adjust declaration.

gcc/c-family/ChangeLog:

* c-pragma.c (handle_pragma_diagnostic): Handle #pragma GCC diagnostic
ignored_attributes.

gcc/c/ChangeLog:

* c-decl.c (c_parse_final_cleanups): Call free_attr_data.

gcc/cp/ChangeLog:

* decl2.c (c_parse_final_cleanups): Call free_attr_data.

gcc/testsuite/ChangeLog:

* c-c++-common/Wno-attributes-1.c: New test.
* c-c++-common/Wno-attributes-2.c: New test.
---
 gcc/attribs.c | 122 +-
 gcc/attribs.h |   5 +-
 gcc/c-family/c-pragma.c   |  22 +++-
 gcc/c/c-decl.c|   2 +
 gcc/common.opt|   9 +-
 gcc/cp/decl2.c|   2 +
 gcc/doc/extend.texi   |  19 +++
 gcc/doc/invoke.texi   |  18 +++
 gcc/opts.c|  14 ++
 gcc/plugin.h  |   4 +-
 gcc/testsuite/c-c++-common/Wno-attributes-1.c |  40 ++
 gcc/testsuite/c-c++-common/Wno-attributes-2.c |  41 ++
 12 files changed, 289 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/Wno-attributes-1.c
 create mode 100644 gcc/testsuite/c-c++-common/Wno-attributes-2.c

diff --git a/gcc/attribs.c b/gcc/attribs.c
index 83fafc98b7d..c85f3aedc4d 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -87,6 +87,8 @@ struct scoped_attributes
   const char *ns;
   vec attributes;
   hash_table *attribute_hash;
+  /* True if we should not warn about unknown attributes in this NS.  */
+  bool ignored_p;
 };
 
 /* The table of scope attributes.  */
@@ -95,6 +97,8 @@ static vec attributes_table;
 static scoped_attributes* find_attribute_namespace (const char*);
 static void register_scoped_attribute (const struct attribute_spec *,
   scoped_attributes *);
+static const struct attribute_spec *lookup_scoped_attribute_spec (const_tree,
+ const_tree);
 
 static bool attributes_initialized = false;
 
@@ -121,12 +125,14 @@ extract_attribute_substring (struct substring *str)
 
 /* Insert an array of attributes ATTRIBUTES into a namespace.  This
array must be NULL terminated.  NS is the name of 

PING^3 [PATCH] x86: Update memcpy/memset inline strategies for -mtune=generic

[H.J. Lu via Gcc-patches]

On Mon, Sep 13, 2021 at 6:38 AM H.J. Lu  wrote:
>
> On Tue, Sep 7, 2021 at 8:01 PM H.J. Lu  wrote:
> >
> > On Sun, Aug 22, 2021 at 8:28 AM H.J. Lu  wrote:
> > >
> > > On Tue, Mar 23, 2021 at 09:19:38AM +0100, Richard Biener wrote:
> > > > On Tue, Mar 23, 2021 at 3:41 AM Hongyu Wang  
> > > > wrote:
> > > > >
> > > > > > Hongyue, please collect code size differences on SPEC CPU 2017 and
> > > > > > eembc.
> > > > >
> > > > > Here is code size difference for this patch
> > > >
> > > > Thanks, nothing too bad although slightly larger impacts than 
> > > > envisioned.
> > > >
> > >
> > > PING.
> > >
> > > OK for master branch?
> > >
> > > Thanks.
> > >
> > > H.J.
> > >  ---
> > > Simplify memcpy and memset inline strategies to avoid branches for
> > > -mtune=generic:
> > >
> > > 1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
> > >load and store for up to 16 * 16 (256) bytes when the data size is
> > >fixed and known.
> > > 2. Inline only if data size is known to be <= 256.
> > >a. Use "rep movsb/stosb" with simple code sequence if the data size
> > >   is a constant.
> > >b. Use loop if data size is not a constant.
> > > 3. Use memcpy/memset libray function if data size is unknown or > 256.
> > >
> >
> > PING:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577889.html
> >
>
> PING.  This should fix:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294
>

PING.

-- 
H.J.

Re: [PATCH] Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*

[Richard Biener via Gcc-patches]

On Mon, 20 Sep 2021, Richard Biener wrote:

> On Mon, 20 Sep 2021, Jeff Law wrote:
> 
> > 
> > 
> > On 9/20/2021 1:00 AM, Richard Biener wrote:
> > > This obsoletes the 32bit hppa-hpux configurations which only support
> > > STABS as debuginfo format.
> > >
> > > As discussed, I'm going to push this (and a changes.html entry) when
> > > it was included in a bootstrap/regtest cycle.
> > >
> > > 2021-09-20  Richard Biener  
> > >
> > > gcc/
> > >  * config.gcc: Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*.
> > >
> > > contrib/
> > >  * config-list.mk: --enable-obsolete for hppa2.0-hpux10.1 and
> > >  hppa2.0-hpux11.9.
> > Is this marking hppa2.0w-hp-hpux11 as obsolete?  That platform is using ELF 
> > &
> > DWARF.
> 
> If so then that's by mistake - I had the impression that all 32bit
> hpux pa targets are STABS only, but that's from trying to decipher
> config.gcc and the comments from you and David ... maybe the
> matching pattern needs to be "split"?

Btw, I don't see any elfos.h in the hppa[12]*-*-hpux11* case in config.gcc
and it contains a warning that the target doesn't support DWARF.  But yes,
that pattern matches hppa2.0-hpux11.9 and the hppa*64*-*-hpux11* pattern
doesn't - there's hppa64-hpux11.0 in config-list.mk that does though.

Richard.

> Can you maybe take care of any adjustments necessary?  I've also
> edited changes.html already.
> 
> Thanks,
> Richard.
> 
> > jeff
> > 
> > 
> > 
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

[PATCH] c++: consider built-in operator candidates first

[Patrick Palka via Gcc-patches]

During operator overload resolution, we currently consider non-member
candidates before built-in candidates.  This didn't make a difference
before r12-3346, but after this change add_candidates will avoid
computing excess argument conversions if we've already seen a strictly
viable candidate, so it's better to consider built-in candidates first.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

gcc/cp/ChangeLog:

* call.c (add_operator_candidates): Consider built-in operator
candidates before considering non-member candidates.

gcc/testsuite/ChangeLog:

* g++.dg/template/conv17.C: Extend test.
---
 gcc/cp/call.c  | 13 +++--
 gcc/testsuite/g++.dg/template/conv17.C |  7 +++
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c5601d96ab8..c0da083758f 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6321,7 +6321,6 @@ add_operator_candidates (z_candidate **candidates,
 vec *arglist,
 int flags, tsubst_flags_t complain)
 {
-  z_candidate *start_candidates = *candidates;
   bool ismodop = code2 != ERROR_MARK;
   tree fnname = ovl_op_identifier (ismodop, ismodop ? code2 : code);
 
@@ -6333,6 +6332,12 @@ add_operator_candidates (z_candidate **candidates,
   if (rewritten && code != EQ_EXPR && code != SPACESHIP_EXPR)
 flags &= ~LOOKUP_REWRITTEN;
 
+  /* Add built-in candidates to the candidate set.  The standard says to
+ rewrite built-in candidates, too, but there's no point.  */
+  if (!rewritten)
+add_builtin_candidates (candidates, code, code2, fnname, arglist,
+   flags, complain);
+
   bool memonly = false;
   switch (code)
 {
@@ -6352,6 +6357,7 @@ add_operator_candidates (z_candidate **candidates,
 
   /* Add namespace-scope operators to the list of functions to
  consider.  */
+  z_candidate *start_candidates = *candidates;
   if (!memonly)
 {
   tree fns = lookup_name (fnname, LOOK_where::BLOCK_NAMESPACE);
@@ -6423,11 +6429,6 @@ add_operator_candidates (z_candidate **candidates,
 
   if (!rewritten)
 {
-  /* The standard says to rewrite built-in candidates, too,
-but there's no point.  */
-  add_builtin_candidates (candidates, code, code2, fnname, arglist,
- flags, complain);
-
   /* Maybe add C++20 rewritten comparison candidates.  */
   tree_code rewrite_code = ERROR_MARK;
   if (cxx_dialect >= cxx20
diff --git a/gcc/testsuite/g++.dg/template/conv17.C 
b/gcc/testsuite/g++.dg/template/conv17.C
index f0f10f2ef4f..87ecefb8de3 100644
--- a/gcc/testsuite/g++.dg/template/conv17.C
+++ b/gcc/testsuite/g++.dg/template/conv17.C
@@ -61,3 +61,10 @@ concept E = requires { T().h(nullptr); };
 
 static_assert(!E);
 #endif
+
+// Verify that the strictly viable built-in operator+ candidate precludes
+// us from computing all argument conversions for the below non-strictly
+// viable non-member candidate.
+enum N { n };
+int operator+(N&, B);
+int f = n + 42;
-- 
2.33.0.363.g4c719308ce

[Bug c++/102412] New: Template argument deduction fails when using concept as defaulted non-type template parameter

[joeloser93 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102412

Bug ID: 102412
   Summary: Template argument deduction fails when using concept
as defaulted non-type template parameter
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joeloser93 at gmail dot com
  Target Milestone: ---

When using a defaulted non-type template parameter whose value is from a
concept, GCC is unable to deduce the template correctly when calling the
function template. Clang accepts this code and it should be valid. 

```
#include 

template
concept different_from = not std::is_same_v;

template>
void f() {}

template>
void g() {}

int main() {
f(); // fails to compile
g(); // compiles
}

```

See it live at https://godbolt.org/z/n1zrzGPoq

Re: [PATCH] Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*

[Richard Biener via Gcc-patches]

On Mon, 20 Sep 2021, Jeff Law wrote:

> 
> 
> On 9/20/2021 1:00 AM, Richard Biener wrote:
> > This obsoletes the 32bit hppa-hpux configurations which only support
> > STABS as debuginfo format.
> >
> > As discussed, I'm going to push this (and a changes.html entry) when
> > it was included in a bootstrap/regtest cycle.
> >
> > 2021-09-20  Richard Biener  
> >
> > gcc/
> >  * config.gcc: Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*.
> >
> > contrib/
> >  * config-list.mk: --enable-obsolete for hppa2.0-hpux10.1 and
> >  hppa2.0-hpux11.9.
> Is this marking hppa2.0w-hp-hpux11 as obsolete?  That platform is using ELF &
> DWARF.

If so then that's by mistake - I had the impression that all 32bit
hpux pa targets are STABS only, but that's from trying to decipher
config.gcc and the comments from you and David ... maybe the
matching pattern needs to be "split"?

Can you maybe take care of any adjustments necessary?  I've also
edited changes.html already.

Thanks,
Richard.

> jeff
> 
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

[Bug target/102411] New: arm/vfp18.c fails with -march=armv7e-m+fp for cortex-m4

[clyon at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102411

Bug ID: 102411
   Summary: arm/vfp18.c fails with -march=armv7e-m+fp for
cortex-m4
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

When running the testsuite with -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp and
simulating for cortex-m4, I noticed that gcc.target/arm/vfp18.c fails at
execution.

The testcase contains:
void myfunc(__fp16, float, double, float, __fp16, int) ;

int main()
{
  myfunc(1.0f, 2.0f, 4.0, 2.0f, 1.0f, 3);

}

The testcase is compiled with:
-mthumb -mfloat-abi=hard -march=armv7e-m+fp -mfpu=vfpv4 -mfp16-format=ieee

For main we generate:
push{r7, lr}@ 27[c=8 l=2]  *push_multi
add r7, sp, #0  @ 28[c=4 l=4]  *arm_addsi3/4
movsr0, #3  @ 5 [c=4 l=2]  *thumb2_movsi_shortim
movwr3, #15360  @ 23[c=4 l=8]  *movhf_vfp/6
vmovs5, r3  @ 6 [c=4 l=4]  *movhf_vfp/4
vmov.f32s4, #2.0e+0 @ 7 [c=4 l=4]  *thumb2_movsf_vfp/2
vmov.f64d1, #4.0e+0 @ 8 [c=4 l=4]  *thumb2_movdf_vfp/2
vmov.f32s1, #2.0e+0 @ 9 [c=4 l=4]  *thumb2_movsf_vfp/2
vmovs0, r3  @ 10[c=4 l=4]  *movhf_vfp/4
bl  myfunc  @ 11[c=8 l=4]  *call_symbol
movsr3, #0  @ 12[c=4 l=2]  *thumb2_movsi_shortim
mov r0, r3  @ 19[c=4 l=2]  *thumb2_movsi_vfp/0
pop {r7, pc}@ 31[c=8 l=2] 
*pop_multiple_with_writeback_and_return

The problem is the vmov.f64 instruction which is not supported by cortex-m4
since it has a single-precision-only FPU.

Running under QEMU with -cpu cortex-m7 passes, as expected.

The problem comes from -mfpu=vfpv4, which is added by arm_fp16_hw (indirectly
from check_effective_target_arm_fp16_ok_nocache)

Indeed arm-cpus.in says:
begin fpu vfpv4
  isa VFPv4 FP_D32
end fpu vfpv4

so it enables double-precision support.


Looks like a testism, since we effectively override -march=armv7e-m+fp with
-mfpu=vfpv4, but maybe a warning would be helpful?
And something to disable the test or make it pass.

Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

[Qing Zhao via Gcc-patches]

> On Sep 20, 2021, at 10:59 AM, Richard Earnshaw 
>  wrote:
> 
> 
> 
> On 20/09/2021 16:51, Qing Zhao via Gcc-patches wrote:
>>> On Sep 20, 2021, at 9:36 AM, Richard Earnshaw 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 20/09/2021 14:55, Qing Zhao wrote:
> On Sep 20, 2021, at 8:18 AM, Richard Earnshaw 
>  wrote:
> 
> 
> 
> On 20/09/2021 13:47, Qing Zhao wrote:
>>> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote:
 Hi,
 There are much less issues with aarch64/auto-init-* test cases.
 Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till 
 ‘armv8.6-a’, ‘armv8-r’) do not change the pattern match.
 Only
 1. -mabi=ilp32/lp64 impact two of the testing cases “auto-init-2.c” 
 and “auto-init-padding-5.c”.
 2. -fstack-clash-protection impact two of the testing cases 
 “auto-init-1.c” and “auto-init-7.c”.
 Naturally the patch for this set is:
 A. Adjust the patterns for ilp32 or lp64 in “auto-init-2.c” and 
 “auto-init-padding-5.c”;
 B. Add -fno-stack-protector to “auto-init-1.c” and “auto-init-7.c”
 The above A fixed issue 1, however, the above B did not fix issue 2.
 If I fixed “auto-init-1.c” as:
 diff --git a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c 
 b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
 index 0fa4708..a38d91b 100644
 --- a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
 +++ b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
 @@ -1,6 +1,6 @@
  /* Verify zero initialization for integer and pointer type automatic 
 variables.  */
  /* { dg-do compile } */
 -/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand" } */
 +/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand 
 -fno-stack-protector" } */
#ifndef __cplusplus
  # define bool _Bool
 So, I took a look at the log file of the testing, and found that, If I 
 tested it as:
  make check-gcc 
 RUNTESTFLAGS='--target_board=unix\{-mabi=lp64/-fstack-clash-protection/-fstack-protector-all\}
  aarch64.exp=auto-init*’
 In the log file, I got:
 /home/qinzhao/Work/GCC/build_git/gcc/xgcc 
 -B/home/qinzhao/Work/GCC/build_git/gcc/ 
 /home/qinzhao/Work/GCC/latest_gcc_git/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
   -fdiagnostics-plain-output  -ftrivial-auto-var-init=zero 
 -fdump-rtl-expand -fno-stack-protector -ffat-lto-objects -S  
 -mabi=lp64 -fstack-clash-protection -fstack-protector-all  -o 
 auto-init-1.s
 From it, we can see, that the options that were passed through 
 RUNTESTFLAGS “mabi-lp64 -fstack-clash-protection 
 -fstack-protector-all” were appended AFTER the options inside the 
 testing case through “dg-options”. As a result, the option 
 “-fno-stack-protector” did not have any impact at all.
 What’s the expected behavior for the order of these options? Should 
 options through RUNTESTFLAGS be appended BEFORE or AFTER the options 
 through testing cases?
 For X86, the options through RUNTESTFLAGS are added BEFORE the options 
 through testing cases. Therefore adding “-fno-stack-protector” has the 
 expected result.
>>> 
>>> Can you check that you are using the same version of dejagnu on both 
>>> platforms?
>> Stupid question:  how to check the version of it?
> 
> $ runtest --version
 Thanks.
 On aarch64:
 qinzhao@gcc116:~/Work/GCC/build_git$ runtest --version
 Expect version is  5.45
 Tcl version is 8.6
 Framework version is   1.5
>>> 
>>> Ok, so this is dejagnu 1.5 (older versions of dejagnu reported the 
>>> 'framework version') ...
>>> 
 On X86:
 [opc@qinzhao-ol8u3-x86 gcc]$ runtest --version
 WARNING: Couldn't find the global config file.
 DejaGnu version1.6.1
 Expect version 5.45.4
 Tcl version8.6
>>> 
>>> While this is dejagnu 1.6.1
>>> 
>>> IIRC there were some changes to the way various options were combined at 
>>> one point and I suspect this may be the source of your problem.  Can you 
>>> update your dejagnu on your aarch64 system to be the same as that on x86?
>> The aarch64 machine I used is a GCC farm machine, looks like it has an older 
>> version of dejagnu. I don’t have permission to update it myself.
>> I will use another aarch64 machine to test this to see whether a higher 
>> version of dejagnu can resolve the issue or not.
> 
> You could probably try installing a local copy of dejagnu in, for example, 
> ~/tools and then adding that to your path before the system version.
Will try this too.
thanks.

Qing
> 
> R.
> 
>> Thanks a lot for your help.
>> 

Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

[Richard Earnshaw via Gcc-patches]

On 20/09/2021 16:51, Qing Zhao via Gcc-patches wrote:




On Sep 20, 2021, at 9:36 AM, Richard Earnshaw  
wrote:



On 20/09/2021 14:55, Qing Zhao wrote:

On Sep 20, 2021, at 8:18 AM, Richard Earnshaw  
wrote:



On 20/09/2021 13:47, Qing Zhao wrote:

On Sep 20, 2021, at 5:43 AM, Richard Earnshaw  
wrote:



On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote:

Hi,
There are much less issues with aarch64/auto-init-* test cases.
Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till ‘armv8.6-a’, 
‘armv8-r’) do not change the pattern match.
Only
1. -mabi=ilp32/lp64 impact two of the testing cases “auto-init-2.c” and 
“auto-init-padding-5.c”.
2. -fstack-clash-protection impact two of the testing cases “auto-init-1.c” and 
“auto-init-7.c”.
Naturally the patch for this set is:
A. Adjust the patterns for ilp32 or lp64 in “auto-init-2.c” and 
“auto-init-padding-5.c”;
B. Add -fno-stack-protector to “auto-init-1.c” and “auto-init-7.c”
The above A fixed issue 1, however, the above B did not fix issue 2.
If I fixed “auto-init-1.c” as:
diff --git a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c 
b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
index 0fa4708..a38d91b 100644
--- a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
@@ -1,6 +1,6 @@
  /* Verify zero initialization for integer and pointer type automatic 
variables.  */
  /* { dg-do compile } */
-/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand" } */
+/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand 
-fno-stack-protector" } */
#ifndef __cplusplus
  # define bool _Bool
So, I took a look at the log file of the testing, and found that, If I tested 
it as:
  make check-gcc 
RUNTESTFLAGS='--target_board=unix\{-mabi=lp64/-fstack-clash-protection/-fstack-protector-all\}
 aarch64.exp=auto-init*’
In the log file, I got:
/home/qinzhao/Work/GCC/build_git/gcc/xgcc 
-B/home/qinzhao/Work/GCC/build_git/gcc/ 
/home/qinzhao/Work/GCC/latest_gcc_git/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
  -fdiagnostics-plain-output  -ftrivial-auto-var-init=zero -fdump-rtl-expand 
-fno-stack-protector -ffat-lto-objects -S  -mabi=lp64 -fstack-clash-protection 
-fstack-protector-all  -o auto-init-1.s
 From it, we can see, that the options that were passed through RUNTESTFLAGS 
“mabi-lp64 -fstack-clash-protection -fstack-protector-all” were appended AFTER 
the options inside the testing case through “dg-options”. As a result, the 
option “-fno-stack-protector” did not have any impact at all.
What’s the expected behavior for the order of these options? Should options 
through RUNTESTFLAGS be appended BEFORE or AFTER the options through testing 
cases?
For X86, the options through RUNTESTFLAGS are added BEFORE the options through 
testing cases. Therefore adding “-fno-stack-protector” has the expected result.


Can you check that you are using the same version of dejagnu on both platforms?

Stupid question:  how to check the version of it?


$ runtest --version

Thanks.
On aarch64:
qinzhao@gcc116:~/Work/GCC/build_git$ runtest --version
Expect version is   5.45
Tcl version is  8.6
Framework version is1.5


Ok, so this is dejagnu 1.5 (older versions of dejagnu reported the 'framework 
version') ...


On X86:
[opc@qinzhao-ol8u3-x86 gcc]$ runtest --version
WARNING: Couldn't find the global config file.
DejaGnu version 1.6.1
Expect version  5.45.4
Tcl version 8.6


While this is dejagnu 1.6.1

IIRC there were some changes to the way various options were combined at one 
point and I suspect this may be the source of your problem.  Can you update 
your dejagnu on your aarch64 system to be the same as that on x86?


The aarch64 machine I used is a GCC farm machine, looks like it has an older 
version of dejagnu. I don’t have permission to update it myself.

I will use another aarch64 machine to test this to see whether a higher version 
of dejagnu can resolve the issue or not.


You could probably try installing a local copy of dejagnu in, for 
example, ~/tools and then adding that to your path before the system 
version.


R.



Thanks a lot for your help.

Qing


R.


So, is there anything wrong with the installation of runtest on X86?
Qing


R.


Qing


R.


Is this a bug in aarch64 testing suite?
Thanks.
Qing

Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

[Qing Zhao via Gcc-patches]

> On Sep 20, 2021, at 9:36 AM, Richard Earnshaw  
> wrote:
> 
> 
> 
> On 20/09/2021 14:55, Qing Zhao wrote:
>>> On Sep 20, 2021, at 8:18 AM, Richard Earnshaw 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 20/09/2021 13:47, Qing Zhao wrote:
> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw 
>  wrote:
> 
> 
> 
> On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote:
>> Hi,
>> There are much less issues with aarch64/auto-init-* test cases.
>> Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till ‘armv8.6-a’, 
>> ‘armv8-r’) do not change the pattern match.
>> Only
>> 1. -mabi=ilp32/lp64 impact two of the testing cases “auto-init-2.c” and 
>> “auto-init-padding-5.c”.
>> 2. -fstack-clash-protection impact two of the testing cases 
>> “auto-init-1.c” and “auto-init-7.c”.
>> Naturally the patch for this set is:
>> A. Adjust the patterns for ilp32 or lp64 in “auto-init-2.c” and 
>> “auto-init-padding-5.c”;
>> B. Add -fno-stack-protector to “auto-init-1.c” and “auto-init-7.c”
>> The above A fixed issue 1, however, the above B did not fix issue 2.
>> If I fixed “auto-init-1.c” as:
>> diff --git a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c 
>> b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>> index 0fa4708..a38d91b 100644
>> --- a/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>> +++ b/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>> @@ -1,6 +1,6 @@
>>  /* Verify zero initialization for integer and pointer type automatic 
>> variables.  */
>>  /* { dg-do compile } */
>> -/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand" } */
>> +/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand 
>> -fno-stack-protector" } */
>>#ifndef __cplusplus
>>  # define bool _Bool
>> So, I took a look at the log file of the testing, and found that, If I 
>> tested it as:
>>  make check-gcc 
>> RUNTESTFLAGS='--target_board=unix\{-mabi=lp64/-fstack-clash-protection/-fstack-protector-all\}
>>  aarch64.exp=auto-init*’
>> In the log file, I got:
>> /home/qinzhao/Work/GCC/build_git/gcc/xgcc 
>> -B/home/qinzhao/Work/GCC/build_git/gcc/ 
>> /home/qinzhao/Work/GCC/latest_gcc_git/gcc/testsuite/gcc.target/aarch64/auto-init-1.c
>>   -fdiagnostics-plain-output  -ftrivial-auto-var-init=zero 
>> -fdump-rtl-expand -fno-stack-protector -ffat-lto-objects -S  -mabi=lp64 
>> -fstack-clash-protection -fstack-protector-all  -o auto-init-1.s
>> From it, we can see, that the options that were passed through 
>> RUNTESTFLAGS “mabi-lp64 -fstack-clash-protection -fstack-protector-all” 
>> were appended AFTER the options inside the testing case through 
>> “dg-options”. As a result, the option “-fno-stack-protector” did not 
>> have any impact at all.
>> What’s the expected behavior for the order of these options? Should 
>> options through RUNTESTFLAGS be appended BEFORE or AFTER the options 
>> through testing cases?
>> For X86, the options through RUNTESTFLAGS are added BEFORE the options 
>> through testing cases. Therefore adding “-fno-stack-protector” has the 
>> expected result.
> 
> Can you check that you are using the same version of dejagnu on both 
> platforms?
 Stupid question:  how to check the version of it?
>>> 
>>> $ runtest --version
>> Thanks.
>> On aarch64:
>> qinzhao@gcc116:~/Work/GCC/build_git$ runtest --version
>> Expect version is5.45
>> Tcl version is   8.6
>> Framework version is 1.5
> 
> Ok, so this is dejagnu 1.5 (older versions of dejagnu reported the 'framework 
> version') ...
> 
>> On X86:
>> [opc@qinzhao-ol8u3-x86 gcc]$ runtest --version
>> WARNING: Couldn't find the global config file.
>> DejaGnu version  1.6.1
>> Expect version   5.45.4
>> Tcl version  8.6
> 
> While this is dejagnu 1.6.1
> 
> IIRC there were some changes to the way various options were combined at one 
> point and I suspect this may be the source of your problem.  Can you update 
> your dejagnu on your aarch64 system to be the same as that on x86?

The aarch64 machine I used is a GCC farm machine, looks like it has an older 
version of dejagnu. I don’t have permission to update it myself.

I will use another aarch64 machine to test this to see whether a higher version 
of dejagnu can resolve the issue or not.

Thanks a lot for your help.

Qing
> 
> R.
> 
>> So, is there anything wrong with the installation of runtest on X86?
>> Qing
>>> 
>>> R.
>>> 
 Qing
> 
> R.
> 
>> Is this a bug in aarch64 testing suite?
>> Thanks.
>> Qing

Re: [PATCH] c: [PR32122] Require pointer types for computed gotos

[Jeff Law via Gcc-patches]

On 9/19/2021 10:14 PM, apinski--- via Gcc-patches wrote:

From: Andrew Pinski 

So GCC has always accepted non-pointer types in computed gotos but
that was wrong based on the documentation:
Any expression of type void * is allowed.

So this fixes the problem by requiring the type to
be a pointer type.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR c/32122

gcc/c/ChangeLog:

* c-parser.c (c_parser_statement_after_labels): Pass
the c_expr instead of the tree to c_finish_goto_ptr.
* c-typeck.c (c_finish_goto_ptr): Change the second
argument type to c_expr.
* c-tree.h (c_finish_goto_ptr): Likewise.
Error out if the expression was not of a pointer type.

gcc/testsuite/ChangeLog:

* gcc.dg/comp-goto-5.c: New test.
* gcc.dg/comp-goto-6.c: New test.

OK
jeff

[PATCH] x86: Clean up gcc.target/i386/auto-init-* tests

[H.J. Lu via Gcc-patches]

On Fri, Sep 17, 2021 at 10:32 AM Qing Zhao via Gcc-patches
 wrote:
>
>
>
> > On Sep 17, 2021, at 11:59 AM, Jakub Jelinek  wrote:
> >
> > On Fri, Sep 17, 2021 at 04:55:22PM +, Qing Zhao wrote:
> >> This is the patch to fix gcc.target/i386/auto-init-* tests.
> >>
> >> I have tested the change at X86_64-linux with
> >>
> >> make check-gcc 
> >> RUNTESTFLAGS='--target_board=unix\{-m64,-m64/-march=skylake-avx512,-m64/-fstack-protector-all,-m64/-fstack-clash-protection,-m32/-mno-sse,-m32/-mtune=bonnell,-m32/-march=bonnell,-m32/-fstack-protector-all/-fstack-clash-protection\}
> >>  i386.exp=auto-init*’
> >>
> >> make check-gcc 
> >> RUNTESTFLAGS='--target_board=unix\{-m64,-m64/-march=skylake-avx512/-fPIC,-m64/-fstack-protector-all/-fPIC,-m64/-fstack-clash-protection/-fPIC,-m32/-mno-sse/-fPIC,-m32/-mtune=bonnell/-fPIC,-m32/-march=bonnell/-fPIC,-m32/-fstack-protector-all/-fstack-clash-protection/-fPIC\}
> >>  i386.exp=auto-init*’
> >>
> >> Everything works fine.
> >>
> >> Okay for commit?
> >
> > LGTM.
>
> Thank you.
>
> I will commit the change soon.
>
> For the aarch64 tests, do you have a suggestion on what the option 
> combination I should test?
>

Here is the followup patch to clean up these tests:

1. Replace ia32 with { ! lp64 } to enable ILP32 tests for -mx32.
2. Replace lp64 with { ! ia32 } to enable x86-64 ISA tests for -mx32.
3. For auto-init-3.c, add -msse and -mfpmath=387 for ia32.

Any comments?

-- 
H.J.
From 79831005e6d63e17d077d3c94b6f3c1e097c3da8 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Mon, 20 Sep 2021 07:48:05 -0700
Subject: [PATCH] x86: Clean up gcc.target/i386/auto-init-* tests

1. Replace ia32 with { ! lp64 } to enable ILP32 tests for -mx32.
2. Replace lp64 with { ! ia32 } to enable x86-64 ISA tests for -mx32.
3. For auto-init-3.c, add -msse and -mfpmath=387 for ia32.

	* gcc.target/i386/auto-init-2.c: Replace ia32 with { ! lp64 }.
	* gcc.target/i386/auto-init-3.c (dg-options): Add -msse.
	(dg-additional-options): Add -mfpmath=387 for ia32.
	Replace lp64 with { ! ia32 }. Add a space after ia32.
	* gcc.target/i386/auto-init-4.c: Replace lp64 with { ! ia32 }.
	* gcc.target/i386/auto-init-5.c: Likewise.
	* gcc.target/i386/auto-init-padding-3.c: Likewise.
	* gcc.target/i386/auto-init-padding-7.c: Likewise.
	* gcc.target/i386/auto-init-padding-8.c: Likewise.
	* gcc.target/i386/auto-init-padding-9.c: Likewise.
---
 gcc/testsuite/gcc.target/i386/auto-init-2.c | 5 ++---
 gcc/testsuite/gcc.target/i386/auto-init-3.c | 7 ---
 gcc/testsuite/gcc.target/i386/auto-init-4.c | 7 +++
 gcc/testsuite/gcc.target/i386/auto-init-5.c | 4 +---
 gcc/testsuite/gcc.target/i386/auto-init-padding-3.c | 6 ++
 gcc/testsuite/gcc.target/i386/auto-init-padding-7.c | 4 +---
 gcc/testsuite/gcc.target/i386/auto-init-padding-8.c | 2 +-
 gcc/testsuite/gcc.target/i386/auto-init-padding-9.c | 4 ++--
 8 files changed, 16 insertions(+), 23 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/auto-init-2.c b/gcc/testsuite/gcc.target/i386/auto-init-2.c
index b23f733a403..e22930ae89b 100644
--- a/gcc/testsuite/gcc.target/i386/auto-init-2.c
+++ b/gcc/testsuite/gcc.target/i386/auto-init-2.c
@@ -33,6 +33,5 @@ void foo()
 /* { dg-final { scan-rtl-dump-times "0xfefe" 1 "expand" } } */
 /* { dg-final { scan-rtl-dump-times "0xfefefefe" 2 "expand" { target lp64 } } } */
 /* { dg-final { scan-rtl-dump-times "0xfefefefefefefefe" 3 "expand" { target lp64 } } } */
-/* { dg-final { scan-rtl-dump-times "0xfefefefe" 4 "expand" { target ia32 } } } */
-/* { dg-final { scan-rtl-dump-times "0xfefefefefefefefe" 1 "expand" { target ia32 } } } */
-
+/* { dg-final { scan-rtl-dump-times "0xfefefefe" 4 "expand" { target { ! lp64 } } } } */
+/* { dg-final { scan-rtl-dump-times "0xfefefefefefefefe" 1 "expand" { target { ! lp64 } } } } */
diff --git a/gcc/testsuite/gcc.target/i386/auto-init-3.c b/gcc/testsuite/gcc.target/i386/auto-init-3.c
index df317616db3..891eab1c40b 100644
--- a/gcc/testsuite/gcc.target/i386/auto-init-3.c
+++ b/gcc/testsuite/gcc.target/i386/auto-init-3.c
@@ -1,6 +1,7 @@
 /* Verify zero initialization for floating point type automatic variables.  */
 /* { dg-do compile } */
-/* { dg-options "-ftrivial-auto-var-init=zero -march=x86-64 -mtune=generic" } */
+/* { dg-options "-ftrivial-auto-var-init=zero -march=x86-64 -mtune=generic -msse" } */
+/* { dg-additional-options "-mfpmath=387" { target ia32 } } */
 
 long double result;
 
@@ -14,5 +15,5 @@ long double foo()
   return result;
 }
 
-/* { dg-final { scan-assembler-times "pxor\t\\\%xmm0, \\\%xmm0" 3  { target lp64 } } } */
-/* { dg-final { scan-assembler-times "fldz" 3  { target ia32} } } */
+/* { dg-final { scan-assembler-times "pxor\t\\\%xmm0, \\\%xmm0" 3  { target { ! ia32 } } } } */
+/* { dg-final { scan-assembler-times "fldz" 3  { target ia32 } } } */
diff --git a/gcc/testsuite/gcc.target/i386/auto-init-4.c b/gcc/testsuite/gcc.target/i386/auto-init-4.c
index 554a2c57eb6..7b46c74a073 100644
--- 

Re: [Patch]GCC11 - Fortran: combined directives - order(concurrent) not on distribute (was: Re: [Patch] Fortran/OpenMP: unconstrained/reproducible ordered modifier)

[Jakub Jelinek via Gcc-patches]

On Mon, Sep 20, 2021 at 05:01:32PM +0200, Tobias Burnus wrote:
> On 20.09.21 11:55, Jakub Jelinek via Fortran wrote:
> > So the FE was splitting the order clause to distribute already before,
> > perhaps we should undo that for gcc 11 which doesn't claim any OpenMP 5.1
> > support.
> > The difference is e.g. the distribute parallel do order(concurrent) 
> > copyin(thr)
> > case which used to be ok in 5.0 and is not in 5.1.
> 
> Well, if I try with GCC 11:
> 
> void f(int *a)
> {
> int  i;
> static int thr;
> #pragma omp threadprivate (thr)
> #pragma omp distribute parallel for order(concurrent) copyin(thr)
>   for (i = 0; i < 10; ++i)
>{
> thr = 5;
> a[i] = thr;
>}
> }
> 
> I get with gcc (+ gfortran):
>   error: threadprivate variable ‘thr’ used in a region with 
> ‘order(concurrent)’ clause
> I might have misunderstood the example.

Sure, even before you couldn't use it in the region body, because
order(concurrent) was split to worksharing-loop.
The testcase that used to be accepted and is now rejected is e.g.

int thr;
#pragma omp threadprivate (thr)

void
foo (void)
{
  int i;
#pragma omp distribute parallel for order(concurrent) copyin(thr)
  for (i = 0; i < 10; ++i)
   ;
}

While copyin without actually using the threadprivate var in the body
might look weird, in some cases it might be useful if the threadprivate
variable is used in some following parallel region.

> OK for GCC 11, only?
> 
> Tobias
> 
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955

> GCC11 - Fortran: combined directives - order(concurrent) not on distribute
> 
> While OpenMP 5.1 and GCC 12 permits 'order(concurrent)' on distribute,
> OpenMP 5.0 and GCC 11 don't. This patch for GCC 11 ensures the clause also
> does not end up on 'distribute' when splitting combined directives.
> 
> gcc/fortran/ChangeLog:
> 
>   * trans-openmp.c (gfc_split_omp_clauses): Don't put 'order(concurrent)'
>   on 'distribute' for combined directives, matching OpenMP 5.0
> 
> gcc/testsuite/ChangeLog:
> 
>   * gfortran.dg/gomp/distribute-order-concurrent.f90: New test.

Ok, thanks.

Jakub

[Patch]GCC11 - Fortran: combined directives - order(concurrent) not on distribute (was: Re: [Patch] Fortran/OpenMP: unconstrained/reproducible ordered modifier)

[Tobias Burnus]

On 20.09.21 11:55, Jakub Jelinek via Fortran wrote:

So the FE was splitting the order clause to distribute already before,
perhaps we should undo that for gcc 11 which doesn't claim any OpenMP 5.1
support.
The difference is e.g. the distribute parallel do order(concurrent) copyin(thr)
case which used to be ok in 5.0 and is not in 5.1.


Well, if I try with GCC 11:

void f(int *a)
{
int  i;
static int thr;
#pragma omp threadprivate (thr)
#pragma omp distribute parallel for order(concurrent) copyin(thr)
  for (i = 0; i < 10; ++i)
   {
thr = 5;
a[i] = thr;
   }
}

I get with gcc (+ gfortran):
  error: threadprivate variable ‘thr’ used in a region with ‘order(concurrent)’ 
clause
I might have misunderstood the example.

 * * *

In any case, for GCC 11, I have now fixed the splitting and added a testcase 
which
relies on -fdump-tree-original scanning and does not use threadprivate.

OK for GCC 11, only?

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
GCC11 - Fortran: combined directives - order(concurrent) not on distribute

While OpenMP 5.1 and GCC 12 permits 'order(concurrent)' on distribute,
OpenMP 5.0 and GCC 11 don't. This patch for GCC 11 ensures the clause also
does not end up on 'distribute' when splitting combined directives.

gcc/fortran/ChangeLog:

	* trans-openmp.c (gfc_split_omp_clauses): Don't put 'order(concurrent)'
	on 'distribute' for combined directives, matching OpenMP 5.0

gcc/testsuite/ChangeLog:

	* gfortran.dg/gomp/distribute-order-concurrent.f90: New test.

 gcc/fortran/trans-openmp.c |  2 --
 .../gomp/distribute-order-concurrent.f90   | 25 ++
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index 7e931bf4bc7..973d916b4a2 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -5176,8 +5176,6 @@ gfc_split_omp_clauses (gfc_code *code,
 	  /* Duplicate collapse.  */
 	  clausesa[GFC_OMP_SPLIT_DISTRIBUTE].collapse
 	= code->ext.omp_clauses->collapse;
-	  clausesa[GFC_OMP_SPLIT_DISTRIBUTE].order_concurrent
-	= code->ext.omp_clauses->order_concurrent;
 	}
   if (mask & GFC_OMP_MASK_PARALLEL)
 	{
diff --git a/gcc/testsuite/gfortran.dg/gomp/distribute-order-concurrent.f90 b/gcc/testsuite/gfortran.dg/gomp/distribute-order-concurrent.f90
new file mode 100644
index 000..9597d913684
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/distribute-order-concurrent.f90
@@ -0,0 +1,25 @@
+! { dg-additional-options "-fdump-tree-original" }
+!
+! In OpenMP 5.0, 'order(concurrent)' does not apply to distribute
+! Ensure that it is rejected in GCC 11.
+! 
+! Note: OpenMP 5.1 allows it; the GCC 12 testcase for it is gfortran.dg/gomp/order-5.f90
+
+subroutine f(a)
+implicit none
+integer :: i, thr
+!save :: thr
+integer :: a(:)
+
+!$omp distribute parallel do order(concurrent) private(thr)
+  do i = 1, 10
+thr = 5
+a(i) = thr
+  end do
+!$omp end distribute parallel do
+end
+
+! { dg-final { scan-tree-dump-not "omp distribute\[^\n\r]*order" "original" } }
+! { dg-final { scan-tree-dump "#pragma omp distribute\[\n\r\]" "original" } }
+! { dg-final { scan-tree-dump "#pragma omp parallel private\\(thr\\)" "original" } }
+! { dg-final { scan-tree-dump "#pragma omp for nowait order\\(concurrent\\)" "original" } }

[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329

--- Comment #6 from Martin Sebor  ---
In general a program can add an attribute to a system function by redeclaring
it with it.  This of course needs to be done conditionally on the GCC version
that supports the attribute.  This in turn can be tested at compile time by the
__has_attribute operator or based on GCC version macros.

Re: [PATCH] Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*

[Jeff Law via Gcc-patches]

On 9/20/2021 1:00 AM, Richard Biener wrote:

This obsoletes the 32bit hppa-hpux configurations which only support
STABS as debuginfo format.

As discussed, I'm going to push this (and a changes.html entry) when
it was included in a bootstrap/regtest cycle.

2021-09-20  Richard Biener  

gcc/
* config.gcc: Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*.

contrib/
* config-list.mk: --enable-obsolete for hppa2.0-hpux10.1 and
hppa2.0-hpux11.9.
Is this marking hppa2.0w-hp-hpux11 as obsolete?  That platform is using 
ELF & DWARF.


jeff

Re: [pushed] Driver: Fix bootstrap with DEFAULT_{ASSEMBLER,LINKER,DSYMUTIL}.

[Jeff Law via Gcc-patches]

On 9/20/2021 12:50 AM, Iain Sandoe wrote:

Hi

The patch at r12-3662-g5fee8a0a9223d factored the code for
printing the names of programes into a separate function.
However the moved editions that print out the names of the
assembler, linker (and dsymutil on Darwin) when those are
specified at configure-time were not adjusted accordingly,
leading to a bootstrap fail.

Fixed by testing specifically for execute OK, since we know
these are programs.

tested on i686-darwin9, x86_64-darwin20 configured with
—with-{as,ld,dsymutil}= and on x86_64-darwin18 without.

confirmed that the build and installed versions print the right
thing (and, of course, that bootstrap succeeds).

pushed to master as bootstrap fix, thanks
Iain

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

* gcc.c: Test for execute OK when we find the
programs for assembler linker and dsymutil and those
were specified at configure-time.

Thanks for taking care of this.  Sorry for the breakage.

jeff