[Bug target/48595] score-elf fails to build with --enable-werror-always

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |WAITING
   Last reconfirmed|2013-02-25 00:00:00 |2019-08-09
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> does this still happen?

WAITING on a reply

[Bug c++/80078] Incorrect classification of address of volatile as not constant

[headch at gmail dot com]

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

--- Comment #3 from Christopher Head  ---
I tried 9.1 at gcc.godbolt.org and it looks like this is fixed. Anyone else
care to take a look? If there are no further comments, I guess I’ll close this
ticket in a few days.

[Bug c++/91397] -Wstringop-overflow specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #10 from Martin Sebor  ---
GCC assumes that no object can be bigger than PTRDIFF_MAX - 1 bytes and warns
when it detects code that expects otherwise.  A more general condition to add
to mem_strdupl() to avoid the warning is:

  if (len >= PTRDIFF_MAX)
__builtin_unreachable ();

GCC doesn't track pointer ranges as well as it does integers and it easily
"loses" information about their relationships.  For instance, in the functions
below, GCC folds the first test to false but it doesn't fold the second.

  void f (long a, long b)
  { 
if (a < b)
  return;

if (a - b < 0)   // folded to false
  __builtin_abort ();
  }

  void g (int *a, int *b)
  {
if (a < b)
  return;

if (a - b < 0)   // not folded
  __builtin_abort ();
  }

[Bug c++/90473] gcc does not call function in comma operator for default argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00597.html

[Bug driver/80545] option -Wstringop-overflow not recognized by Fortran

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
I believe r273771 fully this bug.

[Bug ada/82813] warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]

[msebor at gcc dot gnu.org]

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

Bug 80545 Summary: option -Wstringop-overflow not recognized by Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80545

   What|Removed |Added

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

[Bug tree-optimization/89176] Vectorizer fails to consider narrower vector width for res[i] = v1[i] < v2[i] ? v2[i] : v1[i]

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #2 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> 
> The epilogue vectorization issue also needs investigation.

Epilogue vectorization doesn't seem to work:

[hjl@gnu-cfl-1 pr89176]$ cat x.i
extern float *v1;
extern float *v2;
extern float *res;


void
foo (int n)
{
  int i;

  for (i = 0; i < n; i++)
res[i] = v2[i] * v1[i];
}
[hjl@gnu-cfl-1 pr89176]$ make x.s
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O3
-march=skylake  -S x.i
[hjl@gnu-cfl-1 pr89176]$ cat x.s
.file   "x.i"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
testl   %edi, %edi
jle .L23
movqv2(%rip), %rcx
movqres(%rip), %rdx
movqv1(%rip), %rsi
leaq31(%rcx), %r8
subq%rdx, %r8
cmpq$62, %r8
leaq31(%rsi), %r8
seta%r9b
subq%rdx, %r8
cmpq$62, %r8
seta%r8b
leal-1(%rdi), %eax
testb   %r8b, %r9b
je  .L3
cmpl$6, %eax
jbe .L3
movl%edi, %r8d
shrl$3, %r8d
salq$5, %r8
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L4:
vmovups (%rcx,%rax), %ymm1
vmulps  (%rsi,%rax), %ymm1, %ymm0
vmovups %ymm0, (%rdx,%rax)
addq$32, %rax
cmpq%r8, %rax
jne .L4
movl%edi, %eax
andl$-8, %eax
testb   $7, %dil
je  .L22
movl%eax, %r8d
vmovss  (%rcx,%r8,4), %xmm0
vmulss  (%rsi,%r8,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%r8,4)
leal1(%rax), %r8d
cmpl%r8d, %edi
jle .L22
movslq  %r8d, %r8
vmovss  (%rcx,%r8,4), %xmm0
vmulss  (%rsi,%r8,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%r8,4)
leal2(%rax), %r8d
cmpl%r8d, %edi
jle .L22
movslq  %r8d, %r8
vmovss  (%rcx,%r8,4), %xmm0
vmulss  (%rsi,%r8,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%r8,4)
leal3(%rax), %r8d
cmpl%r8d, %edi
jle .L22
movslq  %r8d, %r8
vmovss  (%rcx,%r8,4), %xmm0
vmulss  (%rsi,%r8,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%r8,4)
leal4(%rax), %r8d
cmpl%r8d, %edi
jle .L22
movslq  %r8d, %r8
vmovss  (%rcx,%r8,4), %xmm0
vmulss  (%rsi,%r8,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%r8,4)
leal5(%rax), %r8d
cmpl%r8d, %edi
jle .L22
movslq  %r8d, %r8
vmovss  (%rcx,%r8,4), %xmm0
addl$6, %eax
vmulss  (%rsi,%r8,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%r8,4)
cmpl%eax, %edi
jle .L22
cltq
vmovss  (%rcx,%rax,4), %xmm0
vmulss  (%rsi,%rax,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%rax,4)
vzeroupper
ret
.p2align 4,,10
.p2align 3
.L22:
vzeroupper
.L23:
ret
.p2align 4,,10
.p2align 3
.L3:
movl%eax, %edi
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L6:
vmovss  (%rcx,%rax,4), %xmm0
movq%rax, %r8
vmulss  (%rsi,%rax,4), %xmm0, %xmm0
vmovss  %xmm0, (%rdx,%rax,4)
incq%rax
cmpq%rdi, %r8
jne .L6
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 10.0.0 20190723 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 pr89176]$

[Bug c++/90473] gcc does not call function in comma operator for default argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
I think checking TREE_SIDE_EFFECTS there should be enough.

[Bug c++/90473] gcc does not call function in comma operator for default argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
This is where we lose the side-effect:

check_default_argument
13174   /* Avoid redundant -Wzero-as-null-pointer-constant warnings at
13175  the call sites.  */
13176   if (TYPE_PTR_OR_PTRMEM_P (decl_type)
13177   && null_ptr_cst_p (arg))
13178 return nullptr_node;

Poking more...

[Bug c++/91394] C++ ABI incompatibility (stdexcept)

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Some programs which happen to not use any new features might work with an older
version of libstdc++.so but that is not guaranteed, and definitely not
supported.

Removing one or two functions from a header is not going to solve the problem
in the general case. Using _GLIBCXX_USE_CXX11_ABI is also not a solution for
this, that's not what it's for.

If you want to run with the libstdc++.so from GCC 4.9.4 then compile with GCC
4.9.4, that's guaranteed to work.

[Bug driver/91406] New: gcc -Q -v lies about what flags are enabled

[sje at gcc dot gnu.org]

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

Bug ID: 91406
   Summary: gcc -Q -v lies about what flags are enabled
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---

If you run 'gcc -Q -v x.c'  and look at the 'options enabled:' list, it is not
accurate.  For example, on aarch64 it will show '-fprefetch-loop-arrays' which
is not on by default for a generic aarch64 compiles (even at -O3).  The problem
is that this flag is initialized to -1 and it might be overridden by
aarch64_override_options_internal in some cases to turn it on but if it is not
overridden it stays at -1 and then option_enabled (opts-common.c) checks
to see if it is zero or not-zero and if not-zero it returns true and says it
is enabled.  Note that in this case the compiler will not actually generate
prefetch instructions because the gate function is checking for 'x > 0', not
'x != 0' like option_enabled does.

This can affect any option in commons.opt (or elsewhere) that is initialized to
-1.  There are also flags that are initialized to 1 but probably should not
show up if compiling at -O0 because in that case the pass that would check the
flag is never called, such as -faggressive-loop-optimizations for example.  If
you run a '-Q -v -O0' compilation on x86 the list of enabled options will
include -faggressive-loop-optimizations which I am sure is not actually run.  I
guess you could claim it is enabled but not run, but that seems unhelpful.

I could fix the specific aarch64 '-fprefetch-loop-arrays' bug by having
aarch64_override_options_internal set the prefetch flag to 0 in those cases
where it is not setting it to 1.  That way it would never be -1 when
option_enabled checks it, but I am not sure this the right/best fix.

[Bug target/47779] Problem cross-compiling trunk for bfin

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #8 from Jeffrey A. Law  ---
Per c#7.

[Bug c++/91394] C++ ABI incompatibility (stdexcept)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Forwards compatible is not guaranteed; only backwards compatible.
That is you can compile with X and run with (X+1) libraries but not the
opposite way around.  This is true with almost all software including but not
limited to GLIBC, GCC, libstdc++ (and even Windows).

[Bug libgcc/91379] internal compiler error __gcov_fork

[cbunch at cfhp dot com]

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

--- Comment #4 from Clinton Bunch  ---
Setting the CFLAGS and CXXFLAGS to -O0 -g as suggested didn't help. It still
blew up at the same point building libgcc.

  Interestingly, I noticed that it doesn't blow up if the code is compiled in
-mlp64 mode, only in the default -milp32 mode.  The process successfully builds
a 64-bit libgcc_s.so

[Bug c++/91405] [concepts] internal compiler error: in synthesize_implicit_template_parm, at cp/parser.c:41206

[kingoipo at gmail dot com]

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

--- Comment #1 from Michael de Lang  ---
Correction, the reported line number for 7.4.0 is cp.parser.c:38874

[Bug c++/91405] New: [concepts] internal compiler error: in synthesize_implicit_template_parm, at cp/parser.c:41206

[kingoipo at gmail dot com]

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

Bug ID: 91405
   Summary: [concepts] internal compiler error: in
synthesize_implicit_template_parm, at
cp/parser.c:41206
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kingoipo at gmail dot com
  Target Milestone: ---

Created attachment 46691
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46691=edit
Wrong usage of concepts leads to ICE

The compiler ICE's on the attached file. There are some simular bug reports
which might be the same problem or a related one, but they report a different
parser.c line.

I believe the code is incorrect and would have expected an error message like
"cannot use concept as type specifier, use template arguments instead". But it
gives an ICE.

The error happens with both g++ 7.4.0 and 9.1.0, using -fconcepts and latest
supported std version.

[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is

[msebor at gcc dot gnu.org]

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

--- Comment #19 from Martin Sebor  ---
That's a valid concern.  Issuing a warning (either at the same time as or in
lieu of the folding) would be a way to detect and prevent these kinds of
problems.  Exposing it to enough code (like in a whole distro rebuild) would
give us a pretty good idea about what the appropriate defaults ought to be.

[Bug target/91229] RISC-V ABI problem with zero-length bit-fields and float struct fields

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #4 from Jim Wilson  ---
Fixed on mainline.

[Bug target/91229] RISC-V ABI problem with zero-length bit-fields and float struct fields

[wilson at gcc dot gnu.org]

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

--- Comment #3 from Jim Wilson  ---
Author: wilson
Date: Thu Aug  8 19:04:56 2019
New Revision: 274215

URL: https://gcc.gnu.org/viewcvs?rev=274215=gcc=rev
Log:
RISC-V: Fix C ABI for flattened struct with 0-length bitfield.

gcc/
PR target/91229
* config/riscv/riscv.c (riscv_flatten_aggregate_field): New arg
ignore_zero_width_bit_field_p.  Skip zero size bitfields when true.
Pass into recursive call.
(riscv_flatten_aggregate_argument): New arg.  Pass to
riscv_flatten_aggregate_field.
(riscv_pass_aggregate_in_fpr_pair_p): New local warned.  Call
riscv_flatten_aggregate_argument twice, with false and true as last
arg.  Process result twice.  Compare results and warn if different.
(riscv_pass_aggregate_in_fpr_and_gpr_p): Likewise.

gcc/testsuite/
* gcc.target/riscv/flattened-struct-abi-1.c: New test.
* gcc.target/riscv/flattened-struct-abi-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/riscv/flattened-struct-abi-1.c
trunk/gcc/testsuite/gcc.target/riscv/flattened-struct-abi-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/riscv/riscv.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/91403] GCC fails with ICE.

[belyshev at depni dot sinp.msu.ru]

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

Serge Belyshev  changed:

   What|Removed |Added

 CC||belyshev at depni dot 
sinp.msu.ru

--- Comment #2 from Serge Belyshev  ---
Crashes here in predcom:

Program received signal SIGSEGV, Segmentation fault.
...
(gdb) bt -100
...
#662173 0x012f7c09 in follow_ssa_edge (loop=0x778cd000,
def=0x7fffd8be5160, halting_phi=0x778d4200,
evolution_of_loop=0x7fffdf00, limit=0) at
../../gcc/gcc/tree-scalar-evolution.c:1350
#662174 0x012f6f22 in follow_ssa_edge_binary (loop=0x778cd000,
at_stmt=0x7fffd8be51b8, type=0x778c31f8, rhs0=0x7fffd8be6120,
code=POINTER_PLUS_EXPR, rhs1=0x77775d38, halting_phi=0x778d4200,
evolution_of_loop=0x7fffdf00, limit=0) at
../../gcc/gcc/tree-scalar-evolution.c:947
#662175 0x012f769e in follow_ssa_edge_in_rhs (loop=0x778cd000,
stmt=0x7fffd8be51b8, halting_phi=0x778d4200,
evolution_of_loop=0x7fffdf00, limit=0) at
../../gcc/gcc/tree-scalar-evolution.c:1135
#662176 0x012f7c09 in follow_ssa_edge (loop=0x778cd000,
def=0x7fffd8be51b8, halting_phi=0x778d4200,
evolution_of_loop=0x7fffdf00, limit=0) at
../../gcc/gcc/tree-scalar-evolution.c:1350
#662177 0x012f6f22 in follow_ssa_edge_binary (loop=0x778cd000,
at_stmt=0x778ccf20, type=0x778c31f8, rhs0=0x7fffd8be61b0,
code=POINTER_PLUS_EXPR, rhs1=0x77775d38, halting_phi=0x778d4200,
evolution_of_loop=0x7fffdf00, limit=0) at
../../gcc/gcc/tree-scalar-evolution.c:947
#662178 0x012f769e in follow_ssa_edge_in_rhs (loop=0x778cd000,
stmt=0x778ccf20, halting_phi=0x778d4200,
evolution_of_loop=0x7fffdf00, limit=0) at
../../gcc/gcc/tree-scalar-evolution.c:1135
#662179 0x012f7c09 in follow_ssa_edge (loop=0x778cd000,
def=0x778ccf20, halting_phi=0x778d4200,
evolution_of_loop=0x7fffdf00, limit=0) at
../../gcc/gcc/tree-scalar-evolution.c:1350
#662180 0x012f812d in analyze_evolution_in_loop
(loop_phi_node=0x778d4200, init_cond=0x778ce0d8) at
../../gcc/gcc/tree-scalar-evolution.c:1467
#662181 0x012f864d in interpret_loop_phi (loop=0x778cd000,
loop_phi_node=0x778d4200) at ../../gcc/gcc/tree-scalar-evolution.c:1630
#662182 0x012fa1bd in analyze_scalar_evolution_1 (loop=0x778cd000,
var=0x7777fee8) at ../../gcc/gcc/tree-scalar-evolution.c:2044
#662183 0x012fa393 in analyze_scalar_evolution (loop=0x778cd000,
var=0x7777fee8) at ../../gcc/gcc/tree-scalar-evolution.c:2108
#662184 0x012fa49e in analyze_scalar_evolution_in_loop
(wrto_loop=0x778cd000, use_loop=0x778cd000, version=0x7777fee8,
folded_casts=0x7fffe0df) at ../../gcc/gcc/tree-scalar-evolution.c:2210
#662185 0x012fd082 in simple_iv_with_niters (wrto_loop=0x778cd000,
use_loop=0x778cd000, op=0x7777fee8, iv=0x7fffe280, iv_niters=0x0,
allow_nonconstant_step=true) at ../../gcc/gcc/tree-scalar-evolution.c:3288
#662186 0x012fd8e0 in simple_iv (wrto_loop=0x778cd000,
use_loop=0x778cd000, op=0x7777fee8, iv=0x7fffe280,
allow_nonconstant_step=true) at ../../gcc/gcc/tree-scalar-evolution.c:3413
#662187 0x0207e0ef in dr_analyze_innermost (drb=0x3166a50,
ref=0x778e11b8, loop=0x778cd000, stmt=0x778d8dc0) at
../../gcc/gcc/tree-data-ref.c:950
#662188 0x0207f342 in create_data_ref (nest=0x778d0f00,
loop=0x778cd000, memref=0x778e11b8, stmt=0x778d8dc0, is_read=true,
is_conditional_in_stmt=false) at ../../gcc/gcc/tree-data-ref.c:1255
#662189 0x02089d1c in find_data_references_in_stmt
(nest=0x778cd000, stmt=0x778d8dc0, datarefs=0x7fffe7f8) at
../../gcc/gcc/tree-data-ref.c:5149
#662190 0x02089f0e in find_data_references_in_bb (loop=0x778cd000,
bb=0x778da410, datarefs=0x7fffe7f8) at
../../gcc/gcc/tree-data-ref.c:5203
#662191 0x02089fce in find_data_references_in_loop
(loop=0x778cd000, datarefs=0x7fffe7f8) at
../../gcc/gcc/tree-data-ref.c:5236
#662192 0x0208a604 in compute_data_dependences_for_loop
(loop=0x778cd000, compute_self_and_read_read_dependences=true,
loop_nest=0x7fffe750, datarefs=0x7fffe7f8,
dependence_relations=0x7fffe7f0) at ../../gcc/gcc/tree-data-ref.c:5411
#662193 0x012d7b7e in tree_predictive_commoning_loop
(loop=0x778cd000) at ../../gcc/gcc/tree-predcom.c:3192
#662194 0x012d8134 in tree_predictive_commoning () at
../../gcc/gcc/tree-predcom.c:3314
#662195 0x012d81b4 in run_tree_predictive_commoning
(fun=0x778c6000) at ../../gcc/gcc/tree-predcom.c:3339
#662196 0x012d8222 in (anonymous namespace)::pass_predcom::execute
(this=0x2fc7cb0, fun=0x778c6000) at ../../gcc/gcc/tree-predcom.c:3368
#662197 0x0102b1c3 in execute_one_pass (pass=0x2fc7cb0) at

[Bug tree-optimization/91403] GCC fails with ICE.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Doesn't ICE for me, but SLP during vectorization goes wild, for very short
*.ifcvt
   [local count: 12199019]:
  b_lsm.4_24 = b;

   [local count: 97603136]:
  # d_69 = PHI <2(2), d_9(5)>
  # b_lsm.4_17 = PHI 
  # ivtmp_76 = PHI <8(2), ivtmp_73(5)>
  _14 = a[d_69][5];
  _16 = _14 + b_lsm.4_17;
  _23 = _14 + _16;
  _30 = _14 + _23;
  _37 = _14 + _30;
  _44 = _14 + _37;
  _51 = _14 + _44;
  _58 = _14 + _51;
  _65 = _14 + _58;
  _72 = _14 + _65;
  _79 = _14 + _72;
  d_9 = d_69 + 1;
  ivtmp_73 = ivtmp_76 - 1;
  if (ivtmp_73 != 0)
goto ; [87.50%]
  else
goto ; [12.50%]

   [local count: 85404116]:
  goto ; [100.00%]

   [local count: 12199019]:
  # _80 = PHI <_79(3)>
  b = _80;
  return;
it creates a *.vect dump with 1860297 lines, with:
  vect__14.10_5 = MEM  [(int *)vectp_a.8_7];
  vectp_a.8_4 = vectp_a.8_7 + 32;
  vect__14.11_3 = MEM  [(int *)vectp_a.8_4];
  vectp_a.8_2 = vectp_a.8_4 + 32;
  vect__14.12_1 = MEM  [(int *)vectp_a.8_2];
  vectp_a.8_10 = vectp_a.8_2 + 32;
  vect__14.13_15 = MEM  [(int *)vectp_a.8_10];
  vectp_a.8_31 = vectp_a.8_10 + 32;
...
where there are 620046 those MEM loads that nothing consumes and 620046
additions of 32.

[Bug c++/91334] [10 Regression] ICE in propagate_necessity at gcc/tree-ssa-dce.c:813 since r273791

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from H.J. Lu  ---
I opened PR 91404.

[Bug ipa/91404] New: [10 Regression] internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

Bug ID: 91404
   Summary: [10 Regression] internal compiler error: Segmentation
fault
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

On x86-64, when building 483.xalancbmk in SPEC CPU 2006, r273857 caused:

$ gcc  -S -DSPEC_CPU -DNDEBUG  -DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER -I.
-Ixercesc -Ixercesc/dom -Ixercesc/dom/impl -Ixercesc/sax
-Ixercesc/util/MsgLoaders/InMemory -Ixercesc/util/Transcoders/Iconv
-Ixalanc/include -DPROJ_XMLPARSER -DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C
-DPROJ_SAX2 -DPROJ_DOM -DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER
-DXML_USE_INMEM_MESSAGELOADER -O2-DSPEC_CPU_LP64  -DSPEC_CPU_LINUX
XPath.cpp  -ffast-math
./PlatformDefinitions.hpp:66:35: internal compiler error: Segmentation fault
   66 |  #define XALAN_CPP_NAMESPACE_END  }
  |   ^
0xfbc09f crash_signal
../../src-trunk/gcc/toplev.c:326
0xb26383 lookup_page_table_entry
../../src-trunk/gcc/ggc-page.c:632
0xb26383 ggc_set_mark(void const*)
../../src-trunk/gcc/ggc-page.c:1531
0xd69c41 gt_ggc_mx_symtab_node(void*)
/export/gnu/import/git/gcc-test-spec-lto/bld/gcc/gtype-desc.c:1302
0xee468d gt_ggc_ma_order
./gt-passes.h:31
0xee468d gt_ggc_ma_order
./gt-passes.h:26
0xcf6115 ggc_mark_root_tab
../../src-trunk/gcc/ggc-common.c:77
0xcf631c ggc_mark_roots()
../../src-trunk/gcc/ggc-common.c:94
0xb26d05 ggc_collect()
../../src-trunk/gcc/ggc-page.c:2201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

It doesn't fail with pre-processed file.

[Bug c++/91402] PowerPC unecessary -Wignored-attriubte warnings on template specialization with -mlongcall

[andrewdkaster at gmail dot com]

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

--- Comment #1 from Andrew Kaster  ---
As a note, I was able to reproduce using godbolt, but they don't have very
recent versions of gcc for powerpc:

https://godbolt.org/z/20lNhf

Of the available compilers:

No warnings:
power64le clang (trunk)
powerpc64 clang (trunk)
PowerPC gcc 4.8.5

Warnings:
power64 AT 12.0
power64le AT 12.0
power64le gcc 6.3.0

[Bug tree-optimization/91403] New: GCC fails with ICE.

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 91403
   Summary: GCC fails with ICE.
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

GCC fails with an internal compiler error. Sometimes the compilation takes
about 12 minutes before it fails. Originally the bug was reported in r91178.

Reproducer:
extern int a[][1240092];
int b;
void c() {
  for (int d = 2; d <= 9; d++)
for (int e = 32; e <= 41; e++)
  b += a[d][5];
}

Error:
>$ gcc -march=skylake-avx512 -c -O3 small.c
gcc: internal compiler error: Segmentation fault signal terminated program cc1

GCC version:
gcc version 10.0.0 (rev. 274155)

[Bug tree-optimization/91178] [9 Regression] Infinite recursion in split_constant_offset in slp after r260289

[vsevolod.livinskij at frtk dot ru]

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

--- Comment #17 from Vsevolod Livinskiy  ---
(In reply to Serge Belyshev from comment #16)
> (In reply to Vsevolod Livinskiy from comment #15)
> > I don't know if it is the same error or not, but the reproducer looks
> > similar.
> 
> This one is different.  It does not fail for me with -O3
> -march=skylake-avx512, just slow and consumes over 1G of memory.
> 
> But with just "-O3" it blows up the stack during predictive commoning pass
> via  follow_ssa_edge tree-scalar-evolution.c:1350 --> follow_ssa_edge_in_rhs
> tree-scalar-evolution.c:1135 -->  follow_ssa_edge_binary
> tree-scalar-evolution.c:947 --> follow_ssa_edge tree-scalar-evolution.c:1350
> recursion.
> 
> Git bisect points at r256634.

Thank you! I'll open a new bug to keep them separated.

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

[ian at airs dot com]

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

--- Comment #23 from Ian Lance Taylor  ---
Look for _kern in runtime.inc.  See what struct it is part of.  The struct is
likely defined in the generated file runtime_sysinfo.go.  You may need to
modify libgo/mkrsysinfo.sh to not add that struct to runtime_sysinfo.go, or you
may need to modify mkrsysinfo.sh to define __usem2.

[Bug c++/79520] Spurious caching for constexpr arguments

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Done.

[Bug c++/79520] Spurious caching for constexpr arguments

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Thu Aug  8 17:54:58 2019
New Revision: 274214

URL: https://gcc.gnu.org/viewcvs?rev=274214=gcc=rev
Log:
PR c++/79520
* g++.dg/cpp1y/constexpr-79520.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-79520.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/91402] New: PowerPC unecessary -Wignored-attriubte warnings on template specialization with -mlongcall

[andrewdkaster at gmail dot com]

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

Bug ID: 91402
   Summary: PowerPC unecessary -Wignored-attriubte warnings on
template specialization with -mlongcall
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrewdkaster at gmail dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: powerpc-linux-gnu
 Build: x86_64-linux-gnu

Created attachment 46690
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46690=edit
Reproducer

When using the option -mlongcall for powerpc, g++ appears to treat my template
parameter for my template specialization as a function declaration and add the
longcall attribute, which then is later ignored and generates a warning.

~: powerpc-linux-gnu-g++ -mlongcall -Wall -Wextra -c test.cpp -o test.o
test.cpp:5:15: warning: ignoring attributes on template argument ‘R(A)’
[-Wignored-attributes]
 struct S  {};
   ^
test.cpp:11:18: warning: ignoring attributes on template argument ‘Ret(Arg)’
[-Wignored-attributes]
 struct D {
  ^
I am using this class to wrap a generic delegate, per the second example.

Tested on Ubuntu 18.04.03, powerpc-linux-gnu-g++ version 7.4.0

~: powerpc-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=powerpc-linux-gnu-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/powerpc-linux-gnu/7/lto-wrapper
Target: powerpc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.4.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--with-system-zlib --enable-secureplt --disable-softfloat --with-cpu=default32
--disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux
--enable-multiarch --disable-werror --with-long-double-128 --enable-multilib
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=powerpc-linux-gnu --program-prefix=powerpc-linux-gnu-
--includedir=/usr/powerpc-linux-gnu/include
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)


The same results happen when using a version of g++ 8.1 obtained from WindRiver
to target PowerPC VxWorks (running on Rhel-7):

./powerpc-linux-gnu-g++ -v
Reading specs from
/opt/workbench4-r2/compilers/gnu-8.1.0.1/x86_64-linux2/bin/../lib/gcc/powerpc-linux-gnu/8.1.0/../../../../powerpc-linux-gnu/lib/specs
COLLECT_GCC=./powerpc-linux-gnu-g++
COLLECT_LTO_WRAPPER=/opt/workbench4-r2/compilers/gnu-8.1.0.1/x86_64-linux2/bin/../libexec/gcc/powerpc-linux-gnu/8.1.0/lto-wrapper
Target: powerpc-linux-gnu
Configured with:
/folk/prj-llvm-build/gcc/build-storage/master/20190313_161647/wr-gcc/gcc/configure
--target=powerpc-linux-gnu --prefix=/usr/local/wind/tmp/compilers
--with-pkgversion='Wind River VxWorks GCC 8.1.0.1 - 2019.03.13' --disable-nls
--enable-languages=c,c++ --enable-targets=all --disable-multilib
--enable-threads --enable-tls --enable-__cxa_atexit --enable-secureplt
Thread model: posix
gcc version 8.1.0 (Wind River VxWorks GCC 8.1.0.1 - 2019.03.13)

[Bug c++/79520] Spurious caching for constexpr arguments

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed by r255788.  Probably it's worth to add the new test.

[Bug c++/88330] Implement P0542R5, P1289R1, C++20 contract based programming.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Marek Polacek  ---
Since contracts were pulled out of C++20, I'm closing this PR.

[Bug c++/88323] implement C++20 language features.

[mpolacek at gcc dot gnu.org]

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

Bug 88330 Summary: Implement P0542R5, P1289R1, C++20 contract based programming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88330

   What|Removed |Added

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

[Bug c++/88102] Implement P0542R5, C++20 contracts

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Marek Polacek  ---
Since contracts were pulled out of C++20, I'm closing this PR.

[Bug c++/88323] implement C++20 language features.

[mpolacek at gcc dot gnu.org]

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

Bug 88102 Summary: Implement P0542R5, C++20 contracts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88102

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

[Bug c/91398] Possible missed optimization: Can a pointer be passed as hidden pointer in x86-64 System V ABI

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
ABI question: is a function that returns a value through such a hidden 
pointer required not to write anything to the storage pointed to until it 
knows that it will definitely be returning normally (rather than e.g. 
through longjmp)?  The ABI document seems silent on this matter.  This 
optimization is only valid if there is such a requirement, since *out in 
the example given must not be written if the function returns through 
longjmp.

[Bug middle-end/91395] Report an uninitialized variable on its initialization statement (setjmp)

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
It's *accessible objects* whose value on second return from setjmp is the 
same as when longjmp is called (unless non-volatile, automatic storage 
duration and changed between setjmp and longjmp).  The point is that when 
longjmp is called, save_exception_stack may not be an accessible object 
(because of having gone out of scope), so has no defined value, so it's 
just like goto jumping into the block where save_exception_stack is 
declared and thus bypassing its initialization - it's valid to jump into 
the scope like that (unless jumping into the scope of a declaration with 
variably modified type), but the variable is uninitialized.

[Bug c++/81930] [meta-bug] Issues with -Weffc++

[mpolacek at gcc dot gnu.org]

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

Bug 57854 Summary: Would like to have a warning for virtual overrides without 
C++11 "override" keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57854

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug c++/57854] Would like to have a warning for virtual overrides without C++11 "override" keyword

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
-Wsuggest-override is already present, closing.

[Bug c++/80061] error on constexpr function with an unevaluated throw

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #7 from Marek Polacek  ---
Comment 1 compiles fine since r264171.

[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is

[joseph at codesourcery dot com]

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

--- Comment #18 from joseph at codesourcery dot com  ---
I don't expect people to do such comparisons with addresses of local 
variables directly.  It is plausible that they have a memmove-like 
function, and once it gets inlined the compiler can see that, at a 
particular call site, it's doing such comparisons involving addresses of 
local variables.  The question then is whether this might result in 
problems if e.g. the comparisons say two arrays are both before and after 
each other and the memmove-like function isn't prepared for that.  And, 
then, whether we say that's OK and such a function needs to cast to 
uintptr_t as the way to make something that's valid in 
C-with-ABI-boundaries into something that works in GNU C in the presence 
of (possibly LTO) inlining.

[Bug c++/90313] [7/8/9/10 Regression] Is an assignment elided with gcc7.3 -O2?

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

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

[Bug c++/63391] Erroneous -Wsign-conversion with offsetof

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Fixed now by r274211.

[Bug driver/91396] Link error when I use -fvtable-verify=std and -static

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||link-failure
 CC||cmtice at google dot com,
   ||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing libvtv maintainer

[Bug c++/91334] [10 Regression] ICE in propagate_necessity at gcc/tree-ssa-dce.c:813 since r273791

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  ---
(In reply to Martin Liška from comment #10)
> (In reply to H.J. Lu from comment #9)
> > [hjl@gnu-mic-1 build_base_lto.]$
> > /export/gnu/import/git/gcc-test-spec-lto/usr/bin/g++ -S -DSPEC_CPU -DNDEBUG 
> > -DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom
> > -Ixercesc/dom/impl -Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory
> > -Ixercesc/util/Transcoders/Iconv -Ixalanc/include -DPROJ_XMLPARSER
> > -DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM
> > -DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER
> > -O2-DSPEC_CPU_LP64  -DSPEC_CPU_LINUX XPath.cpp  -ffast-math
> > In file included from ./XPathDefinitions.hpp:21,
> >  from XPath.hpp:22,
> >  from XPath.cpp:18:
> > XPath.cpp: In member function ‘void
> > xalanc_1_8::XPath::executeMore(xalanc_1_8::XalanNode*,
> > xalanc_1_8::XPath::OpCodeMapPositionType,
> > xalanc_1_8::XPathExecutionContext&, xalanc_1_8::FormatterListener&,
> > xalanc_1_8::XPath::MemberFunctionPtr) const’:
> > ./PlatformDefinitions.hpp:66:35: internal compiler error: Segmentation fault
> >66 |  #define XALAN_CPP_NAMESPACE_END  }
> >   |   ^
> > XPath.cpp:5696:1: note: in expansion of macro ‘XALAN_CPP_NAMESPACE_END’
> >  5696 | XALAN_CPP_NAMESPACE_END
> >   | ^~~
> > 0xfbcc0f crash_signal
> > ../../src-trunk/gcc/toplev.c:326
> > 0xb26b73 lookup_page_table_entry
> > ../../src-trunk/gcc/ggc-page.c:632
> > 0xb26b73 ggc_set_mark(void const*)
> > ../../src-trunk/gcc/ggc-page.c:1531
> > 0xd6a781 gt_ggc_mx_symtab_node(void*)
> > /export/gnu/import/git/gcc-test-spec-lto/bld/gcc/gtype-desc.c:1302
> > 0xee51fd gt_ggc_ma_order
> > ./gt-passes.h:31
> > 0xee51fd gt_ggc_ma_order
> > ./gt-passes.h:26
> > 0xcf6995 ggc_mark_root_tab
> > ../../src-trunk/gcc/ggc-common.c:77
> > 0xcf6b9c ggc_mark_roots()
> > ../../src-trunk/gcc/ggc-common.c:94
> > 0xb274f5 ggc_collect()
> > ../../src-trunk/gcc/ggc-page.c:2201
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > Please include the complete backtrace with any bug report.
> > See  for instructions.
> > [hjl@gnu-mic-1 build_base_lto.]$ 
> > 
> > -O2 -ffast-math is needed to trigger ICE.
> 
> Hm, I can't reproduce that. How have you configured the compiler?

I used:

 --enable-clocale=gnu --with-system-zlib --enable-shared --enable-cet
--with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran,lto

[Bug c/91401] schedule + dist_schedule clauses rejected on distribute parallel for

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-08
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c/91401] New: schedule + dist_schedule clauses rejected on distribute parallel for

[jakub at gcc dot gnu.org]

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

Bug ID: 91401
   Summary: schedule + dist_schedule clauses rejected on
distribute parallel for
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

void
foo (void)
{
  int i;
  #pragma omp distribute parallel for schedule (static) dist_schedule (static)
  for (i = 0; i < 64; i++)
;
}

is incorrectly rejected due to a typo.

[Bug c++/87519] -Wsign-conversion -Wconversion explicit cast fails to silence warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek  ---
Fixed on trunk, will backport to 9.3 later.

[Bug c++/87519] -Wsign-conversion -Wconversion explicit cast fails to silence warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Author: mpolacek
Date: Thu Aug  8 15:37:46 2019
New Revision: 274211

URL: https://gcc.gnu.org/viewcvs?rev=274211=gcc=rev
Log:
PR c++/87519 - bogus warning with -Wsign-conversion.
* typeck.c (cp_build_binary_op): Use same_type_p instead of comparing
the types directly.

* g++.dg/warn/Wsign-conversion-5.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wsign-conversion-5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/91400] New: __builtin_cpu_supports conjunction is optimized poorly

[vanyacpp at gmail dot com]

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

Bug ID: 91400
   Summary: __builtin_cpu_supports conjunction is optimized poorly
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

Clang 8 optimizes both f() and g() to the same code:

bool f()
{
return __builtin_cpu_supports("popcnt") && __builtin_cpu_supports("ssse3");
}

bool g()
{
extern unsigned int cpu_model;
return (cpu_model & 64) && (cpu_model & 4);
}

f()/g():
mov eax, dword ptr [rip + cpu_model]
and eax, 68
cmp eax, 68
seteal
ret

GCC generates this code only for g(). For f() GCC generates less optimal:

f():
mov edx, DWORD PTR __cpu_model[rip+12]
mov eax, edx
shr eax, 6
and eax, 1
and edx, 4
mov edx, 0
cmove   eax, edx
ret

I believe it would be great if GCC is able to generate the same code for f()
too.

[Bug target/91399] New: parse_mtune_ctrl_str shouldn't use ix86_tune_ctrl_string

[hjl.tools at gmail dot com]

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

Bug ID: 91399
   Summary: parse_mtune_ctrl_str shouldn't use
ix86_tune_ctrl_string
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i386

There are

static void 
parse_mtune_ctrl_str (bool dump)
{
  if (!ix86_tune_ctrl_string)
return;

parse_mtune_ctrl_str is only called from set_ix86_tune_features, which
is only called from ix86_function_specific_restore and
ix86_option_override_internal.  parse_mtune_ctrl_str shouldn't use
ix86_tune_ctrl_string which is defined with global_options.  Instead,
opts should be passed to parse_mtune_ctrl_str:

diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
index 8e7c9c8363a2..b9d526ecc9d5 100644
--- a/gcc/config/i386/i386-options.c
+++ b/gcc/config/i386/i386-options.c
@@ -655,7 +655,8 @@ ix86_option_override_internal (bool main_args_p,
   struct gcc_options *opts,
   struct gcc_options *opts_set);
 static void
-set_ix86_tune_features (enum processor_type ix86_tune, bool dump);
+set_ix86_tune_features (struct gcc_options *opts,
+   enum processor_type ix86_tune, bool dump);

 /* Restore the current options */

@@ -730,7 +731,7 @@ ix86_function_specific_restore (struct gcc_options *opts,

   /* Recreate the tune optimization tests */
   if (old_tune != ix86_tune)
-set_ix86_tune_features (ix86_tune, false);
+set_ix86_tune_features (opts, ix86_tune, false);
 }

 /* Adjust target options after streaming them in.  This is mainly about
@@ -1458,13 +1464,13 @@ ix86_parse_stringop_strategy_string (char
*strategy_str, bool is_memset)
print the features that are explicitly set.  */

 static void
-parse_mtune_ctrl_str (bool dump)
+parse_mtune_ctrl_str (struct gcc_options *opts, bool dump)
 {
-  if (!ix86_tune_ctrl_string)
+  if (!opts->x_ix86_tune_ctrl_string)
 return;

   char *next_feature_string = NULL;
-  char *curr_feature_string = xstrdup (ix86_tune_ctrl_string);
+  char *curr_feature_string = xstrdup (opts->x_ix86_tune_ctrl_string);
   char *orig = curr_feature_string;
   int i;
   do
@@ -1503,7 +1509,8 @@ parse_mtune_ctrl_str (bool dump)
processor type.  */

 static void
-set_ix86_tune_features (enum processor_type ix86_tune, bool dump)
+set_ix86_tune_features (struct gcc_options *opts,
+   enum processor_type ix86_tune, bool dump)
 {
   unsigned HOST_WIDE_INT ix86_tune_mask = HOST_WIDE_INT_1U << ix86_tune;
   int i;
@@ -1525,7 +1532,7 @@ set_ix86_tune_features (enum processor_type ix86_tune,
bool dump)
  ix86_tune_features[i] ? "on" : "off");
 }

-  parse_mtune_ctrl_str (dump);
+  parse_mtune_ctrl_str (opts, dump);
 }


@@ -2230,7 +2237,7 @@ ix86_option_override_internal (bool main_args_p,
   XDELETEVEC (s);
 }

-  set_ix86_tune_features (ix86_tune, opts->x_ix86_dump_tunes);
+  set_ix86_tune_features (opts, ix86_tune, opts->x_ix86_dump_tunes);

 #ifndef USE_IX86_FRAME_POINTER
 #define USE_IX86_FRAME_POINTER 0

[Bug c++/87519] -Wsign-conversion -Wconversion explicit cast fails to silence warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #10 from Marek Polacek  ---
Tested fine:
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00553.html

[Bug lto/91376] g++.dg/lto/pr90990 FAILs with gld 2.32.51

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Martin Liška  ---
> (In reply to Martin Liška from comment #6)
>> Good, then let me take a look.
>
> So I've just tested current master of binutils and I can see:
>
> marxin@marxinbox:/tmp> gcc --version
> gcc (GCC) 10.0.0 20190806 (experimental)
> 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.
>
> marxin@marxinbox:/tmp> gcc -c -flto main.c
>
> $ nm main.o
> nm: main.o: plugin needed to handle lto object
> 0001 C __gnu_lto_slim
>
> The issue here is that the installed nm can't load plugin from bfd-plugins:
>
> $ strace -f -s512 nm main.o 2>&1 | grep plugin
> openat(AT_FDCWD, "/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins",
> O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
> stat("/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins/..",
> {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> stat("/home/marxin/bin/binutils/bin/../bin/../lib/bfd-plugins/.",
> {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> write(2, "main.o: plugin needed to handle lto object", 42main.o: plugin needed
> to handle lto object) = 42
>
> $ nm --plugin /dev/shm/objdir/lto-plugin/.libs/liblto_plugin.so.0.0.0 main.o
>  T main
>
> So the question is if you have a LTO plugin accessible for the built gold or
> nm?

I don't see how nm would come into play here.  For one, I've only
installed gas and gld from binutils trunk under non-standard names
(gas-2.32.51 and gld-2.32.51) and use them via --with-as and --with-ld.

The failing testcases boils down to (run in gcc/testsuite/g++):

#!/bin/sh

COLLECT_GCC=../../xg++ \
COLLECT_GCC_OPTIONS= \
COLLECT_LTO_WRAPPER=../../lto-wrapper \
COMPILER_PATH=../.. \
\
/vol/gcc/bin/gld-2.32.51 \
  -plugin ../../liblto_plugin.so \
  -plugin-opt=../../lto-wrapper \
  -plugin-opt=-fresolution=cp_lto_pr90990_0.res \
  -plugin-opt=-v \
  -plugin-opt=-save-temps \
  -o g++-dg-lto-pr90990-01.exe -r cp_lto_pr90990_0.o

$ gld.cmd 
../../lto-wrapper -fresolution=cp_lto_pr90990_0.res -flinker-output=rel
cp_lto_pr90990_0.o 
/vol/gcc/bin/gld-2.32.51: /var/tmp//ccKkavFd.lto.o: plugin needed to handle lto
object
[Leaving g++-dg-lto-pr90990-01.exe.lto_wrapper_args]
[Leaving /var/tmp//ccKkavFd.lto.o]

When I run this under truss (Solaris equivalent of strace), I find just
the following calls to execve:

12815:  execve("../../lto-wrapper", 0xFEFFD6F4, 0xFEFFD844)  argc = 2
12815:   argv: ../../lto-wrapper
12815:@g++-dg-lto-pr90990-01.exe.lto_wrapper_args

12817:  execve("../../xg++", 0xFEFFD5A4, 0xFEFFD990)  argc = 2
12817:   argv: ../../xg++ @/var/tmp//ccxh7UCb

12819:  execve("../../lto1", 0x08189FD0, 0x08187784)  argc = 19
12819:   argv: ../../lto1 -quiet -dumpbase cp_lto_pr90990_0.o
12819:-mtune=generic -march=pentium4 -auxbase-strip
12819:/var/tmp//ccKkavFd.lto.o -O0 -fno-openmp -fno-openacc
12819:-fno-pie -fno-diagnostics-show-caret
12819:-fno-diagnostics-show-line-numbers
12819:-fresolution=cp_lto_pr90990_0.res -flinker-output=rel
12819:@/var/tmp//ccsvXE.b -o /var/tmp//ccM632hc.s

12821:  execve("/vol/gcc/bin/gas-2.32.51", 0x08189FD0, 0x08187784)  argc = 7
12821:   argv: /vol/gcc/bin/gas-2.32.51 -Qy -s --32 -o
12821:/var/tmp//ccKkavFd.lto.o /var/tmp//ccM632hc.s

There's no nm anywhere in sight.  Besides, I find it very strange that
out of hundreds if not thousends of LTO tests during this bootstrap,
only a single one shows this error.  If there were a fundamental
problem, I'd expect a way larger number here.

[Bug c/91398] New: Possible missed optimization: Can a pointer be passed as hidden pointer in x86-64 System V ABI

[no...@turm-lahnstein.de]

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

Bug ID: 91398
   Summary: Possible missed optimization: Can a pointer be passed
as hidden pointer in x86-64 System V ABI
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: no...@turm-lahnstein.de
  Target Milestone: ---

For the following example:

struct Vec3{
double x, y, z;
};

struct Vec3 do_something(void);

void use(struct Vec3 *restrict out){
*out = do_something();
}

The resulting assembly (-O2) is:

use:
pushq   %rbx
movq%rdi, %rbx
subq$32, %rsp
movq%rsp, %rdi
calldo_something
movdqu  (%rsp), %xmm0
movq16(%rsp), %rax
movups  %xmm0, (%rbx)
movq%rax, 16(%rbx)
addq$32, %rsp
popq%rbx
ret

Here on godbolt: https://godbolt.org/z/kUPFox

However, as out is restrict, it could be passed as hidden pointer to
do_something, which would lead to the following assembler:

use:
jmp do_something ; %rdi is now the hidden pointer

So is it a missed optimization, or is there something in x86-64 System V ABI
that would forbid the above?

[Bug c++/91397] -Wstringop-overflow specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807

[steinar+gcc at gunderson dot no]

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

--- Comment #9 from Steinar H. Gunderson  ---
Putting this at the start of mem_strdupl() suppresses the warning:

  if (len + 1 == 0) __builtin_unreachable();

This seemingly also does:

  if (static_cast(len) < 0) __builtin_unreachable();

So somehow, even though it knows that path >= last_slash (from before), it
doesn't know that last_slash - path >= 0. I don't know how easy or hard this is
to infer.

[Bug c++/91397] -Wstringop-overflow specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807

[steinar+gcc at gunderson dot no]

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

--- Comment #8 from Steinar H. Gunderson  ---
But all of those conditions include last_slash > path.

I tried adding this just before the mem_strdupl() call:

  if (last_slash < path) {
ib::fatal() << "Logic error.";
__builtin_unreachable();
  }

and the warning still triggers.

[Bug middle-end/91358] Wrong code with dynamic allocation and optional like class

[matz at gcc dot gnu.org]

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

--- Comment #7 from Michael Matz  ---
(In reply to Antony Polukhin from comment #6)
> (In reply to Michael Matz from comment #3)
> > I don't really see any, no good idea here :-/
> 
> How about moving all the optimizations based on reading uninitialized values
> under a flag like -funinitialized-logic, so that users could build with -O2
> -fno-uninitialized-logic ?

That can't work in general.  How would you propose that GCC automagically
detects that in:

struct S {int a, b;};
int foo (struct S *s) { return s->a ? s->b : 0; }

the read of ->b is uninitialized?  After all, it might have been initialized
by the caller or not.

[Bug c++/91397] -Wstringop-overflow specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807

[glisse at gcc dot gnu.org]

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

--- Comment #7 from Marc Glisse  ---
(In reply to Steinar H. Gunderson from comment #6)
> So basically GCC is worried that I might be calling allocate() with -1
> bytes, and gives a warning?

Yes, although it might not always give the warning, depends on various
heuristics.

> last_slash presumably has to be >= path, given that it comes out of
> strrchr().

It doesn't directly, there is a lot of last_slash-- with various conditions.

[Bug tree-optimization/91178] [9 Regression] Infinite recursion in split_constant_offset in slp after r260289

[belyshev at depni dot sinp.msu.ru]

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

--- Comment #16 from Serge Belyshev  ---
(In reply to Vsevolod Livinskiy from comment #15)
> I don't know if it is the same error or not, but the reproducer looks
> similar.

This one is different.  It does not fail for me with -O3 -march=skylake-avx512,
just slow and consumes over 1G of memory.

But with just "-O3" it blows up the stack during predictive commoning pass via 
follow_ssa_edge tree-scalar-evolution.c:1350 --> follow_ssa_edge_in_rhs
tree-scalar-evolution.c:1135 -->  follow_ssa_edge_binary
tree-scalar-evolution.c:947 --> follow_ssa_edge tree-scalar-evolution.c:1350 
recursion.

Git bisect points at r256634.

[Bug middle-end/91358] Wrong code with dynamic allocation and optional like class

[antoshkka at gmail dot com]

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

--- Comment #6 from Antony Polukhin  ---
(In reply to Michael Matz from comment #3)
> I don't really see any, no good idea here :-/

How about moving all the optimizations based on reading uninitialized values
under a flag like -funinitialized-logic, so that users could build with -O2
-fno-uninitialized-logic ?

[Bug driver/91396] Link error when I use -fvtable-verify=std and -static

[niva at niisi dot msk.ru]

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

niva at niisi dot msk.ru changed:

   What|Removed |Added

Version|unknown |7.4.0

--- Comment #1 from niva at niisi dot msk.ru ---
I've also noticed that small programs (tests) built with "vtable-verify
enabled" gcc work slower than programs built with default gcc (even when the
-fvtable-verify option is not used). This slowdown mostly concerns dynamically
linked programs.

[Bug c++/91397] -Wstringop-overflow specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807

[steinar+gcc at gunderson dot no]

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

--- Comment #6 from Steinar H. Gunderson  ---
So basically GCC is worried that I might be calling allocate() with -1 bytes,
and gives a warning?

last_slash presumably has to be >= path, given that it comes out of strrchr().
But maybe GCC won't know that.

[Bug target/91052] [10 Regression] ICE in fix_reg_equiv_init, at ira.c:2705

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-08
 CC||linkw at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to work||9.1.0
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #2 from Martin Liška  ---
Started with r272731.

[Bug c++/91397] -Wstringop-overflow specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
mem_strdupl calls allocate(len+1). If len+1 is 0, you proceed to write to
s[len] i.e. 0[-1]. I think gcc would be happier if you handled this special
case explicitly (you could error, trap, just assume it cannot happen
(__builtin_unreachable), whatever).

This type of warning can easily give false positives if your code is written
with invariants in mind that are not visible enough to the compiler.

If you had been writing to address 0, gcc would have detected that as a trap,
but it doesn't do anything special for -1.

[Bug target/91306] [MSP430] libgcc/crtstuff.c: Alignment of frame_dummy .init_array entry is too big

[jozefl.gcc at gmail dot com]

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

--- Comment #4 from Jozef Lawrynowicz  ---
Should I submit a patch which changes uses of sizeof in alignment attributes to
__alignof__? Or are you working on it?

[Bug c++/90313] [7/8/9/10 Regression] Is an assignment elided with gcc7.3 -O2?

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||marxin at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r242668.
@Richard S. Can you please take a look?

[Bug c++/91397] -Wstringop-overflow specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
I guess it happens in some dead path that gcc doesn't know is dead. At some
point, you look at last_slash-path+1. Here there is a branch on whether this
number is 0, and if it is 0, nonsense happens (writing 0 at address -1, this
huge memcpy, etc). Maybe you know that last_slash is always >= path (so this
weird code path is dead) and gcc doesn't?

[Bug c++/91397] -Wstringop-overflow specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807

[steinar+gcc at gunderson dot no]

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

--- Comment #3 from Steinar H. Gunderson  ---
Yes, the reduced one is awkward. Thus the unreduced one :-)

[Bug c++/91397] -Wstringop-overflow specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
if (g == 0) return (char *)malloc(0);
for (;;)
;

so the only way this can return is if g is 0. This means that in j, k is -1,
and you are calling memcpy with a huge argument. So at least in the reduced
testcase, the warning makes some sense.

[Bug libstdc++/90415] [9/10 Regression] std::is_copy_constructible> is incomplete

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Lei YU from comment #6)
> @Jonathan Wakely Is there a quick fix for this? I would like to test it.

If I had a fix I would have committed it.

[Bug c++/91397] -Wstringop-overflow specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807

[steinar+gcc at gunderson dot no]

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

--- Comment #1 from Steinar H. Gunderson  ---
Created attachment 46689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46689=edit
Unreduced test case

[Bug c++/91397] New: -Wstringop-overflow specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807

[steinar+gcc at gunderson dot no]

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

Bug ID: 91397
   Summary: -Wstringop-overflow specified bound
18446744073709551615 exceeds maximum object size
9223372036854775807
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steinar+gcc at gunderson dot no
  Target Milestone: ---

Hi,

We saw this coming only with GCC 10 (probably different inlining decisions),
but the reduced test case also triggers with 9, so I'm going to file it against
9.1.0.

This test case is reduced from MySQL 8.0 (osfile0.cc):

#include 
#include 

char *allocate(unsigned long g) {
if (g == 0) return (char *)malloc(0);
for (;;)
;
} 

char *i;
char *j(long k) {
char *l(allocate(k + 1));
memcpy(l, i, k);
return l;
} 

atum17:~> g++-9 -O2 -Wstringop-overflow -c os0file.cc
os0file.cc: In function ‘char* j(long int)’:
os0file.cc:12:9: warning: ‘void* memcpy(void*, const void*, size_t)’ specified
bound 18446744073709551615 exceeds maximum object size 9223372036854775807
[-Wstringop-overflow=]
   12 |   memcpy(l, i, k);
  |   ~~^

I don't even understand what the warning means (“specified bound” of what?),
but it looks spurious to me. Perhaps some signed/unsigned confusion?

Since the reduction is somewhat nonsensical with the empty infinite loop in
there, I'm also including an unreduced test case. With GCC 9.1.0 and -O2, it
gives the same warning.

[Bug driver/91396] New: Link error when I use -fvtable-verify=std and -static

[niva at niisi dot msk.ru]

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

Bug ID: 91396
   Summary: Link error when I use -fvtable-verify=std and -static
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: niva at niisi dot msk.ru
  Target Milestone: ---

I have built gcc-7.4.0 with --enable-vtable-verify for x86_64 under Fedora 27:

$HOME/src/gcc-7.4.0/configure --srcdir=$HOME/src/gcc-7.4.0 --verbose
--enable-vtable-verify --enable-languages=c,c++,fortran --enable-lto
--prefix=$HOME/local-gcc

When I run:

$ ~/local-gcc/bin/g++ -fvtable-verify=std -O2 -static t.C -o t.exe

the following error occurs:

~/local-gcc/lib/gcc/x86_64-pc-linux-gnu/7.4.0/vtv_end.o: In function
`__VLTprotect':
vtv_end.c:(.text.startup+0x0): multiple definition of `__VLTprotect'
~/local-gcc/lib/gcc/x86_64-pc-linux-gnu/7.4.0/../../../../lib64/libvtv.a(vtv_end.o):~/build/native-gcc/x86_64-pc-linux-gnu/libvtv/vtv_end.c:59:
first defined here

$ cat t.C
int main () {return 0;}

I have fixed the problem by deleting vtv_end.o from
~/local-gcc/lib64/libvtv.a but I'm not sure it's OK.

[Bug c/91392] g++: internal compiler error: Aborted (program cc1plus)

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
I would try any of these:
https://mingw-w64.org/doku.php/download

[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)

[rguenther at suse dot de]

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

--- Comment #37 from rguenther at suse dot de  ---
On August 8, 2019 3:35:26 AM GMT+02:00, "luoxhu at cn dot ibm.com"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
>--- Comment #34 from Xiong Hu XS Luo  ---
>(In reply to rguent...@suse.de from comment #32)
>> On Mon, 5 Aug 2019, luoxhu at cn dot ibm.com wrote:
>> 
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>> > 
>> > --- Comment #31 from Xiong Hu XS Luo  ---
>> > (In reply to rguent...@suse.de from comment #30)
>> > > On Fri, 2 Aug 2019, luoxhu at cn dot ibm.com wrote:
>> > > 
>> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>> > > > 
>> > > > --- Comment #28 from Xiong Hu XS Luo 
>---
>> > > > (In reply to Richard Biener from comment #24)
>> > > > > Btw, this is controlled by
>symtab_node::output_to_lto_symbol_table_p which
>> > > > > has
>> > > > > 
>> > > > >   /* FIXME: Builtins corresponding to real functions probably
>should have
>> > > > >  symbol table entries.  */
>> > > > >   if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p
>(decl))
>> > > > > return false;
>> > > > > 
>> > > > > we could try to do sth like
>> > > > > 
>> > > > >   if (TREE_CODE (decl) == FUNCTION_DECL
>> > > > >   && (fndecl_built_in_p (decl, BUILT_IN_MD)
>> > > > >   || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
>> > > > >   && !associated_internal_fn (decl
>> > > > > return false;
>> > > > > 
>> > > > > but that would still leave us with too many undefineds I
>guess
>> > > > > (gcc_unreachable for one).
>> > > > > 
>> > > > > We do not currently track builtins that do have a library
>implementation
>> > > > > (whether that it is used in the end is another thing, but
>less important).
>> > > > > 
>> > > > > What we definitely can do is put a whitelist above like via
>the following
>> > > > > which also catches the case of definitions of builtins.
>> > > > > 
>> > > > > Index: gcc/symtab.c
>> > > > >
>===
>> > > > > --- gcc/symtab.c(revision 273968)
>> > > > > +++ gcc/symtab.c(working copy)
>> > > > > @@ -2375,10 +2375,24 @@
>symtab_node::output_to_lto_symbol_table_
>> > > > >   first place.  */
>> > > > >if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
>> > > > >  return false;
>> > > > > +
>> > > > >/* FIXME: Builtins corresponding to real functions
>probably should have
>> > > > >   symbol table entries.  */
>> > > > > -  if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p
>(decl))
>> > > > > -return false;
>> > > > > +  if (TREE_CODE (decl) == FUNCTION_DECL
>> > > > > +  && !definition
>> > > > > +  && fndecl_built_in_p (decl))
>> > > > > +{
>> > > > > +  if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
>> > > > > +   switch (DECL_FUNCTION_CODE (decl))
>> > > > > + {
>> > > > > + CASE_FLT_FN (BUILT_IN_ATAN2):
>> > > > > + CASE_FLT_FN (BUILT_IN_SIN):
>> > > > > +   return true;
>> > > > > + default:
>> > > > > +   break;
>> > > > > + }
>> > > > > +  return false;
>> > > > > +}
>> > > > >  
>> > > > >/* We have real symbol that should be in symbol table. 
>However try to
>> > > > > trim
>> > > > >   down the refernces to libraries bit more because linker
>will otherwise
>> > > > 
>> > > > Hi Richard, no undefineds generated with below code, what's
>your opinion about
>> > > > the updated code, please? Thanks.
>> > > 
>> > > It will break code calling __builtin_unreachable for example
>since
>> > > we'll emit an UNDEF that cannot be satisfied.
>> > 
>> > Thanks. I tried to add __builtin_unreachable() in the test case, it
>can also
>> > works. As BUILT_IN_UNREACHABLE is defined in buitins.def instead of
>> > internal-fn.def, so associated_internal_fn will return IFN_LAST for
>it, then no
>> > UNDEF of __builtin_unreachable will be emitted to object file.
>> > 
>> > Most of functions in internal-fn.def are math functions, I am not
>sure whether
>> > you mean the BUILT_IN_NOP or something else?
>> 
>> OK, so a specific example woul dbe __builtin_clz.  IIRC the
>> DECL_ASSEMBLER_NAME of the functions which have a libgcc fallback is
>> _not_ the symbol in libgcc (you'd have to double-check).
>> 
>> That said, using associated_internal_fn is probably mostly safe but
>> not a complete fix since we have builtins like __builtin_strcpy
>> as well (but of course the C library is always linked).
>> 
>> But I'm fine with an approach that incrementally improves things
>> here, but without possibly causing link-failures due to bogus
>> UNDEFs
>
>Add x = __builtin_clz(x); and __builtin_strcpy(str, "test\n") to the
>test code,
>the object file's symbol will be:
>luoxhu@genoa lto $ ~/workspace/gcc-git/gcc-master_debug/gcc/gcc-nm
>-B/home/luoxhu/workspace/gcc-git/gcc-master_debug/gcc/ atan2bashzowie.o
> U atan2
> U __builtin_clz

That shows 

[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)

[rguenther at suse dot de]

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

--- Comment #36 from rguenther at suse dot de  ---
On August 8, 2019 10:27:38 AM GMT+02:00, "rsandifo at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
>rsandifo at gcc dot gnu.org  changed:
>
>   What|Removed |Added
>
>CC||rsandifo at gcc dot gnu.org
>
>--- Comment #35 from rsandifo at gcc dot gnu.org gnu.org> ---
>I might be missing the point, but tying this decision to internal
>functions seems conceptually wrong.  The main distinguishing
>feature of internal functions is that they're purely compiler-
>internal and have no linkage.  It seems odd to use them to decide
>whether a built-in function actually does have linkage. ;-)

Yes indeed. Fact is we do not have the information whether a builtin has
linkage or not readily available. 

>E.g. we only really have an internal function for things like
>atan2 because of (the rarely used?) -mfancy-math-387.  We should
>be free to remove the internal function if we ever drop the
>associated 387 support.

[Bug c/91392] g++: internal compiler error: Aborted (program cc1plus)

[harry.onslow at emenda dot com]

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

--- Comment #2 from Harry Onslow  ---
Hi Martin,

Thanks for the message. I will try a newer version - Could you please advise on
where I can download the latest release please?

Regards,
Harry

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||10.0, 9.1.0

--- Comment #19 from Martin Liška  ---
Good I can confirm the patch works for the package!

[Bug middle-end/91395] Report an uninitialized variable on its initialization statement (setjmp)

[ali at pivotal dot io]

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

--- Comment #4 from Adam  ---
(In reply to Andrew Pinski from comment #3)
> In theory other can cause a call to longjmp but gcc does not know it cannot.

Thanks for the quick reply.

I got the longjmp() part, it could be called anytime. The part I don't get is
why it reports since gcc could tell that no one changes the
save_exception_stack (it has a certain short life).

The POSIX's statement as I know has two facts: "a local not-volatile variable"
and "it's been changed between setjmp() and longjmp()". Have I missed anything?

[Bug bootstrap/91352] [10 Regression] Jobserver detection uses fcntl, which is not available on mingw-w64

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Should be fixed now.

[Bug rtl-optimization/66087] Invalid narrowing of MEM with containing POST_INC

[mikpelinux at gmail dot com]

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

--- Comment #4 from Mikael Pettersson  ---
Still miscompiled by gcc-10.0, 9.1, and 8.3 at -O1 and above.

[Bug sanitizer/91389] [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Forgot to say, if you are just looking for a workaround for the warning (note,
-O2 -Wreturn-type doesn't warn, in this case you need also no optimizations),
then I'd just move the return from the default: clause to after the switch if
the package maintainers insist on their weird coding conventions.

[Bug sanitizer/91389] [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Martin Liška from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > I see dead code everywhere in the function, they must have some weirdo 
> > > macro
> > > for cases that wraps everything in case something { ... } break;
> > 
> > Is the 'break;' really dead in such situation (when you don't have a return
> > or another break within the {} block)?
> > 
> > > Many of those break; statements are dead code.
> 
> It is dead when you do have an unconditional return in there.  As I said in
> the other PR, we try hard to do a good job with block_may_fallthru and
> gimple_seq_may_fallthru, but it can't handle everything, feel free to
> improve those.  And all -fsanitize=thread does is it adds a cleanup code,
> the same thing as you get if you have an automatic variable with a
> destructor.
> 
> *** This bug has been marked as a duplicate of bug 86899 ***

Sure, thank you for your time.

[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #35 from rsandifo at gcc dot gnu.org  
---
I might be missing the point, but tying this decision to internal
functions seems conceptually wrong.  The main distinguishing
feature of internal functions is that they're purely compiler-
internal and have no linkage.  It seems odd to use them to decide
whether a built-in function actually does have linkage. ;-)

E.g. we only really have an internal function for things like
atan2 because of (the rarely used?) -mfancy-math-387.  We should
be free to remove the internal function if we ever drop the
associated 387 support.

[Bug sanitizer/86899] [8/9/10 regression] TSAN incorrect warning: control reaches end of non-void function

[jakub at gcc dot gnu.org]

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

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

[Bug sanitizer/91389] [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > I see dead code everywhere in the function, they must have some weirdo macro
> > for cases that wraps everything in case something { ... } break;
> 
> Is the 'break;' really dead in such situation (when you don't have a return
> or another break within the {} block)?
> 
> > Many of those break; statements are dead code.

It is dead when you do have an unconditional return in there.  As I said in the
other PR, we try hard to do a good job with block_may_fallthru and
gimple_seq_may_fallthru, but it can't handle everything, feel free to improve
those.  And all -fsanitize=thread does is it adds a cleanup code, the same
thing as you get if you have an automatic variable with a destructor.

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

[Bug middle-end/91395] Report an uninitialized variable on its initialization statement (setjmp)

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
In theory other can cause a call to longjmp but gcc does not know it cannot.

[Bug libstdc++/90415] [9/10 Regression] std::is_copy_constructible> is incomplete

[mine260309 at gmail dot com]

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

--- Comment #7 from Lei YU  ---
Additional information.

std::experimental::fundamentals_v1::any has no problem, so the below code
compiles fine.

```
#include 
#include 
#include 

bool is_copy_constructible_tuple_any() {
return
std::is_copy_constructible>::value;
}
```

[Bug sanitizer/91389] [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #3)
> I see dead code everywhere in the function, they must have some weirdo macro
> for cases that wraps everything in case something { ... } break;

Is the 'break;' really dead in such situation (when you don't have a return or
another break within the {} block)?

> Many of those break; statements are dead code.

[Bug sanitizer/91389] [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I see dead code everywhere in the function, they must have some weirdo macro
for cases that wraps everything in case something { ... } break;
Many of those break; statements are dead code.

[Bug bootstrap/91352] [10 Regression] Jobserver detection uses fcntl, which is not available on mingw-w64

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Thu Aug  8 07:50:28 2019
New Revision: 274208

URL: https://gcc.gnu.org/viewcvs?rev=274208=gcc=rev
Log:
Fix file descriptor existence of MinGW.

2019-08-08  Martin Liska  

PR bootstrap/91352
* gcc.c (driver::detect_jobserver): Use is_valid_fd.
* lto-wrapper.c (jobserver_active_p): Likewise.
2019-08-08  Martin Liska  

PR bootstrap/91352
* libiberty.h (is_valid_fd): New function.
2019-08-08  Martin Liska  

PR bootstrap/91352
* lrealpath.c (is_valid_fd): New function.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcc.c
trunk/gcc/lto-wrapper.c
trunk/include/ChangeLog
trunk/include/libiberty.h
trunk/libiberty/ChangeLog
trunk/libiberty/lrealpath.c

[Bug middle-end/91395] Report an uninitialized variable on its initialization statement (setjmp)

[ali at pivotal dot io]

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

--- Comment #2 from Adam  ---
I got the point "The local variables that do not have the volatile type and
have been changed between the setjmp() invocation and longjmp() call are
indeterminate"

But save_exception_stack is not changed between the setjmp() invocation and
longjmp() call, it is defined every time. Still looks expected?

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
(In reply to Richard Earnshaw from comment #17)
> Created attachment 46686 [details]
> candidate patch
> 
> Could you try this patch please?  So far only very lightly tested.

Sure, I'll test the problematic package build with your patch.

[Bug libgcc/91379] internal compiler error __gcov_fork

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Clinton Bunch from comment #2)
> As I stated, I've tried to compile 4.9.4, 5.3.0, 5.5.0, 6.1.0, 6.5.0 and
> 8.3.0 I get the same error on all of them.  I reported on 9.1.0 as it is the
> current version.  I can't get a gcc more recent than 4.9.2 to even attempt a
> build and none of these versions will compile with the HP C/C++ compiler.

Then the only option is to build host compiler with -O0. That can be done with:
make all-host -k CFLAGS="-O0 -g" CXXFLAGS="-O0 -g"

then you'll be hopefully able to build runtime libraries.

[Bug sanitizer/91389] [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 46688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46688=edit
Original test-case

I'm fine with the approach to remove a dead code. However, I can't easily find
what to change in the original source file. The warning location does not help
much.

[Bug c/91392] g++: internal compiler error: Aborted (program cc1plus)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Note that GCC 6 is out of support. Please try a newer release.

[Bug lto/91393] lto1: internal compiler error: decompressed stream: Destination buffer is too small

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Can you please provide the objects files so that I can reproduce it?
Which GCC version do you use?

[Bug middle-end/91395] Report an uninitialized variable on its initialization statement (setjmp)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |middle-end
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
The warning is correct due to the way sigsetjmp works.
You need to mark save_exception_stack as volatile to fix the issue.

Basically any non-volatile variable in the function scope can be incorrect. 
This is what the POSIX (and C standard for setjmp) says.  GCC is just taking
into account this now.

[Bug c++/91334] [10 Regression] ICE in propagate_necessity at gcc/tree-ssa-dce.c:813 since r273791

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
(In reply to H.J. Lu from comment #9)
> [hjl@gnu-mic-1 build_base_lto.]$
> /export/gnu/import/git/gcc-test-spec-lto/usr/bin/g++ -S -DSPEC_CPU -DNDEBUG 
> -DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom
> -Ixercesc/dom/impl -Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory
> -Ixercesc/util/Transcoders/Iconv -Ixalanc/include -DPROJ_XMLPARSER
> -DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM
> -DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER
> -O2-DSPEC_CPU_LP64  -DSPEC_CPU_LINUX XPath.cpp  -ffast-math
> In file included from ./XPathDefinitions.hpp:21,
>  from XPath.hpp:22,
>  from XPath.cpp:18:
> XPath.cpp: In member function ‘void
> xalanc_1_8::XPath::executeMore(xalanc_1_8::XalanNode*,
> xalanc_1_8::XPath::OpCodeMapPositionType,
> xalanc_1_8::XPathExecutionContext&, xalanc_1_8::FormatterListener&,
> xalanc_1_8::XPath::MemberFunctionPtr) const’:
> ./PlatformDefinitions.hpp:66:35: internal compiler error: Segmentation fault
>66 |  #define XALAN_CPP_NAMESPACE_END  }
>   |   ^
> XPath.cpp:5696:1: note: in expansion of macro ‘XALAN_CPP_NAMESPACE_END’
>  5696 | XALAN_CPP_NAMESPACE_END
>   | ^~~
> 0xfbcc0f crash_signal
>   ../../src-trunk/gcc/toplev.c:326
> 0xb26b73 lookup_page_table_entry
>   ../../src-trunk/gcc/ggc-page.c:632
> 0xb26b73 ggc_set_mark(void const*)
>   ../../src-trunk/gcc/ggc-page.c:1531
> 0xd6a781 gt_ggc_mx_symtab_node(void*)
>   /export/gnu/import/git/gcc-test-spec-lto/bld/gcc/gtype-desc.c:1302
> 0xee51fd gt_ggc_ma_order
>   ./gt-passes.h:31
> 0xee51fd gt_ggc_ma_order
>   ./gt-passes.h:26
> 0xcf6995 ggc_mark_root_tab
>   ../../src-trunk/gcc/ggc-common.c:77
> 0xcf6b9c ggc_mark_roots()
>   ../../src-trunk/gcc/ggc-common.c:94
> 0xb274f5 ggc_collect()
>   ../../src-trunk/gcc/ggc-page.c:2201
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> [hjl@gnu-mic-1 build_base_lto.]$ 
> 
> -O2 -ffast-math is needed to trigger ICE.

Hm, I can't reproduce that. How have you configured the compiler?

[Bug libstdc++/90415] [9/10 Regression] std::is_copy_constructible> is incomplete

[mine260309 at gmail dot com]

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

Lei YU  changed:

   What|Removed |Added

 CC||mine260309 at gmail dot com

--- Comment #6 from Lei YU  ---
This issue prevents using std::any with gmock, which I need it for the unit
tests to pass the build.

There are related SO questions:
*
https://stackoverflow.com/questions/57332965/incomplete-type-for-stdany-when-gmocking-interface
*
https://stackoverflow.com/questions/57387245/using-stdany-with-gmock-result-in-different-behavior-on-gcc-79

@Jonathan Wakely Is there a quick fix for this? I would like to test it.