[Bug target/102211] [12 regression] ICE introduced by r12-3277

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

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

--- Comment #5 from Jim Wilson  ---
I have a WIP fix that lets me build newlib and glibc via riscv-gnu-toolchain. 
I haven't tried a bootstrap yet.  I created a new predicate that uses the small
bit of deleted code I need from validate_subregs, and then modified most
patterns with an f constraint to use it.

+;; This predicate should be used for any pattern that has constraints that
+;; accept FP registers.
+(define_predicate "f_register_operand"
+  (match_operand 0 "register_operand")
+{
+  /* We can't allow a subreg that changes size in an FP reg, as that violates
+ the NaN-boxing requirement.  Copied from old validate_subregs code.  */
+  if (GET_CODE (op) == SUBREG)
+{
+  machine_mode imode = GET_MODE (SUBREG_REG (op));
+  machine_mode omode = GET_MODE (op);
+  if (FLOAT_MODE_P (imode) || FLOAT_MODE_P (omode))
+   {
+ poly_uint64 isize = GET_MODE_SIZE (imode);
+ poly_uint64 osize = GET_MODE_SIZE (omode);
+
+ if (! (known_eq (isize, osize)
+/* LRA can use subreg to store a floating point value in
+   an integer mode.  Although the floating point and the
+   integer modes need the same number of hard registers,
+   the size of floating point mode can be less than the
+   integer mode.  LRA also uses subregs for a register
+   should be used in different mode in on insn.  */
+|| lra_in_progress))
+   return false;
+   }
+}
+  return true;
+})

I haven't fixed the move patterns yet.  I need a few more new predicates for
that.

The riscv_hard_regno_mode_ok function looks odd as Hongtao Liu mentioned.  The
mov*i patterns have f constraints, but we don't allow FP values in integer
registers here.  I think this is a missed optimization, or maybe good register
allocation creates some no-op moves to hide the problem.  My current patch does
not need a riscv_hard_regno_mode_ok change to work.

The riscv_can_change_mode_class also looks a little odd.  The MIPS one that we
copied doesn't allow mode changes in FP regs, but the alpha one does allow mode
changes in FP regs if the modes have the same size.  I think the alpha one can
work for RISC-V and that this is another missed optimization, though again
maybe good regalloc hides the problem with no-op moves.

But I will worry about the possible missed optimizations after I get bootstrap
working again.

[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||55004

--- Comment #10 from Andrew Pinski  ---
This is starting to get more duplicates because of lamdbas and C++11 and
constexprs.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||johelegp at gmail dot com

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

[Bug c++/102249] Can't compare pointers to function during constant evaluation

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug target/102250] [11/12 Regression] python is not documented as a Prerequisite for building for riscv

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

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

--- Comment #2 from Andrew Pinski  ---
Also is there a reason why this shell script could not be written in just plain
shell script with sed and awk instead of python?  Seems like adding python just
for this script is heavy weight.

[Bug target/89954] missed optimization for signed extension for x86-64

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
 aarch64 dump---
Failed to match this instruction:
(set (reg:SI 95)
(xor:SI (zero_extend:SI (mem/c:QI (lo_sum:DI (reg/f:DI 97)
(symbol_ref:DI ("*.LANCHOR0") [flags 0x182])) [0 c+0 S1
A8]))
(const_int 1 [0x1])))
Successfully matched this instruction:
(set (reg:SI 99)
(zero_extend:SI (mem/c:QI (lo_sum:DI (reg/f:DI 97)
(symbol_ref:DI ("*.LANCHOR0") [flags 0x182])) [0 c+0 S1 A8])))
Successfully matched this instruction:
(set (reg:SI 95)
(xor:SI (reg:SI 99)
(const_int 1 [0x1])))
-dump end

It looks like there's splitter in aarch64 which combines load+xor+zero_extend
to zero_extend(mem) + xor, x86 doesn't have. The simple way is to add
corresponding define_split for x86.

-x86 dump---
Failed to match this instruction:
(set (reg:SI 85)
(sign_extend:SI (xor:QI (mem/c:QI (symbol_ref:DI ("c") [flags 0x2] 
) [0 c+0 S1 A8])
(const_int 1 [0x1]
---dump end--

[Bug target/102250] [11/12 Regression] python is not documented as a Prerequisite for building for riscv

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

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

--- Comment #1 from Andrew Pinski  ---
The requirement was introduced by r11-5700.

[Bug target/102250] [11/12 Regression] python is not documented as a Prerequisite for building for riscv

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |major
 CC||kito.cheng at gmail dot com
   Target Milestone|--- |11.3

[Bug target/102250] New: [11/12 Regression] python is not documented as a Prerequisite for building for riscv

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

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

Bug ID: 102250
   Summary: [11/12 Regression] python is not documented as a
Prerequisite for building for riscv
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: riscv

The requirement for having python install is not documented to build for
riscv-linux-gnu:
https://gcc.gnu.org/install/prerequisites.html

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

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

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

--- Comment #4 from Jeffrey A. Law  ---
Bernd E. analyzed this in the thread referenced in c#1.

The test links staticly and we're pulling in the weak definition of
pthread_join.

I'm not sure why we're linking statically.  Reverting to normal dynamic linking
would likely fix this problem.

If that's not desired, then something like --whole-archive -lpthread
--no-whole-archive in the link line will make this work as long as it appears
before -lc.

Or we could add -Wl,-u,pthread_join to the link line.

Or we could hack up the source per Bernd's patch in that thread.

No strong opinions here.  Just trying to get another failure resolved on our
target :-)

[Bug c++/102249] New: Can't compare pointer to functions during constant evaluation

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 102249
   Summary: Can't compare pointer to functions during constant
evaluation
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

This is specified at https://eel.is/c++draft/expr.eq#3. See
https://godbolt.org/z/Wdradsb4a.
```C++
#include 
static_assert(not std::ranges::equal_to{}([]{}, +[]{}));
static_assert(std::not_equal_to{}([]{}, +[]{}));
static_assert([]{} != +[]{});
```
```
:2:15: error: non-constant condition for static assertion
2 | static_assert(not std::ranges::equal_to{}(+[]{}, +[]{}));
  |   ^
In file included from
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/iterator_concepts.h:37,
 from
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/stl_iterator_base_types.h:71,
 from
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/stl_algobase.h:65,
 from
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/array:40,
 from
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/tuple:39,
 from
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/functional:54,
 from :1:
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/ranges_cmp.h:93:39:
error: '(::_FUN == ::_FUN)' is not a constant expression
   93 |   { return std::forward<_Tp>(__t) == std::forward<_Up>(__u); }
  |~~~^
:3:34: error: non-constant condition for static assertion
3 | static_assert(std::not_equal_to{}(+[]{}, +[]{}));
  |   ~~~^~
In file included from
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/functional:49,
 from :1:
/opt/compiler-explorer/gcc-11.2.0/include/c++/11.2.0/bits/stl_function.h:509:41:
error: '(::_FUN != ::_FUN)' is not a constant expression
  509 | { return std::forward<_Tp>(__t) != std::forward<_Up>(__u); }
  |  ~~~^
:4:21: error: non-constant condition for static assertion
4 | static_assert(+[]{} != +[]{});
:4:21: error: '(::_FUN != ::_FUN)' is not a
constant expression
Compiler returned: 1
```

[Bug target/91103] AVX512 vector element extract uses more than 1 shuffle instruction; VALIGND can grab any element

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Hongtao.liu  ---
Fixed in GCC12.

[Bug target/101059] v4sf reduction not optimal

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
Fixed in GCC12.

[Bug target/101059] v4sf reduction not optimal

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r12-3426-g8f323c712ea76cc4506b03895e9b991e4e4b2baf
Author: liuhongt 
Date:   Tue Sep 7 12:39:04 2021 +0800

Optimize v4sf reduction.

gcc/ChangeLog:

PR target/101059
* config/i386/sse.md (reduc_plus_scal_): Split to ..
(reduc_plus_scal_v4sf): .. this, New define_expand.
(reduc_plus_scal_v2df): .. and this, New define_expand.

gcc/testsuite/ChangeLog:

PR target/101059
* gcc.target/i386/sse2-pr101059.c: New test.
* gcc.target/i386/sse3-pr101059.c: New test.

[Bug target/91103] AVX512 vector element extract uses more than 1 shuffle instruction; VALIGND can grab any element

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:60eec23b5eda0f350e572586eee738eab0804a74

commit r12-3425-g60eec23b5eda0f350e572586eee738eab0804a74
Author: liuhongt 
Date:   Wed Sep 8 16:19:37 2021 +0800

Optimize vec_extract for 256/512-bit vector when index exceeds the lower
128 bits.

-   vextracti32x8   $0x1, %zmm0, %ymm0
-   vmovd   %xmm0, %eax
+   valignd $8, %zmm0, %zmm0, %zmm1
+   vmovd   %xmm1, %eax

-   vextracti32x8   $0x1, %zmm0, %ymm0
-   vextracti128$0x1, %ymm0, %xmm0
-   vpextrd $3, %xmm0, %eax
+   valignd $15, %zmm0, %zmm0, %zmm1
+   vmovd   %xmm1, %eax

-   vextractf64x2   $0x1, %ymm0, %xmm0
+   valignq $2, %ymm0, %ymm0, %ymm0

-   vextractf64x4   $0x1, %zmm0, %ymm0
-   vextractf64x2   $0x1, %ymm0, %xmm0
-   vunpckhpd   %xmm0, %xmm0, %xmm0
+   valignq $7, %zmm0, %zmm0, %zmm0

gcc/ChangeLog:

PR target/91103
* config/i386/sse.md
(*vec_extract_valign):
New define_insn.

gcc/testsuite/ChangeLog:

PR target/91103
* gcc.target/i386/pr91103-1.c: New test.
* gcc.target/i386/pr91103-2.c: New test.

[Bug target/44553] Cross compiling for ia64 fails as stdlib.h doesn't exist

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Fixed for GCC 6 by r6-5814.

[Bug target/40363] Nonoptimal save/restore registers

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Fixed for GCC 4.8.0 by r0-120854.

[Bug c++/102220] Conversion from cv void* to object-type* not rejected during constant evaluation

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/96963] [10 Regression] -Wstringop-overflow false positive on -O3 or -O2 -ftree-vectorize when assigning consecutive char struct members

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||eugene.chereshnev at intel dot 
com

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

[Bug c++/102248] -Wstringop-overflow false positive

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/60318] Documentation bug: C++ Misunderstandings: Implicit Copy-Assignment for Virtual Bases

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed for all active branches. Thanks for the report, sorry it took so long to
fix!

[Bug c++/60318] Documentation bug: C++ Misunderstandings: Implicit Copy-Assignment for Virtual Bases

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

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

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

https://gcc.gnu.org/g:03b8e26897fbddec10a703cf518280af675e6458

commit r9-9715-g03b8e26897fbddec10a703cf518280af675e6458
Author: Jonathan Wakely 
Date:   Tue Aug 31 09:46:41 2021 +0100

c++: Fix docs on assignment of virtual bases [PR60318]

The description of behaviour is incorrect, the virtual base gets
assigned before entering the bodies of A::operator= and B::operator=,
not after.

The example is also ill-formed (passing a string literal to char*) and
undefined (missing return from Base::operator=).

Signed-off-by: Jonathan Wakely 

gcc/ChangeLog:

PR c++/60318
* doc/trouble.texi (Copy Assignment): Fix description of
behaviour and fix code in example.

(cherry picked from commit 3c64582372cf445eabc4f9e99def7e33fb0270ee)

[Bug c++/102248] New: -Wstringop-overflow false positive

[eugene.chereshnev at intel dot com via Gcc-bugs]

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

Bug ID: 102248
   Summary: -Wstringop-overflow false positive
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eugene.chereshnev at intel dot com
  Target Milestone: ---

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

Observing false positive with 10.x versions, 9.x and 11.x versions are good.
Reproduced only with -O3.

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

$ cat 1.cpp
#include 

struct Foo {
int8_t a, b;

Foo(): a(0), b(1) {}
};

struct Bar {
Bar();

Foo x0;
Foo x1;
Foo x2;
Foo x3;
};


void foo(Foo&);

Bar::Bar() { foo(x0); }
$ g++ -c -O3 1.cpp
In constructor ‘Foo::Foo()’,
inlined from ‘Bar::Bar()’ at 1.cpp:21:10:
1.cpp:6:21: warning: writing 8 bytes into a region of size 2
[-Wstringop-overflow=]
6 | Foo(): a(0), b(1) {}
  | ^
1.cpp: In constructor ‘Bar::Bar()’:
1.cpp:12:9: note: at offset 0 to object ‘Bar::x0’ with size 2 declared here
   12 | Foo x0;
  | ^~

Godbolt link: https://godbolt.org/z/W7e4PqK7n

[Bug c++/60318] Documentation bug: C++ Misunderstandings: Implicit Copy-Assignment for Virtual Bases

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

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

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

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

commit r10-10102-gb9f52acb7dc74fb7b4591f98d81cdcf54b36df38
Author: Jonathan Wakely 
Date:   Tue Aug 31 09:46:41 2021 +0100

c++: Fix docs on assignment of virtual bases [PR60318]

The description of behaviour is incorrect, the virtual base gets
assigned before entering the bodies of A::operator= and B::operator=,
not after.

The example is also ill-formed (passing a string literal to char*) and
undefined (missing return from Base::operator=).

Signed-off-by: Jonathan Wakely 

gcc/ChangeLog:

PR c++/60318
* doc/trouble.texi (Copy Assignment): Fix description of
behaviour and fix code in example.

(cherry picked from commit 3c64582372cf445eabc4f9e99def7e33fb0270ee)

[Bug c++/60318] Documentation bug: C++ Misunderstandings: Implicit Copy-Assignment for Virtual Bases

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

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

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

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

commit r11-8974-gd7b2e9bd1a3cdb502bfd837d56ef809817ef0db7
Author: Jonathan Wakely 
Date:   Tue Aug 31 09:46:41 2021 +0100

c++: Fix docs on assignment of virtual bases [PR60318]

The description of behaviour is incorrect, the virtual base gets
assigned before entering the bodies of A::operator= and B::operator=,
not after.

The example is also ill-formed (passing a string literal to char*) and
undefined (missing return from Base::operator=).

Signed-off-by: Jonathan Wakely 

gcc/ChangeLog:

PR c++/60318
* doc/trouble.texi (Copy Assignment): Fix description of
behaviour and fix code in example.

(cherry picked from commit 3c64582372cf445eabc4f9e99def7e33fb0270ee)

[Bug c++/102247] Overload resolution with brace-init is ambiguous when it shouldn't be

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

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

--- Comment #1 from Andrew Pinski  ---
I think this the same case as in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84849#c5 .

[Bug c++/102247] New: Overload resolution with brace-init is ambiguous when it shouldn't be

[ldionne.2 at gmail dot com via Gcc-bugs]

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

Bug ID: 102247
   Summary: Overload resolution with brace-init is ambiguous when
it shouldn't be
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldionne.2 at gmail dot com
  Target Milestone: ---

The following code fails to compile when I believe it should succeed
(https://godbolt.org/z/z9aved8Wb):

#include 

template 
struct pair {
template
constexpr pair(U1&&, U2&&) { }
};

struct BraceInit { BraceInit() = default; };
struct ExplicitBraceInit { explicit ExplicitBraceInit() = default; };

constexpr int f(pair) { return 1; }
constexpr int f(pair) { return 2; }

static_assert(f({{}, {}}) == 2, "");

Indeed, the error is

:15:16: error: call of overloaded 'f()' is ambiguous
15 | static_assert(f({{}, {}}) == 2, "");
|   ~^~
:12:15: note: candidate: 'constexpr int f(pair)'
12 | constexpr int f(pair) { return
1; }
|   ^
:13:15: note: candidate: 'constexpr int f(pair)'
13 | constexpr int f(pair) { return 2; }
|   ^
Compiler returned: 1

I think it should succeed because `f(pair)` can never be selected, since selecting it would require
using the explicit constructor of `ExplicitBraceInit`. And indeed, if we try to
call `f(pair)` alone, we get
(https://godbolt.org/z/W33Pvnnoe):

:15:16: error: converting to 'ExplicitBraceInit' from initializer
list would use explicit constructor 'constexpr
ExplicitBraceInit::ExplicitBraceInit()'
15 | static_assert(f({{}, {}}) == 2, "");
|   ~^~
Compiler returned: 1

So I'm not sure why that overload is considered valid for overload resolution
(leading to the ambiguity), but it seems like GCC itself doesn't think it's
valid when there are no other candidates. Also note that Clang compiles this
code without issue, calling the non-explicit BraceInit version as expected.

This issue was uncovered while implementing http://wg21.link/P1951 in libc++.

[Bug libgomp/96661] configure:16984: error: unsupported system, cannot find Fortran int kind=16

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

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

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

[Bug libgomp/102246] [11 Regression] libgomp build broken on hppa64-hp-hpux*

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 96661.

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

[Bug libgomp/102246] [11 Regression] libgomp build broken on hppa64-hp-hpux*

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

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

--- Comment #1 from Jakub Jelinek  ---
There is no reason why 64-bit target couldn't support 128-bit ints, and they
are really required here.  The OpenMP standards requires a Fortran kind for
this and we need pointer + extra info.
So, if 128-bit int support can't be enabled on hppa64-hp-hpux*, then it can't
support libgomp.

[Bug libgomp/102246] New: [11 Regression] libgomp build broken on hppa64-hp-hpux*

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

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

Bug ID: 102246
   Summary: [11 Regression] libgomp build broken on
hppa64-hp-hpux*
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux*
Target: hppa64-hp-hpux*
 Build: hppa64-hp-hpux*

The following change broke building libgomp on hppa64-hp-hpux* even when
fortran
is not being built:

2020-07-23  Tobias Burnus  

* configure.ac: Add OMP_DEPEND_KIND and OMP_INT128_SIZE.
* libgomp_f.h.in (omp_check_defines): Check whether
sizeof of determined Fortran kind and C typedef match.
* omp_lib.f90.in: Add omp_depened_kind.
* omp_lib.h.in: Likewise; fix omp_alloctrait_key_kind.
* configure: Regenerate.
* Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.

Although there is support for 128-bit floats, there is currently no int128
support on this target.

If I disable the configure check, everything builds successfully.  The only
libgomp test that fails due to this is:

FAIL: libgomp.fortran/depobj-1.f90   -O  (test for excess errors)

[Bug c/102245] [12 Regression] false int-in-bool-context warning with shift

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

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

--- Comment #4 from Jakub Jelinek  ---
So, seems the binary context is result of shorten_binary_op, we see the
1L and (((int)x) << 0) operands of BIT_AND_EXPR, result_type is therefore long
int and shorten_binary_op uses convert to convert that (((int)x) << 0) to long
int and triggers the match.pd rule and folds it into (long int)x (where x has
_Bool type).
shorten_binary_op then decides to return _Bool type, which is why we have the
bool context.

[Bug bootstrap/102242] [12 regression] analyzer/engine.cc built with clang: /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort'

[gerald at pfeifer dot com via Gcc-bugs]

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

--- Comment #3 from Gerald Pfeifer  ---
(In reply to David Malcolm from comment #1)
> Sorry about the breakage.

That's what my nightly testers are here for to catch. :)

> I think I need to #define INCLUDE_UNIQUE_PTR before including system.h,
> rather than manually including .  Was that what your patch does?

In my patch, which passed bootstrap in the meantime, I added

#ifdef INCLUDE_MEMORY
# include 
#endif

to gcc/system.h and defined INCLUDE_MEMORY early in analyzer/engine.cc.

Your patch sounds a little lighter and in fact more portable, so happy if
you want to go with it.

[Bug bootstrap/102242] [12 regression] analyzer/engine.cc built with clang: /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort'

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-09-08
 Ever confirmed|0   |1
   Target Milestone|--- |12.0
   Keywords||build

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug c/102245] [12 Regression] false int-in-bool-context warning with shift

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-08
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Started with r12-3073-g1d244020246cb155e4de62ca3b302b920a1f513f
Deobfuscated testcase:
int
foo (_Bool x)
{
  int v = 0;
  return (v & ~1L) | (1L & (x << 0));
}

[Bug c/102245] [12 Regression] false int-in-bool-context warning with shift

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
Summary|false  int-in-bool-context  |[12 Regression] false
   |warning with shift  |int-in-bool-context warning
   ||with shift

[Bug c/102245] false int-in-bool-context warning with shift

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

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

--- Comment #2 from Andrew Pinski  ---
So this is a regression only on the trunk.

[Bug c/102245] false int-in-bool-context warning with shift

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

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

--- Comment #1 from Andrew Pinski  ---
I should mention this was reduced from drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c in
the Linux kernel compiling for arm-linux-gnueabi but can reproduce the warning
on x86_64 with -m32 option.

[Bug c/102245] New: false int-in-bool-context warning with shift

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

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

Bug ID: 102245
   Summary: false  int-in-bool-context warning with shift
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
#define shiftCB_DISABLE_FAULT_ON_UNMAPPED_ACCESS1 0
#define maskCB_DISABLE_FAULT_ON_UNMAPPED_ACCESS1 1L

#define REG_FIELD_MASK(a,b) (mask##b)
#define REG_FIELD_SHIFT(a,b) (shift##b)

#define REG_SET_FIELD(orig_val, reg, field, field_val)  \
(((orig_val) & ~REG_FIELD_MASK(reg, field)) |   \
 (REG_FIELD_MASK(reg, field) & ((field_val) << REG_FIELD_SHIFT(reg,
field



int f(_Bool enable)
{
  int tmp = 0;
  tmp = REG_SET_FIELD(tmp, VM_PRT_CNTL,
  CB_DISABLE_FAULT_ON_UNMAPPED_ACCESS1,
  enable);
  return tmp;
}

-- CUT 
Compile this on an ILP32 target with "-W -Wall -O2 -Werror
-Werror=int-in-bool-context" and you get:
: In function 'f':
:10:53: error: '<<' in boolean context, did you mean '<'?
[-Werror=int-in-bool-context]
   10 |  (REG_FIELD_MASK(reg, field) & ((field_val) <<
REG_FIELD_SHIFT(reg, field
  |   
~^~~
:17:9: note: in expansion of macro 'REG_SET_FIELD'
   17 |   tmp = REG_SET_FIELD(tmp, VM_PRT_CNTL,
  | ^
cc1: all warnings being treated as errors


This is not correct as the shift is correct, I want to do a shift by 0 here and
there is no boolean context at all. And it does not warn with LP64 targets
either.

[Bug c++/60318] Documentation bug: C++ Misunderstandings: Implicit Copy-Assignment for Virtual Bases

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

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

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

https://gcc.gnu.org/g:3c64582372cf445eabc4f9e99def7e33fb0270ee

commit r12-3423-g3c64582372cf445eabc4f9e99def7e33fb0270ee
Author: Jonathan Wakely 
Date:   Tue Aug 31 09:46:41 2021 +0100

c++: Fix docs on assignment of virtual bases [PR60318]

The description of behaviour is incorrect, the virtual base gets
assigned before entering the bodies of A::operator= and B::operator=,
not after.

The example is also ill-formed (passing a string literal to char*) and
undefined (missing return from Base::operator=).

Signed-off-by: Jonathan Wakely 

gcc/ChangeLog:

PR c++/60318
* doc/trouble.texi (Copy Assignment): Fix description of
behaviour and fix code in example.

[Bug target/102244] Arc: Error: operand out of range (0x0000000000001036 is not between 0xfffffffffffff000 and 0x0000000000000fff)

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

Giulio Benetti  changed:

   What|Removed |Added

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

--- Comment #3 from Giulio Benetti  ---
Sorry for the noise. This bug is Synopsis's toolchain related and has nothing
to deal with official gcc.

Pardon. I mark this bug as Resolved/Invalid.

[Bug c++/102223] no warning when calling member function on dangling reference

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Federico Kircheis from comment #6)
> That's true, but if you look at the assembly there is no function call to
> std::move,

There is though, on line 10.

[Bug target/102244] Arc: Error: operand out of range (0x0000000000001036 is not between 0xfffffffffffff000 and 0x0000000000000fff)

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #2 from Giulio Benetti  ---
Created attachment 51427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51427=edit
Pre-processed hb-ot-shape-complex-use.cpp(hb-ot-shape-complex-use.s)

[Bug c++/102244] Arc: Error: operand out of range (0x0000000000001036 is not between 0xfffffffffffff000 and 0x0000000000000fff)

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #1 from Giulio Benetti  ---
Created attachment 51426
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51426=edit
Pre-processed hb-ot-shape-complex-use.cpp(hb-ot-shape-complex-use.ii)

[Bug c++/102244] New: Arc: Error: operand out of range (0x0000000000001036 is not between 0xfffffffffffff000 and 0x0000000000000fff)

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

Bug ID: 102244
   Summary: Arc: Error: operand out of range (0x1036
is not between 0xf000 and
0x0fff)
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: giulio.benetti at benettiengineering dot com
  Target Milestone: ---

When building package harfbuzz on buildroot we get this error:
'''
[45/74] Compiling C++ object
src/libharfbuzz.so.0.20900.0.p/hb-ot-shape-complex-use.cc.o
FAILED: src/libharfbuzz.so.0.20900.0.p/hb-ot-shape-complex-use.cc.o 
/home/giuliobenetti/br_reproduce/e4da9ba40c8f4567601d404e20dd6a0b322210c2/output/host/bin/arc-buildroot-linux-uclibc-g++
-Isrc/libharfbuzz.so.0.20900.0.p -Isrc -I../src -I. -I..
-I/home/giuliobenetti/br_reproduce/e4da9ba40c8f4567601d404e20dd6a0b322210c2/output/host/arc-buildroot-linux-uclibc/sysroot/usr/include/freetype2
-I/home/giuliobenetti/br_reproduce/e4da9ba40c8f4567601d404e20dd6a0b322210c2/output/host/arc-buildroot-linux-uclibc/sysroot/usr/include
-I/home/giuliobenetti/br_reproduce/e4da9ba40c8f4567601d404e20dd6a0b322210c2/output/host/arc-buildroot-linux-uclibc/sysroot/usr/include/glib-2.0
-I/home/giuliobenetti/br_reproduce/e4da9ba40c8f4567601d404e20dd6a0b322210c2/output/host/arc-buildroot-linux-uclibc/sysroot/usr/lib/glib-2.0/include
-fdiagnostics-color=always -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++11
-fno-exceptions -fno-rtti -O3 -fno-exceptions -fno-rtti -fno-threadsafe-statics
-fvisibility-inlines-hidden -DHAVE_CONFIG_H -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g2 -fPIC -pthread
-Wno-non-virtual-dtor -MD -MQ
src/libharfbuzz.so.0.20900.0.p/hb-ot-shape-complex-use.cc.o -MF
src/libharfbuzz.so.0.20900.0.p/hb-ot-shape-complex-use.cc.o.d -o
src/libharfbuzz.so.0.20900.0.p/hb-ot-shape-complex-use.cc.o -c
../src/hb-ot-shape-complex-use.cc
/tmp/ccC22PCP.s: Assembler messages:
/tmp/ccC22PCP.s:21423: Error: operand out of range (0x1036 is not
between 0xf000 and 0x0fff)
'''

To reproduce the bug:
'''
# git clone git://git.busybox.net/buildroot
# wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build

- modify BASE_GIT=... with your buildroot path in br-reproduce-build then:
# chmod a+x br-reproduce-build
# ./br-reproduce-build e4da9ba40c8f4567601d404e20dd6a0b322210c2
'''

I've found that it can be worked around disabling the optimization passing -O0
to CFLAGS.

[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop

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

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

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #9)
> (In reply to Steve Kargl from comment #7)
> > This regresses okay.
> 
> Still does.  Shall I submit it for review, commit for you, or let it bit-rot?

If you agree with the patch, I think you can commit it without review.
Two sets of eyes (yours and mine) have looked over the patch.  You'll
still need to submit emails.  Just use the "committed as obvious" or
"committed after discussion with Steve" excuse.

[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #7)
> This regresses okay.

Still does.  Shall I submit it for review, commit for you, or let it bit-rot?

[Bug fortran/92805] gfortran: blanks within literal constants should not be allowed

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #9)
> (In reply to Steve Kargl from comment #4)
> > Tested.
> 
> I tried to resurrect your patch, but it partly misses on the following:
> 
>   integer, parameter :: ck = kind ("a")  ! default character kind
>   print *, ck_"a"
>   print *, ck _"a"
>   print *, ck_ "a"
>   print *, 1_"a"
>   print *, 1 _"a"
>   print *, 1_ "a"
>   end
> 
> pr92805.f90:3:19:
> 
> 3 |   print *, ck _"a"
>   |   1
> Error: Syntax error in PRINT statement at (1)
> pr92805.f90:4:20:
> 
> 4 |   print *, ck_ "a"
>   |1
> Error: Syntax error in PRINT statement at (1)
> 
> For some reason we detect only some of the syntax violations.

Thanks for taking a look.  I completely forgot about
character kinds.  I wonder if the difference/problem
is caused by location.  Numeric kinds are suffixes on
the literal constant while character kinds are prefixes.

[Bug libstdc++/102221] Missed optimizations for algorithms over std::unique_ptr

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> This comes from the construction of a local unique_ptr variable in:
> 
>   template
> _GLIBCXX20_CONSTEXPR
> void
> __unguarded_linear_insert(_RandomAccessIterator __last,
> _Compare __comp)

Actually, even if we eliminate the temporary here, there's another in the
__make_heap routine:

  while (true)
{
  _ValueType __value = _GLIBCXX_MOVE(*(__first + __parent));
  std::__adjust_heap(__first, __parent, __len, _GLIBCXX_MOVE(__value),
 __comp);
  if (__parent == 0)
return;
  __parent--;
}

[Bug fortran/97589] Segementation fault when allocating coarrays.

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #28 from anlauf at gcc dot gnu.org ---
(In reply to Toon Moene from comment #27)
> Yes, I am now convince this works (64 leads to stop 1, but 63 works).

So has this been definitely fixed, and can we close it?

[Bug libstdc++/102221] Missed optimizations for algorithms over std::unique_ptr

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Giuseppe D'Angelo from comment #2)
> Hi,
> 
> Thanks for the analysis!
> 
> That basically allows me to reduce the testcase to something as simple as a
> swap:

Yes. The actual swaps done by std::sort don't cause the problem, because they
use the overload for swapping unique_ptrs, which calls the member function,
which doesn't need to create+destroy a local. But the __unguarded_linear_insert
function doesn't use swap, and directly creates a local like the generic
std::swap does.


> I don't think this falls on libstdc++, rather than on the optimizer?

Agreed, except that we might (one day) be able to simplify unique_ptr, to help
the optimizer do better.

[Bug middle-end/102243] [12 Regression] ice in get_range_query

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

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

--- Comment #1 from Andrew Pinski  ---
I suspect r12-3300-gece28da924dd

[Bug middle-end/102243] [12 Regression] ice in get_range_query

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ice in get_range_query  |[12 Regression] ice in
   ||get_range_query
   Keywords||ice-on-valid-code
   Target Milestone|--- |12.0
  Component|c++ |middle-end

[Bug c++/102243] New: ice in get_range_query

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 102243
   Summary: ice in get_range_query
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C++ code:

$ more bug755.cc
void *operator new(unsigned long, void *);
class FlagRegisterer {
public:
  template < typename FlagType >
  FlagRegisterer(char *, char *, char *, FlagType, FlagType);
};
union {
  char s[sizeof(int)];
} s_message[2];
int FLAGS_nomessage;
FlagRegisterer o_message("", "", "", _nomessage,
 new (s_message[1].s) int);

with recent g++ and *no* optimiser flags, does this:

$ /home/dcb/gcc/results/bin/g++ -c bug755.cc
bug755.cc:12:47: internal compiler error: Segmentation fault
   12 |  new (s_message[1].s) int);
  |   ^~~
0x1013819 crash_signal(int)
../../trunk.git/gcc/toplev.c:328
0x12286ff get_range_query(function const*)
../../trunk.git/gcc/function.h:728

Git hash range seems to be 7a6f40d0452ec76e..9695e1c23be5b5c5,
so only 21 commits.

[Bug c++/102223] no warning when calling member function on dangling reference

[federico.kircheis at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Federico Kircheis  ---
> are you expecting this to go under an existing warning flag, or a new one?

Ideally -Wall, but there might already be some flags related to dangling
pointers and references.

> Your compiler explorer link doesn't enable optimizations.

That's true, but if you look at the assembly there is no function call to
std::move, thus I assumed that contrary to another (non-inline) function call,
a diagnostic would have been possible even without optimizations.
But there is no warning even with optimizations enabled.


> I assume you already know this, but the original testcase in comment 0 is 
> perfectly valid. The static_cast creates a new temporary, which *does* get 
> its lifetime extended.


Yes, should have made it clearer in comment #1, sorry.
Unfortunately I realized after I wrote the message that I copied the wrong
snippet (and typed thus a wrong explanation), and I could not edited it.

> With inlining, in theory it would be possible to diagnose the invalid access, 
> but other compilers don't do it either. It would be nice, but I'm not sure 
> it's likely to happen any time soon.

I noticed too that other compiler do not do this diagnostic.
Too bad.


> GCC doesn't even get it right in constexpr contexts, see PR 70331 and the 
> linked bugs in the See Also field.

Ouch.


> PR 96780 comment 2 could potentially help for the specific case of std::move, 
> but not the general case.


AS I had a discussion explicitly about std::move/xvalues and lifetime
extension, I'll say it's a good start.
And it confused me until I realized std::move is a function, and thus obviously
destroys lifetime extension in the example I gave, while the cast not.


> N.B AddressSanitizer will diagnose this at runtime.
+1

[Bug fortran/92805] gfortran: blanks within literal constants should not be allowed

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #4)
> Tested.

I tried to resurrect your patch, but it partly misses on the following:

  integer, parameter :: ck = kind ("a")  ! default character kind
  print *, ck_"a"
  print *, ck _"a"
  print *, ck_ "a"
  print *, 1_"a"
  print *, 1 _"a"
  print *, 1_ "a"
  end

pr92805.f90:3:19:

3 |   print *, ck _"a"
  |   1
Error: Syntax error in PRINT statement at (1)
pr92805.f90:4:20:

4 |   print *, ck_ "a"
  |1
Error: Syntax error in PRINT statement at (1)

For some reason we detect only some of the syntax violations.

[Bug bootstrap/102242] [12 regression] analyzer/engine.cc built with clang: /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort'

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

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Sorry about the breakage.

I think I need to #define INCLUDE_UNIQUE_PTR before including system.h, rather
than manually including .  Was that what your patch does?

[Bug bootstrap/102242] New: [11 regression] analyzer/engine.cc built with clang: /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort'

[gerald at pfeifer dot com via Gcc-bugs]

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

Bug ID: 102242
   Summary: [11 regression] analyzer/engine.cc built with clang:
/usr/include/c++/v1/typeinfo:346:5: error: no member
named 'fancy_abort'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerald at pfeifer dot com
  Target Milestone: ---

Only with clang as bootstrap compiler:

  In file included from
/scratch/tmp/gerald/GCC-HEAD/gcc/analyzer/engine.cc:69:
  In file included from /usr/include/c++/v1/memory:653:
  /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort' 
in name space 'std::__1'; did you mean simply 'fancy_abort'?
_VSTD::abort();
^~~
  /usr/include/c++/v1/__config:782:15: note: expanded from macro '_VSTD'
  #define _VSTD std::_LIBCPP_ABI_NAMESPACE
^
  /scratch/tmp/gerald/GCC-HEAD/gcc/system.h:777:13: note: 'fancy_abort'
declared here
  extern void fancy_abort (const char *, int, const char *)
  ^

I am pretty sure this is caused by

  gcc/analyzer/ChangeLog:
   PR analyzer/99260
   * analyzer.h (class custom_edge_info): New class, adapted from
   exploded_edge::custom_info_t.  Make member functions const.
   Make update_model return bool, converting edge param from
   reference to a pointer, and adding a ctxt param.
   (class path_context): New class.
   * call-info.cc: New file.
   * call-info.h: New file.
   * engine.cc: Include "analyzer/call-info.h" and .

and think I have an idea how to tackle this. Prototype patch in testing...

[Bug analyzer/102225] [12 Regression] ICE in get_or_create_int_cst, at analyzer/region-model-manager.cc:227 since r12-3237-geafa9d969237fd8f

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/102225] [12 Regression] ICE in get_or_create_int_cst, at analyzer/region-model-manager.cc:227 since r12-3237-geafa9d969237fd8f

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r12-3422-ge66b9f6779f46433b0e2c093b58403604ed131cc
Author: David Malcolm 
Date:   Wed Sep 8 14:37:19 2021 -0400

analyzer: fix ICE when discarding result of realloc [PR102225]

gcc/analyzer/ChangeLog:
PR analyzer/102225
* analyzer.h (compat_types_p): New decl.
* constraint-manager.cc
(constraint_manager::get_or_add_equiv_class): Guard against NULL
type when checking for pointer types.
* region-model-impl-calls.cc (region_model::impl_call_realloc):
Guard against NULL lhs type/region.  Guard against the size value
not being of a compatible type for dynamic extents.
* region-model.cc (compat_types_p): Make non-static.

gcc/testsuite/ChangeLog:
PR analyzer/102225
* gcc.dg/analyzer/realloc-1.c (test_10): New.
* gcc.dg/analyzer/torture/pr102225.c: New test.

[Bug target/102224] [9/10 regession] wrong code for `x * copysign(1.0, x)` since r9-5298-g33142cf9cf82aa1f

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11 regession] wrong   |[9/10 regession] wrong code
   |code for `x * copysign(1.0, |for `x * copysign(1.0, x)`
   |x)` since   |since
   |r9-5298-g33142cf9cf82aa1f   |r9-5298-g33142cf9cf82aa1f

--- Comment #16 from Jakub Jelinek  ---
Fixed for 11.3 too.

[Bug target/102224] [9/10/11 regession] wrong code for `x * copysign(1.0, x)` since r9-5298-g33142cf9cf82aa1f

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

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

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

commit r11-8973-gcb5690b8d2ce84fb943535bea0d587863cf57753
Author: Jakub Jelinek 
Date:   Wed Sep 8 11:25:31 2021 +0200

i386: Fix up @xorsign3_1 [PR102224]

As the testcase shows, we miscompile @xorsign3_1 if both input
operands are in the same register, because the splitter overwrites op1
before with op1 & mask before using op0.

For dest = xorsign op0, op0 we can actually simplify it from
dest = (op0 & mask) ^ op0 to dest = op0 & ~mask (aka abs).

The expander change is an optimization improvement, if we at expansion
time know it is xorsign op0, op0, we can emit abs right away and get better
code through that.

The @xorsign3_1 is a fix for the case where xorsign wouldn't be known
to have same operands during expansion, but during RTL optimizations they
would appear.  We need to use earlyclobber, we require dest and op1 to be
the same but op0 must be different because we overwrite
op1 first.

2021-09-08  Jakub Jelinek  

PR target/102224
* config/i386/i386.md (xorsign3): If operands[1] is equal to
operands[2], emit abs2 instead.
(@xorsign3_1): Add early-clobber for output operand.

* gcc.dg/pr102224.c: New test.
* gcc.target/i386/avx-pr102224.c: New test.

(cherry picked from commit a7b626d98a9a821ffb33466818d6aa86cac1d6fd)

[Bug fortran/102240] [PDT] derived type parameter does not shadow variable name in enclosing scope

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2021-09-08
 Ever confirmed|0   |1
Summary|[F03] derived type  |[PDT] derived type
   |parameter does not shadow   |parameter does not shadow
   |variable name in enclosing  |variable name in enclosing
   |scope   |scope
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d

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

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

--- Comment #17 from Segher Boessenkool  ---
(In reply to Hongtao.liu from comment #15)
> as discussed in
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578437.html, allow
> specific float-int subreg seems weird.

Indiscriminately allowing all of them is a bad idea.  No machine (that has
more than just integer hardware) can actually use those, resulting in ICEs
(like here) or inefficient code generated by reload, or a mix, or worse.

> And when i look the pattern, it also seems to be strange to disallow subreg
> in operands[1], IMHO things like TARGET_ALLOW_SF_SUBREG should be done in
> TARGET_CAN_CHANGE_MODE_CLASS, so reload/lra will do the right thing.

No.  We usually have this in the predicates.  But there simply is no even
remotely efficient way to do such moves, so we should not pretend there is.

It would be nicer to disallow such subregs elsewhere, sure.

(And rs6000_can_change_mode_class already disallows this move fwiw).

[Bug fortran/102145] TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #3 from Steve Kargl  ---
On Wed, Sep 08, 2021 at 02:14:26PM +, ripero84 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102145
> 
> --- Comment #2 from ripero84 at gmail dot com ---
> 1) The gfortran manual has its own entries for -pedantic and -pedantic-errors:
> 

Seems I owe you an apology.  I failed to check the gfortran
manual as I assumed these options where inherited from gcc
general option pool, and thus, documented in the gcc manual.

(option descriptions removed)

> 2) This answers part of my issue: the behaviour is indeed
>documented, just in a way that has proved confusing to me.

Well, there are lots of things that gfortran does that I
find confusing, and I've contributed to some of it. ;)

>  It think that a more accurate description
> would start with: 
> 
> -pedantic: Issue warnings for some uses of extensions to Fortran, raise
> otherwise warnings to errors for others.  Not all extensions will raise
> warnings or errors.
> 
> which sounds bad.

Yes, it sounds bad, but at least reflects reality.  -pedantic
is not really pedantic.

> 3) If this is the intended behaviour I can propose some tweaks
> to the documentation, but as I said first I would like to have
> a confirmation (ideally by the person who set up the interaction
> between -pedantic and -fallow-argument-mismatch) that this is
> really intended behaviour, not accidental.

You would need to ping Thomas about the intended behavior.

> 
> 4) Apologies for not going into the C discussion, my C is limited,
>

No apology needed given gfortran's manual documents (badly?)
these options.  Given the lack of volunteers to maintain 
gfortran at the moment, the best path forward may be an
attempt to clarify the option descriptions.

After years of contributing to gfortran, I have come to the
conclusion that all extensions should require options to
permit them.  -std=gnu would activate the options; while, 
any other -std=... would de-active all of the extensions
and issue errors.  But, that ship has sailed.

[Bug gcov-profile/90364] 521.wrf_r is 8-17% slower with PGO at -Ofast and native march/mtune

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #10 from Martin Liška  ---
All right, I understand what goes wrong. The benchmark builds 2 binaries: wrf_r
and diffwrf_521. Both of them contain pretty much the same objects that *are*
built twice:

gfortran -c -o module_mp_wsm5.fppized.o -I. -I./netcdf/include -I./inc -O2
-march=native -std=legacy -fprofile-generate -fconvert=big-endian -fno-openmp
-g0 module_mp_wsm5.fppized.f90

then wrf_r is trained, module_mp_wsm5.fppized.gcda is properly created.
But then diffwrf_521 is invoked and the GCDA if overwritten:

$ export GCOV_ERROR_FILE=/tmp/wrf.txt
...
$ grep wsm5 /tmp/wrf.txt
libgcov profiling
error:/home/marxin/Programming/cpu2017/benchspec/CPU/521.wrf_r/build/build_peak_gcc-m64./module_mp_wsm5.fppized.gcda:overwriting
an existing profile data with a different timestamp

That explains why we end up with a profile that has relatively low
sum_max=4450478, as shown the profile comes from a verification binary 
 diffwrf_521.

I don't have an easy solution for that. Maybe we can somehow drop
-fprofile-generate for diffwrf_521 binary. Is it possible?

[Bug c++/101874] [12 Regression] ICE with auto specifier for VLAs since r12-1933-ge66d0b7b87d105d2

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/102228] lookup_anon_field is quadratic

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||12.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #8 from Richard Biener  ---
Fixed for GCC 12.

[Bug c++/102228] lookup_anon_field is quadratic

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

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

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

https://gcc.gnu.org/g:716a5836928ee6d8fb884d9a2fbc1b1386ec8994

commit r12-3421-g716a5836928ee6d8fb884d9a2fbc1b1386ec8994
Author: Richard Biener 
Date:   Wed Sep 8 10:39:27 2021 +0200

c++/102228 - make lookup_anon_field O(1)

For the testcase in PR101555 lookup_anon_field takes the majority
of parsing time followed by get_class_binding_direct/fields_linear_search
which is PR83309.  The situation with anon aggregates is particularly
dire when we need to build accesses to their members and the anon
aggregates are nested.  There for each such access we recursively
build sub-accesses to the anon aggregate FIELD_DECLs bottom-up,
DFS searching for them.  That's inefficient since as I believe
there's a 1:1 relationship between anon aggregate types and the
FIELD_DECL used to place them.

The patch below does away with the search in lookup_anon_field and
instead records the single FIELD_DECL in the anon aggregate types
lang-specific data, re-using the RTTI typeinfo_var field.  That
speeds up the compile of the testcase with -fsyntax-only from
about 4.5s to slightly less than 1s.

I tried to poke holes into the 1:1 relationship idea with my C++
knowledge but failed (which might not say much).  It also leaves
a hole for the case when the C++ FE itself duplicates such type
and places it at a semantically different position.  I've tried
to poke holes into it with the duplication mechanism I understand
(templates) but failed.

2021-09-08  Richard Biener  

PR c++/102228
gcc/cp/
* cp-tree.h (ANON_AGGR_TYPE_FIELD): New define.
* decl.c (fixup_anonymous_aggr): Wipe RTTI info put in
place on invalid code.
* decl2.c (reset_type_linkage): Guard CLASSTYPE_TYPEINFO_VAR
access.
* module.cc (trees_in::read_class_def): Likewise.  Reconstruct
ANON_AGGR_TYPE_FIELD.
* semantics.c (finish_member_declaration): Populate
ANON_AGGR_TYPE_FIELD for anon aggregate typed members.
* typeck.c (lookup_anon_field): Remove DFS search and return
ANON_AGGR_TYPE_FIELD directly.

[Bug fortran/102241] New: ICE when declaring derived type with a parameterized derived type member

[roland_wirth at web dot de via Gcc-bugs]

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

Bug ID: 102241
   Summary: ICE when declaring derived type with a parameterized
derived type member
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland_wirth at web dot de
  Target Milestone: ---

The following code triggers an ICE in gfortran 9.1.0

MODULE mo
  TYPE t1(n)
INTEGER, LEN :: n
INTEGER :: a(n)
  END TYPE

  TYPE t2
TYPE(t1(1)) :: p_t1
  END TYPE
END MODULE

f951: internal compiler error: in gfc_get_derived_type, at
fortran/trans-types.c:2519
0x586d70 gfc_get_derived_type(gfc_symbol*, int)
../.././gcc/fortran/trans-types.c:2519
0x715384 gfc_get_derived_type(gfc_symbol*, int)
../.././gcc/fortran/trans-types.c:2670
0x715cd8 gfc_typenode_for_spec(gfc_typespec*, int)
../.././gcc/fortran/trans-types.c:1166
0x71601c gfc_sym_type(gfc_symbol*)
../.././gcc/fortran/trans-types.c:2247
0x71601c gfc_sym_type(gfc_symbol*)
../.././gcc/fortran/trans-types.c:2205
0x6bf0a2 gfc_get_symbol_decl(gfc_symbol*)
../.././gcc/fortran/trans-decl.c:1718
0x6c2178 gfc_create_module_variable
../.././gcc/fortran/trans-decl.c:5140
0x6c2178 gfc_create_module_variable
../.././gcc/fortran/trans-decl.c:5057
0x684912 do_traverse_symtree
../.././gcc/fortran/symbol.c:4166
0x6c2943 gfc_generate_module_vars(gfc_namespace*)
../.././gcc/fortran/trans-decl.c:5639
0x69f589 gfc_generate_module_code(gfc_namespace*)
../.././gcc/fortran/trans.c:2193
0x650285 translate_all_program_units
../.././gcc/fortran/parse.c:6121
0x650285 gfc_parse_file()
../.././gcc/fortran/parse.c:6337
0x6990ef gfc_be_parse_file
../.././gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The error persists when adding the POINTER attribute to p_t1 and when deferring
the type parameter (TYPE(t1(:))). Also for the invalid declaration with
deferred parameter, but without POINTER.

[Bug libstdc++/102221] Missed optimizations for algorithms over std::unique_ptr

[dangelog at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Giuseppe D'Angelo  ---
Hi,

Thanks for the analysis!

That basically allows me to reduce the testcase to something as simple as a
swap:


#include 
#include 

#if defined(SMART)
using ptr = std::unique_ptr;
#else
using ptr = int *;
#endif

auto swap1(ptr , ptr ) {
if ( == )
__builtin_unreachable(); // 

ptr tmp(std::move(a));
a = std::move(b);
b = std::move(tmp);
}

auto swap2(ptr , ptr )
{
// deliberate
std::swap(a, b);
}

https://gcc.godbolt.org/z/Tqzz5eqrW


In both cases there's basically a call to "delete nullptr" that doesn't get
removed. I don't think this falls on libstdc++, rather than on the optimizer?

[Bug fortran/102145] TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings

[ripero84 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from ripero84 at gmail dot com ---
1) The gfortran manual has its own entries for -pedantic and -pedantic-errors:

-Wpedantic
-pedantic
 Issue warnings for uses of extensions to Fortran.  -pedantic also
 applies to C-language constructs where they occur in GNU Fortran
 source files, such as use of \e in a character constant within a
 directive like "#include".

 Valid Fortran programs should compile properly with or without
 this option.  However, without this option, certain GNU extensions
 and traditional Fortran features are supported as well.  With this
 option, many of them are rejected.

 Some users try to use -pedantic to check programs for conformance.
 They soon find that it does not do quite what they want---it finds
 some nonstandard practices, but not all.  However, improvements to
 GNU Fortran in this area are welcome.

 This should be used in conjunction with -std=f95, -std=f2003,
 -std=f2008 or -std=f2018.

-pedantic-errors
 Like -pedantic, except that errors are produced rather than
 warnings.

The first lines of each description are quite clear about -pedantic issuing
warnings and -pedantic-errors issuing errors instead of warnings, in what
sounds like a very reasonable strategy.  But then the second paragraph of
-pedantic says that many (unspecified) non-standard features will be rejected.

2) This answers part of my issue: the behaviour is indeed documented, just in a
way that has proved confusing to me.  It think that a more accurate description
would start with: 

-pedantic: Issue warnings for some uses of extensions to Fortran, raise
otherwise warnings to errors for others.  Not all extensions will raise
warnings or errors.

which sounds bad.

3) If this is the intended behaviour I can propose some tweaks to the
documentation, but as I said first I would like to have a confirmation (ideally
by the person who set up the interaction between -pedantic and
-fallow-argument-mismatch) that this is really intended behaviour, not
accidental.

4) Apologies for not going into the C discussion, my C is limited, and to start
with I don't understand the "warnings demanded by strict ISO C" statement:
ISO/IEC 9899:2017, Annex I (informative) "Common warnings" says that "An
implementation may generate warnings in many situations, none of which are
specified as part of this International Standard", so I don't really know what
the "demanded warnings" are.

Thank you for your help.

[Bug tree-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22

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

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

--- Comment #3 from Martin Jambor  ---
(In reply to Richard Biener from comment #1)
> Martin, maybe you can try moving late sink to before the last phiopt pass.

If you mean the following then unfortunately that has not helped.

diff --git a/gcc/passes.def b/gcc/passes.def
index d7a1f8c97a6..5eb70cd2cd8 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -347,10 +347,10 @@ along with GCC; see the file COPYING3.  If not see
   /* After late CD DCE we rewrite no longer addressed locals into SSA
 form if possible.  */
   NEXT_PASS (pass_forwprop);
+  NEXT_PASS (pass_sink_code);
   NEXT_PASS (pass_phiopt, false /* early_p */);
   NEXT_PASS (pass_fold_builtins);
   NEXT_PASS (pass_optimize_widening_mul);
-  NEXT_PASS (pass_sink_code);
   NEXT_PASS (pass_store_merging);
   NEXT_PASS (pass_tail_calls);
   /* If DCE is not run before checking for uninitialized uses,


...I'll have a very brief look at what is actually happening just so that I
have more reasons to believe this is not a code placement issue again.

[Bug target/102107] protocol register (r12) corrupted before a tail call

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

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

--- Comment #17 from CVS Commits  ---
The master branch has been updated by Segher Boessenkool :

https://gcc.gnu.org/g:86e6268cff328e27ee6f90e2afc35b6f437a25cd

commit r12-3418-g86e6268cff328e27ee6f90e2afc35b6f437a25cd
Author: Segher Boessenkool 
Date:   Wed Sep 8 13:10:30 2021 +

rs6000: Fix ELFv2 r12 use in epilogue

We cannot use r12 here, it is already in use as the GEP (for sibling
calls).

2021-09-08  Segher Boessenkool  
PR target/102107
* config/rs6000/rs6000-logue.c (rs6000_emit_epilogue): For ELFv2
use
r11 instead of r12 for restoring CR.

[Bug fortran/102240] New: [F03] derived type parameter does not shadow variable name in enclosing scope

[roland_wirth at web dot de via Gcc-bugs]

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

Bug ID: 102240
   Summary: [F03] derived type parameter does not shadow variable
name in enclosing scope
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland_wirth at web dot de
  Target Milestone: ---

Consider the following module definition:

MODULE mo
IMPLICIT NONE

INTEGER :: n

TYPE t(n)
  INTEGER, LEN :: n
  INTEGER :: a(n)
END TYPE t
END MODULE

gfortran 9.1.0 produces the following error when trying to compile:

8 | INTEGER :: a(n)
  | 1
Error: Variable 'n' at (1) in this context must be constant

Upon renaming the INTEGER variable to some other name `nn` the unit compiles
fine.

The Fortran 2003 standard (N1601) says in the Host association section
[16.4.1.3] that "A name that appears in the scoping unit as [...] (3) A
type-param-name in a derived-type-stmt [...] is a local identifier in the
scoping unit and any entity of the host that has this as its nongeneric name is
inaccessible by that name by host association." If I read that correctly the
type parameter `n` shadows the variable `n`, and the module definition should
be valid Fortran.

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

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

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

Bug 102227 Summary: [12 Regression] Likely wrong code since 
r12-3369-g652bef70d392f9541b12ef65b461009c8c8fd54a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102227

   What|Removed |Added

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

[Bug target/102227] [12 Regression] Likely wrong code since r12-3369-g652bef70d392f9541b12ef65b461009c8c8fd54a

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed after g:7485a52551d71db2e8bbfc4c484196bcc321a1cd.

[Bug target/89984] Extra register move

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Should be fixed now.

[Bug target/89984] Extra register move

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

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

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

https://gcc.gnu.org/g:7485a52551d71db2e8bbfc4c484196bcc321a1cd

commit r12-3417-g7485a52551d71db2e8bbfc4c484196bcc321a1cd
Author: Jakub Jelinek 
Date:   Wed Sep 8 14:06:10 2021 +0200

i386: Fix up xorsign for AVX [PR89984]

Thinking about it more this morning, while this patch fixes the problems
revealed in the testcase, the recent PR89984 change was buggy too, but
perhaps that can be fixed incrementally.  Because for AVX the new code
destructively modifies op1.  If that is different from dest, say on:
float
foo (float x, float y)
{
  return x * __builtin_copysignf (1.0f, y) + y;
}
then we get after RA:
(insn 8 7 9 2 (set (reg:SF 20 xmm0 [orig:82 _2 ] [82])
(unspec:SF [
(reg:SF 20 xmm0 [88])
(reg:SF 21 xmm1 [89])
(mem/u/c:V4SF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 
S16 A128])
] UNSPEC_XORSIGN)) "hohoho.c":4:12 649 {xorsignsf3_1}
 (nil))
(insn 9 8 15 2 (set (reg:SF 20 xmm0 [87])
(plus:SF (reg:SF 20 xmm0 [orig:82 _2 ] [82])
(reg:SF 21 xmm1 [89]))) "hohoho.c":4:44 1021 {*fop_sf_comm}
 (nil))
but split the xorsign into:
vandps  .LC0(%rip), %xmm1, %xmm1
vxorps  %xmm0, %xmm1, %xmm0
and then the addition:
vaddss  %xmm1, %xmm0, %xmm0
which means we miscompile it - instead of adding y in the end we add
__builtin_copysignf (0.0f, y).
So, wonder if we don't want instead in addition to the  <- Yv, 0
alternative (enabled for both pre-AVX and AVX as in this patch) the
 <- Yv, Yv where destination must be different from inputs and another
Yv <- Yv, Yv where it can be the same but then need a match_scratch
(with X for the other alternatives and =Yv for the last one).
That way we'd always have a safe register we can store the op1 & mask
value into, either the destination (in the first alternative known to
be equal to op1 which is needed for non-AVX but ok for AVX too), in the
second alternative known to be different from both inputs and in the third
which could be used for those
float bar (float x, float y) { return x * __builtin_copysignf (1.0f, y); }
cases where op1 is naturally xmm1 and dest == op0 naturally xmm0 we'd use
some other register like xmm2.

On Wed, Sep 08, 2021 at 05:23:40PM +0800, Hongtao Liu wrote:
> I'm curious why we need the  post_reload splitter @xorsign3_1
> for scalar mode, can't we just expand them into and/xor operations in
> the expander, just like vector modes did.

Following seems to work for all the testcases I've tried (and in some
generates better code than the post-reload splitter).

2021-09-08  Jakub Jelinek  
liuhongt  

PR target/89984
* config/i386/i386.md (@xorsign3_1): Remove.
* config/i386/i386-expand.c (ix86_expand_xorsign): Expand right
away
into AND with mask and XOR, using paradoxical subregs.
(ix86_split_xorsign): Remove.
* config/i386/i386-protos.h (ix86_split_xorsign): Remove.

* gcc.target/i386/avx-pr102224.c: Fix up PR number.
* gcc.dg/pr89984.c: New test.
* gcc.target/i386/avx-pr89984.c: New test.

[Bug c/102239] New: powerpc suboptimal boolean test of contiguous bits

[npiggin at gmail dot com via Gcc-bugs]

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

Bug ID: 102239
   Summary: powerpc suboptimal boolean test of contiguous bits
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: npiggin at gmail dot com
  Target Milestone: ---
Target: powerpc64le-linux-gnu

gcc version 11.2.1 20210815 (Debian 11.2.0-2) 

Build flags -O2

--- test.c ---
void foo(long arg)
{
if (arg & ((1UL << 33) | (1UL << 34)))
asm volatile("# if");
else
asm volatile("# else");
}
---

generates:

foo:
rldicr 3,3,29,1
srdi. 3,3,29
beq 0,.L6
# if
blr
.L6:
# else
blr

This test of multiple contiguous bits could be tested with a single instruction
with rldicr. or rldicl.

Those instructions do tend to be more expensive than the Rc=0 form (C2 cracked
on POWER9, slower pipe class on POWER10), but I think they should be better
than the current 2-instruction sequence.

[Bug tree-optimization/65206] Vectorized version of loop is removed.

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #11 from Richard Biener  ---
*** Bug 101548 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/101548] dependence analysis fails with .MASK_STORE

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
quite exact duplicate

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

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 46391 Summary: false dependencies are computed after vectorization (#2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46391

   What|Removed |Added

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

[Bug rtl-optimization/46391] false dependencies are computed after vectorization (#2)

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||12.0, 7.5.0
 Resolution|--- |FIXED
  Known to fail||4.3.5

--- Comment #5 from Richard Biener  ---
It is.  Slightly altered testcase (to avoid unrolling on GIMPLE), with
-fno-schedule-insn2 on x86_64:

.L2:
movdqu  (%rdi,%rax), %xmm1
paddb   %xmm0, %xmm1
movups  %xmm1, (%rsi,%rax)
movdqu  16(%rdi,%rax), %xmm2
paddb   %xmm0, %xmm2
movups  %xmm2, 16(%rsi,%rax)
movdqu  32(%rdi,%rax), %xmm3
paddb   %xmm0, %xmm3
movups  %xmm3, 32(%rsi,%rax)
movdqu  48(%rdi,%rax), %xmm4
paddb   %xmm0, %xmm4
movups  %xmm4, 48(%rsi,%rax)
movdqu  64(%rdi,%rax), %xmm5
paddb   %xmm0, %xmm5
movups  %xmm5, 64(%rsi,%rax)
movdqu  80(%rdi,%rax), %xmm6
paddb   %xmm0, %xmm6
movups  %xmm6, 80(%rsi,%rax)
movdqu  96(%rdi,%rax), %xmm7
paddb   %xmm0, %xmm7
movups  %xmm7, 96(%rsi,%rax)
movdqu  112(%rdi,%rax), %xmm8
paddb   %xmm0, %xmm8
movups  %xmm8, 112(%rsi,%rax)
subq$-128, %rax
cmpq$4096, %rax
jne .L2

and without:

.L2:
movdqu  (%rdi,%rax), %xmm1
movdqu  16(%rdi,%rax), %xmm2
movdqu  32(%rdi,%rax), %xmm3
movdqu  48(%rdi,%rax), %xmm4
movdqu  64(%rdi,%rax), %xmm5
paddb   %xmm0, %xmm1
paddb   %xmm0, %xmm2
movdqu  80(%rdi,%rax), %xmm6
movdqu  96(%rdi,%rax), %xmm7
paddb   %xmm0, %xmm3
paddb   %xmm0, %xmm4
movups  %xmm1, (%rsi,%rax)
movdqu  112(%rdi,%rax), %xmm8
paddb   %xmm0, %xmm5
paddb   %xmm0, %xmm6
movups  %xmm2, 16(%rsi,%rax)
paddb   %xmm0, %xmm7
movups  %xmm3, 32(%rsi,%rax)
paddb   %xmm0, %xmm8
movups  %xmm4, 48(%rsi,%rax)
movups  %xmm5, 64(%rsi,%rax)
movups  %xmm6, 80(%rsi,%rax)
movups  %xmm7, 96(%rsi,%rax)
movups  %xmm8, 112(%rsi,%rax)
subq$-128, %rax
cmpq$4096, %rax
jne .L2

and that's only possible if this dependence is not visible.  4.3 shows the
problem still, GCC 7 doesn't.

[Bug tree-optimization/96135] [9/10/11/12 regression] bswap not detected by bswap pass, unexpected results between optimization levels

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> Note on the trunk for f and g at -O3 -msse4 (and -O3 on aarch64), GCC
> produces:
>   _21 = VIEW_CONVERT_EXPR(i_2(D));
>   _22 = VEC_PERM_EXPR <_21, _21, { 7, 6, 5, 4, 3, 2, 1, 0 }>;
>   _18 = VIEW_CONVERT_EXPR(_22);
> 
> But that VEC_PERM_EXPR is a bswap :).
> 
> So to fix this at -O3 -msse4, maybe we could just do:
> (simplify
>  (view_convert (vec_perm @0 @0 vector_cst_byteswap_p @1))
>  (if (INTERGAL_TYPE_P (type)))
>   (convert (bswap (view_convert @1
> 
> Note I don't think we want to do the byteswap in the integer registers if we
> are going back to the floating point registers.

Or we could just support that in vect-lowering.

[Bug tree-optimization/96135] [9/10/11/12 regression] bswap not detected by bswap pass, unexpected results between optimization levels

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

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

--- Comment #5 from Andrew Pinski  ---
Note on the trunk for f and g at -O3 -msse4 (and -O3 on aarch64), GCC produces:
  _21 = VIEW_CONVERT_EXPR(i_2(D));
  _22 = VEC_PERM_EXPR <_21, _21, { 7, 6, 5, 4, 3, 2, 1, 0 }>;
  _18 = VIEW_CONVERT_EXPR(_22);

But that VEC_PERM_EXPR is a bswap :).

So to fix this at -O3 -msse4, maybe we could just do:
(simplify
 (view_convert (vec_perm @0 @0 vector_cst_byteswap_p @1))
 (if (INTERGAL_TYPE_P (type)))
  (convert (bswap (view_convert @1

Note I don't think we want to do the byteswap in the integer registers if we
are going back to the floating point registers.

[Bug libstdc++/101263] non-propagating-cache::emplace-deref missing constexpr

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Patrick Palka from comment #1)
> We might first need to implement P2231 (for constexpr optional) before this
> function can be properly constexpr.

I have a patch for that, but it's not upstream yet.

[Bug c++/102223] no warning when calling member function on dangling reference

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Federico Kircheis from comment #0)
> Normally life-extension would kick in, but because we added an unnecessary
> static_cast, it does not kick in and v is a dangling reference.

I assume you already know this, but the original testcase in comment 0 is
perfectly valid. The static_cast creates a new temporary, which *does* get its
lifetime extended.

[Bug c++/102223] no warning when calling member function on dangling reference

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

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

--- Comment #4 from Jonathan Wakely  ---
N.B AddressSanitizer will diagnose this at runtime.

[Bug target/102227] [12 Regression] Likely wrong code since r12-3369-g652bef70d392f9541b12ef65b461009c8c8fd54a

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

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

Martin Liška  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89984

--- Comment #5 from Martin Liška  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Martin Liška from comment #3)
> > After r12-3413-ga7b626d98a9a821ffb33466818d6aa86cac1d6fd, I still see the
> > miscompilation in the mentioned file.
> > 
> > @Jakub: Can one somehow bisect which XORSIGN pattern causes that?
> 
> See PR 89984.

Thanks!

[Bug c++/102223] no warning when calling member function on dangling reference

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=96780

--- Comment #3 from Jonathan Wakely  ---
Your compiler explorer link doesn't enable optimizations. There's no way G++
can warn without optimization (specifically, without inlining). The std::move
call is an opaque function that returns a reference, which might have nothing
whatsoever to do with the function argument, so the reference it returns could
be valid.

With inlining, in theory it would be possible to diagnose the invalid access,
but other compilers don't do it either. It would be nice, but I'm not sure it's
likely to happen any time soon. GCC doesn't even get it right in constexpr
contexts, see PR 70331 and the linked bugs in the See Also field.

PR 96780 comment 2 could potentially help for the specific case of std::move,
but not the general case.

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

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

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

--- Comment #7 from Jonathan Wakely  ---
Because a user-provided inner() means it's default constructible, period. If
that default constructor happens to be ill-formed, that's your problem and is
outside the immediate context that is checked by is_default_constructible.

Without that user-provided constructor, the compiler has to try to implicitly
define a default constructor, which has to consider all the members and their
default member initializers, which requires the type to be complete.

[Bug target/91103] AVX512 vector element extract uses more than 1 shuffle instruction; VALIGND can grab any element

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---
For elements located above 128bits, it seems always better(?) to use
valign{d,q}

diff --git a/origin.s b/after.s
index 9a7dfee..9a23f7e 100644
--- a/origin.s
+++ b/after.s
@@ -6,7 +6,7 @@
 foo_v8sf_4:
 .LFB0:
.cfi_startproc
-   vextractf128$0x1, %ymm0, %xmm0
+   valignd $4, %ymm0, %ymm0, %ymm0
ret
.cfi_endproc
 .LFE0:
@@ -17,8 +17,7 @@ foo_v8sf_4:
 foo_v8sf_7:
 .LFB1:
.cfi_startproc
-   vextractf128$0x1, %ymm0, %xmm0
-   vshufps $255, %xmm0, %xmm0, %xmm0
+   valignd $7, %ymm0, %ymm0, %ymm0
ret
.cfi_endproc
 .LFE1:
@@ -29,8 +28,8 @@ foo_v8sf_7:
 foo_v8si_4:
 .LFB2:
.cfi_startproc
-   vextracti128$0x1, %ymm0, %xmm0
-   vmovd   %xmm0, %eax
+   valignd $4, %ymm0, %ymm0, %ymm1
+   vmovd   %xmm1, %eax
ret
.cfi_endproc
 .LFE2:
@@ -41,8 +40,8 @@ foo_v8si_4:
 foo_v8si_7:
 .LFB3:
.cfi_startproc
-   vextracti128$0x1, %ymm0, %xmm0
-   vpextrd $3, %xmm0, %eax
+   valignd $7, %ymm0, %ymm0, %ymm1
+   vmovd   %xmm1, %eax
ret
.cfi_endproc
 .LFE3:
@@ -53,7 +52,7 @@ foo_v8si_7:
 foo_v16sf_8:
 .LFB4:
.cfi_startproc
-   vextractf32x8   $0x1, %zmm0, %ymm0
+   valignd $8, %zmm0, %zmm0, %zmm0
ret
.cfi_endproc
 .LFE4:
@@ -64,9 +63,7 @@ foo_v16sf_8:
 foo_v16sf_15:
 .LFB5:
.cfi_startproc
-   vextractf32x8   $0x1, %zmm0, %ymm0
-   vextractf128$0x1, %ymm0, %xmm0
-   vshufps $255, %xmm0, %xmm0, %xmm0
+   valignd $15, %zmm0, %zmm0, %zmm0
ret
.cfi_endproc
 .LFE5:
@@ -77,8 +74,8 @@ foo_v16sf_15:
 foo_v16si_8:
 .LFB6:
.cfi_startproc
-   vextracti32x8   $0x1, %zmm0, %ymm0
-   vmovd   %xmm0, %eax
+   valignd $8, %zmm0, %zmm0, %zmm1
+   vmovd   %xmm1, %eax
ret
.cfi_endproc
 .LFE6:
@@ -89,9 +86,8 @@ foo_v16si_8:
 foo_v16si_15:
 .LFB7:
.cfi_startproc
-   vextracti32x8   $0x1, %zmm0, %ymm0
-   vextracti128$0x1, %ymm0, %xmm0
-   vpextrd $3, %xmm0, %eax
+   valignd $15, %zmm0, %zmm0, %zmm1
+   vmovd   %xmm1, %eax
ret
.cfi_endproc
 .LFE7:
@@ -102,7 +98,7 @@ foo_v16si_15:
 foo_v4df_2:
 .LFB8:
.cfi_startproc
-   vextractf64x2   $0x1, %ymm0, %xmm0
+   valignq $2, %ymm0, %ymm0, %ymm0
ret
.cfi_endproc
 .LFE8:
@@ -113,8 +109,7 @@ foo_v4df_2:
 foo_v4df_3:
 .LFB9:
.cfi_startproc
-   vextractf64x2   $0x1, %ymm0, %xmm0
-   vunpckhpd   %xmm0, %xmm0, %xmm0
+   valignq $3, %ymm0, %ymm0, %ymm0
ret
.cfi_endproc
 .LFE9:
@@ -125,8 +120,8 @@ foo_v4df_3:
 foo_v4di_2:
 .LFB10:
.cfi_startproc
-   vextracti64x2   $0x1, %ymm0, %xmm0
-   vmovq   %xmm0, %rax
+   valignq $2, %ymm0, %ymm0, %ymm1
+   vmovq   %xmm1, %rax
ret
.cfi_endproc
 .LFE10:
@@ -137,8 +132,8 @@ foo_v4di_2:
 foo_v4di_3:
 .LFB11:
.cfi_startproc
-   vextracti64x2   $0x1, %ymm0, %xmm0
-   vpextrq $1, %xmm0, %rax
+   valignq $3, %ymm0, %ymm0, %ymm1
+   vmovq   %xmm1, %rax
ret
.cfi_endproc
 .LFE11:
@@ -149,7 +144,7 @@ foo_v4di_3:
 foo_v8df_4:
 .LFB12:
.cfi_startproc
-   vextractf64x4   $0x1, %zmm0, %ymm0
+   valignq $4, %zmm0, %zmm0, %zmm0
ret
.cfi_endproc
 .LFE12:
@@ -160,9 +155,7 @@ foo_v8df_4:
 foo_v8df_7:
 .LFB13:
.cfi_startproc
-   vextractf64x4   $0x1, %zmm0, %ymm0
-   vextractf64x2   $0x1, %ymm0, %xmm0
-   vunpckhpd   %xmm0, %xmm0, %xmm0
+   valignq $7, %zmm0, %zmm0, %zmm0
ret
.cfi_endproc
 .LFE13:
@@ -173,8 +166,8 @@ foo_v8df_7:
 foo_v8di_4:
 .LFB14:
.cfi_startproc
-   vextracti64x4   $0x1, %zmm0, %ymm0
-   vmovq   %xmm0, %rax
+   valignq $4, %zmm0, %zmm0, %zmm1
+   vmovq   %xmm1, %rax
ret
.cfi_endproc
 .LFE14:
@@ -185,12 +178,11 @@ foo_v8di_4:
 foo_v8di_7:
 .LFB15:
.cfi_startproc
-   vextracti64x4   $0x1, %zmm0, %ymm0
-   vextracti64x2   $0x1, %ymm0, %xmm0
-   vpextrq $1, %xmm0, %rax
+   valignq $7, %zmm0, %zmm0, %zmm1
+   vmovq   %xmm1, %rax
ret
.cfi_endproc
 .LFE15:
.size   foo_v8di_7, .-foo_v8di_7
-   .ident  "GCC: (GNU) 12.0.0 20210907 (experimental)"
+   .ident  "GCC: (GNU) 12.0.0 20210908 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug target/102227] [12 Regression] Likely wrong code since r12-3369-g652bef70d392f9541b12ef65b461009c8c8fd54a

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Martin Liška from comment #3)
> After r12-3413-ga7b626d98a9a821ffb33466818d6aa86cac1d6fd, I still see the
> miscompilation in the mentioned file.
> 
> @Jakub: Can one somehow bisect which XORSIGN pattern causes that?

See PR 89984.

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

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

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

Bug 102227 Summary: [12 Regression] Likely wrong code since 
r12-3369-g652bef70d392f9541b12ef65b461009c8c8fd54a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102227

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |---

[Bug target/102227] [12 Regression] Likely wrong code since r12-3369-g652bef70d392f9541b12ef65b461009c8c8fd54a

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
 Resolution|DUPLICATE   |---
   Last reconfirmed||2021-09-08
 Status|RESOLVED|REOPENED

--- Comment #3 from Martin Liška  ---
After r12-3413-ga7b626d98a9a821ffb33466818d6aa86cac1d6fd, I still see the
miscompilation in the mentioned file.

@Jakub: Can one somehow bisect which XORSIGN pattern causes that?

[Bug target/102224] [9/10/11 regession] wrong code for `x * copysign(1.0, x)` since r9-5298-g33142cf9cf82aa1f

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11/12 regession]  |[9/10/11 regession] wrong
   |wrong code for `x * |code for `x * copysign(1.0,
   |copysign(1.0, x)` since |x)` since
   |r9-5298-g33142cf9cf82aa1f   |r9-5298-g33142cf9cf82aa1f

--- Comment #14 from Jakub Jelinek  ---
Fixed on the trunk.  The 11 etc. backports will be somewhat different, because
the PR89984 change aren't and won't be on those branches.

[Bug libstdc++/102221] Missed optimizations for algorithms over std::unique_ptr

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-09-08
 Ever confirmed|0   |1
   Keywords||missed-optimization

--- Comment #1 from Jonathan Wakely  ---
This comes from the construction of a local unique_ptr variable in:

  template
_GLIBCXX20_CONSTEXPR
void
__unguarded_linear_insert(_RandomAccessIterator __last,
  _Compare __comp)
{
  typename iterator_traits<_RandomAccessIterator>::value_type
__val = _GLIBCXX_MOVE(*__last);
  _RandomAccessIterator __next = __last;
  --__next;
  while (__comp(__val, __next))
{
  *__last = _GLIBCXX_MOVE(*__next);
  __last = __next;
  --__next;
}
  *__last = _GLIBCXX_MOVE(__val);
}

The compiler apparently doesn't see that after std::move(__val) on the last
line there is no need to invoke the deleter, because it's empty.

The use of std::tuple> for std::unique_ptr might make
it too hard for the compiler to track the value of the stored pointer.

I'm not sure there's anything the library can do here (except maybe replace
std::tuple with [[no_unique_address]], once all the compilers we care about
support that properly).

[Bug target/102224] [9/10/11/12 regession] wrong code for `x * copysign(1.0, x)` since r9-5298-g33142cf9cf82aa1f

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

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

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

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

commit r12-3413-ga7b626d98a9a821ffb33466818d6aa86cac1d6fd
Author: Jakub Jelinek 
Date:   Wed Sep 8 11:25:31 2021 +0200

i386: Fix up @xorsign3_1 [PR102224]

As the testcase shows, we miscompile @xorsign3_1 if both input
operands are in the same register, because the splitter overwrites op1
before with op1 & mask before using op0.

For dest = xorsign op0, op0 we can actually simplify it from
dest = (op0 & mask) ^ op0 to dest = op0 & ~mask (aka abs).

The expander change is an optimization improvement, if we at expansion
time know it is xorsign op0, op0, we can emit abs right away and get better
code through that.

The @xorsign3_1 is a fix for the case where xorsign wouldn't be known
to have same operands during expansion, but during RTL optimizations they
would appear.  For non-AVX we need to use earlyclobber, we require
dest and op1 to be the same but op0 must be different because we overwrite
op1 first.  For AVX the constraints ensure that at most 2 of the 3 operands
may be the same register and if both inputs are the same, handles that
case.
This case can be easily tested with the xorsign3 expander change
reverted.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Thinking about it more this morning, while this patch fixes the problems
revealed in the testcase, the recent PR89984 change was buggy too, but
perhaps that can be fixed incrementally.  Because for AVX the new code
destructively modifies op1.  If that is different from dest, say on:
float
foo (float x, float y)
{
  return x * __builtin_copysignf (1.0f, y) + y;
}
then we get after RA:
(insn 8 7 9 2 (set (reg:SF 20 xmm0 [orig:82 _2 ] [82])
(unspec:SF [
(reg:SF 20 xmm0 [88])
(reg:SF 21 xmm1 [89])
(mem/u/c:V4SF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 
S16 A128])
] UNSPEC_XORSIGN)) "hohoho.c":4:12 649 {xorsignsf3_1}
 (nil))
(insn 9 8 15 2 (set (reg:SF 20 xmm0 [87])
(plus:SF (reg:SF 20 xmm0 [orig:82 _2 ] [82])
(reg:SF 21 xmm1 [89]))) "hohoho.c":4:44 1021 {*fop_sf_comm}
 (nil))
but split the xorsign into:
vandps  .LC0(%rip), %xmm1, %xmm1
vxorps  %xmm0, %xmm1, %xmm0
and then the addition:
vaddss  %xmm1, %xmm0, %xmm0
which means we miscompile it - instead of adding y in the end we add
__builtin_copysignf (0.0f, y).
So, wonder if we don't want instead in addition to the  <- Yv, 0
alternative (enabled for both pre-AVX and AVX as in this patch) the
 <- Yv, Yv where destination must be different from inputs and another
Yv <- Yv, Yv where it can be the same but then need a match_scratch
(with X for the other alternatives and =Yv for the last one).
That way we'd always have a safe register we can store the op1 & mask
value into, either the destination (in the first alternative known to
be equal to op1 which is needed for non-AVX but ok for AVX too), in the
second alternative known to be different from both inputs and in the third
which could be used for those
float bar (float x, float y) { return x * __builtin_copysignf (1.0f, y); }
cases where op1 is naturally xmm1 and dest == op0 naturally xmm0 we'd use
some other register like xmm2.

2021-09-08  Jakub Jelinek  

PR target/102224
* config/i386/i386.md (xorsign3): If operands[1] is equal to
operands[2], emit abs2 instead.
(@xorsign3_1): Add early-clobbers for output operand, enable
first alternative even for avx, add another alternative with
= <- 0, Yv, Yvm constraints.
* config/i386/i386-expand.c (ix86_split_xorsign): If op0 is equal
to op1, emit vpandn instead.

* gcc.dg/pr102224.c: New test.
* gcc.target/i386/avx-pr102224.c: New test.

[Bug c++/102228] lookup_anon_field is quadratic

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

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

--- Comment #6 from Richard Biener  ---
I do have a functional patch which improves the -fsyntax-only compile-time for
the PR101555 testcase from 14s to 2s.

After lookup_anon_field is gone PR83309 pops up of course:

Samples: 6K of event 'cycles', Event count (approx.): 6523483993
Overhead   Samples  Command  Shared Object Symbol   
  20.96%  1375  cc1plus  cc1plus   [.] get_class_binding_direct
  11.83%   776  cc1plus  cc1plus   [.] fields_linear_search
   7.63%   501  cc1plus  cc1plus   [.] cp_fold

I wonder if we should delay duplicate decl diagnostics until after the class
is completed so we have the CLASSTYPE_MEMBER_VEC populated.