[Bug bootstrap/98340] New: gcc trunk build with clang failure, part 2

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 98340
   Summary: gcc trunk build with clang failure, part 2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

More fallout from Nathan's new module code. Probably.

../../trunk.git/gcc/cp/module.cc:2722:28: error: 'uintset::values' is not a member of class 'uintset::hash'
 + sizeof (uintset::values) * n);
   ~^
../../trunk.git/gcc/cp/module.cc:7550:22: note: in instantiation of member
function 'uintset::hash::add' requested here
if (!pending_table->add (key_ident, ~ident))
^
../../trunk.git/gcc/cp/module.cc:2747:28: error: 'uintset::values'
is not a member of class 'uintset::hash'
 + (sizeof (uintset::values) << p2alloc));
~^
../../trunk.git/gcc/cp/module.cc:8086:24: note: in instantiation of member
function 'uintset::hash::create' requested here
set = attached_table->create (DECL_UID (inner), num, NULL_TREE);
../../trunk.git/gcc/cp/module.cc:2722:28: error: 'uintset::values' is not a member of class 'uintset::hash'
 + sizeof (uintset::values) * n);
   ~^
../../trunk.git/gcc/cp/module.cc:18493:23: note: in instantiation of member
function 'uintset::hash::add' requested here
  if (attached_table->add (DECL_UID (ctx), decl))
  ^
  ^

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #1 from David Binderman  ---
As expected, git blame indicates Nathan.

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

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e

--- Comment #42 from John Paul Adrian Glaubitz  ---
Ada bootstrap on m68k is broken as well.

Full buildlog in:
https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot&arch=m68k&ver=1%3A20201214-1&stamp=1608126919&raw=0

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This boils down to:

template 
struct delete_ptr_hash
{
};

template 
struct hash_table
{
};

template 
struct uintset
{
  T values[1];
  struct traits : delete_ptr_hash 
  {
  };
  struct hash : hash_table 
  {
int foo ();
  };
  hash h;
};

template 
int
uintset::hash::foo ()
{
  return sizeof (uintset::values);
}

uintset s;
int x = s.h.foo ();

This is rejected by g++ up to 4.5.x, icc 13 and clang (all versions) and
accepted by gcc 4.6 and later and icc 16 and later.

[Bug target/98341] New: [11 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

Bug ID: 98341
   Summary: [11 Regression] Ada bootstrap fails with Storage_Error
stack overflow or erroneous memory access on m68k
   Product: gcc
   Version: 11.0
   URL: https://buildd.debian.org/status/fetch.php?pkg=gcc-sna
pshot&arch=m68k&ver=1%3A20201214-1&stamp=1608126919&ra
w=0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
  Target Milestone: ---
Target: m68k-*-*

Bootstrapping Ada works fine with gcc-10, but is broken with gcc-11/trunk:

+===GNAT BUG DETECTED==+
| 11.0.0 20201214 (experimental) [master revision
cf7efe2d36f:0bf15ad54b9:ab28eac607637a641fbec27c5f6bbe9b6197c80f]
(m68k-linux-gnu) |
| Storage_Error stack overflow or erroneous memory access  |
| No source file position information available|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

../../src/gcc/ada/gcc-interface/system.ads
../../src/gcc/ada/sem_aggr.adb
../../src/gcc/ada/sem_aggr.ads
../../src/gcc/ada/types.ads
../../src/gcc/ada/libgnat/unchconv.ads
../../src/gcc/ada/libgnat/unchdeal.ads
../../src/gcc/ada/aspects.ads
../../src/gcc/ada/namet.ads
../../src/gcc/ada/alloc.ads
../../src/gcc/ada/hostparm.ads
../../src/gcc/ada/table.ads
ada/snames.ads
../../src/gcc/ada/atree.ads
../../src/gcc/ada/sinfo.ads
../../src/gcc/ada/uintp.ads
../../src/gcc/ada/urealp.ads
../../src/gcc/ada/einfo.ads
../../src/gcc/ada/checks.ads
../../src/gcc/ada/errout.ads
../../src/gcc/ada/err_vars.ads
../../src/gcc/ada/erroutc.ads
../../src/gcc/ada/elists.ads
../../src/gcc/ada/expander.ads
../../src/gcc/ada/exp_ch6.ads
../../src/gcc/ada/exp_tss.ads
../../src/gcc/ada/exp_util.ads
../../src/gcc/ada/rtsfind.ads
../../src/gcc/ada/freeze.ads
../../src/gcc/ada/itypes.ads
../../src/gcc/ada/sem_util.ads
../../src/gcc/ada/opt.ads
../../src/gcc/ada/libgnat/s-string.ads
../../src/gcc/ada/libgnat/ada.ads
../../src/gcc/ada/libgnat/a-uncdea.ads
../../src/gcc/ada/libgnat/s-wchcon.ads
../../src/gcc/ada/lib.ads
../../src/gcc/ada/libgnat/gnat.ads
../../src/gcc/ada/libgnat/g-htable.ads
../../src/gcc/ada/libgnat/s-htable.ads
../../src/gcc/ada/lib-xref.ads
../../src/gcc/ada/spark_xrefs.ads
../../src/gcc/ada/namet-sp.ads
ada/nmake.ads
../../src/gcc/ada/nlists.ads
../../src/gcc/ada/restrict.ads
../../src/gcc/ada/rident.ads
../../src/gcc/ada/libgnat/s-rident.ads
../../src/gcc/ada/sem.ads
../../src/gcc/ada/sem_aux.ads
../../src/gcc/ada/sem_cat.ads
../../src/gcc/ada/sem_ch3.ads
../../src/gcc/ada/sem_ch5.ads
../../src/gcc/ada/sem_ch8.ads
../../src/gcc/ada/sem_ch13.ads
../../src/gcc/ada/sem_disp.ads
../../src/gcc/ada/sem_dim.ads
../../src/gcc/ada/sem_eval.ads
../../src/gcc/ada/sem_res.ads
../../src/gcc/ada/sem_type.ads
../../src/gcc/ada/sem_warn.ads
../../src/gcc/ada/stringt.ads
../../src/gcc/ada/stand.ads
../../src/gcc/ada/style.ads
../../src/gcc/ada/styleg.ads
../../src/gcc/ada/targparm.ads
../../src/gcc/ada/tbuild.ads
../../src/gcc/ada/ttypes.ads
../../src/gcc/ada/set_targ.ads
../../src/gcc/ada/libgnat/s-stalib.ads
../../src/gcc/ada/libgnat/a-unccon.ads
../../src/gcc/ada/libgnat/s-exctab.ads
../../src/gcc/ada/libgnat/s-unstyp.ads
../../src/gcc/ada/libgnat/s-conca2.ads
../../src/gcc/ada/libgnat/s-assert.ads
../../src/gcc/ada/libgnat/a-except.ads
../../src/gcc/ada/libgnat/s-parame.ads
../../src/gcc/ada/libgnat/s-traent.ads
../../src/gcc/ada/atree.adb
../../src/gcc/ada/debug.ads
../../src/gcc/ada/output.ads
../../src/gcc/ada/libgnat/s-os_lib.ads
../../src/gcc/ada/sinput.ads
../../src/gcc/ada/casing.ads
../../src/gcc/ada/libgnat/g-hesorg.ads

compilation abandoned
make[5]: *** [../../src/gcc/ada/gcc-interface/Make-lang.in:139: ada/sem_aggr.o]
Error 1
make[5]: *** Waiting for unfinished jobs
rm gpl.pod cpp.pod fsf-funding.pod gcc.pod gfdl.pod gcov-tool.pod lto-dump.pod
gcov.pod gcov-dump.pod gdc.pod gfortran.pod

[Bug bootstrap/98338] [11 Regression] profiledbootstrap failure on x86_64-linux

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-12-17

--- Comment #3 from Martin Liška  ---
Reproduced, looking into it now.

[Bug c/94722] implement __attribute__((no_stack_protector)) function attribute

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

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

--- Comment #8 from Martin Liška  ---
I guess Jakub can chime in. He was actively involved in Linux kernel
discussion.

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

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

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

--- Comment #3 from Jakub Jelinek  ---
Before r0-99643-g2defb926479247a61fe0fffbcf95597722a94c40 this used to be
rejected with:
pr98340.C: In member function ‘int uintset::hash::foo() [with T = int]’:
pr98340.C:33:18:   instantiated from here
pr98340.C:29:33: error: type ‘uintset’ is not a base type for type
‘uintset::hash’

clang++ rejects the above testcase even if it is just struct traits {};
i.e. not derived from delete_ptr_hash , but accepts it if
uintptr::hash isn't derived from hash_table but say hash_table
(rejects if it is derived
from hash_table::traits> though).
I guess a C++ language lawyer would need to have a look if it is a clang++ bug
or g++ bug in accepting it.  Of course, even if it is clang++ bug, a workaround
is possible, e.g. it could use sizeof (T) rather than sizeof (uintset::values),
after all, when it multiplicates by n, I guess it wants sizeof
(uintset::values[0]) anyway, because it uses trailing array of Ts rather
than T[1]s.

[Bug c/94722] implement __attribute__((no_stack_protector)) function attribute

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
I've said in that thread that I don't really like disabling the inlining, if we
wanted to make sure everything is stack protected, we'd need to disable all the
inlining no matter whether the attribute is there or not, because inlining by
definition removes the stack protector checks, it is only tested on function
boundaries, not on inline function boundaries.
The user has the option to add noinline when he wants.

[Bug fortran/98342] New: Allocatable component in call to assumed-rank routine causes invalid pointer

[mscfd at gmx dot net via Gcc-bugs]

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

Bug ID: 98342
   Summary: Allocatable component in call to assumed-rank routine
causes invalid pointer
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

Created attachment 49784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49784&action=edit
Fortran source code

The attached code aborts with
 *** Error in `./alloc_rank.x': munmap_chunk(): invalid pointer
after finishing the function call to "sel_rank". Necessary ingredients are a
derived type with an allocatable component and that the argument tuple of
"sel_rank" has assumed rank.

[Bug bootstrap/98338] [11 Regression] profiledbootstrap failure on x86_64-linux

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||doko at debian dot org

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

[Bug target/98045] [11 Regression] ICE in compute_fn_summary, at ipa-fnsummary.c:3138 on powerpc64le-linux-gnu

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Dup.

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

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #35 from Thomas Schwinge  ---
In an '--enable-werror' configuration (assuming that's relevant), I'm seeing
new code from commit r11-4691-g93e79ed391b9c636f087e6eb7e70f14963cd10ad
"libstdc++: Rewrite std::call_once to use futexes [PR 66146]" fail to build:

[...]/source-gcc/libstdc++-v3/src/c++11/mutex.cc: In member function ‘void
std::once_flag::_M_finish(bool)’:
[...]/source-gcc/libstdc++-v3/src/c++11/mutex.cc:77:11: error: unused
variable ‘prev’ [-Werror=unused-variable]
   77 |   int prev = __atomic_exchange_n(&_M_once, newval,
__ATOMIC_RELEASE);
  |   ^~~~
cc1plus: all warnings being treated as errors
Makefile:648: recipe for target 'mutex.lo' failed
make[5]: *** [mutex.lo] Error 1
make[5]: Leaving directory
'[...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11'

Should a '(void) prev;' be added (my current workaround), or 'prev' get some
attribute 'used' added, or something else?

[Bug fortran/97694] ICE with optional assumed rank class(*) argument

[mscfd at gmx dot net via Gcc-bugs]

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

--- Comment #6 from martin  ---
There is still a somewhat related problem if a variable of a derived type with
allocatable component is provided to cssel. See bug 98342 with a simplified
example code (without class(*)).

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

[mscfd at gmx dot net via Gcc-bugs]

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

--- Comment #1 from martin  ---
This does not the require the recent patch proposed for bug 97694 and bug
97723. It also fails with gfortran 10.1.0.

[Bug fortran/98307] Dependency check fails when using "allocatable" instead of "pointer" (forall_3.f90)

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r11-6193-gc09deceb534b82ce144af3a345dcb06ab5e49ba4
Author: Harald Anlauf 
Date:   Thu Dec 17 10:31:55 2020 +0100

PR fortran/98307 - Dependency check fails when using "allocatable"

The dependency check for FORALL constructs already handled pointer
components to derived types, but missed allocatables.  Fix that.

gcc/fortran/ChangeLog:

PR fortran/98307
* trans-stmt.c (check_forall_dependencies): Extend dependency
check to allocatable components of derived types.

gcc/testsuite/ChangeLog:

PR fortran/98307
* gfortran.dg/forall_19.f90: New test.

[Bug fortran/92587] [9/10/11 Regression] Compiler is unable to generate finalization wrapper

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r11-6194-gba9fa684053917a07bfa8f4742da0e196e72b9a2
Author: Tobias Burnus 
Date:   Thu Dec 17 10:39:09 2020 +0100

Fortran: Delay vtab generation until after parsing [PR92587]

gcc/fortran/ChangeLog:

PR fortran/92587
* match.c (gfc_match_assignment): Move gfc_find_vtab call from here
...
* resolve.c (gfc_resolve_code): ... to here.

gcc/testsuite/ChangeLog:

PR fortran/92587
* gfortran.dg/finalize_37.f90: New test.

[Bug bootstrap/98338] [11 Regression] profiledbootstrap failure on x86_64-linux

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

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

--- Comment #5 from Martin Liška  ---
Created attachment 49785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49785&action=edit
Reduced test-case

I reduced both the source file and the corresponding GCDA file.

[Bug bootstrap/98338] [11 Regression] profiledbootstrap failure on x86_64-linux

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

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
  Known to fail||11.0
  Known to work||10.2.0
 CC||hubicka at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
Started with r11-5162-gd8cf89767492a41b0f76e0aa302dddee4e1b3434 where Honza
improved merging of OBJ_TYPE_REFs.

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

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

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

--- Comment #36 from Jonathan Wakely  ---
Attribute unused, not attribute used.

I'll fix it shortly.

[Bug bootstrap/98338] [11 Regression] profiledbootstrap failure on x86_64-linux

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

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

--- Comment #7 from Jakub Jelinek  ---
Doesn't that just enable the possibility of ICF optimization of those:
bool
operator_plus::op1_range (irange &r, tree type,
  const irange &lhs,
  const irange &op2) const
{
  return range_op_handler (MINUS_EXPR, type)->fold_range (r, type, lhs, op2);
}

bool
operator_plus::op2_range (irange &r, tree type,
  const irange &lhs,
  const irange &op1) const
{
  return range_op_handler (MINUS_EXPR, type)->fold_range (r, type, lhs, op1);
}
methods?

[Bug tree-optimization/98334] Failure to optimally optimize add loop to mul

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This boils down to:
int
bar (int x, int y)
{
  return (int) (y - 1U) * x + x;
}

int
baz (int x, int y)
{
  return (y - 1) * x + x;
}

We do optimize the latter, but don't optimize the former into y * x.
For non-wrapping operation in bar that would be an invalid optimization,
as (int) (y - 1U) * x + x is well defined for y == INT_MIN and x == -1:
it is INT_MAX * -1 + -1, i.e. INT_MIN without overflow, but INT_MIN * -1
does overflow.
But we perhaps could and should turn that into just (int) ((y - 1U) * x),
i.e. unsigned multiplication.
We shouldn't do this until very late though, because turning signed arithmetics
into unsigned may disable other optimizations as it has no UB.

Or we could optimize this on RTL, combiner attempts:
Trying 7, 8 -> 9:
7: {r90:SI=r93:SI-0x1;clobber flags:CC;}
  REG_DEAD r93:SI
  REG_UNUSED flags:CC
8: {r91:SI=r90:SI*r92:SI;clobber flags:CC;}
  REG_UNUSED flags:CC
  REG_DEAD r90:SI
9: r89:SI=r91:SI+r92:SI
  REG_DEAD r92:SI
  REG_DEAD r91:SI
Failed to match this instruction:
(set (reg:SI 89)
(plus:SI (mult:SI (plus:SI (reg:SI 93)
(const_int -1 [0x]))
(reg:SI 92))
(reg:SI 92)))
so if we hack up simplify-rtx.c to optimize that to (mult:SI (reg:SI 93)
(reg:SI 92)), it should work.

[Bug bootstrap/98338] [11 Regression] profiledbootstrap failure on x86_64-linux

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

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

--- Comment #8 from Martin Liška  ---
So the following 2 functions are merged:

(gdb) p original->debug()
_ZNK13operator_plus9op1_rangeER6irangeP9tree_nodeRKS0_S5_/1 (bool
operator_plus::op1_range(irange&, tree, const irange&, const irange&) const)
@0x7756b000
  Type: function definition analyzed
  Visibility: externally_visible public
  References: range_op_handler_type_0_0/6 (read) pointer_tree_table/5 (read)
integral_tree_table/4 (read)
_ZNK14range_operator10fold_rangeER6irangeP9tree_nodeRKS0_S5_/0 (addr)
(speculative) 
  Referring: 
  Availability: available
  Profile id: 1426567252
  Function flags: count:15202 (precise) first_run:5548 body hot
  Called by: 
  Calls: _ZNK14range_operator10fold_rangeER6irangeP9tree_nodeRKS0_S5_/0
(speculative) (15202 (adjusted),1.00 per call) 
   Polymorphic indirect call of type const struct range_operator
token:0(speculative) (0 (adjusted),0.00 per call) num speculative call targets:
1
Outer type (dynamic):struct range_operator (or a derived type) offset 0

bool operator_plus::op1_range (const struct operator_plus * const this, struct
irange & r, struct tree_node * type, const struct irange & lhs, const struct
irange & op2)
{
   [count: 15202]:
  range_op_handler_type_0_0.1_4 = range_op_handler_type_0_0;
  if (range_op_handler_type_0_0.1_4 == 1)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  _11 = pointer_tree_table.m_range_tree[2];
  goto ; [100.00%]

   [count: 15202]:
  if (range_op_handler_type_0_0.1_4 != 0)
goto ; [100.00%]
  else
goto ; [0.00%]

   [count: 15202]:
  _12 = integral_tree_table.m_range_tree[2];

   [count: 15202]:
  # _13 = PHI <_11(3), 0B(4), _12(5)>
  _1 = _13->_vptr.range_operator;
  _2 = *_1;
  _10 = OBJ_TYPE_REF(_2;(const struct range_operator)_13->0) (_13, r_5(D),
type_6(D), lhs_7(D), op2_8(D));
  return _10;

}

$26 = void
(gdb) p alias->debug()
_ZNK13operator_plus9op2_rangeER6irangeP9tree_nodeRKS0_S5_/2 (bool
operator_plus::op2_range(irange&, tree, const irange&, const irange&) const)
@0x7756b110
  Type: function definition analyzed
  Visibility: externally_visible public
  References: range_op_handler_type_0_0/6 (read) pointer_tree_table/5 (read)
integral_tree_table/4 (read)
_ZNK14range_operator10fold_rangeER6irangeP9tree_nodeRKS0_S5_/0 (addr)
(speculative) 
  Referring: 
  Availability: available
  Profile id: 1031185534
  Function flags: count:15141 (precise) first_run:6411 body icf_merged hot
  Called by: 
  Calls: _ZNK14range_operator10fold_rangeER6irangeP9tree_nodeRKS0_S5_/0
(speculative) (15141 (adjusted),1.00 per call) 
   Polymorphic indirect call of type const struct range_operator
token:0(speculative) (0 (adjusted),0.00 per call) num speculative call targets:
1
Outer type (dynamic):struct range_operator (or a derived type) offset 0

(gdb) p debug_function(alias->decl, 0)
bool operator_plus::op2_range (const struct operator_plus * const this, struct
irange & r, struct tree_node * type, const struct irange & lhs, const struct
irange & op1)
{
   [count: 15141]:
  range_op_handler_type_0_0.1_4 = range_op_handler_type_0_0;
  if (range_op_handler_type_0_0.1_4 == 1)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  _11 = pointer_tree_table.m_range_tree[2];
  goto ; [100.00%]

   [count: 15141]:
  if (range_op_handler_type_0_0.1_4 != 0)
goto ; [100.00%]
  else
goto ; [0.00%]

   [count: 15141]:
  _12 = integral_tree_table.m_range_tree[2];

   [count: 15141]:
  # _13 = PHI <_11(3), 0B(4), _12(5)>
  _1 = _13->_vptr.range_operator;
  _2 = *_1;
  _10 = OBJ_TYPE_REF(_2;(const struct range_operator)_13->0) (_13, r_5(D),
type_6(D), lhs_7(D), op1_8(D));
  return _10;

}

As seen both have a speculative indirect call. That's properly merged into:

$29 = void
(gdb) p dst->debug()
_ZNK13operator_plus9op1_rangeER6irangeP9tree_nodeRKS0_S5_/1 (bool
operator_plus::op1_range(irange&, tree, const irange&, const irange&) const)
@0x7756b000
  Type: function definition analyzed
  Visibility: externally_visible public
  References: range_op_handler_type_0_0/6 (read) pointer_tree_table/5 (read)
integral_tree_table/4 (read)
_ZNK14range_operator10fold_rangeER6irangeP9tree_nodeRKS0_S5_/0 (addr)
(speculative) 
  Referring: 
  Availability: available
  Profile id: 1426567252
  Function flags: count:30343 (precise) first_run:5548 body icf_merged hot
  Called by: 
  Calls: _ZNK14range_operator10fold_rangeER6irangeP9tree_nodeRKS0_S5_/0
(speculative) (30343 (adjusted),1.00 per call) 
   Polymorphic indirect call of type const struct range_operator
token:0(speculative) (0 (adjusted),0.00 per call) num speculative call targets:
1
Outer type (dynamic):struct range_operator (or a derived type) offset 0
$30 = void
(gdb) p debug_function(dst->decl, 0)
bool operator_plus::op1_range (const struct operator_plus * const this, struct
irange & r, struct tree_node * type, const struct irange & lhs, const struct
irange & op2)
{
   [count: 30343]:
  range_op_

[Bug bootstrap/98338] [11 Regression] profiledbootstrap failure on x86_64-linux

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

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

--- Comment #9 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #7)
> Doesn't that just enable the possibility of ICF optimization of those:
> bool
> operator_plus::op1_range (irange &r, tree type,
>   const irange &lhs,
>   const irange &op2) const
> {
>   return range_op_handler (MINUS_EXPR, type)->fold_range (r, type, lhs, op2);
> }
> 
> bool
> operator_plus::op2_range (irange &r, tree type,
>   const irange &lhs,
>   const irange &op1) const
> {
>   return range_op_handler (MINUS_EXPR, type)->fold_range (r, type, lhs, op1);
> }
> methods?

Yes. The problem is related to the speculative indirect call.

[Bug c++/98343] New: [11 Regression] ICE in in relocate_ptrs, at ggc-common.c:363 [PCH and C++20 std::source_location?]

[pexu--- via Gcc-bugs]

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

Bug ID: 98343
   Summary: [11 Regression] ICE in in relocate_ptrs, at
ggc-common.c:363 [PCH and C++20 std::source_location?]
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p...@gcc-bugzilla.mail.kapsi.fi
  Target Milestone: ---
  Host: x86_64-w64-mingw32 x86_64-linux-gnu
Target: aarch64-none-elf

Created attachment 49786
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49786&action=edit
An input header using std::source_location::current().

Hi.

Using GCC11 trunk built on 15.12.2020 @ x86_64-w64-mingw32 and 16.12.2020 @
x86_64-linux-gnu (sorry, unable to the latest trunk due to PR98300).

When attempting to precompile the following input header file GCC will ICE at
ggc-common.  However that happens only, and only if, certain warnings are
enabled.  `-Wall' will trigger this, and to be more precise any of the
following warnings: `-Wformat', `-Wnonnull' or `-Wrestrict'.

I do know if `std::source_location' is a red herring, or the warning flags, but
using a (large) real life file when the ICE occurs all symptoms point (dumping
a corresponding troublesome hash table) to  locations which use
`std::source_location::current()'.  Again, without `-Wall', PCH is compiled
just fine.  (The resulting GCH is over 128 MB.)

I'm able to reproduce this on both Windows and Linux.  I quickly tried a GCC10
(Windows) GCC9 (Linux) and they work just fine with that input file (though
those where not aarch64 targets;  I presume this really has nothing to with the
target).

$ cat pch.hpp
#if __has_include()
#include 
#else
#include 
namespace std { using namespace experimental; }
#endif
extern void location_fun(std::source_location loc =
std::source_location::current());


$ aarch64-none-elf-g++ -std=c++20 -c pch.hpp -Wall
pch.hpp:2:85: internal compiler error: in relocate_ptrs, at ggc-common.c:363
2 | extern void location_fun(std::source_location loc =
std::source_location::current());

$ aarch64-none-elf-g++ -std=c++20 -c pch.hpp -Wall -wrapper gdb,--args
(gdb) break fancy_abort
(gdb) run
Thread 1 hit Breakpoint 1, fancy_abort (
file=0x1eefb00 <(anonymous namespace)::pass_data_rtl_pre+576>
"<...>/src/gcc/gcc/ggc-common.c", line=363, function=0x1eefbc2 <(anonymous
namespace)::pass_data_rtl_pre+770> "relocate_ptrs")
at <...>/src/gcc/gcc/diagnostic.c:1835

(gdb) bt
#0  fancy_abort (
file=0x1eefb00 <(anonymous namespace)::pass_data_rtl_pre+576>
"<...>/src/gcc/gcc/ggc-common.c", line=363, function=0x1eefbc2 <(anonymous
namespace)::pass_data_rtl_pre+770> "relocate_ptrs")
at <...>/src/gcc/gcc/diagnostic.c:1835
#1  0x01c15cc8 in relocate_ptrs (ptr_p=0x210ea9b0, state_p=)
at <...>/src/gcc/gcc/ggc-common.c:351
#2  relocate_ptrs (ptr_p=0x210ea9b0, state_p=)
at <...>/src/gcc/gcc/ggc-common.c:351
#3  0x00471ea6 in ggc_remove::pch_nx
(cookie=0x1cf0fab0,
op=0x8d75e0 , p=...) at
<...>/src/gcc/gcc/hash-traits.h:255
#4  hashtab_entry_note_pointers
(obj=, h=0x210d5960,
op=0x8d75e0 , cookie=0x1cf0fab0)
at <...>/src/gcc/gcc/hash-table.h:1181
#5  0x008d7d70 in gt_pch_save (f=) at
<...>/src/gcc/gcc/ggc-common.c:549
#6  0x006b72d8 in c_common_write_pch () at
<...>/src/gcc/gcc/c-family/c-pch.c:177
#7  0x004ce405 in c_parse_final_cleanups () at
<...>/src/gcc/gcc/cp/decl2.c:4911
#8  0x00bc34a2 in compile_file () at <...>/src/gcc/gcc/toplev.c:457
#9  0x01c8ff38 in do_compile () at <...>/src/gcc/gcc/toplev.c:2193
#10 toplev::main (this=this@entry=0x1cf0fe0e, argc=,
argc@entry=19, argv=,
argv@entry=0x1f7425b0) at <...>/src/gcc/gcc/toplev.c:2332
#11 0x01df7107 in main (argc=19, argv=0x1f7425b0) at
<...>/src/gcc/gcc/main.c:39

(gdb) print *((hash_table*)0x210d5960)
$1 = {m_entries = 0x210ea800, m_size = 127, m_n_elements = 1, m_n_deleted = 0,
m_searches = 1, m_collisions = 0,
  m_size_prime_index = 4, m_ggc = true, m_sanitize_eq_and_hash = true, static
m_gather_mem_stats = false}

(gdb) print *((hash_table*)0x210d5960)->m_entries@127
$2 = {{loc = 0, uid = 0, var = 0x0} , {loc = 10262528, uid =
4294967295, var = 0x210eb2d0}, {
loc = 0, uid = 0, var = 0x0} }

(gdb) call expand_location (10262528)
$3 = {file = 0x1cf91790 "pch.hpp", line = 7, column = 83, data = 0x0, sysp =
false}


I noticed that on a few times `expand_location' displayed incorrect line or
column information for the given input location -- so, the real issue might be
buried quite deep.  (I was using an older GDB9, so it might an issue, too.)


I used this to probe the problematic warnings.  I took the list from
documentation, I presume it should be pretty complete.

$ for flag in -Waddress -Warray-bounds=1 -Wbool-compare -Wbool-operation
-Wc++11-compat -Wc++14-compat -Wcatch-value -Wchar-subsc

[Bug rtl-optimization/98334] Failure to optimally optimize add loop to mul

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2020-12-17
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

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

Untested fix.

[Bug c++/98326] [10/11 Regression] ICE: in create_tmp_var, at gimple-expr.c:482, converting stateless generic-lambda to function pointer since r10-599-gc652ff8312433483

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |10.3
   Last reconfirmed||2020-12-17
  Known to fail||10.2.0, 11.0
  Known to work||9.3.0
 CC||marxin at gcc dot gnu.org
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
Summary|ICE: in create_tmp_var, at  |[10/11 Regression] ICE: in
   |gimple-expr.c:482,  |create_tmp_var, at
   |converting stateless|gimple-expr.c:482,
   |generic-lambda to function  |converting stateless
   |pointer |generic-lambda to function
   ||pointer since
   ||r10-599-gc652ff8312433483

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-599-gc652ff8312433483.

[Bug c++/98327] C++ Module ICE on Linux

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-17
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Can't reproduce with the current master:

$ g++ pr98327.cc -c -fmodules-ts -std=c++20
pr98327.cc:3:8: error: module-declaration not permitted here
3 | export module hello;
  |^~
pr98327.cc:4:1: error: ‘export’ may only occur after a module interface
declaration
4 | export inline void greeter (std::string_view name) noexcept
  | ^~

[Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-12-17
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can't reproduce that with the current master.

[Bug c++/98331] [9/10/11 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-17
 CC||aoliva at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|[9/10/11 Regression] ICE in |[9/10/11 Regression] ICE in
   |haifa_luid_for_non_insn, at |haifa_luid_for_non_insn, at
   |haifa-sched.c:7845  |haifa-sched.c:7845 since
   ||r8-5479-g67a8d7199fe4e474
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r8-5479-g67a8d7199fe4e474.

[Bug c++/98332] [10/11 Regression] ICE in unshare_constructor, at cp/constexpr.c:1527 since r6-7607-g52228180f1e50cbb

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|[10/11 Regression] ICE in   |[10/11 Regression] ICE in
   |unshare_constructor, at |unshare_constructor, at
   |cp/constexpr.c:1527 |cp/constexpr.c:1527 since
   ||r6-7607-g52228180f1e50cbb
   Last reconfirmed||2020-12-17
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r6-7607-g52228180f1e50cbb.

[Bug c++/98343] [11 Regression] ICE in in relocate_ptrs, at ggc-common.c:363 [PCH and C++20 std::source_location?]

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
namespace std
{
  struct source_location
  {
struct __impl
{
  const char* _M_file_name;
  const char* _M_function_name;
  unsigned _M_line;
  unsigned _M_column;
};
const __impl* _M_impl = nullptr;
  };
}
const void *ptr = __builtin_source_location ();

is enough.

[Bug c++/98333] [10/11 Regression] ICE in check_qualified_type, at tree.c:6593 since r10-1280-g78f7607db4c53f8c

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-17
 Status|UNCONFIRMED |NEW
Summary|[10/11 Regression] ICE in   |[10/11 Regression] ICE in
   |check_qualified_type, at|check_qualified_type, at
   |tree.c:6593 |tree.c:6593 since
   ||r10-1280-g78f7607db4c53f8c
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r10-1280-g78f7607db4c53f8c.

[Bug libstdc++/98344] New: Testsuite 17_intro/headers/c++2020/stdc++.cc failure

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

Bug ID: 98344
   Summary: Testsuite 17_intro/headers/c++2020/stdc++.cc failure
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

Testsuite on x86_64-*-dragonfly gives:

Running target unix
FAIL: 17_intro/headers/c++2020/stdc++.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc (test for excess
errors)

spawn -ignore SIGHUP /build/trunk/./gcc/xg++ -shared-libgcc
-B/build/trunk/./gcc -nostdinc++
-L/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/src
-L/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/src/.libs
-L/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/libsupc++/.libs
-B/opt/gcc11f/x86_64-unknown-dragonfly5.9/bin/
-B/opt/gcc11f/x86_64-unknown-dragonfly5.9/lib/ -isystem
/opt/gcc11f/x86_64-unknown-dragonfly5.9/include -isystem
/opt/gcc11f/x86_64-unknown-dragonfly5.9/sys-include -fchecking=1
-B/build/trunk/x86_64-unknown-dragonfly5.9/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-DLOCALEDIR="." -nostdinc++
-I/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/x86_64-unknown-dragonfly5.9
-I/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include
-I/data/gg/libstdc++-v3/libsupc++ -I/data/gg/libstdc++-v3/include/backward
-I/data/gg/libstdc++-v3/testsuite/util
/data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++.cc -std=gnu++2a
-Wall -Wsystem-headers -fdiagnostics-plain-output -S -o stdc++.s
In file included from
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/semaphore:35,
 from
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/stop_token:37,
 from
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/condition_variable:47,
 from
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/x86_64-unknown-dragonfly5.9/bits/stdc++.h:103,
 from
/data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++.cc:25:
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/bits/semaphore_base.h:279:
warning: extra tokens at end of #ifdef directive
FAIL: 17_intro/headers/c++2020/stdc++.cc (test for excess errors)
Excess errors:
/build/trunk/x86_64-unknown-dragonfly5.9/libstdc++-v3/include/bits/semaphore_base.h:279:
warning: extra tokens at end of #ifdef directive

extra_tool_flags are:
 -std=gnu++2a -Wall -Wsystem-headers

The libstdc++-v3/include/bits/semaphore_base.h:279 looks to be a typo:
// Note: the _GLIBCXX_REQUIRE_POSIX_SEMAPHORE macro can be used to force the
// use of Posix semaphores (sem_t). Doing so however, alters the ABI.
#ifdef _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE
  // Use futex if available and didn't force use of POSIX

[Bug c++/98343] [11 Regression] ICE in in relocate_ptrs, at ggc-common.c:363 [PCH and C++20 std::source_location?]

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-17
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

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

Untested fix.

[Bug c++/98315] [11 regression] libcody breaks Solaris bootstrap

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Nathan Sidwell  ---
> sorry for not getting this right sooner:
>
> b7b6879f0b5: c++: Another solaris header use [PR 98315]

No worries: I've now completed Solaris 11.3 and 11.4 bootstraps, so
everything is fine again.

Thanks.

[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3

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

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

Rainer Orth  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-Decembe
   ||r/562185.html

--- Comment #5 from Rainer Orth  ---
Final patch posted.

[Bug rtl-optimization/98289] [8/9/10/11 Regression] [x86] Suboptimal optimization of stack usage when function call does not occur

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:62cb9680e592057a49de66eac34da679338932f9

commit r11-6222-g62cb9680e592057a49de66eac34da679338932f9
Author: Jakub Jelinek 
Date:   Thu Dec 17 13:28:48 2020 +0100

shrink-wrap: Don't put on incoming EDGE_CROSSING [PR98289]

As mentioned in the PR, shrink-wrapping disqualifies for prologue
placement basic blocks that have EDGE_CROSSING incoming edge.
I don't see why that is necessary, those edges seem to be redirected
just fine, both on x86_64 and powerpc64.  In the former case, they
are usually conditional jumps that patch_jump_insn can handle just fine,
after all, they were previously crossing and will be crossing after
the redirection too, just to a different label.  And in the powerpc64
case, it is a simple_jump instead that again seems to be handled by
patch_jump_insn just fine.
Sure, redirecting an edge that was previously not crossing to be crossing
or
vice versa can fail, but that is not what shrink-wrapping needs.
Also tested in GCC 8 with this patch and don't see ICEs there either
(though, of course, I'm not suggesting we should backport this to release
branches).
The old ICEs could have been fixed by PR87475 fix or some other one
years ago.

2020-12-17  Jakub Jelinek  

PR rtl-optimization/98289
* shrink-wrap.c (can_get_prologue): Don't punt on EDGE_CROSSING
incoming edges.

* gcc.target/i386/pr98289.c: New test.
* gcc.dg/torture/pr98289.c: New test.

[Bug c++/98345] New: Different behaviour of gcc Versions (<=8, >=9)

[budek at wtal dot de via Gcc-bugs]

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

Bug ID: 98345
   Summary: Different behaviour of gcc Versions (<=8, >=9)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: budek at wtal dot de
  Target Milestone: ---

The following (strange) construction seems to behave different
in Versions <=8 and >=9:
for( ... ; ... ; ... )
for(... ; ... ; break)...
Versions <=8 cancel the inner loop, Versions >=9 the outer loop.

The real problem is, that a similar construction is used in QT4's
implementation of foreach() (Qt/qglobal.h and QtCore/qglobal.h).

Compiling old QT projects with a version >=9 will fail, if
foreach is used.

[Bug c++/98345] Different behaviour of gcc Versions (<=8, >=9)

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-17
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Martin Liška  ---
Can you please attach a self-contained test-case one can compile?

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

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

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

Nathan Sidwell  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-17

[Bug c++/98345] Different behaviour of gcc Versions (<=8, >=9)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Most likely PR44715.  Just use new Qt or fix the old one.

[Bug c++/98345] Different behaviour of gcc Versions (<=8, >=9)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
And more details about it are in PR90617.

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

[Bug c++/90617] GCC 9 miscompiles Qt4 "foreach" macro

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||budek at wtal dot de

--- Comment #6 from Jakub Jelinek  ---
*** Bug 98345 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/94779] Bad optimization of simple switch

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

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

--- Comment #14 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #12)
> So, for start I think we should do:
> 1) query->range_of_expr (m_index_range, m_index_expr, swtch)
>where query is address of gimple_ranger passed down from the caller
>to figure out range of the index expression; case labels without
> CASE_HIGH for
>which m_index_range.contains_p (CASE_LOW (case)) is false can be ignored
>for the optimization (well, handled the way it is better for the
> optimization)
>For CASE_HIGH labels, similarly query if the range overlaps the index
> range.
>Note, I don't remember exactly in which way the types of the index
> expression
>and of the case labels can differ, I believe all case labels have to have
> the
>same type, so probably for the computation of the range if it has
> different
>type from the case label ones, it needs to call something that would
> emulate
>the effect of conversion to that type (or vice versa?)
>CCing Andrew for the range stuff

Ok, I've just taken look at what EVRP pass does before SWITCHCONV pass is
called.
I see that EVRP can properly prune dead cases of a switch, but it's not
perfect:

int f1(unsigned x)
{
if (x == 2 || x == 3 || x >= 5)
  __builtin_unreachable ();
switch (x)
{
  case 0: return 1;
  case 1: return 2;
  case 2: return 3;
  case 3 ... 8: return 4;
}
}

after VRP we end up with:
  switch (x_6(D))  [INV], case 1:  [INV], case 2:  [INV],
case 3 ... 4:  [INV]>

but case '3' is not pruned here. Similarly, I can imagine the following
reduction:

if (x >= 4 && x <= 9)
  __builtin_unreachable ();
switch (x)
{
  case 0: return 1;
  case 1: return 2;
  case 2: return 3;
  case 3 ... 10: return 4;
}

is not simplified to:
  switch (x_3(D))  [INV], case 0:  [INV], case 1:  [INV],
case 2:  [INV], case 3 ... 10:  [INV]>

but I would expect:
  switch (x_3(D))  [INV], case 0:  [INV], case 1:  [INV],
case 2:  [INV], case 3: , case 10:  [INV]>

Btw, EVRP knows the information:
4->8  x_3(D) :  unsigned int [11, +INF]
4->9  x_3(D) :  unsigned int [0, 0]
4->5  x_3(D) :  unsigned int [1, 1]
4->6  x_3(D) :  unsigned int [2, 2]
4->7  x_3(D) :  unsigned int [3, 3][10, 10]

The question is whether we want to make the transformation by EVRP?

> 2) similarly, cases that refer to blocks which have EDGE_COUNT (bb->succs)
> == 0
>&& gimple_seq_unreachable_p (bb_seq (bb)) should be treated again like
> cases
>one shouldn't need to care about

I've got a patch candidate for this.

> 3) to handle the #c0 testcase in C (C++ already adds __builtin_unreachable),
>handle also the case where case refers to block which has EDGE_COUNT
> (bb->succs) and ends in GIMPLE_RETURN without expression in a function that
>returns integral or pointer value (for simplicity) and has no statements
>other than debug stmts or clobber stmts before it.  Note, this case can't
> be
>treated completely like a UB case, there is no UB in C unless the caller
>checks the return value, but it could be handled conditionally, as long as
>the code we emit for that doesn't invoke UB in the function, we really
> don't 
>care about the value we return to the caller.  So e.g. if we are
> considering
>a linear function and other case labels return that linear value and some
>return unspecified value, just use the linear function to cover those too.

Likewise here, it's smart to return a random value for C when there's a missing
return value.

> 4) to be able to optimize the int f1(unsigned x) { if (x >= 3)
> __builtin_unreachable();
>switch (x) { case 0: return 1; case 1: return 2; case 2: return 3; } }
>testcase, we should for consideration virtually undo the evrp optimization
>which removed the case 0: and replaced it with default: - here the handled
>cases (that should include the really handled ones and ones that and the
>UB ones (if the case is outside of range or __builtin_unreachable) cover
>everything but one case, assume the default label is that for that single
>case rather than handling anything else; similarly, if the whole range
>is covered, ignore the default label

This seems to me like a strange EVRP transformation :/

[Bug c++/98345] Different behaviour of gcc Versions (<=8, >=9)

[budek at wtal dot de via Gcc-bugs]

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

--- Comment #4 from Peter Budek  ---
The requested test-case:

#include 
#include 

int main(int argc, char *argv[])
{
   QList l ;

   l.append(1) ;
   l.append(2) ;
   l.append(3) ;
   foreach(int i, l) std::cout << i << std::endl ;  

   return(0) ;
}

The result is '1' with gcc 10.2.0 (not 1 2 3).
I found this compiling qucs (http://qucs.sourceforge.net/index.html).

patching qt helps:
+++ qt-everywhere-opensource-src-4.8.7/src/corelib/global/qglobal.h
2020-12-17 10:46:30.0 +0100
@@ -2496,9 +2496,9 @@
 #define Q_FOREACH(variable, container)\
 for (QForeachContainer<__typeof__(container)> _container_(container); \
  !_container_.brk && _container_.i != _container_.e;  \
  __extension__  ({ ++_container_.brk; ++_container_.i; }))
  \
-for (variable = *_container_.i;; __extension__ ({--_container_.brk;
break;}))
+for (variable = *_container_.i;!_container_.brk; __extension__
({--_container_.brk;}))

 #else

 struct QForeachContainerBase {};

[Bug tree-optimization/94779] Bad optimization of simple switch

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

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

--- Comment #15 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #14)
> Ok, I've just taken look at what EVRP pass does before SWITCHCONV pass is
> called.
> I see that EVRP can properly prune dead cases of a switch, but it's not
> perfect:
> 
> int f1(unsigned x)
> {
> if (x == 2 || x == 3 || x >= 5)
>   __builtin_unreachable ();
> switch (x)
> {
>   case 0: return 1;
>   case 1: return 2;
>   case 2: return 3;
>   case 3 ... 8: return 4;
> }
> }

The old VRP/EVRP only tracks simple ranges and anti-ranges, so can't deal with
what you have above, the new ranger code can deal with multiple subranges, but
the question is if all the interfaces deal with those.

> This seems to me like a strange EVRP transformation :/

Why?  And, the user could have written it that way too.

[Bug c++/98343] [11 Regression] ICE in in relocate_ptrs, at ggc-common.c:363 [PCH and C++20 std::source_location?]

[pexu--- via Gcc-bugs]

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

--- Comment #3 from Pekka S  ---
Hi.

Thanks.

Applied the patch to the latest trunk, built on x86_64-linux-gnu and tested
that it indeed fixes both of these test cases.  Did not try on
x86_64-w64-mingw32 yet.  I presume it will work just fine.

[Bug c++/98346] New: ICE with a combination of concepts, decltype and type aliases

[drozdov_xf2g3gb3 at mail dot ru via Gcc-bugs]

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

Bug ID: 98346
   Summary: ICE with a combination of concepts, decltype and type
aliases
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drozdov_xf2g3gb3 at mail dot ru
  Target Milestone: ---

The following code(https://godbolt.org/z/asPv6s):

template 
concept always_satisfied = true;

using arg_alias = int;

template 
using result_of = decltype(F{}(arg_alias{}));

template 
always_satisfied> auto foo(F) {}

void bar() { foo([](auto){}); }

When compiled with -v -std=c++20 produces:

Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
COLLECT_LTO_WRAPPER=/opt/compiler-explorer/gcc-trunk-20201217/bin/../libexec/gcc/x86_64-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20201217/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,d
--enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201216 (experimental) (Compiler-Explorer-Build) 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' './output.s' '-L.'
'-v' '-std=c++20' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir'
'./output.s-'

/opt/compiler-explorer/gcc-trunk-20201217/bin/../libexec/gcc/x86_64-linux-gnu/11.0.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-trunk-20201217/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/
-D_GNU_SOURCE  -quiet -dumpdir ./output.s- -dumpbase example.cpp
-dumpbase-ext .cpp -mtune=generic -march=x86-64 -g -std=c++20 -version
-fdiagnostics-color=always -o /tmp/ccwWsVpH.s
GNU C++20 (Compiler-Explorer-Build) version 11.0.0 20201216 (experimental)
(x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-trunk-20201217/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../x86_64-linux-gnu/include"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20201217/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20201217/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20201217/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20201217/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/include"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20201217/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/include-fixed"
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-trunk-20201217/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/opt/compiler-explorer/gcc-trunk-20201217/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0

/opt/compiler-explorer/gcc-trunk-20201217/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0/x86_64-linux-gnu

/opt/compiler-explorer/gcc-trunk-20201217/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward

/opt/compiler-explorer/gcc-trunk-20201217/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/include

/opt/compiler-explorer/gcc-trunk-20201217/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/include-fixed
 /usr/local/include
 /opt/compiler-explorer/gcc-trunk-20201217/bin/../lib/gcc/../../include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++20 (Compiler-Explorer-Build) version 11.0.0 20201216 (experimental)
(x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=

[Bug tree-optimization/94779] Bad optimization of simple switch

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

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

--- Comment #16 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #15)
> (In reply to Martin Liška from comment #14)
> > Ok, I've just taken look at what EVRP pass does before SWITCHCONV pass is
> > called.
> > I see that EVRP can properly prune dead cases of a switch, but it's not
> > perfect:
> > 
> > int f1(unsigned x)
> > {
> > if (x == 2 || x == 3 || x >= 5)
> >   __builtin_unreachable ();
> > switch (x)
> > {
> >   case 0: return 1;
> >   case 1: return 2;
> >   case 2: return 3;
> >   case 3 ... 8: return 4;
> > }
> > }
> 
> The old VRP/EVRP only tracks simple ranges and anti-ranges, so can't deal
> with
> what you have above, the new ranger code can deal with multiple subranges,
> but the question is if all the interfaces deal with those.

EVRP knows the proper range:
2->4  (F) x_6(D) :  unsigned int [0, 1][4, 4]

> 
> > This seems to me like a strange EVRP transformation :/
> 
> Why?  And, the user could have written it that way too.

Looking into it.

[Bug c++/98345] Different behaviour of gcc Versions (<=8, >=9)

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

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

--- Comment #5 from Jakub Jelinek  ---
Old Qt was relying on a GCC bug (as can be seen from the fact that
void
foo ()
{
  for (;; ({ break; }))
;
}
has been rejected since forever).  It wasn't rejected in the for nested in
another for, because it was expected to bind in that case to the outer loop,
but due to a bug was bound to the inner loop.
This has been fixed in GCC9 and newer.

[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:096164229a4c2d1efab9f259f50be1bdcdfc8abd

commit r11-6225-g096164229a4c2d1efab9f259f50be1bdcdfc8abd
Author: Nathan Sidwell 
Date:   Thu Dec 17 05:57:13 2020 -0800

bootstrap: Fix some windows issues [PR 98300]

When breaking out the sample server from the gcc/cp directory, it lost
its check for mmap, and the sample resolver just assumed it was there.
Fixed thusly.  The non-mapping paths in module.cc weren't (recently)
excercised, and led to a signedness warning.  Finally I'd missed
c++tools's config.h.in in the gcc_update script.  There I took the
opportunity of adding a 'tools' segment of the dependency lists.

PR bootstrap/98300
contrib/
* gcc_update: Add c++tools/config.h.in.
c++tools/
* configure.ac: Check for sys/mman.h.
* resolver.cc: Don't assume mmap, O_CLOEXEC are available.  Use
xmalloc.
* config.h.in: Regenerated.
* configure: Regenerated.
gcc/cp/
* module.cc: Fix ::read, ::write result signedness comparisons.

[Bug c++/98305] spurious -Wmismatched-new-delete on template instance

[sbergman at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Stephan Bergmann  ---
(In reply to Martin Sebor from comment #2)
> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562141.html

Thanks; can confirm that fixes my LibreOffice build.

[Bug libstdc++/98344] Testsuite 17_intro/headers/c++2020/stdc++.cc failure

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

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

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

https://gcc.gnu.org/g:8dc63f13f03facc49b777195c9068432477b5dcd

commit r11-6228-g8dc63f13f03facc49b777195c9068432477b5dcd
Author: Jonathan Wakely 
Date:   Thu Dec 17 12:09:20 2020 +

libstdc++: Fix preprocessor condition [PR 98344]

libstdc++-v3/ChangeLog:

PR libstdc++/98344
* include/bits/semaphore_base.h: Fix preprocessor condition.

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

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

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

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

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

commit r11-6229-g9f9dbc8e09cf48406aa24b6c78735f1a7912cc4e
Author: Jonathan Wakely 
Date:   Thu Dec 17 13:16:02 2020 +

libstdc++: Fix -Wunused warning

As noted in PR 66146 comment 35, there is a new warning in the new
std::call_once implementation.

libstdc++-v3/ChangeLog:

* src/c++11/mutex.cc (std::once_flag::_M_finish): Add
maybe_unused attribute to variable used in assertion.

[Bug tree-optimization/94779] Bad optimization of simple switch

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

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

--- Comment #17 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #16)
> > The old VRP/EVRP only tracks simple ranges and anti-ranges, so can't deal
> > with
> > what you have above, the new ranger code can deal with multiple subranges,
> > but the question is if all the interfaces deal with those.
> 
> EVRP knows the proper range:
> 2->4  (F) x_6(D) :unsigned int [0, 1][4, 4]

EVRP ATM invokes both the old code and ranger and only ranger knows the above.
There is a param to adjust the behavior.
Anyway, if something isn't able to work with the detailed ranges (up to 255
subranges), type conversions will ensure that one gets a single summary range
([0, 4] in this case likely) and possibly the switch opts still do that.

Anyway, whether EVRP or VRP or whatever other pass performs some switch
optimizations based on ranges or not, it is valuable to query the ranges in
switchconv too.  Because, what e.g. EVRP can only do with the switch is remove
unreachable cases, but for switchconv it should be valueable to know for each
possible value in the range of the switch index whether such value is possible
and there is a handler for it and that handler is not __builtin_unreachable
();, or if the case is possible but not explicitly handled (thus default:
unless default is __builtin_unreachable ()), or the never happen cases (or will
invoke UB immediately, that is the same thing).
Because for some things it is better to treat the last category as non-existing
and for others to treat it as existing but can do anything.
E.g. if you compute the full covered range, the invalid cases at the start of
the range or at the end of the range don't need to be counted, one can shorten
the range, but e.g. when deciding if it is contiguous or if one can use linear
expressions on the index, one can treat the invalid cases as present and
satisfying whatever we need.

[Bug libstdc++/98344] Testsuite 17_intro/headers/c++2020/stdc++.cc failure

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
It should be fixed now, thanks for the report.

[Bug rtl-optimization/98347] New: [11 Regression] gcc.dg/long_branch.c ICEs on i686-linux

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

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

Bug ID: 98347
   Summary: [11 Regression] gcc.dg/long_branch.c ICEs on
i686-linux
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

during RTL pass: fwprop1
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/long_branch.c: In function
'test_and_branch':
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/long_branch.c:185:1: internal compiler
error: Segmentation fault
0x8b940ba crash_signal
../../gcc/toplev.c:327
0x97490e1 rtl_ssa::full_register(unsigned int)
../../gcc/rtl-ssa/access-utils.h:26
0x97490e1
rtl_ssa::function_info::add_entry_block_defs(rtl_ssa::function_info::build_info&)
../../gcc/rtl-ssa/blocks.cc:508
0x974bbfe rtl_ssa::function_info::process_all_blocks()
../../gcc/rtl-ssa/blocks.cc:1058
0x96cc708 rtl_ssa::function_info::function_info(function*)
../../gcc/rtl-ssa/functions.cc:49
0x95a834a fwprop_init
../../gcc/fwprop.c:881
0x95a834a fwprop
../../gcc/fwprop.c:951
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gcc.dg/long_branch.c (internal compiler error)
FAIL: gcc.dg/long_branch.c (test for excess errors)

It didn't fail 2 days ago, I suspect the RTL SSA changes.

[Bug tree-optimization/97750] [11 Regression] ICE in during GIMPLE pass: wrestrict since r11-4135-ge864d395b4e862ce

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

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

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

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

commit r11-6232-gc25b504636fec7bf8f181a84af83a52757ba7e89
Author: Andrew MacLeod 
Date:   Thu Dec 17 09:24:11 2020 -0500

Fix trap in pointer conversion in op1_range.

Processing op1_range for conversion between a non-pointer and pointer
shouldnt do any fancy math.

gcc/
PR tree-optimization/97750
* range-op.cc (operator_cast::op1_range): Handle pointers better.
gcc/testsuite/
* gcc.dg/pr97750.c: New.

[Bug tree-optimization/97750] [11 Regression] ICE in during GIMPLE pass: wrestrict since r11-4135-ge864d395b4e862ce

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

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

[Bug c++/98348] New: GCC 10.2 AVX512 Mask regression from GCC 9

[danielhanchen at gmail dot com via Gcc-bugs]

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

Bug ID: 98348
   Summary: GCC 10.2 AVX512 Mask regression from GCC 9
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danielhanchen at gmail dot com
  Target Milestone: ---

In GCC 9, vector comparisons on 128 and 256bit vectors on a AVX512 machine used
vpcmpeqd without any masks.

In GCC 10, for 128bit and 256bit vectors, AVX512 mask instructions are used.
https://gcc.godbolt.org/z/1sPzM5

GCC 10 should follow GCC 9 for vector comparisons when a mask is not needed.

The reason why is https://uops.info/table.html shows that using mask registers
makes 128/256/512 operations have a throughput of 1 and a latency of 3.

However, using a vector comparison directly has a throughput of 2 and a latency
of 1.

[Bug rtl-optimization/98347] [11 Regression] gcc.dg/long_branch.c ICEs on i686-linux

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

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

--- Comment #1 from Jakub Jelinek  ---
Strangely, it doesn't reproduce under gdb, nor when cc1 is 64-bit binary with
-m32 -mno-sse -march=pentiumpro -mtune=pentiumpro on top of the normal test
flags.

[Bug c++/98348] GCC 10.2 AVX512 Mask regression from GCC 9

[danielhanchen at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Daniel Han-Chen  ---
I also just noticed that in GCC 10, an extra movdqa is done, which is also not
necessary.

[Bug rtl-optimization/98347] [11 Regression] gcc.dg/long_branch.c ICEs on i686-linux

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-17
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug ipa/98349] New: [11 regression] cc.target/powerpc/sse-movhps-1.c and sse-movlps.c fail after r11-3434

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

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

Bug ID: 98349
   Summary: [11 regression] cc.target/powerpc/sse-movhps-1.c and
sse-movlps.c fail after r11-3434
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

g:c33f474239308d81bf96cfdb2520d25488ad8724, r11-3434

make  -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/sse-movhps-1.c"
FAIL: gcc.target/powerpc/sse-movhps-1.c execution test
# of expected passes1
# of unexpected failures1

also

make  -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/sse-movlps-1.c"
FAIL: gcc.target/powerpc/sse-movlps-1.c execution test
# of expected passes1
# of unexpected failures1

spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/sse-movlps-1.c
-fdiagnostics-plain-output -O3 -mpower8-vector -Wno-psabi -lm -o
./sse-movlps-1.exe
PASS: gcc.target/powerpc/sse-movlps-1.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/git/build/gcc-test/gcc::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.4.0/lib64
Execution timeout is: 300
spawn [open ...]
FAIL: gcc.target/powerpc/sse-movlps-1.c execution test

Program received signal SIGABRT, Aborted.
0x3fffb7cd260c in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
55return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) where
#0  0x3fffb7cd260c in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1  0x3fffb7cd47f8 in __GI_abort () at abort.c:90
#2  0x1768 in sse_test () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/sse-movlps-1.c:46
#3  do_test () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/sse-check.h:14
#4  0x1510 in main () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/sse-check.h:20

commit c33f474239308d81bf96cfdb2520d25488ad8724
Author: Jan Hubicka 
Date:   Thu Sep 24 15:09:17 2020 +0200

[Bug c++/98333] [10/11 Regression] ICE in check_qualified_type, at tree.c:6593 since r10-1280-g78f7607db4c53f8c

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

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |10.3
 Status|NEW |ASSIGNED

[Bug libstdc++/96592] [10 Regression] Tuple element w/ member reference to incomplete template type rejected

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c/98269] gcc 6.5.0 __builtin_add_overflow() with small uint32_t values incorrectly detects overflow

[stli at linux dot ibm.com via Gcc-bugs]

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

--- Comment #5 from stli at linux dot ibm.com  ---
Just as information,
I've just committed this glibc patch:
"s390x: Require GCC 7.1 or later to build glibc."
https://sourceware.org/git/?p=glibc.git;a=commit;h=844b4d8b4b937fe6943d2c0c80ce7d871cdb1eb5

[Bug tree-optimization/98350] New: Reassociation breaks FMA chains

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

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

Bug ID: 98350
   Summary: Reassociation breaks FMA chains
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

Consider the testcase:

#define N 1024
double a[N];
double b[N];
double c[N];
double d[N];
double e[N];
double f[N];
double g[N];
double h[N];
double j[N];
double k[N];
double l[N];
double m[N];
double o[N];
double p[N];


void
foo (void)
{
  for (int i = 0; i < N; i++)
  {
a[i] += b[i]* c[i] + d[i] * e[i] + f[i] * g[i] + h[i] * j[i] + k[i] * l[i]
+ m[i]* o[i] + p[i];
  }
}

For -Ofast --param=tree-reassoc-width=1 GCC generates the loop:
.L2:
ldr q1, [x1, x0]
ldr q0, [x12, x0]
ldr q3, [x14, x0]
faddv0.2d, v0.2d, v1.2d
ldr q1, [x13, x0]
ldr q2, [x11, x0]
fmlav0.2d, v3.2d, v1.2d
ldr q1, [x10, x0]
ldr q3, [x9, x0]
fmlav0.2d, v2.2d, v1.2d
ldr q1, [x8, x0]
ldr q2, [x7, x0]
fmlav0.2d, v3.2d, v1.2d
ldr q1, [x6, x0]
ldr q3, [x5, x0]
fmlav0.2d, v2.2d, v1.2d
ldr q1, [x4, x0]
ldr q2, [x3, x0]
fmlav0.2d, v3.2d, v1.2d
ldr q1, [x2, x0]
fmlav0.2d, v2.2d, v1.2d
str q0, [x1, x0]
add x0, x0, 16
cmp x0, 8192
bne .L2

with --param=tree-reassoc-width=4 it generates:
.L2:
ldr q5, [x11, x0]
ldr q4, [x7, x0]
ldr q0, [x3, x0]
ldr q3, [x12, x0]
ldr q1, [x8, x0]
ldr q2, [x4, x0]
fmulv3.2d, v3.2d, v5.2d
fmulv1.2d, v1.2d, v4.2d
fmulv2.2d, v2.2d, v0.2d
ldr q16, [x1, x0]
ldr q18, [x14, x0]
ldr q17, [x13, x0]
ldr q0, [x2, x0]
ldr q7, [x10, x0]
ldr q6, [x9, x0]
ldr q5, [x6, x0]
ldr q4, [x5, x0]
fmlav3.2d, v18.2d, v17.2d
faddv0.2d, v0.2d, v16.2d
fmlav1.2d, v7.2d, v6.2d
fmlav2.2d, v5.2d, v4.2d
faddv0.2d, v0.2d, v3.2d
faddv1.2d, v1.2d, v2.2d
faddv0.2d, v0.2d, v1.2d
str q0, [x1, x0]
add x0, x0, 16
cmp x0, 8192
bne .L2

The reassociation is evident. The problem here is that the fmla chains are
something we'd want to preserve.
Is there a way we can get the reassoc pass to handle FMAs more intelligently?

[Bug ipa/98351] New: [11 regression] gcc.target/powerpc/sse-andnps-1.c and sse2-andnpd-1.c fail after r11-3308

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

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

Bug ID: 98351
   Summary: [11 regression] gcc.target/powerpc/sse-andnps-1.c and
sse2-andnpd-1.c fail after r11-3308
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

g:d119f34c952f8718fdbabc63e2f369a16e92fa07, r11-3308

make  -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/sse-andnps-1.c"
FAIL: gcc.target/powerpc/sse-andnps-1.c execution test
# of expected passes1
# of unexpected failures1

and

make  -k check-gcc
RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/sse2-andnpd-1.c"
FAIL: gcc.target/powerpc/sse2-andnpd-1.c execution test
# of expected passes1
# of unexpected failures1


(gdb) run
Starting program: /home/seurer/gcc/git/build/gcc-test/sse2-andnpd-1.exe 

Program received signal SIGABRT, Aborted.
0x77c20468 in raise () from /lib/powerpc64le-linux-gnu/libc.so.6
(gdb) where
#0  0x77c20468 in raise () from /lib/powerpc64le-linux-gnu/libc.so.6
#1  0x77bf7cd0 in abort () from /lib/powerpc64le-linux-gnu/libc.so.6
#2  0x1778 in sse2_test () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/sse2-andnpd-1.c:40
#3  do_test () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/sse2-check.h:20
#4  0x1518 in main () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/sse2-check.h:26


NOTE: also see pr38949 for a similar failure (albeit from a different revision)

[Bug rtl-optimization/98335] [9/10/11 Regression] Poor code generation for partial struct initialization

[mcolavita at fb dot com via Gcc-bugs]

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

--- Comment #1 from Michael Colavita  ---
A similar problem appears to occur for the following example:

  struct Data {
long a;
union {
  long u;
  struct {
char b;
char pad[3];
  };
};
  };

  Data val(long d, long e) {
return { d, e };
  }

Yielding:

movq%rdi, %xmm0
movq%rsi, %xmm1
punpcklqdq  %xmm1, %xmm0
movaps  %xmm0, -56(%rsp)
movq-56(%rsp), %rax
movq-48(%rsp), %rdx
ret

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

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

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

--- Comment #4 from Nathan Sidwell  ---
Created attachment 49789
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49789&action=edit
try this

I tried building with clang, but it barfed about invalid utf8 in libiberty.

[Bug c++/98348] GCC 10.2 AVX512 Mask regression from GCC 9

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com,
   ||hjl.tools at gmail dot com

--- Comment #2 from H.J. Lu  ---
Hongtao, can you take a look?

[Bug target/98321] [nvptx] 'atom.add.f32' for atomic add of 32-bit 'float'

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

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

--- Comment #1 from Tom de Vries  ---
Ok, let's first make a runnable test-case:
...
$ cat src/libgomp/testsuite/libgomp.oacc-c/test.c
#include 

#define TYPE float

TYPE a = 1;
TYPE b = 2;

int
main (void)
{

  printf ("A: %f\n", a);

#pragma acc parallel num_gangs (1) num_workers (1) copy (a, b)
#pragma acc atomic update
  a += b;

  printf ("A: %f\n", a);

  return !(a == 3);
}
...

Indeed we see the cas, but that has nothing to do with support in the nvptx
port:
...
atom.cas.b32%r29, [%r25], %r22, %r28;   
...

This appears already at ompexp on the host, where we expand:
...
  #pragma omp atomic_load relaxed
D.2555 = *D.2568

   :
  D.2557 = D.2555 + b.1;
  #pragma omp atomic_store relaxed (D.2557)
...
into:
...
  D.2583 = __atomic_load_4 (D.2582, 0);
  D.2584 = D.2583;

   :
  D.2585 = VIEW_CONVERT_EXPR(D.2584);
  D.2586 = D.2585 + b.1;
  D.2587 = VIEW_CONVERT_EXPR(D.2586);
  D.2588 = __sync_val_compare_and_swap_4 (D.2582, D.2584, D.2587);
...

This is part of a generic problem with offloading, where choices are made in
the host compiler which are suboptimal or even unsupported in the offload
compiler.

Ideally this should be addressed in the host compiler.

It may be possible to address this in the nvptx port by trying to detect the
unoptimal pattern and converting it to the optimal atom.add.f32.  But
ultimately that's a workaround, and it's better to fix this at the source.

[Bug tree-optimization/94779] Bad optimization of simple switch

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #18 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #17)
> (In reply to Martin Liška from comment #16)

> > 
> > EVRP knows the proper range:
> > 2->4  (F) x_6(D) :  unsigned int [0, 1][4, 4]
> 
> EVRP ATM invokes both the old code and ranger and only ranger knows the
> above.
> There is a param to adjust the behavior.
> Anyway, if something isn't able to work with the detailed ranges (up to 255
> subranges), type conversions will ensure that one gets a single summary
> range ([0, 4] in this case likely) and possibly the switch opts still do
> that.
>

Indeed.  Ranger knows, but at this point most of the client consumers such as
folding and simplification still only deal with value_range, which means they
will revert to using the best approximation using only a pair, which would be
[0,4] in this case as you observe.

One of the work items for the next release is to multi-range enable all these
consumers that can make use of the information.

[Bug c++/98352] New: [9/10/11 Regression] ICE in implicitly_declare_fn, at cp/method.c:2914

[gscfq--- via Gcc-bugs]

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

Bug ID: 98352
   Summary: [9/10/11 Regression] ICE in implicitly_declare_fn, at
cp/method.c:2914
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190217 and 20190224, and affects roughly
a dozen testsuite files when running without -std=c++11 :


$ cat z1_nsdmi-defer6.C
struct A
{
  int i = (A(), 42);
};
A a;


$ g++-11-20201213 -c z1_nsdmi-defer6.C -ansi
z1_nsdmi-defer6.C:3:19: warning: non-static data member initializers only
available with '-std=c++11' or '-std=gnu++11'
3 |   int i = (A(), 42);
  |   ^
z1_nsdmi-defer6.C:3:14: internal compiler error: in implicitly_declare_fn, at
cp/method.c:2914
3 |   int i = (A(), 42);
  |  ^
0x7f19a0 implicitly_declare_fn(special_function_kind, tree_node*, bool,
tree_node*, tree_node*)
../../gcc/cp/method.c:2914
0x7f24a5 lazily_declare_fn(special_function_kind, tree_node*)
../../gcc/cp/method.c:3209
0x7ff9fc maybe_lazily_declare
../../gcc/cp/name-lookup.c:1922
0x7ff9fc get_class_binding(tree_node*, tree_node*, bool)
../../gcc/cp/name-lookup.c:1952
0x8f406b lookup_field_r
../../gcc/cp/search.c:978
0x8f2a4e dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
../../gcc/cp/search.c:1408
0x8f2bfc lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
../../gcc/cp/search.c:1121
0x8f2fa0 lookup_fnfields(tree_node*, tree_node*, int, int)
../../gcc/cp/search.c:1327
0x6b1950 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/cp/call.c:9958
0x7bc8f6 build_value_init(tree_node*, int)
../../gcc/cp/init.c:355
0x9745bd build_functional_cast_1
../../gcc/cp/typeck2.c:2264
0x9745bd build_functional_cast(unsigned int, tree_node*, tree_node*, int)
../../gcc/cp/typeck2.c:2286
0x82f287 cp_parser_functional_cast
../../gcc/cp/parser.c:30524
0x843b92 cp_parser_postfix_expression
../../gcc/cp/parser.c:7417
0x858cf5 cp_parser_unary_expression
../../gcc/cp/parser.c:8808
0x8286ef cp_parser_cast_expression
../../gcc/cp/parser.c:9712
0x828fb1 cp_parser_binary_expression
../../gcc/cp/parser.c:9814
0x8299e0 cp_parser_assignment_expression
../../gcc/cp/parser.c:10118
0x82b409 cp_parser_expression
../../gcc/cp/parser.c:10288
0x840b4d cp_parser_primary_expression
../../gcc/cp/parser.c:5556

[Bug c++/98353] New: [9/10/11 Regression] ICE in propagate_necessity, at tree-ssa-dce.c:1053

[gscfq--- via Gcc-bugs]

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

Bug ID: 98353
   Summary: [9/10/11 Regression] ICE in propagate_necessity, at
tree-ssa-dce.c:1053
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to r6 :


$ cat z1.cc
template  class A {};
template  struct B {
  static const int n = 1;
  template  A ::n> f();
  _Complex double c[2], d = 1.0;
};
void g ()
{
  B().f();
}


$ g++-5 -c z1.cc -O2 -std=c++11
$
$ g++-11-20201213 -c z1.cc -O2
during GIMPLE pass: cddce
z1.cc: In function 'void g()':
z1.cc:10:1: internal compiler error: in propagate_necessity, at
tree-ssa-dce.c:1053
   10 | }
  | ^
0xd7fa5b propagate_necessity
../../gcc/tree-ssa-dce.c:1053
0xd80a91 perform_tree_ssa_dce
../../gcc/tree-ssa-dce.c:1747

---

z1.cc: In function 'void g()':
z1.cc:7:6: error: non-register as LHS of binary operation
7 | void g ()
  |  ^
D.2410.c[D.2438] = COMPLEX_EXPR <(double) 0, (double) 0>;
z1.cc:7:6: internal compiler error: 'verify_gimple' failed
0xfd241d verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:5119
0xc97791 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:15329
0xc97a47 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:15400
0xac81f7 cgraph_node::analyze()
../../gcc/cgraphunit.c:670
0xacb326 analyze_functions
../../gcc/cgraphunit.c:1235
0xacc4dd symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2513

[Bug c++/98354] New: OOM: cc1plus: out of memory with operator auto

[gscfq--- via Gcc-bugs]

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

Bug ID: 98354
   Summary: OOM: cc1plus: out of memory with operator auto
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Seems to be very old :


$ cat z1.cc
struct S
{
  operator auto () { return [] };
};


$ g++-11-20201213 -c z1.cc -std=c++17
z1.cc: In lambda function:
z1.cc:3:32: error: expected '{' before '}' token
3 |   operator auto () { return [] };
  |^
cc1plus: out of memory allocating 96299408 bytes after a total of 737280 bytes

[Bug c++/98355] New: [9/10/11 Regression] ICE in has_attribute, at c-family/c-attribs.c:5628

[gscfq--- via Gcc-bugs]

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

Bug ID: 98355
   Summary: [9/10/11 Regression] ICE in has_attribute, at
c-family/c-attribs.c:5628
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started to ICE with version r9, roundabout 20181125 :


$ cat z1.cc
struct S { int a; };
template  struct T
{
  static_assert (__builtin_has_attribute (((S*)0) -> a, packed));
};


$ g++-11-20201213 -c z1.cc
z1.cc:4:57: internal compiler error: Segmentation fault
4 |   static_assert (__builtin_has_attribute (((S*)0) -> a, packed));
  | ^~
0xc8f5ff crash_signal
../../gcc/toplev.c:327
0x841f52 has_attribute(unsigned int, tree_node*, tree_node*, tree_node*
(*)(tree_node*))
../../gcc/c-family/c-attribs.c:5628
0x7525ed cp_parser_has_attribute_expression
../../gcc/cp/parser.c:8936
0x7525ed cp_parser_unary_expression
../../gcc/cp/parser.c:8527
0x72b84f cp_parser_cast_expression
../../gcc/cp/parser.c:9712
0x72c082 cp_parser_binary_expression
../../gcc/cp/parser.c:9814
0x72c7e0 cp_parser_assignment_expression
../../gcc/cp/parser.c:10118
0x72dcbd cp_parser_constant_expression
../../gcc/cp/parser.c:10414
0x72f7d2 cp_parser_static_assert
../../gcc/cp/parser.c:15319
0x75d23c cp_parser_member_declaration
../../gcc/cp/parser.c:25844
0x73774e cp_parser_member_specification_opt
../../gcc/cp/parser.c:25712
0x73774e cp_parser_class_specifier_1
../../gcc/cp/parser.c:24801
0x739639 cp_parser_class_specifier
../../gcc/cp/parser.c:25112
0x739639 cp_parser_type_specifier
../../gcc/cp/parser.c:18368
0x73a0b6 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14990
0x75bd05 cp_parser_single_declaration
../../gcc/cp/parser.c:30321
0x75c095 cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.c:29984
0x75c84b cp_parser_explicit_template_declaration
../../gcc/cp/parser.c:30250
0x75c84b cp_parser_template_declaration_after_export
../../gcc/cp/parser.c:30269
0x75ecf9 cp_parser_declaration
../../gcc/cp/parser.c:13996

[Bug c++/98356] New: [9/10/11 Regression] ICE in cp_parser_dot_deref_incomplete, at cp/parser.c:7899

[gscfq--- via Gcc-bugs]

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

Bug ID: 98356
   Summary: [9/10/11 Regression] ICE in
cp_parser_dot_deref_incomplete, at cp/parser.c:7899
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190210 (error) and 20190217 (ICE) :
(typo ; -> .)


$ cat z1.cc
template  class T> struct S
{
  using A = T;
  using A::foo;
  void foo ();
  void bar () {foo.}
};


$ g++-11-20201213 -c z1.cc
z1.cc: In member function 'void S::bar()':
z1.cc:6:19: internal compiler error: Segmentation fault
6 |   void bar () {foo.}
  |   ^
0xc8f5ff crash_signal
../../gcc/toplev.c:327
0x7d8279 cxx_incomplete_type_diagnostic(unsigned int, tree_node const*,
tree_node const*, diagnostic_t)
../../gcc/cp/typeck2.c:373
0x72725e cp_parser_dot_deref_incomplete(tree_node**, cp_expr*, bool*)
../../gcc/cp/parser.c:7899
0x743cb5 cp_parser_postfix_dot_deref_expression
../../gcc/cp/parser.c:7973
0x7414d3 cp_parser_postfix_expression
../../gcc/cp/parser.c:7736
0x751a35 cp_parser_unary_expression
../../gcc/cp/parser.c:8808
0x72b84f cp_parser_cast_expression
../../gcc/cp/parser.c:9712
0x72c082 cp_parser_binary_expression
../../gcc/cp/parser.c:9814
0x72c7e0 cp_parser_assignment_expression
../../gcc/cp/parser.c:10118
0x72d65c cp_parser_expression
../../gcc/cp/parser.c:10288
0x7301e7 cp_parser_expression_statement
../../gcc/cp/parser.c:11955
0x73d44f cp_parser_statement
../../gcc/cp/parser.c:11751
0x73e344 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:12102
0x73e3ff cp_parser_compound_statement
../../gcc/cp/parser.c:12052
0x758ff8 cp_parser_function_body
../../gcc/cp/parser.c:23975
0x758ff8 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:24026
0x7594a6 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:29916
0x759804 cp_parser_late_parsing_for_member
../../gcc/cp/parser.c:30827
0x73866a cp_parser_class_specifier_1
../../gcc/cp/parser.c:25088
0x739639 cp_parser_class_specifier
../../gcc/cp/parser.c:25112

[Bug middle-end/98357] New: Bounds check not eliminated

[jmuizelaar at mozilla dot com via Gcc-bugs]

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

Bug ID: 98357
   Summary: Bounds check not eliminated
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmuizelaar at mozilla dot com
  Target Milestone: ---

#include 
char foo(char* data, size_t len, size_t i, size_t j) {
if (i < len && j <= i) {
if (j < len) {
return data[j];
} else {
exit(1);
}
} else {
return 0;
}
}


compiles to:

foo(char*, unsigned long, unsigned long, unsigned long):
cmp rdx, rsi
jnb .L4
cmp rdx, rcx
jb  .L4
cmp rsi, rcx
jbe .L3
movzx   eax, BYTE PTR [rdi+rcx]
ret
.L4:
xor eax, eax
ret
.L3:
pushrax
mov edi, 1
callexit

The call to exit should be eliminated.

[Bug tree-optimization/98281] - -Wformat-truncation false positive due to excessive integer range (gcc 10.2.0)

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

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Martin Sebor  ---
The warning works as designed but the range information it depends on is less
than perfect.  As discussed in pr94021 that's a known limitation of the current
range propagation infrastructure.  GCC 11 adds an improved range engine known
as the Ranger that's expected to remedy this but it is yet to be integrated
with the sprintf/strlen pass.  The argument ranges can be constrained by using
a "narrower" directive such as %hhu.

A small test case that helps see what's going on is this:

$ gcc -O2 -S -Wall -fdump-tree-strlen-all=/dev/stdout pr98281.c
void f (char *d, int i)
{
  if (i >= 3600 * 24 || i <= -3600 * 24)
return;
  if (i < 0)
i = -i;

  int h = i / 3600;
  int m = (i - (h * 3600)) / 60;
  int s = (i - (h * 3600) - (m * 60));

  if (s > 0)
__builtin_snprintf (d, 9, "%c%02d%02d%02d", '+', h, m, s);
}

;; Function f (f, funcdef_no=0, decl_uid=1944, cgraph_uid=1, symbol_order=0)
...
Intersecting
  int [-169140, 169199]
and
  int [1, 169199]
to
  int [1, 169199]
pushing new range for s_11: int [1, 169199]  EQUIVALENCES: { s_11 } (1
elements)   <<< last argument (s)
pr98281.c:13: snprintfD.977: objsize = 9, fmtstr = "%c%02d%02d%02d"
   <<< snprintf call
  Directive 1 at offset 0: "%c"
Result: 1, 1, 1, 1 (1, 1, 1, 1)
  Directive 2 at offset 2: "%02d"
Result: 2, 2, 2, 2 (3, 3, 3, 3)
  Directive 3 at offset 6: "%02d"  
   <<< last directive
Result: 2, 5, 5, 5 (5, 8, 8, 8)
   <<< output between 2 and 5 bytes
  Directive 4 at offset 10: "%02d"
pr98281.c: In function ‘f’:
pr98281.c:13:42: warning: ‘%02d’ directive output may be truncated writing
between 2 and 6 bytes into a region of size between 1 and 4
[-Wformat-truncation=]
   13 | __builtin_snprintf (d, 9, "%c%02d%02d%02d", '+', h, m, s);
  |  ^~~~
pr98281.c:13:31: note: directive argument in the range [1, 169199]
   13 | __builtin_snprintf (d, 9, "%c%02d%02d%02d", '+', h, m, s);
  |   ^~~~
Result: 2, 6, 6, 6 (7, 14, 14, 14)
  Directive 5 at offset 14: "", length = 1
pr98281.c:13:5: note: ‘__builtin_snprintf’ output between 8 and 15 bytes into a
destination of size 9
   13 | __builtin_snprintf (d, 9, "%c%02d%02d%02d", '+', h, m, s);
  | ^
voidD.51 f (charD.7 * dD.1942, intD.6 iD.1943)
{
  ...
  # RANGE [-169140, 169199]
   <<< last argument (negative?)
  s_11 = _4 + _6;
  ...
  snprintfD.977 (d_13(D), 9, "%c%02d%02d%02d", 43, h_9, m_10, s_11);
  ...
}

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

[Bug tree-optimization/94021] -Wformat-truncation false positive due to excessive integer range

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

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

--- Comment #8 from Martin Sebor  ---
*** Bug 98281 has been marked as a duplicate of this bug. ***

[Bug c++/98355] [9/10/11 Regression] ICE in has_attribute, at c-family/c-attribs.c:5628

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90915,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=92104
 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2020-12-17
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Sebor  ---
The built-in (still) isn't implemented for templates.  See also pr90915 (and
pr92104).  There's little value in raising new reports for this or in changing
the ICE to Sorry.

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
(In reply to Nathan Sidwell from comment #4)
> Created attachment 49789 [details]
> try this

Thanks. That seemed to build ok.

> I tried building with clang, but it barfed about invalid utf8 in libiberty.

I got an ok build with clang of gcc trunk hash 6f8486523f61bf0a,
with your patch.

I am no expert, but maybe you could share the error message. These
problems frequently go away after some random tinkering with locale.

[Bug libgcc/98251] libgcc on 32-bit soft-float ARM narrows -NaN incorrectly

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

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #1 from nsz at gcc dot gnu.org ---
i believe ieee-754 only specifies the sign bit of a
nan after copy, negate, abs and copysign operations.

iso c does not specify further requirements about
the sign bit of a nan either.

so i think gcc should not assume that conversions
preserve the sign bit. (there may be real hw where
that is not the case, independently from what libgcc
is doing.)

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

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

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

--- Comment #6 from Nathan Sidwell  ---
Now I look carefully, it appears to be trying to compile libiberty.a (the
library) as a source file.  Of course that'll barf.  
Configured using "CXX='clang -x c++ -std=c++11'  CC=clang"  (Of course I didn't
look for any instructions :)

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

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

commit r11-6237-g2d7a40fa60fb8b9870cfd053a37fc67404353ee2
Author: Nathan Sidwell 
Date:   Thu Dec 17 09:53:01 2020 -0800

c++: Fix clang problem [PR 98340]

Clang didn't like sizeot (uintset::value) in a templated context.  Not sure
where the problem lies -- ambiguous std, gcc erroneous accept or clang
erroneous
reject.  Anyway, this avoids that construct.

PR c++/98340
gcc/cp/
* module.cc (uintset::hash::add): Use uintset (0u).MEMBER,
rather than uintset::MEMBER.

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #8 from Nathan Sidwell  ---
Fixed

* 2d7a40fa60f 2020-12-17 | c++: Fix clang problem [PR 98340] (HEAD -> master,
origin/master, origin/HEAD) [Nathan Sidwell]

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-12-17
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Googling on munmap_chunk(): invalid pointer reveals that this is quite a
frequent problem.

It originates from the call

out = sel_rank(get_tuple(x))

rather than what happens in either function. Somewhere a free is bein done on
memory that is not malloc'ed.

Bizarrely,

out = sel_rank([get_tuple(x)])

as does

z = get_tuple(x) ! z appropriately declared of course!
out = sel_rank(z)

valgrind confirms this:
snip
==535157== Invalid free() / delete / delete[] / realloc()
==535157==at 0x483A9F5: free (vg_replace_malloc.c:538)
==535157==by 0x40343A: MAIN__ (pr98342.f90:48)
==535157==by 0x4035BA: main (pr98342.f90:40)
==535157==  Address 0x1ffeffede0 is on thread 1's stack
==535157==  in frame #1, created by MAIN__ (pr98342.f90:39)
==535157== 
snip

The problem arises somewhere in trans-expr.c(gfc_conv_procedure_call).

I am on to it :-)

Paul

[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool

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

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

--- Comment #52 from Jim Wilson  ---
I did some simple testing of my patch alone.  I modified the
riscv-gnu-toolchain makefile to use -Os to build all libraries, built a
rv32imac/ilp32 toolchain, and looked at library code size.  I see a few cases
where my patch gives smaller code, and no obvious cases where it gives larger
code, so I think it is OK.

I haven't tried a full test with my patch combined with Levy's patch minus the
combine change.

[Bug rtl-optimization/98347] [11 Regression] gcc.dg/long_branch.c ICEs on i686-linux

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

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Bah, stupid thinko: using regno_raw_mode[regno] instead of
GET_MODE (regno_reg_rtx[regno]) for general registers :-(
Testing a fix.

[Bug c++/98358] New: new test case g++.dg/template/pr98297.C in r8-10683 fails

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

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

Bug ID: 98358
   Summary: new test case g++.dg/template/pr98297.C in r8-10683
fails
   Product: gcc
   Version: 8.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:02092ec9a00273716052732eb9ee343eef6bdc1b, r8-10683

make  -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/template/pr98297.C"
FAIL: g++.dg/template/pr98297.C  -std=c++11  (test for errors, line 5)
FAIL: g++.dg/template/pr98297.C  -std=c++11 (test for excess errors)
FAIL: g++.dg/template/pr98297.C  -std=c++14  (test for errors, line 5)
FAIL: g++.dg/template/pr98297.C  -std=c++14 (test for excess errors)
# of expected passes2
# of unexpected failures4
# of unsupported tests  1

commit 02092ec9a00273716052732eb9ee343eef6bdc1b
Author: Nathan Sidwell 
Date:   Wed Dec 16 11:49:41 2020 -0800

c++: Fix template parm ICE [PR 98297]

Executing on host:
/home/seurer/gcc/git/build/gcc-8-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-8-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-8-test/gcc/testsuite/g++.dg/template/pr98297.C   
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/git/build/gcc-8-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-8-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-8-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-8-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-8-test/libstdc++-v3/testsuite/util
-fmessage-length=0  -std=c++11  -pedantic-errors -Wno-long-long  -S -o
pr98297.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-8-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-8-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-8-test/gcc/testsuite/g++.dg/template/pr98297.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/git/build/gcc-8-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-8-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-8-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-8-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-8-test/libstdc++-v3/testsuite/util
-fmessage-length=0 -std=c++11 -pedantic-errors -Wno-long-long -S -o pr98297.s
/home/seurer/gcc/git/gcc-8-test/gcc/testsuite/g++.dg/template/pr98297.C:5:1:
warning: 'b' attribute directive ignored [-Wattributes]
/home/seurer/gcc/git/gcc-8-test/gcc/testsuite/g++.dg/template/pr98297.C:5:1:
error: name of class shadows template template parameter 'a'
compiler exited with status 1
FAIL: g++.dg/template/pr98297.C  -std=c++11  (test for errors, line 5)
PASS: g++.dg/template/pr98297.C  -std=c++11  (test for warnings, line 5)
FAIL: g++.dg/template/pr98297.C  -std=c++11 (test for excess errors)
Excess errors:
/home/seurer/gcc/git/gcc-8-test/gcc/testsuite/g++.dg/template/pr98297.C:5:1:
error: name of class shadows template template parameter 'a'

[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool

[jiawei at iscas dot ac.cn via Gcc-bugs]

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

--- Comment #53 from jiawei  ---
   Hi Jim,

   Levy had asked me to help about the test. I was resigned on EEMBC and
   waiting acess for more benchmarks. Now I am testing on csibe and
   coremax-pro. I think will lineout the result in this week.If it need
   test on more set. Just mail me about it.

   Best wishes,
   Jiawei


   在 2020年12月18日 上午2:13，"wilson at gcc dot gnu.org"
   写道：

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

 --- Comment #52 from Jim Wilson  ---
 I did some simple testing of my patch alone. I modified the
 riscv-gnu-toolchain makefile to use -Os to build all libraries,
 built a
 rv32imac/ilp32 toolchain, and looked at library code size. I see a
 few cases
 where my patch gives smaller code, and no obvious cases where it
 gives larger
 code, so I think it is OK.

 I haven't tried a full test with my patch combined with Levy's
 patch minus the
 combine change.

 --
 You are receiving this mail because:
 You are on the CC list for the bug.



   1. http://gnu.org

[Bug c++/98358] new test case g++.dg/template/pr98297.C in r8-10683 fails

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

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

Nathan Sidwell  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

--- Comment #1 from Nathan Sidwell  ---
ah, this is clueful about what changed to cause the problem in the first place.

[Bug rtl-optimization/98144] REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #7 from Andrew Macleod  ---
PR 98174 has that patch applied btw.

[Bug middle-end/98357] Bounds check not eliminated

[jmuizelaar at mozilla dot com via Gcc-bugs]

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

--- Comment #1 from Jeff Muizelaar  ---
Clang compiles this to:

foo(char*, unsigned long, unsigned long, unsigned long):   
# @foo(char*, unsigned long, unsigned long, unsigned long)
xor eax, eax
cmp rdx, rsi
jae .LBB0_3
cmp rcx, rdx
ja  .LBB0_3
mov al, byte ptr [rdi + rcx]
.LBB0_3:
ret

with -O2 -mllvm -enable-constraint-elimination

[Bug bootstrap/98359] New: bootstrapping failure on windows

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 98359
   Summary: bootstrapping failure on windows
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

x86_64-w64-mingw32-g++  -fno-PIE -c   -march=x86-64 -mtune=generic -O2 -pipe
-DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag   
-DHAVE_CONFIG_H -I. -Ianalyzer -I../../gcc-git/gcc -I../../gcc-git/gcc/analyzer
-I../../gcc-git/gcc/../include -I../../gcc-git/gcc/../libcpp/include
-I../../gcc-git/gcc/../libcody -I/mingw64/include -I/mingw64/include
-I/mingw64/include  -I../../gcc-git/gcc/../libdecnumber
-I../../gcc-git/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc-git/gcc/../libbacktrace -I/mingw64/include
-D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include -o analyzer/engine.o -MT
analyzer/engine.o -MMD -MP -MF analyzer/.deps/engine.TPo
../../gcc-git/gcc/analyzer/engine.cc
In file included from ../../gcc-git/gcc/target-def.h:121x86_64-w64-mingw32-g++ 
-fno-PIE -c   -march=x86-64 -mtune=generic -O2 -pipe -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-error=format-diag-DHAVE_CONFIG_H -I.
-Ianalyzer -I../../gcc-git/gcc -I../../gcc-git/gcc/analyzer
-I../../gcc-git/gcc/../include -I../../gcc-git/gcc/../libcpp/include
-I../../gcc-git/gcc/../libcody -I/mingw64/include -I/mingw64/include
-I/mingw64/include  -I../../gcc-git/gcc/../libdecnumber
-I../../gcc-git/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc-git/gcc/../libbacktrace -I/mingw64/include
-D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include -o analyzer/function-set.o -MT
analyzer/function-set.o -MMD -MP -MF analyzer/.deps/function-set.TPo
../../gcc-git/gcc/analyzer/function-set.cc
,
 from ../../gcc-git/gcc/config/i386/i386.c:100:
./target-hooks-def.h:2523:3: error: invalid conversion from 'long long int
(*)(poly_int64)' {aka 'long long int (*)(poly_int<1, long long int>)'} to 'long
long int (*)(poly_int64, poly_value_estimate_kind)' {aka 'long long int
(*)(poly_int<1, long long int>, poly_value_estimate_kind)'} [-fpermissive]
 2523 |   }
  |   ^
  |   |
  |   long long int (*)(poly_int64) {aka long long int (*)(poly_int<1, long
long int>)}
../../gcc-git/gcc/config/i386/i386.c:23857:29: note: in expansion of macro
'TARGET_INITIALIZER'
23857 | struct gcc_target targetm = TARGET_INITIALIZER;
  | ^~
x86_64-w64-mingw32-g++  -fno-PIE -c   -march=x86-64 -mtune=generic -O2 -pipe
-DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag   
-DHAVE_CONFIG_H -I. -Ianalyzer -I../../gcc-git/gcc -I../../gcc-git/gcc/analyzer
-I../../gcc-git/gcc/../include -I../../gcc-git/gcc/../libcpp/include
-I../../gcc-git/gcc/../libcody -I/mingw64/include -I/mingw64/include
-I/mingw64/include  -I../../gcc-git/gcc/../libdecnumber
-I../../gcc-git/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc-git/gcc/../libbacktrace -I/mingw64/include
-D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include -o analyzer/pending-diagnostic.o
-MT analyzer/pending-diagnostic.o -MMD -MP -MF
analyzer/.deps/pending-diagnostic.TPo
../../gcc-git/gcc/analyzer/pending-diagnostic.cc
make[2]: *** [Makefile:2383: i386.o] Error 1
make[2]: *** Waiting for unfinished jobs
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod
gcov.pod lto-dump.pod
make[2]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/gcc'
make[1]: *** [Makefile:4446: all-gcc] Error 2
make[1]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32'
make: *** [Makefile:973: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...

unlvs@DESKTOP-DFHPDC1 MINGW64 ~/mingw-gcc-mcf-gthread
$

[Bug c++/98360] New: sizeof in template difference between g++/icc and clang++

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

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

Bug ID: 98360
   Summary: sizeof in template difference between g++/icc and
clang++
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: dcb314 at hotmail dot com, jakub at gcc dot gnu.org,
marxin at gcc dot gnu.org, nathan at gcc dot gnu.org
Depends on: 98340
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #98340 +++

template 
struct delete_ptr_hash
{
};

template 
struct hash_table
{
};

template 
struct uintset
{
  T values[1];
  struct traits : delete_ptr_hash 
  {
  };
  struct hash : hash_table 
  {
int foo ();
  };
  hash h;
};

template 
int
uintset::hash::foo ()
{
  return sizeof (uintset::values);
}

uintset s;
int x = s.h.foo ();

As stated in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98340#c2
the above has been rejected by g++ before
r0-99643-g2defb926479247a61fe0fffbcf95597722a94c40 and by icc 13 and is
rejected by all clang++ versions I've tried (but each compiler different
diagnostic), while it is accepted by g++ 4.6+ and icc 16+.

Is this an accepts-invalid bug in g++ or ice-on-invalid in clang++?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98340
[Bug 98340] gcc trunk build with clang failure, part 2

[Bug bootstrap/98359] bootstrapping failure on windows

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
This patch breaks all platforms it looks like. Even linux has this bug now.

Please fix it asap or it will break everything.


-things like cost calculations or profiling frequencies.  The default\n\
+things like cost calculations or profiling frequencies.  @var{kind} is used\n\
+to ask for the minimum, maximum, and likely estimates of the value through\n\
+the @code{POLY_VALUE_MIN}, @code{POLY_VALUE_MAX} and\n\
+@code{POLY_VALUE_LIKELY} values.  The default\n\
 implementation returns the lowest possible value of @var{val}.",
- HOST_WIDE_INT, (poly_int64 val),
+ HOST_WIDE_INT, (poly_int64 val, poly_value_estimate_kind kind),



Same issue on Linux


gs -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libcody  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/gcc/../libbacktrace   -o insn-recog.o -MT insn-recog.o -MMD -MP -MF
./.deps/insn-recog.TPo insn-recog.c
../../gcc/gcc/../libgcc/libgcov-util.c: In function 'int
gcov_profile_merge(gcov_info*, gcov_info*, int, int)':
../../gcc/gcc/../libgcc/libgcov-util.c:703:12: warning: '*' may be
used uninitialized [-Wmaybe-uninitialized]
  703 |   tgt_tail = tgt_infos[tgt_cnt - 1];
  |   ~^~~~
In file included from ../../gcc/gcc/target-def.h:121,
 from ../../gcc/gcc/config/i386/i386.c:100:
./target-hooks-def.h:2523:3: error: invalid conversion from 'long int
(*)(poly_int64)' {aka 'long int (*)(poly_int<1, long int>)'} to 'long int
(*)(poly_int64, poly_value_estimate_kind)' {aka 'long int (*)(poly_int<1, long
int>, poly_value_estimate_kind)'} [-fpermissive]
 2523 |   }
  |   ^
  |   |
  |   long int (*)(poly_int64) {aka long int (*)(poly_int<1, long int>)}
../../gcc/gcc/config/i386/i386.c:23857:29: note: in expansion of macro
'TARGET_INITIALIZER'
23857 | struct gcc_target targetm = TARGET_INITIALIZER;
  | ^~
g++   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE -fno-PIE
-static-libstdc++ -static-libgcc  -no-pie -o build/genmatch \
build/genmatch.o ../build-x86_64-pc-linux-gnu/libcpp/libcpp.a
build/errors.o build/vec.o build/hash-table.o build/sort.o
../build-x86_64-pc-linux-gnu/libiberty/libiberty.a
build/genmatch --gimple ../../gcc/gcc/match.pd \
> tmp-gimple-match.c
GIMPLE decision tree has 3710 leafs, maximum depth 28 and a total number of
15729 nodes
removed 2449 duplicate tails
build/genmatch --generic ../../gcc/gcc/match.pd \
> tmp-generic-match.c
GENERIC decision tree has 3468 leafs, maximum depth 13 and a total number of
14427 nodes
removed 2379 duplicate tails
/bin/bash ../../gcc/gcc/../move-if-change tmp-gimple-match.c \
gimple-match.c
/bin/bash ../../gcc/gcc/../move-if-change tmp-generic-match.c \
generic-match.c
echo timestamp > s-match
g++  -fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common -Wno-unused -DHAVE_CONFIG_H -I. -I.
-I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o gimple-match.o -MT
gimple-match.o -MMD -MP -MF ./.deps/gimple-match.TPo gimple-match.c
g++  -fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common -Wno-unused -DHAVE_CONFIG_H -I. -I.
-I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o generic-match.o -MT
generic-match.o -MMD -MP -MF ./.deps/generic-match.TPo generic-match.c
make[2]: *** [Makefile:2383: i386.o] Error 1
make[2]: *** Waiting for unfinished jobs
/bin/bash ../../gcc/gcc/../move-if-change tmp-automata.c insn-automata.c
echo timestamp > s-automata
/bin/bash ../../gcc/gcc/../move-if-change tmp-attrtab.cinsn-attrtab.c
/bin/bash ../../gcc/gcc/../move-if-change tmp-dfatab.c