[Bug c++/94957] Compilation slowww for simple code with -O1/2/3 and -g in GCC 8 and 9

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Plenty of dups for this in bugzilla - but FE folks never get that idea of using
a loop ...

[Bug c++/94781] version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.

[ishikawa at yk dot rim.or.jp]

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

--- Comment #7 from ishikawa,chiaki  ---
(In reply to Martin Liška from comment #6)
> (In reply to ishikawa,chiaki from comment #3)
> > https://send.firefox.com/download/bdf77223953903fa/#WMrJbMYdsL7AXf2vXYm82g
> > 
> > I uploaded the file, UnifiedBindings23-v7.cpp, to the link above.
> > 
> 
> Sorry, the link has expired. Can you please re-upload it?

Thank you for your attention on this matter.

I have re-upload it now.

https://send.firefox.com/download/496fe37075c2429f/#izMu3peg8oBwFQhg1RXuLQ


If we can make "phase last asm" elapsed time as short as v7, the total build
time of thunderbird mailer would be shorter, I suppose.

TIA

[Bug c++/94960] extern template prevents inlining of standard library objects

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
  Component|libstdc++   |c++

--- Comment #4 from Richard Biener  ---
I guess the C++ FE could honor -finline-functions and consider all functions
having the 'inline' hint in that case.  I'm not sure how wide-spread
explicit instantiations are and what compile-time (and size?) hit we get
when doing the instantiations always.

That is, is the middle-end smart enough to not emit out-of-line instances
for the inline instantiated extern template parts?  Off the top of my head
I'm not aware of any middle-end flagging of this?

[Bug bootstrap/94961] [11 regression] internal compiler error: in df_refs_verify, at df-scan.c:4002

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Target Milestone|--- |11.0

[Bug c++/94957] Compilation slowww for simple code with -O1/2/3 and -g in GCC 8 and 9

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Some of it changed recently, e.g. when the FEs use ARRAY_RANGE_REFs in the
initializer the gimplifier's gimplify_init_ctor_eval emits a loop.
But in this case I think we need the FE to emit the loop itself.
Marek, would you like to have a look?
I'd use serial code if the array doesn't have too many elts (perhaps compare to
a param, or hardcode something small like 16).

[Bug c++/94781] version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.

[ishikawa at yk dot rim.or.jp]

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

--- Comment #8 from ishikawa,chiaki  ---
(In reply to ishikawa,chiaki from comment #7)
> (In reply to Martin Liška from comment #6)
> > (In reply to ishikawa,chiaki from comment #3)
> > > https://send.firefox.com/download/bdf77223953903fa/#WMrJbMYdsL7AXf2vXYm82g
> > > 
> > > I uploaded the file, UnifiedBindings23-v7.cpp, to the link above.
> > > 
> > 
> > Sorry, the link has expired. Can you please re-upload it?
> 
> Thank you for your attention on this matter.
> 
> I have re-upload it now.
> 
> https://send.firefox.com/download/496fe37075c2429f/#izMu3peg8oBwFQhg1RXuLQ
> 
> 
> If we can make "phase last asm" elapsed time as short as v7, the total build
> time of thunderbird mailer would be shorter, I suppose.
> 
> TIA

Sorry I did not set the expiration condition properly.:

https://send.firefox.com/download/c1e1bef0d9c360a6/#TWmiEAGr3zFfRIEDAcOsIQ

The above link should work for one week or 20 downloads, which ever comes
first.

TIA

[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-127-gf14848aea70066777faf201c0b6eb3c5520bfab9
Author: Jakub Jelinek 
Date:   Wed May 6 09:31:19 2020 +0200

combine: Don't replace SET_SRC with REG_EQUAL note content if SET_SRC has
side-effects [PR94873]

There were some discussions about whether REG_EQUAL notes are valid on
insns with a single
set which contains auto-inc-dec side-effects in the SET_SRC and the
majority thinks that
it should be valid.  So, this patch fixes the combiner to punt in that
case, because otherwise
the auto-inc-dec side-effects from the SET_SRC are lost.

2020-05-06  Jakub Jelinek  

PR rtl-optimization/94873
* combine.c (combine_instructions): Don't optimize using REG_EQUAL
note if SET_SRC (set) has side-effects.

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

[Bug tree-optimization/94963] [11 Regression] Spurious uninitialized warning for static variable building glibc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-06
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |11.0

--- Comment #1 from Richard Biener  ---
Confirmed.  I've met the underlying issue when developing the patch and for
this reason marked the conditional store inserted by LIM with no-warning.
But for the testcase that's not enough since now PRE comes along and
optimizes the var.field load away, re-exposing the issue.

LIM transforms the testcase to (simplified a bit)

void
f (void)
{
  if (pv != 0)
{
  bool v2_set = false;
  bool varfield_set = false;
  int v2tem, varfield_tem;
for (const P *ph = pv; ph < &pv[ps]; ++ph)
  switch (ph->p1)
{
case 1:
  v2tem = ph->p2;
  v2_set = true;
  break;
case 2:
  varfield_tem = ph->p3;
  varfield_set = true;
  break;
}
  if (varfield_set)
var.field = varfield_tem;
  if (v2_set)
v2 = v2tem;
 }
  if (var.field != 0)
foo (&var);
}

where the uninit predicate analysis doesn't grok the relation between
varfield_set and varfield_tem being initialized.

The patch changed code generation to elide the previously emitted
unconditional load of v2 and var.field.  I suspected that for
the case where there is no load the loop PHI for varfield_tem
might be eliminated, but it is not in all cases it seems.  Now
apart from marking the store no-warning we could easily initialize
the tems on loop entry, just not with their true value but for example
with zero.  That might result in less optimal out-of-SSA though
(no coalescing with constants, the constant move needs to be emitted...)
at least when the loop PHI is not eliminated.

What works is initializing with an uninitialized variable marked
TREE_NO_WARNING.  I'm going to test that (eliding the no-warning
on the conditional stores).

[Bug target/94950] [8/9/10/11 regression] ICE in gcc.dg/pr94780.c on riscv64

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-128-gb4ace720e004f736f1ee46b374c12f9826aad630
Author: Jakub Jelinek 
Date:   Wed May 6 09:40:33 2020 +0200

riscv: Fix up riscv_atomic_assign_expand_fenv [PR94950]

Similarly to the fixes on many other targets, riscv needs to use
TARGET_EXPR
to avoid having the create_tmp_var_raw temporaries without proper
DECL_CONTEXT
and not mentioned in local decls.

2020-05-06  Jakub Jelinek  

PR target/94950
* config/riscv/riscv-builtins.c (riscv_atomic_assign_expand_fenv):
Use
TARGET_EXPR instead of MODIFY_EXPR for first assignment to
old_flags.

[Bug tree-optimization/94964] New: [8/9/10/11 Regression] ICE in add_phi_arg, at tree-phinodes.c:359 since r8-2993-ga7976089dba5e227

[marxin at gcc dot gnu.org]

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

Bug ID: 94964
   Summary: [8/9/10/11 Regression] ICE in add_phi_arg, at
tree-phinodes.c:359 since r8-2993-ga7976089dba5e227
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

Quite old issue:

$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.robertl/eh990323-5.C
-fno-tree-sink -fno-guess-branch-probability -fno-tree-ch
-finline-small-functions -O1 --param=early-inlining-insns=100
-fpredictive-commoning -c
during GIMPLE pass: pcom
/home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.robertl/eh990323-5.C:
In function ‘void f()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.robertl/eh990323-5.C:41:6:
internal compiler error: in add_phi_arg, at tree-phinodes.c:359
   41 | void f()
  |  ^
0x7eb110 add_phi_arg(gphi*, tree_node*, edge_def*, unsigned int)
/home/marxin/Programming/gcc/gcc/tree-phinodes.c:359
0x1162f37 initialize_root_vars_lm
/home/marxin/Programming/gcc/gcc/tree-predcom.c:1969
0x1162f37 execute_load_motion
/home/marxin/Programming/gcc/gcc/tree-predcom.c:2001
0x1162f37 execute_pred_commoning
/home/marxin/Programming/gcc/gcc/tree-predcom.c:2265
0x11654f2 tree_predictive_commoning_loop
/home/marxin/Programming/gcc/gcc/tree-predcom.c:3308
0x11654f2 tree_predictive_commoning()
/home/marxin/Programming/gcc/gcc/tree-predcom.c:
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/94964] [8/9/10/11 Regression] ICE in add_phi_arg, at tree-phinodes.c:359 since r8-2993-ga7976089dba5e227

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.4.0
  Known to fail||11.0, 8.3.0
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-06

[Bug bootstrap/94961] [11 regression] internal compiler error: in df_refs_verify, at df-scan.c:4002

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Keywords||needs-bisection,
   ||needs-reduction
   Last reconfirmed||2020-05-06
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, I'm gonna bisect that.

[Bug tree-optimization/94963] [11 Regression] Spurious uninitialized warning for static variable building glibc

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Created attachment 48459
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48459&action=edit
patch in testing

Testing the attached.

[Bug tree-optimization/94442] [10/11 regression] Redundant loads/stores emitted at -O3

[xiezhiheng at huawei dot com]

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

--- Comment #4 from xiezhiheng at huawei dot com ---
(In reply to Richard Biener from comment #3)
> So I wonder why
> 
>   a$vect_s8$0_4 = MEM[(const struct __m256i &)output_5(D) + 32].vect_s8[0];  
> 
> necessarily emits two RTL insns.  It's likely because get_inner_reference
> will not see through MEM[output_5(D) + 32] but records an extra offset
> from the component-ref which we fail to fold into the MEM generated by
> expansion of the MEM base.

Indeed, get_inner_reference only handles the decl for MEM[&decl, off]
  case MEM_REF:
/* Hand back the decl for MEM[&decl, off].  */
if (TREE_CODE (TREE_OPERAND (exp, 0)) == ADDR_EXPR)
  {
tree off = TREE_OPERAND (exp, 1);
if (!integer_zerop (off))
  {
poly_offset_int boff = mem_ref_offset (exp);
boff <<= LOG2_BITS_PER_UNIT;
bit_offset += boff;
  }
exp = TREE_OPERAND (TREE_OPERAND (exp, 0), 0);
  }
goto done;

In
  MEM[(const struct __m256i &)output_5(D) + 32].vect_s8[0];
output_5 is a SSA_NAME.
So maybe we could expand to handle the situation like MEM[decl, off]

[Bug tree-optimization/94964] [8/9/10/11 Regression] ICE in add_phi_arg, at tree-phinodes.c:359 since r8-2993-ga7976089dba5e227

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Target Milestone|--- |8.5
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
Mine.  The loop does not have a preheader we can sink to so
gsi_insert_seq_on_edge_immediate will split the edge and the following
add_phi_arg breaks.

Now, the loop entry edge is an EH edge in this case, will dig what
the appropriate solution is.

[Bug middle-end/4210] should not warn in dead code

[nisse at lysator dot liu.se]

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

--- Comment #38 from Niels Möller  ---
Just a brief update.

1. Tried adding fprintf warnings to c_gimplify_expr (btw, what's the right way
to display a pretty warning with line numbers etc in later passes?). But it
seems that's too early, I still get warnings for dead code.

2. The pass_remove_useless_stmts, mentioned in the docs, was deleted in 2009
(see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41573), and I take it it was
obsoleted earlier, since there's no mention of a replacement. So what pass
should I look at that is related to basic control flow analysis, and discarding
unreachable statements?

[Bug other/89394] libiberty :stack overflow in nm

[trupti_pardeshi at persistent dot co.in]

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

Trupti Pardeshi  changed:

   What|Removed |Added

 CC||trupti_pardeshi@persistent.
   ||co.in

--- Comment #9 from Trupti Pardeshi  
---
May I know, in which version of binutils this fix is available?

Any heads up will be appreciated.

Best Regards,

[Bug tree-optimization/94965] [11 Regression] ICE during SLP since r11-59-g308bc496884706af4b3077171cbac684c7a6f7c6

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-06
  Known to fail||11.0
   Target Milestone|--- |11.0
   Priority|P3  |P1
  Known to work||10.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug tree-optimization/94965] New: [11 Regression] ICE during SLP since r11-59-g308bc496884706af4b3077171cbac684c7a6f7c6

[marxin at gcc dot gnu.org]

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

Bug ID: 94965
   Summary: [11 Regression] ICE during SLP since
r11-59-g308bc496884706af4b3077171cbac684c7a6f7c6
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu

I see the following ICE:

$ /dev/shm/gcc-objdir-bisect/gcc/xgcc -B/dev/shm/gcc-objdir-bisect/gcc
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/aliasing_dummy_4.f90
--param=scev-max-expr-size=0 -mno-vsx -O3 -c
during GIMPLE pass: slp
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/aliasing_dummy_4.f90:8:0:

8 | program  test_f90
  | 
internal compiler error: Segmentation fault
0x778fef1f ???
   
/usr/src/debug/glibc-2.31-4.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x778e9cea __libc_start_main
../csu/libc-start.c:308
0x8fdf59 ???
../sysdeps/x86_64/start.S:120

[Bug tree-optimization/94965] [11 Regression] ICE during SLP since r11-59-g308bc496884706af4b3077171cbac684c7a6f7c6

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Huh.  mine.

[Bug fortran/94943] [10 Regression] A module does not export allocatable attribute of herein arrays.

[artu72 at gmail dot com]

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

--- Comment #3 from Andrea Mastellone  ---
Created attachment 48460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48460&action=edit
simple test case which reproduces the bug

Here is a simple source code replying the bug. I have attached the original
module, used by the main procedure. Compiling it (by issuing make debug or make
release) produces the error.

[Bug c/94966] New: [10 regression] internal compiler error: tree check: expected function_type or method_type, have integer_type in gimplify_call_expr, at gimplify.c:3433

[anbu1024.me at gmail dot com]

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

Bug ID: 94966
   Summary: [10 regression] internal compiler error: tree check:
expected function_type or method_type, have
integer_type in gimplify_call_expr, at gimplify.c:3433
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat test.c 

extern void (*x) () ; 

void foo() 
{ 
x(); 
} 

char x [] = { foo };



$ gcc-10 --version
gcc (GCC) 10.0.1 20200419 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc-10 test.c 
test.c:9:6: error: conflicting types for ‘x’
9 | char x [] = { foo };
  |  ^
test.c:2:15: note: previous declaration of ‘x’ was here
2 | extern void (*x) () ;
  |   ^
test.c:9:15: warning: initialization of ‘char’ from ‘void (*)()’ makes integer
from pointer without a cast
[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wint-conversion-Wint-conversion]8;;]
9 | char x [] = { foo };
  |   ^~~
test.c:9:15: note: (near initialization for ‘x[0]’)
test.c:9:15: error: initializer element is not computable at load time
test.c:9:15: note: (near initialization for ‘x[0]’)
test.c: In function ‘foo’:
test.c:6:2: internal compiler error: tree check: expected function_type or
method_type, have integer_type in gimplify_call_expr, at gimplify.c:3433
6 |  x();
  |  ^~~
0x731ae0 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-10-20200419/gcc/tree.c:9727
0x677c3f tree_check2(tree_node*, char const*, int, char const*, tree_code,
tree_code)
../../gcc-10-20200419/gcc/tree.h:3306
0x677c3f gimplify_call_expr
../../gcc-10-20200419/gcc/gimplify.c:3433
0xafe096 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-10-20200419/gcc/gimplify.c:13580
0xb00bd6 gimplify_stmt(tree_node**, gimple**)
../../gcc-10-20200419/gcc/gimplify.c:6825
0xb0199b gimplify_bind_expr
../../gcc-10-20200419/gcc/gimplify.c:1424
0xafe0b3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-10-20200419/gcc/gimplify.c:13809
0xb15927 gimplify_stmt(tree_node**, gimple**)
../../gcc-10-20200419/gcc/gimplify.c:6825
0xb15927 gimplify_body(tree_node*, bool)
../../gcc-10-20200419/gcc/gimplify.c:14857
0xb15e53 gimplify_function_tree(tree_node*)
../../gcc-10-20200419/gcc/gimplify.c:15030
0x9607d7 cgraph_node::analyze()
../../gcc-10-20200419/gcc/cgraphunit.c:670
0x9633f7 analyze_functions
../../gcc-10-20200419/gcc/cgraphunit.c:1227
0x963fc2 symbol_table::finalize_compilation_unit()
../../gcc-10-20200419/gcc/cgraphunit.c:2974
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



$ gcc-9 --version
gcc (GCC) 9.3.1 20200425
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc-9 test.c 
test.c:9:6: error: conflicting types for ‘x’
9 | char x [] = { foo };
  |  ^
test.c:2:15: note: previous declaration of ‘x’ was here
2 | extern void (*x) () ;
  |   ^
test.c:9:15: warning: initialization of ‘char’ from ‘void (*)()’ makes integer
from pointer without a cast [-Wint-conversion]
9 | char x [] = { foo };
  |   ^~~
test.c:9:15: note: (near initialization for ‘x[0]’)
test.c:9:15: error: initializer element is not computable at load time
test.c:9:15: note: (near initialization for ‘x[0]’)
test.c:6: confused by earlier errors, bailing out

[Bug tree-optimization/94965] [11 Regression] ICE during SLP since r11-59-g308bc496884706af4b3077171cbac684c7a6f7c6

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
@@ -9319,7 +9364,8 @@ vectorizable_load (stmt_vec_info stmt_info,
gimple_stmt_it
erator *gsi,
 initialized yet, use first_stmt_info_for_drptr DR by bumping the
 distance from first_stmt_info DR instead as below.  */
   if (!diff_first_stmt_info)
-   msq = vect_setup_realignment (first_stmt_info, gsi, &realignment_token,
+   msq = vect_setup_realignment (loop_vinfo,
+ first_stmt_info, gsi, &realignment_token,
  alignment_support_scheme, NULL_TREE,
  &at_loop);
   if (alignment_support_scheme == dr_explicit_realign_optimized)

that should have been 'vinfo', not 'loop_vinfo'.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[kretz at kde dot org]

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

Matthias Kretz (Vir)  changed:

   What|Removed |Added

 CC||kretz at kde dot org

--- Comment #21 from Matthias Kretz (Vir)  ---
Is it possible to insert a predicated warning-marker into the tree in the front
end? Basically "if signed object can be negative, emit OPT_Wsign_compare
warning". It could even strengthen the message if it detects that the signed
object is guaranteed to be negative.

Then the middle end can either drop the warning from the tree or emit it as
suggested by the front end.

Test case, showing that simply predicating the warning with `if (x < 0)` works:
https://godbolt.org/z/iFePwJ. However, -O2 would still show the warning.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[kretz at kde dot org]

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

--- Comment #22 from Matthias Kretz (Vir)  ---
(In reply to Matthias Kretz (Vir) from comment #21)
> However, -O2 would still show the warning.

I meant -O0 of course.

[Bug c++/94967] New: std::get<0>(tuple const &&) returns wrong type

[rene.r...@fu-berlin.de]

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

Bug ID: 94967
   Summary: std::get<0>(tuple const &&) returns wrong type
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rene.r...@fu-berlin.de
  Target Milestone: ---

Hi GCC Team,

i couldn't find anything in the advanced search about this but I was wondering
if this is not reported already.
According to the tuple get implementation, the return type of get over a `const
&& tuple` should also be `const &&`. But this fails with gcc 7 but works with
gcc-8,9 and 10.

Here is the link to godbolt: https://godbolt.org/z/akae2V

And this is the offending line that fails
```
#include 

static_assert(std::is_same(std::declval
const &&>())), int const &&>::value);
```

Thank you very much for your support.

[Bug c++/94946] [10/11 Regression] error: ‘template JSC::FunctionPtr::FunctionPtr(returnType (*)())’ cannot be overloaded since r10-7998-g5f1cd1da1a805c3d

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Can please anybody take a look before we'll make 10.1 release?

[Bug c/94968] New: [10 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87

[anbu1024.me at gmail dot com]

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

Bug ID: 94968
   Summary: [10 Regression] internal compiler error: tree check:
expected class ‘type’, have ‘exceptional’ (error_mark)
in useless_type_conversion_p, at gimple-expr.c:87
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat test.c 

int foo() { 
__builtin_speculation_safe_value ( 1 , x );
}



$ gcc-10 --version
gcc (GCC) 10.0.1 20200419 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc-10 test.c 
test.c: In function ‘foo’:
test.c:3:41: error: ‘x’ undeclared (first use in this function)
3 |  __builtin_speculation_safe_value ( 1 , x );
  | ^
test.c:3:41: note: each undeclared identifier is reported only once for each
function it appears in
test.c:3:2: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87
3 |  __builtin_speculation_safe_value ( 1 , x );
  |  ^~~~
0x731f2f tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-10-20200419/gcc/tree.c:9777
0x665cf0 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-10-20200419/gcc/tree.h:3410
0x665cf0 useless_type_conversion_p(tree_node*, tree_node*)
../../gcc-10-20200419/gcc/gimple-expr.c:87
0x8919e4 speculation_safe_value_resolve_params
../../gcc-10-20200419/gcc/c-family/c-common.c:6720
0x8919e4 resolve_overloaded_builtin(unsigned int, tree_node*, vec*)
../../gcc-10-20200419/gcc/c-family/c-common.c:7407
0x81a6c9 c_build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
../../gcc-10-20200419/gcc/c/c-typeck.c:3199
0x838cde c_parser_postfix_expression_after_primary
../../gcc-10-20200419/gcc/c/c-parser.c:10501
0x8307a1 c_parser_postfix_expression
../../gcc-10-20200419/gcc/c/c-parser.c:10176
0x834ada c_parser_unary_expression
../../gcc-10-20200419/gcc/c/c-parser.c:8273
0x83632d c_parser_cast_expression
../../gcc-10-20200419/gcc/c/c-parser.c:8115
0x8365b9 c_parser_binary_expression
../../gcc-10-20200419/gcc/c/c-parser.c:7918
0x837595 c_parser_conditional_expression
../../gcc-10-20200419/gcc/c/c-parser.c:7652
0x837bb0 c_parser_expr_no_commas
../../gcc-10-20200419/gcc/c/c-parser.c:7569
0x837e11 c_parser_expression
../../gcc-10-20200419/gcc/c/c-parser.c:10637
0x8385b7 c_parser_expression_conv
../../gcc-10-20200419/gcc/c/c-parser.c:10670
0x82dd0b c_parser_statement_after_labels
../../gcc-10-20200419/gcc/c/c-parser.c:6301
0x82ff71 c_parser_compound_statement_nostart
../../gcc-10-20200419/gcc/c/c-parser.c:5805
0x84c8c4 c_parser_compound_statement
../../gcc-10-20200419/gcc/c/c-parser.c:5617
0x84e381 c_parser_declaration_or_fndef
../../gcc-10-20200419/gcc/c/c-parser.c:2505
0x8566e3 c_parser_external_declaration
../../gcc-10-20200419/gcc/c/c-parser.c:1745
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



$ gcc-9 --version
gcc (GCC) 9.3.1 20200425
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc-9 test.c 
test.c: In function ‘foo’:
test.c:3:41: error: ‘x’ undeclared (first use in this function)
3 |  __builtin_speculation_safe_value ( 1 , x );
  | ^
test.c:3:41: note: each undeclared identifier is reported only once for each
function it appears in
test.c:3:2: error: both arguments must be compatible
3 |  __builtin_speculation_safe_value ( 1 , x );
  |  ^~~~

[Bug c++/94781] version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Thanks.
I've made a more permanent link here:
https://drive.google.com/file/d/1s9i_l68CR8UGhqPfq0pdgQTH26G7YEFW/view?usp=sharing

I get these numbers for g++ UnifiedBindings23-v7.cpp -c -std=c++17 -O2
-fno-checking -fmax-errors=1 -Wno-invalid-offsetof:

  7.4.0 (adafdb1e7212d53a)(06 Dec 2018 10:00): [took: 68.766s] result: OK
  7.5.0 (b2d961e7342b5ba4)(14 Nov 2019 07:40): [took: 68.694s] result: OK
  8.1.0 (406c2abec3f998e9)(02 May 2018 10:13): [took: 73.308s] result: OK
  8.2.0 (ddeb81e76461fc00)(26 Jul 2018 09:47): [took: 72.738s] result: OK
  8.3.0 (4c44b708f11eec6f)(22 Feb 2019 14:20): [took: 72.058s] result: OK
  8.4.0 (8cd3bffead2ed1d1)(04 Mar 2020 08:30): [took: 71.730s] result: OK
  9.1.0 (c8913260b0756f97)(03 May 2019 07:59): [took: 77.404s] result: OK
  9.2.0 (a0c06cc27d2146b7)(12 Aug 2019 09:38): [took: 76.432s] result: OK
  9.3.0 (4212a6a3e44f8704)(12 Mar 2020 11:08): [took: 76.636s] result: OK

current master:
  438085cc66ed5801(05 May 2020 12:24)(Michael Meissner meiss...@linux.ibm.com):
[took: 78.698s] result: OK

Which is a regression of ~12% and one can't point to a single point where it
jumped rapidly. Note that we do more inlining and more optimizations in
general.

[Bug c/94966] ICE: tree check: expected function_type or method_type, have integer_type in gimplify_call_expr, at gimplify.c:3433

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Old issue (at least GCC 5.1.0+).

[Bug tree-optimization/94965] [11 Regression] ICE during SLP since r11-59-g308bc496884706af4b3077171cbac684c7a6f7c6

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:380a681518c3b387476be1064097f24b0847726d

commit r11-131-g380a681518c3b387476be1064097f24b0847726d
Author: Richard Biener 
Date:   Wed May 6 10:46:22 2020 +0200

tree-optimization/94965 - fix typo in vec_info * passing

Should have passed vinfo, not loop_vinfo.

2020-05-06  Richard Biener  

PR tree-optimization/94965
* tree-vect-stmts.c (vectorizable_load): Fix typo.

[Bug tree-optimization/94965] [11 Regression] ICE during SLP since r11-59-g308bc496884706af4b3077171cbac684c7a6f7c6

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/94960] extern template prevents inlining of standard library objects

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Erich Keane from comment #3)
> As you know, "extern template" is a hint to the compiler that we don't need
> to emit the template as a way to save on compile time.
> 
> Both GCC and clang will NOT instantiate these templates in O0 mode. 
> However, in O1+ modes, both will actually still instantiate the templates in
> the frontend, BUT only for 'inline' functions.  Basically, we're using
> 'inline' as a heuristic that there is benefit in sending these functions to
> the optimizer (basically, sacrificing the compile time gained by 'extern
> template' in exchange for a better inlining experience).

Hmm, I've seen different behaviours for clang and g++ in this respect, with
clang inlining a lot more of std::string's members. So I'm surprised they use
the same heuristic.

Do they both instantiate the function templates marked 'inline' even at -O1?
Presumably not at -O0.

> In the submitter's case, the std::string constructor calls "_M_construct". 
> The constructor is inlined, but _M_construct is not, since it never gets to
> the optimizer.
> 
> libc++ uses an __init function to do the same thing as _M_construct, however
> IT is marked inline, and thus doesn't have the problem.
> 
> I believe the submitter wants to have you mark more of the functions in
> extern-templated classes 'inline' so that it matches the heuristic better.

And that's what I don't want to do. I think it's wrong for the human to say
"inline this!" because humans are stupid (well, I am anyway). And I don't want
to have to examine the GIMPLE/asm again for every new GCC release to decide
whether 'inline' is still in the right places (and whether the answer should be
different for every different version of Clang or ICC!)

And when I say "I don't want to" I mean "I am never ever going to".

> I don't think that there is a good way to change the compiler itself without
> making 'extern template' absolutely meaningless.

I absolutely disagree.

It would still give a reduction in object file size for cases where the
compiler decides not to inline, and still make compilation much faster for -O0
and -O1.

One property of -O2 and -O3 is that we try to optimize aggressively even if
that takes a long time to compile. So we could instantiate things that have an
explicit instantiation declaration (thus doing "redundant" work) to see if
inlining them would be beneficial. That would take longer to compile, but might
produce faster code. If the heuristics decide the instantiation ends up too big
to inline, it could just discard it (because we know there's a definition
elsewhere).

If the only way to get that is to mark every function as 'inline' (and then
"trick" the compiler into doing all that extra work even at -O1?) then we might
as well add 'inline' to every single function template in  and
, ,  etc. so they're all potential candiates for
inlining.

And if we have to mark every single function as 'inline' then maybe the
compiler shouldn't be using it as a hint.

[Bug tree-optimization/94969] New: Invalid loop distribution

[krebbel at gcc dot gnu.org]

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

Bug ID: 94969
   Summary: Invalid loop distribution
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

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

The attached testcase aborts on x86 when compiled with -O3. It succeeds with
-O2 or -O3 -fno-loop-distribution.

The loop is distributed separating the two statements. This affects the result
of the testcase.

 for (; c <= 1; c++) {
f[b] = g;
f[b].e ^= 1;
  }

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
You are right, the documentation is not complete.
Btw. are you parsing a .gcda or .gcna format for some reason?

[Bug tree-optimization/94969] Invalid loop distribution

[krebbel at gcc dot gnu.org]

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

--- Comment #1 from Andreas Krebbel  ---
The problem arises from dr_analyze_innermost not being able to analyze the
bitfield access. However, the returned error is ignored in
find_data_references_in_stmt and execution continues with bogus values in the
data reference object.

[Bug c++/94781] version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.

[ishikawa at yk dot rim.or.jp]

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

--- Comment #10 from ishikawa,chiaki  ---
(In reply to Martin Liška from comment #9)
> Thanks.
> I've made a more permanent link here:
> https://drive.google.com/file/d/1s9i_l68CR8UGhqPfq0pdgQTH26G7YEFW/
> view?usp=sharing
> 
> I get these numbers for g++ UnifiedBindings23-v7.cpp -c -std=c++17 -O2
> -fno-checking -fmax-errors=1 -Wno-invalid-offsetof:
> 
>   7.4.0 (adafdb1e7212d53a)(06 Dec 2018 10:00): [took: 68.766s] result: OK
>   7.5.0 (b2d961e7342b5ba4)(14 Nov 2019 07:40): [took: 68.694s] result: OK
>   8.1.0 (406c2abec3f998e9)(02 May 2018 10:13): [took: 73.308s] result: OK
>   8.2.0 (ddeb81e76461fc00)(26 Jul 2018 09:47): [took: 72.738s] result: OK
>   8.3.0 (4c44b708f11eec6f)(22 Feb 2019 14:20): [took: 72.058s] result: OK
>   8.4.0 (8cd3bffead2ed1d1)(04 Mar 2020 08:30): [took: 71.730s] result: OK
>   9.1.0 (c8913260b0756f97)(03 May 2019 07:59): [took: 77.404s] result: OK
>   9.2.0 (a0c06cc27d2146b7)(12 Aug 2019 09:38): [took: 76.432s] result: OK
>   9.3.0 (4212a6a3e44f8704)(12 Mar 2020 11:08): [took: 76.636s] result: OK
> 
> current master:
>   438085cc66ed5801(05 May 2020 12:24)(Michael Meissner
> meiss...@linux.ibm.com): [took: 78.698s] result: OK
> 
> Which is a regression of ~12% and one can't point to a single point where it
> jumped rapidly. Note that we do more inlining and more optimizations in
> general.

I will try to see if assigning more CPU cores to VirtualBox image I am using
locally can improve the situation. I am not sure how CPU cache is handled in
such a setting, but there may be some improvement.

Thank you again for your attention on this matter. I have been using GCC for
quite a long time on workstations and embedded systems. Thank you for making
the great package available to the wide developer community.

Chiaki

[Bug tree-optimization/94921] Failure to optimize nots with sub into single add

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-132-ga7b76d574b19190da190a60c065f347f40bab59e
Author: Jakub Jelinek 
Date:   Wed May 6 11:20:20 2020 +0200

match.pd: Optimize ~(~X +- Y) into (X -+ Y) [PR94921]

According to my verification proglet, this transformation for signed types
with undefined overflow doesn't introduce nor remove any UB cases, so
should
be valid even for signed integral types.
Not using a for because of the :c on plus which can't be there on minus.

2020-05-06  Jakub Jelinek  

PR tree-optimization/94921
* match.pd (~(~X - Y) -> X + Y, ~(~X + Y) -> X - Y): New
simplifications.

* gcc.dg/tree-ssa/pr94921.c: New test.

[Bug tree-optimization/94969] Invalid loop distribution

[krebbel at gcc dot gnu.org]

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

--- Comment #2 from Andreas Krebbel  ---
Created attachment 48462
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48462&action=edit
Experimental patch

With this patch the returned error is propagated. Unfortunately this prevents
some vectorizations e.g. in gcc.dg/vect/vect-simd-5.c. The reason appears to be
the "evolution of base is not affine" failure in dr_analyze_innermost which now
also gets propagated.

[Bug c++/94967] std::get<0>(tuple const &&) returns wrong type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
GCC 7 was correct at the time it was released. The spec was changed in early
2017 by https://wg21.link/lwg2485 which is implemented in GCC 8 and later.

Since GCC 7 is no longer maintained or supported, there's nothing to do.

[Bug tree-optimization/94969] Invalid loop distribution

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

   Priority|P3  |P2
   Host||x86_64-gnu-linux

[Bug tree-optimization/94921] Failure to optimize nots with sub into single add

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed for 11+.

[Bug c++/94781] version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
> 
> I will try to see if assigning more CPU cores to VirtualBox image I am using
> locally can improve the situation. I am not sure how CPU cache is handled in
> such a setting, but there may be some improvement.

Note that our core developer Honza Hubička takes care of compile time (also
comparing to Clang), for more numbers take a look at
http://hubicka.blogspot.com/

He's been measuring Firefox build time (mainly with LTO) for a couple of years.

> 
> Thank you again for your attention on this matter. I have been using GCC for
> quite a long time on workstations and embedded systems. Thank you for making
> the great package available to the wide developer community.
> 
> Chiaki

Thank you!

[Bug c/94966] ICE: tree check: expected function_type or method_type, have integer_type in gimplify_call_expr, at gimplify.c:3433

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code

--- Comment #2 from Andrew Pinski  ---
(In reply to John X from comment #0)
> test.c:6: confused by earlier errors, bailing out

This does mean there was an ICE but since it is after an error and release
checking is used, this message is outputed.

[Bug c/94968] [10/11 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |10.2

[Bug c/94966] ICE: tree check: expected function_type or method_type, have integer_type in gimplify_call_expr, at gimplify.c:3433

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
IMNSHO a clear dup of PR94730.  It really doesn't make sense to file further
similar bugs until that one is fixed.  Any time you incorrectly redeclare a
variable with completely unrelated type you can run into similar ICEs.

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

[Bug c/94730] [8/9/10/11 Regression] internal compiler error: in fold_convert_loc, at fold-const.c:2435

[jakub at gcc dot gnu.org]

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

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

[Bug c/94968] [10/11 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
   Keywords||wrong-code
   Last reconfirmed||2020-05-06
 Status|UNCONFIRMED |NEW
Summary|Invalid loop distribution   |[8/9/10/11 Regression]
   ||Invalid loop distribution
  Known to work||7.5.0
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed.  Works fine in GCC 7 which also says

Creating dr for f[pretmp_5].e
analyze_innermost: Applying pattern match.pd:84, generic-match.c:11461
failed: bit offset alignment.
base_address:
offset from base address:
constant offset from base address:
step:
aligned to:
base_object: f
Access function 0: 7
Access function 1: pretmp_5

but

(compute_affine_dependence
  stmt_a: f[pretmp_5] = g;
  stmt_b: _2 = f[pretmp_5].e;
) -> dependence analysis failed

instead of

(compute_affine_dependence
  stmt_a: f[pretmp_5] = g;
  stmt_b: _2 = f[pretmp_5].e;
(analyze_overlapping_iterations
  (chrec_a = pretmp_5)
  (chrec_b = pretmp_5)
  (overlap_iterations_a = [0])
  (overlap_iterations_b = [0]))
)

[Bug c++/85958] Make const qualifier error clear

[jg at jguk dot org]

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

--- Comment #11 from Jonny Grant  ---
Created attachment 48463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48463&action=edit
argument discards qualifiers

Another example  "argument discards qualifiers"

[Bug c++/85958] Make const qualifier error clear

[jg at jguk dot org]

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

--- Comment #12 from Jonny Grant  ---
Another example const.cpp attached.

The message doesn't mention it's the const qualifier.

Expected:
:6:21: error: passing 'const
std::vector >' as 'this' argument discards
const qualifier [-fpermissive]

6 | vec.push_back("");

  | ^



Output:


#1 with x86-64 gcc (trunk)
: In function 'void f(const
std::vector >&)':

:6:21: error: passing 'const
std::vector >' as 'this' argument discards
qualifiers [-fpermissive]

6 | vec.push_back("");

  | ^

In file included from
/opt/compiler-explorer/gcc-trunk-20200506/include/c++/11.0.0/vector:67,

 from :2:

/opt/compiler-explorer/gcc-trunk-20200506/include/c++/11.0.0/bits/stl_vector.h:1203:7:
note:   in call to 'void std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp,
_Alloc>::value_type&&) [with _Tp = std::__cxx11::basic_string; _Alloc =
std::allocator >; std::vector<_Tp,
_Alloc>::value_type = std::__cxx11::basic_string]'

 1203 |   push_back(value_type&& __x)

  |   ^

Compiler returned: 1

[Bug bootstrap/94961] [11 regression] internal compiler error: in df_refs_verify, at df-scan.c:4002 since r11-87-gd44f14ccef831d90feb57fab56bc3389d543ffdd

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[11 regression] internal|[11 regression] internal
   |compiler error: in  |compiler error: in
   |df_refs_verify, at  |df_refs_verify, at
   |df-scan.c:4002  |df-scan.c:4002 since
   ||r11-87-gd44f14ccef831d90feb
   ||57fab56bc3389d543ffdd
   Keywords|needs-bisection |

--- Comment #2 from Martin Liška  ---
I'm reducing that right now.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10/11 Regression]
   |Invalid loop distribution   |Invalid loop distribution
   ||since
   ||r8-2390-gdfbddbeb1ca912c9
 CC||marxin at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Confirmed, started with -O3 -ftree-loop-distribution since
r8-2390-gdfbddbeb1ca912c9

[Bug d/94970] New: d: internal compiler error: in verify_gimple_stmt, at tree-cfg.c:4959

[ibuclaw at gdcproject dot org]

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

Bug ID: 94970
   Summary: d: internal compiler error: in verify_gimple_stmt, at
tree-cfg.c:4959
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Reduced test also seen on version 9.2.1.  With -fno-checking, the ICE instead
happens in lower_stmt, at gimple-low.c:409.

struct RegexMatch
{   
static @property m() { return RegexMatch(); }
string opIndex(size_t) { return null; }
~this() { }
}

void initCommands()
{   
auto a = RegexMatch.m[1] ~ ' ';
}

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

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So I think the issue is not dependence testing but loop distribution accepting
a
zero dependence distance as OK.  Of course dependence analysis is quite useless
here since the accesses are to the same location in every iteration.

Bin, maybe you can share your thoughts on this issue?

The testcase doesn't need bitfields - those just disable the cost model
which otherwise prevents the distribution.

diff --git a/gcc/tree-loop-distribution.c b/gcc/tree-loop-distribution.c
index 44423215332..ac272d63c3d 100644
--- a/gcc/tree-loop-distribution.c
+++ b/gcc/tree-loop-distribution.c
@@ -2852,6 +2852,7 @@ loop_distribution::finalize_partitions (class loop *loop,
   /* Don't distribute current loop into too many loops given we don't have
  memory stream cost model.  Be even more conservative in case of loop
  nest distribution.  */
+#if 0
   if ((same_type_p && num_builtin == 0
&& (loop->inner == NULL || num_normal != 2 || num_partial_memset != 1))
   || (loop->inner != NULL
@@ -2867,6 +2868,7 @@ loop_distribution::finalize_partitions (class loop *loop,
}
   partitions->truncate (1);
 }
+#endif

   /* Fuse memset builtins if possible.  */
   if (partitions->length () > 1)


makes the testcase miscompiled even with the : 7 and : 2 commented, so plain

struct S {
  signed m;
  signed e;
};

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

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Before Richards change we likely gave up on the mismatch in access function
dimensionality for f[b] vs. f[b].e but now we compute a dependence distance
of zero.

[Bug c/92472] enhancement: 5 * constify some parameters

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to David Binderman from comment #0)
> Message:
> 
> trunk/libstdc++-v3/include/parallel/multiway_merge.h:121:40: style:
> Parameter '__bi2' can be declared with const [constParameter]
> trunk/libstdc++-v3/include/parallel/multiway_merge.h:191:42: style:
> Parameter '__bi2' can be declared with const [constParameter]
> 
> Patch:
> 
> Index: libstdc++-v3/include/parallel/multiway_merge.h
> ===
> --- libstdc++-v3/include/parallel/multiway_merge.h  (revision 278050)
> +++ libstdc++-v3/include/parallel/multiway_merge.h  (working copy)
> @@ -118,7 +118,7 @@
> *  @return @c true if less. */
>friend bool
>operator<(_GuardedIterator<_RAIter, _Compare>& __bi1,
> -   _GuardedIterator<_RAIter, _Compare>& __bi2)
> +   _GuardedIterator<_RAIter, const _Compare>& __bi2)
>{
> if (__bi1._M_current == __bi1._M_end)   // __bi1 is sup
>   return __bi2._M_current == __bi2._M_end;  // __bi2 is not sup
> @@ -188,7 +188,7 @@
> *  @return @c true if less. */
>friend bool
>operator<(_UnguardedIterator<_RAIter, _Compare>& __bi1,
> -   _UnguardedIterator<_RAIter, _Compare>& __bi2)
> +   _UnguardedIterator<_RAIter, const _Compare>& __bi2)
>{
> // Normal compare.
> return (__bi1.__comp)(*__bi1, *__bi2);

This is 400% wrong. It doesn't even address what cppcheck is complaining about,
and cppcheck is drunk anyway. Those parameter can NOT be const, because *__b1
and *__b2 will not compile if they're const, because operator* is not const.

> All patches seemed to bootstrap ok.

But what about testing them?

[Bug libstdc++/94971] New: [10/11 Regression] Parallel Mode cannot be used in C++20

[redi at gcc dot gnu.org]

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

Bug ID: 94971
   Summary: [10/11 Regression] Parallel Mode cannot be used in
C++20
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This fails to compile in C++20 mode:

#define _GLIBCXX_PARALLEL 1
#include 

The new std::lexicographical_compare_three_way algo I added is in the wrong
namespace.

[Bug libstdc++/94971] [10/11 Regression] Parallel Mode cannot be used in C++20

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I'm not going to fix this for 10.1, I doubt anybody is using our non-standard
parallel mode with C++20 (they should be using the standard parallel algos
added in C++17 instead).

[Bug tree-optimization/94963] [11 Regression] Spurious uninitialized warning for static variable building glibc

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:371905d12259c180efb9b1f1b5716e969feb60f9

commit r11-138-g371905d12259c180efb9b1f1b5716e969feb60f9
Author: Richard Biener 
Date:   Wed May 6 09:39:45 2020 +0200

tree-optimization/94963 - avoid bogus uninit warning with store-motion

Eliding the load for store-motion causes an uninitialized variable
flowing into the loop, conditionally initialized and used.  The
uninit warning cannot relate the flag used to guard the initialization
and use with the actual initialization so the following robustifies
the previous approach of marking the conditional store as not to
be warned on by instead initializing the variable on loop entry
from an uninitialized variable we mark as not to be warned for.

2020-05-06  Richard Biener  

PR tree-optimization/94963
* tree-ssa-loop-im.c (execute_sm_if_changed): Remove
no-warning marking of the conditional store.
(execute_sm): Instead mark the uninitialized state
on loop entry to be not warned about.

* gcc.dg/pr94963.c: New testcase.

[Bug tree-optimization/94963] [11 Regression] Spurious uninitialized warning for static variable building glibc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c/94968] [10/11 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug c/92472] enhancement: 5 * constify some parameters

[dcb314 at hotmail dot com]

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

--- Comment #7 from David Binderman  ---
(In reply to Jonathan Wakely from comment #6)
> This is 400% wrong. It doesn't even address what cppcheck is complaining
> about, and cppcheck is drunk anyway. 

Thanks for your explanation. 
I am a bit confused by it, so further explanation sought, please. 

> Those parameter can NOT be const, because *__b1 and *__b2 will not 
> compile if they're const, because operator* is not const.

My understanding of C++, frayed somewhat since 1988, is that operator * 
being const is a different language feature to parameters being const.

Unless you know different.

> But what about testing them?

Any guidance on fixing this problem, if it is a problem at all,
would be most welcome.

[Bug d/94970] d: internal compiler error: in verify_gimple_stmt, at tree-cfg.c:4959

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw  ---
The statement it is balking on is GIMPLE_WITH_CLEANUP_EXPR.

[Bug other/89394] libiberty :stack overflow in nm

[nickc at gcc dot gnu.org]

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

--- Comment #10 from Nick Clifton  ---
(In reply to Trupti Pardeshi from comment #9)
> May I know, in which version of binutils this fix is available?

2.35.  Which should be available in August, all being well.

Cheers
  Nick

PS.  The fix is already in the mainline development code, so you can always
clone the repository and build your own toolchain.

[Bug bootstrap/94961] [11 Regression] ICE in df_refs_verify, at df-scan.c:4002 since r11-87-gd44f14ccef831d90feb57fab56bc3389d543ffdd

[marxin at gcc dot gnu.org]

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

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

Cannot reduce much..

[Bug bootstrap/94961] [11 Regression] ICE in df_refs_verify, at df-scan.c:4002 since r11-87-gd44f14ccef831d90feb57fab56bc3389d543ffdd

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug tree-optimization/94964] [8/9/10/11 Regression] ICE in add_phi_arg, at tree-phinodes.c:359 since r8-2993-ga7976089dba5e227

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:6fc00b41e764219e2c88d8892d7c701c0d292a17

commit r11-139-g6fc00b41e764219e2c88d8892d7c701c0d292a17
Author: Richard Biener 
Date:   Wed May 6 10:23:15 2020 +0200

middle-end/94964 - avoid EH loop entry with CP_SIMPLE_PREHEADERS

Loop optimizers expect to be able to insert on the preheader
edge w/o splitting it thus avoid ending up with a preheader
that enters the loop via an EH edge (or an abnormal edge).

2020-05-06  Richard Biener  

PR middle-end/94964
* cfgloopmanip.c (create_preheader): Require non-complex
preheader edge for CP_SIMPLE_PREHEADERS.

[Bug tree-optimization/94964] [8/9/10 Regression] ICE in add_phi_arg, at tree-phinodes.c:359 since r8-2993-ga7976089dba5e227

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail|11.0|10.0
Summary|[8/9/10/11 Regression] ICE  |[8/9/10 Regression] ICE in
   |in add_phi_arg, at  |add_phi_arg, at
   |tree-phinodes.c:359 since   |tree-phinodes.c:359 since
   |r8-2993-ga7976089dba5e227   |r8-2993-ga7976089dba5e227
  Known to work||11.0
   Priority|P3  |P2

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

[Bug target/94950] [8/9/10 regression] ICE in gcc.dg/pr94780.c on riscv64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10/11 regression] ICE  |[8/9/10 regression] ICE in
   |in gcc.dg/pr94780.c on  |gcc.dg/pr94780.c on riscv64
   |riscv64 |

--- Comment #4 from Jakub Jelinek  ---
Should be fixed on the trunk so far.

[Bug rtl-optimization/94873] [8/9/10 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10 Regression] wrong
   |wrong code with -O  |code with -O
   |-fno-merge-constants|-fno-merge-constants
   |-fno-split-wide-types   |-fno-split-wide-types
   |-fno-tree-fre   |-fno-tree-fre

--- Comment #21 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/94865] Failure to combine unpckhpd+unpcklpd into blendps

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Missing match.pd patterns also include a no-op comb of insertion of an
extracted element at the same position

(simplify
  (bit_insert @0 (BIT_FIELD_REF @0 @size @pos) @pos)
  (if (size matches)
   @0)

in addition to the requested

(simplify
  (bit_insert @0 (BIT_FIELD_REF @1 @rsize @rpos) @ipos)
  (if (@0 and @1 are vectors compatible for a vec_perm)
   (vec_perm @0 @1 { shuffle-mask }))

[Bug d/94970] d: internal compiler error: in verify_gimple_stmt, at tree-cfg.c:4959

[ibuclaw at gdcproject dot org]

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

--- Comment #2 from Iain Buclaw  ---
Because RegexMatch needs destruction, a temporary is created that requires
scope destruction.  The temporary is wrapped in a TARGET_EXPR, and dtor call
set in TARGET_EXPR_CLEANUP.

  TARGET_EXPR 


A clean-up point is then created around the initialization of 'a'.

  <>


The problem is that for the array concat expression on the RHS, a BIND_EXPR is
set-up for a temporary created for the character literal (its address needs to
be taken).

The routine gimplify_cleanup_point_expr does not look any lower than the first
level of sequences in the body, so it completely misses the
GIMPLE_WITH_CLEANUP_EXPRs in the following:

{
  const char D.4043;

  try 
{ 
  D.4043 = 32;
  D.4110.length = 1;
  D.4110.ptr = &D.4043;
  __tmpfordtor57 = m (); [return slot optimization]
  <<< Unknown GIMPLE statement: gimple_with_cleanup_expr >>>

  <<< Unknown GIMPLE statement: gimple_with_cleanup_expr >>>

  D.4111 = index (&__tmpfordtor57);
  D.4112 = _d_arraycatT (&_D12TypeInfo_Aya6__initZ, D.4111, D.4110);
  retval.0 = VIEW_CONVERT_EXPR(D.4112);
} 
  finally
{
  D.4043 = {CLOBBER};
}
}
retval.1 = retval.0;
a = retval.1;



There is a note above gimplify_cleanup_point_expr:

FIXME should we complexify the prequeue handling instead?  Or use flags
for all the cleanups and let the optimizer tighten them up?  The current
code seems pretty fragile; it will break on a cleanup within any
non-conditional nesting.  But any such nesting would be broken, anyway;
we can't write a TRY_FINALLY_EXPR that starts inside a nesting construct
and continues out of it.  We can do that at the RTL level, though, so
having an optimizer to tighten up try/finally regions would be a Good
Thing.

[Bug c++/94960] extern template prevents inlining of standard library objects

[erich.keane at intel dot com]

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

--- Comment #6 from Erich Keane  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Erich Keane from comment #3)
> > As you know, "extern template" is a hint to the compiler that we don't need
> > to emit the template as a way to save on compile time.
> > 
> > Both GCC and clang will NOT instantiate these templates in O0 mode. 
> > However, in O1+ modes, both will actually still instantiate the templates in
> > the frontend, BUT only for 'inline' functions.  Basically, we're using
> > 'inline' as a heuristic that there is benefit in sending these functions to
> > the optimizer (basically, sacrificing the compile time gained by 'extern
> > template' in exchange for a better inlining experience).
> 
> Hmm, I've seen different behaviours for clang and g++ in this respect, with
> clang inlining a lot more of std::string's members. So I'm surprised they
> use the same heuristic.
> 
> Do they both instantiate the function templates marked 'inline' even at -O1?
> Presumably not at -O0.

My understanding of Clang is based on a brief debugging session. My
understanding of GCC's behavior here is a brief amount of time messing around
on godbolt. I could very well be incorrect.


> 
> > In the submitter's case, the std::string constructor calls "_M_construct". 
> > The constructor is inlined, but _M_construct is not, since it never gets to
> > the optimizer.
> > 
> > libc++ uses an __init function to do the same thing as _M_construct, however
> > IT is marked inline, and thus doesn't have the problem.
> > 
> > I believe the submitter wants to have you mark more of the functions in
> > extern-templated classes 'inline' so that it matches the heuristic better.
> 
> And that's what I don't want to do. I think it's wrong for the human to say
> "inline this!" because humans are stupid (well, I am anyway). And I don't
> want to have to examine the GIMPLE/asm again for every new GCC release to
> decide whether 'inline' is still in the right places (and whether the answer
> should be different for every different version of Clang or ICC!)
> 
> And when I say "I don't want to" I mean "I am never ever going to".
> 
> > I don't think that there is a good way to change the compiler itself without
> > making 'extern template' absolutely meaningless.
> 
> I absolutely disagree.
> 
> It would still give a reduction in object file size for cases where the
> compiler decides not to inline, and still make compilation much faster for
> -O0 and -O1.

That is fair, I guess it would slightly reduce 'link' time because of that. I
doubt people would be willing to put up with the STL compiling that much slower
though (which seems to be the major user of this feature in my experience).

> One property of -O2 and -O3 is that we try to optimize aggressively even if
> that takes a long time to compile. So we could instantiate things that have
> an explicit instantiation declaration (thus doing "redundant" work) to see
> if inlining them would be beneficial. That would take longer to compile, but
> might produce faster code. If the heuristics decide the instantiation ends
> up too big to inline, it could just discard it (because we know there's a
> definition elsewhere).

That is essentially what the frontends DO, except only with the 'inline'
functions.  If the inliner chooses to not inline it, it gets thrown out (since
we've marked it 'available externally').

> If the only way to get that is to mark every function as 'inline' (and then
> "trick" the compiler into doing all that extra work even at -O1?) then we
> might as well add 'inline' to every single function template in  and
> , ,  etc. so they're all potential candiates
> for inlining.
> 
> And if we have to mark every single function as 'inline' then maybe the
> compiler shouldn't be using it as a hint.

I don't think the idea is to mark EVERY function 'inline', simply ones that are
pretty tiny and really good candidates for inlining.

[Bug d/94970] d: internal compiler error: in verify_gimple_stmt, at tree-cfg.c:4959

[ibuclaw at gdcproject dot org]

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

--- Comment #3 from Iain Buclaw  ---
Somewhat simplified reduction of test that doesn't depend on operator
overloading.

struct RegexMatch
{
string index() { return null; }
~this() { }
}
auto m() { return RegexMatch(); }

void initCommands()
{
auto a = m.index() ~ ' ';
}

[Bug fortran/93833] [8/9/10/11 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #8 from markeggleston at gcc dot gnu.org ---
As noted by Tobias:

  Patch was submitted
at https://gcc.gnu.org/pipermail/fortran/2020-March/054072.html
  but the new mailing had stripped off the 'text/x-patch' MIME type back then.

Is the patch going to be resubmitted?

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[myron.walker at gmail dot com]

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

--- Comment #2 from Myron Walker  ---
I am parsinv both gcno and gcda files.

[Bug d/94970] d: internal compiler error: in verify_gimple_stmt, at tree-cfg.c:4959

[ibuclaw at gdcproject dot org]

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

--- Comment #4 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #3)
> Somewhat simplified reduction of test that doesn't depend on operator
> overloading.
> 
> struct RegexMatch
> {
> string index() { return null; }
> ~this() { }
> }
> auto m() { return RegexMatch(); }
> 
> void initCommands()
> {
> auto a = m.index() ~ ' ';
> }


There are two places that create a BIND_EXPR in the D front end, first in
CatExp, the other in NewExp.

The ICE would also happen there as well, and indeed, it does if the
initialization is replaced with.

auto a = new int[](m.index);

[Bug fortran/91726] [8/9 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612

[jrfsousa at gmail dot com]

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

José Rui Faustino de Sousa  changed:

   What|Removed |Added

 CC||jrfsousa at gmail dot com

--- Comment #7 from José Rui Faustino de Sousa  ---
Hi all!

Still ICEs with 9/10/11 using -ftrapv -fcheck=bounds

Best regards,
José Rui

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Myron Walker from comment #2)
> I am parsinv both gcno and gcda files.

These files are not intended to be parsed :/
Can you please describe your use-case?

[Bug tree-optimization/94913] Failure to optimize not+cmp into overflow check

[jakub at gcc dot gnu.org]

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

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

Untested fix for that part.

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[myron.walker at gmail dot com]

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

--- Comment #4 from Myron Walker  ---
A python tool that can do distributed code coverage analysis.  Gcda files from
cluster nodes from a web interface, gcno from a web interface or file share in
a build archive, and source directly from github.

[Bug target/94972] New: Function multi-versioning binary may crash dynamic linker

[d at ilvokhin dot com]

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

Bug ID: 94972
   Summary: Function multi-versioning binary may crash dynamic
linker
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d at ilvokhin dot com
  Target Milestone: ---

Created attachment 48468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48468&action=edit
Simplified version of function multi-versioning example

I compiled simple binary (a simplified version of function multi-versioning
example from gcc.gnu.org) and do ldd -u -r on result.

This leads to ldd segfault in __cpu_indicator_init from libgcc_s.so.

Behaviour is observed at least for GCC 9.1.1 and 7.3.1 (both from Red Hat
devtoolset).

$ g++ --version
g++ (GCC) 9.1.1 20190605 (Red Hat 9.1.1-2)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ tt.cpp -o cpp
$ ldd -u -r ./cpp
/usr/bin/ldd: line 116:  6148 Segmentation fault  (core dumped)
LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes
LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= LD_DEBUG="unused" "$@

Backtrace is looks like that:
(gdb) bt
#0  0x7efccf094c87 in __cpu_indicator_init () from /lib64/libgcc_s.so.1
#1  0x00401178 in ?? ()
#2  0x7fff5f97e220 in ?? ()
#3  0x7efccf8bce5f in _dl_relocate_object () from
/lib64/ld-linux-x86-64.so.2 
(gdb) disass
Dump of assembler code for function __cpu_indicator_init:
   0x7efccf094c70 <+0>: push   %r15
   0x7efccf094c72 <+2>: push   %r14
   0x7efccf094c74 <+4>: push   %r13
   0x7efccf094c76 <+6>: push   %r12
   0x7efccf094c78 <+8>: push   %rbp
   0x7efccf094c79 <+9>: xor%ebp,%ebp
   0x7efccf094c7b <+11>:push   %rbx
   0x7efccf094c7c <+12>:sub$0x18,%rsp
   0x7efccf094c80 <+16>:mov0x212351(%rip),%rax#
0x7efccf2a6fd8
=> 0x7efccf094c87 <+23>:mov(%rax),%eax
   0x7efccf094c89 <+25>:test   %eax,%eax

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Myron Walker from comment #4)
> A python tool that can do distributed code coverage analysis.  Gcda files
> from cluster nodes from a web interface, gcno from a web interface or file
> share in a build archive, and source directly from github.

Can you please use gcov --json-format:
https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html#Invoking-Gcov
?

What kind of information do you need to get from these files? Is it about
finding a corresponding files?

[Bug lto/48200] Implement function attribute for symbol versioning (.symver)

[hubicka at gcc dot gnu.org]

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

--- Comment #44 from Jan Hubicka  ---
Thanks, I am happy we now have real-world use of symver attribute.  I have WIP
patch for better control over the symbol visibility, but I have run into
problems with gas limitations which was fixed by HJ about two weeks ago.
I will try to update the patch and aim for backporting to gcc 10.2.

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[myron.walker at gmail dot com]

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

--- Comment #6 from Myron Walker  ---
I use the gcno file to build a the graph, pull counters from the gcda files and
then solve the graph for the missing counts.  I am merging the data from
multiple gcda sources.  Multiple nodes running the same software.

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Myron Walker from comment #6)
> I use the gcno file to build a the graph, pull counters from the gcda files
> and then solve the graph for the missing counts.

That's what gcov does itself.

> I am merging the data from
> multiple gcda sources.  Multiple nodes running the same software.

I would recommend writing a simple merging tool on top of the JSON files. That
will save you a lot of time.

[Bug c/92472] enhancement: 5 * constify some parameters

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to David Binderman from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > Those parameter can NOT be const, because *__b1 and *__b2 will not 
> > compile if they're const, because operator* is not const.
> 
> My understanding of C++, frayed somewhat since 1988, is that operator * 
> being const is a different language feature to parameters being const.

The function looks like this:

  friend bool
  operator<(const _UnguardedIterator<_RAIter, _Compare>& __bi1,
const _UnguardedIterator<_RAIter, _Compare>& __bi2)
  {
// Normal compare.
return (__bi1.__comp)(*__bi1, *__bi2);
  }

i.e. it uses *__b1 which uses _UnguardedIterator::operator*

If you change __b1 to be const, you can't call non-const member functions on
that object, including _UnguardedIterator::operator*


> Any guidance on fixing this problem, if it is a problem at all,
> would be most welcome.

It's not a problem. The code should be left alone to die in peace.

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Or even better: you can merge various .gcda files with:
gcov-tool merge ...
https://gcc.gnu.org/onlinedocs/gcc/Gcov-tool-Intro.html

[Bug c/92472] enhancement: 5 * constify some parameters

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Or in other words, of course whether a parameter can be const is separate from
whether a member function can be const. But that doesn't mean that changing a
parameter from non-const to const can't have any effect. It certainly has an
effect on which member functions you can call on the parameter.

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[myron.walker at gmail dot com]

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

--- Comment #9 from Myron Walker  ---
How you I process data files from multiple sources and multiple runs with gcov.

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
(In reply to Myron Walker from comment #9)
> How you I process data files from multiple sources and multiple runs with
> gcov.

$ man gcov-tool

$ gcov-tool merge [merge-options] directory1 directory2

So you basically take 2 folders of 2 runs and merge them into a destination
one.
The folders are traversed for .gcda files and corresponding files are merged.
Having N runs, you need to run log2(N) merge operations.

[Bug fortran/92736] [9/10/11 Regression] Error when using a variable from a module in a submodule and its parent module.

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #8 from markeggleston at gcc dot gnu.org ---
This was fixed by Tobias:

https://gcc.gnu.org/g:36c3edb1e39c74e2705efac738a389b5597d9d88

As PR fortran/92736 was not used in the body of the commit message (or
ChangeLog files) this PR was not automatically updated with the commit info.

I'm not precisely sure of the mechanism used to automatically add the commit
info to a PR but preceding change log entries with PR / (both in
the commit message and the ChangeLog files) has worked for me. When I've
omitted PR / it has not worked.

Just needs backporting to gcc-9.

[Bug c++/94967] std::get<0>(tuple const &&) returns wrong type

[rene.r...@fu-berlin.de]

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

--- Comment #2 from Rene Rahn  ---
Oh, thanks for clarifying this.

Best regards

[Bug c++/94953] A lot of false maybe-uninitialized warnings with O3

[olaf.krzikalla at dlr dot de]

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

--- Comment #2 from Olaf Krzikalla  ---
Created attachment 48469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48469&action=edit
Test case code triggering the warning

[Bug target/94972] Function multi-versioning binary may crash dynamic linker

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-06
 Status|UNCONFIRMED |WAITING
 CC||jakub at gcc dot gnu.org,
   ||jwakely.gcc at gmail dot com,
   ||marxin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can't reproduce that on openSUSE Tumbleweed with:

marxin@marxinbox:~/Programming/testcases> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--disable-werror --with-gxx-include-dir=/usr/include/c++/9 --enable-ssp
--disable-libssp --disable-libvtv --disable-cet --disable-libcc1
--enable-plugin --with-bugurl=https://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-9 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 9.3.1 20200406 [revision 6db837a5288ee3ca5ec504fbd5a765817e556ac2]
(SUSE Linux) 
marxin@marxinbox:~/Programming/testcases> ldd --version
ldd (GNU libc) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

I'm adding RedHat guys to CC.

[Bug target/94934] Failure to inline addv

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Yeah, -ftrapv should just be reimplemented using the ubsan/__builtin_*_overflow
internal functions or perhaps killed altogether, one can use
-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error instead.

[Bug tree-optimization/94877] Failure to simplify ~(x + 1) to -2 - x

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I'm not sure why this is considered a simplification, two insns vs. two, and on
the subtraction it isn't specific to just one target, but I think for most the
constant will need to be forced into register, the immediates the instructions
have is mostly for the second operand.

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[myron.walker at gmail dot com]

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

--- Comment #11 from Myron Walker  ---
Ok.  I'll look into it

On Wed, May 6, 2020, 7:25 AM marxin at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928
>
> --- Comment #10 from Martin Liška  ---
> (In reply to Myron Walker from comment #9)
> > How you I process data files from multiple sources and multiple runs with
> > gcov.
>
> $ man gcov-tool
>
> $ gcov-tool merge [merge-options] directory1 directory2
>
> So you basically take 2 folders of 2 runs and merge them into a destination
> one.
> The folders are traversed for .gcda files and corresponding files are
> merged.
> Having N runs, you need to run log2(N) merge operations.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug libstdc++/94973] New: compile error when trying to use pointer-to-member function as invokable projection to ranges::find()

[db0451 at gmail dot com]

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

Bug ID: 94973
   Summary: compile error when trying to use pointer-to-member
function as invokable projection to ranges::find()
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: db0451 at gmail dot com
  Target Milestone: ---

`range-v3` has the concept of "invocable projections", i.e. simple
transformations that can be applied as predicates to its algorithms.
Pointer-to-member-functions should be included and mean 'get the result of
calling that on the current element'. However, it seems that invoking a
pointer-to-member-function in g++ (but NOT clang++) causes the build to fail.

Given the code, compiled with `g++ -std=c++17` against `ericniebler/range-v3`
release `range-v3-0.10.0`, using `g++.exe (Rev2, Built by MSYS2 project)
9.3.0`:

```cpp
#include 
#include 

auto
main() -> int
{
struct S {
int i{};
auto get_i() const { return i; }
};

auto const ss = std::vector(10);
ranges::find(ss, 1, &S::get_i);
return 0;
}

```

I get a spew of errors:
```none
test.cpp: In function 'int main()':
test.cpp:14:31: error: no match for call to '(const ranges::find_fn) (const
std::vector&, int, int (main()::S::*)() const)'
   14 |  ranges::find(ss, 1, &S::get_i);
  |   ^
In file included from FOO/include/range-v3/range/v3/range_fwd.hpp:24,
 from FOO/include/range-v3/range/v3/algorithm/find.hpp:18,
 from test.cpp:1:
FOO/include/range-v3/range/v3/detail/config.hpp:618:27: note: candidate:
'template constexpr concepts::return_t && sentinel_for) &&
indirect_relation::apply, const V*>) &&
concepts::detail::CPP_true(concepts::detail::Nil{})), void>::type>
ranges::find_fn::operator()(I, S, const V&, P) const'
  618 | #define RANGES_FUNC(NAME) operator() RANGES_FUNC_CONST_ /**/
  |   ^~~~
FOO/include/range-v3/range/v3/algorithm/find.hpp:47:24: note: in expansion of
macro 'RANGES_FUNC'
   47 | constexpr auto RANGES_FUNC(find)(I first, S last, V const &
val, P proj = P{})
  |^~~
FOO/include/range-v3/range/v3/detail/config.hpp:618:27: note:   template
argument deduction/substitution failed:
  618 | #define RANGES_FUNC(NAME) operator() RANGES_FUNC_CONST_ /**/
  |   ^~~~
FOO/include/range-v3/range/v3/algorithm/find.hpp:47:24: note: in expansion of
macro 'RANGES_FUNC'
   47 | constexpr auto RANGES_FUNC(find)(I first, S last, V const &
val, P proj = P{})
  |^~~
In file included from FOO/include/range-v3/range/v3/iterator/access.hpp:22,
 from FOO/include/range-v3/range/v3/iterator/concepts.hpp:30,
 from FOO/include/range-v3/range/v3/algorithm/find.hpp:22,
 from test.cpp:1:
FOO/include/range-v3/std/detail/associated_types.hpp: In substitution of
'template using enable_if_t = typename
ranges::detail::enable_if::apply [with bool B =
ranges::readable >; T = std::vector]':
FOO/include/range-v3/range/v3/iterator/concepts.hpp:561:19:   required by
substitution of 'template using apply =
ranges::detail::enable_if_t<(bool)(readable), I> [with I =
std::vector]'
FOO/include/range-v3/range/v3/algorithm/find.hpp:48:15:   required by
substitution of 'template constexpr
concepts::return_t &&
sentinel_for) && indirect_relation::apply, const V*>) &&
concepts::detail::CPP_true(concepts::detail::Nil{})), void>::type>
ranges::find_fn::operator()(I, S, const V&, P) const [with I =
std::vector; S = int; V = int (main()::S::*)() const; P =
ranges::identity]'
test.cpp:14:31:   required from here
FOO/include/range-v3/std/detail/associated_types.hpp:73:15: error: no class
template named 'apply' in 'struct ranges::detail::enable_if'
   73 | using enable_if_t = typename enable_if::template apply;
  |   ^~~
In file included from FOO/include/range-v3/range/v3/range_fwd.hpp:24,
 from FOO/include/range-v3/range/v3/algorithm/find.hpp:18,
 from test.cpp:1:
FOO/include/range-v3/range/v3/detail/config.hpp:618:27: note: candidate:
'template constexpr concepts::return_t >::apply())), ranges::dangling>, typename
std::enable_if<((input_range && indirect_relation::apply()))>, const V*>) &&
concepts::detail::CPP_true(concepts::detail::Nil{})), void>::type>
ranges::find_fn::operator()(Rng&&, const V&, P) const'
  618 | #define RANGES_FUNC(NAME) operator() RANGES_FUNC_CONST_ /**/
  |   ^~~~
FOO/include/range-v3/range/v3/algorithm/find.hpp:60:24: note: in expansion of
macro 'RANGES_FUNC'
   60 | constexpr auto RANGES_FUNC(find)(Rng && rng, V const & val, P
proj = P{})
  |