[Bug c/100150] ice in bp_unpack_string

[krzysztof.a.nowicki+gcc at gmail dot com via Gcc-bugs]

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

Krzysztof Nowicki  changed:

   What|Removed |Added

 CC||krzysztof.a.nowicki+gcc@gma
   ||il.com

--- Comment #14 from Krzysztof Nowicki  ---
I'm seeing this very often now on my Gentoo system after upgrading from GCC
11.1 to 11.2. The cause of this ICE is well understood - the LTO bitstream is
incompatible. I however see this as a regression, as in previous GCC upgrades
the LTO linker always explicitly complained that a static library or object has
incompatible LTO data due to being built with an earlier compiler. With the
11.1 to 11.2 transition no such error happens, but the linker ICEs.

I suspect that this has happened due to introduction of an incompatible change
in the LTO bitstream without bumping the bitstream version.

This is very annoying, as previously - with the error message - it was
immediately clear which static library or object was at fault. Now with the ICE
I need to take a guess, which of one of the many libraries on the linker
command line is the problem.

[Bug ipa/101839] New: [9/10/11/12 Regression] Hand in C++ code with -fdevirtualize

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

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

Bug ID: 101839
   Summary: [9/10/11/12 Regression] Hand in C++ code with
-fdevirtualize
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Reported by leon zadorin  via email:

The following produces hanged application (busy-polling by what appears to be
calling self-method in a loop indefinitely) when, essentially, "-fdevirtualize"
is brought into play (albeit with other options possibly).

The reproduction was achieved on
Linux: gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2), x86_64-linux-gnu
and Windows: gcc version 11.1.0 (GCC), x86_64-w64-mingw32

Code compiled as:
c++ -O3 -fprofile-generate ./devirtualize.cpp

Whilst consistently reproducible ("done writing" is never printed out), the
buggy behavior is rather strange and any of the following would change/"fix"
the situation:

Taking out the anonymous namespace;
Marking BA::type() as non-final;
Taking out std::map from CA;
Adding -fno-devirtualize flag to GCC compilation flags.

Note: taking out -fprofile-generate from GCC compilation flags results in
different busy-print loop (potentially followed by segfault) i.e. different,
yet still buggy behaviour.

The repro code could be simplified even further (e.g. by taking out Buf class,
reducing number of calls to 'add', etc) and  still reproduce in gcc-9.2 on
Linux. However on gcc-11.1 on Windows it would then no longer reproduce.
So I've left the following code in its current state so as to hopefully induce
more consistent reproduction across different versions.

Here it is, devirtualize.cpp (also attached):

#include 
#include 
#include 
namespace {
  struct Buf {
char * buf; int a{0}; int b{0};
Buf(char * b) : buf(b) { }
void add(int v) {
  ::memcpy(buf, &v, sizeof(v));
  a += sizeof(v);
  b += sizeof(v);
}
  };
  struct A {
virtual void fill(Buf &buf) {
  buf.add(type());
  buf.add(type());
}
virtual ~A() {}
virtual int type() = 0;
  };
  struct BA : A {
void fill(Buf &buf) {
  A::fill(buf);
  buf.add(type());
  buf.add(type());
}
int type() final {
  return 1;
}
  };
  struct CBA final : BA {
  };
  struct CA final : A {
::std::map m;
int type() final {
  return 2;
}
  };
}
int main(int argc, char ** ) {
  char d[1024];
  CBA cba;
  ::std::cerr << "writing \n"; ::std::cerr.flush();
  Buf buf(d);
  cba.fill(buf);
  ::std::cerr << "done writing \n"; ::std::cerr.flush();
  CA ca;
}

Richi replied:

The issue also reproduces with GCC 7.5
(on Leap 15.3), -O -fprofile-generate -fdevirtualize is enough
to trigger it there.  Confirmed also with GCC 9, 10, 11 and trunk
and those options.

We hang in

Program received signal SIGINT, Interrupt.
0x004017d5 in (anonymous namespace)::A::fill (buf=..., 
this=) at t.C:16
16buf.add(type());
Missing separate debuginfos, use: zypper install 
libgcc_s1-debuginfo-10.3.0+git1587-1.6.4.x86_64 
libstdc++6-debuginfo-10.3.0+git1587-1.6.4.x86_64
(gdb) bt
#0  0x004017d5 in (anonymous namespace)::A::fill (buf=..., 
this=) at t.C:16
#1  (anonymous namespace)::BA::fill (this=this@entry=0x7fffde08, 
buf=...)
at t.C:24
#2  0x00401860 in main (argc=) at t.C:46
(gdb) s
(anonymous namespace)::BA::fill (this=this@entry=0x7fffde08, buf=...)
at t.C:24
24A::fill(buf);
(gdb) s
(anonymous namespace)::A::fill (buf=..., this=0x7fffddd8) at t.C:15
15  virtual void fill(Buf &buf) {
(gdb) s
16buf.add(type());
(gdb) s
(anonymous namespace)::BA::fill (this=this@entry=0x7fffde08, buf=...)
at t.C:24
24A::fill(buf);
(gdb) s
(anonymous namespace)::A::fill (buf=..., this=0x7fffddd8) at t.C:15
15  virtual void fill(Buf &buf) {
(gdb) s
16buf.add(type());


there is one thing that I'm not sure is allowed.  You do:

  struct A {
virtual void fill(Buf &buf) {
  buf.add(type());
  buf.add(type());
}
virtual ~A() {}
virtual int type() = 0;
  };
  struct BA : A {
void fill(Buf &buf) {
  A::fill(buf);
  buf.add(type());
  buf.add(type());
}

thus override virtual A::fill with non-virtual BA::fill.  But this
might be where the devirtualization code (or the indirect call/devirt
profiling code?) is confused.

[Bug ipa/101839] [9/10/11/12 Regression] Hand in C++ code with -fdevirtualize

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
With, -O2 -fprofile-generate -fdevirtualize, it started first with
r6-168-g5a33401eabe208e6 which might be a non-culprit commit.

[Bug ipa/101839] [9/10/11/12 Regression] Hand in C++ code with -fdevirtualize

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

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

--- Comment #2 from Martin Liška  ---
Apparently, -fprofile-generate is not needed, w/o it it started with the same
revision.

[Bug ipa/101839] [9/10/11/12 Regression] Hang in C++ code with -fdevirtualize

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11/12 Regression]
   |Hand in C++ code with   |Hang in C++ code with
   |-fdevirtualize  |-fdevirtualize
  Known to fail||10.3.0, 11.2.1, 7.5.0,
   ||9.4.0
   Target Milestone|--- |9.5
   Priority|P3  |P2

--- Comment #3 from Richard Biener  ---
BA::fill can be declared virtual without any change (it is implicitely so as
stated by the C++ standard it seems).

With GCC 11 and -O -fdevirtualize the program crashes and we see

void {anonymous}::BA::fill (struct BA * const this, struct Buf & buf)
{
   [count: 0]:
  __builtin_unreachable ();

which is from

a-t.C.083i.inline:t.C:16:14: optimized: folding virtual function call to 
__builtin_unreachable
a-t.C.083i.inline:Introduced new external node (void 
__builtin_unreachable()/1356).
a-t.C.083i.inline:t.C:17:14: optimized: folding virtual function call to 
__builtin_unreachable

[Bug c/100150] ice in bp_unpack_string

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #15 from Martin Liška  ---
(In reply to Krzysztof Nowicki from comment #14)
> I'm seeing this very often now on my Gentoo system after upgrading from GCC
> 11.1 to 11.2. The cause of this ICE is well understood - the LTO bitstream
> is incompatible. I however see this as a regression, as in previous GCC
> upgrades the LTO linker always explicitly complained that a static library
> or object has incompatible LTO data due to being built with an earlier
> compiler. With the 11.1 to 11.2 transition no such error happens, but the
> linker ICEs.

Sorry for the inconvenience.

> 
> I suspect that this has happened due to introduction of an incompatible
> change in the LTO bitstream without bumping the bitstream version.

Looking at the git diff releases/gcc-11.1.0..releases/gcc-11.2.0, I don't see
any LTO-related change that would break the LTO stream. But it may come from a
FE.

> 
> This is very annoying, as previously - with the error message - it was
> immediately clear which static library or object was at fault. Now with the
> ICE I need to take a guess, which of one of the many libraries on the linker
> command line is the problem.

Note that we automatically bump LTO major stream version among each major
version update. But minor update (branch release) needs to be done
automatically.

We would need an automatic way how to monitor LTO stream incompatibility..

[Bug ipa/101839] [9/10/11/12 Regression] Hang in C++ code with -fdevirtualize

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #3)
> BA::fill can be declared virtual without any change (it is implicitely so as
> stated by the C++ standard it seems).

Correct.

[Bug c++/101833] [9/10/11/12 Regression] ICE with -Wformat on a constructor with a virtual base

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-08-10
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r9-4163-g1d24950977c730f5.
What's strange that one needs '-Wall' in order to trigger the warning.
-Wattributes is not enough, is it correct Martin?

[Bug c++/101840] New: Friendship must be extended on default argument initializer

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 101840
   Summary: Friendship must be extended on default argument
initializer
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

The following program is correct:
```
class U{ ~U(); friend void foo(U); };
void foo(U = {});
```

But GCC rejects it with the error:
```
error: 'U::~U()' is private within this context
2 | void foo(U = {});
  |^
```
Clang and MSVC accept it:
https://gcc.godbolt.org/z/eGxYGdzj3

[Bug analyzer/101837] [11/12 Regression] ICE with -O3 -fsanitize=undefined -fanalyzer since r11-7941-ge4bb1bd60a9fd1be

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
Summary|ICE with -O3|[11/12 Regression] ICE with
   |-fsanitize=undefined|-O3 -fsanitize=undefined
   |-fanalyzer  |-fanalyzer since
   ||r11-7941-ge4bb1bd60a9fd1be

--- Comment #1 from Martin Liška  ---
Thanks for the report. Reduced test-case:

$ cat pr101837.i
void memory_exhausted();
void memcheck(void *ptr) {
  if (ptr)
memory_exhausted();
}

int emalloc(int size) { memcheck(__builtin_malloc(size)); }
int main() { int max_envvar_len = emalloc(max_envvar_len + 1); }

Started with r11-7941-ge4bb1bd60a9fd1be.

[Bug target/33437] potentially valid construct rejected

[jbeulich at suse dot com via Gcc-bugs]

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

jbeulich at suse dot com changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INVALID |---

--- Comment #3 from jbeulich at suse dot com ---
(In reply to Andrew Pinski from comment #2)
> This is not a valid C.

As per "All the expressions in an initializer for an object that has static or
thread storage duration shall be constant expressions or string literals."

long l = (long)x;

then either similarly isn't (yet the compiler accepts it), or both are (which
is my reading of the sentence, albeit further restrictions make this invalid).
Plus if it was strictly invalid, then why would a PPC compiler accept it (as
you've said yourself many years ago)?

It was for a reason that I did say  "potentially" in the title. Without knowing
what "x" is and what relocation types a target has, the compiler has no
justification to say "initializer element is not computable at load time". It
might use "may", but then it would still be overly limiting. As said in the
original description, "x" may simply stand for a small constant value, which C
does not allow to access any (meaningfully) other way than by expressing
through either an array (as in the example) or by using the address operator in
the initialization.

>  That is (int)(long)x where
> sizeof(long)!=sizeof(int)!=sizeof(void*) the linker might not know the value
> at link time and therefor will need a runtime relocation and then it might
> not load at load time as the value would have gotten truncated.

Hence it should be the assembler's job to determine whether a suitable
relocation type is available and the (static and/or dynamic) linker's job to
detect and report truncation / overflow. This is not the least because later
the standard also says "An implementation may accept other forms of constant
expressions."

[Bug target/101819] [12 Regression] ICE in expand_expr_real_2, at expr.c:9552 since r12-2789-gf31da42e047e8018ca6ad9809273bc7efb6ffcaf

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

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

--- Comment #2 from Martin Liška  ---
Happens also on x86_64:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/pr51581-3.c
-mno-mmx -Ofast -mno-sse -c
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/pr51581-3.c: In function
‘f2’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/pr51581-3.c:22:1:
internal compiler error: in expand_expr_real_2, at expr.c:9552
   22 | f2 (void)
  | ^~
0x6a17bb expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/marxin/Programming/gcc/gcc/expr.c:9552
0xb1d086 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:10480
0xb167a8 expand_expr
/home/marxin/Programming/gcc/gcc/expr.h:301
0xb167a8 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/marxin/Programming/gcc/gcc/expr.c:9780
0xb1d086 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:10480
0xb2d76a expand_normal
/home/marxin/Programming/gcc/gcc/expr.h:307
0xb2d76a store_field
/home/marxin/Programming/gcc/gcc/expr.c:7439
0xb2cfa5 store_constructor
/home/marxin/Programming/gcc/gcc/expr.c:7289
0xb2e6bd expand_constructor
/home/marxin/Programming/gcc/gcc/expr.c:8634
0xb1c32a expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:10819
0xb278a6 store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/marxin/Programming/gcc/gcc/expr.c:6064
0xb29dad expand_assignment(tree_node*, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/expr.c:5796
0x9ecffa expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3945
0x9ecffa expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:4043
0x9f3950 expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6085
0x9f58c7 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6811
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/101824] VOLATILE not honored

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

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

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

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

commit r12-2831-gbb169406cdc9e044eaec500dd742c2fed40f5488
Author: Richard Biener 
Date:   Mon Aug 9 10:19:10 2021 +0200

middle-end/101824 - properly handle volatiles in nested fn lowering

When we build the COMPONENT_REF of a formerly volatile local off
the FRAME decl we have to make sure to mark the COMPONENT_REF
as TREE_THIS_VOLATILE.  While the GIMPLE operand scanner looks
at the FIELD_DECL this is not how volatile GENERIC refs work.

2021-08-09  Richard Biener  

PR middle-end/101824
* tree-nested.c (get_frame_field): Mark the COMPONENT_REF as
volatile in case the variable was.

* gcc.dg/tree-ssa/pr101824.c: New testcase.

[Bug tree-optimization/101824] [9/10/11 Regression] VOLATILE not honored

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
  Known to fail||11.2.0
   Priority|P3  |P2
Summary|VOLATILE not honored|[9/10/11 Regression]
   ||VOLATILE not honored
  Known to work||12.0

--- Comment #4 from Richard Biener  ---
Fixed on trunk sofar.  The issue is latent on branches and a regression from
introduction of predictive commoning (but it could otherwise have
materialized).

[Bug fortran/101841] New: Wrong realloc-lhs warning with matmul and -O2

[jellby at yahoo dot com via Gcc-bugs]

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

Bug ID: 101841
   Summary: Wrong realloc-lhs warning with matmul and -O2
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jellby at yahoo dot com
  Target Milestone: ---

I get a warning with this:

program test
real, allocatable :: F(:,:), A(:,:), B(:,:)
allocate(F(10,10), A(10,10), B(10,10))
F(:,:) = 1.0
A(:,:) = 0.5
B(:,:) = 2.0
F(:,:) = F-matmul(a,b)
end program test

$ gfortran test.f90 -Wrealloc-lhs -O2

No warning with "F(:,:) = matmul(a,b)"

Maybe the warning means that a temporary array is created (although I guess it
wouldn't be needed)? But as far as I can see there should be no reallocation
here.

[Bug target/101819] [12 Regression] ICE in expand_expr_real_2, at expr.c:9552 since r12-2789-gf31da42e047e8018ca6ad9809273bc7efb6ffcaf

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

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

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

https://gcc.gnu.org/g:19d1a529fa9f78e7ec7be38d423c90e00cec8f8c

commit r12-2832-g19d1a529fa9f78e7ec7be38d423c90e00cec8f8c
Author: Richard Biener 
Date:   Mon Aug 9 11:42:47 2021 +0200

tree-optimization/101801 - rework generic vector vectorization more

This builds ontop of the vect_worthwhile_without_simd_p refactoring
done earlier.  It was wrong in dropping the appearant double checks
for operation support since the optab check can happen with an
integer vector emulation mode and thus succeed but vector lowering
might not actually support the operation on word_mode.

The following patch adds a vect_emulated_vector_p helper and
re-instantiates the check where it was previously.  It also adds
appropriate costing of the scalar stmts emitted by vector lowering
to vectorizable_operation which should be the only place such
operations are synthesized.  I've also cared for the case where
the vector mode is supported but the operation is not (though
I think this will be unlikely given we're talking about plus, minus
and negate).

This fixes the observed FAIL of gcc.dg/tree-ssa/gen-vect-11b.c
with -m32 where we end up vectorizing a multiplication that ends up
being teared down to scalars again by vector lowering.

I'm not super happy about all the other places where we're now
and previously feeding scalar modes to optab checks where we
want to know whether we can vectorize sth but well.

2021-09-08  Richard Biener  

PR tree-optimization/101801
PR tree-optimization/101819
* tree-vectorizer.h (vect_emulated_vector_p): Declare.
* tree-vect-loop.c (vect_emulated_vector_p): New function.
(vectorizable_reduction): Re-instantiate a check for emulated
operations.
* tree-vect-stmts.c (vectorizable_shift): Likewise.
(vectorizable_operation): Likewise.  Cost emulated vector
operations according to the scalar sequence synthesized by
vector lowering.

[Bug tree-optimization/101801] vect_worthwhile_without_simd_p is broken

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

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

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

https://gcc.gnu.org/g:19d1a529fa9f78e7ec7be38d423c90e00cec8f8c

commit r12-2832-g19d1a529fa9f78e7ec7be38d423c90e00cec8f8c
Author: Richard Biener 
Date:   Mon Aug 9 11:42:47 2021 +0200

tree-optimization/101801 - rework generic vector vectorization more

This builds ontop of the vect_worthwhile_without_simd_p refactoring
done earlier.  It was wrong in dropping the appearant double checks
for operation support since the optab check can happen with an
integer vector emulation mode and thus succeed but vector lowering
might not actually support the operation on word_mode.

The following patch adds a vect_emulated_vector_p helper and
re-instantiates the check where it was previously.  It also adds
appropriate costing of the scalar stmts emitted by vector lowering
to vectorizable_operation which should be the only place such
operations are synthesized.  I've also cared for the case where
the vector mode is supported but the operation is not (though
I think this will be unlikely given we're talking about plus, minus
and negate).

This fixes the observed FAIL of gcc.dg/tree-ssa/gen-vect-11b.c
with -m32 where we end up vectorizing a multiplication that ends up
being teared down to scalars again by vector lowering.

I'm not super happy about all the other places where we're now
and previously feeding scalar modes to optab checks where we
want to know whether we can vectorize sth but well.

2021-09-08  Richard Biener  

PR tree-optimization/101801
PR tree-optimization/101819
* tree-vectorizer.h (vect_emulated_vector_p): Declare.
* tree-vect-loop.c (vect_emulated_vector_p): New function.
(vectorizable_reduction): Re-instantiate a check for emulated
operations.
* tree-vect-stmts.c (vectorizable_shift): Likewise.
(vectorizable_operation): Likewise.  Cost emulated vector
operations according to the scalar sequence synthesized by
vector lowering.

[Bug target/101819] [12 Regression] ICE in expand_expr_real_2, at expr.c:9552 since r12-2789-gf31da42e047e8018ca6ad9809273bc7efb6ffcaf

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c/100150] ice in bp_unpack_string

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #16 from Martin Liška  ---
> Looking at the git diff releases/gcc-11.1.0..releases/gcc-11.2.0, I don't
> see any LTO-related change that would break the LTO stream. But it may come
> from a FE.

This one is caused by change here:

commit 52f0aa4dee8401ef3958dbf789780b0ee877beab
Author: Andrew MacLeod 
Date:   Mon Jun 7 13:18:55 2021 -0400

Implement a sparse bitmap representation for Rangers on-entry cache.

Use a sparse representation for the on entry cache, and utilize it when
the number of basic blocks in the function exceeds
param_evrp_sparse_threshold.

PR tree-optimization/100299
* gimple-range-cache.cc (class sbr_sparse_bitmap): New.
(sbr_sparse_bitmap::sbr_sparse_bitmap): New.
(sbr_sparse_bitmap::bitmap_set_quad): New.
(sbr_sparse_bitmap::bitmap_get_quad): New.
(sbr_sparse_bitmap::set_bb_range): New.
(sbr_sparse_bitmap::get_bb_range): New.
(sbr_sparse_bitmap::bb_range_p): New.
(block_range_cache::block_range_cache): initialize bitmap obstack.
(block_range_cache::~block_range_cache): Destruct obstack.
(block_range_cache::set_bb_range): Decide when to utilze the
sparse on entry cache.
* gimple-range-cache.h (block_range_cache): Add bitmap obstack.
* params.opt (-param=evrp-sparse-threshold): New.

[Bug tree-optimization/101809] emulated gather capability doesn't support 32-bit target

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

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

--- Comment #4 from Richard Biener  ---
I am testing a patch.

[Bug c/100150] ice in bp_unpack_string

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #17 from rguenther at suse dot de  ---
On Tue, 10 Aug 2021, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150
> 
> Martin Liška  changed:
> 
>What|Removed |Added
> 
>  CC||amacleod at redhat dot com
> 
> --- Comment #16 from Martin Liška  ---
> > Looking at the git diff releases/gcc-11.1.0..releases/gcc-11.2.0, I don't
> > see any LTO-related change that would break the LTO stream. But it may come
> > from a FE.
> 
> This one is caused by change here:
> 
> commit 52f0aa4dee8401ef3958dbf789780b0ee877beab
> Author: Andrew MacLeod 
> Date:   Mon Jun 7 13:18:55 2021 -0400
> 
> Implement a sparse bitmap representation for Rangers on-entry cache.
> 
> Use a sparse representation for the on entry cache, and utilize it when
> the number of basic blocks in the function exceeds
> param_evrp_sparse_threshold.
> 
> PR tree-optimization/100299
> * gimple-range-cache.cc (class sbr_sparse_bitmap): New.
> (sbr_sparse_bitmap::sbr_sparse_bitmap): New.
> (sbr_sparse_bitmap::bitmap_set_quad): New.
> (sbr_sparse_bitmap::bitmap_get_quad): New.
> (sbr_sparse_bitmap::set_bb_range): New.
> (sbr_sparse_bitmap::get_bb_range): New.
> (sbr_sparse_bitmap::bb_range_p): New.
> (block_range_cache::block_range_cache): initialize bitmap obstack.
> (block_range_cache::~block_range_cache): Destruct obstack.
> (block_range_cache::set_bb_range): Decide when to utilze the
> sparse on entry cache.
> * gimple-range-cache.h (block_range_cache): Add bitmap obstack.
> * params.opt (-param=evrp-sparse-threshold): New.

Altering any *.opt can indeed cause compatibility breakage.  Streaming
options in a less fragile way would be nice.

[Bug target/80355] Improve __builtin_shuffle on AVX512F

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

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

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

https://gcc.gnu.org/g:7665af0b1a964b1baae3a59b22fcc420369c63cf

commit r12-2835-g7665af0b1a964b1baae3a59b22fcc420369c63cf
Author: Jakub Jelinek 
Date:   Tue Aug 10 11:34:53 2021 +0200

i386: Improve single operand AVX512F permutations [PR80355]

On the following testcase we emit
vmovdqa32   .LC0(%rip), %zmm1
vpermd  %zmm0, %zmm1, %zmm0
and
vmovdqa64   .LC1(%rip), %zmm1
vpermq  %zmm0, %zmm1, %zmm0
instead of
vshufi32x4  $78, %zmm0, %zmm0, %zmm0
and
vshufi64x2  $78, %zmm0, %zmm0, %zmm0
we can emit with the patch.  We have patterns that match two argument
permutations for vshuf[if]*, but for one argument it doesn't trigger.
Either we can add two patterns for that, or we would need to add another
routine to i386-expand.c that would transform under certain condition
these cases to the two argument vshuf*, doing it in sse.md looked simpler.
We don't need this for 32-byte vectors, we already emit single insn
permutation that doesn't need memory op there.

2021-08-10  Jakub Jelinek  

PR target/80355
* config/i386/sse.md
(*avx512f_shuf_64x2_1_1,
*avx512f_shuf_32x4_1_1): New define_insn
patterns.

* gcc.target/i386/avx512f-pr80355-1.c: New test.

[Bug tree-optimization/101842] New: Vectorizer doesn't vectorize when loop bound depends on two independent variables that are unknown

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

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

Bug ID: 101842
   Summary: Vectorizer doesn't vectorize when loop bound depends
on two independent variables that are unknown
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---

The following example

float f(float *p, float d, int len, float lim)
{
  float m[4];
  for (int i = 0; i < len && d >= lim; i += 4)
  {
m[0] = p[0] * p[0];
m[1] = p[1] * p[1];
m[2] = p[2] * p[2];
m[3] = p[3] * p[3];
d = d - m[0];
d = d - m[1];
d = d - m[2];
d = d - m[3];
p += 4;
  }

  return d;
}

isn't vectorized at -Ofast because

```
missed: not vectorized: number of iterations cannot be computed.
```

which seems odd because I would expect that it would be treated as just any
other loop with unbounded iterations.  Commenting out this check results in it
bailing out because of it not knowing how to deal with the reduction.

This loop should be easy to vectorize with vectorizing the multiplications of m
and then reducing the changes of `d - sum (m[0..3])`.

[Bug tree-optimization/101842] Vectorizer doesn't vectorize when loop bound depends on two independent variables that are unknown

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Blocks||53947
   Last reconfirmed||2021-08-10
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
The issue is that there's no symbolic expression to compute the number of
iterations since the number of iterations depends on data computed inside the
loop.  We require a symbolic number of iterations in various places since
we're using a canonical IV for loop control.  There's also the dynamic cost
check which depends on the number of vector iterations - I suppose for this
kind of loop we'd have to statically assert the vectorization is always
profitable.

But confirmed, we can't vectorize this loop.  But we should vectorize the
basic-block eventually.  We currently don't because the reduction handling
has the mixed +- case not implemented yet and we see

  _41 = powmult_3 + powmult_5;
  _42 = powmult_7 + _41;
  _43 = powmult_9 + _42;
  d_25 = d_35 - _43;

we detect this as reduction of 5 lanes and fail to see the opportunity to
reduce the 4 lanes with PLUS and then do the final minus with the remaining
(unvectorized) scalar.

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index f9ca24415a2..33b21c8c247 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -5666,10 +5666,12 @@ vect_slp_check_for_constructors (bb_vec_info bb_vinfo)
{
  if (chain[i].dt != vect_internal_def)
invalid_cst = true;
- else if (chain[i].code != code)
-   invalid_op = true;
  else
-   valid_lanes++;
+   {
+ valid_lanes++;
+ if (chain[i].code != code)
+   invalid_op = true;
+   }
}
  if (!invalid_op && !invalid_cst)
{

then properly prints:

t.c:4:27: optimized:  BB reduction missed with 5 lanes

The one different op lane could be handled similar as to the yet unsupported
constant - we need to record this operand and apply the it to the reduction
int the epilogue.

Let me try sth.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug c++/52959] Missing typo suggestions

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

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

--- Comment #4 from Jonathan Wakely  ---
This is a rather unhelpful bug report. For anybody else wondering what the OP
is actually saying: the commented-out errors in the original report show
clang's output, and the request is that GCC should do something similar.

[Bug tree-optimization/101842] Vectorizer doesn't vectorize when loop bound depends on two independent variables that are unknown

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

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

--- Comment #2 from Richard Biener  ---
OK, so with a hack like the following we vectorize the BB as

  vect__1.10_62 = MEM  [(float *)p_34];
  vect_powmult_9.11_61 = vect__1.10_62 * vect__1.10_62;
  _60 = .REDUC_PLUS (vect_powmult_9.11_61);
  d_25 = d_35 - _60;
  p_26 = p_34 + 16;
  i_27 = i_37 + 4;
  _10 = len_20(D) > i_27;
  _11 = lim_21(D) <= d_25;
  _12 = _10 & _11;
  if (_12 != 0)

and on x86_64 we get

.L3:
movups  (%rdi), %xmm2
addl$4, %eax
addq$16, %rdi
mulps   %xmm2, %xmm2
movaps  %xmm2, %xmm3
movhlps %xmm2, %xmm3
addps   %xmm2, %xmm3
movaps  %xmm3, %xmm2
shufps  $85, %xmm3, %xmm2
addps   %xmm3, %xmm2
subss   %xmm2, %xmm0
cmpl%eax, %esi
jle .L2
comiss  %xmm1, %xmm0
jnb .L3
.L2:
ret

or with AVX

.L3:
vmovups (%rdi), %xmm4
addl$4, %eax
addq$16, %rdi
vmulps  %xmm4, %xmm4, %xmm2
vmovhlps%xmm2, %xmm2, %xmm3
vaddps  %xmm2, %xmm3, %xmm3
vshufps $85, %xmm3, %xmm3, %xmm2
vaddps  %xmm3, %xmm2, %xmm2
vsubss  %xmm2, %xmm0, %xmm0
cmpl%eax, %esi
jle .L2
vcomiss %xmm1, %xmm0
jnb .L3
.L2:
ret


diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index f9ca24415a2..0e14c164635 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -5637,6 +5637,11 @@ vect_slp_check_for_constructors (bb_vec_info bb_vinfo)
   || (gimple_assign_rhs_code (use_stmt)
   != (code == PLUS_EXPR ? MINUS_EXPR :
PLUS_EXPR))
{
+ gassign *next_stmt = assign;
+ while (next_stmt)
+   {
+ assign = next_stmt;
+ next_stmt = NULL;
  /* We start the match at the end of a possible association
 chain.  */
  auto_vec chain;
@@ -5666,10 +5671,12 @@ vect_slp_check_for_constructors (bb_vec_info bb_vinfo)
{
  if (chain[i].dt != vect_internal_def)
invalid_cst = true;
- else if (chain[i].code != code)
-   invalid_op = true;
  else
-   valid_lanes++;
+   {
+ valid_lanes++;
+ if (chain[i].code != code)
+   invalid_op = true;
+   }
}
  if (!invalid_op && !invalid_cst)
{
@@ -5707,8 +5714,13 @@ vect_slp_check_for_constructors (bb_vec_info bb_vinfo)
statistics_counter_event (cfun, "BB reduction missed
(cst)", 1);
  statistics_histogram_event (cfun, "BB reduction missed
lanes",
  valid_lanes);
+
+ /* Try again.  */
+ if (valid_lanes > 2)
+   next_stmt = as_a  (chain_stmts[1]);
}
}
+   }
}
 }
 }


the hack simply re-starts reduction discovery at the "previous" stmt
(this breaks down after skipping the first stmt eventually).  As said,
it's a hack.  But is that the kind of vectorization you expect?

[Bug tree-optimization/101809] emulated gather capability doesn't support 32-bit target

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

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

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

https://gcc.gnu.org/g:08aa0e3d4f781fd6a6e293bb06d280365a0bdc1d

commit r12-2836-g08aa0e3d4f781fd6a6e293bb06d280365a0bdc1d
Author: Richard Biener 
Date:   Tue Aug 10 10:54:58 2021 +0200

tree-optimization/101809 - support emulated gather for double[int]

This adds emulated gather support for index vectors with more
elements than the data vector.  The internal function gather
vectorization code doesn't currently handle this (but the builtin
decl code does).  This allows vectorization of double data gather
with int indexes on 32bit platforms where there isn't an implicit
widening to 64bit present.

2021-08-10  Richard Biener  

PR tree-optimization/101809
* tree-vect-stmts.c (get_load_store_type): Allow emulated
gathers with offset vector nunits being a constant multiple
of the data vector nunits.
(vect_get_gather_scatter_ops): Use the appropriate nunits
for the offset vector defs.
(vectorizable_store): Adjust call to
vect_get_gather_scatter_ops.
(vectorizable_load): Likewise.  Handle the case of less
offset vectors than data vectors.

[Bug c++/68888] No Warning when converting an array of a subclass to its parent

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is undefined behaviour, and should definitely warn (and UBsan should give
an error too).

The implicit conversion sequence of array-to-pointer decay followed by
derived-to-base conversion should warn. If the derived-to-base conversion is
really desired (because no pointer arithmetic will be done on the result) then
users can get a pointer to the first element of the array explicitly, so there
is no implicit decay e.g. any of these would not warn:

  go(&bs[0]);
  go(&*bs);
  go((B*)bs);
  go(std::begin(bs));

(of course the code would still have undefined behaviour due to the arithmetic
in go, but it wouldn't warn because there's no implicit decay).

[Bug tree-optimization/101809] emulated gather capability doesn't support 32-bit target

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Fixed.  The reverse remains, so we currently cannot vectorize int[long] or
char[int] with emulated gather (but the more elements we get the less efficient
it will be).

It would be nice to transition x86 over to internal function gathers
(thus [mask_]gather_load and [mask_]scatter_store optabs, away from the
target hook returing a builtin decl).  If somebody can cover the .md
part (write define_expands) I'll take over the vectorizer part which
unfortunately isn't a no-op.

[Bug target/80355] Improve __builtin_shuffle on AVX512F

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

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

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

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

commit r12-2837-g50b5877925ef5ae8e9f913d6d2b5ce0204ebc588
Author: Jakub Jelinek 
Date:   Tue Aug 10 12:38:00 2021 +0200

i386: Allow some V32HImode and V64QImode permutations even without AVX512BW
[PR80355]

When working on the PR, I've noticed we generate terrible code for
V32HImode or V64QImode permutations for -mavx512f -mno-avx512bw.
Generally we can't do much with such permutations, but since PR68655
we can handle at least some, those expressible using V16SImode or V8DImode
permutations, but that wasn't reachable, because
ix86_vectorize_vec_perm_const
didn't even try, it said without TARGET_AVX512BW it can't do anything, and
with it can do everything, no d.testing_p attempts.

This patch makes it try it for TARGET_AVX512F && !TARGET_AVX512BW.

The first hunk is to avoid ICE, expand_vec_perm_even_odd_1 asserts d->vmode
isn't V32HImode because expand_vec_perm_1 for AVX512BW handles already
all permutations, but when we let it through without !TARGET_AVX512BW,
expand_vec_perm_1 doesn't handle it.

If we want, that hunk can be dropped if we implement in
expand_vec_perm_even_odd_1 and its helper the even permutation as
vpmovdw + vpmovdw + vinserti64x4 and odd permutation as
vpsrld $16 + vpsrld $16 + vpmovdw + vpmovdw + vinserti64x4.

2021-08-10  Jakub Jelinek  

PR target/80355
* config/i386/i386-expand.c (expand_vec_perm_even_odd): Return
false
for V32HImode if !TARGET_AVX512BW.
(ix86_vectorize_vec_perm_const) :
If !TARGET_AVX512BW and TARGET_AVX512F and d.testing_p, don't fail
early, but actually check the permutation.

* gcc.target/i386/avx512f-pr80355-2.c: New test.

[Bug target/80355] Improve __builtin_shuffle on AVX512F

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/101842] Vectorizer doesn't vectorize when loop bound depends on two independent variables that are unknown

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

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

--- Comment #3 from Tamar Christina  ---
(In reply to Richard Biener from comment #2)
> OK, so with a hack like the following we vectorize the BB as
> 
>   vect__1.10_62 = MEM  [(float *)p_34];
>   vect_powmult_9.11_61 = vect__1.10_62 * vect__1.10_62;
>   _60 = .REDUC_PLUS (vect_powmult_9.11_61);
>   d_25 = d_35 - _60;
>   p_26 = p_34 + 16;
>   i_27 = i_37 + 4;
>   _10 = len_20(D) > i_27;
>   _11 = lim_21(D) <= d_25;
>   _12 = _10 & _11;
>   if (_12 != 0)
> 

Ah awesome!

> 
> the hack simply re-starts reduction discovery at the "previous" stmt
> (this breaks down after skipping the first stmt eventually).  As said,
> it's a hack.  But is that the kind of vectorization you expect?

Yeah that looks perfect, the patch seems to be based on a different code than
upstream so couldn't apply it to test the full loop, but this looks perfect!
(We already vectorize a similar loop without the `&& d >= lim` condition).

[Bug c++/101811] Error not helpful for misplaced 'template'

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Tobias Schlüter from comment #2)
> Hi Jonathan,
> actually I found clang's error message a lot more helpful, I just didn't
> bother to write it explicitly, especially given that my compiler explorer
> link shows it for everybody else to make the same observation.  Well, you
> came to a different conclusion comparing the two and so I was wondering why
> I would find clang's message more helpful and you didn't.
> 
> Here's clang's error message:
> :6:9: error: out-of-line definition of 'f' does not match any
> declaration in 'X'
> void X::f()
> ^
> :2:10: note: member declaration nearly matches
> void f();
> 
> When I read that I know 1) there are two 'f's.

GCC tells you this too, there are two locations, one on line 2 and one on line
6.

> 2) the one on line 6 doesn't
> match the one on line 2.

That seems obvious from the fact there are two and GCC says "no declaration
matches" :-)


> 3) yet it ought to match (the) one in 'struct X'. 
> So I as s user am left with wondering "how does it not match" which is
> sufficient to resolve the problem.

I honestly don't see how GCC's error doesn't provide exactly the same
information. It could be clearer, but all the same information is there.


> Let me point to three things where gcc ends up making things harder to
> understand in my opinion:
> 1) clang uses (almost) complete sentences.  One doesn't have to figure out
> how the parts of the error message relate to then form a logical whole from
> the set of "error" and "note"s.

GCC's "error:" is a complete sentence too, it's just a lot more terse.

> 2) "candidate" in gcc's error message appears to be a technical term or a

It's the term used in the C++ standard for functions of the same name that are
participating in overload resolution.

The compiler isn't actually doing overload resolution here so maybe it's a poor
choice of terminology that only makes sense from the compiler writers'
perspective.

> gcc-specific term, one has to make sense of what it means from the context
> ("nothing matches -> oh, so this was a candidate for a match and this is
> what 'candidate' means here" whereas clang's error implies directly that the
> 'f' on line 2 was really close to the one on line 6.
> 3) gcc's second note, which points to the struct declaration isn't really
> helpful, it just floats in the ether for the user to make sense of.  I would
> go so far as to claim that it doesn't add any helpful information and thus
> does more bad than good.

I agree.

I think this would be better than GCC's current diagnostic, and better than
Clang's too:

:6:6: error: no declaration matches 'template void X::f()'
6 | void X::f()
  |  ^
:2:10: note: non-matching declaration 'void X::f()' is not a template
2 | void f();
  |  ^





> Anyway, I'm well aware that the C++ frontend unfortunately doesn't get much
> developer attention,

That's not true at all. Over the past year it has more commits than all other
GCC front ends combined, and more distinct contributors than any other front
end.

[Bug tree-optimization/101842] Vectorizer doesn't vectorize when loop bound depends on two independent variables that are unknown

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

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

--- Comment #4 from Richard Biener  ---
(In reply to Tamar Christina from comment #3)
> (In reply to Richard Biener from comment #2)
> > OK, so with a hack like the following we vectorize the BB as
> > 
> >   vect__1.10_62 = MEM  [(float *)p_34];
> >   vect_powmult_9.11_61 = vect__1.10_62 * vect__1.10_62;
> >   _60 = .REDUC_PLUS (vect_powmult_9.11_61);
> >   d_25 = d_35 - _60;
> >   p_26 = p_34 + 16;
> >   i_27 = i_37 + 4;
> >   _10 = len_20(D) > i_27;
> >   _11 = lim_21(D) <= d_25;
> >   _12 = _10 & _11;
> >   if (_12 != 0)
> > 
> 
> Ah awesome!
> 
> > 
> > the hack simply re-starts reduction discovery at the "previous" stmt
> > (this breaks down after skipping the first stmt eventually).  As said,
> > it's a hack.  But is that the kind of vectorization you expect?
> 
> Yeah that looks perfect, the patch seems to be based on a different code
> than upstream so couldn't apply it to test the full loop, but this looks
> perfect! (We already vectorize a similar loop without the `&& d >= lim`
> condition).

It's applied to my working tree so that's possible.  Note it doesn't
vectorize the loop but the loop body in basic-block vectorization.

[Bug c++/101840] Friendship must be extended on default argument initializer

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Confirmed.

[class.access.general] p8:
"Access is checked for a default argument ([dcl.fct.default]) at the point of
declaration, rather than at any points of use of the default argument."

[Bug other/101843] New: Build of binutils-2.37 with gcc-11.2.0 fails due to change to libiberty/hashtab.c

[mailboxnotfound at yahoo dot com via Gcc-bugs]

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

Bug ID: 101843
   Summary: Build of binutils-2.37 with gcc-11.2.0 fails due to
change to libiberty/hashtab.c
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mailboxnotfound at yahoo dot com
  Target Milestone: ---

SUMMARY

   Building binutils along with GCC is a documented method,
   but it fails for gcc-11.2.0 with binutils-2.37 because 
  libiberty/hashtab.c
   differs between gcc-11.2.0 and binutils-2.37

   I have heard that hashtab.c has been updated in GCC master,
   presumably fixing this problem (I have not verified this assertion).

   It would be useful to include a fix in at least GCC 11, 
   and perhaps for other still-supported GCC version.


DETAIL

According to 
   https://gcc.gnu.org/install/download.html 
it is acceptable to build binutils at the same time that one builds GCC.   

However, if one does so by this method:

cd gcc-11.2.0
for dir in ../binutils-2.37/*
 if dir does not exist in this gcc tree
   ln -s $dir

then the following directories that already exist in the GCC tree are NOT
replaced by directories from the binutils-2.37 tree

   config/   include/  intl/  libiberty/  zlib/

leading to this failure [white space adjusted] (*)

 libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes
 -Wshadow -I/data1/gcc/build/gcc-11.2.0/binutils/../zlib -g
 -o strip-new objcopy.o is-strip.o rename.o rddbg.o debug.o
 stabs.o rdcoff.o wrstabs.o bucomm.o version.o filemode.o  
 ../bfd/.libs/libbfd.a
-L/data1/gcc/build/Linux-x86_64-gcc-build-11.2.0/zlib
 -lz ../libiberty/libiberty.a -ldl

objcopy.o: In function `create_symbol_htab':
/data1/gcc/build/gcc-11.2.0/binutils/objcopy.c:1031: undefined reference to
'htab_eq_string'

The missing symbol, htab_eq_string, is defined in 
../binutils-2.37/libiberty/hashtab.c and ../binutils-2.37/include/hashtab.h

(*) There may be other failures; I did not attempt to do anything resembling 
make --keep-going


WORKAROUND

Building gcc-11.2.0 with binutils-2.36 works.


NOT A WORKAROUND 

   Note that this fails:

   $ cd gcc-11.2.0/libiberty/
   $ mv hashtab.c hashtab.c.orig; cp -p ../../binutils-2.37/libiberty/hashtab.c
.
   $ cd ../include
   $ mv hashtab.h hashtab.h.orig; cp -p ../../binutils-2.37/include/hashtab.h .

   The above fails for module gensupport:

   gcc-11.2.0/gcc/gensupport.c:2328:47: error: int htab_eq_string(const void*,
const void*) was declared 'extern' and later 'static'


RECOMMENDATION

   Given that the documentation says that building binutils in your GCC tree
should work, 
   and given the existence of user habits (various google tracks for this
method), 
   it would be useful if at least GCC 11 (and maybe the other still-supported
GCC versions) 
   were fixed such that in-tree builds of binutils-2.37 would work.

[Bug c++/57014] pretty-printer prints anonymous for template-parameter with a name

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-08-10

--- Comment #2 from Jonathan Wakely  ---
Confirmed. Here's the relevant code:

template struct B
{
  void F2(int, int, int = 0);
};

template void B::F2(int = 0, int, int) {}



57014.C:6:22: error: redeclaration of ‘void B< >::F2(int, int, int)’
may not have default arguments [-fpermissive]
6 | template void B::F2(int = 0, int, int) {}
  |  ^~~~
57014.C:6:40: error: default argument missing for parameter 2 of ‘void
B< >::F2(int, int, int)’
6 | template void B::F2(int = 0, int, int) {}
  |^~~
57014.C:6:31: note: ...following parameter 1 which has a default argument
6 | template void B::F2(int = 0, int, int) {}
  |   ^~~


It would be nice if later declarations that name a template parameter could be
used to "fill in" any unnamed template parameters from the original
declaration, so that pretty printing isn't so ugly.

[Bug c++/101844] New: Don't pretty print template parameter names that aren't needed

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

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

Bug ID: 101844
   Summary: Don't pretty print template parameter names that
aren't needed
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The diagnostic for this invalid code has ugly pretty printing:

struct A
{
  template void f();
};

void A::f() { }


t.C:6:6: error: no declaration matches ‘void A::f()’
6 | void A::f() { }
  |  ^
t.C:3:22: note: candidate is: ‘template > void A::f()’
3 |   template void f();
  |  ^

There is no reason to print "" in the note here. Nothing else in the
declarator needs to refer to it (it can't refer to it, since it hasn't got a
name!) so printing it just makes the diagnostic harder to read.

Printing  is strictly worse than printing nothing at all, but I
think we shouldn't print any template parameter names if they aren't used later
in the declarator. For example:

struct A
{
  template void f();
};

void A::f() { }


This prints:

t.C:6:6: error: no declaration matches ‘void A::f()’
6 | void A::f() { }
  |  ^
t.C:3:58: note: candidate is: ‘template void A::f()’
3 |   template void f();
  |  ^

I don't see any benefit to printing the name in the note, it just adds noise.

Obviously there are some cases where we need to pretty print the template
parameter name, because it's used in another parameter:

  template = true> void f();

Here we need to print A so that "enable_if" can use it:

t.C:5:59: note: candidate is: ‘template::type  > void A::f()’

However, we don't need the  for the second parameter.

[Bug tree-optimization/101842] Vectorizer doesn't vectorize when loop bound depends on two independent variables that are unknown

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

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

--- Comment #5 from Tamar Christina  ---
(In reply to Richard Biener from comment #4)
> (In reply to Tamar Christina from comment #3)
> > (In reply to Richard Biener from comment #2)
> > > OK, so with a hack like the following we vectorize the BB as
> 
> It's applied to my working tree so that's possible.  Note it doesn't
> vectorize the loop but the loop body in basic-block vectorization.

I think that's fine, the actual loop also doesn't use any cross iteration
information so vectorizing the BB is good enough.

[Bug c++/57012] pretty-printer does not handle well template parameter packs

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-08-10
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=54948

--- Comment #1 from Jonathan Wakely  ---
GCC improved error recovery with r219067 so that now it just prints one error:

gcc/testsuite/g++.dg/cpp0x/pr31432.C:2:10: error: parameter pack
‘’ must be at the end of the template parameter list
2 | template struct A // { dg-error "parameter pack"
}
  |  ^~~~

Printing "" is still not pretty.

See also PR 54948 and PR 101844.

If the template parameter (or template parameter pack) hasn't got a name, maybe
we should not try to print it. The caret location already shows which pack
we're talking about.

If it's unnamed, maybe special case the diagnostic so it just says "parameter
pack must be at the end ..." instead of making up a name which doesn't appear
in the source code.

[Bug c++/101811] Error not helpful for misplaced 'template'

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

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

--- Comment #4 from Tobias Schlüter  ---
Hi Jonathan,

I know that we disagree about clang's error message and that's why I tried to
explain what makes clang's a  better error message for me.  My "parsing" of
clang's error message was not a comparison to gcc's, but an analysis how it
conveys all the information I need to find and fix the issue. 

Glad to see that we more or less agree on the issues with gcc's message,
though.  That's the important part anyway.  I also like your suggestion.  If we
are at a stage where grammatical niceties matter, I would make the symbol in
the first message the subject, so

:6:6: error: 'template void X::f()' matches no declaration
6 | void X::f()
  |  ^
:2:10: note: non-matching declaration 'void X::f()' is not a template
2 | void f();
  |  ^ 

Thanks for correcting my misunderstanding about the status of the C++ FE, and
I'm glad to hear that.  I really wonder where I'd picked up that piece of
misinformation.  Actually, while I wrote this I was wondering "how do they
manage to stay up to speed with the latest versions then?"  Now I'm less
impressed ;-)

Cheers!

[Bug c++/101811] Error not helpful for misplaced 'template'

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Tobias Schlüter from comment #4)
> we are at a stage where grammatical niceties matter, I would make the symbol
> in the first message the subject, so
> 
> :6:6: error: 'template void X::f()' matches no declaration
> 6 | void X::f()
>   |  ^

No, I disagree. The function declarator can be arbitrarily long, sometimes
wrapping over several lines on the screen. If the important "matches no
declaration" text is at an arbitrary place on the screen it is hard to find. If
it appears immediately after the "error:" string (which is typically
highlighted in red) then you don't have to scan the output to find it.

"X matches no declaration" also seems grammatically worse than "no declaration
matches X", but that's debatable.

[Bug target/101845] New: wrong code at -O1 on aarch64 with __builtin_shufflevector()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 101845
   Summary: wrong code at -O1 on aarch64 with
__builtin_shufflevector()
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

Created attachment 51284
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51284&action=edit
reduced testcase

Output:
$ aarch64-unknown-linux-gnu-gcc -O testcase.c -static
$ qemu-aarch64 -- ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

foo:
mvniv0.2s, 0
ret

just 0x is returned


$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-2833-20210810162020-gc318f8e42b3-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/12.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-2833-20210810162020-gc318f8e42b3-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210810 (experimental) (GCC)

[Bug c++/101811] Error not helpful for misplaced 'template'

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

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

--- Comment #6 from Tobias Schlüter  ---
Sure, that's a good argument (before I18N), and I guess it matches the general
style.

Anyway, I'll try to keep myself from bikeshedding this further, I'm sure the
person fixing this will have enough time to figure out a good way of conveying
this information.

[Bug bootstrap/101843] Build of binutils-2.37 with gcc-11.2.0 fails due to change to libiberty/hashtab.c

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|other   |bootstrap
   Keywords||documentation

--- Comment #1 from Richard Biener  ---
The combined tree builds indeed only work for versions where those mentioned
directories are in sync - usually that's binutils master vs. gcc master.  For
release versions your milage may vary and we fail to document working version
pairs.

I'm not sure this is anything but a documentation bug.

For GCC 11 I recommend to use binutils 2.36 instead.

[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)

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

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

--- Comment #5 from Bill Schmidt  ---
If I commit the build patch, everyone who doesn't build with --disable-werror
will blame me for breaking bootstrap.

I thought perhaps the way safe_inc_pos was implemented might have made it
possible for the warning machinery to make this error, but I experimented with
changes and nothing helps.

Just to be clear:  The code is fine.  The warning is bogus.

[Bug tree-optimization/101809] emulated gather capability doesn't support 32-bit target

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:557d06f8b3ddb54bca134695e117c40c6e2267ab

commit r12-2838-g557d06f8b3ddb54bca134695e117c40c6e2267ab
Author: H.J. Lu 
Date:   Tue Aug 10 05:30:44 2021 -0700

Enable gcc.target/i386/pr88531-1a.c for all targets

PR tree-optimization/101809
* gcc.target/i386/pr88531-1a.c: Enable for all targets.

[Bug target/101846] New: Improve __builtin_shufflevector emitted code

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

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

Bug ID: 101846
   Summary: Improve __builtin_shufflevector emitted code
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

typedef short v16hi __attribute__((vector_size (32)));
typedef short v32hi __attribute__((vector_size (64)));

v32hi
foo (v16hi x)
{
  return __builtin_shufflevector (x, (v16hi) {}, 0, 16, 1, 17, 2, 18, 3, 19, 4,
20, 5, 21, 6, 22, 7, 23,
 8, 24, 9, 25, 10, 26, 11, 27,
12, 28, 13, 29, 14, 30, 15, 31);
}

v16hi
bar (v32hi x)
{
  return __builtin_shufflevector (x, x, 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20,
22, 24, 26, 28, 30);
}

shows two cases, where we should be emitting just
vpmovzxwd   %ymm0, %zmm0
and
vpmovdw %zmm0, %ymm0
but we actually emit
vmovdqa %ymm0, %ymm0
vpmovzxwd   %ymm0, %zmm0
where the vmovdqa is unnecessary - the permutation doesn't care about the
elements at or above 32-bytes - and
vmovdqa64   %zmm0, %zmm1
vmovdqa64   .LC0(%rip), %zmm0
vpermi2w%zmm1, %zmm1, %zmm0
Similarly for permutations matching other vpmovxz* or vpmov* instructions.

[Bug bootstrap/101843] Build of binutils-2.37 with gcc-11.2.0 fails due to change to libiberty/hashtab.c

[mailboxnotfound at yahoo dot com via Gcc-bugs]

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

--- Comment #2 from john henning  ---
If this is a doc bug, then two documentation comments
and one other thought.

(1) https://gcc.gnu.org/gcc-11/changes.html  says that certain 
functionality requires “Binutils version 2.36 or later”. 
Perhaps that would have been better without the "or later".

(2) Maybe one handy place to document the right version would 
be in the comments to 
   contrib/download_prerequisites

For many (most?) systems binutils is not a prerequisite.  

But sometimes, it is (*) and perhaps the comments to 
download_prerequisites could include some guidance.  

(3) Or maybe instead of a comment, it could be an option, like 
 download_prerequisites --with-binutils
in which case it would automatically grab the version that 
is deemed likely to be useful.

--

(*) For example, in the days of 
https://bugzilla.redhat.com/show_bug.cgi?id=1552529 
Jacob Jelinek commented "You are trying to use f29 gcc 
with some older binutils (non-f29).  Don't do that."

Right now, I am building on several systems; I 
think only one of them will actually end up requiring it.

[Bug c++/87805] Incomplete diagnostic for -Wnoexcept

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

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail||8.2.0
 Resolution|--- |FIXED
   Target Milestone|--- |10.0
  Known to work||10.1.0

--- Comment #1 from Volker Reichelt  ---
Fixed by Jason with the patch in PR90992.

[Bug target/101846] Improve __builtin_shufflevector emitted code

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.  I've pondered (for elsewhere) about how to represent "paradoxical
subregs" on GIMPLE.  We expand from

v32hi foo (v16hi x)
{
  vector(32) short int _1;
  v32hi _3;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _1 = {x_2(D), { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }};
  _3 = VEC_PERM_EXPR <_1, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, { 0, 32, 1, 33, 2, 34, 3, 35, 4,
36, 5, 37, 6, 38, 7, 39, 8, 40, 9, 41, 10, 42, 11, 43, 12, 44, 13, 45, 14, 46,
15, 47 }>;
  return _3;

and

v16hi bar (v32hi x)
{
  vector(32) short int _1;
  v16hi _3;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _1 = VEC_PERM_EXPR ;
  _3 = BIT_FIELD_REF <_1, 256, 0>;
  return _3;

I think bar() is reasonable from the GIMPLE side, it would be a 1:1
canonicalization choice to move the BIT_FIELD_REF across the permute
(and something only "profitable" for single operand permutes).

For foo() I thought of doing

 _1 = BIT_INSERT_EXPR ;

with tem_3(D) being uninitialized as to represent a paradoxical subreg.
I've tested and disregarded the idea of simply doing VIEW_CONVERT_EXPRs
here but I'm considering it for the case where we need the lowpart
of a vector and the the highpart doesn't matter (aka %xmm0 vs %ymm0)
since the current representation of doing a BIT_FIELD_REF doesn't
seem to optimize well (that was in the context of AVX512 mask registers
though).

I suppose the testcases can be optimized on the RTL level as well.

[Bug testsuite/101847] New: [12 regression] linker errors after r12-2808

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

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

Bug ID: 101847
   Summary: [12 regression] linker errors after r12-2808
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:527a1cf32c27a3fbeaf6be7596241570d864cc4c, r12-2808

After the change in include paths there are now a bunch of undefined symbol
linker errors.

FAIL: gfortran.dg/ieee/dec_math_1.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ieee/dec_math_1.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ieee/dec_math_1.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ieee/dec_math_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/ieee/dec_math_1.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ieee/dec_math_1.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_1.F90   -O0  execution test
FAIL: gfortran.dg/ieee/ieee_1.F90   -O1  execution test
FAIL: gfortran.dg/ieee/ieee_1.F90   -O2  execution test
FAIL: gfortran.dg/ieee/ieee_1.F90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/ieee/ieee_1.F90   -O3 -g  execution test
FAIL: gfortran.dg/ieee/ieee_1.F90   -Os  execution test
FAIL: gfortran.dg/ieee/ieee_10.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_10.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_10.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_10.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_10.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_10.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_3.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_3.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_3.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_3.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_3.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_4.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_4.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_4.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_4.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_4.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_6.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_6.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_6.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_6.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_6.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_6.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_7.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_7.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_7.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_7.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_7.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_7.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_8.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_8.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_8.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_8.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_8.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_8.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_9.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_9.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_9.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_9.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_9.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_9.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/ieee/large_1.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ieee/large_1.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ieee/large_1.f90   -

[Bug testsuite/101847] [12 regression] linker errors after r12-2808

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #1 from Tobias Burnus  ---
Also discussed on IRC. Solution:

Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577099.html

[Bug testsuite/101847] [12 regression] linker errors after r12-2808

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c++/101840] Friendship must be extended on default argument initializer

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 70608 which shows the problem is with {} only.

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

[Bug c++/70608] Braced initializer in default argument misses friendship

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||fchelnokov at gmail dot com

--- Comment #2 from Andrew Pinski  ---
*** Bug 101840 has been marked as a duplicate of this bug. ***

[Bug bootstrap/101843] Build of binutils-2.37 with gcc-11.2.0 fails due to change to libiberty/hashtab.c

[schwab--- via Gcc-bugs]

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

--- Comment #3 from Andreas Schwab  ---
You can certainly use gcc 11 and binutils 2.37 together, just not building them
in a single source tree.

[Bug c++/39057] ICE with default argument in friend declaration

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||error-recovery
   Last reconfirmed|2021-08-04 00:00:00 |2021-8-10
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=59480

--- Comment #4 from Andrew Pinski  ---
After PR 59480 was fixed, this became a error recovery bug only.

[Bug c++/101848] New: Template metaprogramming errors in v11.1

[qwdkguneykiffmmuyd at uivvn dot net via Gcc-bugs]

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

Bug ID: 101848
   Summary: Template metaprogramming errors in v11.1
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qwdkguneykiffmmuyd at uivvn dot net
  Target Milestone: ---

Created attachment 51285
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51285&action=edit
Preprocessed file

This program fails to compile with g++ 11.1.0 with the following template
errors, but DOES compile and execute with clang++ 12.0.1 on the same hardware.
It is reported here in case such behavior is not intended. As instructed, the
preprocessed file is included but not the original CPP file, which was
explicitly listed as not to include.

+verbatim+
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (GCC) 
-verbatim-


+verbatim+
$ g++ kirktemp.cpp 
kirktemp.cpp:60:12: error: explicit specialization in non-namespace scope
‘struct ValidSched’
   60 |   template<> struct daytriad
  |^
kirktemp.cpp:60:21: error: too few template-parameter-lists
   60 |   template<> struct daytriad
  | ^~~
kirktemp.cpp: In instantiation of ‘struct ValidSched<1>::daytriad<0>’:
kirktemp.cpp:52:82:   recursively required from ‘struct
ValidSched<34>::daytriad<0>’
kirktemp.cpp:52:82:   required from ‘struct ValidSched<35>::daytriad<0>’
kirktemp.cpp:71:28:   required from ‘static void
ValidSched::printschedule() [with int numdays = 35]’
kirktemp.cpp:83:19:   required from here
kirktemp.cpp:52:82: error: invalid use of incomplete type ‘struct
ValidSched<0>::daytriad<0>’
   52 | typedef typename ValidSched::template
daytriad::thisdaytriad thisdaytriad;
  |
 ^~~~
kirktemp.cpp:78:24: note: declaration of ‘struct ValidSched<0>::daytriad<0>’
   78 |   template struct daytriad;
  |^~~~

-verbatim-

[Bug c++/101848] Template metaprogramming errors in v11.1

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-08-10
   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
  Known to fail||11.2.0, 12.0

--- Comment #1 from Richard Biener  ---
Confirmed.  clang takes quite some time compiling this.

[Bug fortran/101660] [12 Regression] FAIL: gfortran.dg/bind_c_array_params_3.f90

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

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

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

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

commit r12-2839-g2ba0376ac40447ce7ee09fcef00511c18db25dfa
Author: Tobias Burnus 
Date:   Tue Aug 10 17:26:32 2021 +0200

gfortran: Fix in-build-tree testing [PR101305, PR101660]

ISO_Fortran_binding.h is written in the build dir - hence, a previous
commit
added it as include directory for in-build-tree testing.  However,
it turned out that -I$specdir/libgfortran interferes with reading .mod
files
as they are then no longer regareded as intrinsic modules.  Solution:
Create
an extra include/ directory in the libgfortran build dir and copy
ISO_Fortran_binding.h to that directory.  As -B$specdir/libgfortran already
causes gfortran to read that include subdirectory, the -I flag is no longer
needed.

PR libfortran/101305
PR fortran/101660
PR testsuite/101847

libgfortran/ChangeLog:

* Makefile.am (ISO_Fortran_binding.h): Create include/ in the build
dir
and copy the include file to it.
(clean-local): Add for removing the 'include' directory.
* Makefile.in: Regenerate.

gcc/testsuite/ChangeLog:

* lib/gfortran.exp (gfortran_init): Remove -I$specpath/libgfortran
from the string used to set GFORTRAN_UNDER_TEST.

[Bug libfortran/101305] Bind(C): Problems with incorrect kinds/sizes in ISO_Fortran_binding.h and CFI_establish

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

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

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

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

commit r12-2839-g2ba0376ac40447ce7ee09fcef00511c18db25dfa
Author: Tobias Burnus 
Date:   Tue Aug 10 17:26:32 2021 +0200

gfortran: Fix in-build-tree testing [PR101305, PR101660]

ISO_Fortran_binding.h is written in the build dir - hence, a previous
commit
added it as include directory for in-build-tree testing.  However,
it turned out that -I$specdir/libgfortran interferes with reading .mod
files
as they are then no longer regareded as intrinsic modules.  Solution:
Create
an extra include/ directory in the libgfortran build dir and copy
ISO_Fortran_binding.h to that directory.  As -B$specdir/libgfortran already
causes gfortran to read that include subdirectory, the -I flag is no longer
needed.

PR libfortran/101305
PR fortran/101660
PR testsuite/101847

libgfortran/ChangeLog:

* Makefile.am (ISO_Fortran_binding.h): Create include/ in the build
dir
and copy the include file to it.
(clean-local): Add for removing the 'include' directory.
* Makefile.in: Regenerate.

gcc/testsuite/ChangeLog:

* lib/gfortran.exp (gfortran_init): Remove -I$specpath/libgfortran
from the string used to set GFORTRAN_UNDER_TEST.

[Bug testsuite/101847] [12 regression] linker errors after r12-2808

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

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

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

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

commit r12-2839-g2ba0376ac40447ce7ee09fcef00511c18db25dfa
Author: Tobias Burnus 
Date:   Tue Aug 10 17:26:32 2021 +0200

gfortran: Fix in-build-tree testing [PR101305, PR101660]

ISO_Fortran_binding.h is written in the build dir - hence, a previous
commit
added it as include directory for in-build-tree testing.  However,
it turned out that -I$specdir/libgfortran interferes with reading .mod
files
as they are then no longer regareded as intrinsic modules.  Solution:
Create
an extra include/ directory in the libgfortran build dir and copy
ISO_Fortran_binding.h to that directory.  As -B$specdir/libgfortran already
causes gfortran to read that include subdirectory, the -I flag is no longer
needed.

PR libfortran/101305
PR fortran/101660
PR testsuite/101847

libgfortran/ChangeLog:

* Makefile.am (ISO_Fortran_binding.h): Create include/ in the build
dir
and copy the include file to it.
(clean-local): Add for removing the 'include' directory.
* Makefile.in: Regenerate.

gcc/testsuite/ChangeLog:

* lib/gfortran.exp (gfortran_init): Remove -I$specpath/libgfortran
from the string used to set GFORTRAN_UNDER_TEST.

[Bug c++/101848] Template metaprogramming errors in v11.1

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail|11.2.0, 12.0|
   Last reconfirmed|2021-08-10 00:00:00 |
   Keywords|rejects-valid   |
 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Andrew Pinski  ---
It is only valid C++17 :).

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

[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||qwdkguneykiffmmuyd at uivvn 
dot ne
   ||t

--- Comment #14 from Andrew Pinski  ---
*** Bug 101848 has been marked as a duplicate of this bug. ***

[Bug testsuite/101847] [12 regression] linker errors after r12-2808

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
FIXED - hopefully for good.

[Bug c++/93992] fail to compile specialization of inner class with template template parameter pack

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 85282.  Note this was declared as valid in C++17+.

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

[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||yawaraka.7-11.hemogurobin@e
   ||zweb.ne.jp

--- Comment #15 from Andrew Pinski  ---
*** Bug 93992 has been marked as a duplicate of this bug. ***

[Bug bootstrap/101843] Build of binutils-2.37 with gcc-11.2.0 fails due to change to libiberty/hashtab.c

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

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

--- Comment #4 from Andrew Pinski  ---
Combined source builds are not for released sources unless you are going to
change/fix them yourself.  They are useful for building the trunk sources only
really.

[Bug c++/78826] jump bypasses non-POD

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

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

--- Comment #6 from Andrew Pinski  ---
Here is another one where GCC6- used to reject and in GCC7+ accepts (note this
looks to be only valid C++11 anyways):
struct vec { vec () = default; };
void ggg () {
  goto out;
  vec odsd;
  out: ;
}
 CUT 
This shows up in building GCC with older GCCs now.
Also the change for the above was caused by
r7-2822-gd0b0fbd9fce2f30a82558bf2308b3a7b56c2f364 (Jakub Jelinek bisected it).

[Bug bootstrap/101843] Build of binutils-2.37 with gcc-11.2.0 fails due to change to libiberty/hashtab.c

[mailboxnotfound at yahoo dot com via Gcc-bugs]

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

--- Comment #5 from john henning  ---
Andrew suggests: Combined source builds are not for released sources
Respectfully, I suggest that the documentation disagrees.  
Please see the binutils paragraph of the documentation of the released version
at
  https://gcc.gnu.org/install/download.html 

Plus there are google tracks and user habits doing so.

It would be useful if the gcc-n.n.n documentation specifically suggested which
binutils-n.nn is likely to be useful.

Or, it would be useful if there were a switch something like:

  download_prerequisites --with-binutils

[Bug libstdc++/100894] The std::common_reference implementation seems to be wrong

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

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

commit r10-10026-g0e54986854831a4c66b308f98aff949ca7d3ce84
Author: Jonathan Wakely 
Date:   Mon Jun 14 20:31:00 2021 +0100

libstdc++: Fix common_reference for non-reference results [PR100894]

The result of COMMON-REF(A&, B&&) where they have no common reference
type should be ill-formed. Our implementation fails to check that the
COMMON-REF result is a reference, so is well-formed when it shouldn't
be. This means that common_reference uses that result when it shouldn't
do.

The fix is to reject the result of COMMON-REF(A, B) if it's not a
reference, so that common_reference falls through to the next case,
which uses COND-RES, which yields the correct non-reference result.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/100894
* include/std/type_traits (__common_ref_impl): Only
use the type if it's a reference.
* testsuite/20_util/common_reference/100894.cc: New test.

(cherry picked from commit c37b5ddcc88e0cc0f6a4ad609eda51021df0f6bb)

[Bug libstdc++/100894] The std::common_reference implementation seems to be wrong

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 10.4 and 11.2, thanks

[Bug c++/55922] brace initializing parent cause bogus virtual base constructor calls

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #16 from Andrew Pinski  ---
Fixed so closing.

[Bug c++/68903] missing default initialization of member when combined with virtual inheritance

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

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

--- Comment #3 from Andrew Pinski  ---
Seems fixed on trunk; maybe by the fix for PR 98744.

[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/95567] Defaulted virtual <=> has the wrong behavior, vtable is checked when it should not be

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2020-10-28 00:00:00 |2021-8-10
Summary|Defaulted virtual <=> has   |Defaulted virtual <=> has
   |the wrong behavior  |the wrong behavior, vtable
   ||is checked when it should
   ||not be

--- Comment #2 from Andrew Pinski  ---
Right it is checking the vtable for equality.

[Bug c++/62207] [8 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'overload' in tsubst_copy, at cp/pt.c

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

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

Volker Reichelt  changed:

   What|Removed |Added

   Target Milestone|8.0 |9.0
  Known to work||9.1.0

--- Comment #13 from Volker Reichelt  ---
It's fixed in GCC 9, but not 8.

[Bug tree-optimization/39305] tree-ssa-loop-ch.c:copy_loop_headers performs loop unrolling

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #2 from Andrew Pinski  ---
A slightly different but better patch was done for GCC 9.  r9-4967 .

r9-4967 checks if the exit was an IV which is very similar to what your check
was trying to do.

[Bug other/39363] [meta-bug] pending patches from ARC International (UK) Ltd

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

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

Bug 39305 Summary: tree-ssa-loop-ch.c:copy_loop_headers performs loop unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39305

   What|Removed |Added

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

[Bug target/101849] New: MMA built-in dies with a verify_gimple failed error

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

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

Bug ID: 101849
   Summary: MMA built-in dies with a verify_gimple failed error
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

bergner@pike:~/gcc/BUGS/MMA/ICE$ cat bug.i 
__vector_pair vp;
void
foo (double *x)
{
   vp = __builtin_vsx_lxvp(0, (__vector_pair *)(void *)x);
}

bergner@pike:~/gcc/BUGS/MMA/IC3$ gcc -S -O2 -mcpu=power10 bug.i 
bug.i: In function ‘foo’:
bug.i:3:1: error: non-trivial conversion in ‘mem_ref’
3 | foo (double *x)
  | ^~~
__vector_pair
double
_1 = *_2;
during GIMPLE pass: lower
bug.i:3:1: internal compiler error: ‘verify_gimple’ failed
0x114e804f verify_gimple_in_seq(gimple*)
/home/bergner/gcc/gcc-fsf-mainline/gcc/tree-cfg.c:5183
0x11188afb execute_function_todo
/home/bergner/gcc/gcc-fsf-mainline/gcc/passes.c:2044
0x111872cb do_per_function
/home/bergner/gcc/gcc-fsf-mainline/gcc/passes.c:1687
0x11188de3 execute_todo
/home/bergner/gcc/gcc-fsf-mainline/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/101849] MMA built-in dies with a verify_gimple failed error

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #1 from Peter Bergner  ---
This is a target bug with my new __builtin_vsx_lxvp built-in.  Mine.

[Bug target/101849] MMA built-in dies with a verify_gimple failed error

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

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

Peter Bergner  changed:

   What|Removed |Added

   Host||powerpc64*-linux-gnu
   Target Milestone|--- |12.0
  Known to fail||11.0, 12.0

[Bug tree-optimization/46236] Local aggregate not eliminated

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed|2018-04-22 00:00:00 |2021-8-10

[Bug tree-optimization/46957] http://blog.regehr.org/archives/320 Example 1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed|2018-04-22 00:00:00 |2021-8-10

[Bug tree-optimization/85697] At -Os nontrivial ctor does not use SSE to zero

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2018-05-09 00:00:00 |2021-8-10
   Severity|normal  |enhancement

--- Comment #3 from Andrew Pinski  ---
Note the testcase needs a slight update to it:
__attribute__((noinline, noipa)) void UseA (A& a) { a.a=1; }

Note you need the noipa because GCC figures out that only writes to a.a and
later on only accesses a.a so it deletes the other writes :).

Turning SLP on at -O2/-Os would be something to look into.

[Bug tree-optimization/85720] bad codegen for looped assignment of primitives at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #8 from Andrew Pinski  ---
(In reply to Mathias Stearn from comment #2)
> Hmm. Taking the example from the -ftree-loop-distribute-patterns
> documentation, it still seems to generate poor code, this time at both -O2
> and -O3: https://godbolt.org/g/EsQDj8
> 
> Why isn't that transformed to memset(A, 0, N); memset(B, 1, N); ? This feels
> similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85721. Should I make
> a new ticket with this example?

For this case (with the mentioned B[i] = A[i] + 1 fix), in GCC 10+ we started
to produce memset for one of the alias conditions.
-ftree-loop-distribute-patterns is turned on at -O2 for starting in GCC 10
also.

I should note clang, ICC nor MSVC is able to do this second loop to convert it
to two memset even with an alias check; others just vectorize the loop with an
aliasing check. clang and MSVC are able to detect the one in comment #0 and
convert it to memset though so I know they have this kind of optimization for
sure.

[Bug tree-optimization/68027] uncprop should work on more than PHI nodes

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|conditional statement and   |uncprop should work on more
   |unnecessary register|than PHI nodes
   |assignment  |
   Severity|normal  |enhancement

--- Comment #5 from Andrew Pinski  ---
tree-ssa-uncprop.c does some of this but only handles PHI nodes currrently.
Note ICC and MSVC generate the code without the move while GCC and clang both
do the move.

[Bug tree-optimization/68027] uncprop should work on more than PHI nodes

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to SztfG from comment #4)
> I think this can be optimized in this way:
> 
> cmpl$100, %edi
> jg  a1
> jne a2
> jmp a3

Note that is a different bug and should be filed seperately.  Something about
conditional tail calls.  I thought there was a bug filed for that case but I
can't seem to find it.

[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |10.0

--- Comment #22 from Andrew Pinski  ---
Fixed so closing as such.

[Bug tree-optimization/90571] Missed optimization opportunity when returning function pointers based on run-time boolean

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2019-05-22 00:00:00 |2021-8-10
   Severity|normal  |enhancement

[Bug tree-optimization/86050] Inline break tail-call optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #9 from Andrew Pinski  ---
In the case of removing the noinline, GCC 10+ is able to tail call this
function just fine and we don't get an overall stack increase.

[Bug tree-optimization/91965] missing simplification for (C - a) << N

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed|2019-10-04 00:00:00 |2021-8-10

--- Comment #4 from Andrew Pinski  ---
Note I noticed clang does not vectorize bar because they convert (1048575 - a)
<< 44 to (a * -17592186044416ull) -17592186044416.

So right now at least we vectorize the loop.

[Bug c++/101850] New: Initialising a std::string variable to itself does not fail at compile time, but throws std::bad_alloc at run time

[prasantabehera at hotmail dot com via Gcc-bugs]

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

Bug ID: 101850
   Summary: Initialising a std::string variable to itself does not
fail at compile time, but throws std::bad_alloc at run
time
   Product: gcc
   Version: 8.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prasantabehera at hotmail dot com
  Target Milestone: ---

Version info:
=
~$ g++ --version
g++ (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
Copyright (C) 2018 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 --version
gcc (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
Copyright (C) 2018 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.

Sample Program:
===
~$ cat t.cpp
#include 

int main() {
  std::string s = s;
  return 0;
}

Problem Description:

The above program tries to initialise a string with itself which is wrong!
However g++ does not show any compile time error, but the resulting binary
fails at run time throwing std::bad_alloc as shown below.

~$ g++ t.cpp
~$ ./a.out
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

gcc however shows a link time error which is slightly better.

~$ gcc t.cpp
/tmp/cc30YkgH.o: In function `main':
t.cpp:(.text+0x27): undefined reference to `std::__cxx11::basic_string, std::allocator
>::basic_string(std::__cxx11::basic_string,
std::allocator > const&)'
t.cpp:(.text+0x38): undefined reference to `std::__cxx11::basic_string, std::allocator >::~basic_string()'
collect2: error: ld returned 1 exit status

I think the coding error should be caught at the compile time by g++. 

Also, the problem is same with any generic C++ class/struct:

#include 

struct M {
  std::string s;
};

int main() {
  // std::string s = s;
  M m = m;
  return 0;
}

Also checked with g++ version 7.5.0, to see the same behavior.

[Bug tree-optimization/55912] missing optimization of x/x and x/std::abs(x)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug tree-optimization/94357] Inline assembly with memory operand is considered nothrow with `-fnon-call-exceptions`

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 52770.

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

[Bug c++/52770] RFE: Letting compiler know asm block can call function that can throw

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||sagebar at web dot de

--- Comment #4 from Andrew Pinski  ---
*** Bug 94357 has been marked as a duplicate of this bug. ***

[Bug c++/101850] Initialising a struct/class variable to itself does not fail at compile time (but throws std::bad_alloc at run time, as expected)

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

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

--- Comment #1 from Andrew Pinski  ---
In GCC 11+ we start to warn about this code with -W -Wall:
: In function 'int main()':
:5:19: warning: 's' may be used uninitialized [-Wmaybe-uninitialized]
5 |   std::string s = s;
  |   ^

[Bug c++/101850] Initialising a struct/class variable to itself does not fail at compile time (but throws std::bad_alloc at run time, as expected)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||48829

--- Comment #2 from Andrew Pinski  ---
See PR 48829 also.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48829
[Bug 48829] g++ no warning initializing a variable using itself

[Bug middle-end/36396] standard md pattern vec_realign_load_M and REALIGN_LOAD_EXPR tree are not documented

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|standard md pattern |standard md pattern
   |vec_realign_load_M isn't|vec_realign_load_M and
   |documented  |REALIGN_LOAD_EXPR tree are
   ||not documented
   Last reconfirmed|2008-12-28 01:47:22 |2021-8-10

--- Comment #2 from Andrew Pinski  ---
OPTAB_D (vec_realign_load_optab, "vec_realign_load_$a")


REALIGN_STORE_EXPR was removed not far after being added.


These were added back in r0-61921.