[Bug lto/96591] [8/9/10/11 Regression] ICE with -flto=auto and -O1: tree code ‘typename_type’ is not supported in LTO streams

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

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

--- Comment #7 from Richard Biener  ---
So the type is refered to by constant 8 which is refered to by a VECTOR_CST
{ 8 } which is refered to by

# .MEM_4 = VDEF <.MEM_2>
MEM[(struct Test *)_3].data[0] = { 8 };

and while walk_tree walks CTOR elements for VECTOR_CST it does nothing:

  switch (code)
{
case ERROR_MARK:
case IDENTIFIER_NODE:
case INTEGER_CST:
case REAL_CST:
case FIXED_CST:
case VECTOR_CST:
case STRING_CST:
case BLOCK:
case PLACEHOLDER_EXPR:
case SSA_NAME:
case FIELD_DECL:
case RESULT_DECL:
  /* None of these have subtrees other than those already walked
 above.  */
  break;

which is eventually true since we expect the element type of a VECTOR_CST
to match that of the vector element type.  _But_ - we're forcing a vector
element type to be the main variant / canonical type:

 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x765885e8 precision:32 min  max

pointer_to_this >
type_6 SI size  unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x766dedc8 nunits:1>
constant npatterns:1 nelts-per-pattern:1
elt:0:   constant 8>>
(gdb) p ((tree)0x766de3f0)->type_common.canonical 
$134 = 
(gdb) p ((tree)0x766de3f0)->type_common.main_variant 
$135 = 

where we build this via

#0  0x01cf4437 in tree_vector_builder::build (this=0x7fffbfe0)
at /home/rguenther/src/gcc3/gcc/tree-vector-builder.c:44
#1  0x01d112c9 in build_vector_from_ctor (
type=, v=0x766e72d0 = {...})
at /home/rguenther/src/gcc3/gcc/tree.c:1969
#2  0x012cccda in fold (expr=)
at /home/rguenther/src/gcc3/gcc/fold-const.c:13383
#3  0x00b0b893 in cxx_eval_bare_aggregate (ctx=0x7fffc290, 
t=, lval=false, non_constant_p=0x7fffd1bf, 
overflow_p=0x7fffd1be)
at /home/rguenther/src/gcc3/gcc/cp/constexpr.c:4438
#4  0x00b14c6b in cxx_eval_constant_expression (ctx=0x7fffc610, 
t=, lval=false, non_constant_p=0x7fffd1bf, 
overflow_p=0x7fffd1be, jump_target=0x0)
at /home/rguenther/src/gcc3/gcc/cp/constexpr.c:6591

it's tempting to try force the cached integer constants to be always
unqualified so that only the TYPE_MAIN_VARIANT has TYPE_CACHED_VALUES
and we save memory.  The constant is built via

(gdb) bt
#0  0x01d0fcf1 in cache_wide_int_in_type_cache (
type=, cst=..., slot=9, 
max_slots=252) at /home/rguenther/src/gcc3/gcc/tree.c:1535
#1  0x01d1020d in wide_int_to_tree_1 (
type=, pcst=...)
at /home/rguenther/src/gcc3/gcc/tree.c:1649
#2  0x01d10878 in wide_int_to_tree (
type=, value=...)
at /home/rguenther/src/gcc3/gcc/tree.c:1756
#3  0x01d0f918 in force_fit_type (
type=, cst=..., overflowable=1, 
overflowed=false) at /home/rguenther/src/gcc3/gcc/tree.c:1474
#4  0x012969cb in fold_convert_const_int_from_int (
type=, 
arg1=)
at /home/rguenther/src/gcc3/gcc/fold-const.c:2000
#5  0x012988b6 in fold_convert_const (code=NOP_EXPR, 
type=, 
arg1=)
at /home/rguenther/src/gcc3/gcc/fold-const.c:2276
#6  0x01299214 in fold_convert_loc (loc=0, 
type=, 
arg=)
--Type  for more, q to quit, c to continue without paging--
at /home/rguenther/src/gcc3/gcc/fold-const.c:2418
#7  0x00b714fa in cp_fold_convert (
type=, 
expr=)
at /home/rguenther/src/gcc3/gcc/cp/cvt.c:629
#8  0x00aff0d3 in adjust_temp_type (
type=, 
temp=)
at /home/rguenther/src/gcc3/gcc/cp/constexpr.c:1501
#9  0x00aff651 in cxx_bind_parameters_in_call (ctx=0x7fffd0a0, 
t=, new_call=0x7fffccc0, 
non_constant_p=0x7fffd1bf, overflow_p=0x7fffd1be, 
non_constant_args=0x7fffcc7f)
at /home/rguenther/src/gcc3/gcc/cp/constexpr.c:1611
#10 0x00b0404c in cxx_eval_call_expression (ctx=0x7fffd0a0, 
t=, lval=false, non_constant_p=0x7fffd1bf, 
overflow_p=0x7fffd1be)
at /home/rguenther/src/gcc3/gcc/cp/constexpr.c:2536
#11 0x00b13215 in cxx_eval_constant_expression (ctx=0x7fffd0a0, 
t=, lval=false, non_constant_p=0x7fffd1bf, 
overflow_p=0x7fffd1be, jump_target=0x0)
at /home/rguenther/src/gcc3/gcc/cp/constexpr.c:6134

where the constant is first built in the "correct" type and then
converted via adjust_temp_type which does

1499  /* Now we know we're dealing with a scalar, and a prvalue of
non-class
1500 type is cv-unqualified.  */
1501  return cp_fold_convert (cv_unqualified (type), temp);

but that cv_unqualified doesn't produce the main variant.

Now, as a fact walk_tree _does_ walk COMPLEX_CST components so the "obvious"
fix here would be to change it to also walk VECTOR_CST components.  So that's
what I'm going to try first.

[Bug rtl-optimization/98863] [11 Regression] WRF with LTO consumes a lot of memory in REE, FWPROP and x86 specific passes

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

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

--- Comment #39 from rsandifo at gcc dot gnu.org  
---
Just to give an update on this: I have a patch that reduces the
amount of memory consumed by fwprop so that it no longer seems
to be outlier.  However, it involves doing more bitmap operations.
In this testcase we have a larger number of registers that
seem to be live but unused across a large region of code,
so bitmap ANDs with the live in sets are expensive and hit
the worst-case O(nblocks×nregisters).  I'm still trying to find
a way of reducing the effect of that.

[Bug c++/98232] [9 Regression] ICE when compiling libreoffice

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

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

[Bug c++/95719] [10/11 Regression] ICE in lookup_vfn_in_binfo at gcc/cp/class.c:2459 since r11-954-g0ddb93ce77374004

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

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

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

[Bug rtl-optimization/98863] [11 Regression] WRF with LTO consumes a lot of memory in REE, FWPROP and x86 specific passes

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #40 from rguenther at suse dot de  ---
On Mon, 8 Feb 2021, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
> 
> --- Comment #39 from rsandifo at gcc dot gnu.org  gnu.org> ---
> Just to give an update on this: I have a patch that reduces the
> amount of memory consumed by fwprop so that it no longer seems
> to be outlier.  However, it involves doing more bitmap operations.
> In this testcase we have a larger number of registers that
> seem to be live but unused across a large region of code,
> so bitmap ANDs with the live in sets are expensive and hit
> the worst-case O(nblocks×nregisters).  I'm still trying to find
> a way of reducing the effect of that.

But isn't this what the RD problem does as well (yeah, DF shows
up as quite compile-time expensive here), and thus all UD/DU chain
users suffer from the same issue?

What I didn't explore further is re-doing the way RD numbers defs
in the bitmaps with the idea that all defs just used inside a
single BB are not necessary to be represented (the local problems
take care of them).  But that of course only helps if there are
a significant number of such defs (shadowed by later defs of the same
reg in the same BB) - which usually should be the case.  There's
extra overhead for re-numbering things of course (but my hope was
to make the RD problem fit in the cache for a nice speedup...)

[Bug c++/98990] [10/11 Regression] ICE when two overloaded functions return `auto &&` and one accepts an `auto` parameter since r10-6571-ga6ee556c7659877b

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|Internal compiler error |[10/11 Regression] ICE when
   |when two overloaded |two overloaded functions
   |functions return `auto &&`  |return `auto &&` and one
   |and one accepts an `auto`   |accepts an `auto` parameter
   |parameter   |since
   ||r10-6571-ga6ee556c7659877b
   Last reconfirmed||2021-02-08
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #2 from Martin Liška  ---
With -fchecking, it started with a6ee556c7659877b.

[Bug fortran/98979] [11 regression] ICE in several tests cases after r11-7112

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #3 from Richard Biener  ---
everywhere.

[Bug c++/98991] ICE: Max. number of generated reload insns per insn is achieved (90)

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2021-02-08
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Is it a valid or invalid code, please?

[Bug tree-optimization/98982] Optimizing loop variants of fixed-byte-order functions

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

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

--- Comment #3 from Richard Biener  ---
loop distribution is our pass for this, but then the load/store idioms are
matched by the bswap pass which relies on unrolled loops where the unrolling
will only happen if it doesn't seem to increase code size.

Note your testcase is incomplete and cannot be compiled.

[Bug c++/98983] SEGV during C++17 variadic template instantiation

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2021-02-08

--- Comment #1 from Richard Biener  ---
If preprocessed source is too large please compress it.

[Bug target/98998] New: ICE in change_address_1, at emit-rtl.c:2275

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

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

Bug ID: 98998
   Summary: ICE in change_address_1, at emit-rtl.c:2275
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: arm-linux-gnueabi

Likely similar to PR97269:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/vla15.C
-mcpu=cortex-m1 -mpure-code -fstack-protector -c
during RTL pass: mach
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/vla15.C: In function ‘int
main()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/vla15.C:23:1: internal
compiler error: in change_address_1, at emit-rtl.c:2275
   23 | }
  | ^
0x62057d change_address_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/emit-rtl.c:2275
0x9d275d emit_move_insn(rtx_def*, rtx_def*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/expr.c:3932
0x12becc9 gen_split_74(rtx_insn*, rtx_def**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/config/arm/arm.md:9219
0x9a143e try_split(rtx_def*, rtx_insn*, int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/emit-rtl.c:3834
0xc366c1 split_insn
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/recog.c:3361
0xc3bdd7 split_all_insns_noflow()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/recog.c:3523
0xfc209a arm_reorg
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/config/arm/arm.c:19153
0xc646a9 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/reorg.c:4028
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/98984] Failure to optimize out float conversion from long long->float->char conversion

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|Failure to optinize out |Failure to optimize out
   |float conversion from long  |float conversion from long
   |long->float->char   |long->float->char
   |conversion  |conversion
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-02-08
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  If all target values can be represented exactly.  We can use
unspecified/undefined(?) behavior in float<->integer conversions to our
advantage.

[Bug rtl-optimization/98986] Try matching both orders of commutative RTX operations when there is no canonical order

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |11.0
 CC||rguenth at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Clearly making one order canonical would make sense (subreg, extend, lowpart of
a reg should be singled out from other random exprs of the same kind).

Doesn't help if existing backends do not follow the new canonical order.

On tree/GIMPLE we end up "trying" quite some permutes but on statically
generated decision trees (gimple/generic-match.c) which makes it expensive
on the compiler code-size side but not so expensive on the compile-time side.

(so pre-scanning target .mds and auto-generating parts of combine might
even speed it up ...)

[Bug c++/98990] [10/11 Regression] ICE when two overloaded functions return `auto &&` and one accepts an `auto` parameter since r10-6571-ga6ee556c7659877b

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking,
   ||ice-on-valid-code
   Priority|P3  |P2
   Target Milestone|--- |10.3

[Bug rtl-optimization/98863] [11 Regression] WRF with LTO consumes a lot of memory in REE, FWPROP and x86 specific passes

[richard.sandiford at arm dot com via Gcc-bugs]

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

--- Comment #41 from richard.sandiford at arm dot com ---
"rguenther at suse dot de"  writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
>
> --- Comment #40 from rguenther at suse dot de  ---
> On Mon, 8 Feb 2021, rsandifo at gcc dot gnu.org wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
>> 
>> --- Comment #39 from rsandifo at gcc dot gnu.org > gnu.org> ---
>> Just to give an update on this: I have a patch that reduces the
>> amount of memory consumed by fwprop so that it no longer seems
>> to be outlier.  However, it involves doing more bitmap operations.
>> In this testcase we have a larger number of registers that
>> seem to be live but unused across a large region of code,
>> so bitmap ANDs with the live in sets are expensive and hit
>> the worst-case O(nblocks×nregisters).  I'm still trying to find
>> a way of reducing the effect of that.
>
> But isn't this what the RD problem does as well (yeah, DF shows
> up as quite compile-time expensive here), and thus all UD/DU chain
> users suffer from the same issue?
Sure, it certainly isn't specific to the RTL-SSA code :-)
I just think we can do better than my current WIP patch does.

> What I didn't explore further is re-doing the way RD numbers defs
> in the bitmaps with the idea that all defs just used inside a
> single BB are not necessary to be represented (the local problems
> take care of them).  But that of course only helps if there are
> a significant number of such defs (shadowed by later defs of the same
> reg in the same BB) - which usually should be the case.
Yeah.  And I think the problem here is that we have a large
number of non-local defs and uses.  It doesn't look like there
are an excessive number of uses per def, just that the defs are
live across a large region before being used.

> There's extra overhead for re-numbering things of course (but my hope
> was to make the RD problem fit in the cache for a nice speedup...)

Has anyone looked into how we end up in this situation for this
testcase?  E.g. did we make bad inlining decisions?  Or is it just
a natural consequence of the way the source is written?

We should cope with the situation better regardless, but since
extreme cases like this tend to trigger --param limits, it would
be good to avoid getting into the situation too. :-)

FWIW, as far as compile-time goes, the outlier in a release build
seems to be do_rpo_vn.

[Bug inline-asm/98991] ICE: Max. number of generated reload insns per insn is achieved (90)

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid
  Component|c++ |inline-asm

--- Comment #2 from Richard Biener  ---
it looks reduced ad absurdum but the issue must lie in

 asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));

which I can't really parse but we expand from

int {anonymous}::n ()
{
  int D.2351;
  struct ._anon_1 t;
  float f;
  int D.2422;
  struct ._anon_0 D.2374;
  register int * D.2360;
  void * _1;
  int _5;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  D.2374.__t = 0;
  __asm__("" : "=rmf" f, "=d" D.2374 : "0" 0, "" 0);

likely D.2374 is not re-loadable into DREG.  The zero seems to be SFmode:

(insn 6 2 7 2 (set (reg:SI 86)
(const_int 0 [0])) "t.ii":1:163 75 {*movsi_internal}
 (nil))
(insn 7 6 11 2 (parallel [
(set (mem/c:SF (plus:DI (reg/f:DI 19 frame)
(const_int -4 [0xfffc])) [1 f+0 S4 A32])
(asm_operands:SF ("") ("=rmf") 0 [
(reg:SI 86)
(const_int 0 [0])
]
 [
(asm_input:SI ("0") t.ii:1)
(asm_input:SI ("") t.ii:1)
]
 [] t.ii:1))
(set (reg:SI 84 [ D.2374 ])
(asm_operands:SI ("") ("=d") 1 [
(reg:SI 86)
(const_int 0 [0])
]
 [
(asm_input:SI ("0") t.ii:1)
(asm_input:SI ("") t.ii:1)
]
 [] t.ii:1))
(clobber (reg:CC 17 flags))
]) "t.ii":1:163 -1
 (expr_list:REG_DEAD (reg:SI 86)
(expr_list:REG_UNUSED (reg:SI 84 [ D.2374 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)

and we fail to reload.  It _looks_ similar to

void foo(float f)
{
  struct { float f; } x;
  asm("": "=f" (f), "=d" (x) : "0" (0), "" (0));
}

but we reject this via

t.i: In function 'void foo(float)':
t.i:4:3: error: inconsistent operand constraints in an 'asm'
4 |   asm("": "=f" (f), "=d" (x) : "0" (0), "" (0));
  |   ^~~

[Bug c++/98994] [11 Regression] Empty type with [[no_unique_address]] in union with constructor is not a constant expression

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|Empty type with |[11 Regression] Empty type
   |[[no_unique_address]] in|with [[no_unique_address]]
   |union with constructor is   |in union with constructor
   |not a constant expression   |is not a constant
   ||expression
   Target Milestone|--- |11.0
   Keywords||rejects-valid

[Bug c++/98995] [11 Regression] Copy elision not applied to members declared with [[no_unique_address]]

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
Summary|Copy elision not applied to |[11 Regression] Copy
   |members declared with   |elision not applied to
   |[[no_unique_address]]   |members declared with
   ||[[no_unique_address]]
   Target Milestone|--- |11.0

[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |10.2.1
 Target||x86_64-*-* i?86-*-*

--- Comment #1 from Richard Biener  ---
__builtin{setjmp,longjmp} are internal to GCC (for SJLJ EH), they do _not_
map to setjmp/longjmp in glibc.  Just in case this matters here.

[Bug c++/98994] [11 Regression] Empty type with [[no_unique_address]] in union with constructor is not a constant expression since r11-6918

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
Summary|[11 Regression] Empty type  |[11 Regression] Empty type
   |with [[no_unique_address]]  |with [[no_unique_address]]
   |in union with constructor   |in union with constructor
   |is not a constant   |is not a constant
   |expression  |expression since r11-6918
   Last reconfirmed||2021-02-08
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r11-6918-ga4dfd0f089af33f2af57bf422f9859405b9b4a16

[Bug c++/96003] [11 Regression] spurious -Wnonnull calling a member on the result of static_cast

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

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

--- Comment #19 from Martin Liška  ---
(In reply to Martin Sebor from comment #17)
> Warnings for the static cast suppressed in r11-2457.
> 
> The warning for the dynamic cast is still issued and I would suggest to use
> a cast to a reference instead, both to avoid it and as an indication that
> the cast is expected to succeed (or throw):
> 
>  if (mainloop_ && typeid(mainloop_) == typeid(M)) {
>   dynamic_cast(*mainloop_).setup_M( );

I still see quite some packages failing due to the warning in the dynamic_cast
context. Can you please write a note into Porting to section?

[Bug rtl-optimization/98863] [11 Regression] WRF with LTO consumes a lot of memory in REE, FWPROP and x86 specific passes

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

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

--- Comment #42 from Richard Biener  ---
(In reply to richard.sandiford from comment #41)
> "rguenther at suse dot de"  writes:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
> >
> > --- Comment #40 from rguenther at suse dot de  ---
> > On Mon, 8 Feb 2021, rsandifo at gcc dot gnu.org wrote:
> >
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
> >> 
> >> --- Comment #39 from rsandifo at gcc dot gnu.org  >> gnu.org> ---
> >> Just to give an update on this: I have a patch that reduces the
> >> amount of memory consumed by fwprop so that it no longer seems
> >> to be outlier.  However, it involves doing more bitmap operations.
> >> In this testcase we have a larger number of registers that
> >> seem to be live but unused across a large region of code,
> >> so bitmap ANDs with the live in sets are expensive and hit
> >> the worst-case O(nblocks×nregisters).  I'm still trying to find
> >> a way of reducing the effect of that.
> >
> > But isn't this what the RD problem does as well (yeah, DF shows
> > up as quite compile-time expensive here), and thus all UD/DU chain
> > users suffer from the same issue?
> Sure, it certainly isn't specific to the RTL-SSA code :-)
> I just think we can do better than my current WIP patch does.
> 
> > What I didn't explore further is re-doing the way RD numbers defs
> > in the bitmaps with the idea that all defs just used inside a
> > single BB are not necessary to be represented (the local problems
> > take care of them).  But that of course only helps if there are
> > a significant number of such defs (shadowed by later defs of the same
> > reg in the same BB) - which usually should be the case.
> Yeah.  And I think the problem here is that we have a large
> number of non-local defs and uses.  It doesn't look like there
> are an excessive number of uses per def, just that the defs are
> live across a large region before being used.
> 
> > There's extra overhead for re-numbering things of course (but my hope
> > was to make the RD problem fit in the cache for a nice speedup...)
> 
> Has anyone looked into how we end up in this situation for this
> testcase?  E.g. did we make bad inlining decisions?  Or is it just
> a natural consequence of the way the source is written?

I don't think it's the natural consequence.  Last time I looked at WRF
excessive compile-time issues the root is that there are _lots_ of loops
eventually cloned for pro/epilogue by vectorization so we have _lots_
of loops.  I think the issue is also visible without LTO, just less obviously
pronounced.

> We should cope with the situation better regardless, but since
> extreme cases like this tend to trigger --param limits, it would
> be good to avoid getting into the situation too. :-)

Yeah.  One source of extra lifetime is of course demotion of memory
to registers done by GIMPLE optimizers (store-motion, PRE, hoisting
but also simply FRE).  IIRC WRF once was a bad hitter at store-motion.

> FWIW, as far as compile-time goes, the outlier in a release build
> seems to be do_rpo_vn.

Yeah, I've looked at profiles and the outlier was

static void
do_unwind (unwind_state *to, int rpo_idx, rpo_elim &avail, int *bb_to_rpo)
{
...
  /* Prune [rpo_idx, ] from avail.  */
  /* ???  This is O(number-of-values-in-region) which is
 O(region-size) rather than O(iteration-piece).  */
  for (hash_table::iterator i = vn_ssa_aux_hash->begin ();
   i != vn_ssa_aux_hash->end (); ++i)
{
  while ((*i)->avail)
{
  if (bb_to_rpo[(*i)->avail->location] < rpo_idx)
break;
  vn_avail *av = (*i)->avail;
  (*i)->avail = (*i)->avail->next;
  av->next = avail.m_avail_freelist;
  avail.m_avail_freelist = av;
}
}

which has tons of cache misses (and this is triggered from the region-based
call from unrolling a lot of times, making the comment eventually apply as
well).  But for me the "total" outlier is the sum of DF times.

Again almost all dataflow problems do not fit the cache since the function
is so large.  That adds quite some constant factor to all compile-time
cost making it memory bound :/

[Bug libstdc++/98999] New: Random testsuite errors in 27_io/filesystem/operations/canonical.cc

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

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

Bug ID: 98999
   Summary: Random testsuite errors in
27_io/filesystem/operations/canonical.cc
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

I've noticed random testsuite failures in
27_io/filesystem/operations/canonical.cc

I'm targeting arm, executing under qemu.

As an example I can see this in my libstdc++.log:

terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: cannot make canonical path: No such file or
directory [filesystem-test.Iwjpan-canonical]


terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: comparing 'native' failed: Invalid argument []
[/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/testsuite/normal3/filesystem-test.dJGwrB-canonical]

I'm not sure how to match this to a source line in the testcase?

[Bug libstdc++/98999] Random testsuite errors in 27_io/filesystem/operations/canonical.cc

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

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

Christophe Lyon  changed:

   What|Removed |Added

Version|11.0|10.0

--- Comment #1 from Christophe Lyon  ---
Seen also in the gcc-10 branch:

terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: cannot make canonical path: No such file or
directory [filesystem-test.gXbbQl-canonical]

terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: comparing 'native' failed: Invalid argument []
[/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-arm-none-linux-gnueabihf/gcc3/arm-none-linux-gnueabihf/libstdc++-v3/testsuite/normal1/filesystem-test.daYZUN-canonical]

terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: comparing 'native' failed: Invalid argument []
[/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-armeb-none-linux-gnueabihf/gcc3/armeb-none-linux-gnueabihf/libstdc++-v3/testsuite/normal2/filesystem-test.84BdCk-canonical]

terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: cannot make canonical path: No such file or
directory [filesystem-test.XD0ApR-canonical]

which look very similar.

[Bug libstdc++/98999] Random testsuite errors in 27_io/filesystem/operations/canonical.cc

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

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

--- Comment #2 from Christophe Lyon  ---
There might be similar problems in
experimental/filesystem/operations/current_path.cc, where I can see:

terminate called after throwing an instance of
'std::experimental::filesystem::v1::__cxx11::filesystem_error'
  what():  filesystem error: cannot canonicalize: No such file or directory
[/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc3/arm-none-linux-gnueabihf/libstdc++-v3/testsuite/normal1]
[/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc3/arm-none-linux-gnueabihf/libstdc++-v3/testsuite/normal1]


terminate called after throwing an instance of
'std::experimental::filesystem::v1::__cxx11::filesystem_error'
  what():  filesystem error: cannot canonicalize: No such file or directory
[/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc3/arm-none-linux-gnueabihf/libstdc++-v3/testsuite/normal1]
[/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc3/arm-none-linux-gnueabihf/libstdc++-v3/testsuite/normal1]

[Bug tree-optimization/97236] [8 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile

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

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Kyrylo Tkachov
:

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

commit r8-10757-gde0ede7625f6c4d4bbd2caaf363032b0da80cf69
Author: Matthias Klose 
Date:   Tue Oct 6 13:41:37 2020 +0200

Backport fix for PR/tree-optimization/97236 - fix bad use of
VMAT_CONTIGUOUS

This avoids using VMAT_CONTIGUOUS with single-element interleaving
when using V1mode vectors.  Instead keep VMAT_ELEMENTWISE but
continue to avoid load-lanes and gathers.

2020-10-01  Richard Biener  

PR tree-optimization/97236
* tree-vect-stmts.c (get_group_load_store_type): Keep
VMAT_ELEMENTWISE for single-element vectors.

* gcc.dg/vect/pr97236.c: New testcase.

(cherry picked from commit 1ab88985631dd2c5a5e3b5c0dce47cf8b6ed2f82)

[Bug fortran/98979] [11 regression] ICE in several tests cases after r11-7112

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #4 from Tobias Burnus  ---
For crossref, as Julian stated in
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564920.html :

"Oops -- I tested on a tree with the following patch already applied:
 https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564711.html
 That patch fixes these failures."

(That's part 3/4 of the patch series, which still is pending final approval –
but we are getting there ...)

[Bug preprocessor/98882] [11 Regression] ICE in in cpp_directive_only_process on empty translation unit

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #6 from Boris Kolpackov  ---
After this change I now get an ICE (that same assert) when partially
preprocessing (-E -fdirectives-only) a TU that has an include directive that is
translated to an import:

cat &2; }
function resp () { info "  < $*"; echo "$*"; }

while read l; do
  info "  > $l"

  case "$l" in
HELLO*)
  resp "HELLO 1 test ;"
  ;;
MODULE-REPO)
  resp "PATHNAME /"
  ;;
INCLUDE-TRANSLATE*hello.hxx)
  resp "PATHNAME $(pwd)/hello.gcm"
  ;;
INCLUDE-TRANSLATE*)
  resp "BOOL FALSE"
  ;;
MODULE-EXPORT*|MODULE-IMPORT*)
  resp "PATHNAME $(pwd)/hello.gcm"
  ;;
MODULE-COMPILED*)
  resp "OK"
  ;;
*)
  resp "ERROR 'unexpected request: $l'"
  ;;
  esac
done
EOF

chmod ugo+x ./mapper

g++ -std=c++2a -fmodules-ts -fmodule-mapper='|./mapper' -fmodule-header -x
c++-header hello.hxx
g++ -std=c++2a -fmodules-ts -fmodule-mapper='|./mapper' -E -fdirectives-only -x
c++ -o main.ii main.cxx

main.cxx:1: internal compiler error: in cpp_directive_only_process, at
libcpp/lex.c:4323

0x2c26a7a cpp_directive_only_process(cpp_reader*, void*, void (*)(cpp_reader*,
CPP_DO_task, void*, ...))
../../gcc/libcpp/lex.c:4323
0xf1745e scan_translation_unit_directives_only
../../gcc/gcc/c-family/c-ppoutput.c:402
0xf16928 preprocess_file(cpp_reader*)
../../gcc/gcc/c-family/c-ppoutput.c:100
0xf10e2b c_common_init()
../../gcc/gcc/c-family/c-opts.c:1195
0xbe8ea7 cxx_init()
../../gcc/gcc/cp/lex.c:332
0x180c1af lang_dependent_init
../../gcc/gcc/toplev.c:1881
0x180ca61 do_compile
../../gcc/gcc/toplev.c:2178

Note that there is no assert if we are using import directly, without include
translation.

[Bug tree-optimization/97236] [8 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #16 from Richard Biener  ---
Fixed.

[Bug tree-optimization/97043] latent wrong-code with SLP vectorization

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

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

Bug 97236 Summary: [8 Regression] g:e93428a8b056aed83a7678 triggers vlc 
miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug rtl-optimization/98986] Try matching both orders of commutative RTX operations when there is no canonical order

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

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

--- Comment #2 from Segher Boessenkool  ---
I agree it makes sense to have the one arm with vec_duplicate first in the
canonical order.  Problem is that this is deep in the arms, but it can be
done of course.

Autogenerating part of combine?  Nonononono please.  Or, what part do you
mean?  Something in rtx-simplify would make sense, and something in recog
would make a *lot* of sense.  For the latter, we probably want some more
syntax in the machine description, things like % are too restrictive (and
that is really only meant for RA).  For example, a common pattern is the
sum of three things, which has no good way of expressing right now.

[Bug c++/99000] New: [modules] declaration std::__copy_move_a2 conflicts with import

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 99000
   Summary: [modules] declaration std::__copy_move_a2 conflicts
with import
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

The following header unit import causes the "declaration conflicts with import"
error:

cat ::__type
std::__copy_move_a2(std::istreambuf_iterator<_CharT, std::char_traits<_CharT>
>, std::istreambuf_iterator<_CharT, std::char_traits<_CharT> >, _CharT*)’
conflicts with import
  367 |istreambuf_iterator<_CharT> __last, _CharT*
__result)
  |   
^
In file included from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/char_traits.h:39,
 from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/string_view:41,
 from hello.hxx:3,
of module ./hello.hxx, imported at hello.cxx:1:
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/stl_algobase.h:471:5:
note: import declared ‘template typename
__gnu_cxx::__enable_if::__value, _CharT*>::__type
std::__copy_move_a2(std::istreambuf_iterator<_CharT, std::char_traits<_CharT>
>, std::istreambuf_iterator<_CharT, std::char_traits<_CharT> >, _CharT*)’ here
  471 | __copy_move_a2(istreambuf_iterator<_CharT, char_traits<_CharT> >,
  | ^~


Interestingly, if we change the #include and import order in hello.cxx, then
the error goes away.

[Bug lto/98971] LTO removes __patchable_function_entries

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

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

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

https://gcc.gnu.org/g:0d701e3eb89870237669ef7bf41394d90c35ae70

commit r11-7133-g0d701e3eb89870237669ef7bf41394d90c35ae70
Author: Martin Liska 
Date:   Fri Feb 5 13:11:44 2021 +0100

opts: fix handling of -fpatchable-function-entries option

gcc/ChangeLog:

PR lto/98971
* cfgexpand.c (pass_expand::execute): Parse per-function option
flag_patchable_function_entry and use it.
* common.opt: Remove function_entry_patch_area_size and
function_entry_patch_area_start global variables.
* opts.c (parse_and_check_patch_area): New function.
(common_handle_option): Use it.
* opts.h (parse_and_check_patch_area): New function.
* toplev.c (process_options): Parse and use
function_entry_patch_area_size.

[Bug lto/98971] LTO removes __patchable_function_entries

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

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||11.0
  Known to fail|11.0|

--- Comment #7 from Martin Liška  ---
Fixed on master so far.
@Gabriel: Are you interested in backporting the patch?

[Bug lto/96591] [8/9/10/11 Regression] ICE with -flto=auto and -O1: tree code ‘typename_type’ is not supported in LTO streams

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

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

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

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

commit r11-7134-gd4536e431316b4568e236afd7a6017e5efd1b0a1
Author: Richard Biener 
Date:   Mon Feb 8 09:52:56 2021 +0100

lto/96591 - walk VECTOR_CST elements in walk_tree

This implements walking of VECTOR_CST elements in walk_tree, mimicing
the walk of COMPLEX_CST elements.  Without this free-lang-data fails
to see some types in case they are only refered to via tree constants
used only as VECTOR_CST elements.

2021-02-08  Richard Biener  

PR lto/96591
* tree.c (walk_tree_1): Walk VECTOR_CST elements.

* g++.dg/lto/pr96591_0.C: New testcase.

[Bug lto/96591] [8/9/10 Regression] ICE with -flto=auto and -O1: tree code ‘typename_type’ is not supported in LTO streams

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.0
Summary|[8/9/10/11 Regression] ICE  |[8/9/10 Regression] ICE
   |with -flto=auto and -O1:|with -flto=auto and -O1:
   |tree code ‘typename_type’   |tree code ‘typename_type’
   |is not supported in LTO |is not supported in LTO
   |streams |streams

--- Comment #9 from Richard Biener  ---
Fixed on trunk sofar.

[Bug c++/99001] New: indirect modification of function parameters

[wolfgang.roehrl--- via Gcc-bugs]

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

Bug ID: 99001
   Summary: indirect modification of function parameters
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wolfgang.roe...@gi-de.com
  Target Milestone: ---

Hi,
I would like to post a bug report for the GNU C/C++ compiler 7.5.0.
We use the compiler to generate code for a PowerPC processor.

Invokation line for the GNU C++ compiler:
ccppc -c -x c++ --std=gnu++17 -Wall -Werror -g -mcpu=e6500 -m32
  -maltivec -mvrsave -ftls-model=local-exec -msdata=sysv
  -fno-common -fno-openmp -mbig -mmultiple -mno-string -misel
  -mstrict-align -fverbose-asm -G 8 -O3
  -I
  -D
  X.CPP -oX.O

// file X.CPP

struct X
{
X (int& r) : rr(r) {}
~X () { rr = 0; }

int& rr;
};

int f1 (int i)
{
{ X x(i); }
return i;
}

int f2 (int i)
{
X x(i);
return i;
}

Wenn we compile this program the functions do the following:
- function f1() returns 0 - independently of the value of parameter i;
- function f2() returns the unmodified value of parameter i.

I think that the behaviour of f2() is wrong and f2() should behave as
function f1() does.

With kind regards
W. Roehrl

[Bug c++/98995] [11 Regression] Copy elision not applied to members declared with [[no_unique_address]]

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
Started with r11-2704:

c++: Copy elision and [[no_unique_address]]. [PR93711]

We don't elide a copy from a function returning a class by value into a
base
because that can overwrite data laid out in the tail padding of the base
class; we need to handle [[no_unique_address]] fields the same way, or we
ICE when the middle-end wants to create a temporary object of a
TYPE_NEEDS_CONSTRUCTING type.

This means that we can't always express initialization of a field with
INIT_EXPR from a TARGET_EXPR the way we usually do, so I needed
to change several places that were assuming that was sufficient.

This also fixes 90254, the same problem with C++17 aggregate initialization
of a base.

[Bug c++/99001] indirect modification of function parameters

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Wolfgang Roehrl from comment #0)
> Hi,
> I would like to post a bug report for the GNU C/C++ compiler 7.5.0.

GCC 7 is no longer supported or maintained and will not get any bug fixes.


> I think that the behaviour of f2() is wrong and f2() should behave as
> function f1() does.

No, what GCC does is correct.

In f2 the return value is initialized before x.~X() runs.

[Bug rtl-optimization/98863] [11 Regression] WRF with LTO consumes a lot of memory in REE, FWPROP and x86 specific passes

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

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

--- Comment #43 from Richard Biener  ---
So module_configure.fppized.f90 is one of the interesting ones (IIRC lot of
small init loops), module_first_rk_step_part1.fppized.f90 is the one with most
obvious DF and fwprop participation, that one also has complete unrolling.

/home/rguenther/install/gcc-11.0/usr/local/bin/gfortran -c -o
start_em.fppized.o -I. -I./netcdf/include -I./inc -Ofast -march=znver2
-ftime-report -std=legacy -fconvert=big-endian -fno-openmp -g0
start_em.fppized.f90
 df reaching defs   :   0.96 (  3%)   0.02 (  3%)   0.94 (  3%)
0  (  0%)
 df live regs   :   1.15 (  4%)   0.00 (  0%)   1.13 (  4%)
0  (  0%)
 df live&initialized regs   :   1.08 (  4%)   0.01 (  2%)   1.18 (  4%)
0  (  0%)
 tree forward propagate :   0.09 (  0%)   0.01 (  2%)   0.08 (  0%)
 2217k (  0%)
 complete unrolling :   1.00 (  3%)   0.02 (  3%)   1.01 (  3%)
   56M ( 12%)
 forward prop   :   0.93 (  3%)   0.18 ( 29%)   1.10 (  4%)
  388k (  0%)
 TOTAL  :  30.60  0.62 31.23   
  492M

/home/rguenther/install/gcc-11.0/usr/local/bin/gfortran -c -o
module_advect_em.fppized.o -I. -I./netcdf/include -I./inc -Ofast -march=znver2
-ftime-report -std=legacy -fconvert=big-endian -fno-openmp -g0
module_advect_em.fppized.f90
 df reaching defs   :   0.28 (  1%)   0.00 (  0%)   0.30 (  1%)
0  (  0%)
 df live regs   :   1.45 (  5%)   0.00 (  0%)   1.35 (  4%)
0  (  0%)
 df live&initialized regs   :   0.54 (  2%)   0.00 (  0%)   0.64 (  2%)
0  (  0%)
 tree forward propagate :   0.08 (  0%)   0.00 (  0%)   0.13 (  0%)
 2824k (  0%)
 complete unrolling :   0.99 (  3%)   0.03 (  9%)   1.05 (  3%)
   78M (  8%)
 forward prop   :   0.24 (  1%)   0.00 (  0%)   0.20 (  1%)
 1270k (  0%)
 TOTAL  :  31.59  0.34 31.96   
  974M

/home/rguenther/install/gcc-11.0/usr/local/bin/gfortran -c -o
module_first_rk_step_part1.fppized.o -I. -I./netcdf/include -I./inc -Ofast
-march=znver2 -ftime-report -std=legacy -fconvert=big-endian -fno-openmp -g0
module_first_rk_step_part1.fppized.f90
 df reaching defs   :   2.69 (  4%)   0.04 (  3%)   2.81 (  5%)
0  (  0%)
 df live regs   :   1.76 (  3%)   0.01 (  1%)   1.71 (  3%)
0  (  0%)
 df live&initialized regs   :   1.57 (  3%)   0.01 (  1%)   1.58 (  3%)
0  (  0%)
 tree forward propagate :   0.20 (  0%)   0.02 (  2%)   0.19 (  0%)
 4095k (  0%)
 complete unrolling :   3.25 (  5%)   0.04 (  3%)   3.27 (  5%)
   94M ( 11%)
 forward prop   :   2.79 (  5%)   0.38 ( 30%)   3.16 (  5%)
  765k (  0%)
 TOTAL  :  60.41  1.27 61.72   
  873M

/home/rguenther/install/gcc-11.0/usr/local/bin/gfortran -c -o
solve_em.fppized.o -I. -I./netcdf/include -I./inc -Ofast -march=znver2
-ftime-report -std=legacy -fconvert=big-endian -fno-openmp -g0
solve_em.fppized.f90
 df reaching defs   :   1.57 (  5%)   0.01 (  2%)   1.50 (  5%)
0  (  0%)
 df live regs   :   2.22 (  7%)   0.01 (  2%)   2.24 (  7%)
0  (  0%)
 df live&initialized regs   :   2.83 (  9%)   0.01 (  2%)   2.81 (  9%)
0  (  0%)
 tree forward propagate :   0.15 (  0%)   0.00 (  0%)   0.15 (  0%)
 2644k (  0%)
 complete unrolling :   1.11 (  4%)   0.02 (  4%)   1.12 (  4%)
   86M ( 14%)
 forward prop   :   0.75 (  2%)   0.08 ( 14%)   0.84 (  3%)
  495k (  0%)
 TOTAL  :  31.21  0.57 31.80   
  629M

In the end LTO makes the case unique still ...

And then there's of course one other frequently reported bug:

/home/rguenther/install/gcc-11.0/usr/local/bin/gfortran -c -o
module_alloc_space_2.fppized.o -I. -I./netcdf/include -I./inc -Ofast
-march=znver2 -ftime-report -std=legacy -fconvert=big-endian -fno-openmp -g0
module_alloc_space_2.fppized.f90
 load CSE after reload  :  10.18 ( 37%)   0.00 (  0%)  10.19 ( 37%)
   14k (  0%)
 TOTAL  :  27.28  0.33 27.63   
  333M

[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code

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

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-02-08
 Status|UNCONFIRMED |NEW

--- Comment #2 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564972.html

[Bug tree-optimization/99002] New: [11 Regression] memory leak in if-to-switch

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

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

Bug ID: 99002
   Summary: [11 Regression] memory leak in if-to-switch
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

==1542== Memcheck, a memory error detector
==1542== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1542== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==1542== Command: ./cc1 -quiet -fdiagnostics-plain-output -O2 -fno-tree-vrp
-fdump-tree-dom2-details -o ssa-dom-thread-1.s
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-11.c
==1542==
==1542==
==1542== HEAP SUMMARY:
==1542== in use at exit: 1,875,265 bytes in 2,696 blocks
==1542==   total heap usage: 16,329 allocs, 13,633 frees, 6,189,742 bytes
allocated
==1542==
==1542== 64 bytes in 1 blocks are definitely lost in loss record 151 of 682
==1542==at 0x4C2E94F: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1542==by 0x24FFE0F: find_conditions(basic_block_def*,
hash_map, condition_info*>
>*) (gimple-if-to-switch.cc:398)
==1542==by 0x250044B: (anonymous
namespace)::pass_if_to_switch::execute(function*) (gimple-if-to-switch.cc:499)
==1542==by 0x12E8130: execute_one_pass(opt_pass*) (passes.c:2572)
==1542==by 0x12E8467: execute_pass_list_1(opt_pass*) (passes.c:2661)
==1542==by 0x12E8498: execute_pass_list_1(opt_pass*) (passes.c:2662)
==1542==by 0x12E84F0: execute_pass_list(function*, opt_pass*)
(passes.c:2672)
==1542==by 0x12E6425: do_per_function_toporder(void (*)(function*, void*),
void*) (passes.c:1774)
==1542==by 0x12E9120: execute_ipa_pass_list(opt_pass*) (passes.c:3006)
==1542==by 0xCFC9D6: ipa_passes() (cgraphunit.c:2157)
==1542==by 0xCFCE0C: symbol_table::compile() (cgraphunit.c:2292)
==1542==by 0xCFD379: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2540)
==1542==

[Bug tree-optimization/99002] [11 Regression] memory leak in if-to-switch

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |11.0

[Bug ipa/97346] IPA reference reference_vars_to_consider leaks

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

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

--- Comment #2 from Richard Biener  ---
Ping.  This is annoying and pops up with each and every valgrind
--leak-check=full ...

[Bug c++/98987] Concept subsumption doesn't work with by-value vs. by-reference parameters

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
As with PR96333, since the function templates' function parameters aren't
equivalent, neither is considered more constrained than the other, and so we're
correct to reject this testcase from what I understand.

[Bug target/97638] aarch64: bti c is missing at function entry with branch-protection

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

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

Wilco  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||wilco at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Wilco  ---
Fixed and backported, so close.

[Bug ipa/93115] gcc fails to emit inline function on llvm-roc project: -O1 -fPIC -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden

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

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

--- Comment #7 from Sergei Trofimovich  ---
Looks like original test does not trigger the bug as is (probably due to tets
fragility). Here is something shorter (but with warnings):

```c++
struct a {
  char at;
  char au;
  int d() { return av() + au - at; }
  virtual void f() {}
  virtual int av() { }
};
struct g : a {
  void f();
  char b;
  char c() { return b; }
} b;
#ifdef MAIN_FILE
g e;
void h() {
  if (b.c()) {
e.d();
return;
  }
}
int main() {}
#endif
#ifdef LIB_FILE
void g::f() {}
#endif
```

$ g++-11.0.0 -Wall -fPIC -O1 -fdevirtualize -fdevirtualize-speculatively
-fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden -fPIC -shared -o libbug.so
bug.cpp -DLIB_FILE
bug.cpp: In member function 'virtual int a::av()':
bug.cpp:6:22: warning: no return statement in function returning non-void
[-Wreturn-type]
6 |   virtual int av() { }
  |  ^

$ g++-11.0.0 -Wall -fPIC -O1 -fdevirtualize -fdevirtualize-speculatively
-fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden -o main bug.cpp -DMAIN_FILE
-L. -lbug
bug.cpp: In member function 'virtual int a::av()':
bug.cpp:6:22: warning: no return statement in function returning non-void
[-Wreturn-type]
6 |   virtual int av() { }
  |  ^
/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/tmp/ccbaHYef.o: in function `h()':
bug.cpp:(.text+0x1a): undefined reference to `a::av()'
collect2: error: ld returned 1 exit status

[Bug ipa/99003] New: memory leak in IPA ICF

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

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

Bug ID: 99003
   Summary: memory leak in IPA ICF
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

==1945== Memcheck, a memory error detector
==1945== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1945== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==1945== Command: ./cc1 -quiet -fdiagnostics-plain-output -O3 -o
ssa-dom-thread-1.s
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/tree-ssa/20030714-1.c
==1945==
==1945==
==1945== HEAP SUMMARY:
==1945== in use at exit: 1,973,344 bytes in 2,924 blocks
==1945==   total heap usage: 52,587 allocs, 49,663 frees, 19,998,193 bytes
allocated
==1945==
==1945== 16 bytes in 1 blocks are definitely lost in loss record 9 of 785
==1945==at 0x4C2E94F: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1945==by 0x263B75A:
ipa_icf::sem_item::add_reference(hash_map,
simple_hashmap_traits,
auto_vec > >*, ipa_icf::sem_item*) (ipa-icf.c:169)
==1945==by 0x264556E: ipa_icf::sem_item_optimizer::build_graph()
(ipa-icf.c:2642)
==1945==by 0x26448AF: ipa_icf::sem_item_optimizer::execute()
(ipa-icf.c:2423)
==1945==by 0x2648932: ipa_icf::ipa_icf_driver() (ipa-icf.c:3584)
==1945==by 0x264B206: ipa_icf::pass_ipa_icf::execute(function*)
(ipa-icf.c:3631)
==1945==by 0x12E8130: execute_one_pass(opt_pass*) (passes.c:2572)
==1945==by 0x12E90C8: execute_ipa_pass_list(opt_pass*) (passes.c:3001)
==1945==by 0xCFCB79: ipa_passes() (cgraphunit.c:2215)
==1945==by 0xCFCE0C: symbol_table::compile() (cgraphunit.c:2292)
==1945==by 0xCFD379: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2540)
==1945==by 0x148FF21: compile_file() (toplev.c:482)

[Bug middle-end/99004] New: memory leak in maybe_warn_rdwr_sizes

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

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

Bug ID: 99004
   Summary: memory leak in maybe_warn_rdwr_sizes
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

==3511== Memcheck, a memory error detector
==3511== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3511== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==3511== Command: ./cc1 -quiet -fdiagnostics-plain-output -O3 -o
ssa-dom-thread-1.s
/home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c
==3511==
==3511==
==3511== HEAP SUMMARY:
==3511== in use at exit: 2,402,368 bytes in 5,697 blocks
==3511==   total heap usage: 424,419 allocs, 418,722 frees, 208,122,638 bytes
allocated
==3511==
==3511== 2 bytes in 1 blocks are definitely lost in loss record 1 of 921
==3511==at 0x4C2E2DF: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3511==by 0x28ECDF6: xmalloc (xmalloc.c:147)
==3511==by 0x28ECF6F: xstrdup (xstrdup.c:34)
==3511==by 0x15EF51F: print_generic_expr_to_str(tree_node*)
(tree-pretty-print.c:179)
==3511==by 0xC532AD: maybe_warn_rdwr_sizes(hash_map,
attr_access> >*, tree_node*, tree_node*, tree_node*) (calls.c:2035)
==3511==by 0xC5535F: initialize_argument_information(int, arg_data*,
args_size*, int, tree_node*, tree_node*, tree_node*, tree_node*,
cumulative_args_t, int, rtx_def**, poly_int_pod<1u, long>*, int*, int*, bool*,
bool) (calls.c:2625)
==3511==by 0xC5957C: expand_call(tree_node*, rtx_def*, int) (calls.c:4009)
==3511==by 0xE84D06: expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool) (expr.c:11279)
==3511==by 0xE77230: expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool) (expr.c:8513)
==3511==by 0xC7C8EA: expand_expr(tree_node*, rtx_def*, machine_mode,
expand_modifier) (expr.h:282)
==3511==by 0xC858B6: expand_call_stmt(gcall*) (cfgexpand.c:2840)
==3511==by 0xC8933E: expand_gimple_stmt_1(gimple*) (cfgexpand.c:3844)

[Bug ipa/97346] IPA reference reference_vars_to_consider leaks

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

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

Jan Hubicka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-02-08
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #3 from Jan Hubicka  ---
I will check

If I recall correctly, during analysis the vector is only collected for dumps,
so that is why vec_free is conditional. Since vec_free is noop on NULL, we
could just free it anyway.  I think it is the delete call that causes the leak.

[Bug tree-optimization/98856] [11 Regression] botan AES-128/XTS is slower by ~17% since r11-6649-g285fa338b06b804e72997c4d876ecf08a9c083af

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

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

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

Full patch.

[Bug c++/98988] delete is not a constant expression with -fsanitize=undefined

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

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

--- Comment #1 from Jakub Jelinek  ---
Some sanitizers imply -fno-delete-null-pointer-checks and this testcase fails
with  fno-delete-null-pointer-checks too - the &heap_magic_var_decl != NULL
comparison in that case which is done on delete is not folded into true.
Wonder if at least for the magic heap vars we shouldn't fold comparisons
against NULL, because those will never live in any memory and thus we can
pretend their address will never be 0.

[Bug inline-asm/98991] ICE: Max. number of generated reload insns per insn is achieved (90)

[zhan3299 at purdue dot edu via Gcc-bugs]

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

--- Comment #3 from zhan3299 at purdue dot edu ---
(In reply to Martin Liška from comment #1)
> Is it a valid or invalid code, please?

Hi, sorry for the confusion. I used a simple delta debugging to reduce the
test-case, and it seems very confused.

Currently, I use C-Reduce to get a simple test-case:


--- poc.cc starts ---
void a() {
  float b;
  asm("" : "=rmf"(b) : "0"(0));
  &b;
}
--- poc.cc ends ---


run 'gcc poc.cc -fpermissive' and we can get the same ICE.


--- error trace starts ---
during RTL pass: reload
poc.cc: In function 'void a()':
poc.cc:5:1: internal compiler error: maximum number of generated reload insns
per insn achieved (90)
5 | }
  | ^
0x20cb324 lra_constraints(bool)
../../gcc/gcc/lra-constraints.c:4951
0x20ab2c8 lra(_IO_FILE*)
../../gcc/gcc/lra.c:2440
0x1ff80de do_reload()
../../gcc/gcc/ira.c:5523
0x1ff80de (anonymous namespace)::pass_reload::execute(function*)
../../gcc/gcc/ira.c:5709
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
--- error trace ends ---


I test it with gcc 10.2.0, but it seems my native 7.5.0 also failed.

[Bug inline-asm/98991] ICE: Max. number of generated reload insns per insn is achieved (90)

[zhan3299 at purdue dot edu via Gcc-bugs]

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

--- Comment #4 from zhan3299 at purdue dot edu ---
Seems '-fpermissive' is useless. I can reproduce the ICE simply via 'gcc
poc.cc'

[Bug fortran/99005] New: libgomp runtime does not support AMD GPU offloading for OpenACC directives

[kd486 at cam dot ac.uk via Gcc-bugs]

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

Bug ID: 99005
   Summary: libgomp runtime does not support AMD GPU offloading
for OpenACC directives
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kd486 at cam dot ac.uk
  Target Milestone: ---

Created attachment 50143
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50143&action=edit
Sample code with single OpenACC directive in for loop

Simple Gfortran compiled OpenACC code crashes. Code used attached and compiled
with:
gfortran -fopenacc -Wall -Wextra -foffload=amdgcn-amdhsa="-march=gfx900" -c
mymodule.f90

The server has an AMD EPYC 7742 CPU with 4 Vega 20 AMD GPUs.

Runtime error:

 ./main 

libgomp: GCN fatal error: Run-time could not be initialized
Runtime message: HSA_STATUS_ERROR_OUT_OF_RESOURCES: The runtime failed to
allocate the necessary resources. This error may also occur when the core
runtime library needs to spawn threads or create internal OS-specific events.

Code runs fine without GPU offloading, or with offloading with PGI compiler.

[Bug middle-end/98974] [11 Regression] ICE in vectorizable_condition after STMT_VINFO_VEC_STMTS

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Andre Simoes Dias Vieira
:

https://gcc.gnu.org/g:40c92180df970143249f3cd5056f8fb48a4d9333

commit r11-7135-g40c92180df970143249f3cd5056f8fb48a4d9333
Author: Andre Vieira 
Date:   Mon Feb 8 16:04:18 2021 +

middle-end/98974 - fixup after STMT_VINFO_VEC_STMTS rework

This fixes up the nvectors parameter passed to vect_get_loop_mask in
vectorizable_condition after the STMT_VINFO_VEC_STMTS rework.

gcc/ChangeLog:
2021-02-08  Andre Vieira  

PR middle-end/98974
* tree-vect-stmts.c (vectorizable_condition): Remove shadow vec_num
parameter in vectorizable_condition.

gcc/testsuite/ChangeLog:
2021-02-08  Andre Vieira  

PR middle-end/98974
* gfortran.dg/pr98974.F90: New test.

[Bug middle-end/98974] [11 Regression] ICE in vectorizable_condition after STMT_VINFO_VEC_STMTS

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

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from avieira at gcc dot gnu.org ---
That should fix it.

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

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

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

Bug 98974 Summary: [11 Regression] ICE in vectorizable_condition after 
STMT_VINFO_VEC_STMTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974

   What|Removed |Added

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

[Bug tree-optimization/99002] [11 Regression] memory leak in if-to-switch

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-02-08
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Mine.

[Bug ipa/99003] memory leak in IPA ICF

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-02-08

--- Comment #1 from Martin Liška  ---
Mine.

[Bug middle-end/99004] memory leak in maybe_warn_rdwr_sizes

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug libstdc++/99006] New: make_shared silently works

[Darrell.Wright at gmail dot com via Gcc-bugs]

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

Bug ID: 99006
   Summary: make_shared silently works
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Darrell.Wright at gmail dot com
  Target Milestone: ---

std::make_shared in libstdc++ prior to c++20 doesn't fail.

The minimal example is

#include 
int func( ) {
  auto sp = std::make_shared( 55 );
  return *sp.get( );
}

will return 55;

libc++ removes it from the overload set and MS STL fails.
https://gcc.godbolt.org/z/PaW6WY

With T = int[], I think
https://timsong-https://timsong-cpp.github.io/cppwp/n4659/util.smartptr.shared.create#1
should make this not work.

[Bug ipa/93115] gcc fails to emit inline function on llvm-roc project: -O1 -fPIC -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden

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

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

--- Comment #8 from Sergei Trofimovich  ---
Slightly better example without warnings (used `__builtin_trap();` to work
around use of uninitialized value):

```c++
struct a {
  char ac1;
  char ac2;
  int d() { return av() + ac1 + ac2; }
  virtual void f() {}
  virtual int av() { __builtin_trap(); }

  a(){}
};

struct g : a {
  virtual void f2();

  g():a(){}
};

#ifdef LIB_FILE
void g::f2() {}
#endif
#ifdef MAIN_FILE
static g b;
static char bb;
char cc() { return bb; }

void h() {
  if (cc()) {
b.d();
return;
  }
}
int main() {}
#endif
```

[Bug c++/98531] [11 Regression] g++.dg/modules/xtreme-header-2_a.H etc. FAIL

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

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

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

https://gcc.gnu.org/g:57b17858a1b3719507ccad926fb57b05f26935f8

commit r11-7138-g57b17858a1b3719507ccad926fb57b05f26935f8
Author: Nathan Sidwell 
Date:   Fri Jan 22 08:48:27 2021 -0800

c++: cross-module __cxa_atexit use [PR 98531]

The compiler's use of lazily-declared library functions must insert
said functions into a symbol table, so that they can be correctly
merged across TUs at the module-level.  We have too many different
ways of declaring such library functions.  This fixes __cxa_atexit (or
its system-specific variations), pushing (or merging) the decl into
the appropriate namespace.  Because we're pushing a lazy builtin,
check_redeclaration_exception_specification needed a tweak to allow a
such a builtin's eh spec to differ from what the user may have already
declared. (I suspect no all headers declare atexit as noexcept.)

We can't test the -fno-use-cxa-atexit path with modules, as that
requires a followup patch to a closely related piece (which also
affects cxa_atexit targets in other circumstances).

PR c++/98531
gcc/cp/
* cp-tree.h (push_abi_namespace, pop_abi_namespace): Declare.
* decl.c (push_abi_namespace, pop_abi_namespace): Moved
from rtti.c, add default namespace arg.
(check_redeclaration_exception_specification): Allow a lazy
builtin's eh spec to differ from an lready-declared user
declaration.
(declare_global_var): Use push/pop_abi_namespace.
(get_atexit_node): Push the fndecl into a namespace.
* rtti.c (push_abi_namespace, pop_abi_namespace): Moved to
decl.c.
gcc/testsuite/
* g++.dg/modules/pr98531-1.h: New.
* g++.dg/modules/pr98531-1_a.H: New.
* g++.dg/modules/pr98531-1_b.C: New.
* g++.dg/abi/pr98531-1.C: New.
* g++.dg/abi/pr98531-2.C: New.
* g++.dg/abi/pr98531-3.C: New.
* g++.dg/abi/pr98531-4.C: New.

[Bug c++/98531] [11 Regression] g++.dg/modules/xtreme-header-2_a.H etc. FAIL

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #12 from Nathan Sidwell  ---
With two patches committed:
* efcd941e86b 2021-02-03 | c++: cleanup function name [PR 98531] (HEAD ->
master, origin/master, origin/HEAD, me/regressions) [Nathan Sidwell]
* 57b17858a1b 2021-01-22 | c++: cross-module __cxa_atexit use [PR 98531]
[Nathan Sidwell]

an i386-solaris2.11 cc1plus can compile the testcase.  If there's still a
problem with (this bit of) the testsuite more information is needed, or maybe a
different report?

[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code

[luto at kernel dot org via Gcc-bugs]

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

--- Comment #3 from Andy Lutomirski  ---
What is -fcf-protection=stack actually supposed to do as compared to
-fcf-protection=none?  Is it valid to run code compiled with
-fcf-protection=none with SHSTK enabled?  If so, then I wonder why
-fcf-protection=stack exists at all.  If not, then I'm wondering why your patch
seems to be effectively hardcoding "stack" mode for SJLJ?

You could probably fix this bug differently by changing __builtin_setjmp() to
store 0 for SSP in "none" mode.  Then at least -fcf-protection=none wouldn't
emit CET code.

[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code

[luto at kernel dot org via Gcc-bugs]

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

--- Comment #4 from Andy Lutomirski  ---
I should add: on brief inspection, that patch looks like an ABI break for
-fcf-protection=none

[Bug c++/99007] New: [11 Regression] ICE in dominated_by_p, at dominance.c:1124

[gscfq--- via Gcc-bugs]

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

Bug ID: 99007
   Summary: [11 Regression] ICE in dominated_by_p, at
dominance.c:1124
   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 between 20201018 and 20201108 :


$ cat z1.cc
template  void bar (T *)
{
  T s[0/0];
  #pragma omp teams distribute parallel for reduction(+:s) allocate(s)
  for (int i = 0; i < 8; i++);
}
void foo ()
{
  long *a;
  bar (a);
}


$ g++-11-20210207 -c z1.cc -fopenmp
z1.cc: In function 'void bar(T*)':
z1.cc:3:8: warning: division by zero [-Wdiv-by-zero]
3 |   T s[0/0];
  |   ~^~
z1.cc: In instantiation of 'void bar(T*) [with T = long int]':
z1.cc:10:9:   required from here
z1.cc:3:8: warning: division by zero [-Wdiv-by-zero]
during GIMPLE pass: ssa
z1.cc: In function '_Z3barIlEvPT_._omp_fn.0':
z1.cc:11:1: internal compiler error: Segmentation fault
   11 | }
  | ^
0xfe6cdf crash_signal
../../gcc/toplev.c:327
0xb6e764 dominated_by_p(cdi_direction, basic_block_def const*, basic_block_def
const*)
../../gcc/dominance.c:1124
0x1259775 verify_use
../../gcc/tree-ssa.c:892
0x125e462 verify_ssa(bool, bool)
../../gcc/tree-ssa.c:1167
0xef8a87 execute_function_todo
../../gcc/passes.c:2049
0xef97f2 execute_todo
../../gcc/passes.c:2096

[Bug c++/99007] [11 Regression] ICE in dominated_by_p, at dominance.c:1124

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |11.0
   Last reconfirmed||2021-02-08
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with my r11-4710-g9649031577028310e853025672c71dfb500494f0 change when
allocate clause has been implemented for this.

[Bug c++/99008] New: [11 Regression] ICE in set_constraints, at cp/constraint.cc:1256

[gscfq--- via Gcc-bugs]

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

Bug ID: 99008
   Summary: [11 Regression] ICE in set_constraints, at
cp/constraint.cc:1256
   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 20200621 and 20200628 :
(maybe related to pr93297)


$ cat z1.cc
template  struct A;
template  using C = A;
void *f { C(); }


$ g++-11-20210207 -c z1.cc
z1.cc:3:13: internal compiler error: in set_constraints, at
cp/constraint.cc:1256
3 | void *f { C(); }
  | ^
0x6a757e set_constraints(tree_node*, tree_node*)
../../gcc/cp/constraint.cc:1256
0x7b1bd2 alias_ctad_tweaks
../../gcc/cp/pt.c:29025
0x7b1bd2 deduction_guides_for
../../gcc/cp/pt.c:29140
0x7b2042 do_class_deduction
../../gcc/cp/pt.c:29250
0x7b2042 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/cp/pt.c:29420
0x81c535 build_functional_cast_1
../../gcc/cp/typeck2.c:2208
0x81c535 build_functional_cast(unsigned int, tree_node*, tree_node*, int)
../../gcc/cp/typeck2.c:2308
0x772977 cp_parser_functional_cast
../../gcc/cp/parser.c:30553
0x783bd2 cp_parser_postfix_expression
../../gcc/cp/parser.c:7427
0x793d35 cp_parser_unary_expression
../../gcc/cp/parser.c:8818
0x76d96f cp_parser_cast_expression
../../gcc/cp/parser.c:9722
0x76e1a2 cp_parser_binary_expression
../../gcc/cp/parser.c:9824
0x76e900 cp_parser_assignment_expression
../../gcc/cp/parser.c:10128
0x76fddd cp_parser_constant_expression
../../gcc/cp/parser.c:10424
0x76fe41 cp_parser_initializer_clause
../../gcc/cp/parser.c:24145
0x76ffe4 cp_parser_initializer_list
../../gcc/cp/parser.c:24424
0x76ffe4 cp_parser_braced_list
../../gcc/cp/parser.c:24186
0x772b82 cp_parser_initializer
../../gcc/cp/parser.c:24103
0x79c6b7 cp_parser_init_declarator
../../gcc/cp/parser.c:21745
0x77cf3a cp_parser_simple_declaration
../../gcc/cp/parser.c:14381

[Bug c++/99008] [10/11 Regression] ICE in set_constraints, at cp/constraint.cc:1256

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2021-02-08
Summary|[11 Regression] ICE in  |[10/11 Regression] ICE in
   |set_constraints, at |set_constraints, at
   |cp/constraint.cc:1256   |cp/constraint.cc:1256
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
With -std=c++17, it started with r10-5020-g1a291106384cabc7.

[Bug c++/99009] New: [11 Regression] ICE in type_dependent_expression_p, at cp/pt.c:27265

[gscfq--- via Gcc-bugs]

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

Bug ID: 99009
   Summary: [11 Regression] ICE in type_dependent_expression_p, at
cp/pt.c:27265
   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 20200621 and 20200628 :
(presumably related to pr97034)


$ cat z1.cc
template  struct B
{
  B (int = A()) {}
  template  struct A;
};


$ cat z2.cc
template  struct A
{
  template  struct B;
  A () { B c; };
};


$ g++-11-20210207 -c z1.cc
z1.cc:3:14: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:27265
3 |   B (int = A()) {}
  |  ^
0x7aacd8 type_dependent_expression_p(tree_node*)
../../gcc/cp/pt.c:27264
0x7b7ca4 maybe_instantiate_noexcept(tree_node*, int)
../../gcc/cp/pt.c:25549
0x6eae12 mark_used(tree_node*, int)
../../gcc/cp/decl2.c:5610
0x80d6d2 cp_build_addr_expr_1
../../gcc/cp/typeck.c:6518
0x6664e3 build_addr_func(tree_node*, int)
../../gcc/cp/call.c:285
0x673eab build_over_call
../../gcc/cp/call.c:8763
0x675da7 build_new_function_call(tree_node*, vec**, int)
../../gcc/cp/call.c:4689
0x7b2a9a do_class_deduction
../../gcc/cp/pt.c:29323
0x7b2a9a do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/cp/pt.c:29420
0x81c535 build_functional_cast_1
../../gcc/cp/typeck2.c:2208
0x81c535 build_functional_cast(unsigned int, tree_node*, tree_node*, int)
../../gcc/cp/typeck2.c:2308
0x772977 cp_parser_functional_cast
../../gcc/cp/parser.c:30553
0x783bd2 cp_parser_postfix_expression
../../gcc/cp/parser.c:7427
0x793d35 cp_parser_unary_expression
../../gcc/cp/parser.c:8818
0x76d96f cp_parser_cast_expression
../../gcc/cp/parser.c:9722
0x76e1a2 cp_parser_binary_expression
../../gcc/cp/parser.c:9824
0x76e900 cp_parser_assignment_expression
../../gcc/cp/parser.c:10128
0x76fddd cp_parser_constant_expression
../../gcc/cp/parser.c:10424
0x76fe41 cp_parser_initializer_clause
../../gcc/cp/parser.c:24145
0x772b5b cp_parser_initializer
../../gcc/cp/parser.c:24085

[Bug fortran/99010] New: [11 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2322

[gscfq--- via Gcc-bugs]

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

Bug ID: 99010
   Summary: [11 Regression] ICE in gfc_dep_resolver, at
fortran/dependency.c:2322
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This changed recently, between 20210131 and 20210207 :


$ cat z1.f90
program p
   integer :: x[*]
   x = this_image()
   if ( this_image() == 2 ) then
  x = x[1]
   end if
end


$ gfortran-11-20210131 -c z1.f90 -fcoarray=lib
$
$ gfortran-11-20210207 -c z1.f90 -fcoarray=lib
z1.f90:5:14:

5 |   x = x[1]
  |  1
internal compiler error: in gfc_dep_resolver, at fortran/dependency.c:2322
0x72b427 gfc_dep_resolver(gfc_ref*, gfc_ref*, gfc_reverse*, bool)
../../gcc/fortran/dependency.c:2322
0x783aa8 conv_caf_send
../../gcc/fortran/trans-intrinsic.c:1952
0x78b3d5 gfc_conv_intrinsic_subroutine(gfc_code*)
../../gcc/fortran/trans-intrinsic.c:12442
0x739be2 trans_code
../../gcc/fortran/trans.c:1981
0x7a58d5 gfc_trans_if_1
../../gcc/fortran/trans-stmt.c:1475
0x7ad46a gfc_trans_if(gfc_code*)
../../gcc/fortran/trans-stmt.c:1507
0x739c87 trans_code
../../gcc/fortran/trans.c:2010
0x7602d4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6880
0x6e6c26 translate_all_program_units
../../gcc/fortran/parse.c:6351
0x6e6c26 gfc_parse_file()
../../gcc/fortran/parse.c:6620
0x732e7f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code

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

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

--- Comment #5 from H.J. Lu  ---
(In reply to Andy Lutomirski from comment #3)
> What is -fcf-protection=stack actually supposed to do as compared to

It is -fcf-protection=return.

> -fcf-protection=none?  Is it valid to run code compiled with
> -fcf-protection=none with SHSTK enabled?  If so, then I wonder why

No.  The binary will crash.

> -fcf-protection=stack exists at all.  If not, then I'm wondering why your
> patch seems to be effectively hardcoding "stack" mode for SJLJ?
> 

Correct.

[Bug c++/99009] [9/10/11 Regression] ICE in type_dependent_expression_p, at cp/pt.c:27265

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

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |9.4
   Priority|P3  |P2
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-02-08
 CC||mpolacek at gcc dot gnu.org
Summary|[11 Regression] ICE in  |[9/10/11 Regression] ICE in
   |type_dependent_expression_p |type_dependent_expression_p
   |, at cp/pt.c:27265  |, at cp/pt.c:27265

--- Comment #1 from Marek Polacek  ---
Started with r267533 so mine.

[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code

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

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

--- Comment #6 from H.J. Lu  ---
(In reply to Andy Lutomirski from comment #4)
> I should add: on brief inspection, that patch looks like an ABI break for
> -fcf-protection=none

True if __builtin_longjmp and __builtin_setjmp are compiled by different
compilers.

[Bug c++/99009] [9/10/11 Regression] ICE in type_dependent_expression_p, at cp/pt.c:27265

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

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

--- Comment #2 from Marek Polacek  ---
Not a duplicate of bug 97034 but they might be related.

[Bug middle-end/98465] [11 Regression] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert

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

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

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

Yet another libstdc++ change that makes the warning go away, but doesn't
actually change the generated code - in GIMPLE we end up with more stmts than
before but RTL optimizations once we lose distinction on what is a pointer and
what is just an offset added to it optimize those differences away.

[Bug libstdc++/37475] [DR 382] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length

[kristian.spangsege at gmail dot com via Gcc-bugs]

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

Kristian Spangsege  changed:

   What|Removed |Added

 CC||kristian.spangsege at gmail 
dot co
   ||m

--- Comment #5 from Kristian Spangsege  ---
This bug still exists in GCC 10.2, while libc++ (clang) appears to do the right
thing.

Specifically, when passing a nonzero amount of data (from_end > from) to
std::codecvt::out(), but an empty output buffer (to_end == to), the return
value is "ok". According to the C++ standard (C++17), the correct return value
is "partial".

This appears to happen regardless of locale. In particular, it happens in the C
locale.

As far as I can tell, http://cplusplus.github.io/LWG/lwg-closed.html#382 is not
relevant here, because the current standard text is clear (C++17), and
http://cplusplus.github.io/LWG/lwg-closed.html#382 has status NAD, which I
assume means "not a defect".

Jonathan, let me know if I am missing something.

[Bug c/99011] New: Potentially missed optimization. Arrays are created without need

[pj at hugeone dot co.uk via Gcc-bugs]

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

Bug ID: 99011
   Summary: Potentially missed optimization. Arrays are created
without need
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pj at hugeone dot co.uk
  Target Milestone: ---

Consider the code:

```
int bar(int N)
{
return  N > 10 ? 14 : 8;
}

int foo(int N)
{
return (const int[]){8, 14}[N > 10]; 
}


int zoo(int N)
{
int a[] = {8,14};
return a[N > 10]; 
}

int boo(int N)
{
const static int a[] = {8,14};
return a[N > 10]; 
}
```

IMO in all cases the generated code should be the same as generated for
function bar. IMO arrays can be optimized out.

Compiled with -O3

foo:
mov rax, QWORD PTR .LC0[rip]
mov QWORD PTR [rsp-8], rax
xor eax, eax
cmp edi, 10
setgal
mov eax, DWORD PTR [rsp-8+rax*4]
ret
bar:
cmp edi, 10
mov edx, 8
mov eax, 14
cmovle  eax, edx
ret
zoo:
mov rax, QWORD PTR .LC0[rip]
mov QWORD PTR [rsp-8], rax
xor eax, eax
cmp edi, 10
setgal
mov eax, DWORD PTR [rsp-8+rax*4]
ret
boo:
xor eax, eax
cmp edi, 10
setgal
mov eax, DWORD PTR a.0[0+rax*4]
ret
a.0:
.long   8
.long   14
.LC0:
.long   8
.long   14


gcc -O3 --verbose:
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-10.2.0/bin/gcc
Target: x86_64-linux-gnu
Configured with: ../gcc-10.2.0/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,go,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 10.2.0 (Compiler-Explorer-Build) 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' './output.s'
'-masm=intel' '-S' '-v' '-O3' '-mtune=generic' '-march=x86-64'

/opt/compiler-explorer/gcc-10.2.0/bin/../libexec/gcc/x86_64-linux-gnu/10.2.0/cc1
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/
 -quiet -dumpbase example.c -masm=intel -mtune=generic -march=x86-64
-auxbase-strip ./output.s -g -O3 -version -fdiagnostics-color=always -o
./output.s
GNU C17 (Compiler-Explorer-Build) version 10.2.0 (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=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/../../../../x86_64-linux-gnu/include"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/10.2.0/include"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/10.2.0/include-fixed"
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/10.2.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/include

/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/include-fixed
 /usr/local/include
 /opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/../../include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C17 (Compiler-Explorer-Build) version 10.2.0 (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=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 870fa0f1a93c5f0ff6fd5ef23d839e5a
COMPILER_PATH=/opt/compiler-explorer/gcc-10.2.0/bin/../libexec/gcc/x86_64-linux-gnu/10.2.0/:/opt/compiler-explorer/gcc-10.2.0/bin/../libexec/gcc/x86_64-linux-gnu/:/opt/compiler-explorer/gcc-10.2.0/bin/../libexec/gcc/:/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/../../../../x86_64-linux-gnu/bin/
LIBRARY_PATH=/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/:/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/:/opt/compiler-ex

[Bug c/99011] Potentially missed optimization. Arrays are created without need

[pj at hugeone dot co.uk via Gcc-bugs]

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

Piotr  changed:

   What|Removed |Added

Version|10.2.1  |10.2.0

--- Comment #1 from Piotr  ---
https://godbolt.org/z/E18djs

[Bug libgomp/99005] libgomp runtime does not support AMD GPU offloading for OpenACC directives

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

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

--- Comment #1 from Tobias Burnus  ---
(In reply to Kiril Dichev from comment #0)
> Code runs fine without GPU offloading, or with offloading with PGI compiler.

With PGI + offloading: that's for that AMD Vega machine or for some Nvidia
system?

> Sample code with single OpenACC directive in for loop

The example code just contains only a module without a main program. Hence, I
added at the end:

use mymodule
implicit none (external, type)
call init
call do_work
call terminate
end

Using that on a gfx906 Vega 20 with GCC 11.0.0 20210203 and -march=gfx906 – and
works fine.

I have now also tried it with: gcc version 10.2.1 20210206 – same result.

 * * *

Especially assuming that AMD system is not the same system as the system used
with the PGI compiler: If I look for HSA_STATUS_ERROR_OUT_OF_RESOURCES, I run
into https://github.com/RadeonOpenCompute/ROCm/issues/1080

That person did have such an error due to permission problems. I assume that it
works on your side, but just to check: Does /opt/rocm/bin/rocminfo work?

If it does, does the program as above work (your module + the lines by me to
run it)? Are there more messages? Which compiler version did you use? Is this a
Linux vendor compiler (which one?), some pre-compiled compiler or self
compiled?

[Bug c++/99000] [modules] declaration std::__copy_move_a2 conflicts with import

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2021-02-08
 Ever confirmed|0   |1

--- Comment #1 from Nathan Sidwell  ---
You're hitting this:


@emph{G++'s modules support is not complete.}  Other than bugs, the
known missing pieces are:



@item Textual merging of reachable GM entities
Entities may be multiply defined across different header-units.
These must be de-duplicated, and this is implemented across imports,
or when an import redefines a textually-defined entity.  However the
reverse is not implemented---textually redefining an entity that has
been defined in an imported header-unit.  A redefinition error is
emitted.

[Bug c++/99012] New: gcc-8.4.0 on aarch64 hits internal error during RTL pass: expand if `std::copysign` is used

[nikita.shulga at gmail dot com via Gcc-bugs]

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

Bug ID: 99012
   Summary: gcc-8.4.0 on aarch64 hits internal error during RTL
pass: expand if `std::copysign` is used
   Product: gcc
   Version: 8.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nikita.shulga at gmail dot com
  Target Milestone: ---

Created attachment 50146
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50146&action=edit
gzipped preprocessed file that hits the issue

To repro, run `g++-8 -O3 -c BinaryOpsKernel.cpp.DEFAULT.E.cpp` and it will fail
with:
```
/usr/include/c++/8/cmath: In function
‘at::native::{anonymous}::cpu_kernel(at::TensorIteratorBase&, func_t&&) [with
func_t =
at::native::{anonymous}::div_floor_kernel(at::TensorIterator&)::]’:
/usr/include/c++/8/cmath:1287:31: internal compiler error: Segmentation fault
   { return __builtin_copysignf(__x, __y); }
~~~^~
```

[Bug c++/98995] [11 Regression] Copy elision not applied to members declared with [[no_unique_address]]

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

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

Jason Merrill  changed:

   What|Removed |Added

   Last reconfirmed||2021-02-08
 Status|UNCONFIRMED |SUSPENDED
 Ever confirmed|0   |1

--- Comment #2 from Jason Merrill  ---
This was a deliberate change.  This language/ABI issue is tracked at
https://wg21.link/cwg2403 and
https://github.com/itanium-cxx-abi/cxx-abi/issues/107

The problem is that we can't safely initialize a base or
potentially-overlapping member from the result of a function call, at least
without a major ABI break, because it might clobber other data allocated into
the tail padding.

[Bug c++/98994] [11 Regression] Empty type with [[no_unique_address]] in union with constructor is not a constant expression since r11-6918

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/98979] [11 regression] ICE in several tests cases after r11-7112

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

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

--- Comment #5 from seurer at gcc dot gnu.org ---
For completeness, the new test case added for this in
g:b2d84e9f9cccbe4ee662f7002b83105629d09939, r11-7113 also fails:

make  -k check-gcc
RUNTESTFLAGS="goacc.exp=gfortran.dg/goacc/derived-chartypes-1.f90"
FAIL: gfortran.dg/goacc/derived-chartypes-1.f90   -O  (internal compiler error)
FAIL: gfortran.dg/goacc/derived-chartypes-1.f90   -O  (test for excess errors)
# of unexpected failures2

[Bug c++/98990] [10/11 Regression] ICE when two overloaded functions return `auto &&` and one accepts an `auto` parameter since r10-6571-ga6ee556c7659877b

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/99011] Potentially missed optimization. Arrays are created without need

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
  Component|c   |middle-end
   Keywords||missed-optimization

[Bug c++/98990] [10/11 Regression] ICE when two overloaded functions return `auto &&` and one accepts an `auto` parameter since r10-6571-ga6ee556c7659877b

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
(In reply to Martin Liška from comment #2)
> With -fchecking, it started with a6ee556c7659877b.

i.e. r10-6571

The problem is that splice_late_return_type is changing the TREE_TYPE of a
REFERENCE_TYPE without also updating its TYPE_CANONICAL, which breaks; we need
to rebuild the type instead.  I expect that tsubst would do the trick, as in
do_auto_deduction.  Want to take this, Patrick?

[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

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/98990] [10/11 Regression] ICE when two overloaded functions return `auto &&` and one accepts an `auto` parameter since r10-6571-ga6ee556c7659877b

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
(In reply to Jason Merrill from comment #3)
> (In reply to Martin Liška from comment #2)
> > With -fchecking, it started with a6ee556c7659877b.
> 
> i.e. r10-6571
> 
> The problem is that splice_late_return_type is changing the TREE_TYPE of a
> REFERENCE_TYPE without also updating its TYPE_CANONICAL, which breaks; we
> need to rebuild the type instead.  I expect that tsubst would do the trick,
> as in do_auto_deduction.  Want to take this, Patrick?

Ah, that makes sense.  Yes, I'll take it :)

[Bug rtl-optimization/98692] Unitialized Values reported only with -Os

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

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

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #9 from Will Schmidt  ---
(In reply to Segher Boessenkool from comment #5)
> Have you tried a new valgrind?
> 
> Either this is (or was) a known problem in valgrind, or it is related to
> one.  Cc:ing Aaron, he might know more (he wrote the GCC optimisations
> that expose the problem).


I've recreated against new (built out of upstream git) valgrind:
with --track-origins=yes


==37507== 
argv[0]=./a.out
==37507== Use of uninitialised value of size 8
==37507==at 0x1618: main (pr9862.C:16)
==37507==  Uninitialised value was created by a stack allocation
==37507==at 0x17D4: isVariable(char*) (pr9862.C:5)

[Bug c++/99012] gcc-8.4.0 on aarch64 hits internal error during RTL pass: expand if `std::copysign` is used

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2021-02-08

--- Comment #1 from ktkachov at gcc dot gnu.org ---
What GCC version are you using? (gcc -v)
I can't reproduce the ICE and it looks at first glance like it could be a
duplicate of the already-fixed PR90075

[Bug rtl-optimization/98692] Unitialized Values reported only with -Os

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

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

--- Comment #10 from Mark Wielaard  ---
(In reply to Will Schmidt from comment #9)
> (In reply to Segher Boessenkool from comment #5)
> > Have you tried a new valgrind?
> > 
> > Either this is (or was) a known problem in valgrind, or it is related to
> > one.  Cc:ing Aaron, he might know more (he wrote the GCC optimisations
> > that expose the problem).
> 
> 
> I've recreated against new (built out of upstream git) valgrind:
> with --track-origins=yes
> 
> 
> ==37507== 
> argv[0]=./a.out
> ==37507== Use of uninitialised value of size 8
> ==37507==at 0x1618: main (pr9862.C:16)
> ==37507==  Uninitialised value was created by a stack allocation
> ==37507==at 0x17D4: isVariable(char*) (pr9862.C:5)

Trying to get hold of a ppc64 setup. But could you try with --vgdb-error=0 and
then (in another window) gdb ./a.out and target remote | vgdb and continue till
you get the TRAP. Then disassamble so we can see the exact instruction that
generates the use of uninitialised value?

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #30 from Mikael Pettersson  ---
Patch has been posted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564990.html

[Bug libgomp/99005] libgomp runtime does not support AMD GPU offloading for OpenACC directives

[kd486 at cam dot ac.uk via Gcc-bugs]

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

--- Comment #2 from Kiril Dichev  ---
Yes, I can confirm that there seems to be an underlying issue with permissions,
similar to the link you posted (rocminfo gives me the same error).

Indeed, I was referring to compilation with PGI on an Nvidia system.

Looks like this is not a bug. Sorry.

[Bug c++/99012] gcc-8.4.0 on aarch64 hits internal error during RTL pass: expand if `std::copysign` is used

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

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

Sebastian Pop  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #2 from Sebastian Pop  ---
I see the bug with

$ gcc-8 --version
gcc-8 (Ubuntu/Linaro 8.4.0-1ubuntu1~18.04) 8.4.0

[Bug rtl-optimization/98692] Unitialized Values reported only with -Os

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

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

--- Comment #11 from Will Schmidt  ---
(In reply to Mark Wielaard from comment #10)
> (In reply to Will Schmidt from comment #9)
> > (In reply to Segher Boessenkool from comment #5)
> > > Have you tried a new valgrind?
> > > 
> > > Either this is (or was) a known problem in valgrind, or it is related to
> > > one.  Cc:ing Aaron, he might know more (he wrote the GCC optimisations
> > > that expose the problem).
> > 
> > 
> > I've recreated against new (built out of upstream git) valgrind:
> > with --track-origins=yes
> > 
> > 
> > ==37507== 
> > argv[0]=./a.out
> > ==37507== Use of uninitialised value of size 8
> > ==37507==at 0x1618: main (pr9862.C:16)
> > ==37507==  Uninitialised value was created by a stack allocation
> > ==37507==at 0x17D4: isVariable(char*) (pr9862.C:5)
> 
> Trying to get hold of a ppc64 setup. But could you try with --vgdb-error=0
> and then (in another window) gdb ./a.out and target remote | vgdb and
> continue till you get the TRAP. Then disassamble so we can see the exact
> instruction that generates the use of uninitialised value?

Yes.  so this traps on a ld instruction upon the return from the isVariable
call.  As seen below here:


Window #1:
==79608== 
argv[0]=./a.out
==79608== Use of uninitialised value of size 8
==79608==at 0x1618: main (pr9862.C:16)
==79608==  Uninitialised value was created by a stack allocation
==79608==at 0x17D4: isVariable(char*) (pr9862.C:5)
==79608== 
==79608== (action on error) vgdb me ... 

Window #2:
(gdb) target remote | vgdb
Remote debugging using | vgdb
relaying data between gdb and process 79608
warning: remote target does not support file transfer, attempting to access
files from local filesystem.
Reading symbols from /lib64/ld64.so.2...
(No debugging symbols found in /lib64/ld64.so.2)
0x04001720 in ?? () from /lib64/ld64.so.2
(gdb) 
(gdb) set disassemble-next-line on 
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
main (argc=, argv=0x1fff00e8a8) at pr9862.C:16
16len = __builtin_strlen (argv[1]);
=> 0x1618 :   08 00 7f e8 ld 
r3,8(r31)
   0x161c :   a5 ff ff 4b bl 
0x15c0 <0037.plt_call.strlen@@GLIBC_2.17>
   0x1620 :   18 00 41 e8 ld 
r2,24(r1)
   0x1624 :   00 00 00 60 nop
   0x1628 :   70 00 21 38 addi   
r1,r1,112
   0x162c :   50 81 62 90 stw
r3,-32432(r2)

(gdb) disas
Dump of assembler code for function main(int, char**):
   0x15e0 <+0>: lis r2,4098
   0x15e4 <+4>: addir2,r2,32512
   0x15e8 <+8>: mflrr0
   0x15ec <+12>:std r31,-8(r1)
   0x15f0 <+16>:addis   r3,r2,-2
   0x15f4 <+20>:mr  r31,r4
   0x15f8 <+24>:addir3,r3,-29882
   0x15fc <+28>:std r0,16(r1)
   0x1600 <+32>:stdur1,-112(r1)
   0x1604 <+36>:ld  r4,0(r4)
   0x1608 <+40>:bl  0x1580
<0037.plt_call.printf@@GLIBC_2.17>
   0x160c <+44>:ld  r2,24(r1)
   0x1610 <+48>:ld  r3,0(r31)
   0x1614 <+52>:bl  0x17c4 
=> 0x1618 <+56>:ld  r3,8(r31)
   0x161c <+60>:bl  0x15c0
<0037.plt_call.strlen@@GLIBC_2.17>
   0x1620 <+64>:ld  r2,24(r1)
   0x1624 <+68>:nop
   0x1628 <+72>:addir1,r1,112
   0x162c <+76>:stw r3,-32432(r2)
   0x1630 <+80>:li  r3,0
   0x1634 <+84>:b   0x198c <_restgpr0_31>
   0x1638 <+88>:.long 0x0
   0x163c <+92>:.long 0x1000900
   0x1640 <+96>:.long 0x180
End of assembler dump.
(gdb)  




WIndow#1:

[Bug c++/99012] gcc-8.4.0 on aarch64 hits internal error during RTL pass: expand if `std::copysign` is used

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

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

--- Comment #3 from Sebastian Pop  ---
I do not see the bug with today's cc1plus from origin/releases/gcc-8