[Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to otcmaf from comment #4)
> Do you mean that those pattern above are also wrong pattern ?

YES those are broken.

[Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c

[xuemaosheng at huawei dot com]

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

--- Comment #4 from otcmaf  ---
(In reply to Andrew Pinski from comment #3)
> The internals documentation documents this even, read:
> https://gcc.gnu.org/onlinedocs/gccint/RTL-Template.html#index-match_005fdup
> 
> From that:
> Note that match_dup should not be used to tell the compiler that a
> particular register is being used for two operands (example: add that adds
> one register to another; the second register is both an input operand and
> the output operand). Use a matching constraint (see Simple Constraints) for
> those.

However, in gcc/config/aarch64/aarch64-simd.md also has the similar usage。
For example：
1227 (define_insn "aarch64_simd_move_hi_quad_"
1228   [(set (match_operand:VQ 0 "register_operand" "+w,w") 
1229 (vec_concat:VQ 
1230   (vec_select:  
1231 (match_dup 0)  
1232 (match_operand:VQ 2 "vect_par_cnst_lo_half" ""))   
1233   (match_operand: 1 "register_operand" "w,r")))]
1234   "TARGET_SIMD && !BYTES_BIG_ENDIAN"   
1235   "@   
1236ins\\t%0.d[1], %1.d[0]  
1237ins\\t%0.d[1], %1"  
1238   [(set_attr "type" "neon_ins")]   
1239 ) 
the operands[0] is a inout reg, and the pattern also use (match_dup 0).

Another case in gcc/config/c6x/c6x.md
 440 (define_insn "*movstricthi_high"   
 441   [(set (match_operand:SI 0 "register_operand" "+ab")  
 442 (ior:SI (and:SI (match_dup 0) (const_int 65535))   
 443 (ashift:SI (match_operand:SI 1 "const_int_operand" "IuB")  
 444(const_int 16]  
 445   "reload_completed"   
 446   "%|%.\\tmvklh\\t%$\\t%1, %0" 
 447   [(set_attr "units" "s")]) 

2930 (define_insn "setup_dsbt"  
2931   [(set (match_operand:SI 0 "pic_register_operand" "+Z")   
2932 (unspec:SI [(match_dup 0)  
2933 (match_operand:SI 1 "symbolic_operand" "")]
2934UNSPEC_SETUP_DSBT))]
2935   "TARGET_DSBT"
2936   "%|%.\\tldw\\t%$\\t*+%0($DSBT_index%1), %0"  
2937   [(set_attr "type" "load")
2938(set_attr "units" "d_addr") 
2939(set_attr "dest_regfile" "b")   
2940(set_attr "addr_regfile" "b")]) 


Do you mean that those pattern above are also wrong pattern ?
As you say that, that match_dup should not be used to tell the compiler that a
particular register is being used for two operands.
But I still think that the function can_assign_to_reg_without_clobbers_p can do
bettter, use max_reg_num to replace FIRST_PSEUDO_REGISTER * 2 and update
TEST_INSN when calling this function.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[f.mach4 at gmail dot com]

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

Max  changed:

   What|Removed |Added

 CC||f.mach4 at gmail dot com

--- Comment #2 from Max  ---
I am interested in working on this, because it would be a big shame to see AVR
support dropped from GCC. However, while I studied computer science at
university and of course have decent experience with the AVR platform, I do not
have a background in compilers nor have ever contributed to GCC before.

I have read some of the GCC internals manual and browsed around the source
tree, including gcc/config/avr, but I am still missing out on some foundational
understanding of how everything fits together inside GCC. 

Is there anyone more familiar with GCC internals and/or the AVR backend who I
would be able to consult or possibly work with on this?

[Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
The internals documentation documents this even, read:
https://gcc.gnu.org/onlinedocs/gccint/RTL-Template.html#index-match_005fdup

>From that:
Note that match_dup should not be used to tell the compiler that a particular
register is being used for two operands (example: add that adds one register to
another; the second register is both an input operand and the output operand).
Use a matching constraint (see Simple Constraints) for those.

[Bug testsuite/95110] new test case in r11-345 error: gcc.dg/tree-ssa/pr94969.c: dump file does not exist

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Bin Cheng :

https://gcc.gnu.org/g:466ad887c9e1cd5a6762e7ec620eef2c8175b50d

commit r9-8614-g466ad887c9e1cd5a6762e7ec620eef2c8175b50d
Author: Bin Cheng 
Date:   Fri May 22 11:42:11 2020 +0800

Add missing unit dependence vector in data dependence analysis

Current data dependence analysis misses unit distant vector if DRs in
DDR have the same invariant access functions.  This adds the vector as
the constant access function case.

Also fix typo in testcase.

Backport from master.

2020-05-13  Bin Cheng  

gcc/
PR tree-optimization/94969
* tree-data-ref.c (constant_access_functions): Rename to...
(invariant_access_functions): ...this.  Add parameter.  Check for
invariant access function, rather than constant.
(build_classic_dist_vector): Call above function.
* tree-loop-distribution.c (pg_add_dependence_edges): Add comment.

gcc/testsuite/
PR tree-optimization/94969
* gcc.dg/tree-ssa/pr94969.c: New test.

2020-05-13  Jakub Jelinek  

gcc/testsuite/
PR tree-optimization/95110
* gcc.dg/tree-ssa/pr94969.c: Swap scan-tree-dump-not arguments.

[Bug tree-optimization/94969] [8/9/10/11 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Bin Cheng :

https://gcc.gnu.org/g:466ad887c9e1cd5a6762e7ec620eef2c8175b50d

commit r9-8614-g466ad887c9e1cd5a6762e7ec620eef2c8175b50d
Author: Bin Cheng 
Date:   Fri May 22 11:42:11 2020 +0800

Add missing unit dependence vector in data dependence analysis

Current data dependence analysis misses unit distant vector if DRs in
DDR have the same invariant access functions.  This adds the vector as
the constant access function case.

Also fix typo in testcase.

Backport from master.

2020-05-13  Bin Cheng  

gcc/
PR tree-optimization/94969
* tree-data-ref.c (constant_access_functions): Rename to...
(invariant_access_functions): ...this.  Add parameter.  Check for
invariant access function, rather than constant.
(build_classic_dist_vector): Call above function.
* tree-loop-distribution.c (pg_add_dependence_edges): Add comment.

gcc/testsuite/
PR tree-optimization/94969
* gcc.dg/tree-ssa/pr94969.c: New test.

2020-05-13  Jakub Jelinek  

gcc/testsuite/
PR tree-optimization/95110
* gcc.dg/tree-ssa/pr94969.c: Swap scan-tree-dump-not arguments.

[Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c

[xuemaosheng at huawei dot com]

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

--- Comment #2 from otcmaf  ---
(In reply to Andrew Pinski from comment #1)
> I think this is a back-end issue.
> Can you provide the definition of movtv8hf16 ?
> I don't think you can do:
> (set (match_operand 0 predicate constraint)
> (unspec:V8HF16 [
> (match_operand 1 predicate constraint)
> (match_operand 2 predicate constraint)
> (match_dup 0)
> ] UNSPEC_MOVTVFM)))
> 
> Rather you need to do:
> (set (match_operand 0 predicate constraint)
> (unspec:V8HF16 [
> (match_operand 1 predicate constraint)
> (match_operand 2 predicate constraint)
> (match_operand 3 predicate "0")
> ] UNSPEC_MOVTVFM)))

we use this definition of movtv8hf16:
(define_insn "movtv8hf16"   
  [(set (match_operand:V8HF16 0 "register_operand_s" "+Zrv")
(unspec:V8HF16 [(match_operand:V8HF16 1 "register_operand_s" "Zrv") 
(match_operand:BF8 2 "register_operand_s" "Zrb")
(match_dup 0)]UNSPEC_MOVTVFM))]

why we can't use (match_dup 0) ?

[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-05-22

--- Comment #1 from Andrew Pinski  ---
I think this is a back-end issue.
Can you provide the definition of movtv8hf16 ?
I don't think you can do:
(set (match_operand 0 predicate constraint)
(unspec:V8HF16 [
(match_operand 1 predicate constraint)
(match_operand 2 predicate constraint)
(match_dup 0)
] UNSPEC_MOVTVFM)))

Rather you need to do:
(set (match_operand 0 predicate constraint)
(unspec:V8HF16 [
(match_operand 1 predicate constraint)
(match_operand 2 predicate constraint)
(match_operand 3 predicate "0")
] UNSPEC_MOVTVFM)))

[Bug rtl-optimization/95267] New: [ICE][gcse]: in process_insert_insn at gcse.c

[xuemaosheng at huawei dot com]

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

Bug ID: 95267
   Summary: [ICE][gcse]: in process_insert_insn at gcse.c
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xuemaosheng at huawei dot com
  Target Milestone: ---

In rtl-optimization gcse pass produces a invalid insn, and finally in function 
process_insert_insn reach the code gcc_unreachable ().

static rtx_insn *
process_insert_insn (struct gcse_expr *expr)
{
  ..
  else
{
  rtx_insn *insn = emit_insn (gen_rtx_SET (reg, exp));

  if (insn_invalid_p (insn, false))
gcc_unreachable ();
}

  .
}

function backtrace is shown as the following:
0xa127cc process_insert_insn
/gcc/gcse.c:2074
0xa12cce pre_edge_insert
gcc/gcse.c:2244
0xa137ee pre_gcse
/gcc/gcse.c:2636
0xa1394f one_pre_gcse_pass
/gcc/gcse.c:2691
0xa169cd execute_rtl_pre
/gcc/gcse.c:4097
0xa16a80 execute
/gcc/gcse.c:4141

the invalid insn produced by gcse pass is shown as the following:
(insn 423 0 0 (set (reg:V8HF16 442 [ userDagc ])
(unspec:V8HF16 [
(reg:V8HF16 171 [ _54 ])
(reg/v:BF8 235 [ boolRsrp ])
(reg/v:V8HF16 234 [ userDagc ])
] UNSPEC_MOVTVFM)) -1
 (nil))

while the original valid insn is shown as the followig:
(insn 261 262 263 30 (set (reg/v:V8HF16 236 [ userDagc ])
(unspec:V8HF16 [
(reg:V8HF16 171 [ _54 ])
(reg/v:BF8 235 [ boolRsrp ])
(reg/v:V8HF16 236 [ userDagc ])
] UNSPEC_MOVTVFM))
"/home2/w00364751/L1Rat/UBBP/src/RatV2/L1Uudp/Srs/nMM/MeasProc/Scheduler/ProcSchedule/src/SRS_UserProc_FDDMM_Private.c":1156
433 {movtv8hf16}
 (expr_list:REG_EQUAL (unspec:V8HF16 [
(reg:V8HF16 171 [ _54 ])
(reg/v:BF8 235 [ boolRsrp ])
(reg/v:V8HF16 234 [ userDagc ])
] UNSPEC_MOVTVFM)
(nil)))

After our analysis, we think that the source of invalid insn is the function
can_assign_to_reg_without_clobbers_p.
function backtrace is shown as the following:
#0  can_assign_to_reg_without_clobbers_p (x=0x77234460, mode=V8HF16mode) at
/gcc/gcse.c:882
#1  0x00a0fe9e in want_to_gcse_p (x=0x77234460, mode=V8HF16mode,
max_distance_ptr=0x0) at /gcc/gcse.c:819
#2  0x00a10a71 in hash_scan_set (set=0x771fe910,
insn=0x771ff370, table=0x1c39980 )
at /gcc/gcse.c:1260
#3  0x00a10dbc in hash_scan_insn (insn=0x771ff370, table=0x1c39980
) at /gcc/gcse.c:1370
#4  0x00a11947 in compute_hash_table_work (table=0x1c39980
) at /gcc/gcse.c:1625
#5  0x00a11a95 in compute_hash_table (table=0x1c39980
) at /gcc/gcse.c:1674
#6  0x00a138de in one_pre_gcse_pass () at 
/gcc/gcse.c:2680
#7  0x00a169ce in execute_rtl_pre () at 
/gcc/gcse.c:4097

the function can_assign_to_reg_without_clobbers_p return true if we can assign
X to a pseudo register of mode MODE such that the resulting insn does not
result in clobbering a hard register as a side-effect.

In our target, the insn is valid since operands[0] is inout reg, this means
that
the insn 262 not only define reg/v:V8HF16 236, but also use reg/v:V8HF16 236.
(insn 261 262 263 30 (set (reg/v:V8HF16 236 [ userDagc ])
(unspec:V8HF16 [
(reg:V8HF16 171 [ _54 ])
(reg/v:BF8 235 [ boolRsrp ])
(reg/v:V8HF16 236 [ userDagc ])
] UNSPEC_MOVTVFM)) 
the REG_EQUAL is
 (expr_list:REG_EQUAL (unspec:V8HF16 [
(reg:V8HF16 171 [ _54 ])
(reg/v:BF8 235 [ boolRsrp ])
(reg/v:V8HF16 234 [ userDagc ])
] UNSPEC_MOVTVFM)
(nil)))

the function can_assign_to_reg_without_clobbers_p use TEST_INSN to judge the
REG_EQUAL is valid or not.
the SET_DEST of TEST_INSN use the regno of FIRST_PSEUDO_REGISTER * 2;
if out target FIRST_PSEUDO_REGISTER is 117, which means that
FIRST_PSEUDO_REGISTER * 2 = 234.
the TEST_ISNN became the following code.
(insn 63 0 0 (set (reg:V8HF16 234)
(unspec:V8HF16 [
(reg:V8HF16 171 [ _54 ])
(reg/v:BF8 235 [ boolRsrp ])
(reg/v:V8HF16 234 [ userDagc ])
] UNSPEC_MOVTVFM)) -1
 (nil))

the insn looks like a valid insn.  However, this is a coincidence，because
FIRST_PSEUDO_REGISTER * 2 = 234， regno 234 is the same as the use reg
reg/v:V8HF16 234, the insn output operands[0],looks like a inout reg.
If  FIRST_PSEUDO_REGISTER is 100 in my target, then the pattern would become
(insn 63 0 0 (set (reg:V8HF16 200)
(unspec:V8HF16 [
(reg:V8HF16 171 [ _54 ])
(reg/v:BF8 235 [ boolRsrp ])
(reg/v:V8HF16 234 [ userDagc ])
] UNSPEC_MOVTVFM)) -1
 (nil))

Then the 

[Bug c/95257] valgrind gives me error when fwprintf in stderr

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
fwprintf is not provided by GCC but rather glibc.
Report it to them instead (https://sourceware.org/bugzilla).

[Bug target/95266] New: [11 regression] gcc.dg/vect/bb-slp-pr69907.c fails on power 7

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95266
   Summary: [11 regression] gcc.dg/vect/bb-slp-pr69907.c fails on
power 7
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

After r11-205 gcc.dg/vect/bb-slp-pr69907.c fails during make check.  I only see
this on a power 7.

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

FAIL: gcc.dg/vect/bb-slp-pr69907.c scan-tree-dump slp1 "BB vectorization with
gaps at the end of a load is not supported"
FAIL: gcc.dg/vect/bb-slp-pr69907.c -flto -ffat-lto-objects  scan-tree-dump slp1
"BB vectorization with gaps at the end of a load is not supported"

# of expected passes2
# of unexpected failures2

[Bug tree-optimization/95199] Remove extra variable created for memory reference in loop vectorization.

[amker at gcc dot gnu.org]

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

--- Comment #5 from bin cheng  ---
(In reply to Richard Biener from comment #1)
> But IVOPTs is supposed to know how to eliminate equal IVs.  Maybe it's
> confused
> about the IFN uses?

It's an known issue that IVOPTs has difficulty in recognizing equal BASEs.  For
now  it tries to identify/eliminate with limited expanding work which isn't
enough for  complicate cases.  I sent a patch to do IVOPTs a favor in
vectorization, but didn't follow up.

Without digging into the code, I am not sure if this is a similar issue.  Will
have a look this WE.

Thanks

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[rafael at espindo dot la]

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

--- Comment #20 from Rafael Avila de Espindola  ---
The attached testcase also fails with just -fsanitize=undefined. I have tested
with gcc version

gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[rafael at espindo dot la]

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

Rafael Avila de Espindola  changed:

   What|Removed |Added

  Attachment #48547|0   |1
is obsolete||

--- Comment #19 from Rafael Avila de Espindola  ---
Created attachment 48579
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48579=edit
Single file testcase

$ g++ -g -fcoroutines -std=gnu++20 coroutines_test.cc -o t && valgrind ./t

no errors, exit value 42

$ g++ -g -fcoroutines -std=gnu++20 coroutines_test.cc -o t -fsanitize=address
-fsanitize=undefined  && ./t
coroutines_test.cc:561:26: runtime error: member access within misaligned
address 0x002231e6 for type 'struct promise_base', which requires 8 byte
alignment
0x002231e6: note: pointer points here
 5c 5d c3 cc 55 48  89 e5 41 57 41 56 41 55  41 54 53 48 83 ec 58 48  89 7d 88
48 8d 5d 90 49  89 df
 ^
AddressSanitizer:DEADLYSIGNAL
=
==112180==ERROR: AddressSanitizer: SEGV on unknown address 0x002231ee (pc
0x0021adf2 bp 0x7ffdf0604570 sp 0x7ffdf06044f0 T0)
==112180==The signal is caused by a WRITE memory access.
#0 0x21adf2 in seastar::internal::future_base::detach_promise()
/home/espindola/scylla/t/coroutines_test.cc:561
#1 0x21ac94 in seastar::internal::future_base::clear()
/home/espindola/scylla/t/coroutines_test.cc:556
#2 0x21acd2 in seastar::internal::future_base::~future_base()
/home/espindola/scylla/t/coroutines_test.cc:559
#3 0x21e3d4 in seastar::future<>::~future()
/home/espindola/scylla/t/coroutines_test.cc:645
#4 0x21d1e1 in seastar::internal::awaiter<>::~awaiter()
/home/espindola/scylla/t/coroutines_test.cc:862
#5 0x215d02 in main::{lambda()#1}::operator()() const [clone .actor]
/home/espindola/scylla/t/coroutines_test.cc:1172
#6 0x214d3b in operator() /home/espindola/scylla/t/coroutines_test.cc:1169
#7 0x216ab8 in apply /home/espindola/scylla/t/coroutines_test.cc:92
#8 0x216b8a in apply >
/home/espindola/scylla/t/coroutines_test.cc:97
#9 0x216d10 in operator() /home/espindola/scylla/t/coroutines_test.cc:680
#10 0x21765e in
satisfy_with_result_of::then_impl_nrvo, seastar::future<> >&&)> mutable:: >
/home/espindola/scylla/t/coroutines_test.cc:793
#11 0x216fee in operator() /home/espindola/scylla/t/coroutines_test.cc:678
#12 0x218881 in run_and_dispose
/home/espindola/scylla/t/coroutines_test.cc:376
#13 0x2143c2 in seastar::reactor::run_tasks(seastar::reactor::task_queue&)
/home/espindola/scylla/t/coroutines_test.cc:1130
#14 0x21463e in seastar::reactor::run()
/home/espindola/scylla/t/coroutines_test.cc:1138
#15 0x216852 in main /home/espindola/scylla/t/coroutines_test.cc:1173
#16 0x7faee1994041 in __libc_start_main (/lib64/libc.so.6+0x27041)
#17 0x21190d in _start (/home/espindola/scylla/t/t+0x21190d)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/espindola/scylla/t/coroutines_test.cc:561
in seastar::internal::future_base::detach_promise()
==112180==ABORTING

[Bug target/95265] aarch64: suboptimal code generation for common neon intrinsic sequence involving shrn and mull

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
 Depends on||92665
   Severity|normal  |enhancement
   Last reconfirmed||2020-05-21
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
The patch for PR 92665 fixes the dup and one mov.  The other move/zeroing the
upper part of the register needs to be seperate as it is due to the intrinsic
being defined as an inline-assembly .


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665
[Bug 92665] [AArch64] low lanes select not optimized out for vmlal intrinsics

[Bug target/95265] New: aarch64: suboptimal code generation for common neon intrinsic sequence involving shrn and mull

[generictoadhuman at gmail dot com]

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

Bug ID: 95265
   Summary: aarch64: suboptimal code generation for common neon
intrinsic sequence involving shrn and mull
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: generictoadhuman at gmail dot com
  Target Milestone: ---

Compileable example:

#include 

int32x4_t func(int32x4_t a, int32x4_t b)
{
return vshrn_high_n_s64(
vshrn_n_s64(vmull_s32(vget_low_s32(a), vget_low_s32(b)), 12), 
vmull_high_s32(a, b), 12);
}

with gcc -O3 the generated code contains two superfluent movs and and one
unecessary dup.

output of gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\opt\devkitpro\devkitA64\bin\aarch64-none-elf-gcc.exe
COLLECT_LTO_WRAPPER=c:/msys64/opt/devkitpro/devkita64/bin/../libexec/gcc/aarch64-none-elf/10.1.0/lto-wrapper.exe
Target: aarch64-none-elf
Configured with: ../../gcc-10.1.0/configure --enable-languages=c,c++,objc,lto
--with-gnu-as --with-gnu-ld --with-gcc --with-march=armv8
--enable-cxx-flags=-ffunction-sections --disable-libstdcxx-verbose
--enable-poison-system-directories --enable-interwork --enable-multilib
--enable-threads --disable-win32-registry --disable-nls --disable-debug
--disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-libstdcxx-filesystem-ts
--target=aarch64-none-elf --with-newlib=yes
--with-headers=../../newlib-3.3.0/newlib/libc/include
--prefix=/opt/devkitpro/x86_64-w64-mingw32/devkitA64 --enable-lto
--with-system-zlib
--with-bugurl=https://github.com/devkitPro/buildscripts/issues
--with-pkgversion='devkitA64 release 15' --build=x86_64-unknown-linux-gnu
--host=x86_64-w64-mingw32 --with-gmp=/opt/mingw64/mingw
--with-mpfr=/opt/mingw64/mingw --with-mpc=/opt/mingw64/mingw
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (devkitA64 release 15)

[Bug c++/95264] New: Infinite Loop When Compiling Templated C++ code at -O1 and above

[freddie at witherden dot org]

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

Bug ID: 95264
   Summary: Infinite Loop When Compiling Templated C++ code at -O1
and above
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie at witherden dot org
  Target Milestone: ---

Created attachment 48578
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48578=edit
Preprocessed source.

When attempting to compile the header-only C++ application Polyquad
(https://github.com/PyFR/Polyquad) with any recent version of GCC at any
optimization level, the compiler gets stuck.  (And either dies with c++: fatal
error: Killed signal terminated program cc1plus or an out of memory error
depending on the platform.)

This is believed to be an interaction between the Boost bfloat type (an
arbitrary precision numerical type) and the Eigen library (a heavily templated
matrix library).

By comparison, Clang is able to compile the application in a few minutes at any
optimization level with memory never peaking above 3-4 GiB.  GCC with -O3 -g
will happily malloc in excess of 30 GiB before dying (although this can be
curtailed somewhat by -fno-var-tracking-assignments).

The compiler command (from the uncompressed pre-processed source) is:

/usr/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/cc1plus -fpreprocessed main.ii
-march=skylake -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16
-msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4
-mno-xop -mbmi -msgx -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2
-msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mrdseed
-mprfchw -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er
-mno-avx512cd -mno-avx512pf -mno-prefetchwt1-mclflushopt -mxsavec -mxsaves
-mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi
-mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku
-mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes
-mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b -mno-waitpkg
-mno-cldemote -mno-ptwrite -mno-avx512bf16 -mno-enqcmd -mno-avx512vp2intersect
--param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=6144-mtune=skylake -quiet -dumpbase main.cpp -auxbase-strip
CMakeFiles/polyquad.dir/src/main.cpp.o -O3 -Wno-deprecated -std=c++17 -version
-fno-var-tracking-assignments-o main.s

[Bug c++/95263] [11 Regression] ICE in lookup_template_class_1 since r11-504-g74744bb1f2847b5b

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/95263] [11 Regression] ICE in lookup_template_class_1 since r11-504-g74744bb1f2847b5b

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|ice in  |[11 Regression] ICE in
   |lookup_template_class_1 |lookup_template_class_1
   ||since
   ||r11-504-g74744bb1f2847b5b
   Keywords||ice-on-valid-code
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
Version|unknown |11.0
   Target Milestone|--- |11.0
   Last reconfirmed||2020-05-21
  Known to fail||11.0
 Status|UNCONFIRMED |NEW
  Known to work||10.1.0

[Bug c++/95263] New: ice in lookup_template_class_1

[dcb314 at hotmail dot com]

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

Bug ID: 95263
   Summary: ice in lookup_template_class_1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C++ code

enum a { b };
template  class c;
template  using d = c;
template  class f { template  using aj = int; };
template  class h {
public:
  using an = f;
  template  using aj = typename an::aj;
  template  void aw();
  template  aj aw();
};
template  class c : h> {
public:
  c();
};
template  c::c() {
  this->template aw();
}
void i() { d e; }

on recent gcc trunk, does this:

bug610.cc: In substitution of ‘template template using 
aj = typename h::an::aj [with ai = ai; a ad = b; g = c]’:
bug610.cc:10:40:   required by substitution of ‘template
h >::aj h >::aw() [with a ad = 
b; ai = ]’
bug610.cc:17:23:   required from ‘c< , ,
,  >::c() [with
 = int; a ad = b;  = int; 
=
 int]’
bug610.cc:19:19:   required from here
bug610.cc:8:35: internal compiler error: in lookup_template_class_1, at
cp/pt.c:
10076
8 |   template  using aj = typename an::aj;
  |   ^~
0x82a5b3 lookup_template_class_1(tree_node*, tree_node*, tree_node*,
tree_node*,
 int, int)
../../trunk.git/gcc/cp/pt.c:10075
0x828739 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
i
nt, int)
../../trunk.git/gcc/cp/pt.c:10128
0x815633 tsubst(tree_node*, tree_node*, int, tree_node*)
../../trunk.git/gcc/cp/pt.c:15831

The bug first seems to occur sometime between 20200519 and 20200520.

[Bug fortran/95106] Bogus warning from module with long name and an equivalence

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Something like

diff --git a/gcc/fortran/trans-common.c b/gcc/fortran/trans-common.c
index bf163bc4f52..06313873002 100644
--- a/gcc/fortran/trans-common.c
+++ b/gcc/fortran/trans-common.c
@@ -242,8 +242,8 @@ static tree
 gfc_sym_mangled_common_id (gfc_common_head *com)
 {
   int has_underscore;
-  char mangled_name[GFC_MAX_MANGLED_SYMBOL_LEN + 1];
-  char name[GFC_MAX_SYMBOL_LEN + 1];
+  char mangled_name[GFC_MAX_MANGLED_SYMBOL_LEN + 10];
+  char name[GFC_MAX_SYMBOL_LEN + 10];

   /* Get the name out of the common block pointer.  */
   strcpy (name, com->name);

prevents the truncation of the mangled name, including the .eq.0123_ part.

[Bug fortran/95106] Bogus warning from module with long name and an equivalence

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2020-05-21
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||wrong-code
   Priority|P3  |P4

--- Comment #1 from anlauf at gcc dot gnu.org ---
The warning is not only bogus, but indicates that something goes wrong.

Doing an "nm" on the resulting object files, it seems one equivalence is
missing for names of length 60+.

For z1_59.o:

0020 C
m2345678901234567890123456789012345678901234567890123456789.eq.0_
0018 C
m2345678901234567890123456789012345678901234567890123456789.eq.1_

For z1_60.o:

0020 C
m23456789012345678901234567890123456789012345678901234567890.eq._

It seems it cannot disambiguate the two equivalences any more,
and treat them as a single common.

[Bug c++/79627] Ice with type of VLA in lambda

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
 Blocks||16994, 54367

--- Comment #5 from Eric Gallager  ---
(In reply to Martin Liška from comment #4)
> (In reply to Arseny Solokha from comment #3)
> > It is fixed for gcc 10, probably by
> > g:00a49cd840f60774b0e9e0109fb10559bc9a9194.
> 
> Yes, it's fixed with this commit.

So... is there a reason to leave this bug open then? Backports?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994
[Bug 16994] [meta-bug] VLA and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
[Bug 54367] [meta-bug] lambda expressions

[Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to M Welinder from comment #4)
> Sorry about the missing "-v".  It is indeed a x86_64-suse-linux system. 
> (It's not internet facing or I'd go get the full output.)
> 
> "Implementation defined", yes, but the implementation is the os, not the
> compiler/library.

No, that's wrong.

"This document specifies requirements for implementations of the C ++
programming language."

The OS is not an implementation of the C++ programming language. GCC is.

>  The OS gets to choose and, possibly, change its mind
> long after the compiler has written its output.

The OS gets to choose whether that path has any effect for system calls to t he
OS, but it's the C++ implementation that chooses the definition of root-name in
the std::filesystem library.

> > What meaning does //foo have on linux?
> 
> Today, nothing separate, tomorrow who knows?  The OS is at perfect liberty
> to assign a different meaning on Fridays if it so pleases.  Run the linux
> binary
> on windows today and I suspect, but haven't verified, that it matters right
> now.

If you can verify that I'd be interested, but not in a suspicion.

> Note that "cd //tmp" in bash shows that bash takes care not to mangle it.

[Bug libfortran/95195] gfortran poorly handles a program error of writing a namelist to an unformatted file.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Component|fortran |libfortran
   Priority|P3  |P4

--- Comment #2 from anlauf at gcc dot gnu.org ---
The following patch generates a runtime error for namelist read:

diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 77d61421a0f..28744d21143 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -3549,6 +3549,14 @@ namelist_read (st_parameter_dt *dtp)
  name.  */
   namelist_info *prev_nl = NULL;

+  if (dtp->u.p.current_unit->flags.form == FORM_UNFORMATTED)
+{
+  generate_error (>common, LIBERROR_OPTION_CONFLICT,
+ "Namelist formatting not allowed for unit connected "
+ "with FORM='UNFORMATTED'");
+  return;
+}
+
   dtp->u.p.input_complete = 0;
   dtp->u.p.expanded_read = 0;

This generates:

At line 10 of file pr95195.f90 (unit = 10, file = 'test.dat')
Fortran runtime error: Namelist formatting not allowed for unit connected with
FORM='UNFORMATTED'

Error termination. Backtrace:
#0  0x7f80d510f1a7 in finalize_transfer
at ../../../gcc-trunk/libgfortran/io/transfer.c:4128
#1  0x400b3b in test
at /home/anlauf/gcc-bugs/pr95195.f90:10
#2  0x400b9c in main
at /home/anlauf/gcc-bugs/pr95195.f90:12


Regtests cleanly for me.

Similar checks can be added for namelist write, list-directed formatting,
and non-advancing data transfers.  (F2018: 12.3.3.3)

Does this look better?

[Bug target/95169] [10/11 Regression] i386 comparison between nan and 0.0 triggers Invalid operation exception

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #9 from Uroš Bizjak  ---
Fixed for gcc-10.2+.

[Bug target/95256] [11 Regression] ICE in convert_move, at expr.c:278 since r11-263-g7c355156aa20eaec

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Depends on||95125
 CC||crazylht at gmail dot com

--- Comment #3 from Uroš Bizjak  ---
This PR and PR95211 will be fixed by the  for PR95125. Here, the offending
pattern should be renamed to something like

avx512dq_fix_truncv2sfv2di2

and an expander should be added:

(define_expand "fix_truncv2sfv2di2"
  [(set (match_operand:V2DI 0 "register_operand")
(any_fix:V2DI
  (match_operand:V2SF 1 "nonimmediate_operand")))]
  "TARGET_AVX512DQ && TARGET_AVX512VL"
{
  if (!MEM_P (operands[1]))
{
  operands[1] = simplify_gen_subreg (V4SFmode, operands[1], V2SFmode, 0);
  emit_insn (gen_avx512dq_fix_truncv2sfv2di2 (operands[0],
operands[1]));
  DONE;
}
})


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95125
[Bug 95125] Unoptimal code for vectorized conversions

[Bug c++/95262] New: Taking address of function pointer do full concept overload resolution

[barry.revzin at gmail dot com]

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

Bug ID: 95262
   Summary: Taking address of function pointer do full concept
overload resolution
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Reduced from StackOverflow (https://stackoverflow.com/q/61941173/2069064):

template  int f() { return 0; }
template  requires true int f() { return 1; }

int (*p)() = ;

gcc complains that converting the function is ambiguous even though the second
overload is a better candidate than the first. clang accepts.

[Bug target/95256] [11 Regression] ICE in convert_move, at expr.c:278 since r11-263-g7c355156aa20eaec

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #2 from Uroš Bizjak  ---
The patch exposes another case of named pattern with non-conformant operand
mode. 

This time, it is:

(define_insn "fix_truncv2sfv2di2"
  [(set (match_operand:V2DI 0 "register_operand" "=v")
(any_fix:V2DI
  (vec_select:V2SF
(match_operand:V4SF 1 "nonimmediate_operand" "vm")
(parallel [(const_int 0) (const_int 1)]]
  "TARGET_AVX512DQ && TARGET_AVX512VL"
  "vcvttps2qq\t{%1, %0|%0, %q1}"
  [(set_attr "type" "ssecvt")
   (set_attr "prefix" "evex")
   (set_attr "mode" "TI")])

[Bug target/95229] [11 Regression] in mark_jump_label_1

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #10 from Uroš Bizjak  ---
Fixed. (thanks Martin for adjusting the testcase!).

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[ubizjak at gmail dot com]

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

Bug 95229 Summary: [11 Regression] in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug target/95261] New: [11 regression] gcc.target/powerpc/pr80695-p8.c and gcc.target/powerpc/pr80695-p9.c fail starting with r11-478

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95261
   Summary: [11 regression] gcc.target/powerpc/pr80695-p8.c and
gcc.target/powerpc/pr80695-p9.c fail starting with
r11-478
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:a4b48fc47c3406b6f41be093c4615879b7006710, r11-478 

FAIL: gcc.target/powerpc/pr80695-p8.c scan-tree-dump-times slp2 "vectorization
is not profitable" 1
FAIL: gcc.target/powerpc/pr80695-p9.c scan-tree-dump-times slp2 "vectorization
is not profitable" 1

[Bug target/95169] [10/11 Regression] i386 comparison between nan and 0.0 triggers Invalid operation exception

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Uros Bizjak :

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

commit r10-8167-gddfb80adbd91a0e45cc6e04a8b0dbe3ca15ba45f
Author: Uros Bizjak 
Date:   Thu May 21 19:36:32 2020 +0200

i386: Avoid reversing a non-trapping comparison to a trapping one [PR95169]

2020-05-21  Uroš Bizjak  

gcc/ChangeLog:
PR target/95169
* config/i386/i386-expand.c (ix86_expand_int_movcc):
 Avoid reversing a non-trapping comparison to a trapping one.

gcc/testsuite/ChangeLog:
PR target/95169
* gcc.target/i386/pr95169.c: New test.

[Bug sanitizer/95244] GCC 10 no longer builds on RHEL5 [trivial patch]

[lopresti at gmail dot com]

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

--- Comment #2 from Patrick J. LoPresti  ---
Done (https://github.com/google/sanitizers/issues/1253). Thanks.

[Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"

[terra at gnome dot org]

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

--- Comment #4 from M Welinder  ---
Sorry about the missing "-v".  It is indeed a x86_64-suse-linux system.  (It's
not internet facing or I'd go get the full output.)

"Implementation defined", yes, but the implementation is the os, not the
compiler/library.  The OS gets to choose and, possibly, change its mind
long after the compiler has written its output.

> What meaning does //foo have on linux?

Today, nothing separate, tomorrow who knows?  The OS is at perfect liberty to
assign a different meaning on Fridays if it so pleases.  Run the linux binary
on windows today and I suspect, but haven't verified, that it matters right
now.

Note that "cd //tmp" in bash shows that bash takes care not to mangle it.

[Bug target/95260] Confusing comments in cpuid.h

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Martin Liška from comment #1)
> Just a question: why do you create PRs for all these issues?
> Is it because you want to backport fixes to active branches?

That would be nice.

[Bug target/95259] Duplicated codes in libgcc, driver-i386.c and i386-builtins.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #48576|0   |1
is obsolete||

--- Comment #2 from H.J. Lu  ---
Created attachment 48577
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48577=edit
An updated patch

[Bug target/95260] Confusing comments in cpuid.h

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Fixed for GCC 11.

[Bug target/95260] Confusing comments in cpuid.h

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r11-552-ga74630f3207d0bec63710c8c803685a0a4956986
Author: H.J. Lu 
Date:   Thu May 21 07:19:27 2020 -0700

config/i386/cpuid.h: Use hexadecimal in comments

Since Intel SDM uses hexadecimal, use hexadecimal in comments.

PR target/95260
* config/i386/cpuid.h: Use hexadecimal in comments.

[Bug target/95260] Confusing comments in cpuid.h

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Just a question: why do you create PRs for all these issues?
Is it because you want to backport fixes to active branches?

[Bug target/95260] New: Confusing comments in cpuid.h

[hjl.tools at gmail dot com]

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

Bug ID: 95260
   Summary: Confusing comments in cpuid.h
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386, x86-64

cpuid.h has

/* XFEATURE_ENABLED_MASK register bits (%eax == 13, %ecx == 0) */
^^^ This is decimal.
/* Extended State Enumeration Sub-leaf (%eax == 13, %ecx == 1) */
^^^ This is decimal.
/* PT sub leaf (%eax == 14, %ecx == 0) */
^^^ This is hex.

Since Intel SDM uses hex, comments should use hex eveywhere.

[Bug target/95259] Duplicated codes in libgcc, driver-i386.c and i386-builtins.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com

--- Comment #1 from H.J. Lu  ---
Created attachment 48576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48576=edit
A patch

[Bug target/95259] Duplicated codes in libgcc, driver-i386.c and i386-builtins.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |11.0
   Last reconfirmed||2020-05-21

[Bug target/95256] [11 Regression] ICE in convert_move, at expr.c:278 since r11-263-g7c355156aa20eaec

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-21
Summary|[11 Regression] ICE in  |[11 Regression] ICE in
   |convert_move, at expr.c:278 |convert_move, at expr.c:278
   ||since
   ||r11-263-g7c355156aa20eaec
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r11-263-g7c355156aa20eaec.

[Bug target/95212] enum processor_features is out of sync

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:9b7d71fdedcc360ad4fe8322ecb522cb7bf8a0f7

commit r10-8165-g9b7d71fdedcc360ad4fe8322ecb522cb7bf8a0f7
Author: H.J. Lu 
Date:   Thu May 21 05:32:53 2020 -0700

libgcc: Move FEATURE_AVX512VP2INTERSECT after FEATURE_AVX512BF16

Move FEATURE_AVX512VP2INTERSECT after FEATURE_AVX512BF16 to avoid
changing libgcc ABI.

gcc/

PR target/95212
* config/i386/i386-builtins.c (processor_features): Move
F_AVX512VP2INTERSECT after F_AVX512BF16.
(isa_names_table): Likewise.

libgcc/

PR target/95212
* config/i386/cpuinfo.h (processor_features): Move
FEATURE_AVX512VP2INTERSECT after FEATURE_AVX512BF16.

(cherry picked from commit 5855bdfa06fb25c0880af89cb2bfdcdf342beac2)

[Bug c++/94038] [8/9/10 Regression] Compiling with -Wall causes function template body to get needlessly instantiated

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r11-550-gf65a3299a521a44522c1e01724f75e36af22f40b
Author: Patrick Palka 
Date:   Thu May 21 09:03:43 2020 -0400

c++: template instantiation during fold_for_warn [PR94038]

Unfortunately, the previous fix to PR94038 is fragile.  When the
argument to fold_for_warn is a bare CALL_EXPR, then all is well: the
result of maybe_constant_value from fold_for_warn (with
uid_sensitive=true) is reused via the cv_cache in the subsequent call to
maybe_constant_value from cp_fold (with uid_sensitive=false), so we
avoid instantiating bar.

But when the argument to fold_for_warn is more complex, e.g. an
INDIRECT_REF of a CALL_EXPR, as in the testcase below (due to bar()
returning const int& which we need to decay to int) then from
fold_for_warn we call maybe_constant_value on the INDIRECT_REF, and from
cp_fold we call it on the CALL_EXPR, so there is no reuse via the
cv_cache and we therefore end up instantiating bar.

So for a more robust solution to this general issue of warning flags
affecting code generation, it seems that we need a way to globally avoid
template instantiation during constexpr evaluation whenever we're
performing warning-dependent folding.

To that end, this patch replaces the flag constexpr_ctx::uid_sensitive
with a global flag uid_sensitive_constexpr_evaluation_p, and enables it
during fold_for_warn using an RAII helper.

The patch also adds a counter that keeps track of the number of times
uid_sensitive_constexpr_evaluation_p is called and returned true, and we
use this to determine whether the result of constexpr evaluation
was restricted by the flag.  This lets us safely update the cv_cache and
fold_cache from fold_for_warn in the most common case where the flag
did not restrict constexpr evaluation.

gcc/cp/ChangeLog:

PR c++/94038
* constexpr.c (constexpr_ctx::uid_sensitive): Remove field.
(uid_sensitive_constexpr_evaluation_value): Define.
(uid_sensitive_constexpr_evaluation_true_counter): Define.
(uid_sensitive_constexpr_evaluation_p): Define.
(uid_sensitive_constexpr_evaluation_sentinel): Define its
constructor.
(uid_sensitive_constexpr_evaluation_checker): Define its
constructor and its evaluation_restricted_p method.
(get_fundef_copy): Remove 'ctx' parameter.  Use u_s_c_e_p
instead of constexpr_ctx::uid_sensitive.
(cxx_eval_call_expression): Use u_s_c_e_p instead, and test it
last.  Adjust call to get_fundef_copy.
(instantiate_cx_fn_r): Test u_s_c_e_p so that we increment the
counter if necessary.
(cxx_eval_outermost_constant_expr): Remove 'uid_sensitive'
parameter.  Adjust function body accordingly.
(maybe_constant_value): Remove 'uid_sensitive' parameter and
adjust function body accordingly.  Set up a
uid_sensitive_constexpr_evaluation_checker, and use it to
conditionally update the cv_cache.
* cp-gimplify.c (cp_fold): Set up a
uid_sensitive_constexpr_evaluation_checker, and use it to
conditionally update the fold_cache.
* cp-tree.h (maybe_constant_value): Update declaration.
(struct uid_sensitive_constexpr_evaluation_sentinel): Define.
(struct sensitive_constexpr_evaluation_checker): Define.
* expr.c (fold_for_warn): Set up a
uid_sensitive_constexpr_evaluation_sentinel before calling
the folding subroutines.  Drop all but the first argument to
maybe_constant_value.

gcc/testsuite/ChangeLog:

PR c++/94038
* g++.dg/warn/pr94038-2.C: New test.

[Bug target/95259] New: Duplicated codes in libgcc, driver-i386.c and i386-builtins.c

[hjl.tools at gmail dot com]

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

Bug ID: 95259
   Summary: Duplicated codes in libgcc, driver-i386.c and
i386-builtins.c
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
Depends on: 95258, 91695, 95212, 95220
  Target Milestone: ---
Target: i386, x86-64

There are duplicated codes in libgcc, driver-i386.c and i386-builtins.c.
It is very hard to keep them in sync and up to date.  libgcc doesn't enable
any AVX512 ISAs if AVX512 isn't usable.  But driver-i386.c only does it for
some AVX512 ISAs.  libgcc  only supports a subset of ISAs.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91695
[Bug 91695] [X86] get_available_features only sets FEATURE_GFNI and
FEATURE_VPCLMULQDQ when avx512_usable is true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95212
[Bug 95212] enum processor_features is out of sync
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95220
[Bug 95220] Incorrect GFNI dectection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95258
[Bug 95258] -march=native doesn't handle -mavx512vpopcntdq

[Bug target/95212] enum processor_features is out of sync

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:5855bdfa06fb25c0880af89cb2bfdcdf342beac2

commit r11-549-g5855bdfa06fb25c0880af89cb2bfdcdf342beac2
Author: H.J. Lu 
Date:   Thu May 21 05:32:53 2020 -0700

libgcc: Move FEATURE_AVX512VP2INTERSECT after FEATURE_AVX512BF16

Move FEATURE_AVX512VP2INTERSECT after FEATURE_AVX512BF16 to avoid
changing libgcc ABI.

gcc/

PR target/95212
* config/i386/i386-builtins.c (processor_features): Move
F_AVX512VP2INTERSECT after F_AVX512BF16.
(isa_names_table): Likewise.

libgcc/

PR target/95212
* config/i386/cpuinfo.h (processor_features): Move
FEATURE_AVX512VP2INTERSECT after FEATURE_AVX512BF16.

[Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> You didn't provide the requested information when creating a new bug report,
> please see https://gcc.gnu.org/bugs/

We're missing the output of 'gcc -v' but the preprocessed source shows the
target is x86_64-suse-linux, and so this is the expected (and
standard-conforming) behaviour.

What meaning does //foo have on linux? As far as I know the linux kernel
doesn't give it any special meaning.

So for linux targets libstdc++ has a single implementation-defined root-name,
which is the empty string and is never matched in a path.

[Bug target/95258] New: -march=native doesn't handle -mavx512vpopcntdq

[hjl.tools at gmail dot com]

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

Bug ID: 95258
   Summary: -march=native doesn't handle -mavx512vpopcntdq
   Product: gcc
   Version: 8.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

AVX512VPOPCNTDQ check is missing from driver-i386.c

[Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-21
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

[Bug target/95229] [11 Regression] in mark_jump_label_1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:2f20c7040f884b542cadf46fd77188729ab3cb17

commit r11-548-g2f20c7040f884b542cadf46fd77188729ab3cb17
Author: Martin Liska 
Date:   Thu May 21 14:21:31 2020 +0200

Fix a test-case warning.

PR target/95229
* g++.target/i386/pr95229.C: Fix
error: unnamed type with no linkage used
to declare variable â eâ with linkage
with -std=gnu++98.

[Bug tree-optimization/95199] Remove extra variable created for memory reference in loop vectorization.

[zhoukaipeng3 at huawei dot com]

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

--- Comment #4 from Kaipeng Zhou  ---
Sorry for not expressing clearly.

I have debugged the testcase you provided.  Not eliminating them is not caused
by IFN.  The relevant code is in the "get_computation_aff_1" function.

In IVOPTs the IV_STEPs must be checked by function "constant_multiple_of"
before using an IV variable to eliminate the other.  But if the tree_code of
input IV_STEP is SSA_NAME, the function will return false.  In your testcase,
the tree_code of IV_STEP is MULT_EXPR, so it return true.

Gimple for my testcase:
   [local count: 8589933]:
  _83 = (sizetype) inc_y_22(D);
  _84 = _83 * POLY_INT_CST [16, 16];
  _85 = (long unsigned int) inc_y_22(D);
  _86 = _85 * 8;
  _87 = (ssizetype) _86;
  _88 = _87 /[ex] 8;
  _89 = (long unsigned int) _88;
  _90 = VEC_SERIES_EXPR <0, _89>;
  vect_cst__95 = [vec_duplicate_expr] m_17(D);
  _97 = (sizetype) inc_x_20(D);
  _98 = _97 * POLY_INT_CST [16, 16];
  _99 = (long unsigned int) inc_x_20(D);
  _100 = _99 * 8;
  _101 = (ssizetype) _100;
  _102 = _101 /[ex] 8;
  _103 = (long unsigned int) _102;
  _104 = VEC_SERIES_EXPR <0, _103>;
  _109 = (sizetype) inc_x_20(D);
  _110 = _109 * POLY_INT_CST [16, 16];
  _111 = (long unsigned int) inc_x_20(D);
  _112 = _111 * 8;
  _113 = (ssizetype) _112;
  _114 = _113 /[ex] 8;
  _115 = (long unsigned int) _114;
  _116 = VEC_SERIES_EXPR <0, _115>;
  max_mask_123 = .WHILE_ULT (0, 1000, { 0, ... });

   [local count: 429496649]:
  # vectp_b.3_91 = PHI 
  # vectp_a.7_105 = PHI 
  # vectp_a.11_117 = PHI 
  # ivtmp_120 = PHI 
  # loop_mask_93 = PHI 
  vect__4.5_94 = .MASK_GATHER_LOAD (vectp_b.3_91, _90, 8, { 0.0, ... },
loop_mask_93);
  vect__5.6_96 = vect__4.5_94 * vect_cst__95;
  vect__9.9_107 = .MASK_GATHER_LOAD (vectp_a.7_105, _104, 8, { 0.0, ... },
loop_mask_93);
  vect__10.10_108 = vect__5.6_96 + vect__9.9_107;
  .MASK_SCATTER_STORE (vectp_a.11_117, _116, 8, vect__10.10_108, loop_mask_93);
  vectp_b.3_92 = vectp_b.3_91 + _84;
  vectp_a.7_106 = vectp_a.7_105 + _98;
  vectp_a.11_118 = vectp_a.11_117 + _110;
  ivtmp_121 = ivtmp_120 + POLY_INT_CST [2, 2];
  _122 = (unsigned int) ivtmp_121;
  next_mask_124 = .WHILE_ULT (_122, 1000, { 0, ... });
  if (next_mask_124 != { 0, ... })
goto ; [98.00%]
  else
goto ; [2.00%]

_98 and _110 are IV_STEPs.  They are both SSA_NAME, so they cannot currently be
eliminated in IVOPTs.

I am not sure about my opinion.  If wrong, please correct me.  And can you
provide some suggestions on how to solve this problem?  Should I try to enhance
the "constant_multiple_of" function?

[Bug c/95257] New: valgrind gives me error when wprintf in stderr

[daffra.claudio at gmail dot com]

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

Bug ID: 95257
   Summary: valgrind gives me error when wprintf in stderr
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daffra.claudio at gmail dot com
  Target Milestone: ---

this simple program gives me error when i check with valgrind,
this happen in stderr only.

valgrind --leak-check=full --show-leak-kinds=all ./x


#include 
#include 

int main ( void )
{

fwprintf ( stderr , L"valgrind error\n" ) ;
return 0 ;
}

valgrind error :

==7438== Memcheck, a memory error detector
==7438== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7438== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==7438== Command: ./x
==7438== 
valgrind error==7438== 
==7438== HEAP SUMMARY:
==7438== in use at exit: 5,120 bytes in 2 blocks
==7438==   total heap usage: 2 allocs, 0 frees, 5,120 bytes allocated
==7438== 
==7438== 1,024 bytes in 1 blocks are still reachable in loss record 1 of 2
==7438==at 0x4C2FB0F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7438==by 0x4EBA18B: _IO_file_doallocate (filedoalloc.c:101)
==7438==by 0x4EBB88C: _IO_wfile_doallocate (wfiledoalloc.c:70)
==7438==by 0x4ECA378: _IO_doallocbuf (genops.c:365)
==7438==by 0x4EC26C7: _IO_wfile_overflow (wfileops.c:430)
==7438==by 0x4EBFD51: __woverflow (wgenops.c:217)
==7438==by 0x4EBFD51: _IO_wdefault_xsputn (wgenops.c:317)
==7438==by 0x4EC2AD0: _IO_wfile_xsputn (wfileops.c:1012)
==7438==by 0x4EA7089: buffered_vfprintf (vfprintf.c:2343)
==7438==by 0x4EA40FD: vfwprintf (vfprintf.c:1301)
==7438==by 0x4EBEA23: fwprintf (fwprintf.c:33)
==7438==by 0x1086A8: main (in /home/claudio/x)
==7438== 
==7438== 4,096 bytes in 1 blocks are still reachable in loss record 2 of 2
==7438==at 0x4C2FB0F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7438==by 0x4EBB858: _IO_wfile_doallocate (wfiledoalloc.c:79)
==7438==by 0x4ECA378: _IO_doallocbuf (genops.c:365)
==7438==by 0x4EC26C7: _IO_wfile_overflow (wfileops.c:430)
==7438==by 0x4EBFD51: __woverflow (wgenops.c:217)
==7438==by 0x4EBFD51: _IO_wdefault_xsputn (wgenops.c:317)
==7438==by 0x4EC2AD0: _IO_wfile_xsputn (wfileops.c:1012)
==7438==by 0x4EA7089: buffered_vfprintf (vfprintf.c:2343)
==7438==by 0x4EA40FD: vfwprintf (vfprintf.c:1301)
==7438==by 0x4EBEA23: fwprintf (fwprintf.c:33)
==7438==by 0x1086A8: main (in /home/claudio/x)
==7438== 
==7438== LEAK SUMMARY:
==7438==definitely lost: 0 bytes in 0 blocks
==7438==indirectly lost: 0 bytes in 0 blocks
==7438==  possibly lost: 0 bytes in 0 blocks
==7438==still reachable: 5,120 bytes in 2 blocks
==7438== suppressed: 0 bytes in 0 blocks
==7438== 
==7438== For counts of detected and suppressed errors, rerun with: -v
==7438== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

compiler :

gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04).

[Bug target/95255] [10/11 Regression] ICE in gen_roundevendf2, at config/i386/i386.md:16328 since r10-2809-gd3b92f35d84f44a8

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
> $ gcc
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/sse4_1-round-
> roundeven-1.c -mfpmath=both

They are here.

[Bug libgcc/91695] [X86] get_available_features only sets FEATURE_GFNI and FEATURE_VPCLMULQDQ when avx512_usable is true

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
 Status|NEW |RESOLVED
Version|unknown |8.4.1
 Resolution|--- |FIXED

--- Comment #6 from H.J. Lu  ---
Fixed for GCC 11, GCC 10.2, GCC 9.4 and GCC 8.5.

[Bug libgcc/95220] Incorrect GFNI dectection

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-8 branch has been updated by H.J. Lu :

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

commit r8-10263-gaad7ffb62247fce56e03b03dd696b49bbc8913e7
Author: H.J. Lu 
Date:   Tue May 19 14:42:12 2020 -0700

x86: Update GFNI check

Update GFNI check to support processors with SSE and AVX versions of GFNI.

Backport from master
PR target/95220
* config/i386/cpuinfo.c (get_available_features): Fix
FEATURE_GFNI check.

(cherry picked from commit 1e46a443f25d26816536c0c480211714b123a1d5)

[Bug libgcc/91695] [X86] get_available_features only sets FEATURE_GFNI and FEATURE_VPCLMULQDQ when avx512_usable is true

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-8 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:69b35b7c91ebbc1a6df57e957303e904210ad265

commit r8-10264-g69b35b7c91ebbc1a6df57e957303e904210ad265
Author: H.J. Lu 
Date:   Tue May 19 18:55:08 2020 -0700

x86: Update VPCLMULQDQ check

Update VPCLMULQDQ check to support processors with AVX version of
VPCLMULQDQ.

Backport from master
PR target/91695
* config/i386/cpuinfo.c (get_available_features): Fix VPCLMULQDQ
check.

(cherry picked from commit 1e46a443f25d26816536c0c480211714b123a1d5)

[Bug libgcc/91695] [X86] get_available_features only sets FEATURE_GFNI and FEATURE_VPCLMULQDQ when avx512_usable is true

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by H.J. Lu :

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

commit r9-8610-gd7796c9d0c851392f91564cb8715dbea4f33eacd
Author: H.J. Lu 
Date:   Tue May 19 18:55:08 2020 -0700

x86: Update VPCLMULQDQ check

Update VPCLMULQDQ check to support processors with AVX version of
VPCLMULQDQ.

Backport from master
PR target/91695
* config/i386/cpuinfo.c (get_available_features): Fix VPCLMULQDQ
check.

(cherry picked from commit 1e46a443f25d26816536c0c480211714b123a1d5)

[Bug target/95255] [10/11 Regression] ICE in gen_roundevendf2, at config/i386/i386.md:16328 since r10-2809-gd3b92f35d84f44a8

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Please post your compile flags.

[Bug fortran/95195] gfortran poorly handles a program error of writing a namelist to an unformatted file.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2020-05-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Seems to be present in all versions.

Confirmed.

[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component

[tkoenig at gcc dot gnu.org]

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

Bug 94788 Summary: [8/9 Regression] Severe regression leading to double free in 
tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #45 from Thomas Koenig  ---
Fixed on all branches.

[Bug fortran/94361] [8/9/10/11 Regression] Memory leak in nested types with final

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||6.5.0, 7.2.0, 7.4.0, 8.1.0
   Target Milestone|--- |8.5
Summary|Memory leak in nested types |[8/9/10/11 Regression]
   |with final  |Memory leak in nested types
   ||with final
  Known to fail||9.2.0

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Antony Lewis from comment #3)
> On Windows 8.1.0 does not leak, and on NERSC 8.3.0 20190222 (Cray Inc.) also
> does not (but 9.2.0 does)... so not exactly sure what this means about when
> it was introduced.

So adding to known-to-work/fail.

I found a Debian machine with 7.2.0 and compared the dump tree with that of
7.4.1.  There is clearly a chunk of code related to finalization present in
7.2.0, but it is missing in 7.4.1:

  if (>t != 0B)
{
  {
integer(kind=4) stat.5;

if ((real(kind=4)[0:] * restrict) ptr2->t.dat.data == 0B)
  {
stat.5 = 1;
  }
else
  {
__builtin_free (ptr2->t.dat.data);
(real(kind=4)[0:] * restrict) ptr2->t.dat.data = 0B;
stat.5 = 0;
  }
if (stat.5 != 0) goto L.9;
L.9:;
ignore = stat.5;
  }
}
  L.8:;
  {
struct array0_typewithfinal desc.6;

desc.6.dtype = 40;
desc.6.data = (void * restrict) >t.x;
__final_debug_Typewithfinal ();
  }

Looking at the changes to the 7 series leading to 7.4.1 might indicate the
which commit (or backport) caused this.

Marking as (7)/8/9/10/11 regression.

[Bug target/95256] New: [11 Regression] ICE in convert_move, at expr.c:278

[asolokha at gmx dot com]

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

Bug ID: 95256
   Summary: [11 Regression] ICE in convert_move, at expr.c:278
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-11.0.0-alpha20200517 snapshot (g:2b9a271b2d0ba340234a138b7f8289bd7dca2fc5)
ICEs when compiling the following testcase w/ -march=skylake-avx512 -O1
-ftree-slp-vectorize:

struct cy {
  long int m5;
  long int i3;
};

void
ys (struct cy *jl, float u6)
{
  jl->m5 = u6;
  jl->i3 = u6;
}

 x86_64-unknown-linux-gnu-gcc-11.0.0 -march=skylake-avx512 -O1
-ftree-slp-vectorize -c mwwf4yc9.c
during RTL pass: expand
mwwf4yc9.c: In function 'ys':
mwwf4yc9.c:9:10: internal compiler error: in convert_move, at expr.c:278
9 |   jl->m5 = u6;
  |   ~~~^~~~
0x6212ce convert_move(rtx_def*, rtx_def*, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:278
0xa27290 convert_modes(machine_mode, machine_mode, rtx_def*, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:737
0xc94665 expand_fix(rtx_def*, rtx_def*, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/optabs.c:4991
0xa1d1c5 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:9139
0xa2352a expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:10054
0xa3056a expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:8358
0xa3056a expand_expr
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.h:282
0xa3056a expand_assignment(tree_node*, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:5090
0x8fdf17 expand_gimple_stmt_1
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cfgexpand.c:3749
0x8fdf17 expand_gimple_stmt
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cfgexpand.c:3847
0x903b11 expand_gimple_basic_block
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cfgexpand.c:5887
0x9055f6 execute
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cfgexpand.c:6571

[Bug c++/94141] c++20 rewritten operator== recursive call mixing friend and external operators for template class

[Laurent.Rineau__gcc at normalesup dot org]

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

--- Comment #4 from Laurent Rineau  
---
(In reply to Marc Glisse from comment #3)
> It seems that this is as currently specified in C++20, but that some people
> are going to try and change the rules to avoid breaking code like this.

Do you have reference to the discussion on the subject?

[Bug c++/94141] c++20 rewritten operator== recursive call mixing friend and external operators for template class

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-21
 Status|UNCONFIRMED |SUSPENDED
 Ever confirmed|0   |1

--- Comment #3 from Marc Glisse  ---
It seems that this is as currently specified in C++20, but that some people are
going to try and change the rules to avoid breaking code like this.

[Bug target/95255] New: [10/11 Regression] ICE in gen_roundevendf2, at config/i386/i386.md:16328 since r10-2809-gd3b92f35d84f44a8

[marxin at gcc dot gnu.org]

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

Bug ID: 95255
   Summary: [10/11 Regression] ICE in gen_roundevendf2, at
config/i386/i386.md:16328 since
r10-2809-gd3b92f35d84f44a8
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: uros at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu

I see the following ICE:

$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/sse4_1-round-roundeven-1.c
-mfpmath=both
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/sse4_1-round-roundeven-1.c:
In function ‘f1’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/sse4_1-round-roundeven-1.c:7:10:
internal compiler error: in gen_roundevendf2, at config/i386/i386.md:17137
7 |   return __builtin_roundeven (x);
  |  ^~~
0x816eab gen_roundevendf2(rtx_def*, rtx_def*)
/home/marxin/Programming/gcc/gcc/config/i386/i386.md:17137
0xd2b148 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/home/marxin/Programming/gcc/gcc/optabs.c:7479
0xd2b148 expand_insn(insn_code, unsigned int, expand_operand*)
/home/marxin/Programming/gcc/gcc/optabs.c:7510
0xbdd6c4 expand_direct_optab_fn
/home/marxin/Programming/gcc/gcc/internal-fn.c:2959
0x9a60ee expand_call_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2627
0x9a60ee expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3682
0x9a60ee expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3847
0x9abac1 expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:5887
0x9ad6b7 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6571
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/95255] [10/11 Regression] ICE in gen_roundevendf2, at config/i386/i386.md:16328 since r10-2809-gd3b92f35d84f44a8

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Version|11.0|10.1.0
   Target Milestone|--- |10.2
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-21

[Bug middle-end/90302] Implement __builtin_warning

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
There is a prototype patch by Martin Sebor at

https://gcc.gnu.org/pipermail/gcc-patches/2019-October/531812.html

[Bug c++/94923] False positive -Wclass-memaccess with trivially copyable std::optional

[dawid_jurek at vp dot pl]

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

--- Comment #6 from dawid_jurek at vp dot pl ---
I quickly tried trunk and all false positive warnings vanished. 
Thanks Martin.

Regards,
Dawid

[Bug sanitizer/95244] GCC 10 no longer builds on RHEL5 [trivial patch]

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-21
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Thank you for the report.
Please make a patch submission to upstream project:
https://reviews.llvm.org/

We sync the runtime library from LLVM.

[Bug tree-optimization/95248] [11 Regression] GCC produces incorrect code with -O3 for loops since r11-272-gb6ff3ddecfa93d53

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to fail||11.0
Summary|GCC produces incorrect code |[11 Regression] GCC
   |with -O3 for loops  |produces incorrect code
   ||with -O3 for loops since
   ||r11-272-gb6ff3ddecfa93d53
 Ever confirmed|0   |1
  Known to work||10.1.0
   Last reconfirmed||2020-05-21
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Confirmed, started with r11-272-gb6ff3ddecfa93d53.

[Bug target/95253] [10/11 Regression] Build failure on MSys. Wrong dependency file escaping on Windows.

[daniel.f.starke at freenet dot de]

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

--- Comment #1 from Daniel Starke  ---
Edit: I meant colon character, not column operator.

[Bug target/95254] New: aarch64: gcc generate inefficient code with fixed sve vector length

[felix.yang at huawei dot com]

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

Bug ID: 95254
   Summary: aarch64: gcc generate inefficient code with fixed sve
vector length
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.yang at huawei dot com
  Target Milestone: ---
Target: aarch64

Test case:

typedef short __attribute__((vector_size (8))) v4hi;

typedef union U4HI { v4hi v; short a[4]; } u4hi;

short b[4];

void pass_v4hi (v4hi v)
{
int i;
u4hi u;
u.v = v;
for (i = 0; i < 4; i++)
  b[i] = u.a[i];
};

$ gcc -O2 -ftree-slp-vectorize -S -march=armv8.2-a+sve foo.c
assembly code:
pass_v4hi:
.LFB0:
.cfi_startproc
adrpx0, .LANCHOR0
str d0, [x0, #:lo12:.LANCHOR0]
ret
.cfi_endproc

$ gcc -O2 -ftree-slp-vectorize -S -march=armv8.2-a+sve -msve-vector-bits=256
foo.c
assembly code:
pass_v4hi:
.LFB0:
.cfi_startproc
sub sp, sp, #16
.cfi_def_cfa_offset 16
ptrue   p0.b, vl32
adrpx0, .LANCHOR0
add x0, x0, :lo12:.LANCHOR0
str d0, [sp, 8]
ld1hz0.d, p0/z, [sp, #1, mul vl]
st1hz0.d, p0, [x0]
add sp, sp, 16
.cfi_def_cfa_offset 0
ret
.cfi_endproc


The root cause here is that we choose a different mode in
aarch64_vectorize_related_mode[1]: VNx2HImode instead of V4HImode.
Then in the final tree ssa forwprop pass, we need to do a VIEW_CONVERT from
V4HImode to VNx2HImode.
One way to fix this is to catch and simplify the pattern in
aarch64_expand_sve_mem_move, emitting a mov pattern of V4HImode instead.
I am assuming endianness does not make a difference here. Will propose a patch
for comments.


[1] call trace:
(gdb) bt
#0  aarch64_vectorize_related_mode (vector_mode=E_VNx8HImode, element_mode=...,
nunits=...) at ../../gcc-git/gcc/config/aarch64/aarch64.c:2377
#1  0x012983b4 in related_vector_mode (vector_mode=E_VNx8HImode,
element_mode=..., nunits=...) at ../../gcc-git/gcc/stor-layout.c:535
#2  0x01652918 in get_related_vectype_for_scalar_type
(prevailing_mode=E_VNx8HImode, scalar_type=0xb22da498, nunits=...)
at ../../gcc-git/gcc/tree-vect-stmts.c:11463
#3  0x01653304 in get_vectype_for_scalar_type (vinfo=0x2f0dc80,
scalar_type=0xb22da498, group_size=4)
at ../../gcc-git/gcc/tree-vect-stmts.c:11545
#4  0x016533a0 in get_vectype_for_scalar_type (vinfo=0x2f0dc80,
scalar_type=0xb22da498, node=0x2e5d460)
at ../../gcc-git/gcc/tree-vect-stmts.c:11569
#5  0x016987e8 in vect_get_constant_vectors (vinfo=0x2f0dc80,
slp_node=0x2e53080, op_num=0, vec_oprnds=0xc738)
at ../../gcc-git/gcc/tree-vect-slp.c:3562
#6  0x016993f8 in vect_get_slp_defs (vinfo=0x2f0dc80,
slp_node=0x2e53080, vec_oprnds=0xc7a8, n=1) at
../../gcc-git/gcc/tree-vect-slp.c:3786
#7  0x01631c70 in vect_get_vec_defs (vinfo=0x2f0dc80,
op0=0xb20e3120, op1=0x0, stmt_info=0x2feef60, vec_oprnds0=0xcdd0,
vec_oprnds1=0x0,
slp_node=0x2e53080) at ../../gcc-git/gcc/tree-vect-stmts.c:1726
#8  0x01648bc8 in vectorizable_store (vinfo=0x2f0dc80,
stmt_info=0x2feef60, gsi=0xdad0, vec_stmt=0xd5b0,
slp_node=0x2e53080,
cost_vec=0x0) at ../../gcc-git/gcc/tree-vect-stmts.c:8186
#9  0x01651808 in vect_transform_stmt (vinfo=0x2f0dc80,
stmt_info=0x2feef60, gsi=0xdad0, slp_node=0x2e53080,
slp_node_instance=0x2fefe70)
at ../../gcc-git/gcc/tree-vect-stmts.c:11184
#10 0x0169a4a0 in vect_schedule_slp_instance (vinfo=0x2f0dc80,
node=0x2e53080, instance=0x2fefe70) at ../../gcc-git/gcc/tree-vect-slp.c:4134
#11 0x0169aaac in vect_schedule_slp (vinfo=0x2f0dc80) at
../../gcc-git/gcc/tree-vect-slp.c:4258
#12 0x016972f0 in vect_slp_bb_region (region_begin=..., region_end=...,
datarefs=..., n_stmts=10) at ../../gcc-git/gcc/tree-vect-slp.c:3227
#13 0x01697c60 in vect_slp_bb (bb=0xb22ce340) at
../../gcc-git/gcc/tree-vect-slp.c:3350
#14 0x016a56f0 in (anonymous namespace)::pass_slp_vectorize::execute
(this=0x2e6aae0, fun=0xb2116000) at
../../gcc-git/gcc/tree-vectorizer.c:1320

[Bug target/95253] New: [10/11 Regression] Build failure on MSys. Wrong dependency file escaping on Windows.

[daniel.f.starke at freenet dot de]

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

Bug ID: 95253
   Summary: [10/11 Regression] Build failure on MSys. Wrong
dependency file escaping on Windows.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

Previously in gcc 9.3.0, escaping of the dependency file output still worked
well. Now I get a dependency check error from make when building mingw-w64 crt
due to wrong output escaping in gcc 10.1.0.
9.3.0 output:
 E:/msys/mingw64/include/windows.h
10.1.0 output:
 E\:/msys/mingw64/include/windows.h
Obviously, the column operator should not be escaped here.

Compiled gcc in both cases on MSys/MinGW (not MSys2) with:
Target: x86_64-w64-mingw32
Configured with: ../gcc-src/configure --enable-languages=c,c++
--enable-seh-exceptions --enable-threads=posix --disable-nls
--enable-shared=libstdc++ --enable-static --enable-fully-dynamic-string
--enable-lto --enable-plugins --enable-libgomp --with-dwarf2
--disable-win32-registry --enable-version-specific-runtime-libs
--prefix=/mingw64 --with-sysroot=/mingw64 --target=x86_64-w64-mingw32
--enable-targets=all --enable-checking=release
--with-gmp=/new-gcc/lib/gmp-6.1.2 --with-mpfr=/new-gcc/lib/mpfr-3.1.6
--with-mpc=/new-gcc/lib/mpc-1.1.0 --with-isl=/new-gcc/lib/isl-0.18
--with-host-libstdcxx='-lstdc++ -lsupc++'
Thread model: posix
Supported LTO compression algorithms: zlib

[Bug target/95125] Unoptimal code for vectorized conversions

[crazylht at gmail dot com]

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

--- Comment #4 from Hongtao.liu  ---
(In reply to Uroš Bizjak from comment #3)
> It turns out that a bunch of patterns have to be renamed (and testcases
> added).
> 
> Easyhack, waiting for someone to show some love to conversion patterns in
> sse.md.

I'll take a look.

[Bug libgomp/95150] Some offloaded programs crash with openmp

[chinoune.mehdi at hotmail dot com]

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

--- Comment #4 from Chinoune  ---
after some tests, It looks like it fails with only with small sizes.
The program doesn't crash when increasing matrices size. and It takes a shorter
time to execute!.

[Bug libstdc++/93983] std::filesystem::path is not concept-friendly

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:566ba72126288272607374a32ac646dcd36fe584

commit r10-8163-g566ba72126288272607374a32ac646dcd36fe584
Author: Jonathan Wakely 
Date:   Thu May 21 07:47:17 2020 +0100

libstdc++: Avoid constraint recursion with iterator_traits (PR 93983)

Checking whether a filesystem::path constructor argument is an iterator
requires instantiating std::iterator_traits. In C++20 that checks for
satisfaction of std::iterator_traits constraints, which checks if the
type is copyable, which can end up recursing back to the path
constructor. The fix in LWG 3420 is to reorder the cpp17-iterator
concept's constraints to check if the type looks vaguely like an
iterator before checking copyable. That avoids the recursion for types
which definitely aren't iterators, but isn't foolproof.

Backport from mainline
2020-05-21  Jonathan Wakely  

PR libstdc++/93983
* include/bits/iterator_concepts.h (__detail::__cpp17_iterator):
Reorder constraints to avoid recursion when constructors use
iterator_traits (LWG 3420).
* testsuite/24_iterators/customization_points/lwg3420.cc: New test.

[Bug c++/67491] [meta-bug] concepts issues

[redi at gcc dot gnu.org]

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

Bug 93983 Summary: std::filesystem::path is not concept-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983

   What|Removed |Added

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

[Bug libstdc++/93983] std::filesystem::path is not concept-friendly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #13 from Jonathan Wakely  ---
Fixed for 10.2

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

[bina2374 at gmail dot com]

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

Bug ID: 95252
   Summary: testcase gcc.dg/torture/pr67916.c failure when testing
with -msave-restore
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bina2374 at gmail dot com
CC: kito at gcc dot gnu.org, wilson at gcc dot gnu.org
  Target Milestone: ---
Target: riscv64-unknown-elf

FAIL: gcc.dg/torture/pr67916.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test

The ABI is lp64d, arch is rv64imafdc, and mcmodel is medany.

The full execution command line is:
/bin/riscv64-unknown-elf-gcc
/gcc/testsuite/gcc.dg/torture/pr67916.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -msave-restore -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
-lm -o ./pr67916.exe

Execute with qemu:
$ /bin/qemu-riscv64./pr67916.exe
Segmentation fault (core dumped)

By the way, I try to reduce the number of compilation options, and found the
smallest combination of options that will cause an execution error:
/bin/riscv64-unknown-elf-gcc
/gcc/testsuite/gcc.dg/torture/pr67916.c -msave-restore -O3
-funroll-loops -lm  -o ./pr67916.exe

[Bug target/69493] Poor code generation for return of struct containing vectors on PPC64LE

[luoxhu at gcc dot gnu.org]

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||luoxhu at gcc dot gnu.org

--- Comment #9 from luoxhu at gcc dot gnu.org ---
No load/store on Power9.
cat pr69493.s
.file   "pr69493.c"
.abiversion 2
.section".text"
.align 2
.p2align 4,,15
.globl test_big_double
.type   test_big_double, @function
test_big_double:
.LFB0:
.cfi_startproc
mfvsrd 7,1
mfvsrd 10,2
mfvsrd 8,3
mfvsrd 9,4
mtvsrdd 34,10,7
mtvsrdd 35,9,8
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.cfi_endproc
.LFE0:
.size   test_big_double,.-test_big_double
.ident  "GCC: (GNU) 9.2.1 20191023 (Advance-Toolchain 13.0-1)
[aba1f4e8b6ac]"
.gnu_attribute 4, 5
.section.note.GNU-stack,"",@progbits

[Bug libgcc/91695] [X86] get_available_features only sets FEATURE_GFNI and FEATURE_VPCLMULQDQ when avx512_usable is true

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Martin Liska
:

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

commit r10-8162-gefcf41fcfa7351f2e941075d2f1fd73cc282de5b
Author: H.J. Lu 
Date:   Tue May 19 18:55:08 2020 -0700

x86: Update VPCLMULQDQ check

Update VPCLMULQDQ check to support processors with AVX version of
VPCLMULQDQ.

Backport from master
PR target/91695
* config/i386/cpuinfo.c (get_available_features): Fix VPCLMULQDQ
check.

(cherry picked from commit 1e46a443f25d26816536c0c480211714b123a1d5)

[Bug libstdc++/93983] std::filesystem::path is not concept-friendly

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-541-gf094665d465cdf8903797cc58bea13007e588616
Author: Jonathan Wakely 
Date:   Thu May 21 07:32:15 2020 +0100

libstdc++: Avoid constraint recursion with iterator_traits (PR 93983)

Checking whether a filesystem::path constructor argument is an iterator
requires instantiating std::iterator_traits. In C++20 that checks for
satisfaction of std::iterator_traits constraints, which checks if the
type is copyable, which can end up recursing back to the path
constructor. The fix in LWG 3420 is to reorder the cpp17-iterator
concept's constraints to check if the type looks vaguely like an
iterator before checking copyable. That avoids the recursion for types
which definitely aren't iterators, but isn't foolproof.

PR libstdc++/93983
* include/bits/iterator_concepts.h (__detail::__cpp17_iterator):
Reorder constraints to avoid recursion when constructors use
iterator_traits (LWG 3420).
* testsuite/24_iterators/customization_points/lwg3420.cc: New test.

[Bug c++/95233] Failure to compile regression in GCC 10.1 and 11 trunk with C++ 20

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|WAITING |RESOLVED

--- Comment #5 from Jonathan Wakely  ---
This indeed PR 93983, which is caused by a defect in C++20.

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

[Bug libstdc++/93983] std::filesystem::path is not concept-friendly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||s_gccbugzilla at nedprod dot 
com

--- Comment #10 from Jonathan Wakely  ---
*** Bug 95233 has been marked as a duplicate of this bug. ***

[Bug target/30271] -mstrict-align can an store extra for struct agrument passing

[luoxhu at gcc dot gnu.org]

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||luoxhu at gcc dot gnu.org

--- Comment #12 from luoxhu at gcc dot gnu.org ---
Fixed at least from GCC 4.9.4?
$ /opt/at8.0/bin/gcc -O3 -c -S  pr30271.c -mstrict-align
$ cat pr30271.s
.file   "pr30271.c"
.abiversion 2
.section".toc","aw"
.section".text"
.align 2
.p2align 4,,15
.globl f
.type   f, @function
f:
extsh 9,3
srawi 3,3,16
add 3,9,3
extsw 3,3
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size   f,.-f
.ident  "GCC: (GNU) 4.9.4 20150824 (Advance-Toolchain-at8.0)
[ibm/gcc-4_9-branch, revision: 227153 merged from gcc-4_9-branch, revision
227151]"
.section.note.GNU-stack,"",@progbits