[Bug sanitizer/103978] AddressSanitizer CHECK failed with threads and thread canceling with glibc 2.28+

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Martin Liška from comment #1) 
> Note clang is fine.

clang might be fine because it uses a static libasan.

[Bug sanitizer/103978] AddressSanitizer CHECK failed with threads and thread canceling with glibc 2.28+

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

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

--- Comment #6 from Andrew Pinski  ---
Could there be some ordering issues with pthread_key going on?
2.28 added C11 thread.h support which did touch pthread_key too.

[Bug sanitizer/103978] AddressSanitizer CHECK failed with threads and thread canceling with glibc 2.28+

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

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

--- Comment #5 from Andrew Pinski  ---
This is what the trunk gives with full debug info:
=
==1230123==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x7f69725fedf0 at pc 0x7f69754d0581 bp 0x7f69725fedb0 sp 0x7f69725fe560
WRITE of size 24 at 0x7f69725fedf0 thread T-1
#0 0x7f69754d0580 in __interceptor_sigaltstack
/home/apinski/src/upstream-gcc-git/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:10168
#1 0x7f6975546e3d in __sanitizer::UnsetAlternateSignalStack()
/home/apinski/src/upstream-gcc-git/gcc/libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:189
#2 0x7f6975536ae4 in __asan::AsanThread::Destroy()
/home/apinski/src/upstream-gcc-git/gcc/libsanitizer/asan/asan_thread.cpp:110
#3 0x7f69752543d0 in __nptl_deallocate_tsd.part.8
(/lib64/libpthread.so.0+0x73d0)
#4 0x7f697525516a in start_thread (/lib64/libpthread.so.0+0x816a)
#5 0x7f6974f86f22 in clone (/lib64/libc.so.6+0xfcf22)

Address 0x7f69725fedf0 is a wild pointer inside of access range of size
0x0018.
SUMMARY: AddressSanitizer: stack-buffer-underflow
/home/apinski/src/upstream-gcc-git/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:10168
in __interceptor_sigaltstack
Shadow bytes around the buggy address:
  0x0fedae4b7d60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fedae4b7d70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fedae4b7d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fedae4b7d90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fedae4b7da0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fedae4b7db0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[f1]f1
  0x0fedae4b7dc0: f1 f1 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00
  0x0fedae4b7dd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fedae4b7de0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fedae4b7df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fedae4b7e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==1230123==ABORTING

[Bug c++/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jason at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Jason pushed a whole set of changes in this area lately, we'd better understand
what's going on here.

[Bug sanitizer/103978] AddressSanitizer CHECK failed with threads and thread canceling with glibc 2.28+

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|11.3|---
  Known to fail|11.1.0, 11.2.0, 12.0|
Summary|[11/12 Regression]  |AddressSanitizer CHECK
   |AddressSanitizer CHECK  |failed with threads and
   |failed  |thread canceling with glibc
   |../../../../src/libsanitize |2.28+
   |r/asan/asan_thread.cpp:367  |
   |"((ptr[0] ==|
   |kCurrentStackFrameMagic))   |
   |!= (0)" (0x0, 0x0)  |
  Known to work|10.1.0, 10.3.0, 7.1.0,  |
   |8.1.0, 9.1.0|

--- Comment #4 from Andrew Pinski  ---
Maybe there is a glibc change here which is causing it.
glibc 2.27 works while 2.28 fails.

I don't know why clang works though.

[Bug sanitizer/103978] [11/12 Regression] AddressSanitizer CHECK failed ../../../../src/libsanitizer/asan/asan_thread.cpp:367 "((ptr[0] == kCurrentStackFrameMagic)) != (0)" (0x0, 0x0)

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

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

--- Comment #3 from Andrew Pinski  ---
Note trunk gives:

=
==1==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7f2aac7fedf0
at pc 0x7f2aae9b28e1 bp 0x7f2aac7fedb0 sp 0x7f2aac7fe560
WRITE of size 24 at 0x7f2aac7fedf0 thread T-1
#0 0x7f2aae9b28e0 
(/opt/compiler-explorer/gcc-snapshot/lib64/libasan.so.8+0x628e0)
#1 0x7f2aaea2916d 
(/opt/compiler-explorer/gcc-snapshot/lib64/libasan.so.8+0xd916d)
#2 0x7f2aaea18e64 
(/opt/compiler-explorer/gcc-snapshot/lib64/libasan.so.8+0xc8e64)
#3 0x7f2aae5a95a0 in __nptl_deallocate_tsd.part.0
(/lib/x86_64-linux-gnu/libpthread.so.0+0x85a0)
#4 0x7f2aae5aa629 in start_thread
(/lib/x86_64-linux-gnu/libpthread.so.0+0x9629)
#5 0x7f2aae4cf292 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x122292)

Address 0x7f2aac7fedf0 is a wild pointer inside of access range of size
0x0018.
SUMMARY: AddressSanitizer: stack-buffer-underflow
(/opt/compiler-explorer/gcc-snapshot/lib64/libasan.so.8+0x628e0) 
Shadow bytes around the buggy address:
  0x0fe5d58f7d60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe5d58f7d70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe5d58f7d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe5d58f7d90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe5d58f7da0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fe5d58f7db0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[f1]f1
  0x0fe5d58f7dc0: f1 f1 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00
  0x0fe5d58f7dd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe5d58f7de0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe5d58f7df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe5d58f7e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==1==ABORTING

[Bug sanitizer/103978] [11/12 Regression] AddressSanitizer CHECK failed ../../../../src/libsanitizer/asan/asan_thread.cpp:367 "((ptr[0] == kCurrentStackFrameMagic)) != (0)" (0x0, 0x0)

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||10.1.0, 10.3.0, 7.1.0,
   ||8.1.0, 9.1.0
   Target Milestone|--- |11.3
  Known to fail||11.1.0, 11.2.0, 12.0
Summary|AddressSanitizer CHECK  |[11/12 Regression]
   |failed  |AddressSanitizer CHECK
   |../../../../src/libsanitize |failed
   |r/asan/asan_thread.cpp:367  |../../../../src/libsanitize
   |"((ptr[0] ==|r/asan/asan_thread.cpp:367
   |kCurrentStackFrameMagic))   |"((ptr[0] ==
   |!= (0)" (0x0, 0x0)  |kCurrentStackFrameMagic))
   ||!= (0)" (0x0, 0x0)

--- Comment #2 from Andrew Pinski  ---
Works for me with GCC 7.1.0.
I didn't see any code different between GCC 10.3.0 and 11.1.0 even. So this has
to be a library issue.

[PATCH] Place jump tables in RELRO only when targets require local relocation to be placed in a read-write section

[HAO CHEN GUI via Gcc-patches]

Hi,
   This patch sets "relocatable" of jump table to true when targets require 
local relocation to be placed
in a read-write section - bit 0 is set in reloc_rw_mask. Jump tables are in 
local relocation, so they
should be placed in RELRO only when both global and local relocation need to be 
placed in a read-write
section. Bit 1 is always set when bit 0 is set.
   Bootstrapped and tested on powerpc64-linux BE/LE and x86 with no 
regressions. Is this okay for trunk?
Any recommendations? Thanks a lot.

ChangeLog
2022-01-12 Haochen Gui 

gcc/
* final.c (jumptable_relocatable): Set relocatable to true when
targets require local relocation to be placed in a read-write section.


patch.diff
diff --git a/gcc/final.c b/gcc/final.c
index 296a9382e91..e86223cb96b 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -2141,7 +2141,7 @@ jumptable_relocatable (void)
   if (!CASE_VECTOR_PC_RELATIVE
   && !targetm.asm_out.generate_pic_addr_diff_vec ()
   && targetm_common.have_named_sections)
- relocatable = targetm.asm_out.reloc_rw_mask ();
+ relocatable = targetm.asm_out.reloc_rw_mask () == 3;

   return relocatable;
 }

[Bug middle-end/76174] Missed VRP optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug middle-end/76174] Missed VRP optimization

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

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

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

https://gcc.gnu.org/g:45ddb395187f8f5f278880fe1422d8958ac35da6

commit r12-6513-g45ddb395187f8f5f278880fe1422d8958ac35da6
Author: Richard Biener 
Date:   Wed Jan 12 08:10:19 2022 +0100

tree-optimization/76174 - testcase for fixed PR

This adds a testcase for the fixed PR, VN now gets us the transform
via IV equality plus predication.

2022-01-12  Richard Biener  

PR tree-optimization/76174
* gcc.dg/tree-ssa/pr76174.c: New testcase.

[PATCH] tree-optimization/76174 - testcase for fixed PR

[Richard Biener via Gcc-patches]

This adds a testcase for the fixed PR, VN now gets us the transform
via IV equality plus predication.

Pushed.

2022-01-12  Richard Biener  

PR tree-optimization/76174
* gcc.dg/tree-ssa/pr76174.c: New testcase.
---
 gcc/testsuite/gcc.dg/tree-ssa/pr76174.c | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr76174.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr76174.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr76174.c
new file mode 100644
index 000..17a4a0faf24
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr76174.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-cddce1" } */
+
+void foo();
+
+void l(unsigned int r) {
+   unsigned int q = 0;
+unsigned int c = r;
+for (unsigned int x = 0; x

[Bug tree-optimization/103986] [9/10 Regression] Miscompilation with -O2 -funswitch-loops and __builtin_unreachable

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||10.1.0, 10.2.0, 10.3.0,
   ||9.1.0, 9.4.0
  Known to work||8.5.0

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> Those come from dom3.
> 
> Here is a testcase which runs in finite time to test this (plus it is not a
> C testcase also):

This only fails at -O2 -funswitch-loops and not -O3 and only fails with GCC
10.x while the original one fails even with 9.x.

Re: libgfortran bootstrap failure

[Jakub Jelinek via Gcc-patches]

On Tue, Jan 11, 2022 at 10:30:26PM -0500, David Edelsohn wrote:
> The recent patch to support Power IEEE128 causes a bootstrap failure
> on AIX and possibly all non-GLIBC systems.
> 
> +#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
> +&& defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
> +#define POWER_IEEE128 1
> +#endif
> 
> __GLIBC_PREREQ is tested on all systems.
> 
> /nasfarm/edelsohn/src/src/libgfortran/libgfortran.h:107:49: error:
> missing binary operator before token "("
>   107 | && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
>   | ^

Guess we need:
#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
&& defined __GLIBC_PREREQ
# if __GLIBC_PREREQ (2, 32)
#  define POWER_IEEE128 1
# endif
#endif
instead.

Jakub

[Bug tree-optimization/103986] [9/10 Regression] Miscompilation with -O2 -funswitch-loops and __builtin_unreachable

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-01-12
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #7 from Andrew Pinski  ---
Those come from dom3.

Here is a testcase which runs in finite time to test this (plus it is not a C
testcase also):
#define assume(Expression) do { if((Expression)) (void)0; else
__builtin_unreachable(); } while(0)
struct GridZYXIterator {
short x;
short y;
short z;
};
static inline
void f(struct GridZYXIterator *t) {
t->x++;
if(t->x == 3) {
t->x = 0;
t->y++;
if(t->y == 3) {
t->y = 0;
t->z++;
}
}
}
static int t = 0;
static void g() __attribute__((noipa));
static void g(){t++; if (t > 27) __builtin_abort();};
int main()
{
struct GridZYXIterator it = {0,0,0};
while(it.z != 3) {
assume(it.y < 3 && it.z < 3);
g();
f();
}   
}

Confirmed.

[Bug tree-optimization/103986] [9/10 Regression] Miscompilation with -O2 -funswitch-loops and __builtin_unreachable

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

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

--- Comment #6 from Andrew Pinski  ---
Actually there are some ranges on some SSA Names before hand which look like
that matter:
  # RANGE [1, 1]

[Bug tree-optimization/103986] [9/10 Regression] Miscompilation with -O2 -funswitch-loops and __builtin_unreachable

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

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

--- Comment #5 from Andrew Pinski  ---
The difference between GCC 11 and GCC 10.3 where the code generation difference
really comes into play is vrp2.

[Bug tree-optimization/103986] [9/10 Regression] Miscompilation with -O2 -funswitch-loops and __builtin_unreachable

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

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

--- Comment #4 from Andrew Pinski  ---
Unsiwtch loops looks the same in GCC 10.3.0 and 11.1.0 so ...

[Bug target/98348] [10 Regression] GCC 10.2 AVX512 Mask regression from GCC 9

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #27 from Andrew Pinski  ---
.

[Bug target/98348] [10 Regression] GCC 10.2 AVX512 Mask regression from GCC 9

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|10.4|11.3

--- Comment #26 from Andrew Pinski  ---
Fixed.

[Bug rtl-optimization/94790] Failure to use andn in specific pattern in which it is available

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #5 from Hongtao.liu  ---
the extra move instrcution can be handle by RAT, but from the perspective of
the pipeline, `andn + and + ior` version take 2 cycles(and and andn doesn't
have dependence), but xor + and + xor will take 3 cycles.

[Bug target/98348] [10 Regression] GCC 10.2 AVX512 Mask regression from GCC 9

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #25 from Hongtao.liu  ---
backport to GCC11, no suitable for GCC10, so fixed in GCC11/12.

[Bug target/98348] [10 Regression] GCC 10.2 AVX512 Mask regression from GCC 9

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

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

--- Comment #24 from CVS Commits  ---
The releases/gcc-11 branch has been updated by hongtao Liu
:

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

commit r11-9455-gd5e7b9fd184c22464d8724ff748e1f7ce0cd6bce
Author: liuhongt 
Date:   Mon Aug 30 15:05:14 2021 +0800

Unify UNSPEC_MASKED_EQ/GT to the form of UNSPEC_PCMP.

Currently for evex vpcmpeqb instruction, we have two forms of rtl
template representation, one is (unspec [op1 op2] UNSPEC_MASK_EQ), the
other is (unspec [op1, op2, const_int 0] UNSPEC_PCMP), which increases
the maintenance burden, such as optimization (not: vpcmpeqb)
to (vpcmpneqb) requires two define_insn_and_split to match the two
forms respectively, this patch removes UNSPEC_MASK_EQ/GT, unifying
them into the form of UNSPEC_PCMP.

gcc/ChangeLog:

PR target/98348
* config/i386/sse.md (*_ucmp3_1): Change from
define_split to define_insn_and_split.
(*avx2_eq3): Removed.
(_eq3): Adjust pattern
(_eq3_1): Rename to ..
(*_eq3_1): .. this, and
adjust pattern.
(*avx2_gt3): Removed.
(_gt3): Change from
define_insn to define_expand, and adjust pattern.
(UNSPEC_MASKED_EQ, UNSPEC_MASKED_GT): Removed.

gcc/testsuite/ChangeLog:

PR target/98348
* gcc.target/i386/avx512bw-vpcmpeqb-1.c: Adjust testcase.
* gcc.target/i386/avx512bw-vpcmpeqw-1.c: Ditto.
* gcc.target/i386/avx512bw-vpcmpgtb-1.c: Ditto.
* gcc.target/i386/avx512bw-vpcmpgtw-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpeqd-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpeqq-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpgtd-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpgtq-1.c: Ditto.
* gcc.target/i386/avx512vl-vpcmpeqd-1.c: Ditto.
* gcc.target/i386/avx512vl-vpcmpeqq-1.c: Ditto.
* gcc.target/i386/avx512vl-vpcmpgtd-1.c: Ditto.
* gcc.target/i386/avx512vl-vpcmpgtq-1.c: Ditto.
* gcc.target/i386/bitwise_mask_op-1.c: Ditto.
* gcc.target/i386/bitwise_mask_op-2.c: Ditto.

[Bug target/103804] ICE: 'global_options' are modified in local context

[asolokha at gmx dot com via Gcc-bugs]

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

Arseny Solokha  changed:

   What|Removed |Added

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

--- Comment #4 from Arseny Solokha  ---
Nope, it still ICEs w/ gcc 20220109 snapshot
(g:49d73c9fb644673323845efebfe6b3106e70af8a). ptr1 and ptr2 passed to
cl_optimization_compare() differ in the following:

--- /tmp/ptr1   2022-01-12 12:04:55.682072663 +0700
+++ /tmp/ptr2   2022-01-12 12:05:37.247041664 +0700
@@ -1305,7 +1305,7 @@
 x_secure_plt = 1
 x_rs6000_abi_name = 0x1b403a2 "linux"
 x_rs6000_compat_align_parm = 0
-x_rs6000_cpu_index = -1
+x_rs6000_cpu_index = 0
 x_rs6000_fold_gimple = 1
 x_TARGET_NO_FP_IN_TOC = 1
 x_TARGET_FRIZ = -1
@@ -1339,7 +1339,7 @@
 x_rs6000_stack_protector_guard_reg_str = 0x0
 x_rs6000_stack_protector_guard = SSP_TLS
 x_rs6000_string_compare_inline_limit = 64
-x_rs6000_tune_index = -1
+x_rs6000_tune_index = 0
 x_unroll_only_small_loops = 0
 x_rs6000_veclibabi_name = 0x0
 x_TARGET_ALTIVEC_VRSAVE = 0

% powerpc-e300c3-linux-gnu-gcc-12.0.0 -mcpu=401 -c tt.c -v
Using built-in specs.
COLLECT_GCC=powerpc-e300c3-linux-gnu-gcc-12.0.0
Target: powerpc-e300c3-linux-gnu
Configured with:
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20220109/work/gcc-12-20220109/configure
--host=x86_64-pc-linux-gnu --target=powerpc-e300c3-linux-gnu
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/powerpc-e300c3-linux-gnu/gcc-bin/12.0.0
--includedir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/12.0.0/include
--datadir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/12.0.0
--mandir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/12.0.0/man
--infodir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/12.0.0/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/12.0.0/include/g++-v12
--with-python-dir=/share/gcc-data/powerpc-e300c3-linux-gnu/12.0.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls
--disable-libunwind-exceptions --enable-checking=yes --disable-esp
--enable-libstdcxx-time --disable-libstdcxx-pch
--enable-poison-system-directories --with-sysroot=/usr/powerpc-e300c3-linux-gnu
--disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libssp --disable-libada --disable-cet --disable-systemtap
--enable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --enable-lto --with-isl --disable-isl-version-check
--disable-libsanitizer --enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20220109 (experimental) (GCC)

<…>

% powerpc-e300c3-linux-gnu-gcc-12.0.0 -mcpu=401 -c tt.c -Q --help=target
The following options are target specific:
  -G8
  -m32  [enabled]
  -m64  [disabled]
  -mabi=altivec [disabled]
  -mabi=d32 [enabled]
  -mabi=d64 [disabled]
  -mabi=elfv1   [disabled]
  -mabi=elfv2   [disabled]
  -mabi=ibmlongdouble   [enabled]
  -mabi=ieeelongdouble  [disabled]
  -mabi=no-altivec  [enabled]
  -mabi=vec-default [enabled]
  -mabi=vec-extabi  [disabled]
  -mads [disabled]
  -maix-struct-return   [enabled]
  -malign-  natural
  -malign-branch-targets
  -mallow-movmisalign   [disabled]
  -maltivec [disabled]
  -malways-hint 
  -mavoid-indexed-addresses [disabled]
  -mbig [enabled]
  -mbig-endian  [enabled]
  -mbionic  [disabled]
  -mbit-align   [disabled]
  -mbit-word[disabled]
  -mblock-compare-inline-limit= 63
  -mblock-compare-inline-loop-limit=-1
  -mblock-move-inline-limit=32
  -mblock-ops-unaligned-vsx [disabled]
  -mblock-ops-vector-pair   [disabled]
  -mbss-plt [disabled]
  -mcall-ABIlinux
  -mcmodel= small
  -mcmpb[disabled]
  -mcompat-align-parm   [disabled]
  -mcpu=401
  -mcrypto  [disabled]
  -mdebug=  
  -mdirect-move [disabled]
  -mdlmzb   [disabled]
  -meabi 

Re: PING^2 (C/C++): Re: [PATCH 6/6] Add __attribute__ ((tainted))

[Jason Merrill via Gcc-patches]

On 1/10/22 16:36, David Malcolm via Gcc-patches wrote:

On Thu, 2022-01-06 at 09:08 -0500, David Malcolm wrote:

On Sat, 2021-11-13 at 15:37 -0500, David Malcolm wrote:

This patch adds a new __attribute__ ((tainted)) to the C/C++
frontends.


Ping for GCC C/C++ mantainers for review of the C/C++ FE parts of this
patch (attribute registration, documentation, the name of the
attribute, etc).

(I believe it's independent of the rest of the patch kit, in that it
could go into trunk without needing the prior patches)

Thanks
Dave


Getting close to end of stage 3 for GCC 12, so pinging this patch
again...

https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584376.html


The c-family change is OK.


Thanks
Dave






It can be used on function decls: the analyzer will treat as tainted
all parameters to the function and all buffers pointed to by
parameters
to the function.  Adding this in one place to the Linux kernel's
__SYSCALL_DEFINEx macro allows the analyzer to treat all syscalls as
having tainted inputs.  This gives additional testing beyond e.g.
__user
pointers added by earlier patches - an example of the use of this can
be
seen in CVE-2011-2210, where given:

  SYSCALL_DEFINE5(osf_getsysinfo, unsigned long, op, void __user *,
buffer,
  unsigned long, nbytes, int __user *, start, void
__user *, arg)

the analyzer will treat the nbytes param as under attacker control,
and
can complain accordingly:

taint-CVE-2011-2210-1.c: In function ‘sys_osf_getsysinfo’:
taint-CVE-2011-2210-1.c:69:21: warning: use of attacker-controlled
value
   ‘nbytes’ as size without upper-bounds checking [CWE-129] [-
Wanalyzer-tainted-size]
    69 | if (copy_to_user(buffer, hwrpb, nbytes) != 0)
   | ^~~

Additionally, the patch allows the attribute to be used on field
decls:
specifically function pointers.  Any function used as an initializer
for such a field gets treated as tainted.  An example can be seen in
CVE-2020-13143, where adding __attribute__((tainted)) to the "store"
callback of configfs_attribute:

   struct configfs_attribute {
  /* [...snip...] */
  ssize_t (*store)(struct config_item *, const char *, size_t)
    __attribute__((tainted));
  /* [...snip...] */
   };

allows the analyzer to see:

  CONFIGFS_ATTR(gadget_dev_desc_, UDC);

and treat gadget_dev_desc_UDC_store as tainted, so that it complains:

taint-CVE-2020-13143-1.c: In function ‘gadget_dev_desc_UDC_store’:
taint-CVE-2020-13143-1.c:33:17: warning: use of attacker-controlled
value
   ‘len + 18446744073709551615’ as offset without upper-bounds
checking [CWE-823] [-Wanalyzer-tainted-offset]
    33 | if (name[len - 1] == '\n')
   | ^

Similarly, the attribute could be used on the ioctl callback field,
USB device callbacks, network-handling callbacks etc.  This
potentially
gives a lot of test coverage with relatively little code annotation,
and
without necessarily needing link-time analysis (which -fanalyzer can
only do at present on trivial examples).

I believe this is the first time we've had an attribute on a field.
If that's an issue, I could prepare a version of the patch that
merely allowed it on functions themselves.

As before this currently still needs -fanalyzer-checker=taint (in
addition to -fanalyzer).

gcc/analyzer/ChangeLog:
 * engine.cc: Include "stringpool.h", "attribs.h", and
 "tree-dfa.h".
 (mark_params_as_tainted): New.
 (class tainted_function_custom_event): New.
 (class tainted_function_info): New.
 (exploded_graph::add_function_entry): Handle functions with
 "tainted" attribute.
 (class tainted_field_custom_event): New.
 (class tainted_callback_custom_event): New.
 (class tainted_call_info): New.
 (add_tainted_callback): New.
 (add_any_callbacks): New.
 (exploded_graph::build_initial_worklist): Find callbacks that
are
 reachable from global initializers, calling add_any_callbacks
on
 them.

gcc/c-family/ChangeLog:
 * c-attribs.c (c_common_attribute_table): Add "tainted".
 (handle_tainted_attribute): New.

gcc/ChangeLog:
 * doc/extend.texi (Function Attributes): Note that "tainted"
can
 be used on field decls.
 (Common Function Attributes): Add entry on "tainted"
attribute.

gcc/testsuite/ChangeLog:
 * gcc.dg/analyzer/attr-tainted-1.c: New test.
 * gcc.dg/analyzer/attr-tainted-misuses.c: New test.
 * gcc.dg/analyzer/taint-CVE-2011-2210-1.c: New test.
 * gcc.dg/analyzer/taint-CVE-2020-13143-1.c: New test.
 * gcc.dg/analyzer/taint-CVE-2020-13143-2.c: New test.
 * gcc.dg/analyzer/taint-CVE-2020-13143.h: New test.
 * gcc.dg/analyzer/taint-alloc-3.c: New test.
 * gcc.dg/analyzer/taint-alloc-4.c: New test.

Signed-off-by: David Malcolm 
---
  gcc/analyzer/engine.cc   

[Bug tree-optimization/103986] [9/10 Regression] Miscompilation with -O2 -funswitch-loops and __builtin_unreachable

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

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

--- Comment #3 from Andrew Pinski  ---
This might be a latent bug in GCC 11 even.
The only difference in the IR before unswitch (besides BB reordering) is:

GCC 10.x:
   [local count: 1073741824]:
  # it$m_pos$x_21 = PHI <0(4), _26(13)>
  if (it$4_29 == 3)
goto ; [11.00%]
  else
goto ; [89.00%]

GCC 11+:
   [local count: 1073741824]:
  # it$m_pos$x_19 = PHI <0(9), _24(13)>
  if (it$4_32 != 3)
goto ; [89.00%]
  else
goto ; [11.00%]

Note bb 11 is the return.

[Bug tree-optimization/103986] [9/10 Regression] Miscompilation with -O2 -funswitch-loops and __builtin_unreachable

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[9/10 Regression]   |[9/10 Regression]
   |Miscompilation with -O2 |Miscompilation with -O2
   |-funswitch-loops and|-funswitch-loops and
   |__builtin_unreachable in|__builtin_unreachable
   |ternary operator|

--- Comment #2 from Andrew Pinski  ---
Note ?: is not the difference as I can reproduce it with:

#define assume(Expression) do { if((Expression)) (void)0; else
__builtin_unreachable(); } while(0)

[Bug tree-optimization/103986] [9/10 Regression] Miscompilation with -O2 -funswitch-loops and __builtin_unreachable in ternary operator

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

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

--- Comment #1 from Andrew Pinski  ---
Looks like it works in GCC 11.1.0.

[Bug tree-optimization/103986] [9/10 Regression] Miscompilation with -O2 -funswitch-loops and __builtin_unreachable in ternary operator

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
   Keywords||wrong-code
Summary|Miscompilation with -O2 |[9/10 Regression]
   |-funswitch-loops and|Miscompilation with -O2
   |__builtin_unreachable in|-funswitch-loops and
   |ternary operator|__builtin_unreachable in
   ||ternary operator

[Bug tree-optimization/103986] New: Miscompilation with -O2 -funswitch-loops and __builtin_unreachable in ternary operator

[daniel at constexpr dot org via Gcc-bugs]

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

Bug ID: 103986
   Summary: Miscompilation with -O2 -funswitch-loops and
__builtin_unreachable in ternary operator
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel at constexpr dot org
  Target Milestone: ---

Created attachment 52166
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52166=edit
Reduced test case

The loop in the attached reduced test case does not terminate when compiled
with -O3 or -O2 -funswitch-loops with GCC 9.4.0 or GCC 10.3.1 even though it
should only iterate 144 times.

Curiously, the programs works as expected when using an if() instead of the
ternary operator in the assume macro but maybe that's just luck.

I could not reproduce the issue with GCC 8.5.0, GCC 11.2.1 or my GCC 12
checkout from 20220102.

libgfortran bootstrap failure

[David Edelsohn via Gcc-patches]

The recent patch to support Power IEEE128 causes a bootstrap failure
on AIX and possibly all non-GLIBC systems.

+#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
+&& defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
+#define POWER_IEEE128 1
+#endif

__GLIBC_PREREQ is tested on all systems.

/nasfarm/edelsohn/src/src/libgfortran/libgfortran.h:107:49: error:
missing binary operator before token "("
  107 | && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
  | ^

[Committed] cris: Avoid format-string-related warnings in calls to error functions

[Hans-Peter Nilsson via Gcc-patches]

These tweaks are installed to avoid build-warnings for
config/cris/cris.c, like:

x/gcc/config/cris/cris.c: In function 'const char* cris_op_str(rtx)':
x/gcc/config/cris/cris.c:728:23: warning: unquoted identifier or keyword \
'cris_op_str' in format [-Wformat-diag]
  728 |   internal_error ("MULT case in cris_op_str");
  |   ^~
In file included from ./tm.h:20,
 from x/gcc/backend.h:28,
 from x/gcc/config/cris/cris.c:26:
x/gcc/config/cris/cris.c: In function 'void cris_expand_return(bool)':
x/gcc/config/cris/cris.h:42:33: warning: unquoted operator '->' in \
format [-Wformat-diag]
   42 |  do { if (!(x)) internal_error ("CRIS-port assertion failed: " #x); \
} while (0)
x/gcc/config/cris/cris.c:1862:3: note: in expansion of macro 'CRIS_ASSERT'
 1862 |   CRIS_ASSERT (cfun->machine->return_type != CRIS_RETINSN_RET \
|| !on_stack);
  |   ^~~
x/gcc/config/cris/cris.c: In function 'void cris_option_override()':
x/gcc/config/cris/cris.c:2298:9: warning: space followed by punctuation \
character ':' [-Wformat-diag]
 2298 |  error ("unknown CRIS version specification in %<-march=%> or "
  | ^~~
 2299 | "%<-mcpu=%> : %s", cris_cpu_str);
  | ~
x/gcc/config/cris/cris.c:2334:9: warning: space followed by punctuation \
character ':' [-Wformat-diag]
 2334 |  error ("unknown CRIS cpu version specification in %<-mtune=%> : %s",
  | ^~~~
In file included from ./tm.h:20,
 from x/gcc/backend.h:28,
 from x/gcc/config/cris/cris.c:26:
x/gcc/config/cris/cris.c: In function 'rtx_def* cris_split_movdx(rtx_def**)':
x/gcc/config/cris/cris.h:42:33: warning: unquoted identifier or keyword \
'GET_CODE' in format [-Wformat-diag]
   42 |  do { if (!(x)) internal_error ("CRIS-port assertion failed: " #x); \
} while (0)
x/gcc/config/cris/cris.c:2457:3: note: in expansion of macro 'CRIS_ASSERT'
 2457 |   CRIS_ASSERT (GET_CODE (dest) != SUBREG && GET_CODE (src) != SUBREG);
  |   ^~~

Not that I therefore agree that operators, identifiers and keywords
should have to be dressed up like this for internal error messages;
they were more readable without these garments, if only slightly so.

2022-01-11  Hans-Peter Nilsson  

* config/cris/cris.c: Quote identifiers in parameters to error
and internal_error, and remove extraneous spaces with punctuation.
* config/cris/cris.h (CRIS_ASSERT): When passing on stringified
expression to internal_error, pass it as a parameter instead of
appending it to the format part.
---
 gcc/config/cris/cris.c | 8 
 gcc/config/cris/cris.h | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/config/cris/cris.c b/gcc/config/cris/cris.c
index ac1fc4909fc3..63e6834b9cfb 100644
--- a/gcc/config/cris/cris.c
+++ b/gcc/config/cris/cris.c
@@ -725,7 +725,7 @@ cris_op_str (rtx x)
 an operator, for immediate output.  If that ever happens for
 MULT, we need to apply TARGET_MUL_BUG in the caller.  Make sure
 we notice.  */
-  internal_error ("MULT case in cris_op_str");
+  internal_error ("MULT case in %");
   break;
 
 case DIV:
@@ -2213,7 +2213,7 @@ cris_side_effect_mode_ok (enum rtx_code code, rtx *ops,
 }
 
   /* If we get here, the caller got its initial tests wrong.  */
-  internal_error ("internal error: cris_side_effect_mode_ok with bad 
operands");
+  internal_error ("internal error: % with bad 
operands");
 }
 
 /* Queue an .ident string in the queue of top-level asm statements.
@@ -2296,7 +2296,7 @@ cris_option_override (void)
 
   if (cris_cpu_version < 0 || cris_cpu_version > 10)
error ("unknown CRIS version specification in %<-march=%> or "
-  "%<-mcpu=%> : %s", cris_cpu_str);
+  "%<-mcpu=%>: %s", cris_cpu_str);
 
   /* Set the target flags.  */
   if (cris_cpu_version >= CRIS_CPU_ETRAX4)
@@ -2331,7 +2331,7 @@ cris_option_override (void)
cris_tune = 10;
 
   if (cris_tune < 0 || cris_tune > 32)
-   error ("unknown CRIS cpu version specification in %<-mtune=%> : %s",
+   error ("unknown CRIS cpu version specification in %<-mtune=%>: %s",
   cris_tune_str);
 
   if (cris_tune >= CRIS_CPU_SVINTO)
diff --git a/gcc/config/cris/cris.h b/gcc/config/cris/cris.h
index c4d635ba0ae9..8235509f2337 100644
--- a/gcc/config/cris/cris.h
+++ b/gcc/config/cris/cris.h
@@ -39,7 +39,7 @@ along with GCC; see the file COPYING3.  If not see
 /* We don't want to use gcc_assert for everything, as that can be
compiled out.  */
 #define CRIS_ASSERT(x) \
- do { if (!(x)) internal_error ("CRIS-port assertion failed: " #x); } while (0)
+ do { if (!(x)) internal_error ("CRIS-port assertion failed: %s", #x); } while 
(0)
 
 /* Replacement for REG_P since 

[Committed] cris: Parenthesize parameter to as_a.

[Hans-Peter Nilsson via Gcc-patches]

Noted by Richard Sandiford in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103974#c7 (thanks!)

Mea culpa: I wrongly thought the default development-level value
("yes,extra") would include everything interesting to normal target
hacking (i.e. as opposed to hacking stuff like GC).  I see
rtl-checking is marked as "expensive" and presumably therefore left
out.  Maybe it could be split into rtl-static (cheap; catching type
errors including this kind of foulups) and rtl-dynamic (the expensive
parts).  I suppose that's for whomever feels a strong enough itch.

A quick (error-prone) grep-and-eyeball in config/ shows this was the
only file missing the parenthesis.  This lets cris-elf configured with
--enable-checking=yes,extra,rtl survive make all-gcc.

2022-01-11  Hans-Peter Nilsson  

* config/cris/cris.c (cris_postdbr_cmpelim): Parenthesize
parameter to as_a.
---
 gcc/config/cris/cris.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/cris/cris.c b/gcc/config/cris/cris.c
index eff58435789e..ac1fc4909fc3 100644
--- a/gcc/config/cris/cris.c
+++ b/gcc/config/cris/cris.c
@@ -392,7 +392,7 @@ cris_postdbr_cmpelim ()
   /* Consider filled delay slots; there might be a comparison there.
 It's only the second insn in a sequence that is interesting.  */
   if (GET_CODE (pat) == SEQUENCE)
-   insn = as_a  XVECEXP (pat, 0, 1);
+   insn = as_a  (XVECEXP (pat, 0, 1));
   /* The "else" eliminates temptations to consider an insn in a
 delay slot for elimination; it can only be a prev_cc_setter.  */
   else if (prev_cc_setter != 0 && GET_CODE (pat) == SET)
-- 
2.30.2

brgds, H-P

[Bug c++/51620] [c++0x] [4.6/4.7 Regression] ICE with private destructor

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by H.J. Lu :

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

commit r11-9454-g8c0f58cd71ec3afcce5abf10c750ec494e88232b
Author: H.J. Lu 
Date:   Fri Dec 17 11:08:32 2021 -0800

libsanitizer: Cherry-pick LLVM release/13.x commit d96358a28193

Cherry-pick from LLVM release/13.x branch:

commit d96358a2819399a2abb60ad3b26444ab7b4409cf
Author: MichaŠGórny 
Date:   Mon Dec 13 22:28:26 2021 +0100

[compiler-rt] Increase kDlsymAllocPoolSize to fix test failures

Increase kDlsymAllocPoolSize on the release branch as discussed on bug
51620, as an alternative to backporting
cb0e14ce6dcdd614a7207f4ce6fcf81a164471ab and its dependencies.
The minimum size is 8192, as needed for the following test to pass:

  AddressSanitizer-i386-linux :: TestCases/Linux/long-object-path.cpp

Fixes #51620

PR sanitizer/102911
* asan/asan_malloc_linux.cpp (kDlsymAllocPoolSize): Set it to
8192 on Linux.

[Bug sanitizer/102911] AddressSanitizer: CHECK failed: asan_malloc_linux.cpp:46

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by H.J. Lu :

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

commit r11-9454-g8c0f58cd71ec3afcce5abf10c750ec494e88232b
Author: H.J. Lu 
Date:   Fri Dec 17 11:08:32 2021 -0800

libsanitizer: Cherry-pick LLVM release/13.x commit d96358a28193

Cherry-pick from LLVM release/13.x branch:

commit d96358a2819399a2abb60ad3b26444ab7b4409cf
Author: MichaŠGórny 
Date:   Mon Dec 13 22:28:26 2021 +0100

[compiler-rt] Increase kDlsymAllocPoolSize to fix test failures

Increase kDlsymAllocPoolSize on the release branch as discussed on bug
51620, as an alternative to backporting
cb0e14ce6dcdd614a7207f4ce6fcf81a164471ab and its dependencies.
The minimum size is 8192, as needed for the following test to pass:

  AddressSanitizer-i386-linux :: TestCases/Linux/long-object-path.cpp

Fixes #51620

PR sanitizer/102911
* asan/asan_malloc_linux.cpp (kDlsymAllocPoolSize): Set it to
8192 on Linux.

[Bug target/103980] -Wdouble-promotion triggers on s390x when it shouldn't.

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

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

--- Comment #7 from Andrew Pinski  ---
It might be the case Wdouble-promotion is just useless on s390 if you configure
your compiler with --enable-s390-excess-float-precision which was only added
for GCC11, so basically between GCC 7 and GCC 10.x, the default was to promote
all float to double for s390.

[Bug target/103980] -Wdouble-promotion triggers on s390x when it shouldn't.

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Host|s390x-*-linux-gnu   |
  Build|s390x-*-linux-gnu   |
  Component|c   |target

--- Comment #6 from Andrew Pinski  ---
g:638108bd6748d7c38dceac491a62c6ce5355850d
g:a5dd6b69fcbe74c02d4821ac2daf2b8c9f819f6e 

Are the two important ones to read.

[Bug tree-optimization/96707] Failure to optimize right shift+unsigned compare of two variables optimally

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #4 from Andrew Macleod  ---
The IL generated is:

  _1 = x_2(D) >> y_3(D);
  _4 = _1 <= x_2(D);
  return _4;

All that should be needed is for the right shift operator in range-ops to
implement lhs_op1_relation() to indicate that if the range of op2 is >=0, then 
return LE_EXPR.   

this will automatically register  the relation _1 <= x_2 at the def point for
_1, and then _4 should simply fold away as true.

Re: [GCC-11] [PATCH] libsanitizer: Cherry-pick LLVM release/13.x commit d96358a28193

[H.J. Lu via Gcc-patches]

On Mon, Jan 3, 2022 at 6:06 AM Richard Biener
 wrote:
>
> On Fri, Dec 17, 2021 at 11:45 PM H.J. Lu via Gcc-patches
>  wrote:
> >
> > OK for release branches?
>
> OK - I assume the size is not leaked as ABI detail?

No, it is not.  I am checking it into GCC 11 and will backport
it to GCC 10/9 branches later.

> >
> > H.J.
> > ---
> > Cherry-pick from LLVM release/13.x branch:
> >
> > commit d96358a2819399a2abb60ad3b26444ab7b4409cf
> > Author: Michał Górny 
> > Date:   Mon Dec 13 22:28:26 2021 +0100
> >
> > [compiler-rt] Increase kDlsymAllocPoolSize to fix test failures
> >
> > Increase kDlsymAllocPoolSize on the release branch as discussed on bug
> > 51620, as an alternative to backporting
> > cb0e14ce6dcdd614a7207f4ce6fcf81a164471ab and its dependencies.
> > The minimum size is 8192, as needed for the following test to pass:
> >
> >   AddressSanitizer-i386-linux :: TestCases/Linux/long-object-path.cpp
> >
> > Fixes #51620
> >
> > PR sanitizer/102911
> > * asan/asan_malloc_linux.cpp (kDlsymAllocPoolSize): Set it to
> > 8192 on Linux.
> > ---
> >  libsanitizer/asan/asan_malloc_linux.cpp | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libsanitizer/asan/asan_malloc_linux.cpp 
> > b/libsanitizer/asan/asan_malloc_linux.cpp
> > index 9c3f0a5338e..7a5776b29ed 100644
> > --- a/libsanitizer/asan/asan_malloc_linux.cpp
> > +++ b/libsanitizer/asan/asan_malloc_linux.cpp
> > @@ -31,7 +31,7 @@ using namespace __asan;
> >
> >  static uptr allocated_for_dlsym;
> >  static uptr last_dlsym_alloc_size_in_words;
> > -static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 1024;
> > +static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 8192;
> >  static uptr alloc_memory_for_dlsym[kDlsymAllocPoolSize];
> >
> >  static inline bool IsInDlsymAllocPool(const void *ptr) {
> > --
> > 2.33.1
> >

Thanks.

-- 
H.J.

[Bug target/98348] [10 Regression] GCC 10.2 AVX512 Mask regression from GCC 9

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #23 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #22)
> (In reply to Dávid Bolvanský from comment #20)
> > Some small regression (missed opportunity to use vptestnmd):
> > 
> > Current trunk
> > 
> > compare(unsigned int __vector(16)):
> >   vpxor xmm1, xmm1, xmm1
> >   vpcmpd k0, zmm0, zmm1, 0
> >   vpmovm2d zmm0, k0
> >   ret
> > 
> > GCC 9.2
> > 
> > compare(unsigned int __vector(16)):
> >   vptestnmd k0, zmm0, zmm0
> >   vpmovm2d zmm0, k0
> >   ret
> > 
> > 
> > https://gcc.godbolt.org/z/5vK68jM3r
> 
> A patch is posed at
> https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568210.html

Fixed by r12-3239

[Bug libfortran/103985] segfault in finalize_transfer (fbuf_destroy) on (parallel) writing into character / string function argument

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

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

--- Comment #1 from Andrew Pinski  ---
There could be a lock missing when it comes to the write. I remember in the
past there were some issues with writes not being thread safe (maybe they still
are not).

[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
I'm not at all familiar with any of this code (yet), but...

Note that it is complaining about variable i declared in the outer procedure p,
not about something in the nested function s that contains the OMP directives.

Looking at the .original dump, I see that the declaration for the iterator
variable j is appearing in the outer procedure p, not the inner function s
where it is used in the OMP task directive.  The .gimple dump shows both i
*and* j declared in both procedures, and the .nested dump shows that a bunch of
static chain stuff has been added for j.  So my guess is that these variables
being inserted into wrong scopes is confusing the ssa passes.

Azuka Kiki

[Annette Wiggins via Gcc]



[Bug tree-optimization/99755] failure to fold a conditional that's a subset of another expression

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Andrew Macleod  ---
we now know the PHI is an equivalence when the other argument is UNDEFINED.:
 [local count: 268435456]:
x_12 = i_8(D) + 1;

x_12 : int [3, +INF]

Equivalence set : [x_7, x_12]<<--Equivalence marked   
 [local count: 805306367]:
# x_7 = PHI 
_4 = i_8(D) == 2;
_5 = j_9(D) == 3;
_15 = k_11(D) == 4;
_21 = _5 & _15;
_16 = _4 & _21;
_17 = x_7 != 3;
_18 = _16 & _17;
if (_18 != 0)
  goto ; [0.00%]
else
  goto ; [100.00%]

x_7 : int [3, +INF]
5->6  (T) _4 :  _Bool [1, 1]
5->6  (T) _5 :  _Bool [1, 1]
5->6  (T) x_7 : int [4, +INF]
5->6  (T) i_8(D) :  int [2, 2]
5->6  (T) j_9(D) :  int [3, 3]

Whats missing is potentially recalculating equivalences on outgoing edges.
we know 
  1) i_8 has a range of [2,2] on the edge 5->6
  2) we know that x_7 and x_12 are equivalences
  3) we know that x_12 = i_8(D) + 1;
  4) We have the ability to recompute x_12 using i_8 on that edge, which would 
conclude x_12 = [3,3] on that edge.  We just don't know to ask that question
(yet).
  5) the equivalence set of x_12=[3, 3] and x_7=[4, +INF] are incompatible.
their intersection is EMPTY, which in turns means the edge is unexecutable.

This is demonstrated by the requirement that x_7 != 3 be true, as well as (x_7
== x_12 == [3,3]) at the same time.

The information is all there, we just need to figure out how best to use it.

[Bug target/102239] powerpc suboptimal boolean test of contiguous bits

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

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #13 from luoxhu at gcc dot gnu.org ---
Fixed on master.

[Bug tree-optimization/103977] [12 Regression] ice in try_vectorize_loop_1 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #4 from Jeffrey A. Law  ---
FWIW, the patch Jakub identified is causing similar testsuite regressions
across ~30 targets at this point.

Re: [Patch][V3][Patch 1/2]Change the 3rd parameter of function .DEFERRED_INIT from IS_VLA to decl name

[Qing Zhao via Gcc-patches]

FYI.

Just committed this patch to gcc12 as:

https://gcc.gnu.org/pipermail/gcc-cvs/2022-January/359118.html

Qing
> On Jan 11, 2022, at 9:38 AM, Qing Zhao via Gcc-patches 
>  wrote:
> 
> 
> 
>> On Jan 11, 2022, at 7:53 AM, Richard Biener  
>> wrote:
>> 
>> On Tue, Jan 11, 2022 at 12:58 AM Qing Zhao  wrote:
>>> 
>>> Hi, Richard,
>>> 
>>> I splited the previous patch for “Enable -Wuninitialized + 
>>> -ftrivial-auto-var-init for address taken variables” into two separate 
>>> patches.
>>> This is the first one
>>> 
>>> This first  patch  is to fix (or work around ) PR103720, therefore it’s an 
>>> important change, and need to be go into GCC12.
>>> At the same time, this patch is the preparation for the second patch that 
>>> will actually enable -Wuninitialized + -ftrivial-auto-var-init for address 
>>> taken variables.
>>> 
>>> The reason I separate the previous patch into two is: most of the previous 
>>> concern was on the second part of the patch (the change in 
>>> tree-ssa-uninit.c), I don’t
>>> want those concern prevent this first patch from being approved into GCC12.
>>> 
>>> 
>>> In this part, I addressed your comments in  gimplify.c :
>>> 
>>> =
>>> tree decl_name
>>> += build_string_literal (IDENTIFIER_LENGTH (DECL_NAME (decl)) + 1,
>>> +   IDENTIFIER_POINTER (DECL_NAME (decl)));
>>> 
>>> you need to deal with DECL_NAME being NULL.
>>> =
>>> 
>>> Please also see the detailed description below for the problem and solution 
>>> of this patch.
>>> 
>>> This first patch has been bootstrapped and regressing tested on both X86 
>>> and aarch64.
>>> 
>>> Okay for GCC12?
>> 
>> +
>> +  char *decl_name_anonymous = xasprintf ("D.%u", DECL_UID (decl));
>> +  const char *decl_name_str = DECL_NAME (decl)
>> + ? IDENTIFIER_POINTER (DECL_NAME (decl))
>> + : decl_name_anonymous;
>> +  tree decl_name
>> += build_string_literal (strlen (decl_name_str) + 1,
>> +   decl_name_str);
>> 
>> please avoid the xasprintf in the case DECL_NAME is not NULL, I'd be happy
>> with sth like
>> 
>>  tree decl_name;
>>  if (DECL_NAME (decl))
>> decl_name = build_string_literal (...);
>>  else
>> {
>>char *decl_name_anon = xasprintf (...);
>>decl_name = build_string_literal (...);
>>free (decl_name_anon);
>> }
>> 
>> otherwise the patch is OK to commit (just do the above change and
>> re-test / push).
> 
> Thanks for the comment, will fix this and commit the patch.
> 
> Qing
>> 
>> Thanks,
>> Richard.
>> 
>>> Thanks.
>>> 
>>> Qing.
>>> 
>>> 
>>> =
>>> 
>>> Change the 3rd parameter of function .DEFERRED_INIT from
>>> IS_VLA to decl name.
>>> 
>>> Currently, the 3rd parameter of function .DEFERRED_INIT is IS_VLA, which is
>>> not needed at all;
>>> 
>>> In this patch, we change the 3rd parameter from IS_VLA to the name of the 
>>> var
>>> decl for the following purposes:
>>> 
>>> 1. Fix (or work around) PR103720:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103720
>>> 
>>> As confirmed in PR103720, with the current definition of .DEFERRED_INIT,
>>> 
>>> Dom transformed:
>>> c$a$0_6 = .DEFERRED_INIT (8, 2, 0);
>>> _1 = .DEFERRED_INIT (8, 2, 0);
>>> 
>>> into:
>>> c$a$0_6 = .DEFERRED_INIT (8, 2, 0);
>>> _1 = c$a$0_6;
>>> 
>>> which is incorrectly done due to Dom treating the two calls to const 
>>> function
>>> .DEFERRED_INIT as the same call since all actual parameters are the same.
>>> 
>>> The same issue has been exposed in PR102608 due to a different optimization 
>>> VN,
>>> the fix for PR102608 is to specially handle call to .DEFERRED_INIT in VN to
>>> exclude it from CSE.
>>> 
>>> To fix PR103720, we could do the same as the fix to PR102608 to specially
>>> handle call to .DEFERRED_INIT in Dom to exclude it from being optimized.
>>> 
>>> However, in addition to Dom and VN, there should be other optimizations that
>>> have the same issue as PR103720 or PR102608 (As I built Linux kernel with
>>> -ftrivial-auto-var-init=zero -Werror, I noticed a bunch of bugos warnings).
>>> 
>>> Other than identifying all the optimizations and specially handling call to
>>> .DEFERRED_INIT in all these optimizations, changing the 3rd parameter of the
>>> function .DEFERRED_INIT from IS_VLA to the name string of the var decl might
>>> be a better workaround (or a fix). After this change, since the 3rd actual
>>> parameter is the name string of the variable, different calls for different
>>> variables will have different name strings as the 3rd actual, As a result, 
>>> the
>>> optimization that previously treated the different calls to .DEFERRED_INIT 
>>> as
>>> the same will be prevented.
>>> 
>>> 2. Prepare for enabling -Wuninitialized + -ftrivail-auto-var-init for 
>>> address
>>> taken variables.
>>> 
>>> As discussion in the following thread:
>>> 
>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577431.html
>>> 
>>> With the current 

Re: [power-ieee128, committed] Enable conversion selection via environment variable

[Jakub Jelinek via Gcc-patches]

On Tue, Jan 11, 2022 at 10:44:56PM +0100, Thomas Koenig wrote:
> > > So... time to merge the branch into trunk before stage 4
> > > kicks in?
> > 
> > IMHO yes.  We need to git merge master; git rebase of course
> > before trying to cherry-pick those commits into trunk and pushing there.
> 
> I would prefer if somebody else did this - my lack of git-fu would
> forseeably lead to some unforseen problems :-)

My git-fu is limited too, but I've pushed it to trunk now.

Jakub

[Bug tree-optimization/81953] Code sinking increases register pressure

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

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #6 from Bill Schmidt  ---
Resetting to unassigned as Kelvin left the project.

[Bug libfortran/103985] New: segfault in finalize_transfer (fbuf_destroy) on (parallel) writing into character / string function argument

[thomas.orgis--- via Gcc-bugs]

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

Bug ID: 103985
   Summary: segfault in finalize_transfer (fbuf_destroy) on
(parallel) writing into character / string function
argument
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.or...@uni-hamburg.de
  Target Milestone: ---

I noticed an infrequent crash of an OpenMP-parallelized scientific application
that is observable when running hundreds of instances. A recent reproduction
attempt on 250 Haswell nodes on Linux 4.14.259 with a loop over simulation
setup and some short computation showed 4 cases of the crash vs. 3176
successful runs. Each run used 16 threads on a dual-socket node.

This chance means getting a reproducer is tricky. This is a rather trivial part
of a rather elaborate codebase (which triggered a number of Fortran compiler
bugs before, regardless of compiler vendor), so it might be extracted, but the
odds may mean that certain structures in memory are necessary to really trip up
the gfortran runtime.

So I'll report the backtrace and some code fragments here. Maybe this already
points into some direction where one can home in on the underlying corruption.

This is the crash (leading the lines is a node name and seconds roughly since
program start):

node292 @ 14.482751:  model_setup: Done.
node292 @ 14.482965:  memory/kiB  peak=5924012 size=5924012 resp=3262324
ress=3225348
node292 @ 14.504973: 
node292 @ 14.505052: Program received signal SIGSEGV: Segmentation fault -
invalid memory reference.
node292 @ 14.505071: 
node292 @ 14.505083: Backtrace for this error:
node292 @ 15.149332: #0  0x15523d2cd3ff in ???
node292 @ 15.149365: #1  0x15523d3174a9 in ???
node292 @ 15.149376: #2  0x15523d31820d in ???
node292 @ 15.150486: #3  0x15523e46f469 in finalize_transfer
node292 @ 15.150499:at ../../../gcc-10.3.0/libgfortran/io/transfer.c:4228
node292 @ 15.150586: #4  0x430f6d in __stringtools_MOD_str_integer
node292 @ 15.150599:at .preprocessed/misc/stringtools.f90:147
node292 @ 15.150789: #5  0x546b3f in find_worst_speeds
node292 @ 15.150800:at .preprocessed/dgmodel/cfl.f90:309
node292 @ 15.150808: #6  0x546b3f in __cfl_MOD_cfl_timestep._omp_fn.0
node292 @ 15.150817:at .preprocessed/dgmodel/cfl.f90:198
node292 @ 15.150939: #7  0x15523d8de4d1 in GOMP_parallel
node292 @ 15.150951:at ../../../gcc-10.3.0/libgomp/parallel.c:171
node292 @ 15.150961: #8  0x547404 in __cfl_MOD_cfl_timestep
node292 @ 15.150969:at .preprocessed/dgmodel/cfl.f90:195
node292 @ 15.151289: #9  0x548f59 in find_new_step
node292 @ 15.151300:at .preprocessed/dgmodel/time_bdf.f90:635
node292 @ 15.151310: #10  0x54d98b in __time_bdf_MOD_time_bdf_explicit_part
node292 @ 15.151318:at .preprocessed/dgmodel/time_bdf.f90:399
node292 @ 15.151326: #11  0x54d98b in __time_bdf_MOD_time_bdf_step
node292 @ 15.151334:at .preprocessed/dgmodel/time_bdf.f90:489
node292 @ 15.151442: #12  0x526acc in __time_integration_MOD_timeint_step
node292 @ 15.151454:at .preprocessed/dgmodel/time_integration.f90:141
node292 @ 15.151743: #13  0x40b058 in dgmodel
node292 @ 15.151754:at .preprocessed/programs/dgmodel.f90:371
node292 @ 15.151764: #14  0x40760c in main
node292 @ 15.151772:at .preprocessed/programs/dgmodel.f90:46
node292 @ 17.984833: 85.74user 6.77system 0:16.76elapsed 551%CPU
(0avgtext+0avgdata 3262324maxresident)k
node292 @ 17.984892: 64680inputs+8737984outputs
(18major+1123633minor)pagefaults 0swaps

The memory stats before/after the crash might be useful, too … I reckon that
some significant memory action is necessary to observe the issue.

The respective code is inside an OpenMP section (line numbers prefixed):

186 !$omp parallel num_threads(cfl%threadcount) private(loopcount, ti)
187loopcount = size(state%setup%grid%elements)
188ti = ompapi_threadnum()
189 
190 
191cfl%maxei(:,ti) = -1
192cfl%max_e_speeds(:,ti) = 0._dp
193cfl%speedratio(:,ti) = m_big
194 
195 !$omp do
196do ei=1,loopcount
197   call find_worst_speeds(state%setup%grid%elements(ei), state, mytype,
cfl%maxei(:,ti), cfl%max_e_speeds(:,ti), cfl%speedratio&
198 &(:,ti), directions)
199end do
200 !$omp end do
201 !$omp end parallel

(The loopcount business is a workaround for an earlier compiler bug with Sun
Studio that messed up parallel loop boundaries, AFAIR.)

The routine find_worst_speeds does some computations on the handed-in
structures and then does this:

308 
309if(err_follow_line('dgmodel/cfl.F90', 265, 'Trouble in element ' //
trim(adjustl(str_number(element%id) return
310 end subroutine

The function err_follow_line checks a global error counter and returns true and
prints the constructed string that is passed if there has been an error raised
before. So, a simple type of exception 

Re: [PATCH v2 1/2] add -Wuse-after-free

[Jason Merrill via Gcc-patches]

On 11/30/21 17:32, Martin Sebor via Gcc-patches wrote:

Attached is a revised patch with the following changes based
on your comments:

1) Set and use statement uids to determine which statement
    precedes which in the same basic block.
2) Avoid testing flag_isolate_erroneous_paths_dereference.
3) Use post-dominance to decide whether to use the "maybe"
    phrasing vs a definite form.

David raised (and in our offline discussion today reiterated)
an objection to the default setting of the option being
the strictest.  I have not changed that in this revision.
See my rationale for this choice in my reply below:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583176.html


In the latest C2x draft I see in the list of undefined behavior

"The value of a pointer that refers to space deallocated by a call to 
the free or realloc function is used (7.22.3)."


So the case that would be technically undefined would be comparing the 
reallocated pointer to the old pointer which has been deallocated.


The C++ draft is more nuanced: it says, "When the end of the duration of 
a region of storage is reached, the values of all pointers representing 
the address of any part of that region of storage become invalid pointer 
values (6.8.3).  Indirection through an invalid pointer value and 
passing an invalid pointer value to a deallocation function have 
undefined behavior.  Any other use of an invalid pointer value has 
implementation-defined behavior."


So the case above is implementation-defined in C++, not undefined.

Let's put =2 in -Wall for now.

With that change, this and the -Wdangling-pointer patch are OK on Friday 
afternoon if there are no other comments before then.



On 11/23/21 2:16 PM, Martin Sebor wrote:

On 11/22/21 6:32 PM, Jeff Law wrote:



On 11/1/2021 4:17 PM, Martin Sebor via Gcc-patches wrote:

Patch 1 in the series detects a small subset of uses of pointers
made indeterminate by calls to deallocation functions like free
or C++ operator delete.  To control the conditions the warnings
are issued under the new -Wuse-after-free= option provides three
levels.  At the lowest level the warning triggers only for
unconditional uses of freed pointers and doesn't warn for uses
in equality expressions.  Level 2 warns also for come conditional
uses, and level 3 also for uses in equality expressions.

I debated whether to make level 2 or 3 the default included in
-Wall.  I decided on 3 for two reasons: 1) to raise awareness
of both the problem and GCC's new ability to detect it: using
a pointer after it's been freed, even only in principle, by
a successful call to realloc, is undefined, and 2) because
it's trivial to lower the level either globally, or locally
by suppressing the warning around such misuses.

I've tested the patch on x86_64-linux and by building Glibc
and Binutils/GDB.  It triggers a number of times in each, all
due to comparing invalidated pointers for equality (i.e., level
3).  I have suppressed these in GCC (libiberty) by a #pragma,
and will see how the Glibc folks want to deal with theirs (I
track them in BZ #28521).

The tests contain a number of xfails due to limitations I'm
aware of.  I marked them pr?? until the patch is approved.
I will open bugs for them before committing if I don't resolve
them in a followup.

Martin

gcc-63272-1.diff

Add -Wuse-after-free.

gcc/c-family/ChangeLog

* c.opt (-Wuse-after-free): New options.

gcc/ChangeLog:

* diagnostic-spec.c (nowarn_spec_t::nowarn_spec_t): Handle
OPT_Wreturn_local_addr and OPT_Wuse_after_free_.
* diagnostic-spec.h (NW_DANGLING): New enumerator.
* doc/invoke.texi (-Wuse-after-free): Document new option.
* gimple-ssa-warn-access.cc (pass_waccess::check_call): Rename...
(pass_waccess::check_call_access): ...to this.
(pass_waccess::check): Rename...
(pass_waccess::check_block): ...to this.
(pass_waccess::check_pointer_uses): New function.
(pass_waccess::gimple_call_return_arg): New function.
(pass_waccess::warn_invalid_pointer): New function.
(pass_waccess::check_builtin): Handle free and realloc.
(gimple_use_after_inval_p): New function.
(get_realloc_lhs): New function.
(maybe_warn_mismatched_realloc): New function.
(pointers_related_p): New function.
(pass_waccess::check_call): Call check_pointer_uses.
(pass_waccess::execute): Compute and free dominance info.

libcpp/ChangeLog:

* files.c (_cpp_find_file): Substitute a valid pointer for
an invalid one to avoid -Wuse-0after-free.

libiberty/ChangeLog:

* regex.c: Suppress -Wuse-after-free.

gcc/testsuite/ChangeLog:

* gcc.dg/Wmismatched-dealloc-2.c: Avoid -Wuse-after-free.
* gcc.dg/Wmismatched-dealloc-3.c: Same.
* gcc.dg/attr-alloc_size-6.c: Disable -Wuse-after-free.
* gcc.dg/attr-alloc_size-7.c: Same.
* c-c++-common/Wuse-after-free-2.c: New test.
* c-c++-common/Wuse-after-free-3.c: New test.
* c-c++-common/Wuse-after-free-4.c: New test.
* 

[Bug c++/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=52320,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=66139,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=66451

--- Comment #2 from Andrew Pinski  ---
Looks related to one of the following PRs:
PR 52320
PR 66139
PR 66451

Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

[FX via Gcc-patches]

Hi HJ,

> I looked at gcc-testresults and find e.g.
> 
> https://gcc.gnu.org/pipermail/gcc-testresults/2022-January/747938.html
> https://gcc.gnu.org/pipermail/gcc-testresults/2022-January/747935.html
> 
> which is x86 (64 and 32 bit) by H.J.; plus some more.
> Maybe H.J. can explain what is different from your platform?

Could you kindly look up what the log says for these failures on your boxes:

FAIL: gfortran.dg/ieee/signaling_1.f90   -O0  (test for excess errors)
UNRESOLVED: gfortran.dg/ieee/signaling_1.f90   -O0  compilation failed to 
produce executable

Somehow they did not seem to show up on my test machine. I’m launching a fresh 
bootstrap, but it will take a while.

FX

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

[Hafiz Abid Qadeer]

Hi Jakub

Thanks for the review. Please see comments inline. Also note that common block 
is now allowed in
allocate clause as per your comment so there is slight adjustment in the 
parsing code for that.

On 20/12/2021 20:06, Jakub Jelinek wrote:
> On Thu, Nov 18, 2021 at 07:30:36PM +, Hafiz Abid Qadeer wrote:
>> +  if (gfc_match (" : ") != MATCH_YES)
>> +{
>> +  /* If no ":" then there is no allocator, we backtrack
>> + and read the variable list.  */
>> +  gfc_free_expr (allocator);
>> +  allocator = NULL;
>> +  gfc_current_locus = old_loc;
>> +}
> 
> Ok, no leak above.
> 
>> +
>> +  gfc_omp_namelist **head = NULL;
>> +  m = gfc_match_omp_variable_list ("", >lists[OMP_LIST_ALLOCATE],
>> +   false, NULL, );
>> +
>> +  if (m == MATCH_ERROR)
>> +break;
> 
> But here it leaks.  Just call gfc_free_expr (allocator); before break.

Done. Although code is a bit different from the last patch.

> 
>> +
>> +  gfc_omp_namelist *n;
>> +  for (n = *head; n; n = n->next)
>> +if (allocator)
>> +  n->expr = gfc_copy_expr (allocator);
>> +else
>> +  n->expr = NULL;
>> +  gfc_free_expr (allocator);
>> +  continue;
>> +}
>>if ((mask & OMP_CLAUSE_AT)
>>&& (m = gfc_match_dupl_check (c->at == OMP_AT_UNSET, "at", true))
>>   != MATCH_NO)
> 
>> +  if (omp_clauses->lists[OMP_LIST_ALLOCATE])
>> +{
>> +  for (n = omp_clauses->lists[OMP_LIST_ALLOCATE]; n; n = n->next)
>> +if (n->expr && (n->expr->ts.type != BT_INTEGER
>> +|| n->expr->ts.kind != gfc_c_intptr_kind))
>> +  {
>> +gfc_error ("Expected integer expression of the "
>> +"'omp_allocator_handle_kind' kind at %L", >expr->where);
> 
> Formatting, "' should be indented below "Expected
Done.

> 
>> +break;
>> +  }
>> +
>> +  /* Check for 2 things here.
>> + 1.  There is no duplication of variable in allocate clause.
>> + 2.  Variable in allocate clause are also present in some
>> + privatization clase (non-composite case).  */
>> +  for (n = omp_clauses->lists[OMP_LIST_ALLOCATE]; n; n = n->next)
>> +n->sym->omp_allocate_clause = 0;
>> +
>> +  gfc_omp_namelist *prev = NULL;
>> +  for (n = omp_clauses->lists[OMP_LIST_ALLOCATE]; n;)
>> +{
>> +  if (n->sym->omp_allocate_clause == 1)
>> +{
>> +  gfc_warning (0, "%qs appears more than once in % "
>> +   "clauses at %L" , n->sym->name, >where);
>> +  /* We have already seen this variable so it is a duplicate.
>> + Remove it.  */
>> +  if (prev != NULL && prev->next == n)
>> +{
>> +  prev->next = n->next;
>> +  n->next = NULL;
>> +  gfc_free_omp_namelist (n, 0);
>> +  n = prev->next;
>> +}
>> +  continue;
>> +}
>> +  n->sym->omp_allocate_clause = 1;
>> +  prev = n;
>> +  n = n->next;
>> +}
>> +
>> +  /* non-composite constructs.  */
>> +  if (code && code->op < EXEC_OMP_DO_SIMD)
>> +{
>> +  for (list = 0; list < OMP_LIST_NUM; list++)
>> +switch (list)
>> +{
>> +  case OMP_LIST_PRIVATE:
>> +  case OMP_LIST_FIRSTPRIVATE:
>> +  case OMP_LIST_LASTPRIVATE:
>> +  case OMP_LIST_REDUCTION:
>> +  case OMP_LIST_REDUCTION_INSCAN:
>> +  case OMP_LIST_REDUCTION_TASK:
>> +  case OMP_LIST_IN_REDUCTION:
>> +  case OMP_LIST_TASK_REDUCTION:
>> +  case OMP_LIST_LINEAR:
>> +for (n = omp_clauses->lists[list]; n; n = n->next)
>> +  n->sym->omp_allocate_clause = 0;
>> +break;
>> +  default:
>> +break;
>> +}
>> +
>> +  for (n = omp_clauses->lists[OMP_LIST_ALLOCATE]; n; n = n->next)
>> +if (n->sym->omp_allocate_clause == 1)
>> +  gfc_error ("%qs specified in 'allocate' clause at %L but not "
>> + "in an explicit privatization clause",
>> + n->sym->name, >where);
>> +}
>> +}
> 
> Do you really need a new omp_allocate_clause bit?  From what I can see,
> other code uses n->sym->mark for such purposes (temporarily marking some
> symbols).

Done.

> Also, I think allocate clause like the privatization clauses should allow
> common blocks and I see code that uses the marks uses something like:
>   for (list = OMP_LIST_TO; list != OMP_LIST_NUM;
>list = (list == OMP_LIST_TO ? OMP_LIST_LINK : OMP_LIST_NUM))
> for (n = c->lists[list]; n; n = n->next)
>   if (n->sym)
> n->sym->mark = 0;
>   else if (n->u.common->head)
> n->u.common->head->mark = 0;
> So, a question is if the above won't just crash if I specify
>   firstprivate(/foobar/) allocate(/foobar/)

[Bug c++/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
Before GCC 12 we had:
{.name=TARGET_EXPR ...

In GCC 12 we get:
<<< Unknown tree: expr_stmt
  D.31068.name = TARGET_EXPR 

[Bug c/103980] -Wdouble-promotion triggers on s390x when it shouldn't.

[rmaguire314 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Ryan  ---
(In reply to Andrew Pinski from comment #1)
> Does it happen with a cross compiler or just a native compiler?

Not sure what you mean by that.
I'm emulating s390x on a Debian 11 amd64 machine via debootstrap:

sudo debootstrap --arch=s390x stable S390X

I chroot into it:

sudo chroot S390X/

I then install the following from Debian's repository:

apt-get install gcc git sudo

I'm writing an implementation of libm for fun.
Tried building the library with gcc with a bunch of flags to check for errors:

STDVER="-std=c89"
...
ExtraArgs=""
...
CArgs1="-pedantic -Wall -Wextra -Wpedantic -Wmissing-field-initializers"
CArgs2="-Wconversion -Wmissing-prototypes -Wmissing-declarations"
CArgs3="-Winit-self -Wnull-dereference -Wwrite-strings -Wdouble-promotion"
CArgs4="-Wfloat-conversion -Wstrict-prototypes -Wold-style-definition"
CArgs5="-I../ -DNDEBUG -g -fPIC -O3 -flto -c"
CompilerArgs="$STDVER $ExtraArgs $CArgs1 $CArgs2 $CArgs3 $CArgs4 $CArgs5"

The library builds but throws -Wdouble-promotion every time a float (single
precision) comparison is made. Removing the -std=c89 flag removes this warning,
which is strange. No issues on any other architectures. I've tried mips,
mipsel, mips64el, i386, arm64, armel, armhf, and amd64. All Debian via
debootstrap. I've also tried using LLVM's clang, pcc, and tcc (again, from
Debian's repositories, and when available since those compilers don't support
as many architectures) using the same arguments above. No warnings or errors on
any of them.

[Bug c++/103984] New: [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0

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

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

Bug ID: 103984
   Summary: [12 regression] Possible maybe-uninitialized false
positive on shaderc-2021.0
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Noticed new warning on shaderc-2021.0 which uses -Werror. Last week's gcc-12
snapshot did not flag it as a warning. Here is the extracted example:

// $ cat glslc/src/main.cc
#include 
#include 
#include 

struct string_piece {
  const char * begin_ = nullptr;
  const char * end_   = nullptr;
  std::string str() const { return std::string(begin_, end_); }

  string_piece(const char* string) : begin_(string), end_(string) {
end_ += strlen(string);
  }

  string_piece(const string_piece& other) {
begin_ = other.begin_;
end_ = other.end_;
  }
};


struct Z { std::string name; int stage; };
extern int to_stage(string_piece file_name);

int main(int argc, char** argv) {
  std::vector input_files;
  const std::string current_entry_point_name("main");
  const string_piece arg = argv[0];

  input_files.emplace_back(Z{
  arg.str(), // what is the lifetime of this temporary?
  to_stage(arg), // why does this constructor matter?
  });

  return 0;
}

$ g++-12.0.0 -O1 -Wall -Werror -std=c++11  -o main.cc.o -c glslc/src/main.cc

In file included from /<>/gcc-12.0.0/include/c++/12.0.0/string:53,
 from glslc/src/main.cc:1:
In member function 'std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::pointer std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_data()
const [with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]',
inlined from 'bool std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_is_local() const [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]' at
/<>/gcc-12.0.0/include/c++/12.0.0/bits/basic_string.h:275:23,
inlined from 'void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_dispose() [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator]' at
/<>/gcc-12.0.0/include/c++/12.0.0/bits/basic_string.h:286:18,
inlined from 'std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::~basic_string() [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator]' at
/<>/gcc-12.0.0/include/c++/12.0.0/bits/basic_string.h:793:19,
inlined from 'int main(int, char**)' at glslc/src/main.cc:35:1:
/<>/gcc-12.0.0/include/c++/12.0.0/bits/basic_string.h:235:28: error:
'.Z::name.std::__cxx11::basic_string::_M_dataplus.std::__cxx11::basic_string::_Alloc_hider::_M_p'
may be used uninitialized [-Werror=maybe-uninitialized]
  235 |   { return _M_dataplus._M_p; }
  |^~~~
glslc/src/main.cc: In function 'int main(int, char**)':
glslc/src/main.cc:32:3: note: '' declared here
   32 |   });
  |   ^
cc1plus: all warnings being treated as errors

$ g++-12.0.0 -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-12.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-12.0.0/libexec/gcc/x86_64-unknown-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20220109 (experimental) (GCC)

Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

[Harald Anlauf via Gcc-patches]

Hi FX,

Am 11.01.22 um 23:04 schrieb FX via Fortran:

Hi Harald,


I think this patch breaks the testsuite


On what platform? It regtested fine on x86_64-pc-linux-gnu


I looked at gcc-testresults and find e.g.

https://gcc.gnu.org/pipermail/gcc-testresults/2022-January/747938.html
https://gcc.gnu.org/pipermail/gcc-testresults/2022-January/747935.html

which is x86 (64 and 32 bit) by H.J.; plus some more.

Maybe H.J. can explain what is different from your platform?




since the directive
! { dg-additional-sources signaling_1_c.c }
should rather read
! { dg-additional-sources "signaling_1_c.c" }


I find plenty of evidence saying it’s allowed (just quoting a few, but there 
are a lot):

./gfortran.dg/PR94331.f90:! { dg-additional-sources PR94331.c }
./gfortran.dg/global_vars_c_init.f90:! { dg-additional-sources 
global_vars_c_init_driver.c }
./gfortran.dg/c_char_tests.f03:! { dg-additional-sources c_char_driver.c }


FX


Harald

Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

[FX via Gcc-patches]

Hi Harald,

> I think this patch breaks the testsuite

On what platform? It regtested fine on x86_64-pc-linux-gnu


> since the directive
> ! { dg-additional-sources signaling_1_c.c }
> should rather read
> ! { dg-additional-sources "signaling_1_c.c" }

I find plenty of evidence saying it’s allowed (just quoting a few, but there 
are a lot):

./gfortran.dg/PR94331.f90:! { dg-additional-sources PR94331.c }
./gfortran.dg/global_vars_c_init.f90:! { dg-additional-sources 
global_vars_c_init_driver.c }
./gfortran.dg/c_char_tests.f03:! { dg-additional-sources c_char_driver.c }


FX

Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

[Harald Anlauf via Gcc-patches]

Hi FX,

Am 02.01.22 um 11:50 schrieb FX via Fortran:

Hi,

This is the first part of a three-patch series to fix PR 82207 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle 
signaling NaNs. This part fixes the library code implementing IEEE_CLASS, by 
using the issignaling macro (from TS 18661-1:2014) to check whether a NaN is 
signalling.

The patch comes with a testcase, conditional on issignaling support (which will 
therefore run on glibc targets), which uses C built-ins to generate signaling 
NaNs and checks in Fortran code that they are classified and behave as expected.

Once this is in, the next two parts are:

- Add support for generating signaling NaNs in IEEE_VALUE, which is a longer 
patch because it requires moving the IEEE_VALUE library code from Fortran to C 
(but will be much more efficient and correct than the current implementation).
- Provide a fallback implementation of issignaling on targets that don’t have 
it.


Bootstrapped and regtested on x86_64-pc-gnu-linux. OK to commit?

FX



I think this patch breaks the testsuite, since the directive
! { dg-additional-sources signaling_1_c.c }

should rather read

! { dg-additional-sources "signaling_1_c.c" }

At least this is similar what I see in other testcases.

Harald

Re: [power-ieee128, committed] Enable conversion selection via environment variable

[Thomas Koenig via Gcc-patches]

On 11.01.22 14:19, Jakub Jelinek via Fortran wrote:

On Mon, Jan 10, 2022 at 11:44:13PM +0100, Thomas Koenig wrote:

Hello world,

I have just pushed the attched patch to the branch.


Thanks.

Here is a patch to fix up the ppc64be vs. ppc64le byteswapping
of IBM extended real(kind=16) and complex(kind=16).
Similarly to the BT_COMPLEX case it halves size and doubles nelems
for the bswap_array calls.  Of course for r16_ibm and r16_ieee conversions
one needs to make sure it is only done when the on file data is in that
format and not in IEEE quad.



The patch is OK.


So... time to merge the branch into trunk before stage 4
kicks in?


IMHO yes.  We need to git merge master; git rebase of course
before trying to cherry-pick those commits into trunk and pushing there.


I would prefer if somebody else did this - my lack of git-fu would
forseeably lead to some unforseen problems :-)


Best regards

Thomas

Re: [PATCH] Use enclosing object size if it's smaller than member [PR 101475]

[Jason Merrill via Gcc-patches]

On 12/16/21 14:56, Martin Sebor via Gcc-patches wrote:

Enabling vectorization at -O2 caused quite a few tests for
warnings to start failing in GCC 12.  These tests were xfailed
and bugs were opened to track the problems until they can be
fully analyzed and ultimately fixed before GCC 12 is released.

I've now started going through these and the first such bug
I tackled is PR 102944.  As it turns out, the xfails there
are all due to a known limitation tracked in PR 101475: when
determining the size of a destination for A COMPONENT_REF,
unless asked for the size of the complete object,
compute_objsize() only considers the size of the referenced
member, even when the member is larger than the object would
allow.  This prevents warnings from diagnosing unvectorized
past-the-end accesses to objects in backing buffers (such as
in character arrays or allocated chunks of memory).

Many (though not all) accesses that are vectorized are diagnosed
because there the COMPONENT_REF is replaced by a MEM_REF.  But
because vectorization depends on target-specific things like
alignment requirements, what is and isn't diagnosed also tends
to be target-specific, making these tests quite brittle..

The attached patch corrects this oversight by using the complete
object's size instead of the member when the former is smaller.
Besides improving the out-of-bounds access detection it also
makes the tests behave more consistently across targets.

Tested on x86_64-linux and by building Glibc and verifying
that the change triggers no new warnings.



+  /* Unconditionally determine the size of the base object (it could
+ be smaller than the referenced member).  */


This comment could use a mention of the backing buffer case.  OK with 
that change.


Jason

[Bug c/103980] -Wdouble-promotion triggers on s390x when it shouldn't.

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #4 from joseph at codesourcery dot com  ---
Possible the way x86 excess precision promotes to long double means this 
is only an issue for s390 excess precision (if it is an excess precision 
issue).

[Bug libstdc++/102807] Simple code using ranges::views::keys does not compile with clang

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||unlvsur at live dot com

--- Comment #6 from Jonathan Wakely  ---
*** Bug 103982 has been marked as a duplicate of this bug. ***

[Bug libstdc++/103982] std::ranges::subrange does not work for clang

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED
   See Also||https://github.com/llvm/llv
   ||m-project/issues/44178

--- Comment #3 from Jonathan Wakely  ---
Dup of PR 102807, which is due to a clang bug:
https://github.com/llvm/llvm-project/issues/44178

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

[Bug fortran/83079] ICE in gfc_widechar_to_char, at fortran/scanner.c:198

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
   Keywords||wrong-code
 Status|NEW |ASSIGNED

--- Comment #6 from anlauf at gcc dot gnu.org ---
Patch posted: https://gcc.gnu.org/pipermail/fortran/2022-January/057352.html

[PATCH] PR fortran/83079 - ICE and wrong code with TRANSFER and character(kind=4)

[Harald Anlauf via Gcc-patches]

Dear Fortranners,

when digging into the issue pointed out in the PR by Gerhard it turned
out that there were several issues with the TRANSFER intrinsics in the
case MOLD was CHARACTER(kind=4).  Default CHARACTER was fine, though.

- the size of the result was wrongly calculated
- the string length used in temporaries was wrong
- the result characteristics was wrong

Fortunately, the few fixes were very local and needed only fix-ups of
the respective computations.

Since the details of which issue would show up seemed to depend on the
properties of a the arguments to TRANSFER, I wrote an extended testcase
which is a "hull" of what I used in debugging.

(The testcase was and can be cross-checked with the NAG compiler.)

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

From cb14e9a1975bc9d9d2f544c314a0820f68b8bdc7 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Tue, 11 Jan 2022 22:06:10 +0100
Subject: [PATCH] Fortran: fix ICE and wrong code with TRANSFER and
 CHARACTER(kind=4)

gcc/fortran/ChangeLog:

	PR fortran/83079
	* target-memory.c (gfc_interpret_character): Result length is
	in bytes and thus depends on the character kind.
	* trans-intrinsic.c (gfc_conv_intrinsic_transfer): Compute correct
	string length for the result of the TRANSFER intrinsic and for
	temporaries for the different character kinds.

gcc/testsuite/ChangeLog:

	PR fortran/83079
	* gfortran.dg/transfer_char_kind4.f90: New test.
---
 gcc/fortran/target-memory.c   |   2 +-
 gcc/fortran/trans-intrinsic.c |  17 ++-
 .../gfortran.dg/transfer_char_kind4.f90   | 115 ++
 3 files changed, 130 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/transfer_char_kind4.f90

diff --git a/gcc/fortran/target-memory.c b/gcc/fortran/target-memory.c
index af1c21047f6..9b5af8d1482 100644
--- a/gcc/fortran/target-memory.c
+++ b/gcc/fortran/target-memory.c
@@ -485,7 +485,7 @@ gfc_interpret_character (unsigned char *buffer, size_t buffer_size,

   result->value.character.string[result->value.character.length] = '\0';

-  return result->value.character.length;
+  return size_character (result->value.character.length, result->ts.kind);
 }


diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index aae34b06948..5821b2264ce 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -8531,7 +8531,8 @@ gfc_conv_intrinsic_transfer (gfc_se * se, gfc_expr * expr)
 {
 case BT_CHARACTER:
   tmp = size_of_string_in_bytes (arg->expr->ts.kind, argse.string_length);
-  mold_type = gfc_get_character_type_len (arg->expr->ts.kind, tmp);
+  mold_type = gfc_get_character_type_len (arg->expr->ts.kind,
+	  argse.string_length);
   break;
 case BT_CLASS:
   tmp = gfc_class_vtab_size_get (argse.expr);
@@ -8633,7 +8634,13 @@ gfc_conv_intrinsic_transfer (gfc_se * se, gfc_expr * expr)

   se->expr = info->descriptor;
   if (expr->ts.type == BT_CHARACTER)
-se->string_length = fold_convert (gfc_charlen_type_node, dest_word_len);
+{
+  tmp = fold_convert (gfc_charlen_type_node,
+			  TYPE_SIZE_UNIT (gfc_get_char_type (expr->ts.kind)));
+  se->string_length = fold_build2_loc (input_location, TRUNC_DIV_EXPR,
+	   gfc_charlen_type_node,
+	   dest_word_len, tmp);
+}

   return;

@@ -8687,7 +8694,11 @@ scalar_transfer:
   gfc_add_expr_to_block (>post, tmp);

   se->expr = tmpdecl;
-  se->string_length = fold_convert (gfc_charlen_type_node, dest_word_len);
+  tmp = fold_convert (gfc_charlen_type_node,
+			  TYPE_SIZE_UNIT (gfc_get_char_type (expr->ts.kind)));
+  se->string_length = fold_build2_loc (input_location, TRUNC_DIV_EXPR,
+	   gfc_charlen_type_node,
+	   dest_word_len, tmp);
 }
   else
 {
diff --git a/gcc/testsuite/gfortran.dg/transfer_char_kind4.f90 b/gcc/testsuite/gfortran.dg/transfer_char_kind4.f90
new file mode 100644
index 000..5f1fe691318
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/transfer_char_kind4.f90
@@ -0,0 +1,115 @@
+! { dg-do run }
+! PR fortran/83079 - ICE and wrong code with TRANSFER and character(kind=4)
+! Exercise TRANSFER intrinsic to check character result length and shape
+
+program p
+  implicit none
+  character(len=*,kind=4), parameter :: a = 4_'ABCDEF'
+  character(len=6,kind=4):: b = 4_'abcdef'
+  character(len=*,kind=4), parameter :: c = 4_'XY'
+  character(len=2,kind=4):: d = 4_'xy'
+  integer :: k, l
+  k = len (a)
+  l = len (c)
+
+! print *, transfer(4_'xy', [4_'a'])
+
+  ! TRANSFER with rank-0 result
+  call chk0 (transfer (4_'ABCD', 4_'XY'), 2, 1)
+  call chk0 (transfer (4_'ABCD', c ), l, 2)
+  call chk0 (transfer (4_'ABCD', d ), l, 3)
+  call chk0 (transfer (a   , 4_'XY'), 2, 4)
+  call chk0 (transfer (a   , c ), l, 5)
+  call chk0 (transfer (a   , d ), l, 6)
+  call chk0 (transfer (b   , 4_'XY'), 2, 7)
+  call chk0 (transfer (b   , c 

[Bug libstdc++/103982] std::ranges::subrange does not work for clang

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

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

--- Comment #2 from Andrew Pinski  ---
Reduced testcase:
#include

void f(int *a, int *b)
{
auto t = std::ranges::subrange(a,b);
}

Re: [PATCH] libstdc++: Avoid overflow in bounds checks [PR103955]

[Jonathan Wakely via Gcc-patches]

On Tue, 11 Jan 2022 at 20:03, Patrick Palka via Libstdc++ <
libstd...@gcc.gnu.org> wrote:

> We currently crash when the floating-point to_chars overloads are passed
> a precision value near INT_MAX, ultimately due to overflow in the bounds
> checks that verify the output range is large enough.
>
> The most portable fix seems to be to replace bounds checks of the form
> A >= B + C (where B + C may overflow) with the otherwise equivalent check
> A >= B && A - B >= C, which is what this patch implements.
>
> Before we could do this in __floating_to_chars_hex, there we first need
> to track the unbounded "excess" precision (i.e. the number of trailing
> digits in the output that are guaranteed to be '0') separately from the
> bounded "effective" precision (i.e. the number of significant fractional
> digits in the output), like we do in __floating_to_chars_precision.
>
> Tested on x86_64 and i686, does this look OK for trunk/11?
>

OK for both, thanks.


> PR libstdc++/103955
>
> libstdc++-v3/ChangeLog:
>
> * src/c++17/floating_to_chars.cc (__floating_to_chars_hex):
> Track the excess precision separately from the effective
> precision.  Avoid overflow in bounds check by splitting it into
> two checks.
> (__floating_to_chars_precision): Avoid overlflow in bounds
> checks similarly.
> * testsuite/20_util/to_chars/103955.cc: New test.
> ---
>  libstdc++-v3/src/c++17/floating_to_chars.cc   | 46 +--
>  .../testsuite/20_util/to_chars/103955.cc  | 31 +
>  2 files changed, 64 insertions(+), 13 deletions(-)
>  create mode 100644 libstdc++-v3/testsuite/20_util/to_chars/103955.cc
>
> diff --git a/libstdc++-v3/src/c++17/floating_to_chars.cc
> b/libstdc++-v3/src/c++17/floating_to_chars.cc
> index c825a3c8b24..6cd92553d05 100644
> --- a/libstdc++-v3/src/c++17/floating_to_chars.cc
> +++ b/libstdc++-v3/src/c++17/floating_to_chars.cc
> @@ -747,7 +747,8 @@ template
>  __glibcxx_assert(shortest_full_precision >= 0);
>
>  int written_exponent = unbiased_exponent;
> -const int effective_precision =
> precision.value_or(shortest_full_precision);
> +int effective_precision = precision.value_or(shortest_full_precision);
> +int excess_precision = 0;
>  if (effective_precision < shortest_full_precision)
>{
> // When limiting the precision, we need to determine how to round
> the
> @@ -794,6 +795,11 @@ template
>   }
>   }
>}
> +else
> +  {
> +   excess_precision = effective_precision - shortest_full_precision;
> +   effective_precision = shortest_full_precision;
> +  }
>
>  // Compute the leading hexit and mask it out from the mantissa.
>  char leading_hexit;
> @@ -816,26 +822,30 @@ template
>  // Now before we start writing the string, determine the total length
> of
>  // the output string and perform a single bounds check.
>  int expected_output_length = sign + 1;
> -if (effective_precision != 0)
> -  expected_output_length += strlen(".") + effective_precision;
> +if (effective_precision + excess_precision > 0)
> +  expected_output_length += strlen(".");
> +expected_output_length += effective_precision;
>  const int abs_written_exponent = abs(written_exponent);
>  expected_output_length += (abs_written_exponent >= 1 ?
> strlen("p+d")
>: abs_written_exponent >= 1000 ?
> strlen("p+")
>: abs_written_exponent >= 100 ?
> strlen("p+ddd")
>: abs_written_exponent >= 10 ?
> strlen("p+dd")
>: strlen("p+d"));
> -if (last - first < expected_output_length)
> +if (last - first < expected_output_length
> +   || last - first - expected_output_length < excess_precision)
>return {last, errc::value_too_large};
> +char* const expected_last = first + expected_output_length +
> excess_precision;
>
> -const auto saved_first = first;
>  // Write the negative sign and the leading hexit.
>  if (sign)
>*first++ = '-';
>  *first++ = leading_hexit;
>
> +if (effective_precision + excess_precision > 0)
> +  *first++ = '.';
> +
>  if (effective_precision > 0)
>{
> -   *first++ = '.';
> int written_hexits = 0;
> // Extract and mask out the leading nibble after the decimal point,
> // write its corresponding hexit, and repeat until the mantissa is
> @@ -863,13 +873,18 @@ template
>   }
>}
>
> +if (excess_precision > 0)
> +  {
> +   memset(first, '0', excess_precision);
> +   first += excess_precision;
> +  }
> +
>  // Finally, write the exponent.
>  *first++ = 'p';
>  if (written_exponent >= 0)
>*first++ = '+';
>  const to_chars_result result = to_chars(first, last,
> written_exponent);
> -__glibcxx_assert(result.ec == errc{}
> -  

[Bug c/103980] -Wdouble-promotion triggers on s390x when it shouldn't.

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to jos...@codesourcery.com from comment #2)
> If it's specific to s390, I wonder if it's something to do with excess 
> precision being enabled by -std=c89 (see commit 
> a5dd6b69fcbe74c02d4821ac2daf2b8c9f819f6e regarding s390 excess precision, 
> but even if that means it doesn't appear by default with newer GCC on 
> s390, if it's an excess precision issue I'd expect it to appear also with 
> x86 -mfpmath=387).

Right, I tried it on x86 with "-m32 -Wdouble-promotion -std=c89 -mfpmath=387
-fexcess-precision=standard -mno-sse" and could not reproduce the failure which
is why I asked it was a native or cross compiler, trying to figure out if there
is a bug miscompiling the front-end or otherwise.

[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases

[amacleod at redhat dot com via Gcc-bugs]

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

Bug 68561 Summary: get_integer_range () that handles symbolical ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68561

   What|Removed |Added

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

[Bug tree-optimization/68561] get_integer_range () that handles symbolical ranges

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||amacleod at redhat dot com
 Status|NEW |RESOLVED

--- Comment #1 from Andrew Macleod  ---
I think this request is subsumed by the ranger work.

[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases

[amacleod at redhat dot com via Gcc-bugs]

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

Bug 76174 Summary: Missed VRP optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76174

   What|Removed |Added

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

[Bug middle-end/76174] Missed VRP optimization

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Macleod  ---
VN performs this optimization.

[Bug c/99131] gcc doesn't detect missing comma in array initialisation [-Wstring-concatenation]

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
Interestingly, I compiled fedora rawhide with clang and found
a whopping 247 cases of this warning across 11 packages.

[Bug c/66322] Linus Torvalds: -Wswitch-bool produces dubious warnings, fails to notice really bad things

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

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

[Bug c/103983] -Wswitch-bool seems to do nothing ?

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
The warning was tuned back on purpose because of a request from Linus. This is
a dup of bug 66322 which was that request.

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

[Bug c/103980] -Wdouble-promotion triggers on s390x when it shouldn't.

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #2 from joseph at codesourcery dot com  ---
If it's specific to s390, I wonder if it's something to do with excess 
precision being enabled by -std=c89 (see commit 
a5dd6b69fcbe74c02d4821ac2daf2b8c9f819f6e regarding s390 excess precision, 
but even if that means it doesn't appear by default with newer GCC on 
s390, if it's an excess precision issue I'd expect it to appear also with 
x86 -mfpmath=387).

[Bug c/79049] Unknown escape sequence not correctly pointed out

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
There are two packages in Fedora where this warning occurs when
compiled by clang:

$ fgrep warning: fedora/pass268/202201*/*.out | fgrep Wunknown-escape-sequence
fedora/pass268/20220107/nco.spec.out:nco_lst_utl.c:38:47: warning: unknown
escape sequence '\.' [-Wunknown-escape-sequence]
fedora/pass268/20220110/safecopy.spec.out:safecopy.c:263:56: warning: unknown
escape sequence '\-' [-Wunknown-escape-sequence]
$ 

gcc doesn't seem to generate the warning.

[Bug c/103983] New: -Wswitch-bool seems to do nothing ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 103983
   Summary: -Wswitch-bool seems to do nothing ?
   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: ---

clang has a warning -Wswitch-bool. There are three cases of
it in Fedora rawhide. 

However, gcc doesn't say anything. See this code:

void g( int);

void f( bool b)
{
switch (b)
{
case false:
g( 1);
break;
case true:
g( 2);
break;
}   
}

$ /home/dcb/gcc/results/bin/gcc -c -O2 -Wall -Wextra -Wswitch-bool -pedantic
jan11b.cc
$ clang++ -g -O2 -Wall jan11b.cc
jan11b.cc:9:2: warning: switch condition has boolean value [-Wswitch-bool]
switch (b)
^   ~
1 warning generated.

[Bug libstdc++/103982] std::ranges::subrange does not work for clang

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
clang++ -v
clang version 14.0.0 (https://github.com/llvm/llvm-project.git
af931a51b98f318955fc0bec71f28929e6535619)
Target: x86_64-unknown-linux-gnu

[Bug libstdc++/103982] New: std::ranges::subrange does not work for clang

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 103982
   Summary: std::ranges::subrange does not work for clang
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

#include
#include

int main()
{
for(std::pair it_pair{};
auto e : std::ranges::subrange(it_pair.first,it_pair.second))
{

}
}

GCC accepts this code. However clang does not.

constraints not satisfied for alias template 'sentinel_t' [with _Range = const
std::ranges::subrange]
&& sized_sentinel_for,
  ^~

[Bug target/103981] powerpc64le: Wrong code generated for vec_cntlz_lsbb, vec_cnttz_lsbb

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

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

Bill Schmidt  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Target||powerpc64le-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-01-11
   Target Milestone|--- |12.0
   Keywords||wrong-code
 CC||bergner at gcc dot gnu.org,
   ||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #1 from Bill Schmidt  ---
Confirmed.  Need to review earlier releases for the same issue.

[Bug target/103981] New: powerpc64le: Wrong code generated for vec_cntlz_lsbb, vec_cnttz_lsbb

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

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

Bug ID: 103981
   Summary: powerpc64le: Wrong code generated for vec_cntlz_lsbb,
vec_cnttz_lsbb
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

Per the PVIPR documentation, vec_cntlz_lsbb should generate vctzlsbb for little
endian, and vclzlsbb for big endian.  vec_cnttz_lsbb should do the opposite. 
The little-endian code generation is incorrect for both.  Clang gets this
right, for what it's worth.

[Bug c/65253] add -Wmemsize-comparison

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
(In reply to David Binderman from comment #4)
> (In reply to David Binderman from comment #3)
> > Also happens in fedora rawhide, package gshutdown.
> 
> Also package openbox.

And package wise2.

[Bug c/103980] -Wdouble-promotion triggers on s390x when it shouldn't.

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Build||s390x-*-linux-gnu
   Keywords||diagnostic
   Host||s390x-*-linux-gnu
 Target||s390x-*-linux-gnu

--- Comment #1 from Andrew Pinski  ---
Does it happen with a cross compiler or just a native compiler?

Re: [PATCH] C++ P0482R6 char8_t: declare std::c8rtomb and std::mbrtoc8 if provided by the C library

[Tom Honermann via Gcc-patches]

On 1/10/22 4:38 PM, Jonathan Wakely wrote:

On Mon, 10 Jan 2022 at 21:24, Tom Honermann via Libstdc++
 wrote:

On 1/10/22 8:23 AM, Jonathan Wakely wrote:


On Sat, 8 Jan 2022 at 00:42, Tom Honermann via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:

 This patch completes implementation of the C++20 proposal P0482R6
 [1] by
 adding declarations of std::c8rtomb() and std::mbrtoc8() in
  if
 provided by the C library in .

 This patch addresses feedback provided in response to a previous
 patch
 submission [2].

 Autoconf changes determine if the C library declares c8rtomb and
 mbrtoc8
 at global scope when uchar.h is included and compiled with either
 -fchar8_t or -std=c++20. New
 _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_FCHAR8_T
 and _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20 configuration macros
 reflect the probe results. The  header declares these
 functions
 in the std namespace only if available and the _GLIBCXX_USE_CHAR8_T
 configuration macro is defined (by default it is defined if the C++20
 __cpp_char8_t feature test macro is defined)

 Patches to glibc to implement c8rtomb and mbrtoc8 have been
 submitted [3].

 New tests validate the presence of these declarations. The tests pass
 trivially if the C library does not provide these functions.
 Otherwise
 they ensure that the functions are declared when  is included
 and either -fchar8_t or -std=c++20 is enabled.

 Tested on Linux x86_64.

 libstdc++-v3/ChangeLog:

 2022-01-07  Tom Honermann  mailto:t...@honermann.net>>

 * acinclude.m4 Define config macros if uchar.h provides
 c8rtomb() and mbrtoc8().
 * config.h.in : Re-generate.
 * configure: Re-generate.
 * include/c_compatibility/uchar.h: Declare ::c8rtomb and
 ::mbrtoc8.
 * include/c_global/cuchar: Declare std::c8rtomb and
 std::mbrtoc8.
 * include/c_std/cuchar: Declare std::c8rtomb and std::mbrtoc8.
 * testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc:
 New test.
 *
 testsuite/21_strings/headers/cuchar/functions_std_fchar8_t.cc:
 New test.



Thanks, Tom, this looks good and I'll get it committed for GCC 12.

Thank you!

My only concern is that the new tests depend on an internal macro:

+#if _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20
+  using std::mbrtoc8;
+  using std::c8rtomb;

I prefer if tests are written as "user code" when possible, and not
using our internal macros. That isn't always possible, and in this
case would require adding new effective-target keyword to
testsuite/lib/libstdc++.exp just for use in these two tests. I don't
think we should bother with that.

I went with this approach solely due to my unfamiliarity with the test
system. I knew there should be a way to conditionally make the test
"pass" as unsupported or as an expected failure, but didn't know how to
go about implementing that. I don't mind following up with an additional
patch if such a change is desirable. I took a look at
testsuite/lib/libstdc++.exp and it looks like it may be pretty straight
forward to add effective-target support. It would probably be a good
learning experience for me. I'll prototype and report back.

Yes, it's very easy to do. Take a look at the
check_effective_target_blah procs in that file, especially the later
ones that use v3_check_preprocessor_condition. You can use that to
define an effective target keyword for any preprocessor condition
(such as the new macros you're adding).

Then the test can do:
// { dg-do compile { target blah } }
which will make it UNSUPPORTED if the effective target proc doesn't return true.
See https://gcc.gnu.org/onlinedocs/gccint/Selectors.html#Selectors for
the docs on target selectors.

I'm just not sure it's worth adding a new keyword for just two tests.


Thank you for the implementation direction; this was quite easy!

Patch attached (to be applied after the original one).

libstdc++-v3/ChangeLog:

2022-01-11  Tom Honermann  

* testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc:
Modify to use new c8rtomb_mbrtoc8_cxx20 effective target.
* testsuite/21_strings/headers/cuchar/functions_std_fchar8_t.cc:
Modify to use new c8rtomb_mbrtoc8_fchar8_t effective target.
* testsuite/lib/libstdc++.exp: Add new effective targets.

If you decide that the new keywords aren't worth adding, no worries; my 
feelings won't be hurt :)


Tom.

commit 0542361fe8cb5da146097f86ca8ea8bca86421e0
Author: Tom Honermann 
Date:   Tue Jan 11 14:57:51 2022 -0500

Add effective target support for tests of C++20 c8rtomb and mbrtoc8.

diff --git a/libstdc++-v3/testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc b/libstdc++-v3/testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc
index 7c152ed42b5..681c12127db 100644
--- 

[PATCH] libstdc++: Avoid overflow in bounds checks [PR103955]

[Patrick Palka via Gcc-patches]

We currently crash when the floating-point to_chars overloads are passed
a precision value near INT_MAX, ultimately due to overflow in the bounds
checks that verify the output range is large enough.

The most portable fix seems to be to replace bounds checks of the form
A >= B + C (where B + C may overflow) with the otherwise equivalent check
A >= B && A - B >= C, which is what this patch implements.

Before we could do this in __floating_to_chars_hex, there we first need
to track the unbounded "excess" precision (i.e. the number of trailing
digits in the output that are guaranteed to be '0') separately from the
bounded "effective" precision (i.e. the number of significant fractional
digits in the output), like we do in __floating_to_chars_precision.

Tested on x86_64 and i686, does this look OK for trunk/11?

PR libstdc++/103955

libstdc++-v3/ChangeLog:

* src/c++17/floating_to_chars.cc (__floating_to_chars_hex):
Track the excess precision separately from the effective
precision.  Avoid overflow in bounds check by splitting it into
two checks.
(__floating_to_chars_precision): Avoid overlflow in bounds
checks similarly.
* testsuite/20_util/to_chars/103955.cc: New test.
---
 libstdc++-v3/src/c++17/floating_to_chars.cc   | 46 +--
 .../testsuite/20_util/to_chars/103955.cc  | 31 +
 2 files changed, 64 insertions(+), 13 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/20_util/to_chars/103955.cc

diff --git a/libstdc++-v3/src/c++17/floating_to_chars.cc 
b/libstdc++-v3/src/c++17/floating_to_chars.cc
index c825a3c8b24..6cd92553d05 100644
--- a/libstdc++-v3/src/c++17/floating_to_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_to_chars.cc
@@ -747,7 +747,8 @@ template
 __glibcxx_assert(shortest_full_precision >= 0);
 
 int written_exponent = unbiased_exponent;
-const int effective_precision = 
precision.value_or(shortest_full_precision);
+int effective_precision = precision.value_or(shortest_full_precision);
+int excess_precision = 0;
 if (effective_precision < shortest_full_precision)
   {
// When limiting the precision, we need to determine how to round the
@@ -794,6 +795,11 @@ template
  }
  }
   }
+else
+  {
+   excess_precision = effective_precision - shortest_full_precision;
+   effective_precision = shortest_full_precision;
+  }
 
 // Compute the leading hexit and mask it out from the mantissa.
 char leading_hexit;
@@ -816,26 +822,30 @@ template
 // Now before we start writing the string, determine the total length of
 // the output string and perform a single bounds check.
 int expected_output_length = sign + 1;
-if (effective_precision != 0)
-  expected_output_length += strlen(".") + effective_precision;
+if (effective_precision + excess_precision > 0)
+  expected_output_length += strlen(".");
+expected_output_length += effective_precision;
 const int abs_written_exponent = abs(written_exponent);
 expected_output_length += (abs_written_exponent >= 1 ? 
strlen("p+d")
   : abs_written_exponent >= 1000 ? strlen("p+")
   : abs_written_exponent >= 100 ? strlen("p+ddd")
   : abs_written_exponent >= 10 ? strlen("p+dd")
   : strlen("p+d"));
-if (last - first < expected_output_length)
+if (last - first < expected_output_length
+   || last - first - expected_output_length < excess_precision)
   return {last, errc::value_too_large};
+char* const expected_last = first + expected_output_length + 
excess_precision;
 
-const auto saved_first = first;
 // Write the negative sign and the leading hexit.
 if (sign)
   *first++ = '-';
 *first++ = leading_hexit;
 
+if (effective_precision + excess_precision > 0)
+  *first++ = '.';
+
 if (effective_precision > 0)
   {
-   *first++ = '.';
int written_hexits = 0;
// Extract and mask out the leading nibble after the decimal point,
// write its corresponding hexit, and repeat until the mantissa is
@@ -863,13 +873,18 @@ template
  }
   }
 
+if (excess_precision > 0)
+  {
+   memset(first, '0', excess_precision);
+   first += excess_precision;
+  }
+
 // Finally, write the exponent.
 *first++ = 'p';
 if (written_exponent >= 0)
   *first++ = '+';
 const to_chars_result result = to_chars(first, last, written_exponent);
-__glibcxx_assert(result.ec == errc{}
-&& result.ptr == saved_first + expected_output_length);
+__glibcxx_assert(result.ec == errc{} && result.ptr == expected_last);
 return result;
   }
 
@@ -1250,7 +1265,8 @@ template
}
 
// Copy the string from the buffer over to the output range.
-   if (last - first < output_length + 

[Bug c/103980] New: -Wdouble-promotion triggers on s390x when it shouldn't.

[rmaguire314 at gmail dot com via Gcc-bugs]

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

Bug ID: 103980
   Summary: -Wdouble-promotion triggers on s390x when it
shouldn't.
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rmaguire314 at gmail dot com
  Target Milestone: ---

The file bug.c:

#include 

int main(void)
{
float x = 1.0F;

if (x == 0.0F)
puts("Hi!");

return 0;
}

Build with:
gcc -Wdouble-promotion bug.c -o test

No errors.

Build with:
gcc -Wdouble-promotion -std=c89 bug.c -o test

Produces:
bug.c: In function 'main':
bug.c:7:11: warning: implicit conversion from 'float' to 'double' to
match other operand of binary expression [-Wdouble-promotion]
7 | if (x == 0.0F)

This only occurs on the s390x architecture. arm64 and amd64 work normally.
I'm running Debian 11 s390x version via emulating and chroot (host is amd64).
GCC version:
gcc (Debian 10.2.1-6) 10.2.1 20210110

Re: reordering of trapping operations and volatile

[Martin Uecker via Gcc]

Am Dienstag, den 11.01.2022, 10:13 +0100 schrieb Richard Biener:
> On Tue, Jan 11, 2022 at 9:17 AM Martin Uecker  wrote:
> > Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener:
> > > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker  wrote:
> > > > Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener:

...
> Consider
> 
> int a[1024];
> void foo (volatile int *p, float *q)
> {
>for (int i = 0; i < 1024; ++i)
>   {
>  *p = 1;
>  a[i] = *q;
>   }
> }
> 
> we happily apply invariant motion to the load from *q, making
> it cross the store to the volatile object at *p.  Now, q might be
> NULL upon entry to the function and thus this transform
> would violate the volatile "I/O" constraint (since I/O is observable)
> and thus we will crash (which is UB) before doing the first I/O.
> 
> That's an example I'd consider important for performance and
> also a case that shows that usually the compiler will have a
> very hard time proving UB cannot happen (as opposed to the
> usual stance where it can assume it doesn't).

I can see that the transformation in general is important,
but why is it important if the "volatile" is there?

I would assume that performance-sensitive code usually
does not volatile. 

Or in other words, what is the purpose of volatile in 
this example if not either I/O or to prevent such
optimizations?

> The case we run into sth similar is with use of uninitialized
> variables where proving some variable is initialized is nearly
> impossible (copy initialization from a variable that is not
> initialized is not initialization).

These are the C++ rules.

For C, an automatic variables which is not initialized and
(as long as the address is not taken), it is directly UB.


> We've mainly settled to the stance that only program termination
> is observable which means if we do not know that a function
> call will always return normally we have to avoid hoisting
> observable UB across such function call (and I/O routines
> usually fall into this category because they are not annotated
> as always returning). 

Yes.

>  Handling all volatile accesses in the
> very same way would be possible but quite some work I don't
> see much value in.

I see some value. 

But an alternative could be to remove volatile
from the observable behavior in the standard
or make it implementation-defined whether it
is observable or not.

Martin


> Richard.
> 
> > Martin
> > 
> > > > > > I am trying to figure out whether this is feasible.
> > > > > 
> > > > > For PRE yes, you'd just need to include the observable stmts you
> > > > > care in the set of stmts that cause PRE to set BB_MAY_NOTRETURN.
> > > > > In general this is of course harder.
> > > > 
> > > > What other passes would need to be checked?
> > > 
> > > All that do code motion by design or by accident.  The difficulty is
> > > that the resulting "wrong IL" is not wrong per se, just the difference is
> > > which is hard to write a checker for (well, in priciple you could copy the
> > > IL before passes and compare to the IL after)
> > > 
> > > > And do you think there is any negative impact on
> > > > an important optimization (considering this affects
> > > > only volatile accesses)?
> > > 
> > > Probably not.  But then semantics of 'volatile' are very weak defined
> > > so I'd like
> > > to see a reference to a part of the standard that supports declaring this
> > > (and only this - the 'volatile' case) a bug.
> > > 
> > > > > > > GCC assumes by default that divide is trappable but stores not 
> > > > > > > are not
> > > > > > > observable. This is where -fnon-call-exceptions come into play.
> > > > > > 
> > > > > > Ok, thanks! I will look at this!
> > > > > > 
> > > > > > > In the second case, GCC assumes reducing trappable instructions 
> > > > > > > are
> > > > > > > fine.
> > > > > > 
> > > > > > -fnon-call-exceptions would treat trapping instructions
> > > > > > as defined (and trapping) instead of UB? This is
> > > > > > then probably even stronger than the requirement above.
> > > > > 
> > > > > No, I don't think it turns UB into defined behavior.  Some frontends 
> > > > > might
> > > > > expect that to some extent.  So even with -fnon-call-exceptions we'd
> > > > > happily do the re-ordering unless the exception is catched in the same
> > > > > function.
> > > > 
> > > > Thanks,
> > > > Martin
> > > > 
> > > > > > > Note I thought -fno-delete-dead-exceptions would fix the sink
> > > > > > > but it didn't.
> > > > > > 
> > > > > > Martin
> > > > > > 
> > > > > > 

[PATCH] tree-optimization/103551 - Always set EDGE_EXECUTABLE in ranger vrp.

[Andrew MacLeod via Gcc-patches]

The simplify_and_fold engine uses the EDGE_EXECUTABLE flag to eliminate 
branches:


substitute_and_fold_dom_walker::before_dom_children:

 if (gimple_code (stmt) == GIMPLE_COND)
    {
  if ((EDGE_SUCC (bb, 0)->flags & EDGE_EXECUTABLE)
  ^ (EDGE_SUCC (bb, 1)->flags & EDGE_EXECUTABLE))

... but if certain passes before VRP2 are turned off, the flag can be in 
an uninitialized state upon entry to VRP2.  This patch simply always 
sets EDGE_EXECUTABLE on all edges before invoking ranger and the S engine.


Bootstraps on  x86_64-pc-linux-gnu with no regressions.

OK for trunk?

Andrew





commit 09934a28871701f3cef5175c2a510cd09ec13836
Author: Andrew MacLeod 
Date:   Tue Jan 11 09:59:21 2022 -0500

Always set EDGE_EXECUTABLE in VRP2.

PR tree-optimization/103551
* tree-vrp.c (execute_ranger_vrp): Always set EDGE_EXECUTABLE.

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 804f3171ccc..62946450b13 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -4332,6 +4332,7 @@ execute_ranger_vrp (struct function *fun, bool warn_array_bounds_p)
   scev_initialize ();
   calculate_dominance_info (CDI_DOMINATORS);
 
+  set_all_edges_as_executable (fun);
   gimple_ranger *ranger = enable_ranger (fun);
   rvrp_folder folder (ranger);
   folder.substitute_and_fold ();

[Bug target/103973] x86: 4-way comparison of floats/doubles with spaceship operator possibly suboptimal

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

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

--- Comment #7 from Jakub Jelinek  ---
Perhaps add a new starship3 optab for it and pattern recognize it in
gimple_isel?  Though that would most likely handle just the 0, -1, 1, 2 case
that <=> emits and not say other constants that one could get e.g. with the
(much less likely):
#include 
int cmp4way(double a, double b)
{
auto c = a <=> b;
if (c == std::partial_ordering::equivalent) return 42;
if (c == std::partial_ordering::less) return 137;
if (c == std::partial_ordering::unordered) return -35;
return 139;
}

[Bug preprocessor/96935] [9 Regression] ICE in subspan, at input.h:69

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||10.3.0, 11.1.0
   Target Milestone|--- |10.3
  Known to fail||10.1.0, 10.2.0

[Bug target/103973] x86: 4-way comparison of floats/doubles with spaceship operator possibly suboptimal

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #5)
> We are lowering this to
> 
> return  = TARGET_EXPR  != SAVE_EXPR  ?
> SAVE_EXPR  < SAVE_EXPR  ? less : SAVE_EXPR  < SAVE_EXPR  ?
> greater : unordered : equivalent>>>;
> 
> I don't think we can elide the first ucomisd, but we should be able to CSE
> the last (from the original quoted assembler), not sure if it ultimatively
> results in better code though.

Why we couldn't do that?  It is true that GIMPLE starts with != comparison that
shouldn't raise exceptions if a or b is qNaN, but if one or both of the
operands is qNaN, then they will compare unequal and < comparison that should
raise exceptions if a or b is qNaN is done.
So, it would be nice if we could at gimple_isel or expansion or later pattern
recognize this and emit optimal code for it.

C testcase:
int
foo (double a, double b)
{
  if (a == b)
return 0;
  if (a < b)
return -1;
  if (a > b)
return 1;
  return 2;
}

We should have something like:
comisd %xmm0, %xmm1
jp 1f
movl $0, %eax
jne 2f
3:
ret
2:
sbbl %eax, %eax
andl $2, %eax
subl $1, %eax
ret
1:
movl $2, %eax
ret

Re: [PATCH v4 2/3] rs6000: Support SSE4.1 "round" intrinsics

[David Edelsohn via Gcc-patches]

Suppress exceptions (when specified), by saving, manipulating, and
restoring the FPSCR.  Similarly, save, set, and restore the floating-point
rounding mode when required.

No attempt is made to optimize writing the FPSCR (by checking if the new
value would be the same), other than using lighter weight instructions
when possible. Note that explicit instruction scheduling "barriers" are
added to prevent floating-point computations from being moved before or
after the explicit FPSCR manipulations.  (That these are required has
been reported as an issue in GCC: PR102783.)

The scalar versions naively use the parallel versions to compute the
single scalar result and then construct the remainder of the result.

Of minor note, the values of _MM_FROUND_TO_NEG_INF and _MM_FROUND_TO_ZERO
are swapped from the corresponding values on x86 so as to match the
corresponding rounding mode values in the Power ISA.

Move implementations of _mm_ceil* and _mm_floor* into _mm_round*, and
convert _mm_ceil* and _mm_floor* into macros. This matches the current
analogous implementations in config/i386/smmintrin.h.

Function signatures match the analogous functions in config/i386/smmintrin.h.

Add tests for _mm_round_pd, _mm_round_ps, _mm_round_sd, _mm_round_ss,
modeled after the very similar "floor" and "ceil" tests.

Include basic tests, plus tests at the boundaries for floating-point
representation, positive and negative, test all of the parameterized
rounding modes as well as the C99 rounding modes and interactions
between the two.

Exceptions are not explicitly tested.

2021-10-18  Paul A. Clarke  

gcc
* config/rs6000/smmintrin.h (_mm_round_pd, _mm_round_ps,
_mm_round_sd, _mm_round_ss, _MM_FROUND_TO_NEAREST_INT,
_MM_FROUND_TO_ZERO, _MM_FROUND_TO_POS_INF, _MM_FROUND_TO_NEG_INF,
_MM_FROUND_CUR_DIRECTION, _MM_FROUND_RAISE_EXC, _MM_FROUND_NO_EXC,
_MM_FROUND_NINT, _MM_FROUND_FLOOR, _MM_FROUND_CEIL, _MM_FROUND_TRUNC,
_MM_FROUND_RINT, _MM_FROUND_NEARBYINT): New.
* config/rs6000/smmintrin.h (_mm_ceil_pd, _mm_ceil_ps, _mm_ceil_sd,
_mm_ceil_ss, _mm_floor_pd, _mm_floor_ps, _mm_floor_sd, _mm_floor_ss):
Convert from function to macro.

gcc/testsuite
* gcc.target/powerpc/sse4_1-round3.h: New.
* gcc.target/powerpc/sse4_1-roundpd.c: New.
* gcc.target/powerpc/sse4_1-roundps.c: New.
* gcc.target/powerpc/sse4_1-roundsd.c: New.
* gcc.target/powerpc/sse4_1-roundss.c: New.

Okay.

Thanks, David

[Bug bootstrap/103974] [12 Regression] ICE in ira_flattening building libstdc++ with r12-6415-g01f3e6a40e72

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
Fixed.

[Bug bootstrap/103974] [12 Regression] ICE in ira_flattening building libstdc++ with r12-6415-g01f3e6a40e72

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r12-6490-gdb8d94a0570dc1f3de10c9eb9fe6e91df804272b
Author: Richard Sandiford 
Date:   Tue Jan 11 19:24:59 2022 +

ira: Fix old-reload targets [PR103974]

The new IRA heuristics would need more work on old-reload targets,
since flattening needs to be able to undo the cost propagation.
It's doable, but hardly seems worth it.

This patch therefore makes all the new calls to
ira_subloop_allocnos_can_differ_p return false if !ira_use_lra_p.
The color_pass code that predated the new function (and that was
the source of ira_subloop_allocnos_can_differ_p) continues to
behave as before.

It's a hack, but at least it has the advantage that the new parameter
would become obviously unused if reload and (!)ira_use_lra_p were
removed.  The hack should therefore disappear alongside reload.

gcc/
PR rtl-optimization/103974
* ira-int.h (ira_subloop_allocnos_can_differ_p): Take an
extra argument, default true, that says whether old-reload
targets should be excluded.
* ira-color.c (color_pass): Pass false.

Re: [PATCH 0/2]: C N2653 char8_t implementation

[Tom Honermann via Gcc-patches]

On 1/10/22 9:23 PM, Joseph Myers wrote:

Please repost these patches after GCC 12 branches (updated as appropriate
depending on whether the feature is accepted at the two-week Jan/Feb WG14
meeting, which doesn't yet have an agenda), since we're currently
stabilizing for the release and so not considering new features.


Thank you, Joseph. Will do!

Tom.

[Bug tree-optimization/99966] Bounds check not eliminated by assert

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #2 from Andrew Macleod  ---
looking at VRP2:
the initial assert provides:

Relational : (start_4(D) < end_5(D))
Relational : (_16 > start_4(D))
Relational : (end_5(D) <= _16)


unfortunately, the loop back edge is:
i_12 = i_17 + 1;
if (end_5(D) != i_12)
  goto ; [89.00%]
else
  goto ; [11.00%]

so it only registers what it knows from the branch:
Relational : (i_12 != end_5(D))

so when it gets to the bounds check at:
if (i_12 >= _16)
  goto ; [0.04%]
else
  goto ; [99.96%]

It doesn't really know the answer.  If the loop branch had remained
if (i_12 < end_5) instead of being changed, then we would instead get the
relation:
Relational : (i_12 < end_5(D))
which combined with the earlier Relational : (end_5(D) <= _16), should register
 the transitive relation (i_12 < _16), and enable removal of the check.

This is transformed in ivopts, which runs after vrp1.  A quick check shows at
VRP1 time, the bounds are still using the < format...

In fact...  running with --param=vrp1-mode=ranger registers this exact
transitive relation, and produces:

Relational : (i_2 < _16)
Relational : (i_2 < end_5(D))
 [local count: 952547451]:
if (0 != 0)
  goto ; [0.04%]
else
  goto ; [99.96%]

and eliminates the bounds check.

So we can close this PR when we turn ranger on by default for VRP1.

[Bug rtl-optimization/103979] asm goto is not considered volatile with output operands

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|asm goto is not considered  |asm goto is not considered
   |volatile|volatile with output
   ||operands
   Last reconfirmed||2022-01-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code,
   ||inline-asm, wrong-code
  Component|c   |rtl-optimization

--- Comment #1 from Andrew Pinski  ---
I suspect the code was not updated once output operands were allowed to have it
marked as volatile. As inline-asm without output operands is always considered
volatile.

[Bug c++/101681] PMF comparison to nullptr is not considered a constexpr inside a template argument

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|PMF comparison to nullptr   |PMF comparison to nullptr
   |is not considered a |is not considered a
   |constexpr   |constexpr inside a template
   ||argument

--- Comment #4 from Andrew Pinski  ---
Note completeness of the class does not matter either:
template  struct Z { };
struct C
{
void f();
};
static_assert ((::f == 0) == false,"");
Z<::f == 0> z;

--- CUT ---
The static_assert passes just fine but the template is still rejected.