[Bug driver/95456] [11 Regression] gcc/gcc.c:6035:16: runtime error: null pointer passed as argument 2, which is declared to never be null

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

Re: [PATCH] Do not copy NULL string with memcpy.

[Martin Liška]

On 6/3/20 5:58 AM, Alexandre Oliva wrote:

Please let me know if you'd prefer me to take this PR over.


Yes, please take a look.

Martin

[Bug tree-optimization/95490] [10/11 Regression] writing 1 byte into a region of size 0 [-Wstringop-overflow=] since r10-5451-gef29b12cfbb4979a89b3cbadbf485a77c8fd8fce

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 48664
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48664=edit
test-case

[Bug tree-optimization/95490] New: [10/11 Regression] writing 1 byte into a region of size 0 [-Wstringop-overflow=] since r10-5451-gef29b12cfbb4979a89b3cbadbf485a77c8fd8fce

[marxin at gcc dot gnu.org]

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

Bug ID: 95490
   Summary: [10/11 Regression] writing 1 byte into a region of
size 0 [-Wstringop-overflow=] since
r10-5451-gef29b12cfbb4979a89b3cbadbf485a77c8fd8fce
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu

Since the revision I see:

$ gcc/bin/ppc64le-linux-gnu-gcc suse.i -c -Wall -O2
/tmp/suse.c: In function ‘reset_tlb_mmu_ways56.constprop.isra’:
/tmp/suse.c:131:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
/tmp/suse.c:132:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
/tmp/suse.c:131:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
/tmp/suse.c:132:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
/tmp/suse.c:131:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
/tmp/suse.c:132:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
/tmp/suse.c:131:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
/tmp/suse.c:132:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
/tmp/suse.c:131:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
/tmp/suse.c:132:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
/tmp/suse.c:131:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
/tmp/suse.c:132:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
/tmp/suse.c:131:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
/tmp/suse.c:132:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]

[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor

[johelegp at gmail dot com]

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

--- Comment #2 from Johel Ernesto Guerrero Peña  ---
That commit added the feature I'm trying to use. I'd hope it's valid, or at
least with this other constructor added: `constexpr X(U) {}`.

PING Re: testsuite: clarify scan-dump file globbing behavior

[Frederik Harwath]

Frederik Harwath  writes:

ping :-)

> Frederik Harwath  writes:
>
> Hi Rainer, hi Mike,
> ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545803.html
>
> Best regards,
> Frederik
>
>> Hi Thomas,
>>
>> Thomas Schwinge  writes:
>>
>>> I can't formally approve testsuite patches, but did a review anyway:
>>
>> Thanks for the review!
>>
>>> On 2020-05-15T12:31:54+0200, Frederik Harwath  
>>> wrote:
>>
 The dump
 scanning procedures are changed to make the test unresolved
 if globbing matches more than one file.
>>>
>>> (The code changes look good, but I have not tested that specific aspect.)
>>
>> We do not have automated tests for the testsuite commands :-), but I
>> have of course tested this manually.
>>
>>> As I said, not an approval, and minor comments (see below), but still:
>>>
>>> Reviewed-by: Thomas Schwinge 
>>>
>>> Do we have to similarly also audit/alter other testsuite infrastructure
>>> files, anything that uses '[glob [...]]'?  (..., and then generalize
>>> 'glob-dump-file' into 'glob-one-file', or similar.)  That can be done
>>> incrementally, as far as I'm concerned.
>>
>> I also think it would make sense to adapt similar test commands as well.
>>
>>> May also make this more useful/explicit:
>>>
>>> This is useful if, for example, if a pass has several static
>>> instances [correct terminology?], and depending on torture testing
>>> command-line flags, a different instance executes and produces a dump
>>> file, and so in the test case you can use a generic [put example
>>> here] to scan the varying dump files names.
>>>
>>> (Or similar.)
>>
>> I have moved the explanation below the description of the individual
>> commands and added an example. See the attached revised patch.
>>
>> Best regards,
>> Frederik
>>
>> From 2a17749d6dbcac690d698323240438722d6119ef Mon Sep 17 00:00:00 2001
>> From: Frederik Harwath 
>> Date: Fri, 15 May 2020 10:35:48 +0200
>> Subject: [PATCH] testsuite: clarify scan-dump file globbing behavior
>>
>> The test commands for scanning optimization dump files
>> perform globbing on the argument that specifies the suffix
>> of the dump files to be scanned.  This behavior is currently
>> undocumented.  Furthermore, the current implementation of
>> "scan-dump" and similar procedures yields an error whenever
>> the file name globbing matches more than one file (due to an
>> attempt to call "open" on multiple files) while a failure to
>> match any file results in an unresolved test.
>>
>> This commit documents the globbing behavior.  The dump
>> scanning procedures are changed to make the test unresolved
>> if globbing matches more than one file.
>>
>> gcc/ChangeLog:
>>
>> 2020-05-19  Frederik Harwath  
>>
>>  * doc/sourcebuild.texi: Describe globbing of the
>>  dump file scanning commands "suffix" argument.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2020-05-19  Frederik Harwath  
>>
>>  * lib/scandump.exp (glob-dump-file): New proc.
>>  (scan-dump): Use glob-dump-file for file name expansion.
>>  (scan-dump-times): Likewise.
>>  (scan-dump-dem): Likewise.
>>  (scan-dump-dem-not): Likewise.
>>
>> Reviewed-by: Thomas Schwinge 
>> ---
>>  gcc/doc/sourcebuild.texi   | 13 
>>  gcc/testsuite/lib/scandump.exp | 54 +++---
>>  2 files changed, 56 insertions(+), 11 deletions(-)
>>
>> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
>> index 240d6e4b08e..9df4b06d460 100644
>> --- a/gcc/doc/sourcebuild.texi
>> +++ b/gcc/doc/sourcebuild.texi
>> @@ -2911,6 +2911,19 @@ Passes if @var{regex} does not match demangled text 
>> in the dump file with
>>  suffix @var{suffix}.
>>  @end table
>>
>> +The @var{suffix} argument which describes the dump file to be scanned
>> +may contain a glob pattern that must expand to exactly one file
>> +name. This is useful if, e.g., different pass instances are executed
>> +depending on torture testing command-line flags, producing dump files
>> +whose names differ only in their pass instance number suffix.  For
>> +example, to scan instances 1, 2, 3 of a tree pass ``mypass'' for
>> +occurrences of the string ``code has been optimized'', use:
>> +@smallexample
>> +/* @{ dg-options "-fdump-tree-mypass" @} */
>> +/* @{ dg-final @{ scan-tree-dump "code has been optimized" "mypass\[1-3\]" 
>> @} @} */
>> +@end smallexample
>> +
>> +
>>  @subsubsection Check for output files
>>
>>  @table @code
>> diff --git a/gcc/testsuite/lib/scandump.exp b/gcc/testsuite/lib/scandump.exp
>> index d6ba350acc8..f3a991b590a 100644
>> --- a/gcc/testsuite/lib/scandump.exp
>> +++ b/gcc/testsuite/lib/scandump.exp
>> @@ -39,6 +39,34 @@ proc dump-base { args } {
>>  return $dumpbase
>>  }
>>
>> +# Expand dump file name pattern to exactly one file.
>> +# Return a single dump file name or an empty string
>> +# if the pattern matches no file or more than one file.
>> +#
>> +# Argument 0 is the testcase name
>> +# Argument 1 is the dump file glob pattern
>> +proc 

[PATCH V2] PING^ correct COUNT and PROB for unrolled loop

[Jiufu Guo via Gcc-patches]

Jiufu Guo via Gcc-patches  writes:

Hi,

I would like to reping this, hope to get approval for this patch.
https://gcc.gnu.org/legacy-ml/gcc-patches/2020-02/msg00927.html

BR,
Jiufu Guo

> Jiufu Guo  writes:
>
> Hi,
>
> I'd like to ping this patch for trunk on stage 1.
>
> This patch could fix the issue on incorrect COUNT/FREQUENCES of loop
> unrolled blocks, and also could help the improve the cold/hot issue of
> the unrolled loops.
>
> patch is also at
> https://gcc.gnu.org/legacy-ml/gcc-patches/2020-02/msg00927.html
>
> Thanks,
> Jiufu
>
>> Jiufu Guo  writes:
>>
>> Hi!
>>
>> I'd like to ping following patch. As near end of gcc10 stage 4, it seems
>> I would ask approval for GCC11 trunk.
>>
>> Thanks,
>> Jiufu Guo
>>
>>> Hi Honza and all,
>>>
>>> I updated the patch a little as below. Bootstrap and regtest are ok
>>> on powerpc64le.
>>>
>>> Is OK for trunk?
>>>
>>> Thanks for comments.
>>> Jiufu
>>>
>>> diff --git a/gcc/cfgloopmanip.c b/gcc/cfgloopmanip.c
>>> index 727e951..ded0046 100644
>>> --- a/gcc/cfgloopmanip.c
>>> +++ b/gcc/cfgloopmanip.c
>>> @@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.  If not see
>>>  #include "gimplify-me.h"
>>>  #include "tree-ssa-loop-manip.h"
>>>  #include "dumpfile.h"
>>> +#include "cfgrtl.h"
>>>  
>>>  static void copy_loops_to (class loop **, int,
>>>class loop *);
>>> @@ -1258,14 +1259,30 @@ duplicate_loop_to_header_edge (class loop *loop, 
>>> edge e,
>>>   /* If original loop is executed COUNT_IN times, the unrolled
>>>  loop will account SCALE_MAIN_DEN times.  */
>>>   scale_main = count_in.probability_in (scale_main_den);
>>> +
>>> + /* If we are guessing at the number of iterations and count_in
>>> +becomes unrealistically small, reset probability.  */
>>> + if (!(count_in.reliable_p () || loop->any_estimate))
>>> +   {
>>> + profile_count new_count_in = count_in.apply_probability 
>>> (scale_main);
>>> + profile_count preheader_count = loop_preheader_edge (loop)->count 
>>> ();
>>> + if (new_count_in.apply_scale (1, 10) < preheader_count)
>>> +   scale_main = profile_probability::likely ();
>>> +   }
>>> +
>>>   scale_act = scale_main * prob_pass_main;
>>> }
>>>else
>>> {
>>> + profile_count new_loop_count;
>>>   profile_count preheader_count = e->count ();
>>> - for (i = 0; i < ndupl; i++)
>>> -   scale_main = scale_main * scale_step[i];
>>>   scale_act = preheader_count.probability_in (count_in);
>>> + /* Compute final preheader count after peeling NDUPL copies.  */
>>> + for (i = 0; i < ndupl; i++)
>>> +   preheader_count = preheader_count.apply_probability (scale_step[i]);
>>> + /* Subtract out exit(s) from peeled copies.  */
>>> + new_loop_count = count_in - (e->count () - preheader_count);
>>> + scale_main = new_loop_count.probability_in (count_in);
>>> }
>>>  }
>>>  
>>> @@ -1381,6 +1398,38 @@ duplicate_loop_to_header_edge (class loop *loop, 
>>> edge e,
>>>   scale_bbs_frequencies (new_bbs, n, scale_act);
>>>   scale_act = scale_act * scale_step[j];
>>> }
>>> +
>>> +  /* Need to update PROB of exit edge and corresponding COUNT.  */
>>> +  if (orig && is_latch && (!bitmap_bit_p (wont_exit, j + 1))
>>> + && bbs_to_scale)
>>> +   {
>>> + edge new_exit = new_spec_edges[SE_ORIG];
>>> + profile_count new_count_in = new_exit->src->count;
>>> + profile_count preheader_count = loop_preheader_edge (loop)->count ();
>>> + edge e;
>>> + edge_iterator ei;
>>> +
>>> + FOR_EACH_EDGE (e, ei, new_exit->src->succs)
>>> +   if (e != new_exit)
>>> + break;
>>> +
>>> + gcc_assert (e && e != new_exit);
>>> +
>>> + new_exit->probability = preheader_count.probability_in (new_count_in);
>>> + e->probability = new_exit->probability.invert ();
>>> +
>>> + profile_count new_latch_count
>>> +   = new_exit->src->count.apply_probability (e->probability);
>>> + profile_count old_latch_count = e->dest->count;
>>> +
>>> + EXECUTE_IF_SET_IN_BITMAP (bbs_to_scale, 0, i, bi)
>>> +   scale_bbs_frequencies_profile_count (new_bbs + i, 1,
>>> +new_latch_count,
>>> +old_latch_count);
>>> +
>>> + if (current_ir_type () != IR_GIMPLE)
>>> +   update_br_prob_note (e->src);
>>> +   }
>>>  }
>>>free (new_bbs);
>>>free (orig_loops);
>>> diff --git a/gcc/testsuite/gcc.dg/pr68212.c b/gcc/testsuite/gcc.dg/pr68212.c
>>> new file mode 100644
>>> index 000..f3b7c22
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.dg/pr68212.c
>>> @@ -0,0 +1,13 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-O2 -fno-tree-vectorize -funroll-loops --param 
>>> max-unroll-times=4 -fdump-rtl-alignments" } */
>>> +
>>> +void foo(long int *a, long int *b, long int n)
>>> +{
>>> +  long int i;
>>> +
>>> +  for (i = 0; i < n; i++)
>>> +a[i] = *b;
>>> 

[Bug middle-end/95485] missing warning writing into function text

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
-Wpedantic catches it:

$ /usr/local/bin/gcc -c -O2 -S -Wall -Wextra -pedantic
-fdump-tree-optimized=/dev/stdout 95485.c
95485.c: In function 'f':
95485.c:6:20: warning: ISO C forbids passing argument 1 of '__builtin_memset'
between function pointer and 'void *' [-Wpedantic]
6 |  __builtin_memset (p, 0, 32);   // zero out -- whoops! -- writing to a
function
  |^
95485.c:6:20: note: expected 'void *' but argument is of type 'void * (*)(int)'

;; Function f (f, funcdef_no=0, decl_uid=1910, cgraph_uid=1, symbol_order=0)

f (void * (*) (int) p)
{
  void * q;

   [local count: 1073741824]:
  q_4 = p_2(D) (32);
  __builtin_memset (p_2(D), 0, 32);
  return q_4;

}


$

[Bug tree-optimization/95487] [10/11 Regression] ICE: verify_gimple failed (error: invalid vector types in nop conversion) with -O3 -march=skylake-avx512 since r10-1052-gc29c92c789d93848

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|ICE: verify_gimple failed   |[10/11 Regression] ICE:
   |(error: invalid vector  |verify_gimple failed
   |types in nop conversion)|(error: invalid vector
   |with -O3|types in nop conversion)
   |-march=skylake-avx512   |with -O3
   ||-march=skylake-avx512 since
   ||r10-1052-gc29c92c789d93848
 CC||fxue at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-03
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-1052-gc29c92c789d93848.

[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2020-06-03
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Martin Liška  ---
The ICE started with r10-5020-g1a291106384cabc7.
Is it a valid or invalid code?

[Bug target/95483] [i386] Missing SIMD functions

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
   Last reconfirmed||2020-06-03
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Thank you very much for the report. I'm adding target maintainers to CC.

[Bug tree-optimization/95489] New: Failure to optimize x && (x & y) to x & y

[gabravier at gmail dot com]

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

Bug ID: 95489
   Summary: Failure to optimize x && (x & y) to x & y
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(int x, int y)
{
return x && (x & y);
}

This can be optimized to `return x & y;` (see also the summary). This
optimization is done by LLVM, but not by GCC.

Re: [PATCH] Do not copy NULL string with memcpy.

[Alexandre Oliva]

Hello, Martin,

On Jun  2, 2020, Martin Liška  wrote:

> The problem happens when we generate temp file
> for .res file. Tested locally with the problematic
> options.

Thanks for looking into this.

> Ready for master?

Erhm, no, I don't think that's correct.

With local analysis, the length computation just before has only
allocated space for basename_length.  If you copy outbase_length, you
might be writing past the end of the allocated area.


I guess basename_length is 0, otherwise you'd see a crash without the
assert you added in the PR.

With some global analysis (and running the testcase), it appears to me
that when input_basename is NULL (e.g., when processing linker specs),
so is outbase, so your proposed change appears to be trading one 0-byte
memcpy from NULL for another.

I'd rather make it:

  if (!outbase_length)
{
  if (basename_length)
memcpy (tmp + dumpdir_length, input_basename, basename_length);
}
  else
memcpy (tmp + dumpdir_length, outbase, outbase_length);

or maybe:

  if (outbase_length)
memcpy (tmp + dumpdir_length, outbase, outbase_length);
  else if (basename_length)
memcpy (tmp + dumpdir_length, input_basename, basename_length);


Please let me know if you'd prefer me to take this PR over.

-- 
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

Re: [PATCH 0/4] IVOPTs consider step cost for different forms when unrolling

[Kewen.Lin via Gcc-patches]

Hi Richi,

on 2020/6/2 下午7:38, Richard Biener wrote:
> On Thu, 28 May 2020, Kewen.Lin wrote:
> 
>> Hi,
>>
>> This is one repost and you can refer to the original series 
>> via https://gcc.gnu.org/pipermail/gcc-patches/2020-January/538360.html.
>>
>> As we discussed in the thread
>> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00196.html
>> Original: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00104.html,
>> I'm working to teach IVOPTs to consider D-form group access during unrolling.
>> The difference on D-form and other forms during unrolling is we can put the
>> stride into displacement field to avoid additional step increment. eg:
>>
>> With X-form (uf step increment):
>>   ...
>>   LD A = baseA, X
>>   LD B = baseB, X
>>   ST C = baseC, X
>>   X = X + stride
>>   LD A = baseA, X
>>   LD B = baseB, X
>>   ST C = baseC, X
>>   X = X + stride
>>   LD A = baseA, X
>>   LD B = baseB, X
>>   ST C = baseC, X
>>   X = X + stride
>>   ...
>>
>> With D-form (one step increment for each base):
>>   ...
>>   LD A = baseA, OFF
>>   LD B = baseB, OFF
>>   ST C = baseC, OFF
>>   LD A = baseA, OFF+stride
>>   LD B = baseB, OFF+stride
>>   ST C = baseC, OFF+stride
>>   LD A = baseA, OFF+2*stride
>>   LD B = baseB, OFF+2*stride
>>   ST C = baseC, OFF+2*stride
>>   ...
>>   baseA += stride * uf
>>   baseB += stride * uf
>>   baseC += stride * uf
>>
>> Imagining that if the loop get unrolled by 8 times, then 3 step updates with
>> D-form vs. 8 step updates with X-form. Here we only need to check stride
>> meet D-form field requirement, since if OFF doesn't meet, we can construct
>> baseA' with baseA + OFF.
> 
> I'd just mention there are other targets that have the choice between
> the above forms.  Since IVOPTs itself does not perform the unrolling
> the IL it produces is the same, correct?
> 
Yes.  Before this patch, IVOPTs doesn't consider the unrolling impacts,
it only models things based on what it sees.  We can assume it thinks
later RTL unrolling won't perform.

With this patch, since the IV choice probably changes, the IL can probably
change.  The typical difference with this patch is:

  vect__1.7_15 = MEM[symbol: x, index: ivtmp.19_22, offset: 0B];
vs.
  vect__1.7_15 = MEM[base: _29, offset: 0B];

BR,
Kewen

> Richard.
> 

Re: [PATCH 6/7] PowerPC tests: Add PC-relative tests.

[Michael Meissner via Gcc-patches]

On Mon, Jun 01, 2020 at 05:45:34PM -0500, will schmidt wrote:
> Similar/same comment as was made in Apr.I recommend something like 
> 
> "Test whether pc-relative prefixed instructions
> are generated for the _Decimal64 type." 

Ok, I missed that comment in April.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[Bug target/95252] testcase gcc.dg/torture/pr67916.c failure when testing with -msave-restore

[kito at gcc dot gnu.org]

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

Kito Cheng  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #9 from Kito Cheng  ---
Just update the status from my side, I have a workable version for exact list
of USEs, and under clean up.

[Bug target/95488] Suboptimal multiplication codegen for v16qi

[crazylht at gmail dot com]

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

--- Comment #1 from Hongtao.liu  ---
I think it's this TYPE_SIGN (TREE_TYPE (REG_EXPR (op1))).

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

[Kewen.Lin via Gcc-patches]

Hi Richard,

on 2020/6/2 下午3:14, Richard Sandiford wrote:
> "Kewen.Lin"  writes:
>> Hi Richard,
>>
>> Thanks for the comments!
>>
>> on 2020/6/2 上午1:59, Richard Sandiford wrote:
>>> Could you go into more detail about this choice of cost calculation?
>>> It looks like we first calculate per-group flags, which are true only if
>>> the unrolled offsets are valid for all uses in the group.  Then we create
>>> per-candidate flags when associating candidates with groups.
>>>
>>
>> Sure.  It checks every address type IV group to determine whether this
>> group is valid to use reg offset addressing mode.  Here we only need to
>> check the first one and the last one, since the intermediates should 
>> have been handled by split_address_groups.  With unrolling the
>> displacement of the address can be offset-ed by (UF-1)*step, check the
>> address with this max offset whether still valid.  If the check finds
>> it's valid to use reg offset mode for the whole group, we flag this
>> group.  Later, when we create IV candidate for address group flagged,
>> we flag the candidate further.  This flag is mainly for iv cand
>> costing, we don't need to scale up iv cand's step cost for this kind
>> of candidate.
> 
> But AIUI, this is calculating whether the uses in their original form
> support all unrolled offsets.  For ivopts, I think the question is really
> whether the uses support all unrolled offsets when based on a given IV
> candidate (which might not be the original IV).
> 

Good point!  Indeed, the patch only flags the IV cands derived from the
address group flagged with reg_offset_p, it has the possibility that
we miss some other candidates with same basic but different offset
which can satisfy addr_offset_valid_p.

How about to update the current approach to: instead of flag the derived
iv cand, when we determine the cost for iv cand, we check whether this
iv cand has the same basic object as the one of any reg_offset_p vuse[0]
(both should be stripped their offsets), then further check the offset
can satisfy addr_offset_valid_p, if all checks expected, update the step
cost without uf consideration.

I would expect this kind of address based iv cand will mainly be used
for address type group and compare type group, for the address type 
group, it can be only applied for those with same basic object, in most
cases they are put in the same address group.  If it's used for generic
much, the step cost tweaking might not be fixed at the beginning but
varies according to the iv set members.  It looks too much for the
existing framework.

> E.g. there might be another IV candidate at a constant offset
> from the original one, and the offsets might all be in range
> for that offset too.
> 
>> Imagining this loop is being unrolled, all the statements will be
>> duplicated by UF.  For the cost modeling against iv group, it's
>> scaling up the cost by UF (here I simply excluded the compare_type
>> since in most cases it for loop ending check).  For the cost modeling
>> against iv candidate, it's to focus on step costs, for an iv candidate
>> we flagged before, it's taken as one time step cost, for the others,
>> it's scaling up the step cost since the unrolling make step 
>> calculation become UF times.
>>
>> This cost modeling is trying to simulate cost change after the
>> unrolling, scaling up the costs accordingly.  There are somethings
>> to be improved like distinguish the loop ending compare or else,
>> whether need to tweak the other costs somehow since the scaling up
>> probably cause existing cost framework imbalance, but during
>> benchmarking I didn't find these matter, so take it as simple as 
>> possible for now.
>>
>>
>>> Instead, couldn't we take this into account in get_address_cost,
>>> which calculates the cost of an address use for a given candidate?
>>> E.g. after the main if-else at the start of the function,
>>> perhaps it would make sense to add the worst-case offset to
>>> the address in “parts”, check whether that too is a valid address,
>>> and if not, increase var_cost by the cost of one add instruction.
>>>
>>
>> IIUC, what you suggest is to tweak the iv group cost, if we find
>> one address group is valid for reg offset mode, we price more on
>> the pairs between this group and other non address-based iv cands.
>> The question is how do we decide this add-on cost.  For the test
>> case I was working on initially, adding one cost (of add) doesn't
>> work, the normal iv still wined.  We can price it more like two
>> but what's the justification on this value, by heuristics?
> 
> Yeah, I was thinking of adding one instance of add_cost.  If that
> doesn't work, it'd be interesting to know why in more detail.
> 

The case is like:

for (i = 0; i < SIZE; i++)
  y[i] = a * x[i] + z[i];

It has three array access in the loop body, after vectorization,
it looks like

  vect__1.7_15 = MEM  [(double *)vectp_x.5_20];
  vect__3.8_13 = vect__1.7_15 * vect_cst__14;
  vect__4.11_19 = 

[Bug tree-optimization/53979] ((a ^ b) | a) not optimized to (a | b)

[gabravier at gmail dot com]

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

Gabriel Ravier  changed:

   What|Removed |Added

 CC||gabravier at gmail dot com

--- Comment #4 from Gabriel Ravier  ---
I've just checked on trunk and it looks fixed

[Bug target/95488] New: Suboptimal multiplication codegen for v16qi

[crazylht at gmail dot com]

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

Bug ID: 95488
   Summary: Suboptimal multiplication codegen for v16qi
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---
Target: x86_64-*-* i?86-*-*

cat test.c

---
typedef unsigned char v16qi __attribute__ ((vector_size (16)));
v16qi
foo (v16qi a, v16qi b)
{
return  a*b;
}
---

gcc -O2 -march=skylake-avx512

---
foo(unsigned char __vector(16), unsigned char __vector(16)):
vpunpcklbw  xmm3, xmm0, xmm0
vpunpcklbw  xmm2, xmm1, xmm1
vpunpckhbw  xmm0, xmm0, xmm0
vpunpckhbw  xmm1, xmm1, xmm1
vpmullw xmm2, xmm2, xmm3
vpmullw xmm1, xmm1, xmm0
vmovdqa xmm3, XMMWORD PTR .LC0[rip]
vpand   xmm0, xmm3, xmm2
vpand   xmm3, xmm3, xmm1
vpackuswb   xmm0, xmm0, xmm3
ret
.LC0:
.value  255
.value  255
.value  255
.value  255
.value  255
.value  255
.value  255
.value  255
---

icc generate
---
foo(unsigned char __vector(16), unsigned char __vector(16)):
vpmovzxbw ymm2, xmm0#5.15
vpmovzxbw ymm3, xmm1#5.15
vpmullw   ymm4, ymm2, ymm3  #5.15
vpmovwb   xmm0, ymm4#5.15
vzeroupper  #5.15
ret #5.15
---

we can do better in ix86_expand_vecop_qihi, problem is how can i get sign info
for an rtx operand.

[Bug tree-optimization/95058] [11 regression] vector test case failures starting with r11-205

[seurer at linux dot vnet.ibm.com]

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

--- Comment #10 from Bill Seurer  ---
There is still one that is failing:

make -k check-gcc RUNTESTFLAGS=vect.exp=gcc.dg/vect/bb-slp-pr68892.c

XPASS: gcc.dg/vect/bb-slp-pr68892.c scan-tree-dump slp2 "not profitable"
XPASS: gcc.dg/vect/bb-slp-pr68892.c -flto -ffat-lto-objects  scan-tree-dump
slp2 "not profitable"
FAIL: gcc.dg/vect/bb-slp-pr68892.c scan-tree-dump-times slp2 "Basic block will
be vectorized" 1
FAIL: gcc.dg/vect/bb-slp-pr68892.c -flto -ffat-lto-objects 
scan-tree-dump-times slp2 "Basic block will be vectorized" 1

# of expected passes4
# of unexpected failures2

[PATCH] Fix zero-masking for vcvtps2ph when dest operand is memory.

[Hongtao Liu via Gcc-patches]

Hi:
  When dest is memory, zero-masking is not valid, only merging-masking
is available,

  Bootstrap is ok, regression test on i386/x86-64 backend is ok.

gcc/ChangeLog:
* gcc/config/i386/sse.md (*vcvtps2ph_store):
Refine from *vcvtps2ph_store.
(vcvtps2ph256): Refine constraint from vm to v.
(avx512f_vcvtps2ph512): Ditto.
(*vcvtps2ph256): New define_insn.
(*avx512f_vcvtps2ph512): Ditto.
* gcc/config/i386/subst.md (merge_mask): New define_subst.
(merge_mask_name): New define_subst_attr.
(merge_mask_operand3): Ditto.

gcc/testsuite/ChangeLog:
* gcc.target/i386/avx512f-vcvtps2ph-pr95254.c: New test.
* gcc.target/i386/avx512vl-vcvtps2ph-pr95254.c: Ditto.
-- 
BR,
Hongtao


0001-Fix-zero-masking-for-vcvtps2ph-when-dest-operand-is-.patch
Description: Binary data

Re: [PATCH 1/2] Introduce flag_cunroll_grow_size for cunroll

[Jiufu Guo via Gcc-patches]

Richard Biener  writes:

> On Tue, Jun 2, 2020 at 4:10 AM Jiufu Guo  wrote:
>>
>> Jiufu Guo  writes:
>>
>> Hi,
>>
>> I updated the patch just a little accordinlgy.  Thanks!
>>
>> diff --git a/gcc/common.opt b/gcc/common.opt
>> index 4464049fc1f..570e2aa53c8 100644
>> --- a/gcc/common.opt
>> +++ b/gcc/common.opt
>> @@ -2856,6 +2856,10 @@ funroll-all-loops
>>  Common Report Var(flag_unroll_all_loops) Optimization
>>  Perform loop unrolling for all loops.
>>
>> +funroll-completely-grow-size
>> +Common Undocumented Var(flag_cunroll_grow_size) Init(2) Optimization
>> +; Internal undocumented flag, allow size growth during complete unrolling
>> +
>>  ; Nonzero means that loop optimizer may assume that the induction variables
>>  ; that control loops do not overflow and that the loops with nontrivial
>>  ; exit condition are not infinite
>> diff --git a/gcc/toplev.c b/gcc/toplev.c
>> index 96316fbd23b..8d52358efdd 100644
>> --- a/gcc/toplev.c
>> +++ b/gcc/toplev.c
>> @@ -1474,6 +1474,10 @@ process_options (void)
>>if (flag_unroll_all_loops)
>>  flag_unroll_loops = 1;
>>
>> +  /* Allow cunroll to grow size accordingly.  */
>> +  if (flag_cunroll_grow_size == AUTODETECT_VALUE)
>> +flag_cunroll_grow_size = flag_unroll_loops || flag_peel_loops;
>> +
>
> (*)
>
>>/* web and rename-registers help when run after loop unrolling.  */
>>if (flag_web == AUTODETECT_VALUE)
>>  flag_web = flag_unroll_loops;
>> diff --git a/gcc/tree-ssa-loop-ivcanon.c b/gcc/tree-ssa-loop-ivcanon.c
>> index 8ab6ab3330c..298ab215530 100644
>> --- a/gcc/tree-ssa-loop-ivcanon.c
>> +++ b/gcc/tree-ssa-loop-ivcanon.c
>> @@ -1603,9 +1603,8 @@ pass_complete_unroll::execute (function *fun)
>>   re-peeling the same loop multiple times.  */
>>if (flag_peel_loops)
>>  peeled_loops = BITMAP_ALLOC (NULL);
>> -  unsigned int val = tree_unroll_loops_completely (flag_unroll_loops
>> -  || flag_peel_loops
>> -  || optimize >= 3, true);
>> +  unsigned int val = tree_unroll_loops_completely (flag_cunroll_grow_size,
>
> With -O3 -fno-peel-loops this does not have the same effect anymore.
> So above (*) you'd need to check || optimize >= 3 as well.

Oh, yes.  Thanks for your kindly review!

BR,
Jiufu

>
>> +  true);
>>if (peeled_loops)
>>  {
>>BITMAP_FREE (peeled_loops);
>>
>> BR,
>> Jiufu
>>
>> > Richard Biener  writes:
>> >
>>
>> >>> >> From: Jiufu Guo 
>> >>> >>
>> >>> >> Currently GIMPLE complete unroller(cunroll) is checking
>> >>> >> flag_unroll_loops and flag_peel_loops to see if allow size growth.
>> >>> >> Beside affects curnoll, flag_unroll_loops also controls RTL unroler.
>> >>> >> To have more freedom to control cunroll and RTL unroller, this patch
>> >>> >> introduces flag_cunroll_grow_size.  With this patch, we can control
>> >>> >> cunroll and RTL unroller indepently.
>> >>> >>
>> >>> >> Bootstrap/regtest pass on powerpc64le. OK for trunk? And backport to
>> >>> >> GCC10 after week?
>> >>> >>
>> >>> >>
>> >>> >> +funroll-completely-grow-size
>> >>> >> +Var(flag_cunroll_grow_size) Init(2)
>> >>> >> +; Control cunroll to allow size growth during complete unrolling
>> >>> >> +
>> >>> >
>> >>
>> >> It won't work without adjusting the awk scripts.  So go with
>> >>
>> >> funroll-completely-grow-size
>> >> Undocumented Optimization Var(flag_cunroll_grow_size)
>> >> EnabledBy(funroll-loops || fpeel-loops)
>> >> ; ...
>> >>
>> > EnabledBy(funroll-loops || fpeel-loops) does not works as we expected:
>> > "-funroll-loops -fno-peel-loops" turns off flag_cunroll_grow_size.
>> >
>> > Through "EnabledBy", a flag can be turned, and also can be turned off by
>> > the "EnabledBy option", only if the flag is not specifed through commond
>> > line.
>> >
>> >> and enable it at O3+.  AUTODETECT_VALUE doesn't make sense for
>> >> an option not supposed to be set by users?
>> >>
>> >
>> > global_options_set.x_flagxxx can be used to check if option is set by
>> > user.  But it does not work well here neither, because we also care of
>> > if the flag is override by OPTION_OPTIMIZATION_TABLE or
>> > OPTION_OVERRIDE.
>> >
>> > AUTODETECT_VALUE(value is 2) is used for some flags like flag_web,
>> > flag_rename_registers, flag_var_tracking, flag_tree_cselim...
>> > And this way could be used to check if the flag is effective(on/off)
>> > either explicit set by command line or implicit set through
>> > OPTION_OVERRIDE or OPTION_OPTIMIZATION_TABLE.
>> > So, I use it here.
>>
>>

[Bug c++/95468] ICE in expression sfinae

[kab at acm dot org]

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

--- Comment #1 from kab at acm dot org ---
This was labeled as "ice-on-invalid-code".  Am I missing something?  I don't
see anything invalid here.

Re: [stage1][PATCH] Make TOPN counter dynamically allocated.

[Gerald Pfeifer]

On Tue, 2 Jun 2020, Martin Liška wrote:
> Ready for master?

Before that, my nightly tester on i386-unknown-freebsd11 just ran into 
the following:

  /scratch/tmp/gerald/GCC-HEAD/gcc/../libgcc/libgcov.h:396:51: error: 
  cannot initialize a parameter of type 'gcov_type' (aka 'long long') 
  with an rvalue of type 'nullptr_t'
return !__sync_val_compare_and_swap (counter, NULL, (intptr_t)node);
  ^~~~
  /usr/include/sys/_null.h:35:14: note: expanded from macro 'NULL'
  #define NULLnullptr
  ^~~

That seems to have come in via 871e5ada6d53d5eb495cc9f323983f347487c1b2

  Author: Martin Liska 
  Date:   Fri Jan 31 13:10:14 2020 +0100

Make TOPN counter dynamically allocated.
  
  :
* libgcov.h (gcov_counter_add): New.
(gcov_counter_set_if_null): Likewise.
(gcov_topn_add_value): New.
  
which added the gcov_counter_set_if_null function.

(The data is quite misleading and appears to be when you first 
committed this locally?  Does git have a good way to show when 
something was pushed?)

Gerald

[Bug tree-optimization/95487] New: ICE: verify_gimple failed (error: invalid vector types in nop conversion) with -O3 -march=skylake-avx512

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 95487
   Summary: ICE: verify_gimple failed (error: invalid vector types
in nop conversion) with -O3 -march=skylake-avx512
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

Error:
>$ g++ -O3 -march=skylake-avx512 -c func.cpp
func.cpp: In function ‘void h()’:
func.cpp:7:6: error: invalid vector types in nop conversion
7 | void h() {
  |  ^
char
vector(32) unsigned char
stmp_117 = (char) stmp_116;
func.cpp:7:6: error: invalid vector types in nop conversion
char
vector(32) unsigned char
stmp_120 = (char) stmp_119;
during GIMPLE pass: vect
func.cpp:7:6: internal compiler error: verify_gimple failed
0x1141df1 verify_gimple_in_cfg(function*, bool)
/gcc/tree-cfg.c:5461
0x10152af execute_function_todo
/gcc/passes.c:1985
0x101608e execute_todo
/gcc/passes.c:2039

Reproducer:
int a;
bool d;
char e;
extern short f[];
extern int g[];
short j;
void h() {
  for (short b = j; b < 0; b += 2) {
f[b] = 0;
if (d) {
  for (char c = 0; c < a; c += 3)
e = 0;
  g[b] = 0;
}
  }
}

GCC version:
11.0.0 (4b68cb38ddca37a14a6f2f43de3a6d396ee1bc79)

bug 92741 might be related

[Bug tree-optimization/90949] [9 Regression] null pointer check removed

[david.bolvansky at gmail dot com]

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

--- Comment #16 from Dávid Bolvanský  ---
For -O3 it is okay, but for -O2 this is questionable

[Bug tree-optimization/90949] [9 Regression] null pointer check removed

[pinskia at gcc dot gnu.org]

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

--- Comment #15 from Andrew Pinski  ---
(In reply to Dávid Bolvanský from comment #14)
> Since 10.1, gcc does crazy things with bloaty codegen for this case
> 
> https://godbolt.org/z/Qb3yHZ

It is called recursive inlining.  Not really bloated.

[Bug tree-optimization/95353] [10/11 Regression] spurious -Wstringop-overflow writing to a trailing array plus offset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #9 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547124.html

[PATCH] avoid false positives due to compute_objsize (PR 95353)

[Martin Sebor via Gcc-patches]

The compute_objsize() function started out as a thin wrapper around
compute_builtin_object_size(), but over time developed its own
features to compensate for the other function's limitations (such
as its inability to work with ranges).  The interaction of these
features and the limitations has started to become increasingly
problematic as the former function is used in more contexts.

A complete "fix" for all the problems (as well as some other
limitations) that I'm working on will be more extensive and won't
be appropriate for backports.  Until then, the attached patch
cleans up the extensions compute_objsize() has accumulated over
the years to avoid a class of false positives.

To make the warnings issued based on the results of the function
easier to understand and fix, the patch also adds an informative
message to many instances of -Wstringop-overflow to point to
the object to which the warning refers.  This is especially
helpful when the object is referenced by a series of pointer
operations.

Tested by boostrapping on x86_64-linux and building Binutils/GDB,
Glibc, and the Linux kernel with no new warnings.

Besides applying it to trunk I'm looking to backport the fix to
GCC 10.

Martin
PR middle-end/95353 - spurious -Wstringop-overflow writing to a trailing array plus offset
PR middle-end/92939 - missing -Wstringop-overflow on negative index from the end of array

gcc/ChangeLog:

	PR middle-end/95353
	PR middle-end/92939
	* builtins.c (inform_access): New function.
	(check_access): Call it.  Add argument.
	(addr_decl_size): Remove.
	(get_range): New function.
	(compute_objsize): New overload.  Only use compute_builtin_object_size
	with raw memory function.
	(check_memop_access): Pass new argument to compute_objsize and
	check_access.
	(expand_builtin_memchr, expand_builtin_strcat): Same.
	(expand_builtin_strcpy, expand_builtin_stpcpy_1): Same.
	(expand_builtin_stpncpy, check_strncat_sizes): Same.
	(expand_builtin_strncat, expand_builtin_strncpy): Same.
	(expand_builtin_memcmp): Same.
	* builtins.h (check_nul_terminated_array): Declare extern.
	(check_access): Add argument.
	(struct access_ref, struct access_data): New structs.
	* gimple-ssa-warn-restrict.c (clamp_offset): New helper.
	(builtin_access::overlap): Call it.
	* tree-object-size.c ((decl_init_size): Declare extern.
	(addr_object_size): Correct offset computation.
	* tree-object-size.h (decl_init_size): Declare.
	* tree-ssa-strlen.c (handle_integral_assign): Remove a call
	to maybe_warn_overflow when assigning to an SSA_NAME.

gcc/testsuite/ChangeLog:

	PR middle-end/95353
	PR middle-end/92939
	* c-c++-common/Wstringop-truncation.c: Remove an xfail.
	* gcc.dg/Warray-bounds-46.c: Remove a bogus warning.
	* gcc.dg/Wrestrict-9.c: Disable -Wstringop-overflow.
	* gcc.dg/Wstringop-overflow-12.c: Remove xfails.
	* gcc.dg/Wstringop-overflow-28.c: Same.
	* gcc.dg/builtin-stringop-chk-4.c: Same.
	* gcc.dg/builtin-stringop-chk-5.c: Same.
	* gcc.dg/builtin-stringop-chk-8.c: Same.
	* gcc.dg/strlenopt-74.c: Avoid buffer overflow.
	* gcc.dg/Wstringop-overflow-33.c: New test.
	* gcc.dg/Wstringop-overflow-34.c: New test.
	* gcc.dg/Wstringop-overflow-35.c: New test.
	* gcc.dg/Wstringop-overflow-36.c: New test.
	* gcc.dg/Wstringop-overflow-37.c: New test.

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 53bae599d3e..ae2ed974e57 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -3310,6 +3310,130 @@ determine_block_size (tree len, rtx len_rtx,
 			  GET_MODE_MASK (GET_MODE (len_rtx)));
 }
 
+/* Issue an inform message describing the target of an access REF.
+   WRITE is set for a write access and clear for a read access.  */
+
+static void
+inform_access (const access_ref , bool write)
+{
+  if (!ref.ref)
+return;
+
+  /* Convert offset range and avoid including a zero range since it isn't
+ necessarily meaningful.  */
+  long long minoff = 0, maxoff = 0;
+  if (wi::fits_shwi_p (ref.offrng[0])
+  && wi::fits_shwi_p (ref.offrng[1]))
+{
+  minoff = ref.offrng[0].to_shwi ();
+  maxoff = ref.offrng[1].to_shwi ();
+}
+
+  /* Convert size range and always include it since all sizes are
+ meaningful. */
+  unsigned long long minsize = 0, maxsize = 0;
+  if (wi::fits_shwi_p (ref.sizrng[0])
+  && wi::fits_shwi_p (ref.sizrng[1]))
+{
+  minsize = ref.sizrng[0].to_shwi ();
+  maxsize = ref.sizrng[1].to_shwi ();
+}
+
+  char sizestr[80];
+  location_t loc;
+  tree allocfn = NULL_TREE;
+  if (TREE_CODE (ref.ref) == SSA_NAME)
+{
+  gimple *stmt = SSA_NAME_DEF_STMT (ref.ref);
+  gcc_assert (is_gimple_call (stmt));
+  loc = gimple_location (stmt);
+  allocfn = gimple_call_fndecl (stmt);
+  if (!allocfn)
+	/* Handle calls through pointers to functions.  */
+	allocfn = gimple_call_fn (stmt);
+
+  /* SIZRNG doesn't necessarily have the same range as the allocation
+	 size determined by gimple_call_alloc_size ().  */
+
+  if (minsize == maxsize)
+	sprintf (sizestr, "%llu", minsize);
+  

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

[Segher Boessenkool]

Hi Arseny,

On Mon, Jun 01, 2020 at 10:38:16AM +0700, Arseny Solokha wrote:
> > PRs from the second group were filed by me, so if there's consensus to 
> > close all
> > of them, the ones from this second group I can close myself. I don't 
> > have the
> > right permissions to modify PRs reported by someone else, so I'd like 
> > to ask a
> > volunteer to step up and close the ones from the first group.
> >
> > WDYT?
> 
>  I can do both, if you want, or just the first group?  Your choice.
> 
>  But let's hear other opinions first.
> >>>
> >>> Thanks. I think I'll close the second group myself, as they constitute 
> >>> almost
> >>> half of the total amount.
> >>
> >> Okido, thanks!
> >
> > Two full weeks have passed without any new input from either former port
> > maintainer or global maintainers, so it's probably about time to go ahead 
> > and
> > wrap it up.
> 
> Segher, ping?

I have closed them all now (with your message, thanks for that, and
thanks for your other work on this!)

This all took "a while", but it is all finished now.


Segher

[Bug other/60158] powerpc: usage of the .data.rel.ro.local section

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Segher Boessenkool  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/52927] "procps" do not work with -Os flag.

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 CC||segher at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #10 from Segher Boessenkool  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/86133] powerpc (-mcpu=8548) internal compiler error for double variables

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Segher Boessenkool  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug tree-optimization/90949] [9 Regression] null pointer check removed

[david.bolvansky at gmail dot com]

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

Dávid Bolvanský  changed:

   What|Removed |Added

 CC||david.bolvansky at gmail dot 
com

--- Comment #14 from Dávid Bolvanský  ---
Since 10.1, gcc does crazy things with bloaty codegen for this case

https://godbolt.org/z/Qb3yHZ

[Bug target/71012] ICE: in expand_expr_real_2, at expr.c:9348 when compiling stress-ng

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Segher Boessenkool  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/57872] ICE occurs for cross-compile of PPC target with e500v2 core

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Segher Boessenkool  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug debug/57389] ICE in dbx_reg_number, at dwarf2out.c:10507 on powerpc-spe target

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #8 from Segher Boessenkool  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug rtl-optimization/51905] ICE at sysklogd compilation for powerpc-linux-gnuspe with -O3

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 CC||segher at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Segher Boessenkool  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/49854] Clean up SPE/e500 option handling

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/47977] powerpc (-mcpu=8548) Wrong code for double operations in little endian mode

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX
 CC||segher at gcc dot gnu.org

--- Comment #5 from Segher Boessenkool  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/47856] PowerPC: Wrong assembler output with -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double -mspe -mabi=spe

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX
 CC||segher at gcc dot gnu.org

--- Comment #3 from Segher Boessenkool  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/37760] internal compiler error: in extract_insn, at recog.c:1990

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED
 CC||segher at gcc dot gnu.org

--- Comment #4 from Segher Boessenkool  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/37759] powerpc option -mabi=no-spe still generates SPE instructions

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/30370] [4.1 regression] Build failure in libgcc2 powitf2 with ICE in gen_reg_rtx

[segher at gcc dot gnu.org]

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

Bug 30259 Summary: ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

[Bug target/30259] ICE on valid code

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #6 from Segher Boessenkool  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/19490] PowerPC back end ignores SPE command-line options

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|ASSIGNED|RESOLVED
 CC||segher at gcc dot gnu.org

--- Comment #1 from Segher Boessenkool  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

Re: [PATCH] rs6000: Use REAL_TYPE to copy when block move array in structure[PR65421]

[Segher Boessenkool]

On Tue, Jun 02, 2020 at 04:56:49PM -0400, David Edelsohn wrote:
> > > +  if (TREE_CODE (type) == RECORD_TYPE
> > > +  && rs6000_discover_homogeneous_aggregate (TYPE_MODE (type), type, 
> > > NULL,
> > > + NULL))
> > > +{
> > > +  tree field_type = TREE_TYPE (first_field (type));
> > > +  if (field_type && TREE_CODE (field_type) == ARRAY_TYPE
> > > +   && TREE_CODE (TREE_TYPE (field_type)) == REAL_TYPE)
> > > + elt_mode = TYPE_MODE (TREE_TYPE (field_type));
> > > +}
> >
> > Homogeneous aggregates only exist in the ELFv2 ABI, while the problem
> > here is the SP float things.  You also noticed (elsewhere) that if the
> > struct contains (say) SI, SF, SI, SF, then this does not help.
> >
> > Is there some better condition this could use, and maybe an expansion
> > that works in more cases as well?
> >
> > And, it would be lovely if generic code could expand to something better
> > already (not expand to a block move at all, certainly not for something
> > as tiny as this).
> 
> And please don't refer to homogeneous aggregates outside of ELFv2 ABI
> code because that will miss an optimization or generate incorrect code
> other PowerPC OSes and ABIs, such as AIX.

Yes, rs6000_discover_homogeneous_aggregate always returns false if some
other ABI is in use, which means for this particular code that the
problem isn't solved for those other ABIs at all.


Segher

[Bug c++/95486] New: ICE for alias CTAD with non-dependent argument and constrained constructor

[johelegp at gmail dot com]

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

Bug ID: 95486
   Summary: ICE for alias CTAD with non-dependent argument and
constrained constructor
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/cPWdGW.
```C++
template
concept Auto = true;

template
struct X { constexpr X(const Auto auto) {} };

template
using Y = X;

constexpr Y y{1};
```

[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from David Malcolm  ---
Should be fixed by the above commit.

[committed] jit: fix __builtin_unreachable [PR 95426]

[David Malcolm via Gcc-patches]

PR jit/95426 reports a crash deep inside "expand" when using
__builtin_unreachable via gcc_jit_context_get_builtin_function,
due to BLOCK_FOR_INSN being erroneously used on a barrier within
rtl_verify_bb_pointers.

The root cause turns out to be that I didn't implement
LANG_HOOKS_COMMON_ATTRIBUTE_TABLE and LANG_HOOKS_FORMAT_ATTRIBUTE_TABLE
for the jit "frontend".  When building a decl for the builtin, the
libgccjit frontend generates a chain of attributes names, but when
this is passed to decl_attributes and the attributes are looked up by
namespace and name within lookup_scoped_attribute_spec, attributes_table
is empty.  Hence no attributes were being associated with the fndecl,
and so ECF_NORETURN was not set on the gimple_call (along with various
other flags missing on the decl, etc), and so the call is treated as
not terminating its BB, and so the CFG rapidly diverges from the
equivalent created by the C frontend.

This patch fixes things by implementing these langhooks, copying the
minimal attribute-handling code from LTO.  I stepped through the
creation of the fndecl and verified that with this fix it has the same
attributes as the equivalent created by the C frontend.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-839-g44564c4c811f4751daf363ca019a9f9bed702f4f.

gcc/jit/ChangeLog:
PR jit/95426
* dummy-frontend.c: Include "options.h", "stringpool.h", and
"attribs.h".
(ATTR_EXCL): New, copied from lto/lto-lang.c.
(attr_noreturn_exclusions): Likewise.
(attr_returns_twice_exclusions): Likewise.
(attr_const_pure_exclusions): Likewise.
(jit_attribute_table): Likewise, copied from lto_attribute_table.
(jit_format_attribute_table): Likewise, copied from
lto_format_attribute_table.
(handle_noreturn_attribute): New, copied from lto/lto-lang.c.
(handle_leaf_attribute): Likewise.
(handle_const_attribute): Likewise.
(handle_malloc_attribute): Likewise.
(handle_pure_attribute): Likewise.
(handle_novops_attribute): Likewise.
(get_nonnull_operand): Likewise.
(handle_nonnull_attribute): Likewise.
(handle_nothrow_attribute): Likewise.
(handle_sentinel_attribute): Likewise.
(handle_type_generic_attribute): Likewise.
(handle_transaction_pure_attribute): Likewise.
(handle_returns_twice_attribute): Likewise.
(handle_patchable_function_entry_attribute): Likewise.
(ignore_attribute): Likewise.
(handle_format_attribute): Likewise.
(handle_format_arg_attribute): Likewise.
(handle_fnspec_attribute): Likewise.
(LANG_HOOKS_COMMON_ATTRIBUTE_TABLE): Define.
(LANG_HOOKS_FORMAT_ATTRIBUTE_TABLE): Define.

gcc/testsuite/ChangeLog:
PR jit/95426
* jit.dg/all-non-failing-tests.h: Add note about...
* jit.dg/test-builtin-unreachable.c: New test.
---
 gcc/jit/dummy-frontend.c  | 460 +-
 gcc/testsuite/jit.dg/all-non-failing-tests.h  |   3 +
 .../jit.dg/test-builtin-unreachable.c |  49 ++
 3 files changed, 511 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/jit.dg/test-builtin-unreachable.c

diff --git a/gcc/jit/dummy-frontend.c b/gcc/jit/dummy-frontend.c
index 6c7b7992a4d..aa64a6eb7a0 100644
--- a/gcc/jit/dummy-frontend.c
+++ b/gcc/jit/dummy-frontend.c
@@ -26,10 +26,462 @@ along with GCC; see the file COPYING3.  If not see
 #include "langhooks.h"
 #include "langhooks-def.h"
 #include "diagnostic.h"
-
+#include "options.h"
+#include "stringpool.h"
+#include "attribs.h"
 
 #include 
 
+/* Attribute handling.  */
+
+static tree handle_noreturn_attribute (tree *, tree, tree, int, bool *);
+static tree handle_leaf_attribute (tree *, tree, tree, int, bool *);
+static tree handle_const_attribute (tree *, tree, tree, int, bool *);
+static tree handle_malloc_attribute (tree *, tree, tree, int, bool *);
+static tree handle_pure_attribute (tree *, tree, tree, int, bool *);
+static tree handle_novops_attribute (tree *, tree, tree, int, bool *);
+static tree handle_nonnull_attribute (tree *, tree, tree, int, bool *);
+static tree handle_nothrow_attribute (tree *, tree, tree, int, bool *);
+static tree handle_sentinel_attribute (tree *, tree, tree, int, bool *);
+static tree handle_type_generic_attribute (tree *, tree, tree, int, bool *);
+static tree handle_transaction_pure_attribute (tree *, tree, tree, int, bool 
*);
+static tree handle_returns_twice_attribute (tree *, tree, tree, int, bool *);
+static tree handle_patchable_function_entry_attribute (tree *, tree, tree,
+  int, bool *);
+static tree ignore_attribute (tree *, tree, tree, int, bool *);
+
+static tree handle_format_attribute (tree *, tree, tree, int, bool *);
+static tree handle_fnspec_attribute (tree *, tree, tree, int, bool *);
+static tree handle_format_arg_attribute (tree *, 

[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:44564c4c811f4751daf363ca019a9f9bed702f4f

commit r11-839-g44564c4c811f4751daf363ca019a9f9bed702f4f
Author: David Malcolm 
Date:   Sun May 31 13:28:41 2020 -0400

jit: fix __builtin_unreachable [PR 95426]

PR jit/95426 reports a crash deep inside "expand" when using
__builtin_unreachable via gcc_jit_context_get_builtin_function,
due to BLOCK_FOR_INSN being erroneously used on a barrier within
rtl_verify_bb_pointers.

The root cause turns out to be that I didn't implement
LANG_HOOKS_COMMON_ATTRIBUTE_TABLE and LANG_HOOKS_FORMAT_ATTRIBUTE_TABLE
for the jit "frontend".  When building a decl for the builtin, the
libgccjit frontend generates a chain of attributes names, but when
this is passed to decl_attributes and the attributes are looked up by
namespace and name within lookup_scoped_attribute_spec, attributes_table
is empty.  Hence no attributes were being associated with the fndecl,
and so ECF_NORETURN was not set on the gimple_call (along with various
other flags missing on the decl, etc), and so the call is treated as
not terminating its BB, and so the CFG rapidly diverges from the
equivalent created by the C frontend.

This patch fixes things by implementing these langhooks, copying the
minimal attribute-handling code from LTO.  I stepped through the
creation of the fndecl and verified that with this fix it has the same
attributes as the equivalent created by the C frontend.

gcc/jit/ChangeLog:
PR jit/95426
* dummy-frontend.c: Include "options.h", "stringpool.h", and
"attribs.h".
(ATTR_EXCL): New, copied from lto/lto-lang.c.
(attr_noreturn_exclusions): Likewise.
(attr_returns_twice_exclusions): Likewise.
(attr_const_pure_exclusions): Likewise.
(jit_attribute_table): Likewise, copied from lto_attribute_table.
(jit_format_attribute_table): Likewise, copied from
lto_format_attribute_table.
(handle_noreturn_attribute): New, copied from lto/lto-lang.c.
(handle_leaf_attribute): Likewise.
(handle_const_attribute): Likewise.
(handle_malloc_attribute): Likewise.
(handle_pure_attribute): Likewise.
(handle_novops_attribute): Likewise.
(get_nonnull_operand): Likewise.
(handle_nonnull_attribute): Likewise.
(handle_nothrow_attribute): Likewise.
(handle_sentinel_attribute): Likewise.
(handle_type_generic_attribute): Likewise.
(handle_transaction_pure_attribute): Likewise.
(handle_returns_twice_attribute): Likewise.
(handle_patchable_function_entry_attribute): Likewise.
(ignore_attribute): Likewise.
(handle_format_attribute): Likewise.
(handle_format_arg_attribute): Likewise.
(handle_fnspec_attribute): Likewise.
(LANG_HOOKS_COMMON_ATTRIBUTE_TABLE): Define.
(LANG_HOOKS_FORMAT_ATTRIBUTE_TABLE): Define.

gcc/testsuite/ChangeLog:
PR jit/95426
* jit.dg/all-non-failing-tests.h: Add note about...
* jit.dg/test-builtin-unreachable.c: New test.

Re: [PATCH] Add pattern for pointer-diff on addresses with same base/offset (PR 94234)

[Marc Glisse]

On Mon, 1 Jun 2020, Feng Xue OS via Gcc-patches wrote:


* match.pd ((PTR + A) - (PTR + B)) -> (ptrdiff_t)(A - B): New
simplification.


Not new, modified.


* ((PTR_A + O) - (PTR_B + O)) -> (PTR_A - PTR_B): New simplification.


O might not be the best choice because of how close it looks to 0.


-   (simplify
-(pointer_diff (pointer_plus @@0 @1) (pointer_plus @0 @2))
-/* The second argument of pointer_plus must be interpreted as signed, and
-   thus sign-extended if necessary.  */
-(with { tree stype = signed_type_for (TREE_TYPE (@1)); }
- /* Use view_convert instead of convert here, as POINTER_PLUS_EXPR
-   second arg is unsigned even when we need to consider it as signed,
-   we don't want to diagnose overflow here.  */
- (minus (convert (view_convert:stype @1))
-   (convert (view_convert:stype @2)))
+  (simplify
+   (pointer_diff (pointer_plus@3 @0 @1) (pointer_plus @0 @2))
+(if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@3)))
+  (convert (minus @1 @2


What don't you like about the existing transformation? You are replacing a 
transformation that always folds by one that folds only in some cases, and 
looses the information that some overflows cannot happen. That looks like 
it is making things worse from an optimization point of view. Do you 
consider the transformation as unsafe with -fsanitize=pointer-overflow 
(does that correspond to the case where TYPE_OVERFLOW_UNDEFINED is true 
for a pointer type?)?


Ah, looking at the PR, you decided to perform the operation as unsigned 
because that has fewer NOP conversions, which, in that particular testcase 
where the offsets are originally unsigned, means we simplify better. But I 
would expect it to regress other testcases (in particular if the offsets 
were originally signed). Also, changing the second argument of 
pointer_plus to be signed, as is supposed to eventually happen, would 
break your testcase again.


At the very least we want to keep a comment next to the transformation 
explaining the situation.


If there are platforms where the second argument of pointer_plus is a 
smaller type than the result of pointer_diff (can this happen? I keep 
forgetting all the weird things some platforms do), this version may do an 
unsafe zero-extension.


I think I would rather try to extend the transformation for A*C-B*C.


+  (simplify
+   (pointer_diff (pointer_plus@3 @0 @2) (pointer_plus @1 @2))
+(if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@3))
+&& !integer_zerop (@2))
+ (pointer_diff @0 @1)


Why would it be a problem if @2 is 0? We should have already simplified 
(pointer_plus @i integer_zerop) to just @i before reaching this, but it 
doesn't make the transformation wrong.


Same remark as above for TYPE_OVERFLOW_UNDEFINED, is that for the sake of 
-fsanitize=pointer-overflow?


--
Marc Glisse

[Bug middle-end/95236] OMP 'GOMP_MAP_STRUCT': a structure is more than the sum of all its fields?

[julian at codesourcery dot com]

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

--- Comment #1 from julian at codesourcery dot com ---
On Wed, 20 May 2020 10:42:23 +
"tschwinge at gcc dot gnu.org"  wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95236
> 
> Bug ID: 95236
>Summary: OMP 'GOMP_MAP_STRUCT': a structure is more than
> the sum of all its fields?
>Product: gcc
>Version: 10.0
> Status: UNCONFIRMED
>   Keywords: openacc, openmp
>   Severity: normal
>   Priority: P3
>  Component: middle-end
>   Assignee: unassigned at gcc dot gnu.org
>   Reporter: tschwinge at gcc dot gnu.org
> CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
>   Target Milestone: ---
> 
> Created attachment 48571
>   -->
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48571=edit
> 'itu_.c'
> 
> ..., and the answer (technically) may easily be "yes", considering
> ABI-mandated padding, for example.
> 
> But: is that user friendly?  Consider the test case I'm attaching,
> where 'struct s' consists of fields 'a', 'b', which both get mapped
> -- yet, 's' itself isn't considered to be.  At the user level, should
> a structure equal the sum of all its fields, or "do we have to be
> complicated"?
> 
> I have not fully thought that through, just noticed this when looking
> into something else.  I also have not verified OpenMP behavior.

The ability to partially copy the struct to the target is deliberate
(and inherited from the OpenMP implementation) since the struct could
potentially be large, and the user might not need all of it on the
target. That's hand-wavingly similar to the ability to copy just a
slice of an array to the target, rather than the whole thing (except an
array slice covering the whole array *is* in fact the array, so will
show as present as such). I'm not sure we'd want to lose the ability to
do such partial mappings for structs.

I suppose the ideal -- which we don't entirely meet, because sometimes
"present(...)" mappings are needed -- is for arrays in structs to behave
the same as arrays which are not in structs, from the user perspective,
without extra cognitive load. So these examples should work the same:

int main(void)
{
  int *a = malloc (sizeof (int) * N));
  int *b = malloc (sizeof (int) * N));

  #pragma acc parallel copy(a[0:N], b[0:N])
  {
a[x] = ...;
b[y] = ...;
  }
}

vs:

int main(void)
{
  struct {
int *a;
int *b;
  } mystruct;

  mystruct s;

  s.a = malloc (sizeof (int) * N);
  s.b = malloc (sizeof (int) * N):

  #pragma acc parallel copy(s.a[0:N], s.b[0:N])
  {
s.a[x] = ...;
s.b[y] = ...;
  }
}

The problem (from an implementation perspective) of an implicit
"copy(s)" not working in your example, or if the above code is
modified like this:

  #pragma acc data copy(s.a[0:N], s.b[0:N])
  {
#pragma acc parallel
{
  s.a[x] = ...;
  s.b[y] = ...;
}
  }

is that s.a and s.b are mapped as separate splay tree keys, and
the implicit (or an explicit) "present(s)" has no way of union'ing those
together to test if the whole struct is mapped. Maybe that could be
solved as part of support for allowing multiple slices of the same
array to be mapped at once, if or when we want to support that.

Thanks,

Julian

Re: sign_and_send_pubkey: signing failed: agent refused operation

[Martin Sebor via Gcc]

On 6/2/20 2:43 PM, Jonathan Wakely wrote:

On Tue, 2 Jun 2020 at 21:26, Martin Sebor  wrote:


On 6/1/20 1:12 PM, Jonathan Wakely via Overseers wrote:

On Mon, 1 Jun 2020 at 19:11, Frank Ch. Eigler via Gcc  wrote:


Hi -


git pull from the GCC and Glibc repos is failing for me with the error
below.  It worked fine last week and I haven't made any changes to my
ssh keys.


And are you logging in from the same workstation with access to the same
set of ssh private keys?


Is this a transient glitch or has something changed recently that I
need to make some adjustments for?


I know of nothing relevant that has changed on the sourceware side.


sign_and_send_pubkey: signing failed: agent refused operation
mse...@gcc.gnu.org: Permission denied (publickey).
fatal: Could not read from remote repository.


The usual advice is to run   % ssh -vv gcc.gnu.org alive
and report the ssh level error.

"agent refused operation" sounds like a problem on the client end.


Yes, it is. "agent" refers to the ssh-agent program.

Martin, what does 'ssh-add -l' show?

Is there only one ssh-agent process shown by 'ps -ef | fgrep
[s]sh-agent'? Does its PID match $SSH_AGENT_PID?

Another possible cause is that the file permissions are not strict
enough on the private key, or on the ~/.ssh directory that contains
it. Key files should be 600 and ~/.ssh should be 700.


We solved the problem over IRC last night so just to close the loop
on it here: it turned out to be caused by Gnome keyring setting
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh.  With the environment
variable undefined I get prompted for the password as expected.


But that just means you're not using an agent, right?


It just means I know what's causing the problem.  Until just
now I haven't thought about how to deal with it in a smarter
way than by remembering to run ssh-add either first, or when
I see the error.



Do you really want to enter a passphrase every time you connect to gcc.gnu.org?


Ideally, I'd prefer never to have to enter it but until that
happy day comes I'll settle for just typing it in once a day.



Solving it by the GNOME keyring would match Jim's suggestion that the
GNOME keyring won't use your key.

You could generate a new 4K key that GNOME keyring will accept, upload
the public key to gcc.gnu.org, and use that instead. Then you could
use the keyring as your agent.


I just saw Jim's email.  I'll see if going to 4k keys works.

Thanks
Martin

[PATCH] c++: more constrained nested partial specialization

[Patrick Palka via Gcc-patches]

When checking that a constrained partial specialization is more
constrained than the primary template, we pass only the innermost level
of generic template arguments to strictly_subsumes.  This leads to us
doing a nonsensical substitution from normalize_concept_check if the
full set of template arguments has multiple levels, and it causes
strictly_subsumes to sometimes erroneously return false as in the
testcase below.

Passes 'make check-c++' and also tested by building the testsuites of
cmcstl2 and range-v3.  Does this look OK to commit to mainline and to
the 10 branch after a full bootstrap and regtest?

(We shouldn't need to do any substitution from strictly_subsumes here,
since processing_template_decl would always be non-zero and so
substituting in the complete set of generic template arguments should
always be a no-op I think.  I can propose this as a subsequent patch for
mainline.)

gcc/cp/ChangeLog:

* pt.c (process_partial_specialization): Pass the full set of
generic template arguments to strictly_subsumes.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-partial-spec8.C: New test.
---
 gcc/cp/pt.c|  2 +-
 .../g++.dg/cpp2a/concepts-partial-spec8.C  | 14 ++
 2 files changed, 15 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec8.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index df92f5584cf..d7f61289621 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -5062,7 +5062,7 @@ process_partial_specialization (tree decl)
   if (comp_template_args (inner_args, INNERMOST_TEMPLATE_ARGS (main_args))
   && (!flag_concepts
  || !strictly_subsumes (current_template_constraints (),
-inner_args, maintmpl)))
+main_args, maintmpl)))
 {
   if (!flag_concepts)
 error ("partial specialization %q+D does not specialize "
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec8.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec8.C
new file mode 100644
index 000..873cf44e407
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec8.C
@@ -0,0 +1,14 @@
+// { dg-do compile { target c++20 } }
+
+template
+concept equal = M == N;
+
+template
+struct traits
+{
+  template requires equal
+struct foo {};
+
+  template requires equal && (M >= 0) // { dg-bogus "not more 
constrained" }
+struct foo {};
+};
-- 
2.27.0.rc1.5.gae92ac8ae3

[PATCH] rs6000: identify lfs prefixed case PR95347

[Aaron Sawdey via Gcc-patches]

The same problem also arises for plfs where prefixed_load_p()
doesn't recognize it so we get just lfs in the asm output
with a @pcrel address.

OK for trunk if regstrap on ppc64le passes?

Thanks,
   Aaron


PR target/95347
* config/rs6000/rs6000.c (is_stfs_insn): Rename to
is_lfs_stfs_insn and make it recognize lfs as well.
(prefixed_store_p): Use is_lfs_stfs_insn().
(prefixed_load_p): Use is_lfs_stfs_insn() to recognize lfs.
---
 gcc/config/rs6000/rs6000.c | 41 +++---
 1 file changed, 29 insertions(+), 12 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index ba9069ecc3b..8ed8ae04e7a 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -24980,14 +24980,18 @@ address_to_insn_form (rtx addr,
   return INSN_FORM_BAD;
 }
 
-/* Helper function to see if we're potentially looking at stfs.
+/* Helper function to see if we're potentially looking at lfs/stfs.
- PARALLEL containing a SET and a CLOBBER
-   - SET is from UNSPEC_SI_FROM_SF to MEM:SI
-   - CLOBBER is a V4SF
+   - stfs:
+- SET is from UNSPEC_SI_FROM_SF to MEM:SI
+- CLOBBER is a V4SF
+   - lfs:
+- SET is from UNSPEC_SF_FROM_SI to REG:SF
+- CLOBBER is a DI
  */
 
 static bool
-is_stfs_insn (rtx_insn *insn)
+is_lfs_stfs_insn (rtx_insn *insn)
 {
   rtx pattern = PATTERN (insn);
   if (GET_CODE (pattern) != PARALLEL)
@@ -25013,16 +25017,22 @@ is_stfs_insn (rtx_insn *insn)
   rtx src = SET_SRC (set);
   rtx scratch = SET_DEST (clobber);
 
-  if (GET_CODE (src) != UNSPEC || XINT (src, 1) != UNSPEC_SI_FROM_SF)
+  if (GET_CODE (src) != UNSPEC)
 return false;
 
-  if (GET_CODE (dest) != MEM || GET_MODE (dest) != SImode)
-return false;
+  /* stfs case.  */
+  if (XINT (src, 1) == UNSPEC_SI_FROM_SF
+  && GET_CODE (dest) == MEM && GET_MODE (dest) == SImode
+  && GET_CODE (scratch) == SCRATCH && GET_MODE (scratch) == V4SFmode)
+return true;
 
-  if (GET_CODE (scratch) != SCRATCH || GET_MODE (scratch) != V4SFmode)
-return false;
+  /* lfs case.  */
+  if (XINT (src, 1) == UNSPEC_SF_FROM_SI
+  && GET_CODE (dest) == REG && GET_MODE (dest) == SFmode
+  && GET_CODE (scratch) == SCRATCH && GET_MODE (scratch) == DImode)
+return true;
 
-  return true;
+  return false;
 }
 
 /* Helper function to take a REG and a MODE and turn it into the non-prefixed
@@ -25135,7 +25145,14 @@ prefixed_load_p (rtx_insn *insn)
   else
 non_prefixed = reg_to_non_prefixed (reg, mem_mode);
 
-  return address_is_prefixed (XEXP (mem, 0), mem_mode, non_prefixed);
+  fprintf(stderr,"prefixed_load_p regmode %s memmode %s non_prefixed %d\n",
+ GET_MODE_NAME(reg_mode), GET_MODE_NAME(mem_mode), non_prefixed);
+  debug_rtx(insn);
+
+  if (non_prefixed == NON_PREFIXED_X && is_lfs_stfs_insn (insn))
+return address_is_prefixed (XEXP (mem, 0), mem_mode, NON_PREFIXED_DEFAULT);
+  else
+return address_is_prefixed (XEXP (mem, 0), mem_mode, non_prefixed);
 }
 
 /* Whether a store instruction is a prefixed instruction.  This is called from
@@ -25170,7 +25187,7 @@ prefixed_store_p (rtx_insn *insn)
   /* Need to make sure we aren't looking at a stfs which doesn't look
  like the other things reg_to_non_prefixed/address_is_prefixed
  looks for.  */
-  if (non_prefixed == NON_PREFIXED_X && is_stfs_insn (insn))
+  if (non_prefixed == NON_PREFIXED_X && is_lfs_stfs_insn (insn))
 return address_is_prefixed (addr, mem_mode, NON_PREFIXED_DEFAULT);
   else
 return address_is_prefixed (addr, mem_mode, non_prefixed);
-- 
2.17.1

Re: [PATCH] rs6000: Use REAL_TYPE to copy when block move array in structure[PR65421]

[David Edelsohn via Gcc-patches]

On Tue, Jun 2, 2020 at 4:32 PM Segher Boessenkool
 wrote:
>
> Hi Xiong Hu,
>
> On Tue, Jun 02, 2020 at 04:41:50AM -0500, Xionghu Luo wrote:
> > Double array in structure as function arguments or return value is accessed
> > by BLKmode, they are stored to stack and load from stack with redundant
> > conversion from DF->DI->DF.  This patch checks the homogeneous type and
> > use the actual element type to do block move to by pass the conversions.
>
> > @@ -2733,6 +2734,7 @@ expand_block_move (rtx operands[], bool might_overlap)
> >rtx loads[MAX_MOVE_REG];
> >rtx stores[MAX_MOVE_REG];
> >int num_reg = 0;
> > +  machine_mode elt_mode = DImode;
> >
> >/* If this is not a fixed size move, just call memcpy */
> >if (! constp)
> > @@ -2750,6 +2752,17 @@ expand_block_move (rtx operands[], bool 
> > might_overlap)
> >if (bytes > rs6000_block_move_inline_limit)
> >  return 0;
> >
> > +  tree type = TREE_TYPE (MEM_EXPR (orig_dest));
>
> Declare elt_mode here as well?
>
> > +  if (TREE_CODE (type) == RECORD_TYPE
> > +  && rs6000_discover_homogeneous_aggregate (TYPE_MODE (type), type, 
> > NULL,
> > + NULL))
> > +{
> > +  tree field_type = TREE_TYPE (first_field (type));
> > +  if (field_type && TREE_CODE (field_type) == ARRAY_TYPE
> > +   && TREE_CODE (TREE_TYPE (field_type)) == REAL_TYPE)
> > + elt_mode = TYPE_MODE (TREE_TYPE (field_type));
> > +}
>
> Homogeneous aggregates only exist in the ELFv2 ABI, while the problem
> here is the SP float things.  You also noticed (elsewhere) that if the
> struct contains (say) SI, SF, SI, SF, then this does not help.
>
> Is there some better condition this could use, and maybe an expansion
> that works in more cases as well?
>
> And, it would be lovely if generic code could expand to something better
> already (not expand to a block move at all, certainly not for something
> as tiny as this).

And please don't refer to homogeneous aggregates outside of ELFv2 ABI
code because that will miss an optimization or generate incorrect code
other PowerPC OSes and ABIs, such as AIX.

Thanks, David

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[andrew2085 at gmail dot com]

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

--- Comment #29 from Andrew Downing  ---
So I think this sort of equivalent example in C shows what's going wrong in the
C++ example. https://godbolt.org/z/ZMz4Cp

gcc knows that if the object mem points to is modified inside pun() its
effective type will change to the type of the value that is assigned because
the object mem points to has no declared type. If the argument to pun has a
declared type, the code doesn't work, like in the c++ example.

So for this c++ example https://godbolt.org/z/NeAJ5d could a solution be for
gcc to treat placement new as if it were a modifying access and as if it's
parameter had no declared type. So it would change the effective type of d in
f1 to uint64_t, or at least insert IL instructions to simulate that?

Re: sign_and_send_pubkey: signing failed: agent refused operation

[Jonathan Wakely via Gcc]

On Tue, 2 Jun 2020 at 21:26, Martin Sebor  wrote:
>
> On 6/1/20 1:12 PM, Jonathan Wakely via Overseers wrote:
> > On Mon, 1 Jun 2020 at 19:11, Frank Ch. Eigler via Gcc  
> > wrote:
> >>
> >> Hi -
> >>
> >>> git pull from the GCC and Glibc repos is failing for me with the error
> >>> below.  It worked fine last week and I haven't made any changes to my
> >>> ssh keys.
> >>
> >> And are you logging in from the same workstation with access to the same
> >> set of ssh private keys?
> >>
> >>> Is this a transient glitch or has something changed recently that I
> >>> need to make some adjustments for?
> >>
> >> I know of nothing relevant that has changed on the sourceware side.
> >>
> >>> sign_and_send_pubkey: signing failed: agent refused operation
> >>> mse...@gcc.gnu.org: Permission denied (publickey).
> >>> fatal: Could not read from remote repository.
> >>
> >> The usual advice is to run   % ssh -vv gcc.gnu.org alive
> >> and report the ssh level error.
> >>
> >> "agent refused operation" sounds like a problem on the client end.
> >
> > Yes, it is. "agent" refers to the ssh-agent program.
> >
> > Martin, what does 'ssh-add -l' show?
> >
> > Is there only one ssh-agent process shown by 'ps -ef | fgrep
> > [s]sh-agent'? Does its PID match $SSH_AGENT_PID?
> >
> > Another possible cause is that the file permissions are not strict
> > enough on the private key, or on the ~/.ssh directory that contains
> > it. Key files should be 600 and ~/.ssh should be 700.
>
> We solved the problem over IRC last night so just to close the loop
> on it here: it turned out to be caused by Gnome keyring setting
> SSH_AUTH_SOCK=/run/user/1000/keyring/ssh.  With the environment
> variable undefined I get prompted for the password as expected.

But that just means you're not using an agent, right?

Do you really want to enter a passphrase every time you connect to gcc.gnu.org?

Solving it by the GNOME keyring would match Jim's suggestion that the
GNOME keyring won't use your key.

You could generate a new 4K key that GNOME keyring will accept, upload
the public key to gcc.gnu.org, and use that instead. Then you could
use the keyring as your agent.

Re: [PATCH] rs6000: Use REAL_TYPE to copy when block move array in structure[PR65421]

[Segher Boessenkool]

Hi Xiong Hu,

On Tue, Jun 02, 2020 at 04:41:50AM -0500, Xionghu Luo wrote:
> Double array in structure as function arguments or return value is accessed
> by BLKmode, they are stored to stack and load from stack with redundant
> conversion from DF->DI->DF.  This patch checks the homogeneous type and
> use the actual element type to do block move to by pass the conversions.

> @@ -2733,6 +2734,7 @@ expand_block_move (rtx operands[], bool might_overlap)
>rtx loads[MAX_MOVE_REG];
>rtx stores[MAX_MOVE_REG];
>int num_reg = 0;
> +  machine_mode elt_mode = DImode;
>  
>/* If this is not a fixed size move, just call memcpy */
>if (! constp)
> @@ -2750,6 +2752,17 @@ expand_block_move (rtx operands[], bool might_overlap)
>if (bytes > rs6000_block_move_inline_limit)
>  return 0;
>  
> +  tree type = TREE_TYPE (MEM_EXPR (orig_dest));

Declare elt_mode here as well?

> +  if (TREE_CODE (type) == RECORD_TYPE
> +  && rs6000_discover_homogeneous_aggregate (TYPE_MODE (type), type, NULL,
> + NULL))
> +{
> +  tree field_type = TREE_TYPE (first_field (type));
> +  if (field_type && TREE_CODE (field_type) == ARRAY_TYPE
> +   && TREE_CODE (TREE_TYPE (field_type)) == REAL_TYPE)
> + elt_mode = TYPE_MODE (TREE_TYPE (field_type));
> +}

Homogeneous aggregates only exist in the ELFv2 ABI, while the problem
here is the SP float things.  You also noticed (elsewhere) that if the
struct contains (say) SI, SF, SI, SF, then this does not help.

Is there some better condition this could use, and maybe an expansion
that works in more cases as well?

And, it would be lovely if generic code could expand to something better
already (not expand to a block move at all, certainly not for something
as tiny as this).


Segher

Re: sign_and_send_pubkey: signing failed: agent refused operation

[Martin Sebor via Gcc]

On 6/1/20 1:12 PM, Jonathan Wakely via Overseers wrote:

On Mon, 1 Jun 2020 at 19:11, Frank Ch. Eigler via Gcc  wrote:


Hi -


git pull from the GCC and Glibc repos is failing for me with the error
below.  It worked fine last week and I haven't made any changes to my
ssh keys.


And are you logging in from the same workstation with access to the same
set of ssh private keys?


Is this a transient glitch or has something changed recently that I
need to make some adjustments for?


I know of nothing relevant that has changed on the sourceware side.


sign_and_send_pubkey: signing failed: agent refused operation
mse...@gcc.gnu.org: Permission denied (publickey).
fatal: Could not read from remote repository.


The usual advice is to run   % ssh -vv gcc.gnu.org alive
and report the ssh level error.

"agent refused operation" sounds like a problem on the client end.


Yes, it is. "agent" refers to the ssh-agent program.

Martin, what does 'ssh-add -l' show?

Is there only one ssh-agent process shown by 'ps -ef | fgrep
[s]sh-agent'? Does its PID match $SSH_AGENT_PID?

Another possible cause is that the file permissions are not strict
enough on the private key, or on the ~/.ssh directory that contains
it. Key files should be 600 and ~/.ssh should be 700.


We solved the problem over IRC last night so just to close the loop
on it here: it turned out to be caused by Gnome keyring setting
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh.  With the environment
variable undefined I get prompted for the password as expected.

Thank you both again for your help in getting to the bottom of it!

Martin

[Bug middle-end/95485] missing warning writing into function text

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-02
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90404
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #1 from Martin Sebor  ---
See also pr90404.  I'm working on a solution for that, and I expect it to
handle this as well.

[Bug target/84553] -rdynamic generates TEXTREL relocations on ia64

[wilson at gcc dot gnu.org]

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

--- Comment #7 from Jim Wilson  ---
I was ia64 maintainer when I wrote the patch, but couldn't test it.  I'm not
the ia64 maintainer anymore.  I suggest asking the current ia64 maintainer. 
Though, oops, I see we don't have one listed in the MAINTAINER file.  I thought
we had appointed one.  I'm a global maintainer, but that doesn't give me power
to approve my own patch for things I don't maintain anymore.  I'm hopelessly
overcommitted on RISC-V issues so unlikely to have time to do anything here.

Re: [PATCH] Extend std::copy/std::copy_n char* overload to deque iterator

[Jonathan Wakely via Gcc-patches]

On 24/05/20 15:43 +0200, François Dumont via Libstdc++ wrote:

Now tested in C++98 mode, there was indeed a small problem.

I even wonder if I shouldn't have extend the std::copy overload to any 
call with deque iterator as the output so that it is transform into an 
output to pointer.


Ok to commit ?





--- a/libstdc++-v3/include/debug/safe_iterator.tcc
+++ b/libstdc++-v3/include/debug/safe_iterator.tcc
@@ -234,6 +234,12 @@ namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION

+  template
+_Ite
+__niter_base(const ::__gnu_debug::_Safe_iterator<_Ite, _Seq,
+std::random_access_iterator_tag>& __it)
+{ return __it.base(); }
+


I was going to ask if there's a reason this uses "_Ite" and not
"_Iter", but I see we already have several uses of that.

Thy all seem to be introduced by you though :-)

We definitely have a lot more "_Iter" uses though:

$ git grep -w _Ite -- include/ | wc -l
46
$ git grep -w _Iter -- include/ | wc -l
835

When I see "Ite" it looks to me as though it should rhyme with "sight"
or "white", rather than "Iter" which rhymes with "bitter" (and so is
the start of "iterator").

Leave it as _Ite for now, I might go through and change every _Ite to
_Iter later.


OK for master, thanks.

[Bug middle-end/95485] missing warning writing into function text

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

[Bug middle-end/95485] New: missing warning writing into function text

[msebor at gcc dot gnu.org]

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

Bug ID: 95485
   Summary: missing warning writing into function text
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC doesn't diagnose attempts to write into functions, even though those will
in all likelihood crash with a SIGBUS at runtime.

For example, in the following snippet the destination of the memset call is a
function rather than the memory it was called to obtain.  The memset call
should be diagnosed.

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout z.c
typedef void* F (int);

void* f (F *p)
{
  void *q = p (32);  // allocate memory
  __builtin_memset (p, 0, 32);   // zero out -- whoops! -- writing to a
function
  return q;  // return "clear" memory
}

;; Function f (f, funcdef_no=0, decl_uid=1933, cgraph_uid=1, symbol_order=0)

f (void * (*) (int) p)
{
  void * q;

   [local count: 1073741824]:
  q_4 = p_2(D) (32);
  __builtin_memset (p_2(D), 0, 32);
  return q_4;

}


Two compilers on Godbolt diagnose the code: Visual C++:

z.c(8): warning C4152: nonstandard extension, function/data pointer conversion
in expression

and the Small Device C Compiler (SDCC):

x.c:8: warning 244: pointer types incompatible 
from type 'void generic* function ( int fixed) code* fixed'
  to type 'void generic* fixed'

Re: sign_and_send_pubkey: signing failed: agent refused operation

[Jim Wilson]

On Mon, Jun 1, 2020 at 3:33 PM Martin Sebor via Gcc  wrote:
> So it sounds like you wouldn't expect the "agent refused operation"
> error either, and it's not just a poor error message that I should
> learn to live with.  That makes me think I should try to figure out
> what's wrong.  I think the ~/.ssh/ contents are pretty standard:

My experience with Ubuntu 18.04 is that 2K bit keys aren't accepted by
something (gnome UI?) anymore.  I had to upgrade to 4K bit keys.
Though oddly ssh-keygen still generates 2K bit keys by default even
though they won't be accepted by the gnome UI (or whatever).  The work
around is to run ssh-add manually to register your 2K bit key, because
ssh-add will still accept 2K bit keys, and then ssh will work, and can
be used to install a 4K bit public key on the other side, and then
things will work normally again.  A web search suggested that there
was some security problem with 2K bit keys and apparently they are
trying to force people to upgrade, but the inconsistent approach here
between different packages makes this confusing as to what is actually
going on.

Jim

[PATCH] c++: constrained nested partial specialization [PR92103]

[Patrick Palka via Gcc-patches]

When determining the most specialized partial specialization of a
primary template that is nested inside a class template, we first
tsubst the outer template arguments into the TEMPLATE_DECL of each
partial specialization, and then check for satisfaction of the new
TEMPLATE_DECL's constraints.

But tsubst_template_decl does not currently guarantee that constraints
from the original DECL_TEMPLATE_RESULT get reattached to the new
DECL_TEMPLATE_RESULT.  In the testcase below, this leads to the
constraints_satisfied_p check in most_specialized_partial_spec to
trivially return true for each of the partial specializations.

I'm not sure if such a guarantee would be desirable, but in any case we
can just check constraints_satisfied_p on the original TEMPLATE_DECL
instead of on the tsubsted TEMPLATE_DECL here, which is what this patch
does (alongside some reorganizing).

Passes 'make check-c++' and also tested by building the testsuites of
cmcstl2 and range-v3.  Does this look OK to commit to mainline and to
the 10 branch after a full bootstrap and regtest?

gcc/cp/ChangeLog:

PR c++/92103
* pt.c (most_specialized_partial_spec): Reorganize the loop over
DECL_TEMPLATE_SPECIALIZATIONS.  Check constraints_satisfied_p on
the original template declaration, not on the substituted one.

gcc/testsuite/ChangeLog:

PR c++/92103
* g++.dg/cpp2a/concepts-partial-spec7.C: New test.
---
 gcc/cp/pt.c   | 19 
 .../g++.dg/cpp2a/concepts-partial-spec7.C | 22 +++
 2 files changed, 32 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec7.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 907ca879c73..df92f5584cf 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -24482,21 +24482,22 @@ most_specialized_partial_spec (tree target, 
tsubst_flags_t complain)
 
   for (t = DECL_TEMPLATE_SPECIALIZATIONS (main_tmpl); t; t = TREE_CHAIN (t))
 {
-  tree spec_args;
-  tree spec_tmpl = TREE_VALUE (t);
+  const tree ospec_tmpl = TREE_VALUE (t);
 
+  tree spec_tmpl;
   if (outer_args)
{
  /* Substitute in the template args from the enclosing class.  */
  ++processing_template_decl;
- spec_tmpl = tsubst (spec_tmpl, outer_args, tf_none, NULL_TREE);
+ spec_tmpl = tsubst (ospec_tmpl, outer_args, tf_none, NULL_TREE);
  --processing_template_decl;
+ if (spec_tmpl == error_mark_node)
+   return error_mark_node;
}
+  else
+   spec_tmpl = ospec_tmpl;
 
-  if (spec_tmpl == error_mark_node)
-   return error_mark_node;
-
-  spec_args = get_partial_spec_bindings (tmpl, spec_tmpl, args);
+  tree spec_args = get_partial_spec_bindings (tmpl, spec_tmpl, args);
   if (spec_args)
{
  if (outer_args)
@@ -24505,9 +24506,9 @@ most_specialized_partial_spec (tree target, 
tsubst_flags_t complain)
   /* Keep the candidate only if the constraints are satisfied,
  or if we're not compiling with concepts.  */
   if (!flag_concepts
-  || constraints_satisfied_p (spec_tmpl, spec_args))
+ || constraints_satisfied_p (ospec_tmpl, spec_args))
 {
-  list = tree_cons (spec_args, TREE_VALUE (t), list);
+ list = tree_cons (spec_args, ospec_tmpl, list);
   TREE_TYPE (list) = TREE_TYPE (t);
 }
}
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec7.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec7.C
new file mode 100644
index 000..5b3afce3bc7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec7.C
@@ -0,0 +1,22 @@
+// PR c++/92103
+// { dg-do compile { target c++20 } }
+
+template
+struct traits
+{
+  template
+struct equal_to
+{ static constexpr bool value = false; };
+
+  template requires (M == N)
+struct equal_to
+{ static constexpr bool value = true; };
+
+  template requires (M < 0) || (N < 0)
+struct equal_to
+{ };
+};
+
+static_assert(traits<0>::equal_to<0>::value);
+static_assert(!traits<0>::equal_to<1>::value);
+static_assert(traits<-1>::equal_to<0>::value); // { dg-error "not a member" }
-- 
2.27.0.rc1.5.gae92ac8ae3

[Bug c++/92103] constraints not checked on nested class template

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/95193] [11 Regression] ICE in tsubst_decl, at cp/pt.c:14624

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:4b68cb38ddca37a14a6f2f43de3a6d396ee1bc79

commit r11-838-g4b68cb38ddca37a14a6f2f43de3a6d396ee1bc79
Author: Jason Merrill 
Date:   Mon Jun 1 17:58:57 2020 -0400

c++: *this capture in const member fn [PR95193].

Here, the capture proxy for *this is const, but its DECL_VALUE_EXPR is not.
Don't ICE on this; it's a reasonable difference, since in C++ an rvalue of
scalar type does not have cv-qualifiers.

gcc/cp/ChangeLog:

PR c++/95193
* pt.c (tsubst_decl): Relax assert.

gcc/testsuite/ChangeLog:

PR c++/95193
* g++.dg/cpp1z/lambda-this7.C: New test.

[pushed] c++: *this capture in const member fn [PR95193].

[Jason Merrill via Gcc-patches]

Here, the capture proxy for *this is const, but its DECL_VALUE_EXPR is not.
Don't ICE on this; it's a reasonable difference, since in C++ an rvalue of
scalar type does not have cv-qualifiers.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

PR c++/95193
* pt.c (tsubst_decl): Relax assert.

gcc/testsuite/ChangeLog:

PR c++/95193
* g++.dg/cpp1z/lambda-this7.C: New test.
---
 gcc/cp/pt.c   |  3 ++-
 gcc/testsuite/g++.dg/cpp1z/lambda-this7.C | 11 +++
 2 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/lambda-this7.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 907ca879c73..9c03c5a5bbd 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -14633,7 +14633,8 @@ tsubst_decl (tree t, tree args, tsubst_flags_t complain)
 && DECL_BIT_FIELD_TYPE (TREE_OPERAND (ve, 1)) == type)
  type = TREE_TYPE (ve);
else
- gcc_checking_assert (TREE_TYPE (ve) == type);
+ gcc_checking_assert (TYPE_MAIN_VARIANT (TREE_TYPE (ve))
+  == TYPE_MAIN_VARIANT (type));
SET_DECL_VALUE_EXPR (r, ve);
  }
if (CP_DECL_THREAD_LOCAL_P (r)
diff --git a/gcc/testsuite/g++.dg/cpp1z/lambda-this7.C 
b/gcc/testsuite/g++.dg/cpp1z/lambda-this7.C
new file mode 100644
index 000..8137061e161
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/lambda-this7.C
@@ -0,0 +1,11 @@
+// PR c++/95193
+// { dg-do compile { target c++17 } }
+
+struct X {
+  void foo() const {
+auto GL1 = [*this](auto a) {
+};
+
+GL1("abc");
+  }
+};

base-commit: 4013baf99c38f7bca06a51f8301e8fb195ccfa33
-- 
2.18.1

[PATCH] FAT library support for libatomic, libgfortran, libgomp, libstdc++

[David Edelsohn via Gcc-patches]

[I'll start by repeating what I wrote about a similar libgcc change to
provide background and context.]

When AIX added 64 bit support, it implemented what Apple MacOS Darwin
calls "FAT" libraries for its equivalent functionality -- both 32 bit
and 64 bit objects (or shared objects) are co-located in the same
archive.  GCC on AIX historically has followed the GCC multilib
directory hierarchy approach with separate directories and archives
for each multilib.

We now are working to support GCC on AIX in 64 bit mode.  To retain
the directory hierarchy, it is beneficial to shift (or at least
initially augment) the GCC multilib mechanism with AIX-style "FAT"
libraries.

It is beneficial for the "FAT" libraries to be created consistently
for GCC in both 32 bit mode and 64 bit mode.  When all of the
libraries are converted, the multilib rules will look for 32 bit and
64 bit multilibs in the top-level library.  All target multilibs need
to be enabled at the same time, but the build can start the creation
of the "FAT" libraries without utilizing them.

The goal is to place both 32 bit and 64 bit objects and shared objects
in archives at the top-level, not multilib subdirectories.  The
multilibs are built in subdirectories, but must be combined during the
last parts of the target library build process.  Because of the way
that GCC bootstrap works, the libraries must be combined during the
multiple stages of GCC bootstrap, not solely when installed in the
final destination, so the libraries have to be correct at the end of
each target library build stage, not solely an install recipe.

After trying various options, the best solution seems to be the
inclusion of target-specific Makefile fragments. Directly adding the
rules to the Makefiles conflicts with Automake conditionals syntax.
And Makefile fragments are easily extendible to other targets, such as
Darwin. It avoids regenerating Makefile.in or configure for each
change.

The rhythm of the fragment is the same for each library, but each
library is slightly different: package name versus directory name,
sub-directory, location of version info. I didn't see the benefit of
trying to rationalize all of the GCC target libraries as part of this
effort.

One global issue: I copied empty.mk into each library because Make
needs to include something by default. Alternatively, I can move
empty.mk to the top-level of the source tree and include a common copy
everywhere.

Bootstrapped on powerpc-ibm-aix7.2.0.0 and powerpc64le-unknown-gnu-linux.

Is this okay with each maintainer for the respective target libraries?

Thanks, David

libgomp/
* Makefile.am (tmake_file): Build and install AIX-style FAT libraries.
* Makefile.in: Regenerate
* configure.ac (tmake_file): Substitute.
* configure: Regenerate.
* configure.tgt (powerpc-ibm-aix*): Define tmake_file.
* config/t-aix: New file.
* empty.mk: New file.

libstdc++-v3/
* Makefile.am (tmake_file): Build and install AIX-style FAT libraries.
* Makefile.in: Regenerate.
* configure.ac (tmake_file): Substitute.
* configure: Regenerate.
* configure.host (aix*): Define tmake_file.
* config/os/aix/t-aix: New file.
* empty.mk: New file.

libatomic/
* Makefile.am (tmake_file): Build and install AIX-style FAT libraries.
* Makefile.in: Regenerate.
* configure.ac (tmake_file): Substitute.
* configure: Regenerate.
* configure.tgt (powerpc-ibm-aix*): Define tmake_file.
* config/t-aix: New file.
* empty.mk: New file.

libgfortran/
* Makefile.am (tmake_file): Build and install AIX-style FAT libraries.
* Makefile.in: Regenerate.
* configure.ac (tmake_file): Substitute.
* configure: Regenerate.
* configure.host: Add system configury stanza. Define tmake_file.
* config/t-aix: New file.
* empty.mk: New file.
From cf96afed42fcda9debb1351e86b511316ee4d781 Mon Sep 17 00:00:00 2001
From: David Edelsohn 
Date: Fri, 15 May 2020 17:46:08 -0400
Subject: [PATCH] FAT target library support

libgomp/
* Makefile.am (tmake_file): Build and install AIX-style FAT libraries.
* Makefile.in: Regenerate
* configure.ac (tmake_file): Substitute.
* configure: Regenerate.
* configure.tgt (powerpc-ibm-aix*): Define tmake_file.
* config/t-aix: New file.
* empty.mk: New file.

libstdc++-v3/
* Makefile.am (tmake_file): Build and install AIX-style FAT libraries.
* Makefile.in: Regenerate.
* configure.ac (tmake_file): Substitute.
* configure: Regenerate.
* configure.host (aix*): Define tmake_file.
* config/os/aix/t-aix: New file.
* empty.mk: New file.

libatomic/
* Makefile.am (tmake_file): Build and install AIX-style FAT libraries.
* Makefile.in: Regenerate.
* configure.ac (tmake_file): Substitute.
* configure: 

[PATCH] RISC-V: Make __divdi3 handle div by zero same as hardware.

[Jim Wilson]

The ISA manual specifies that divide by zero always returns -1 as the result.
We were failing to do that when the dividend was negative.

Tested with cross toolchain builds for riscv32-elf and riscv64-linux.  There
were no regressions.

Committed.

Jim

libgcc/
* config/riscv/div.S (__divdi3): For negative arguments, change bgez
to bgtz.
---
 libgcc/config/riscv/div.S | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libgcc/config/riscv/div.S b/libgcc/config/riscv/div.S
index 151f8e273ac..17234324c1e 100644
--- a/libgcc/config/riscv/div.S
+++ b/libgcc/config/riscv/div.S
@@ -107,10 +107,12 @@ FUNC_END (__umoddi3)
   /* Handle negative arguments to __divdi3.  */
 .L10:
   neg   a0, a0
-  bgez  a1, .L12  /* Compute __udivdi3(-a0, a1), then negate the result.  
*/
+  /* Zero is handled as a negative so that the result will not be inverted.  */
+  bgtz  a1, .L12 /* Compute __udivdi3(-a0, a1), then negate the result.  */
+
   neg   a1, a1
-  j __udivdi3 /* Compute __udivdi3(-a0, -a1).  */
-.L11: /* Compute __udivdi3(a0, -a1), then negate the result.  
*/
+  j __udivdi3/* Compute __udivdi3(-a0, -a1).  */
+.L11:/* Compute __udivdi3(a0, -a1), then negate the result.  */
   neg   a1, a1
 .L12:
   move  t0, ra
-- 
2.17.1

Re: [PATCH] RISC-V: align RISC-V software division with hardware specification in case of division by zero

[Jim Wilson]

On Fri, May 29, 2020 at 1:53 AM MOSER Virginie via Gcc-patches
 wrote:
> The assembly code in libgcc/config/riscv/div.S does not handle the division 
> by zero as specified in the riscv-spec v2.2 chapter 6.2 in case of signed 
> division:

This looks OK.  There are some administrative comments to make here.

FSF policy requires copyright assignments.  I don't see one for you or
your employer.  If you are serious about contributing to GNU projects.
you need to get a copyright assignment.  This patch is small enough
that I can accept it, but I may not be able to accept the next one.
If you don't get a copyright assignment, you might consider filing bug
reports instead and let someone with an assignment write the patch.

The patch is mime encoded which is inconvenient.  The patch also got
corrupted somehow.  I had to edit it before I could get it to apply.
Or maybe the patch was for an older gcc version?  git format-patch and
git send-email is a good way to create and send a patch.  Or you can
file a bug report and add the patch as an attachment there.

ChangeLog entries should describe what change was made.  Not why it
was made.  The why should go into the git commit or comments in the
code.  I rewrote the ChangeLog entry.

We prefer lines that are less than 80 characters.  I moved the comment
to a separate line and also fixed some other nearby lines.  Comments
end with a period and two spaces.

I fixed up the patch, tested it, and committed it.  I will send the
patch I committed.

Jim

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[andrew2085 at gmail dot com]

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

--- Comment #28 from Andrew Downing  ---
Hey that's cheating, but yea the second part did it.

[FYI] [Ada] remove last traces of -auxbase

[Alexandre Oliva]

Remove occurrences of auxbase that remained in comments.

Regstrapped on x86_64-linux-gnu.  Pre-approved by Arno.


for  gcc/ada/ChangeLog

* lib.ads (Compilation_Switches): Remove -auxbase from
comments.
* switch.ads (Is_Internal_GCC_Switch): Likewise.
---
 ada/lib.ads|2 +-
 ada/switch.ads |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git gcc/ada/lib.ads gcc/ada/lib.ads
index 8376d7a..47b6867 100644
--- gcc/ada/lib.ads
+++ gcc/ada/lib.ads
@@ -998,7 +998,7 @@ private
--  The following table records the compilation switches used to compile
--  the main unit. The table includes only switches. It excludes -o
--  switches as well as artifacts of the gcc/gnat1 interface such as
-   --  -quiet, -dumpbase, or -auxbase.
+   --  -quiet, or -dumpbase.
 
--  This table is set as part of the compiler argument scanning in
--  Back_End. It can also be reset in -gnatc mode from the data in an
diff --git gcc/ada/switch.ads gcc/ada/switch.ads
index aa8b283..7fdfb52 100644
--- gcc/ada/switch.ads
+++ gcc/ada/switch.ads
@@ -77,7 +77,7 @@ package Switch is
 
function Is_Internal_GCC_Switch (Switch_Chars : String) return Boolean;
--  Returns True iff Switch_Chars represents an internal GCC switch to be
-   --  followed by a single argument, such as -dumpbase, --param or -auxbase.
+   --  followed by a single argument, such as -dumpbase, or --param.
--  Even though passed by the "gcc" driver, these need not be stored in ALI
--  files and may safely be ignored by non GCC back-ends.
 

-- 
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

Re: [PATCH] Prefer simple case changes in spelling suggestions

[David Malcolm via Gcc-patches]

On Sat, 2020-05-30 at 18:51 +, Pip Cet wrote:
> On Sat, May 30, 2020 at 5:06 PM David Malcolm 
> wrote:
> > On Sat, 2020-05-30 at 13:40 +, Pip Cet via Gcc-patches wrote:
> > > I think we should just omit the triangle inequality test from the
> > > self-test, as in the attached patch.
> > 
> > I like the idea,
> 
> Thanks!
> 
> > but can you update the comment so that it explains why
> > it's not a metric? (better to capture that in a comment in the
> > source
> > rather than just in the mailing list archives).
> 
> How's this?

Thanks; looks good to me.  Hopefully this doesn't clash with Tom's
patch.


Dave

Re: [PATCH] Prefer simple case changes in spelling suggestions

[David Malcolm via Gcc-patches]

On Mon, 2020-06-01 at 14:11 -0600, Tom Tromey wrote:
> > Did the full DejaGnu testsuite get run?  There are a lot of tests
> > in it
> > that make use of this code.
> 
> I did "make check" and only saw some XFAILs.
> 
> Here's v2 of the patch, which I think addresses your comments.  I did
> not add a new test of get_edit_distance, because as I mentioned
> earlier,
> an existing test already does what you asked for.
> 
> Tom
> 
> commit e897a99dada8d3935343ebf7b14ad7ec36515b3d
> Author: Tom Tromey 
> Date:   Fri May 29 10:46:57 2020 -0600
> 
> Prefer simple case changes in spelling suggestions
> 
> I got this error message when editing gcc and recompiling:
> 
> ../../gcc/gcc/ada/gcc-interface/decl.c:7714:39: error:
> ‘DWARF_GNAT_ENCODINGS_all’ was not declared in this scope; did you
> mean ‘DWARF_GNAT_ENCODINGS_GDB’?
>  7714 | = debug_info && gnat_encodings ==
> DWARF_GNAT_ENCODINGS_all;
>   |   ^~~
> ~
>   |   DWARF_GNAT_ENCODING
> S_GDB
> 
> This suggestion could be improved -- what happened here is that I
> failed to upper-case the word, and DWARF_GNAT_ENCODINGS_ALL was
> the
> correct spelling.
> 
> This patch changes gcc's spell checker to prefer simple case
> changes
> when possible.
> 
> I tested this using the self-tests.  A new self-test is also
> included.
> 
> gcc/ChangeLog:
> 
> * spellcheck.c (CASE_COST): New define.
> (BASE_COST): New define.
> (get_edit_distance): Recognize case changes.
> (get_edit_distance_cutoff): Update.
> (test_edit_distances): Update.
> (get_old_cutoff): Update.
> (test_find_closest_string): Add case sensitivity test.

Thanks; looks good to me.

Dave
 

[Bug c++/95484] New: Friend declaration of member function template has no effect

[herring at lanl dot gov]

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

Bug ID: 95484
   Summary: Friend declaration of member function template has no
effect
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: herring at lanl dot gov
  Target Milestone: ---

The current build at Compiler Explorer rejects

  struct A {
template operator T*() const;
  };

  class B {
constexpr static decltype(nullptr) null=nullptr;
template friend A::operator T*() const;
  };

  template A::operator T*() const {return B::null;}

  int main() {
int *p=A();
return !!p;
  }

with

  : In instantiation of 'A::operator T*() const [with T = int]':
  :13:12:   required from here
  :10:53: error: 'constexprstd::nullptr_t B::null' is private within
this context
 10 | template A::operator T*() const {return B::null;}
|  ~~~^~~~
  :6:38: note: declared private here
  6 |   constexpr static decltype(nullptr) null=nullptr;
|  ^~~~

(Note also the missing space in the restated declaration of B::null.)

Declaration matching has certainly succeeded: omitting the 'const' from the
friend declaration or changing "T*" to "T**", "T", or "T&" produces a (correct)
error about the member function template not being found.

[Bug c++/95050] coroutine: no "mandatory copy elision" for prvalue await_resume expression.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:324276ff9b1aa5128e5cb9f5d43182d1ebab0752

commit r11-835-g324276ff9b1aa5128e5cb9f5d43182d1ebab0752
Author: Iain Sandoe 
Date:   Tue Jun 2 16:47:54 2020 +0100

coroutines: Wrap co_await in a target expr where needed [PR95050]

Since the co_await expression is mostly opaque to the existing
machinery, we were hiding the details of the await_resume return
value.  If that needs to be wrapped in a target expression, then
emulate this with the whole co_await.  Similarly, if the await
expression we build in response to co_await p.yield_value (e)
is wrapped in a target expression, then we need to transfer that
wrapper to the resultant CO_YIELD_EXPR (which is, itself, just
a proxy for the underlying co_await).

gcc/cp/ChangeLog:

PR c++/95050
* coroutines.cc (build_co_await): Wrap the co_await expression
in a TARGET_EXPR, where needed.
(finish_co_yield_expr): Likewise.

gcc/testsuite/ChangeLog:

PR c++/95050
* g++.dg/coroutines/pr95050.C: New test.

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

[rguenther at suse dot de]

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

--- Comment #27 from rguenther at suse dot de  ---
On June 2, 2020 6:34:12 PM GMT+02:00, andrew2085 at gmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
>--- Comment #25 from Andrew Downing  ---
>Do you know how to change that example so that gcc's knowledge is
>incomplete
>and it not longer does the correct thing?

Add std::launder ;) or, for example, conditionally assign another pointer
incoming to the function before dereferencing it (untested).

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  ---
On June 2, 2020 6:55:21 PM GMT+02:00, skpgkp2 at gmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237
>
>--- Comment #14 from Sunil Pandey  ---
>Created attachment 48662
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48662=edit
>Add target hook to skip alignment check for long long on x86 with -m32
>and
>-mpreferred-stack-boundary=2
>
>Bootstrap and regression tested on x86_64.

That doesn't make sense.  The alignment is already too large, so the patch will
avoid the ICE but not fix the wrong-code issue.

[Bug target/95471] vrndvq_f32 not supported on armv8

[e...@coeus-group.com]

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

--- Comment #2 from Evan Nemerson  ---
In that case shouldn't the header be adjusted to not define the vrndvq_f32
function unless it is enabled?

It is already guarded by a check for __ARM_ARCH >= 8 (see
,
but obviously that isn't sufficient.  If nothing else it would help document
the actual requirements, which would be great since the flags and macros on ARM
are a bit of a mess.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qinzhao at gcc dot gnu.org]

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

--- Comment #24 from qinzhao at gcc dot gnu.org ---
with the patch added to gcc11, I tested it with the small testing case, and got
the following data:

**without the patch:
qinzhao@gcc14:~/Bugs/profile/small_gcc/gcc_prof_dir/13248$ ls -l
-rw-r--r-- 1 qinzhao qinzhao 100 Jun  2 19:02
#home#qinzhao#Bugs#profile#small_gcc#five.gcda
-rw-r--r-- 1 qinzhao qinzhao 184 Jun  2 19:02
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda
-rw-r--r-- 1 qinzhao qinzhao 100 Jun  2 19:02
#home#qinzhao#Bugs#profile#small_gcc#ten.gcda

**with the patch:
qinzhao@gcc14:~/Bugs/profile/small_gcc/gcc_prof_dir/20668$ ls -l
-rw-r--r-- 1 qinzhao qinzhao  68 Jun  2 19:34
#home#qinzhao#Bugs#profile#small_gcc#five.gcda
-rw-r--r-- 1 qinzhao qinzhao 144 Jun  2 19:34
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda
-rw-r--r-- 1 qinzhao qinzhao 100 Jun  2 19:34
#home#qinzhao#Bugs#profile#small_gcc#ten.gcda

from the above data, we can see:

1. there are size reduction for "five.c" and "lib.c" as expected.
2. However, we still keep the *.gcda file for five.c even though there is no
any meaningful data in this file. 

I will try to get more data on our real application. 

one question: why not just delete the entire records whose counter is zero and
delete the entire file whose counter is zero?

[Bug target/95483] New: [i386] Missing SIMD functions

[e...@coeus-group.com]

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

Bug ID: 95483
   Summary: [i386] Missing SIMD functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e...@coeus-group.com
  Target Milestone: ---

Created attachment 48663
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48663=edit
Script to generate the list

I noticed the _mm_loadu_epi* functions were missing, so I threw together a
trivial script to look for missing functions based on the XML data backing the
Intel Intrinsics Guide
.  After
filtering out the the SVML and Other functions it came up with 122 results.

I attached the script in case anyone wants to reproduce.  It's ugly and slow
(it was really meant to be a throw-away), but it seems to work.  Just run it in
gcc/config/i386, and pass it the location of the IIG XML.

Here is the list:

  AVX _mm256_cvtsi256_si32
  AVX2 _mm_broadcastsd_pd
  AVX2 _mm_broadcastsi128_si256
  AVX-512 _mm512_storeu_epi16
  AVX-512 _mm512_storeu_epi8
  AVX-512 _mm256_storeu_epi16
  AVX-512 _mm256_storeu_epi8
  AVX-512 _mm_storeu_epi16
  AVX-512 _mm_storeu_epi8
  AVX-512 _mm512_loadu_epi16
  AVX-512 _mm512_loadu_epi8
  AVX-512 _mm256_loadu_epi16
  AVX-512 _mm256_loadu_epi8
  AVX-512 _mm_loadu_epi16
  AVX-512 _mm_loadu_epi8
  AVX-512 _mm512_mask_reduce_round_pd
  AVX-512 _mm512_maskz_reduce_round_pd
  AVX-512 _mm512_reduce_round_pd
  AVX-512 _mm512_mask_reduce_round_ps
  AVX-512 _mm512_maskz_reduce_round_ps
  AVX-512 _mm512_reduce_round_ps
  AVX-512 _mm_mask_reduce_round_sd
  AVX-512 _mm_maskz_reduce_round_sd
  AVX-512 _mm_reduce_round_sd
  AVX-512 _mm_mask_reduce_round_ss
  AVX-512 _mm_maskz_reduce_round_ss
  AVX-512 _mm_reduce_round_ss
  AVX-512 _mm_mask_rcp28_round_sd
  AVX-512 _mm_mask_rcp28_sd
  AVX-512 _mm_maskz_rcp28_round_sd
  AVX-512 _mm_maskz_rcp28_sd
  AVX-512 _mm_mask_rcp28_round_ss
  AVX-512 _mm_mask_rcp28_ss
  AVX-512 _mm_maskz_rcp28_round_ss
  AVX-512 _mm_maskz_rcp28_ss
  AVX-512 _mm_mask_rsqrt28_round_sd
  AVX-512 _mm_mask_rsqrt28_sd
  AVX-512 _mm_maskz_rsqrt28_round_sd
  AVX-512 _mm_maskz_rsqrt28_sd
  AVX-512 _mm_mask_rsqrt28_round_ss
  AVX-512 _mm_mask_rsqrt28_ss
  AVX-512 _mm_maskz_rsqrt28_round_ss
  AVX-512 _mm_maskz_rsqrt28_ss
  AVX-512 _mm256_mask_cvt_roundps_ph
  AVX-512 _mm256_maskz_cvt_roundps_ph
  AVX-512 _mm_mask_cvt_roundps_ph
  AVX-512 _mm_maskz_cvt_roundps_ph
  AVX-512 _mm256_store_epi32
  AVX-512 _mm_store_epi32
  AVX-512 _mm256_loadu_epi64
  AVX-512 _mm256_loadu_epi32
  AVX-512 _mm_loadu_epi64
  AVX-512 _mm_loadu_epi32
  AVX-512 _mm256_load_epi64
  AVX-512 _mm256_load_epi32
  AVX-512 _mm_load_epi64
  AVX-512 _mm_load_epi32
  AVX-512 _mm_cvtsd_i32
  AVX-512 _mm_cvtsd_i64
  AVX-512 _mm_mask_cvt_roundsd_ss
  AVX-512 _mm_mask_cvtsd_ss
  AVX-512 _mm_maskz_cvt_roundsd_ss
  AVX-512 _mm_maskz_cvtsd_ss
  AVX-512 _mm_cvti32_sd
  AVX-512 _mm_cvti64_sd
  AVX-512 _mm_cvti32_ss
  AVX-512 _mm_cvti64_ss
  AVX-512 _mm_mask_cvt_roundss_sd
  AVX-512 _mm_mask_cvtss_sd
  AVX-512 _mm_maskz_cvt_roundss_sd
  AVX-512 _mm_maskz_cvtss_sd
  AVX-512 _mm_cvtss_i32
  AVX-512 _mm_cvtss_i64
  AVX-512 _mm_mask_scalef_sd
  AVX-512 _mm_maskz_scalef_sd
  AVX-512 _mm_mask_scalef_ss
  AVX-512 _mm_maskz_scalef_ss
  AVX-512 _mm_mask_sqrt_sd
  AVX-512 _mm_maskz_sqrt_sd
  AVX-512 _mm_mask_sqrt_ss
  AVX-512 _mm_maskz_sqrt_ss
  AVX-512 _mm512_cvtsi512_si32
  AVX-512/KNC _mm512_mask_permutevar_epi32
  AVX-512/KNC _mm512_permutevar_epi32
  AVX-512/KNC _mm512_cvtpslo_pd
  AVX-512/KNC _mm512_mask_cvtpslo_pd
  AVX-512/KNC _mm512_cvtepi32lo_pd
  AVX-512/KNC _mm512_mask_cvtepi32lo_pd
  AVX-512/KNC _mm512_cvtepu32lo_pd
  AVX-512/KNC _mm512_mask_cvtepu32lo_pd
  AVX-512/KNC _mm512_i32extgather_epi32
  AVX-512/KNC _mm512_mask_i32extgather_epi32
  AVX-512/KNC _mm512_i32loextgather_epi64
  AVX-512/KNC _mm512_mask_i32loextgather_epi64
  AVX-512/KNC _mm512_i32extgather_ps
  AVX-512/KNC _mm512_mask_i32extgather_ps
  AVX-512/KNC _mm512_i32loextgather_pd
  AVX-512/KNC _mm512_mask_i32loextgather_pd
  AVX-512/KNC _mm512_i32extscatter_ps
  AVX-512/KNC _mm512_mask_i32extscatter_ps
  AVX-512/KNC _mm512_i32loextscatter_pd
  AVX-512/KNC _mm512_mask_i32loextscatter_pd
  AVX-512/KNC _mm512_i32loextscatter_epi64
  AVX-512/KNC _mm512_mask_i32loextscatter_epi64
  AVX-512/KNC _mm512_cvtpd_pslo
  AVX-512/KNC _mm512_mask_cvtpd_pslo
  AVX-512/KNC _mm512_i32logather_epi64
  AVX-512/KNC _mm512_mask_i32logather_epi64
  AVX-512/KNC _mm512_i32logather_pd
  AVX-512/KNC _mm512_mask_i32logather_pd
  AVX-512/KNC _mm512_i32loscatter_pd
  AVX-512/KNC _mm512_mask_i32loscatter_pd
  AVX-512/KNC _mm512_i32extscatter_epi32
  AVX-512/KNC _mm512_mask_i32extscatter_epi32
  AVX-512/KNC _mm512_prefetch_i32extgather_ps
  AVX-512/KNC _mm512_mask_prefetch_i32extgather_ps
  AVX-512/KNC _mm512_prefetch_i32extscatter_ps
  

[Bug target/95459] aarch64: ICE in aarch64_short_vector_p, at config/aarch64/aarch64.c:16803

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Fixed.

[Bug libstdc++/90102] Incorrect ambiguous overload with _GLIBCXX_DEBUG

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |11.0
 Resolution|--- |FIXED

--- Comment #7 from Jonathan Wakely  ---
Fixed on master.

Re: [PATCH PR95459] aarch64: ICE in aarch64_short_vector_p, at config/aarch64/aarch64.c:16803

[Richard Sandiford]

"Yangfei (Felix)"  writes:
> Hi,
>
> Please review this trivial patch fixing an ICE in aarch64_short_vector_p.
> Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95459 
>
> In aarch64_short_vector_p, we are simply checking whether a type (and a 
> mode)
> is a 64/128-bit short vector or not.  This should not be affected by the 
> value
> of TARGET_SVE.  Simply leave later code to report an error if SVE is 
> disabled.
> Bootstrapped and tested on aarch64-linux-gnu.  OK?

OK, thanks.  Pushed to master.

Richard

>
> gcc/ChangeLog
> @@ -1,3 +1,9 @@
> +2020-06-02  Felix Yang  
> +
> +   PR target/95459
> +   * config/aarch64/aarch64.c (aarch64_short_vector_p):
> +   Leave later code to report an error if SVE is disabled.
>
> gcc/testsuite/ChangeLog
> @@ -1,3 +1,8 @@
> +2020-06-02  Felix Yang  
> +
> +   PR target/95459
> +   * gcc.target/aarch64/mgeneral-regs_6.c: New test.
>
> Thanks,
> Felix

[Bug target/95459] aarch64: ICE in aarch64_short_vector_p, at config/aarch64/aarch64.c:16803

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:b2672dd630c81513e08829adc63294ffeedf5693

commit r11-833-gb2672dd630c81513e08829adc63294ffeedf5693
Author: Fei Yang 
Date:   Tue Jun 2 18:17:34 2020 +0100

aarch64: Fix an ICE in aarch64_short_vector_p [PR95459]

In aarch64_short_vector_p, we are simply checking whether a type (and a
mode)
is a 64/128-bit short vector or not.  This should not be affected by the
value
of TARGET_SVE.  Simply leave later code to report an error if SVE is
disabled.

2020-06-02  Felix Yang  

gcc/
PR target/95459
* config/aarch64/aarch64.c (aarch64_short_vector_p):
Leave later code to report an error if SVE is disabled.

gcc/testsuite/
PR target/95459
* gcc.target/aarch64/mgeneral-regs_6.c: New test.

[committed] libstdc++: Make debug containers prefer copy ctor to base ctor (PR 90102)

[Jonathan Wakely via Gcc-patches]

When given a type which can convert to any container-like type, the
C(const C&) copy constructor and C(const C::_Base&) converting
constructor are ambiguous. This change replaces the converting
constructor's parameter with a reference_wrapper-like type so that
calling that constructor requires an additional user-defined conversion.
This gives it a lower rank than the copy constructor, avoiding the
ambiguity.

While testing this change I discovered that __gnu_debug::forward_list
doesn't have a convering constructor from the std::forward_list base, so
this adds it.

We should probably consider whether the converting constructors should
be 'explicit' but I'm not changing that now.

libstdc++-v3/ChangeLog:

PR libstdc++/90102
* include/debug/deque (deque(const _Base&)): Replace parameter
with a struct that wraps a const _Base&.
* include/debug/forward_list (forward_list(_Base_ref)): New
constructor.
* include/debug/list (list(const _Base&)): Replace parameter
with a struct that wraps a const _Base&.
* include/debug/map.h (map(const _Base&)): Likewise.
* include/debug/multimap.h (multimap(const _Base&)): Likewise.
* include/debug/multiset.h (multiset(const _Base&)): Likewise.
* include/debug/set.h (set(const _Base&)): Likewise.
* include/debug/unordered_map (unordered_map(const _Base&))
(unordered_multimap(const _Base&)): Likewise.
* include/debug/unordered_set (unordered_set(const _Base&))
(unordered_multiset(const _Base&)): Likewise.
* testsuite/23_containers/vector/cons/destructible_debug_neg.cc:
Adjust dg-error line number.
* include/debug/vector (vector(const _Base&)): Likewise.
* testsuite/23_containers/deque/debug/90102.cc: New test.
* testsuite/23_containers/forward_list/debug/90102.cc: New test.
* testsuite/23_containers/list/debug/90102.cc: New test.
* testsuite/23_containers/map/debug/90102.cc: New test.
* testsuite/23_containers/multimap/debug/90102.cc: New test.
* testsuite/23_containers/multiset/debug/90102.cc: New test.
* testsuite/23_containers/set/debug/90102.cc: New test.
* testsuite/23_containers/unordered_map/debug/90102.cc: New test.
* testsuite/23_containers/unordered_multimap/debug/90102.cc: New test.
* testsuite/23_containers/unordered_multiset/debug/90102.cc: New test.
* testsuite/23_containers/unordered_set/debug/90102.cc: New test.
* testsuite/23_containers/vector/debug/90102.cc: New test.

Tested powerpc64le-linux, committed to master.


commit eca833b81289438ec5ae3ed4c77ffb49cfb65f34
Author: Jonathan Wakely 
Date:   Tue Jun 2 18:13:08 2020 +0100

libstdc++: Make debug containers prefer copy ctor to base ctor (PR 90102)

When given a type which can convert to any container-like type, the
C(const C&) copy constructor and C(const C::_Base&) converting
constructor are ambiguous. This change replaces the converting
constructor's parameter with a reference_wrapper-like type so that
calling that constructor requires an additional user-defined conversion.
This gives it a lower rank than the copy constructor, avoiding the
ambiguity.

While testing this change I discovered that __gnu_debug::forward_list
doesn't have a convering constructor from the std::forward_list base, so
this adds it.

We should probably consider whether the converting constructors should
be 'explicit' but I'm not changing that now.

libstdc++-v3/ChangeLog:

PR libstdc++/90102
* include/debug/deque (deque(const _Base&)): Replace parameter
with a struct that wraps a const _Base&.
* include/debug/forward_list (forward_list(_Base_ref)): New
constructor.
* include/debug/list (list(const _Base&)): Replace parameter
with a struct that wraps a const _Base&.
* include/debug/map.h (map(const _Base&)): Likewise.
* include/debug/multimap.h (multimap(const _Base&)): Likewise.
* include/debug/multiset.h (multiset(const _Base&)): Likewise.
* include/debug/set.h (set(const _Base&)): Likewise.
* include/debug/unordered_map (unordered_map(const _Base&))
(unordered_multimap(const _Base&)): Likewise.
* include/debug/unordered_set (unordered_set(const _Base&))
(unordered_multiset(const _Base&)): Likewise.
* testsuite/23_containers/vector/cons/destructible_debug_neg.cc:
Adjust dg-error line number.
* include/debug/vector (vector(const _Base&)): Likewise.
* testsuite/23_containers/deque/debug/90102.cc: New test.
* testsuite/23_containers/forward_list/debug/90102.cc: New test.
* testsuite/23_containers/list/debug/90102.cc: New test.
* 

[Bug libstdc++/90102] Incorrect ambiguous overload with _GLIBCXX_DEBUG

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:eca833b81289438ec5ae3ed4c77ffb49cfb65f34

commit r11-832-geca833b81289438ec5ae3ed4c77ffb49cfb65f34
Author: Jonathan Wakely 
Date:   Tue Jun 2 18:13:08 2020 +0100

libstdc++: Make debug containers prefer copy ctor to base ctor (PR 90102)

When given a type which can convert to any container-like type, the
C(const C&) copy constructor and C(const C::_Base&) converting
constructor are ambiguous. This change replaces the converting
constructor's parameter with a reference_wrapper-like type so that
calling that constructor requires an additional user-defined conversion.
This gives it a lower rank than the copy constructor, avoiding the
ambiguity.

While testing this change I discovered that __gnu_debug::forward_list
doesn't have a convering constructor from the std::forward_list base, so
this adds it.

We should probably consider whether the converting constructors should
be 'explicit' but I'm not changing that now.

libstdc++-v3/ChangeLog:

PR libstdc++/90102
* include/debug/deque (deque(const _Base&)): Replace parameter
with a struct that wraps a const _Base&.
* include/debug/forward_list (forward_list(_Base_ref)): New
constructor.
* include/debug/list (list(const _Base&)): Replace parameter
with a struct that wraps a const _Base&.
* include/debug/map.h (map(const _Base&)): Likewise.
* include/debug/multimap.h (multimap(const _Base&)): Likewise.
* include/debug/multiset.h (multiset(const _Base&)): Likewise.
* include/debug/set.h (set(const _Base&)): Likewise.
* include/debug/unordered_map (unordered_map(const _Base&))
(unordered_multimap(const _Base&)): Likewise.
* include/debug/unordered_set (unordered_set(const _Base&))
(unordered_multiset(const _Base&)): Likewise.
* testsuite/23_containers/vector/cons/destructible_debug_neg.cc:
Adjust dg-error line number.
* include/debug/vector (vector(const _Base&)): Likewise.
* testsuite/23_containers/deque/debug/90102.cc: New test.
* testsuite/23_containers/forward_list/debug/90102.cc: New test.
* testsuite/23_containers/list/debug/90102.cc: New test.
* testsuite/23_containers/map/debug/90102.cc: New test.
* testsuite/23_containers/multimap/debug/90102.cc: New test.
* testsuite/23_containers/multiset/debug/90102.cc: New test.
* testsuite/23_containers/set/debug/90102.cc: New test.
* testsuite/23_containers/unordered_map/debug/90102.cc: New test.
* testsuite/23_containers/unordered_multimap/debug/90102.cc: New
test.
* testsuite/23_containers/unordered_multiset/debug/90102.cc: New
test.
* testsuite/23_containers/unordered_set/debug/90102.cc: New test.
* testsuite/23_containers/vector/debug/90102.cc: New test.

Re: [patch] Make memory copy functions scalar storage order barriers

[Eric Botcazou]

[Starting with tne VN issue]

> For the VN case the issue is interpreting a read via memcpy (non
> reverse-storage) as a reverse-storage one when matching up with a hashtable
> entry from a regular reverse-storage order store, correct?

It's a read from a scalar (hence native order) combined with a store to an 
aggregate type with reverse order:

   u = 305419896;
  __builtin_memcpy (, , 4);
  _1 = tempb.val;

> But likewise whether the pointer destination had the attribute doesn't
> correctly qualify this - instead I think we are already properly matching up
> the reverse storage property?

No, we do not do direct matching for the storage order because you may not 
access the same memory location with different scalar storage orders, it's the 
fundamental invariant, so it's redundant with e.g. the offset for matching.

You need to byte swap if you want to propagate 305419896 to _1 above.  But 
it's an easy case: suppose that tempb is made up of 2 scalars with reverse 
storage order, then it's more complicated.  So memcpy where one of the types 
is aggregate with reverse storage order needs to be considered a storage order 
barrier, exactly like VIEW_CONVERT_EXPR:

case VIEW_CONVERT_EXPR:
  temp.off = 0;
  temp.reverse = storage_order_barrier_p (ref);
  break;

/* Return true if T is a storage order barrier, i.e. a VIEW_CONVERT_EXPR
   that can modify the storage order of objects.  Note that, even if the
   TYPE_REVERSE_STORAGE_ORDER flag is set on both the inner type and the
   outer type, a VIEW_CONVERT_EXPR can modify the storage order because
   it can change the partition of the aggregate object into scalars.  */

static inline bool
storage_order_barrier_p (const_tree t)
{
  if (TREE_CODE (t) != VIEW_CONVERT_EXPR)
return false;

  if (AGGREGATE_TYPE_P (TREE_TYPE (t))
  && TYPE_REVERSE_STORAGE_ORDER (TREE_TYPE (t)))
return true;

  tree op = TREE_OPERAND (t, 0);

  if (AGGREGATE_TYPE_P (TREE_TYPE (op))
  && TYPE_REVERSE_STORAGE_ORDER (TREE_TYPE (op)))
return true;

  return false;
}

hence the similar conditions, but I can add some more commentary.

> Hum.  How does the pointer type matter at all for memcpy()?
> Isn't the
> issue just that we may not use the TYPE_REVERSE_STORAGE_ORDER
> qualified type in the following case:
> 
>   gimple *new_stmt;
>   if (is_gimple_reg_type (TREE_TYPE (srcvar)))
> {
>   tree tem = fold_const_aggregate_ref (srcvar);
>   if (tem)
> srcvar = tem;
>   if (! is_gimple_min_invariant (srcvar))
> {
>   new_stmt = gimple_build_assign (NULL_TREE, srcvar);
>   srcvar = create_tmp_reg_or_ssa_name (TREE_TYPE (srcvar),
>new_stmt);
> 
> ?

Same rationale as above: if you want to rewrite the copy in the presence of an 
aggregate type with reverse storage order, you may need to split the operation 
into the appropriate pieces; one large access may be incorrect.

-- 
Eric Botcazoudiff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 4e3de95d2d2..2dca9776b38 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -741,15 +741,23 @@ gimple_fold_builtin_memory_op (gimple_stmt_iterator *gsi,
 }
   else
 {
-  tree srctype, desttype;
+  /* We cannot (easily) change the type of the copy if it is a storage
+	 order barrier, i.e. is equivalent to a VIEW_CONVERT_EXPR that can
+	 modify the storage order of objects (see storage_order_barrier_p).  */
+  tree srctype
+	= POINTER_TYPE_P (TREE_TYPE (src))
+	  ? TREE_TYPE (TREE_TYPE (src)) : NULL_TREE;
+  tree desttype
+	= POINTER_TYPE_P (TREE_TYPE (dest))
+	  ? TREE_TYPE (TREE_TYPE (dest)) : NULL_TREE;
   unsigned int src_align, dest_align;
-  tree off0;
-  const char *tmp_str;
   unsigned HOST_WIDE_INT tmp_len;
+  const char *tmp_str;
 
   /* Build accesses at offset zero with a ref-all character type.  */
-  off0 = build_int_cst (build_pointer_type_for_mode (char_type_node,
-			 ptr_mode, true), 0);
+  tree off0
+	= build_int_cst (build_pointer_type_for_mode (char_type_node,
+		  ptr_mode, true), 0);
 
   /* If we can perform the copy efficiently with first doing all loads
  and then all stores inline it that way.  Currently efficiently
@@ -767,7 +775,13 @@ gimple_fold_builtin_memory_op (gimple_stmt_iterator *gsi,
 	 hack can be removed.  */
 	  && !c_strlen (src, 1)
 	  && !((tmp_str = c_getstr (src, _len)) != NULL
-	   && memchr (tmp_str, 0, tmp_len) == NULL))
+	   && memchr (tmp_str, 0, tmp_len) == NULL)
+	  && !(srctype
+	   && AGGREGATE_TYPE_P (srctype)
+	   && TYPE_REVERSE_STORAGE_ORDER (srctype))
+	  && !(desttype
+	   && AGGREGATE_TYPE_P (desttype)
+	   && TYPE_REVERSE_STORAGE_ORDER (desttype)))
 	{
 	  unsigned ilen = tree_to_uhwi (len);
 	  if (pow2p_hwi (ilen))
@@ -947,8 +961,13 @@ gimple_fold_builtin_memory_op (gimple_stmt_iterator 

[Bug target/95347] rs6000 mcpu=future generating stfs instead of pstfs for pc-relative references

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-06-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from acsawdey at gcc dot gnu.org ---
Turns out that lfs/plfs has the same problem. Patch for that coming shortly.

[Bug target/49854] Clean up SPE/e500 option handling

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Please *NEVER* close bugs for things you are not the maintainer for.

[Bug middle-end/95481] Failure to optimize infinite recursion for struct types

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/95158] [10/11 Regression] Templates + Diamond Inheritance + Final = Pure Virtual Function Call

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
That the issue goes away when templates are not involved seems an useful hint:
are we trying to optimize too early?

Sorry, for the time being I don't feel like assigning the bug to me, I'm in the
middle of too many other things...

[Bug debug/95482] New: Feature request: add -gsplit-dwarf=single

[i at maskray dot me]

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

Bug ID: 95482
   Summary: Feature request: add -gsplit-dwarf=single
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

DWARF v5 Appendix F. says

> The sections that do not require relocation, however, can be written to the 
> relocatable object (.o) file but ignored by the linker, or they can be 
> written to a separate DWARF object (.dwo) file that need not be accessed by 
> the linker.

GCC/clang -gsplit-dwarf write a separate DWARF object (.dwo)

clang in addition supports -gsplit-dwarf=single
(https://reviews.llvm.org/D52296 ) to write the sections (with the SHF_EXCLUDE
flag) in the .o file.
Linkers ignore SHF_EXCLUDE sections in non -r mode.

Note, SHF_EXCLUDE (0x8000) is in the range of processor-specific bits and
clashes with several processors's (obsoleted?) flags (see
https://sourceware.org/pipermail/binutils/2020-April/110691.html )

Re: [PATCH 5/7 v3] vect: Support vector load/store with length in vectorizer

[Segher Boessenkool]

On Tue, Jun 02, 2020 at 12:50:25PM +0100, Richard Sandiford wrote:
> This might not be the best time to bring this up :-) but it seems
> odd to be asking the target for the induction variable type here.
> I got the impression that the hook was returning DImode, whereas
> the PowerPC instructions only looked at the low 8 bits of the length.

It's the top(!) 8 bits of the register actually (the other 56 bits are
"do not care" bits).

> If so, forcing a naturally 32-bit IV to DImode would insert extra
> sign/zero extensions, even though the input to the length intrinsics
> would have been happy with the 32-bit IV.

It's a shift left always.  All bits beyond the 8 drop out.


Thanks for the great reviews Richard, much appreciated!


Segher

[Bug tree-optimization/95481] New: Failure to optimize infinite recursion for struct types

[gabravier at gmail dot com]

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

Bug ID: 95481
   Summary: Failure to optimize infinite recursion for struct
types
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

struct A {};

struct A foo()
{
  return foo();
}

This can be optimized to an infinite loop. With -O3, GCC currently outputs an
explicit recursive call like this :

foo():
  sub rsp, 8
  call foo()
  xor eax, eax
  add rsp, 8
  ret

When it could just do this :

foo():
.L2:
  jmp .L2