[Bug target/96933] rs6000: inefficient code for char/short vec CTOR

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:025f434a87336e38bf5140fba2005081876aa911

commit r11-4731-g025f434a87336e38bf5140fba2005081876aa911
Author: Kewen Lin 
Date:   Thu Nov 5 00:04:10 2020 -0600

rs6000: Use direct move for char/short vector CTOR [PR96933]

This patch is to make vector CTOR with char/short leverage direct
move instructions when they are available.  With one constructed
test case, it can speed up 145% for char and 190% for short on P9.

Tested SPEC2017 x264_r at -Ofast on P9, it gets 1.61% speedup
(but based on unexpected SLP see PR96789).

Bootstrapped/regtested on powerpc64{,le}-linux-gnu P8 and
powerpc64le-linux-gnu P9.

gcc/ChangeLog:

PR target/96933
* config/rs6000/rs6000.c (rs6000_expand_vector_init): Use direct
move
instructions for vector construction with char/short types.
* config/rs6000/rs6000.md (p8_mtvsrwz_v16qisi2): New define_insn.
(p8_mtvsrd_v16qidi2): Likewise.

gcc/testsuite/ChangeLog:

PR target/96933
* gcc.target/powerpc/pr96933-1.c: New test.
* gcc.target/powerpc/pr96933-2.c: New test.
* gcc.target/powerpc/pr96933-3.c: New test.
* gcc.target/powerpc/pr96933-4.c: New test.
* gcc.target/powerpc/pr96933.h: New test.
* gcc.target/powerpc/pr96933-run.h: New test.

[Bug target/97724] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

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

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||10.2.0
  Known to fail||11.0
   Last reconfirmed||2020-11-05
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug target/97724] New: [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

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

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

Bug ID: 97724
   Summary: [11 Regression] ICE in insn_default_length, at
config/i386/i386.md:15325 since
r11-4578-gd10f3e900b0377b4
   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: hjl at gcc dot gnu.org, qinzhao at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu

The following fails:

$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/zero-scratch-regs-11.c
-msoft-float -c
In file included from
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/zero-scratch-regs-11.c:4:
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:
In function ‘foo9’:
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:77:1:
error: unrecognizable insn:
   77 | }
  | ^
(insn 27 67 28 2 (set (reg:XF 8 st)
(const_double:XF 0.0 [0x0.0p+0]))
"/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c":77:1
-1
 (nil))
during RTL pass: shorten
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:77:1:
internal compiler error: in insn_default_length, at config/i386/i386.md:15325
0x6c85cb _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:108
0x6c85e7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:116
0x7afcad insn_default_length(rtx_insn*)
/home/marxin/Programming/gcc/gcc/config/i386/i386.md:15325
0xa906e9 shorten_branches(rtx_insn*)
/home/marxin/Programming/gcc/gcc/final.c:1118
0xa9074f rest_of_handle_shorten_branches
/home/marxin/Programming/gcc/gcc/final.c:4753
0xa9074f execute
/home/marxin/Programming/gcc/gcc/final.c:4782
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug debug/97718] [11 regression] Excessive GDB memory usage after GCC "Save some memory at debug stream-in time"

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

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

--- Comment #2 from Richard Biener  ---
Using gdb 8.3.1 on openSUSE Leap 15.2 doesn't show the excessive memory use.

The only difference in readelf -w of the binary before/after the patch is

--- /tmp/a  2020-11-05 08:58:26.636803199 +0100
+++ /tmp/b  2020-11-05 08:58:29.912837061 +0100
@@ -280,7 +280,7 @@
 <142>   DW_AT_abstract_origin: <0x2f9>
 <146>   DW_AT_location: 1 byte block: 54   (DW_OP_reg4 (rsi))
  <2><148>: Abbrev Number: 5 (DW_TAG_inlined_subroutine)
-<149>   DW_AT_abstract_origin: <0x2df>
+<149>   DW_AT_abstract_origin: <0x119>
 <14d>   DW_AT_entry_pc: 0x4004e0
 <155>   DW_AT_GNU_entry_view: 0
 <156>   DW_AT_low_pc  : 0x4004e0
@@ -756,7 +756,7 @@
 DW_AT_location DW_FORM_exprloc
 DW_AT value: 0 DW_FORM value: 0
5  DW_TAG_inlined_subroutine[has children]
-DW_AT_abstract_origin DW_FORM_ref_addr
+DW_AT_abstract_origin DW_FORM_ref4
 DW_AT_entry_pc DW_FORM_addr
 DW_AT_GNU_entry_view DW_FORM_data1
 DW_AT_low_pc   DW_FORM_addr

unpatched the abstract origin directly refered to the abstract origin of the
now refered DIE:

 <1><119>: Abbrev Number: 2 (DW_TAG_subprogram)
<11a>   DW_AT_abstract_origin: <0x2df>
<11e>   DW_AT_low_pc  : 0x4004d0
<126>   DW_AT_high_pc : 0x40
<12e>   DW_AT_frame_base  : 1 byte block: 9c(DW_OP_call_frame_cfa)
<130>   DW_AT_GNU_all_call_sites: 1
<130>   DW_AT_sibling : <0x1ff>

...

 <1><2df>: Abbrev Number: 9 (DW_TAG_subprogram)
<2e0>   DW_AT_name: fn2
<2e4>   DW_AT_decl_file   : 1
<2e5>   DW_AT_decl_line   : 12
<2e6>   DW_AT_decl_column : 1
<2e7>   DW_AT_prototyped  : 1
<2e7>   DW_AT_type: <0x2ad>
<2eb>   DW_AT_sibling : <0x304>


I guess we're splitting / re-inlining fn2 here.  The way the patch has
an effect is via

static inline void
add_abstract_origin_attribute (dw_die_ref die, tree origin)
{
  dw_die_ref origin_die = NULL;

  /* For late LTO debug output we want to refer directly to the abstract
 DIE in the early debug rather to the possibly existing concrete
 instance and avoid creating that just for this purpose.  */
  sym_off_pair *desc;
  if (in_lto_p
  && external_die_map
  && (desc = external_die_map->get (origin)))
{
  add_AT_external_die_ref (die, DW_AT_abstract_origin,
   desc->sym, desc->off);
  return;
}

which previously made the direct reference to the early debug origin
even when a local DIE for it was already created.

We can fix this by unwrapping one level.

Now the interesting thing is that before the change we had

FAIL: gcc.dg/guality/pr54519-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  -DPREVENT_OPTIMIZATION line 17 y == 25
FAIL: gcc.dg/guality/pr54519-4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 17 y == 25

while after it

FAIL: gcc.dg/guality/pr54519-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  -DPREVENT_OPTIMIZATION line 22 y == 68
FAIL: gcc.dg/guality/pr54519-4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 22 y == 68

clearly the old DWARF was better so I'm going to restore it but sth in the
location list processing seems off ...

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed||2020-11-05
  Known to work||10.2.0
  Known to fail||11.0
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Confirmed, started with r11-4135-ge864d395b4e862ce.

[Bug gcov-profile/97722] undefined symbol: __gcov_indirect_call_callee

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

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Martin Liška  ---
It seems that you mix objects generated by GCC 9+ and something older.
I changed the variable __gcov_indirect_call_call in:

  r9-3281-g3edbcdbead288664(04 Oct 2018 12:41)(mli...@suse.cz): [took: 0.421s]
result: FAILED (1)
nm: /usr/lib64/libLLVM.so.10: undefined symbol:
_ZNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEC1Ev, version
GLIBCXX_3.4.26

Fix divergence in indirect profiling (PR gcov-profile/84107).

2018-10-04  Martin Liska  

PR gcov-profile/84107
* tree-profile.c (init_ic_make_global_vars):
Remove ic_void_ptr_var and ic_gcov_type_ptr_var.
Come up with new ic_tuple* variables.  Emit
__gcov_indirect_call{,_topn} variables.
(gimple_gen_ic_profiler): Access the variable
and emit gimple.
(gimple_gen_ic_func_profiler): Access
__gcov_indirect_call.callee field.
(gimple_init_gcov_profiler): Use ptr_type_node.
* value-prof.c (gimple_ic): Use ptr_type_node.
2018-10-04  Martin Liska  

PR gcov-profile/84107
* libgcov-profiler.c (__gcov_indirect_call):
Change type to indirect_call_tuple.
(struct indirect_call_tuple): New struct.
(__gcov_indirect_call_topn_profiler): Change type.
(__gcov_indirect_call_profiler_v2): Use the new
variables.
* libgcov.h (struct indirect_call_tuple): New struct
definition.

From-SVN: r264840

[Bug target/97724] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
How is this different from PR97715 ?  -msoft-float is -mno-80387 ...
m80387
Target Report Mask(80387) Save
Use hardware fp.

msoft-float
Target InverseMask(80387) Save
Do not use hardware fp.

[Bug target/96933] rs6000: inefficient code for char/short vec CTOR

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #12 from Kewen Lin  ---
Should be done with latest trunk.

[Bug tree-optimization/97725] New: ICE at -Os and above: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 97725
   Summary: ICE at -Os and above: tree check: expected class
‘type’, have ‘exceptional’ (error_mark) in
useless_type_conversion_p, at gimple-expr.c:87
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[555] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201105 (experimental) [master revision
8f565d255a3:fff11f1136a:35c125cb6ac47fa97aa5ee22f987a38e63adad08] (GCC)
[556] %
[556] % gcctk -O1 -c small.c
[557] %
[557] % gcctk -Os -c small.c
during GIMPLE pass: evrp
small.c: In function ‘main’:
small.c:25:1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87
   25 | }
  | ^
0x5fdbc9 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-trunk/gcc/tree.c:9802
0x9bb5c3 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-trunk/gcc/tree.h:3436
0x9bb5c3 useless_type_conversion_p(tree_node*, tree_node*)
../../gcc-trunk/gcc/gimple-expr.c:87
0xd514f0 verify_gimple_phi
../../gcc-trunk/gcc/tree-cfg.c:5013
0xd514f0 verify_gimple_in_cfg(function*, bool)
../../gcc-trunk/gcc/tree-cfg.c:5342
0xc0102e execute_function_todo
../../gcc-trunk/gcc/passes.c:2039
0xc01f12 execute_todo
../../gcc-trunk/gcc/passes.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[558] %
[558] % cat small.c
int a;
unsigned b;

int main() {
  if (a) {
goto L1;
while (1)
  while (1) {
long e = -1L, g;
int f, h, i;
  L1:
a = f;
  L2:
g = e;
f = h || g;
e = ~(f & b);
if (i || g < -1L) {
  ~(g || 0);
  break;
}
goto L2;
  }
  }
  return 0;
}

[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

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

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

--- Comment #23 from Martin Liška  ---
*** Bug 97724 has been marked as a duplicate of this bug. ***

[Bug target/97724] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Sorry, I didn't take much attention to it.

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

[Bug target/97726] New: simd intrinsics tests fail on armeb

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

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

Bug ID: 97726
   Summary: simd intrinsics tests fail on armeb
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Several arm/simd tests fail on armeb (as opposed to arm):
FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld2_bf16
FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies
test_vld2_dup_bf16
FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld2q_bf16
FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies
test_vld2q_dup_bf16
FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld3_bf16
FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies
test_vld3_dup_bf16
FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld3q_bf16
FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies
test_vld3q_dup_bf16
FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld4_bf16
FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies
test_vld4_dup_bf16
FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld4q_bf16
FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies
test_vld4q_dup_bf16
FAIL: gcc.target/arm/simd/bf16_vstn_1.c check-function-bodies test_vst2_bf16
FAIL: gcc.target/arm/simd/bf16_vstn_1.c check-function-bodies test_vst2q_bf16
FAIL: gcc.target/arm/simd/bf16_vstn_1.c check-function-bodies test_vst3_bf16
FAIL: gcc.target/arm/simd/bf16_vstn_1.c check-function-bodies test_vst3q_bf16
FAIL: gcc.target/arm/simd/bf16_vstn_1.c check-function-bodies test_vst4_bf16
FAIL: gcc.target/arm/simd/bf16_vstn_1.c check-function-bodies test_vst4q_bf16
FAIL: gcc.target/arm/simd/vdot-2-1.c (test for excess errors)
FAIL: gcc.target/arm/simd/vdot-2-2.c (test for excess errors)
FAIL: gcc.target/arm/simd/vldn_lane_bf16_1.c check-function-bodies
test_vld2_lane_bf16
FAIL: gcc.target/arm/simd/vldn_lane_bf16_1.c check-function-bodies
test_vld2q_lane_bf16
FAIL: gcc.target/arm/simd/vldn_lane_bf16_1.c check-function-bodies
test_vld3_lane_bf16
FAIL: gcc.target/arm/simd/vldn_lane_bf16_1.c check-function-bodies
test_vld3q_lane_bf16
FAIL: gcc.target/arm/simd/vldn_lane_bf16_1.c check-function-bodies
test_vld4_lane_bf16
FAIL: gcc.target/arm/simd/vldn_lane_bf16_1.c check-function-bodies
test_vld4q_lane_bf16
FAIL: gcc.target/arm/simd/vmmla_1.c (test for excess errors)
FAIL: gcc.target/arm/simd/vstn_lane_bf16_1.c check-function-bodies
test_vst2_lane_bf16
FAIL: gcc.target/arm/simd/vstn_lane_bf16_1.c check-function-bodies
test_vst2q_lane_bf16
FAIL: gcc.target/arm/simd/vstn_lane_bf16_1.c check-function-bodies
test_vst3_lane_bf16
FAIL: gcc.target/arm/simd/vstn_lane_bf16_1.c check-function-bodies
test_vst3q_lane_bf16
FAIL: gcc.target/arm/simd/vstn_lane_bf16_1.c check-function-bodies
test_vst4_lane_bf16
FAIL: gcc.target/arm/simd/vstn_lane_bf16_1.c check-function-bodies
test_vst4q_lane_bf16


For instance when GCC is configured:
--target armeb-none-linux-gnueabihf
--with-mode arm
--with-cpu cortex-a9
--with-fpu neon-fp16

[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #7 from Christophe Lyon  ---
I see it again rather frequently since a couple of days ago. (cross x86_64 ->
arm)

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Aldy Hernandez  ---
The ranger is analyzing a statement with an integer overflow, and creating a
non-legacy range that is invalid:

(gdb) p debug(stmt)
if (_1 != -1(OVF))

(gdb) p debug(op2_range)
int [-1(OVF), -1(OVF)]

(gdb) p op2_range.legacy_mode_p()
$8 = false

Legacy ranges allow TREE_OVERFLOW to creep in, as the verifier allows symbolics
and other end points that are not comparable at compile time (cmp == -2 below):

case VR_ANTI_RANGE:
case VR_RANGE:
  {
gcc_assert (m_num_ranges == 1);
int cmp = compare_values (tree_lower_bound (0), tree_upper_bound (0));
gcc_assert (cmp == 0 || cmp == -1 || cmp == -2);
return;
  }

However, we're a bit more strict in irange.  We don't allow un-comparable
endpoints and TREE_OVERFLOW integers are such.

I'm not sure where to fix this.

Is the original statement valid gimple?  Richard has mentioned that any time
there's a TREE_OVERFLOW in the IL, it's a sign of a bug.  If the IL is wrong,
we should tackle the source problem.

If the IL is ocrrect, then perhaps we could drop OVF at range creation.

[Bug debug/97718] [11 regression] Excessive GDB memory usage after GCC "Save some memory at debug stream-in time"

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:1436ef2a57e79b6b8ce5b03e32a38dd64f46c97c

commit r11-4733-g1436ef2a57e79b6b8ce5b03e32a38dd64f46c97c
Author: Richard Biener 
Date:   Thu Nov 5 09:27:28 2020 +0100

debug/97718 - fix abstract origin references after last change

The change to clear the external_die_map slot after creating
the concrete instance DIE broke abstract origin processing which
tried to make sure to have those point to the early abstract instance
and not the concrete instance.  The following restores this by
eventually following the abstract origin link in the concrete instance.

2020-11-05  Richard Biener  

PR debug/97718
* dwarf2out.c (add_abstract_origin_attribute): Make sure to
point to the abstract instance.

[Bug debug/97718] [11 regression] Excessive GDB memory usage after GCC "Save some memory at debug stream-in time"

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Should be fixed now.

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Seems ivopts changes:
@@ -24,7 +24,7 @@ z6 (char * tw)
[local count: 955630225]:
   # ot.1_12 = PHI <_1(6), ot.1_11(5)>
   _1 = ot.1_12 + -1;
-  if (_1 >= 0)
+  if (_1 != -1(OVF))
 goto ; [89.00%]
   else
 goto ; [11.00%]

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

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

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

--- Comment #4 from Jakub Jelinek  ---
We have drop_tree_overflow, so perhaps ivopts could use if (TREE_OVERFLOW_P
(whatever)) whatever = drop_tree_overflow (whatever); somewhere.

[Bug target/97727] New: bf16_vstN_lane_2 test fails on aarch64_be

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

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

Bug ID: 97727
   Summary: bf16_vstN_lane_2 test fails on aarch64_be
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

The intrinsics test bf16_vstN_lane_2.c fails on aarch64_be:
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O0  
scan-assembler-times st2\\t{v0.h - v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O0  
scan-assembler-times st2\\t{v2.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O0  
scan-assembler-times st4\\t{v0.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O0  
scan-assembler-times st4\\t{v4.h - v7.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O1  
scan-assembler-times st2\\t{v0.h - v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O1  
scan-assembler-times st2\\t{v2.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O1  
scan-assembler-times st4\\t{v0.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O1  
scan-assembler-times st4\\t{v4.h - v7.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O2  
scan-assembler-times st2\\t{v0.h - v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O2  
scan-assembler-times st2\\t{v2.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O2  
scan-assembler-times st4\\t{v0.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O2  
scan-assembler-times st4\\t{v4.h - v7.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none   scan-assembler-times st2\\t{v0.h
- v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none   scan-assembler-times st2\\t{v2.h
- v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none   scan-assembler-times st4\\t{v0.h
- v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none   scan-assembler-times st4\\t{v4.h
- v7.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects   scan-assembler-times st2\\t{v0.h -
v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects   scan-assembler-times st2\\t{v2.h -
v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects   scan-assembler-times st4\\t{v0.h -
v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects   scan-assembler-times st4\\t{v4.h -
v7.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O3 -g  
scan-assembler-times st2\\t{v0.h - v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O3 -g  
scan-assembler-times st2\\t{v2.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O3 -g  
scan-assembler-times st4\\t{v0.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -O3 -g  
scan-assembler-times st4\\t{v4.h - v7.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -Og -g  
scan-assembler-times st2\\t{v0.h - v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -Og -g  
scan-assembler-times st2\\t{v2.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -Og -g  
scan-assembler-times st4\\t{v0.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -Og -g  
scan-assembler-times st4\\t{v4.h - v7.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -Os  
scan-assembler-times st2\\t{v0.h - v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -Os  
scan-assembler-times st2\\t{v2.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c   -Os  
scan-assembler-times st4\\t{v0.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16

[Bug tree-optimization/97104] [11 Regression] aarch64, SVE: ICE in vect_get_loop_mask since r11-3070-g783dc66f9cc

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

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

--- Comment #2 from Alex Coplan  ---
For the related testcase:

int a, c, d, e;
long b;
void f() {
  short g = a;
  for (; c; c++) {
b &= a == 0 ? 1 : g / a;
d |= e;
  }
}

with the same options on AArch64, we ICE with a similar (but not identical)
backtrace:

during GIMPLE pass: vect
test.c: In function 'f':
test.c:3:6: internal compiler error: in vect_get_loop_mask, at
tree-vect-loop.c:8868
3 | void f() {
  |  ^
0x10a45cc vect_get_loop_mask(gimple_stmt_iterator*, auto_vec*, unsigned int, tree_node*, unsigned int)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.c:8867
0x1085843 vectorizable_condition
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-stmts.c:10195
0x109b040 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-stmts.c:10831
0x10a1eb3 vect_transform_loop_stmt
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.c:9053
0x10bee28 vect_transform_loop(_loop_vec_info*, gimple*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.c:9475
0x10eb324 try_vectorize_loop_1
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1091
0x10eba51 try_vectorize_loop
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1148
0x10ebe2b vectorize_loops()
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1229
0xf7843d execute
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-loop.c:414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

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

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

--- Comment #4 from Jonathan Wakely  ---
N.B. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2593.htm proposes to
standardise typeof.

[Bug tree-optimization/97725] [11 Regression] ICE at -Os and above: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|ICE at -Os and above: tree  |[11 Regression] ICE at -Os
   |check: expected class   |and above: tree check:
   |‘type’, have ‘exceptional’  |expected class ‘type’, have
   |(error_mark) in |‘exceptional’ (error_mark)
   |useless_type_conversion_p,  |in
   |at gimple-expr.c:87 |useless_type_conversion_p,
   ||at gimple-expr.c:87
   Target Milestone|--- |11.0
   Priority|P3  |P1

--- Comment #1 from Richard Biener  ---
It means we end up with a used but released SSA name.  Oops.

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Aldy Hernandez from comment #2)
> The ranger is analyzing a statement with an integer overflow, and creating a
> non-legacy range that is invalid:
> 
> (gdb) p debug(stmt)
> if (_1 != -1(OVF))
> 
> (gdb) p debug(op2_range)
> int [-1(OVF), -1(OVF)]
> 
> (gdb) p op2_range.legacy_mode_p()
> $8 = false
> 
> Legacy ranges allow TREE_OVERFLOW to creep in, as the verifier allows
> symbolics and other end points that are not comparable at compile time (cmp
> == -2 below):
> 
> case VR_ANTI_RANGE:
> case VR_RANGE:
>   {
>   gcc_assert (m_num_ranges == 1);
>   int cmp = compare_values (tree_lower_bound (0), tree_upper_bound (0));
>   gcc_assert (cmp == 0 || cmp == -1 || cmp == -2);
>   return;
>   }
> 
> However, we're a bit more strict in irange.  We don't allow un-comparable
> endpoints and TREE_OVERFLOW integers are such.
> 
> I'm not sure where to fix this.
> 
> Is the original statement valid gimple?  Richard has mentioned that any time
> there's a TREE_OVERFLOW in the IL, it's a sign of a bug.  If the IL is
> wrong, we should tackle the source problem.
> 
> If the IL is ocrrect, then perhaps we could drop OVF at range creation.

Yes, the IL is "correct", just inefficent and possibly confusing to passes.

The OVF flag on INTEGER_CST have _no_ semantic meaning in the IL so making
them "invalid" in ranger doesn't make sense.

[Bug tree-optimization/97725] ICE at -Os and above: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 since r11-4724-ge86fd6a17cdb267

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-11-05
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Known to fail||11.0
  Known to work||10.2.0
Summary|[11 Regression] ICE at -Os  |ICE at -Os and above: tree
   |and above: tree check:  |check: expected class
   |expected class ‘type’, have |‘type’, have ‘exceptional’
   |‘exceptional’ (error_mark)  |(error_mark) in
   |in  |useless_type_conversion_p,
   |useless_type_conversion_p,  |at gimple-expr.c:87 since
   |at gimple-expr.c:87 |r11-4724-ge86fd6a17cdb2671

--- Comment #2 from Martin Liška  ---
Nice report, started with r11-4724-ge86fd6a17cdb2671.

[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #24 from Alexander Monakov  ---
Segher, did you really mean to mark the bug resolved/fixed?

FWIW, I think Jakub is using an overly broad interpretation of the intended
behavior. Stretching that logic, it's possible to argue that it's okay for GCC
to put an operand in a different register than its asm specification says as
long as the constraint matches. But that would lead to wrong code.

Given that the only supported use of local register variables is passing
operands to inline asm in specific registers, I really think that GCC shouldn't
silently change the operand's location like that. The mismatching constraint
could be a result of a typo (or something like a botched refactoring), and the
compiler should help the user catch such errors.

[Bug middle-end/97392] [11 regression] g++.dg/asan/asan_test.C compilation failure starting with r11-3827

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

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

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

https://gcc.gnu.org/g:82972dc3ec83b88280a830540e8127e2a45d61f0

commit r9-9025-g82972dc3ec83b88280a830540e8127e2a45d61f0
Author: Martin Liska 
Date:   Tue Oct 13 10:09:47 2020 +0200

ASAN: disable -Wno-stringop-overflow for 2 tests

gcc/testsuite/ChangeLog:

PR middle-end/97392
* g++.dg/asan/asan_test.C: Disable -Wstringop-overflow.
* gcc.dg/asan/pr80166.c: Likewise.

(cherry picked from commit 8e0e9417ccda583a1bf05ff08e86fdffbec62b3e)
(cherry picked from commit a79cb813205027576d47a27655198cec4b5cd046)

[Bug middle-end/97392] [11 regression] g++.dg/asan/asan_test.C compilation failure starting with r11-3827

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

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

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

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

commit r10-8980-ga79cb813205027576d47a27655198cec4b5cd046
Author: Martin Liska 
Date:   Tue Oct 13 10:09:47 2020 +0200

ASAN: disable -Wno-stringop-overflow for 2 tests

gcc/testsuite/ChangeLog:

PR middle-end/97392
* g++.dg/asan/asan_test.C: Disable -Wstringop-overflow.
* gcc.dg/asan/pr80166.c: Likewise.

(cherry picked from commit 8e0e9417ccda583a1bf05ff08e86fdffbec62b3e)

[Bug libstdc++/97728] New: error: ‘imaxdiv_t’ has not been declared in ‘::’

[shfil at paranoici dot org via Gcc-bugs]

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

Bug ID: 97728
   Summary: error: ‘imaxdiv_t’ has not been declared in ‘::’
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shfil at paranoici dot org
  Target Milestone: ---

```
/usr/include/c++/10.2.0/cinttypes:58:11: error: ‘imaxdiv_t’ has not been
declared in ‘::’
   58 |   using ::imaxdiv_t;
  |   ^
/usr/include/c++/10.2.0/cinttypes:61:11: error: ‘imaxabs’ has not been declared
in ‘::’
   61 |   using ::imaxabs;
  |   ^~~
/usr/include/c++/10.2.0/cinttypes:62:11: error: ‘imaxdiv’ has not been declared
in ‘::’
   62 |   using ::imaxdiv;
  |   ^~~
/usr/include/c++/10.2.0/cinttypes:68:11: error: ‘strtoimax’ has not been
declared in ‘::’
   68 |   using ::strtoimax;
  |   ^
/usr/include/c++/10.2.0/cinttypes:69:11: error: ‘strtoumax’ has not been
declared in ‘::’
   69 |   using ::strtoumax;
  |   ^
/usr/include/c++/10.2.0/cinttypes:72:11: error: ‘wcstoimax’ has not been
declared in ‘::’
   72 |   using ::wcstoimax;
  |   ^
/usr/include/c++/10.2.0/cinttypes:73:11: error: ‘wcstoumax’ has not been
declared in ‘::’
   73 |   using ::wcstoumax;
```
This issue happens with using openal-soft 1.21.
https://github.com/kcat/openal-soft/issues/490

[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input

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

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

--- Comment #25 from Jakub Jelinek  ---
Even if we wanted to do something about it (which I disagree with, e.g. given
that the implementation matches the documentation), you run into the problem
that even GIMPLE nor RTL differentiates between:
void
foo (void)
{
  register int a __asm ("eax") = 1;
  __asm ("# %0 " : : "c" (a+0));
  __asm ("# %0 " : : "c" (a));
}
And "c" (a+0) unquestionably must be valid, it is just an expression that
happens to be equal to a value of local register variable.

[Bug libstdc++/97728] error: ‘imaxdiv_t’ has not been declared in ‘::’

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Please read https://gcc.gnu.org/bugs and provide the missing information.

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

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

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

--- Comment #6 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #5)
> (In reply to Aldy Hernandez from comment #2)

> Yes, the IL is "correct", just inefficent and possibly confusing to passes.
> 
> The OVF flag on INTEGER_CST have _no_ semantic meaning in the IL so making
> them "invalid" in ranger doesn't make sense.

The ranger treating them invalid was a precaution since the conversion to trees
brought the use of compare_values_warnv(), which claims overflowed values
cannot be compared.  But if in fact they can be compared, then perhaps
compare_values_warnv is wrong in claiming the opposite:

  /* We cannot say anything more for non-constants.  */
  if (!cst1 || !cst2)
return -2;

  if (!POINTER_TYPE_P (TREE_TYPE (val1)))
{
  /* We cannot compare overflowed values.  */
  if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
return -2;

What do you think?

It would seem to me that removing this restriction would work, especially since
tree_int_cst_compare, which this function uses, just degrades to wide ints,
which don't care about TREE_OVERFLOW.

[untested]

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index e00c034fee3..8702ad1ae8d 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -609,10 +609,6 @@ compare_values_warnv (tree val1, tree val2, bool
*strict_overflow_p)

   if (!POINTER_TYPE_P (TREE_TYPE (val1)))
 {
-  /* We cannot compare overflowed values.  */
-  if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
-   return -2;
-
   if (TREE_CODE (val1) == INTEGER_CST
  && TREE_CODE (val2) == INTEGER_CST)
return tree_int_cst_compare (val1, val2);
@@ -635,13 +631,7 @@ compare_values_warnv (tree val1, tree val2, bool
*strict_overflow_p)
   else
 {
   if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
-   {
- /* We cannot compare overflowed values.  */
- if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
-   return -2;
-
- return tree_int_cst_compare (val1, val2);
-   }
+   return tree_int_cst_compare (val1, val2);

   /* First see if VAL1 and VAL2 are not the same.  */
   if (operand_equal_p (val1, val2, 0))

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

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

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

--- Comment #7 from Jakub Jelinek  ---
But TREE_OVERFLOW is meaningful during evaluation, e.g. inside of VRP or when
folding some expression.  It just doesn't belong into the GIMPLE IL.
So I'd say it would be better for ranger when it sees TREE_OVERFLOW constant
somewhere in the IL not to set the range to that constant, but to
drop_tree_overflow of it.

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

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

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

--- Comment #8 from Aldy Hernandez  ---
(In reply to Jakub Jelinek from comment #7)
> But TREE_OVERFLOW is meaningful during evaluation, e.g. inside of VRP or
> when folding some expression.  It just doesn't belong into the GIMPLE IL.
> So I'd say it would be better for ranger when it sees TREE_OVERFLOW constant
> somewhere in the IL not to set the range to that constant, but to
> drop_tree_overflow of it.

That's certainly the easiest path for us.  We could drop_overflow in
get_tree_range while creating said ranges, and then no other changes to the
ranger are needed.

However, I wonder if compare_values_warnv is being unnecessarily restrictive. 
For example, here, we bail on overflow, even though tree_int_cst_compare,
through its use of wi::cmps, is perfectly capable of comparing these integers:

  if (!POINTER_TYPE_P (TREE_TYPE (val1)))
{
  /* We cannot compare overflowed values.  */
  if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
return -2;

  if (TREE_CODE (val1) == INTEGER_CST
  && TREE_CODE (val2) == INTEGER_CST)
return tree_int_cst_compare (val1, val2);

as well as here:

 if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
{
  /* We cannot compare overflowed values.  */
  if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
return -2;

  return tree_int_cst_compare (val1, val2);
}

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

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

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

--- Comment #9 from Richard Biener  ---
(In reply to Aldy Hernandez from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > But TREE_OVERFLOW is meaningful during evaluation, e.g. inside of VRP or
> > when folding some expression.  It just doesn't belong into the GIMPLE IL.
> > So I'd say it would be better for ranger when it sees TREE_OVERFLOW constant
> > somewhere in the IL not to set the range to that constant, but to
> > drop_tree_overflow of it.
> 
> That's certainly the easiest path for us.  We could drop_overflow in
> get_tree_range while creating said ranges, and then no other changes to the
> ranger are needed.
> 
> However, I wonder if compare_values_warnv is being unnecessarily
> restrictive.  For example, here, we bail on overflow, even though
> tree_int_cst_compare, through its use of wi::cmps, is perfectly capable of
> comparing these integers:
> 
>   if (!POINTER_TYPE_P (TREE_TYPE (val1)))
> {
>   /* We cannot compare overflowed values.  */
>   if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
>   return -2;
> 
>   if (TREE_CODE (val1) == INTEGER_CST
> && TREE_CODE (val2) == INTEGER_CST)
>   return tree_int_cst_compare (val1, val2);
> 
> as well as here:
> 
>  if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
>   {
> /* We cannot compare overflowed values.  */
> if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
>   return -2;
> 
> return tree_int_cst_compare (val1, val2);
>   }

VRP uses (used to use) fold_* routines and _specifically_ relies (relied)
on some TREE_OVERFLOW bits therein.  This might be all long history
but the above is probably because of that.

Btw, IIRC I've made sure to drop TREE_OVERFLOW from constants picked out
of the IL for VRP purposes (as said, some passes are "confused" about
existing TREE_OVERFLOW if they rely on TREE_OVERFLOW for their own
internal processing - which, nowadays should use wide_int).

[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #26 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #25)
> Even if we wanted to do something about it (which I disagree with, e.g.
> given that the implementation matches the documentation), you run into the
> problem that even GIMPLE nor RTL differentiates between:
> void
> foo (void)
> {
>   register int a __asm ("eax") = 1;
>   __asm ("# %0 " : : "c" (a+0));
>   __asm ("# %0 " : : "c" (a));
> }
> And "c" (a+0) unquestionably must be valid, it is just an expression that
> happens to be equal to a value of local register variable.

So it would need to be diagnosed in the FE (only), making a + 0 valid and
a not.  Eh.

[Bug libstdc++/97729] New: Link failure due to basic_stringbuf and others when building DLL on MinGW

[markus.boeck02 at gmail dot com via Gcc-bugs]

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

Bug ID: 97729
   Summary: Link failure due to basic_stringbuf and others when
building DLL on MinGW
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus.boeck02 at gmail dot com
  Target Milestone: ---

Current trunk of libstdc++ is not able to be built when building a shared
library on the i686-w64-mingw32 and x86_64-w64-mingw32 targets. Following
configure arguments were used:

../configure --target=x86_64-w64-mingw32 --disable-bootstrap
--with-sysroot=/mnt/c/GCC-Build/NewestLinux
--prefix=/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install
--disable-multilib --with-tune=znver1 --disable-libstdcxx-verbose --disable-nls
--enable-shared --with-gnu-ld --enable-threads=posix --enable-__cxa_atexit
--enable-libgomp --with-gnu-as
--with-as=/mnt/c/GCC-Build/NewestLinux/bin/x86_64-w64-mingw32-as
--with-ld=/mnt/c/GCC-Build/NewestLinux/bin/x86_64-w64-mingw32-ld
--enable-languages=c,c++,fortran,lto,objc,obj-c++ --with-cross-host

The last relevant lines of stdout are:

/bin/bash ../libtool --tag CXX   --mode=link
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/./gcc/xgcc -shared-libgcc
-B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/./gcc -nostdinc++
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/mingw/lib -isystem
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/include
-isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/mingw/include
-B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/bin/
-B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib/
-isystem
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/include
-isystem
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/sys-include
-Wl,-O1  -no-undefined -bindir
"/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib/../lib"
-Wl,--gc-sections  -std=gnu++98 -DDLL_EXPORT -DPIC -fno-implicit-templates 
-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 
-fdiagnostics-show-location=once   -ffunction-sections -fdata-sections 
-frandom-seed=libstdc++.la  -o libstdc++.la -version-info 6:29:0
-Wl,--version-script=libstdc++-symbols.ver -lm -no-undefined -bindir
"/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib/../lib"
-rpath
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib/../lib
compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo 
compatibility-c++0x.lo compatibility-atomic-c++0x.lo
compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo 
../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la
../src/c++11/libc++11convenience.la ../src/c++17/libc++17convenience.la
../src/c++20/libc++20convenience.la 
make  all-am
make[3]: Entering directory
'/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libgfortran'
libtool: link: rm -fr  .libs/libstdc++.dll.a
libtool: link:  /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/./gcc/xgcc
-shared-libgcc -B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/./gcc -nostdinc++
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/mingw/lib -isystem
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/include
-isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/mingw/include
-B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/bin/
-B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib/
-isystem
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/include
-isystem
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/sys-include
   -shared -nostdlib /mnt/c/GCC-Build/NewestLinux/mingw/lib/../lib/dllcrt2.o
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/./gcc/crtbegin.o 
.libs/compatibility.o .libs/compatibility-debug_list.o
.libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o
.libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o
.libs/compatibility-chrono.o .libs/compatibility-condvar.o  -Wl,--whole-a

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[aldyh at redhat dot com via Gcc-bugs]

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

--- Comment #10 from Aldy Hernandez  ---
> > as well as here:
> >
> >  if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
> >   {
> > /* We cannot compare overflowed values.  */
> > if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
> >   return -2;
> >
> > return tree_int_cst_compare (val1, val2);
> >   }
>
> VRP uses (used to use) fold_* routines and _specifically_ relies (relied)
> on some TREE_OVERFLOW bits therein.  This might be all long history
> but the above is probably because of that.
>
> Btw, IIRC I've made sure to drop TREE_OVERFLOW from constants picked out
> of the IL for VRP purposes (as said, some passes are "confused" about
> existing TREE_OVERFLOW if they rely on TREE_OVERFLOW for their own
> internal processing - which, nowadays should use wide_int).

Ok, let's let sleeping dogs lie then.  I'll drop the overflow will
building ranges.

Thanks for the explanation.

I'll commit the following if it passes tests.
Aldy

Drop overflow from constants while building ranges in ranger.

Sometimes overflow flag will leak into the IL.  Drop them while
creating ranges.

gcc/ChangeLog:

PR tree-optimization/97721
* gimple-range.cc (get_tree_range): Drop overflow from constants.

gcc/testsuite/ChangeLog:

* gcc.dg/pr97721.c: New test.

diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
index cf979845acf..6d351002830 100644
--- a/gcc/gimple-range.cc
+++ b/gcc/gimple-range.cc
@@ -165,6 +165,8 @@ get_tree_range (irange &r, tree expr)
   switch (TREE_CODE (expr))
 {
   case INTEGER_CST:
+if (TREE_OVERFLOW_P (expr))
+  expr = drop_tree_overflow (expr);
 r.set (expr, expr);
 return true;

diff --git a/gcc/testsuite/gcc.dg/pr97721.c b/gcc/testsuite/gcc.dg/pr97721.c
new file mode 100644
index 000..c2a2848ba13
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr97721.c
@@ -0,0 +1,13 @@
+// { dg-do compile }
+// { dg-options "-O -fno-tree-dominator-opts" }
+
+int ot;
+
+void
+z6 (char *tw)
+{
+  while (ot >= 0)
+--ot;
+
+  __builtin_strcpy (&tw[ot], tw);
+}

[Bug target/97730] New: [10/11 Regression] aarch64, SVE2: Wrong code since r10-5853-g0a09a948 (wrong pattern for BCAX)

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

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

Bug ID: 97730
   Summary: [10/11 Regression] aarch64, SVE2: Wrong code since
r10-5853-g0a09a948 (wrong pattern for BCAX)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

AArch64 GCC miscompiles the following testcase:

unsigned b = 0xce8e5a48, c = 0xb849691a;
unsigned a[8080];
int main() {
  a[0] = b;
  c = c;
  unsigned f = 0xb1e8;
  for (int h = 0; h < 5; h++)
a[h] = (b & c) ^ f;
  if (a[0] != 0x8808f9e0)
__builtin_abort();
}

at -O1 -ftree-vectorize -march=armv8.2-a+sve2 since
r10-5853-g0a09a9483825233f16e5b26bb0ffee76752339fc. Below is the generated code
from a trunk build, with some relevant lines annotated:

.arch armv8.2-a+crc+sve2
.file   "test.c"
.text
.align  2
.global main
.type   main, %function
main:
adrpx0, .LANCHOR0
add x3, x0, :lo12:.LANCHOR0
ldr w0, [x0, #:lo12:.LANCHOR0] // w0 <- b
adrpx2, a
add x1, x2, :lo12:a
str w0, [x2, #:lo12:a] // a[0] <- w0
mov w2, 5
whilelo p0.s, wzr, w2
ptrue   p1.b, all
ld1rw   z2.s, p1/z, [x3, 4]// z2 <- {c, c, ... }
mov z1.s, w0   // z1 <- {b, b, ... }
mov w0, 45544  // w0 <- f (= 0xb1e8)
mov z0.s, w0   // z0 <- {f, f, ... }
bcaxz0.d, z0.d, z2.d, z1.d // z0 ^= (z2 & ~z1)
st1wz0.s, p0, [x1] // a[0, 1, ...] <- z0
cntwx0
whilelo p0.s, w0, w2
b.none  .L2
incbx1
st1wz0.s, p0, [x1]
.L2:
adrpx0, a
ldr w1, [x0, #:lo12:a]
mov w0, 63968
movkw0, 0x8808, lsl 16
cmp w1, w0
bne .L7
mov w0, 0
ret
.L7:
stp x29, x30, [sp, -16]!
mov x29, sp
bl  abort
.size   main, .-main
.global a
.global c
.global b
.data
.align  2
.set.LANCHOR0,. + 0
.type   b, %object
.size   b, 4
b:
.word   -829531576
.type   c, %object
.size   c, 4
c:
.word   -1203148518
.bss
.align  3
.type   a, %object
.size   a, 32320
a:
.zero   32320
    .ident  "GCC: (unknown) 11.0.0 20201105 (experimental)"

The problem appears to be that the instruction:
  bcaxz0.d, z0.d, z2.d, z1.d
computes (~b & c) ^ f instead of (b & c) ^ f.

Looking at the SVE2 pattern for bcax (aarch64-sve2.md), it looks like we're
missing a not on one of the operands to the and rtx:

;; Unpredicated exclusive OR of AND.
(define_insn "@aarch64_sve2_bcax"
  [(set (match_operand:SVE_FULL_I 0 "register_operand" "=w, ?&w")
(xor:SVE_FULL_I
  (and:SVE_FULL_I
(match_operand:SVE_FULL_I 2 "register_operand" "w, w")
(match_operand:SVE_FULL_I 3 "register_operand" "w, w"))
  (match_operand:SVE_FULL_I 1 "register_operand" "0, w")))]
  "TARGET_SVE2"
  "@
  bcax\t%0.d, %0.d, %2.d, %3.d
  movprfx\t%0, %1\;bcax\t%0.d, %0.d, %2.d, %3.d"
  [(set_attr "movprfx" "*,yes")]
)

comparing this to the corresponding pattern for AdvSIMD bcax (aarch64-simd.md),
this becomes clear:

(define_insn "bcaxq4"
  [(set (match_operand:VQ_I 0 "register_operand" "=w")
(xor:VQ_I
 (and:VQ_I
  (not:VQ_I (match_operand:VQ_I 3 "register_operand" "w"))
  (match_operand:VQ_I 2 "register_operand" "w"))
 (match_operand:VQ_I 1 "register_operand" "w")))]
  "TARGET_SIMD && TARGET_SHA3"
  "bcax\\t%0.16b, %1.16b, %2.16b, %3.16b"
  [(set_attr "type" "crypto_sha3")]
)

Indeed, changing the source file to print the value of a[0], we get 0x304190fa,
which is the result of computing (~b & c) ^ f.

[Bug target/97730] [10/11 Regression] aarch64, SVE2: Wrong code since r10-5853-g0a09a948 (wrong pattern for BCAX)

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

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

Alex Coplan  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |10.3
  Known to fail||11.0
 CC||rsandifo at gcc dot gnu.org
 Target||aarch64

[Bug target/97730] [10/11 Regression] aarch64, SVE2: Wrong code since r10-5853-g0a09a948 (wrong pattern for BCAX)

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/97729] Link failure due to basic_stringbuf and others when building DLL on MinGW

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-11-05

--- Comment #1 from Jonathan Wakely  ---
Created attachment 49505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49505&action=edit
Instantiate and export missing constructor

I can't reproduce this with a x86_64-w64-mingw32 cross-compiler built on linux,
nor with a native linux compiler. But this patch should fix it, could you test
it please?

[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||build
Summary|Link failure due to |[11 Regression] Link
   |basic_stringbuf and others  |failure due to
   |when building DLL on MinGW  |basic_stringbuf and others
   ||when building DLL on MinGW
  Known to work||10.2.1
  Known to fail||11.0
   Priority|P3  |P1
   Target Milestone|--- |11.0

[Bug libstdc++/97731] New: terminate called in std::experimental::filesystem::recursive_directory_iterator

[torsten.hilbrich at secunet dot com via Gcc-bugs]

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

Bug ID: 97731
   Summary: terminate called in
std::experimental::filesystem::recursive_directory_ite
rator
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: torsten.hilbrich at secunet dot com
  Target Milestone: ---

Created attachment 49506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49506&action=edit
Reproducer for the problem

The recursive_directory_iterator causes a call to terminate when an I/O error
is happening on the directory to iterate. It originally occured in an
environment where access to a directory was no longer possible and caused EIO
reported through a linux device-mapper target. In the test program this
behaviour is simulated by replacing the readdir function with a mockup always
failing with errno set to EIO.

We initially found this problem with libstdc++ as provided with gcc 8.3.0. But
I also checked the version from gcc 10.2 and could reproduce the problem.

The testing code test.cpp is attached to this ticket.

Here is an example session:

$ g++ -o test test.cpp -lstdc++fs
$ ./test
terminate called after throwing an instance of
'std::experimental::filesystem::v1::__cxx11::filesystem_error'
  what():  filesystem error: directory iterator cannot advance: Input/output
error
Aborted (core dumped)

I already looked at the code and thing I found the culprit.

In recursive_directory_iterator(const path&, directory_options options,
error_code*) (dir.cc:199) the following method call is found:

   if (sp->top().advance(ec))

This calls the method "bool advance(bool skip_permission_denied = false)"
within _Dir, implicitly converting the std::error_code* to bool.

This way, we get roughly the following stack trace:

#0  std::filesystem::_Dir_base::advance (this=0x5559a050,
skip_permission_denied=true, ec=...)
at dir-common.h:110
#1  0xeb39 in
std::experimental::filesystem::v1::__cxx11::_Dir::advance (
this=0x5559a050, skip_permission_denied=true, ec=...) at dir.cc:65
#2  0xed39 in
std::experimental::filesystem::v1::__cxx11::_Dir::advance (
this=0x5559a050, skip_permission_denied=true) at dir.cc:87
#3  0xd110 in
std::experimental::filesystem::v1::__cxx11::recursive_directory_iterator::recursive_directory_iterator
(this=0x7fffdd90, p=filesystem::path "/tmp" = {...}, 
options=std::experimental::filesystem::v1::directory_options::none,
ec=0x7fffdd60) at dir.cc:199
#4  0xc07c in
std::experimental::filesystem::v1::__cxx11::recursive_directory_iterator::recursive_directory_iterator
(this=0x7fffdd90, __p=filesystem::path "/tmp" = {...}, __ec=...)
at /usr/include/c++/9/experimental/bits/fs_dir.h:280
#5  0xbb5d in main () at ./test.cpp:17

and finally, an exception is thrown via a method declared noexcept, causing the
termination of the program.

Torsten

[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW

[markus.boeck02 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Markus Böck  ---
Created attachment 49507
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49507&action=edit
config.h

Applied the patch and it fixed the issue regarding the undefined references.
Still getting the multiple definitions of exception_ptr:

/mnt/c/GCC-Build/NewestLinux/bin/x86_64-w64-mingw32-ld:
../libsupc++/.libs/libsupc++convenience.a(nested_exception.o): in function
`std::__exception_ptr::exception_ptr::~exception_ptr()':
C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/bits/exception_ptr.h:194:
multiple definition of `std::__exception_ptr::exception_ptr::~exception_ptr()';
../libsupc++/.libs/libsupc++convenience.a(eh_ptr.o):C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/bits/exception_ptr.h:194:
first defined here
/mnt/c/GCC-Build/NewestLinux/bin/x86_64-w64-mingw32-ld:
../src/c++11/.libs/libc++11convenience.a(future.o): in function
`std::__exception_ptr::exception_ptr::exception_ptr()':
C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/c++11/C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/bits/std_mutex.h:105:
multiple definition of `std::__exception_ptr::exception_ptr::exception_ptr()';
../libsupc++/.libs/libsupc++convenience.a(eh_ptr.o):C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/bits/exception_ptr.h:176:
first defined here

I am using a cross compiler setup (though in WSL 1) as well so I'd be curious
what leads to the differences in reproducability as this is not the first time
this has happened. I'll attach my config.h if that helps. The MinGW version I
use is current trunk.

[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW

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

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

--- Comment #3 from Jonathan Wakely  ---
It could be a difference in the linker. I'm using the mingw cross-binutils that
comes with Fedora:

$ /usr/bin/x86_64-w64-mingw32-ld --version
GNU ld version 2.32-%{release}
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.


The exception_ptr symbols should get suppressed with:

--- a/libstdc++-v3/src/c++11/future.cc
+++ b/libstdc++-v3/src/c++11/future.cc
@@ -22,6 +22,9 @@
 // see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 // .

+// Prevent multiple definitions of exception_ptr inline members (PR 97729)
+#define _GLIBCXX_EH_PTR_COMPAT
+
 #include 
 #include 

[Bug libstdc++/97731] terminate called in std::experimental::filesystem::recursive_directory_iterator

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2020-11-05

[Bug libstdc++/97731] terminate called in std::experimental::filesystem::recursive_directory_iterator

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

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

--- Comment #1 from Jonathan Wakely  ---
Looks like I fixed it for std::filesystem::recursive_directory_iterator but not
the experimental version:

  if (ecptr ? sp->top().advance(*ecptr) : sp->top().advance())
_M_dirs.swap(sp);

[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW

[markus.boeck02 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Markus Böck  ---
Indeed that sounds like it might be the issue. I am currently on a very recent
version of binutils:

$ ./x86_64-w64-mingw32-ld --versionGNU ld (GNU
Binutils) 2.35.50.20200709 
Copyright (C) 2020 Free Software Foundation, Inc.  
This
program is free software; you may redistribute it under the terms of   
   the GNU General Public License version 3 or
(at your option) a later version.  
This program has absolutely no warranty.

Changing the lines you posted above yields me a compiler error now:

libtool: compile:  /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/./gcc/xgcc
-shared-libgcc -B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/./gcc -nostdinc++
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib
-L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/mingw/lib -isystem
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/include
-isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/mingw/include
-B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/bin/
-B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib/
-isystem
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/include
-isystem
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/sys-include
-I/mnt/c/GCC-Build-Array/gcc/libstdc++-v3/../libgcc
-I/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include
-I/mnt/c/GCC-Build-Array/gcc/libstdc++-v3/libsupc++
-I/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/include -std=gnu++11
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=future.lo -Wno-error=format-extra-args
-Wno-error=format -g1 -fdebug-prefix-map=/mnt/c=C: -c
../../../../../libstdc++-v3/src/c++11/future.cc -o future.o
In file included from ../../../../../libstdc++-v3/src/c++11/future.cc:29:
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/future:
In member function 'std::__future_base::_Result<_Res>&
std::__basic_future<_Res>::_M_get_result() const':
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/future:712:30:
error: ambiguous overload for 'operator==' (operand types are
'std::__exception_ptr::exception_ptr' and 'int')
  712 | if (!(__res._M_error == 0))
  |   ~~ ^~ ~
  | |   |
  | |   int
  | std::__exception_ptr::exception_ptr
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/future:712:30:
note: candidate: 'operator==(std::__exception_ptr::exception_ptr::__safe_bool
{aka void (std::__exception_ptr::exception_ptr::*)()},
std::__exception_ptr::exception_ptr::__safe_bool {aka void
(std::__exception_ptr::exception_ptr::*)()})' (built-in)
  712 | if (!(__res._M_error == 0))
  |   ~~~^~~~
In file included from
/mnt/c/GCC-Build-Array/gcc/libstdc++-v3/libsupc++/exception:147,
 from
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/mutex:40,
 from
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/future:38,
 from ../../../../../libstdc++-v3/src/c++11/future.cc:29:
/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/bits/exception_ptr.h:223:5:
note: candidate: 'bool std::__exception_ptr::operator==(const
std::__exception_ptr::exception_ptr&, const
std::__exception_ptr::exception_ptr&)'
  223 | operator==(const exception_ptr&, const exception_ptr&)
  | ^~~~
Makefile:644: recipe for target 'future.lo' failed
make[5]: Leaving directory
'/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/c++11'

[Bug c/97732] New: ice: tree check fail

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 97732
   Summary: ice: tree check fail
   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:

typedef int a;
typedef struct {
  a b, blink;
} c;
int d;
c *e;
void f(void) {
  e = f;
  for (; d; d += 1, e += 1)
e->b = e->blink = e;
}

compiled with recent gcc trunk and compiler flag -O3, does this:

during RTL pass: expand
bug667.c: In function ‘f’:
bug667.c:7:6: internal compiler error: tree check: expected integer_cst, have
addr_expr in get_val, at tree.h:6008
7 | void f(void) {
  |  ^
0xfd77ba tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../trunk.git/gcc/tree.c:9752
0x7b0221 tree_int_cst_elt_check(tree_node const*, int, char const*, int, char
const*)
../../trunk.git/gcc/tree.h:3501

The bug first appeared sometime between 20201031 and 20201103.

[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW

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

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

--- Comment #5 from Jonathan Wakely  ---
Yes sorry, I get the same error. I should have tested it first! Working patch
on the way ...

[Bug tree-optimization/97733] New: internal compiler error: in operator[], at vec.h:880 with "-O1 -fno-toplevel-reorder -fno-tree-bit-ccp -fno-tree-dce -fno-tree-dominator-opts -fno-tree-scev-cprop -f

[suochenyao at 163 dot com via Gcc-bugs]

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

Bug ID: 97733
   Summary: internal compiler error: in operator[], at vec.h:880
with "-O1 -fno-toplevel-reorder -fno-tree-bit-ccp
-fno-tree-dce -fno-tree-dominator-opts
-fno-tree-scev-cprop -ftree-loop-vectorize -ftree-pre"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: suochenyao at 163 dot com
  Target Milestone: ---

***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
char a=0;
int b=0;
void c() {
  int d = 1;
  short e = 10;
  for (; b; b--) {
e &= a;
d &= 10;
  }
}
int main() { return 0; }
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/home/suocy/bin/gcc-dev/bin/gcc
COLLECT_LTO_WRAPPER=/home/suocy/bin/gcc-dev/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/suocy/bin/gcc-dev/
--disable-multilib --enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201105 (experimental) (GCC)
***
Command Lines:
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -O1 -fno-toplevel-reorder
-fno-tree-bit-ccp -fno-tree-dce -fno-tree-dominator-opts -fno-tree-scev-cprop
-ftree-loop-vectorize -ftree-pre a.c
during GIMPLE pass: vect
a.c: In function ‘c’:
a.c:3:6: internal compiler error: in operator[], at vec.h:880
3 | void c() {
  |  ^
0x74940e vec::operator[](unsigned int)
../../gcc/vec.h:880
0x74a335 vec<_stmt_vec_info*, va_heap, vl_embed>::operator[](unsigned int)
../../gcc/tree.h:3834
0x74a335 vec<_stmt_vec_info*, va_heap, vl_ptr>::operator[](unsigned int)
../../gcc/vec.h:1451
0x74a335 vect_build_slp_tree_2
../../gcc/tree-vect-slp.c:1415
0x105ea49 vect_build_slp_tree
../../gcc/tree-vect-slp.c:1372
0x1061671 vect_build_slp_instance
../../gcc/tree-vect-slp.c:2208
0x1062cc8 vect_analyze_slp_instance
../../gcc/tree-vect-slp.c:2545
0x1063281 vect_analyze_slp(vec_info*, unsigned int)
../../gcc/tree-vect-slp.c:2603
0x10488c8 vect_analyze_loop_2
../../gcc/tree-vect-loop.c:2285
0x10488c8 vect_analyze_loop(loop*, vec_info_shared*)
../../gcc/tree-vect-loop.c:2895
0x106f423 try_vectorize_loop_1
../../gcc/tree-vectorizer.c:995
0x106fee1 vectorize_loops()
../../gcc/tree-vectorizer.c:1229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug analyzer/97668] [11 Regression] ICE in cmp_cst, at analyzer/svalue.cc:283

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

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

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

https://gcc.gnu.org/g:54cbdb528df16686290ad26e2130a1896915639d

commit r11-4740-g54cbdb528df16686290ad26e2130a1896915639d
Author: David Malcolm 
Date:   Thu Nov 5 09:54:58 2020 -0500

analyzer: fix ICE comparing COMPLEX_CSTs [PR97668]

gcc/analyzer/ChangeLog:
PR analyzer/97668
* svalue.cc (cmp_cst): Handle COMPLEX_CST.

gcc/testsuite/ChangeLog:
PR analyzer/97668
* gcc.dg/analyzer/pr97668.c: New test.
* gfortran.dg/analyzer/pr97668.f: New test.

[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

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

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

--- Comment #24 from CVS Commits  ---
The master branch has been updated by Qing Zhao :

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

commit r11-4741-gcc32e81cdbb7696cd571bdb5ffe52f228f125df5
Author: qing zhao 
Date:   Thu Nov 5 15:57:46 2020 +0100

i386: Fix PR97715

This change fixes a bug in the i386 backend when adding
-fzero-call-used-regs=all on a target that has no x87
registers.

When there is no x87 registers available, we should not
zero stack registers.

gcc/ChangeLog:

PR target/97715
* config/i386/i386.c (zero_all_st_registers): Return
earlier when the FPU is disabled.

gcc/testsuite/ChangeLog:

PR target/97715
* gcc.target/i386/zero-scratch-regs-32.c: New test.

[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #25 from qinzhao at gcc dot gnu.org ---
fixed in gcc11

[Bug analyzer/97668] [11 Regression] ICE in cmp_cst, at analyzer/svalue.cc:283

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Thanks for filing this.  Should be fixed by the above commit.

[Bug libstdc++/96269] optional comparison with nullopt fails

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

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

--- Comment #3 from Jonathan Wakely  ---
I don't think this is a bug in std::optional, I think it's how C++20 works.

[Bug libstdc++/96269] optional comparison with nullopt fails

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #4 from Ville Voutilainen  ---
Right; even gcc trunk is happy with that code in C++17 mode with both values of
FLIP, it's the C++20 spaceship rules that cause trouble here.

[Bug tree-optimization/97733] internal compiler error: in operator[], at vec.h:880 with "-O1 -fno-toplevel-reorder -fno-tree-bit-ccp -fno-tree-dce -fno-tree-dominator-opts -fno-tree-scev-cprop -ftree-

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-5
   Priority|P3  |P1
   Target Milestone|--- |11.0
  Known to fail||11.0
  Known to work||10.2.0
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed, started with r11-4603-g5b41d673ad96dd2f.

[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input

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

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

--- Comment #27 from Segher Boessenkool  ---
(In reply to Alexander Monakov from comment #24)
> Segher, did you really mean to mark the bug resolved/fixed?

No, if I did that, I have no idea how :-)

> Given that the only supported use of local register variables is passing
> operands to inline asm in specific registers, I really think that GCC
> shouldn't silently change the operand's location like that.

Yes, exactly.

[Bug c++/67453] vtable not emitted for class with no key method and defaulted destructor with attribute((used))

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Blocks||97729
   Last reconfirmed|2015-09-04 00:00:00 |2020-11-5

--- Comment #2 from Jonathan Wakely  ---
We don't emit any constructors or destructors that are marked used.

This is a problem for libstdc++ now.

struct S {
S();
~S();
S(const S&);
};

[[gnu::used]] inline S::S()  { }
[[gnu::used]] inline S::~S() { }
[[gnu::used]] inline S::S(const S&) { }

This generates no code with GCC. Clang emits all three functions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97729
[Bug 97729] [11 Regression] Link failure due to basic_stringbuf and others when
building DLL on MinGW

[Bug libstdc++/96269] optional comparison with nullopt fails

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Ville Voutilainen  ---
Oh, and if you define a spaceship operator for your type, then things work
again, with or without FLIP.

[Bug tree-optimization/97732] ice: tree check fail

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
Version|unknown |11.0
   Priority|P3  |P1
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
  Known to work||10.2.0
  Known to fail||11.0
   Last reconfirmed||2020-11-05
 Ever confirmed|0   |1
  Component|c   |tree-optimization

--- Comment #1 from Martin Liška  ---
Started with r11-4646-gf53e9d40de721241.

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

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

commit r11-4743-g4ef0f1e90f1795b1f2d5bba05ed299e8c7635fd4
Author: Aldy Hernandez 
Date:   Thu Nov 5 12:40:51 2020 +0100

Drop overflow from constants while building ranges in ranger.

Sometimes the overflow flag will leak into the IL.  Drop it while
creating ranges.

There are various places we could plug this.  This patch just plugs things
at get_tree_range which is the entry point for ranges from tree
expressions.
It fixes the PR, and probably fixes the ranger entirely, but we may need
to revisit this.

For example, I looked to see if there were other places that created
ranges with TREE_OVERFLOW set, and there are various.  For example,
the following code pattern appears multiple times in vr-values.c:

  else if (is_gimple_min_invariant (op0))
vr0.set (op0);

This can pick up TREE_OVERFLOW from the IL if present.  However, the
ranger won't see them so we're good.

At some point we should audit all this.  Or perhaps just nuke all
TREE_OVERFLOW's at irange::set.

For now, this will do.

gcc/ChangeLog:

PR tree-optimization/97721
* gimple-range.cc (get_tree_range): Drop overflow from constants.

gcc/testsuite/ChangeLog:

* gcc.dg/pr97721.c: New test.

[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #12 from Aldy Hernandez  ---
fixed

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

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

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

--- Comment #28 from Martin Liška  ---
(In reply to Eric Botcazou from comment #27)
> Created attachment 49472 [details]
> Slightly better tentative fix

Unfortunately, it still fails.

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

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

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

--- Comment #29 from Martin Liška  ---
Created attachment 49508
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49508&action=edit
ppc_log with patch

[Bug c++/67453] vtable not emitted for class with no key method and defaulted destructor with attribute((used))

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 49509
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49509&action=edit
gcc11-pr67453.patch

Untested fix.

[Bug libstdc++/96269] optional comparison with nullopt fails

[sshannin at gmail dot com via Gcc-bugs]

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

--- Comment #6 from sshannin at gmail dot com ---
Thanks to you both for your analysis. As I said, I wasn't sure if it was an
issue, so I'm certainly willing to accept that it's not.

The one point I wanted to emphasize though just to make sure we're talking
about the same thing is that it seems to odd to me that we're instantiating any
form of comparison function for type T. We're comparing optional to
nullopt_t, so it would seem that it shouldn't matter whether T itself is even
comparable.

More specifically, header  defines operator<=>(const optional &x,
nullopt_t), with the very simple body of bool(x) <=> false, as expected (circa
line 1050, gated by #ifdef __cpp_lib_three_way_comparsion). This is why the
non-flip case works, it hits the spaceship overload for (optional, null_opt_t).
 But there is no such operator in the other direction: (null_opt_t, optional).
So we end up hitting optional's plain templated operator==() at ~line 1120,
which of course ultimately instantiates the T's (broken/weird) operator.

I guess to rephrase, should there also be a specialized spaceship overload for
the (nullopt_t, optional) direction to complement the (optional, nullopt) one?

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

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

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

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #49472|0   |1
is obsolete||

--- Comment #30 from Eric Botcazou  ---
Created attachment 49510
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49510&action=edit
Tentative fix #2

With the missing ampersand.

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

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

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

--- Comment #31 from Eric Botcazou  ---
> Unfortunately, it still fails.

OK, can you try the new one?

[Bug fortran/95847] [9/10/11 Regression] Internal error when processing pFUnit generated files with --coverage

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

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

Martin Liška  changed:

   What|Removed |Added

  Component|gcov-profile|fortran
 Status|ASSIGNED|NEW
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
 CC||burnus at gcc dot gnu.org,
   ||kargl at gcc dot gnu.org,
   ||pault at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
I can only confirm it's a Fortran issue.
Can please anybody from Fortran folks take a look?

[Bug target/97734] New: GCC using branches when a conditional move would be better

[rafael at espindo dot la via Gcc-bugs]

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

Bug ID: 97734
   Summary: GCC using branches when a conditional move would be
better
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafael at espindo dot la
  Target Milestone: ---

Created attachment 49511
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49511&action=edit
graph

Playing with the code in https://github.com/patmorin/arraylayout I noticed that
I could not reproduce the results for the eytzinger layout. It turns out the
issue was with current gcc selecting moves instead of conditional moves for
that particular code.

A reduced testcase is

#include 
uint64_t branchfree_search(uint64_t x, uint64_t n, uint32_t *a) {
uint64_t i = 0;
while (i < n) {
i = (x <= a[i]) ? (2*i + 1) : (2*i + 2);
}
uint64_t j = (i+1) >> __builtin_ffsl(~(i+1));
return (j == 0) ? n : j-1;
}

I have placed it in

https://gcc.godbolt.org/z/Krqrz7

Results
* ICC: conditional move
* Clang: branches
* GCC 6.4: conditional move
* Newer GCCs with -O2:  branches
* GCC with -Os: conditional move

The attached graph shows how the conditional move is better for "small" array
sizes.

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #5 from joseph at codesourcery dot com  ---
A standard version might well end up being handled slightly differently 
from the existing GNU version (cf. _Alignof and __alignof).

[Bug libstdc++/96269] optional comparison with nullopt fails

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to sshannin from comment #6)
> I guess to rephrase, should there also be a specialized spaceship overload
> for the (nullopt_t, optional) direction to complement the (optional,
> nullopt) one?

No, the compiler synthesizes it from operator==(optional, nullopt_t) by
reversing the arguments. That's how comparisons work in C++20.

[Bug libstdc++/96269] optional comparison with nullopt fails

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-05
   Keywords||rejects-valid
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #8 from Jonathan Wakely  ---
Ah, but there is a library bug here after all. The declval expressions used to
constrain the comparison operators are using the wrong type.

They always use declval<_Tp>() == declval<_Up>() but it should be const _Tp&
and const _Up& instead. That would mean those aren't candidates for your
non-const operator== and so the synthesized operator==(nulloptr_t, optional)
would get used.

[Bug c++/57111] Generalize -Wfree-nonheap-object to delete

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90629

--- Comment #11 from Martin Sebor  ---
The patch I submitted for pr90629 implements this enhancement:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557987.html

It detects the bug in the test case in comment #0 but only with optimization
(to see through inlined calls) and with -Wsystem-headers.  Just like all late
warnings to date, -Wfree-nonheap-object isn't without false positives.  pr54202
is one that even the exceedingly simplistic -Wfree-nonheap-object is
susceptible to.  The patch above doesn't change things.

In file included from
/build/gcc-trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/memory:76,
 from t.C:2:
In member function ‘typename std::enable_if::value>::type std::default_delete<_Tp []>::operator()(_Up*) const [with
_Up = int; _Tp = int]’,
inlined from ‘std::unique_ptr<_Tp [], _Dp>::~unique_ptr() [with _Tp = int;
_Dp = std::default_delete]’ at
/build/gcc-trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/unique_ptr.h:612:17,
inlined from ‘int main()’ at t.C:6:32:
/build/gcc-trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/unique_ptr.h:120:11:
warning: ‘void operator delete [](void*)’ called on unallocated object ‘arr’
[-Wfree-nonheap-object]
  120 |   delete [] __ptr;
  |   ^~~
t.C: In function ‘int main()’:
t.C:5:7: note: declared here
5 |   int arr[]={1,2};
  |   ^~~

[Bug libstdc++/96269] optional comparison with nullopt fails

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Ville Voutilainen  ---
Ha, well spotted. In general, in a spaceship world, you do want to provide
comparisons symmetrically and const-correctly, and that also works in the
pre-spaceship world, thus:

#include 

struct X {
  template 
  bool operator==(const T&) const {
return false;
  }
  template  friend bool operator==(const T&, const X&) {return
false;}
};

bool foo() {
  std::optional x;
#ifndef FLIP
  return x == std::nullopt;
#else
  return std::nullopt == x;
#endif
}

[Bug libstdc++/96269] [10/11 Regression] optional comparison with nullopt fails

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
  Known to fail||10.2.1, 11.0
  Known to work||9.3.0
Summary|optional comparison with|[10/11 Regression] optional
   |nullopt fails   |comparison with nullopt
   ||fails
   Priority|P3  |P2

[Bug libstdc++/90295] Please define ~exception_ptr inline

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

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

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

https://gcc.gnu.org/g:710508c7b1a2c8e1d75d4c4f1ac79473dbf2b2bb

commit r11-4749-g710508c7b1a2c8e1d75d4c4f1ac79473dbf2b2bb
Author: Jonathan Wakely 
Date:   Thu Nov 5 16:19:15 2020 +

libstdc++: Fix multiple definitions of std::exception_ptr functions [PR
97729]

This fixes some multiple definition errors caused by the changes for
PR libstdc++/90295. The previous solution for inlining the members of
std::exception_ptr but still exporting them from the library was to
suppress the 'inline' keyword on those functions when compiling
libsupc++/eh_ptr.cc, so they get defined in that file. That produces ODR
violations though, because there are now both inline and non-inline
definitions in the library, due to the use of std::exception_ptr in
other files sucg as src/c++11/future.cc.

The new solution is to define all the relevant members as 'inline'
unconditionally, but use __attribute__((used)) to cause definitions to
be emitted in libsupc++/eh_ptr.cc as before. This doesn't quite work
however, because PR c++/67453 means the attribute is ignored on
constructors and destructors. As a workaround, the old solution
(conditionally inline) is still used for those members, but they are
given the always_inline attribute so that they aren't emitted in
src/c++11/future.o as inline definitions.

libstdc++-v3/ChangeLog:

PR libstdc++/97729
* include/std/future (__basic_future::_M_get_result): Use
nullptr for null pointer constant.
* libsupc++/eh_ptr.cc (operator==, operator!=): Remove
definitions.
* libsupc++/exception_ptr.h (_GLIBCXX_EH_PTR_USED): Define
macro to conditionally add __attribute__((__used__)).
(operator==, operator!=, exception_ptr::exception_ptr())
(exception_ptr::exception_ptr(const exception_ptr&))
(exception_ptr::~exception_ptr())
(exception_ptr::operator=(const exception_ptr&))
(exception_ptr::swap(exception_ptr&)): Always define as
inline. Add macro to be conditionally "used".

[Bug libstdc++/97731] terminate called in std::experimental::filesystem::recursive_directory_iterator

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

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

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

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

commit r11-4750-g2f93a2a03a343a29f614a530d7657f1ed6347ed5
Author: Jonathan Wakely 
Date:   Thu Nov 5 17:26:13 2020 +

libstdc++: Use non-throwing increment in recursive_directory_iterator [PR
97731]

As described in the PR, the recursive_directory_iterator constructor
calls advance(ec), but ec is a pointer so it calls _Dir::advance(bool).
The intention was to either call advance() or advance(*ec) depending
whether the pointer is null or not.

This fixes the bug and renames the parameter to ecptr to make similar
mistakes less likely in future.

libstdc++-v3/ChangeLog:

PR libstdc++/97731
* src/filesystem/dir.cc (recursive_directory_iterator): Call the
right overload of _Dir::advance.
* testsuite/experimental/filesystem/iterators/97731.cc: New test.

[Bug c++/67453] vtable not emitted for class with no key method and defaulted destructor with attribute((used))

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

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

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

https://gcc.gnu.org/g:710508c7b1a2c8e1d75d4c4f1ac79473dbf2b2bb

commit r11-4749-g710508c7b1a2c8e1d75d4c4f1ac79473dbf2b2bb
Author: Jonathan Wakely 
Date:   Thu Nov 5 16:19:15 2020 +

libstdc++: Fix multiple definitions of std::exception_ptr functions [PR
97729]

This fixes some multiple definition errors caused by the changes for
PR libstdc++/90295. The previous solution for inlining the members of
std::exception_ptr but still exporting them from the library was to
suppress the 'inline' keyword on those functions when compiling
libsupc++/eh_ptr.cc, so they get defined in that file. That produces ODR
violations though, because there are now both inline and non-inline
definitions in the library, due to the use of std::exception_ptr in
other files sucg as src/c++11/future.cc.

The new solution is to define all the relevant members as 'inline'
unconditionally, but use __attribute__((used)) to cause definitions to
be emitted in libsupc++/eh_ptr.cc as before. This doesn't quite work
however, because PR c++/67453 means the attribute is ignored on
constructors and destructors. As a workaround, the old solution
(conditionally inline) is still used for those members, but they are
given the always_inline attribute so that they aren't emitted in
src/c++11/future.o as inline definitions.

libstdc++-v3/ChangeLog:

PR libstdc++/97729
* include/std/future (__basic_future::_M_get_result): Use
nullptr for null pointer constant.
* libsupc++/eh_ptr.cc (operator==, operator!=): Remove
definitions.
* libsupc++/exception_ptr.h (_GLIBCXX_EH_PTR_USED): Define
macro to conditionally add __attribute__((__used__)).
(operator==, operator!=, exception_ptr::exception_ptr())
(exception_ptr::exception_ptr(const exception_ptr&))
(exception_ptr::~exception_ptr())
(exception_ptr::operator=(const exception_ptr&))
(exception_ptr::swap(exception_ptr&)): Always define as
inline. Add macro to be conditionally "used".

[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW

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

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

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

https://gcc.gnu.org/g:710508c7b1a2c8e1d75d4c4f1ac79473dbf2b2bb

commit r11-4749-g710508c7b1a2c8e1d75d4c4f1ac79473dbf2b2bb
Author: Jonathan Wakely 
Date:   Thu Nov 5 16:19:15 2020 +

libstdc++: Fix multiple definitions of std::exception_ptr functions [PR
97729]

This fixes some multiple definition errors caused by the changes for
PR libstdc++/90295. The previous solution for inlining the members of
std::exception_ptr but still exporting them from the library was to
suppress the 'inline' keyword on those functions when compiling
libsupc++/eh_ptr.cc, so they get defined in that file. That produces ODR
violations though, because there are now both inline and non-inline
definitions in the library, due to the use of std::exception_ptr in
other files sucg as src/c++11/future.cc.

The new solution is to define all the relevant members as 'inline'
unconditionally, but use __attribute__((used)) to cause definitions to
be emitted in libsupc++/eh_ptr.cc as before. This doesn't quite work
however, because PR c++/67453 means the attribute is ignored on
constructors and destructors. As a workaround, the old solution
(conditionally inline) is still used for those members, but they are
given the always_inline attribute so that they aren't emitted in
src/c++11/future.o as inline definitions.

libstdc++-v3/ChangeLog:

PR libstdc++/97729
* include/std/future (__basic_future::_M_get_result): Use
nullptr for null pointer constant.
* libsupc++/eh_ptr.cc (operator==, operator!=): Remove
definitions.
* libsupc++/exception_ptr.h (_GLIBCXX_EH_PTR_USED): Define
macro to conditionally add __attribute__((__used__)).
(operator==, operator!=, exception_ptr::exception_ptr())
(exception_ptr::exception_ptr(const exception_ptr&))
(exception_ptr::~exception_ptr())
(exception_ptr::operator=(const exception_ptr&))
(exception_ptr::swap(exception_ptr&)): Always define as
inline. Add macro to be conditionally "used".

[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW

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

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

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

https://gcc.gnu.org/g:50b840ac5e1d6534e345c3fee9a97ae45ced6bc7

commit r11-4748-g50b840ac5e1d6534e345c3fee9a97ae45ced6bc7
Author: Jonathan Wakely 
Date:   Thu Nov 5 13:41:40 2020 +

libstdc++: Export basic_stringbuf constructor [PR 97729]

libstdc++-v3/ChangeLog:

PR libstdc++/97729
* config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Add exports.
* src/c++20/sstream-inst.cc (basic_stringbuf): Instantiate
private constructor taking __xfer_bufptrs.

[Bug libstdc++/97731] terminate called in std::experimental::filesystem::recursive_directory_iterator

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |8.5

[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work|10.2.1  |
   Target Milestone|11.0|8.5

--- Comment #8 from Jonathan Wakely  ---
It should be fixed now, could you check?

[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|8.5 |11.0

[Bug tree-optimization/97725] [11 Regression] ICE at -Os and above: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 since r11-4724-

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Andrew Macleod  ---
Created attachment 49512
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49512&action=edit
Use a multirange value in value_query::value_of_*

This was triggered by a new call into range_of_stmt to reevaluate

_3 = e_15 != 0;

we already knew it was [1,1], and had folded some stuff away.  however, e_15
had been further refined so _3 was out of date.

mostly harmless, except e_15 now has a range of
long int [-1, -1][4294967294, 4294967295]

obviously that will still evaluate to [1,1]... except it didn't :-P  it came
back VARYING.

!= checks if the intersection of the 2 operands is empty... which it should be, 
but the code reuses the result range passed in as the temporary.. and that
turns out of be a value_range.  so when we copy  [-1, -1][4294967294,
4294967295] into the value_range, it cant be fully represented, and we end up
with
 long int [-1, 4294967295]
and can no longer tell it is not equal to [0,0].

doh.

First, the range-ops code for not_equal and equal should be adjusted to not use
the range passed in as a temporary.. the consumer may well know this is a
boolean and only pass in an int_range<1> on purpose.

second, the true root is that the 3 value_of_* routines actually pass in a 
value_range rather than a multirange... Original thinking was we are looking
for a single value result.  But there are other range_ops routines that build
into the value passed, like multiply and others, so its better to simple pass
in an int_range_max or something similar could happen elsewhere.

testing the attached patch

[Bug libstdc++/96269] [10/11 Regression] optional comparison with nullopt fails

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

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

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

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

commit r11-4753-gcdd2d448d8200ed5ebcb232163954367b553291e
Author: Jonathan Wakely 
Date:   Thu Nov 5 18:36:19 2020 +

libstdc++: Fix constraints on std::optional comparisons [PR 96269]

The relational operators for std::optional were using the wrong types
in the declval expressions used to constrain them. Instead of using
const lvalues they were using non-const rvalues, which meant that a type
might satisfy the constraints but then give an error when the function
body was instantiated.

libstdc++-v3/ChangeLog:

PR libstdc++/96269
* include/std/optional (operator==, operator!=, operator<)
(operator>, operator<=, operator>=): Fix types used in
SFINAE constraints.
* testsuite/20_util/optional/relops/96269.cc: New test.

[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW

[markus.boeck02 at gmail dot com via Gcc-bugs]

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

Markus Böck  changed:

   What|Removed |Added

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

--- Comment #9 from Markus Böck  ---
Can happily report that it links now! Thanks a lot

[Bug libstdc++/96269] [10/11 Regression] optional comparison with nullopt fails

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #11 from Jonathan Wakely  ---
Fixed for 10.3

[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW

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

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

--- Comment #10 from Jonathan Wakely  ---
Great, thanks for the report and testing the fix.

[Bug libstdc++/96269] [10/11 Regression] optional comparison with nullopt fails

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

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

--- Comment #12 from Jonathan Wakely  ---
Fixed by r10-8983 for gcc-10

[Bug fortran/95847] [9/10/11 Regression] Internal error when processing pFUnit generated files with --coverage

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

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

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Martin Liška from comment #5)
> I can only confirm it's a Fortran issue.
> Can please anybody from Fortran folks take a look?

First, the caveat, the Fortran code in the attached
example is invalid so a compiler can to do whatever
it wants, including dying with an ICE.

Split the example code into a file with only the 
module (say, d.f90) and a file with only the
function foo_suite (say, e.f90).  I get

% gfcx -c --coverage d.f90
% gfcx -c --coverage e.f90

with no ICE.  It seems that the strengthen assumption in
the git commit gets confused on where function information
comes from.

Just a SWAG.  Likely, gfortran reads the newly created
'foo.mod' to get information about the subroutine sbr,
so gfortran simply records the location where it obtains
the information about sbr.  That then means the location
for sbr is set to the line 'use foo'.  Why --coverage
finds the `end subroutine` at line 4 then becomes a
mystery.

Uncompressing the module shows that no location information
is stored in a module.

% cat foo.mod | gunzip
GFORTRAN module version '15' created from d.f90
(() () () () () () () () () () () () () () () () () () () () () () () ()
() () ())
()
()
()
()
()
(2 'foo' 'foo' '' 1 ((MODULE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN
0 0) () (UNKNOWN 0 0 0 0 UNKNOWN ()) 0 0 () () 0 () () () 0 0)
3 'sbr' 'foo' '' 1 ((PROCEDURE UNKNOWN-INTENT MODULE-PROC DECL UNKNOWN 0
0 SUBROUTINE IMPLICIT_PURE) () (UNKNOWN 0 0 0 0 UNKNOWN ()) 0 0 () () 0
() () () 0 0)
)
('foo' 0 2 'sbr' 0 3)

So, it seems the strengthened assumption isn't so strong.

[Bug tree-optimization/97725] [11 Regression] ICE at -Os and above: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 since r11-4724-

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:22984f3f090921b5ac80ec0057f6754ec458e97e

commit r11-4755-g22984f3f090921b5ac80ec0057f6754ec458e97e
Author: Andrew MacLeod 
Date:   Thu Nov 5 13:59:45 2020 -0500

Pass multi-range from range_query::value_*  routines

fix range-ops equal/not_equal to not reuse the result range as
intermediary.
value_query::value routines should pasa multi-range in as some other
rangeop
routines build into this result, so we may need better precision.

gcc/
PR tree-optimization/97725
* range-op.cc (operator_equal::fold_range): Use new tmp value.
(operator_not_equal::fold_range): Ditto.
* value-query.cc (range_query::value_of_expr): Use int_range_max
not a value_range.
(range_query::value_on_edge): Ditto.
(range_query::value_of_stmt): Ditto.
gcc/testsuite/
* gcc.dg/pr97725.c: New.

[Bug tree-optimization/97725] [11 Regression] ICE at -Os and above: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 since r11-4724-

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Macleod  ---
fixed.

[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input

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

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

--- Comment #28 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #25)
> Even if we wanted to do something about it (which I disagree with, e.g.
> given that the implementation matches the documentation), you run into the
> problem that even GIMPLE nor RTL differentiates between:
> void
> foo (void)
> {
>   register int a __asm ("eax") = 1;
>   __asm ("# %0 " : : "c" (a+0));
>   __asm ("# %0 " : : "c" (a));
> }
> And "c" (a+0) unquestionably must be valid, it is just an expression that
> happens to be equal to a value of local register variable.

The documentation says

"""
The only supported use for this feature is to specify registers
for input and output operands when calling Extended @code{asm}-
(@pxref{Extended Asm}).  This may be necessary if the constraints for a-
particular machine don't provide sufficient control to select the desired-
register.  To force an operand into a register, create a local variable-
and specify the register name after the variable's declaration.  Then use-
the local variable for the @code{asm} operand and specify any constraint-
letter that matches the register:

@smallexample
register int *p1 asm ("r0") = @dots{};
register int *p2 asm ("r1") = @dots{};
register int *result asm ("r0");
asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
@end smallexample
"""

Note the "use the local variable *for* the asm operand".  Not *in* the asm
operand.  We really do care about the identity here (for all asm operands),
not the value contained in the operand.

So (a+0) is not valid.  It is of course likely this will be optimised to
just (a) and might even work, but that is not guaranteed.

(The documentation here could be much improved, of course.)

[Bug tree-optimization/97732] [11 Regression] ICE tree check: expected integer_cst, have addr_expr in get_len, at tree.h:6014 since r11-4646-gf53e9d40de721241

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Cleaned up testcase:
struct S { int a, b; } *e;
int d;

void
foo (struct S *x)
{
  for (e = x; d; d++, e++)
e->a = e->b = (int) (__UINTPTR_TYPE__) e;
}

[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input

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

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

--- Comment #29 from Segher Boessenkool  ---
(In reply to Richard Biener from comment #26)
> So it would need to be diagnosed in the FE (only), making a + 0 valid and
> a not.  Eh.

We do not *have* to diagnose anything, certainly not things that just
happen to work (if "a+0" is optimised to just "a", say).  But it would
be good if we could diagnose the obvious and certainly wrong cases we
do not do now -- like a register asm that does not match the operand
constraint!

[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations

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

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

--- Comment #19 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:5b2003105b35f8fe8e074c055a718c8f484d9d32

commit r11-4756-g5b2003105b35f8fe8e074c055a718c8f484d9d32
Author: Marek Polacek 
Date:   Fri Oct 2 09:46:30 2020 -0400

c++: Implement -Wvexing-parse [PR25814]

This patch implements the -Wvexing-parse warning to warn about the
sneaky most vexing parse rule in C++: the cases when a declaration
looks like a variable definition, but the C++ language requires it
to be interpreted as a function declaration.  This warning is on by
default (like clang++).  From the docs:

  void f(double a) {
int i();// extern int i (void);
int n(int(a));  // extern int n (int);
  }

  Another example:

  struct S { S(int); };
  void f(double a) {
S x(int(a));   // extern struct S x (int);
S y(int());// extern struct S y (int (*) (void));
S z(); // extern struct S z (void);
  }

You can find more on this in [dcl.ambig.res].

I spent a fair amount of time on fix-it hints so that GCC can recommend
various ways to resolve such an ambiguity.  Sometimes that's tricky.
E.g., suggesting default-initialization when the class doesn't have
a default constructor would not be optimal.  Suggesting {}-init is also
not trivial because it can use an initializer-list constructor if no
default constructor is available (which ()-init wouldn't do).  And of
course, pre-C++11, we shouldn't be recommending {}-init at all.

I also uncovered a bug in cp_parser_declarator, where we were setting
*parenthesized_p to true despite the comment saying the exact opposite.

gcc/c-family/ChangeLog:

PR c++/25814
* c.opt (Wvexing-parse): New option.

gcc/cp/ChangeLog:

PR c++/25814
* cp-tree.h (enum cp_tree_index): Add CPTI_EXPLICIT_VOID_LIST.
(explicit_void_list_node): Define.
(PARENTHESIZED_LIST_P): New macro.
(struct cp_declarator): Add function::parens_loc.
* decl.c (cxx_init_decl_processing): Initialize
explicit_void_list_node.
(grokparms): Also break when explicit_void_list_node.
* parser.c (make_call_declarator): New location_t parameter.  Use
it
to set declarator->u.function.parens_loc.
(cp_parser_lambda_declarator_opt): Pass UNKNOWN_LOCATION to
make_call_declarator.
(warn_about_ambiguous_parse): New function.
(cp_parser_init_declarator): Call warn_about_ambiguous_parse.
(cp_parser_declarator): Set *parenthesized_p to false rather than
to
true.
(cp_parser_direct_declarator): Create a location for the function's
parentheses and pass it to make_call_declarator.
(cp_parser_parameter_declaration_clause): Return
explicit_void_list_node
for (void).
(cp_parser_parameter_declaration_list): Set PARENTHESIZED_LIST_P
in the parameters tree.

gcc/ChangeLog:

PR c++/25814
* doc/invoke.texi: Document -Wvexing-parse.

gcc/testsuite/ChangeLog:

PR c++/25814
* g++.dg/cpp2a/fn-template16.C: Add a dg-warning.
* g++.dg/cpp2a/fn-template7.C: Likewise.
* g++.dg/lookup/pr80891-5.C: Likewise.
* g++.dg/lto/pr79050_0.C: Add extern.
* g++.dg/lto/pr84805_0.C: Likewise.
* g++.dg/parse/pr58898.C: Add a dg-warning.
* g++.dg/template/scope5.C: Likewise.
* g++.old-deja/g++.brendan/recurse.C: Likewise.
* g++.old-deja/g++.jason/template4.C: Likewise.
* g++.old-deja/g++.law/arm4.C: Likewise.
* g++.old-deja/g++.mike/for2.C: Likewise.
* g++.old-deja/g++.other/local4.C: Likewise.
* g++.old-deja/g++.pt/crash3.C: Likewise.
* g++.dg/warn/Wvexing-parse.C: New test.
* g++.dg/warn/Wvexing-parse2.C: New test.
* g++.dg/warn/Wvexing-parse3.C: New test.
* g++.dg/warn/Wvexing-parse4.C: New test.
* g++.dg/warn/Wvexing-parse5.C: New test.
* g++.dg/warn/Wvexing-parse6.C: New test.
* g++.dg/warn/Wvexing-parse7.C: New test.

libstdc++-v3/ChangeLog:

PR c++/25814
* testsuite/20_util/reference_wrapper/lwg2993.cc: Add a dg-warning.
* testsuite/25_algorithms/generate_n/87982_neg.cc: Likewise.

[Bug c++/97675] GCC does not allow turning off the warning for exceptions being caught by an earlier handler

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:1d87302a8e20c1f49dd37177ec869ee94abc11a5

commit r11-4757-g1d87302a8e20c1f49dd37177ec869ee94abc11a5
Author: Marek Polacek 
Date:   Tue Nov 3 17:46:23 2020 -0500

c++: Add -Wexceptions warning option [PR97675]

This PR asks that we add a warning option for an existing (very old)
warning, so that it can be disabled selectively.  clang++ uses
-Wexceptions for this, so I added this new option rather than using
e.g. -Wnoexcept.

gcc/c-family/ChangeLog:

PR c++/97675
* c.opt (Wexceptions): New option.

gcc/cp/ChangeLog:

PR c++/97675
* except.c (check_handlers_1): Use OPT_Wexceptions for the
warning.  Use inform for the second part of the warning.

gcc/ChangeLog:

PR c++/97675
* doc/invoke.texi: Document -Wexceptions.

gcc/testsuite/ChangeLog:

PR c++/97675
* g++.old-deja/g++.eh/catch10.C: Adjust dg-warning.
* g++.dg/warn/Wexceptions1.C: New test.
* g++.dg/warn/Wexceptions2.C: New test.