[Bug c++/102975] Local alias diagnosed as unused when used in failing constraint

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

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

--- Comment #1 from Andrew Pinski  ---
Hmm, this is interesting:
template concept Never = false;
template concept C = Never;
void f() {
  struct X {
   // using type = int;
  };
  static_assert(not C);
}

is able to compile. I don't know enough about C++ concepts to say if this is
valid or not but it looks like the type is really unused in the above case ...
This is different from "constexpr bool" which requires the type to be defined
...

[Bug c++/96441] ICE in tree check: expected integer_cst, have cond_expr in get_len, at tree.h:5954

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |trivial

[Bug c++/102995] Template friend class declaration of same class with different template parameters fails to allow private methods access

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> I suspect the original testcase is invalid code and clang is incorrect in
> accepting it.

You can limit the friendship to only the operator== that have the same second
template operand if you need to limit the friendship slightly more:
template class First {
  public:
First() = default;

  private:
int GetId() const {
  return 1;
}
template
friend bool operator==(const First& lhs,
   const First& rhs);
};
template
bool operator==(const First& lhs,
const First& rhs) {
 return lhs.GetId() == rhs.GetId();
   }
int main() {
  First a;
  First b;

  return a == b;
}

[Bug c++/102995] Template friend class declaration of same class with different template parameters fails to allow private methods access

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

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

--- Comment #2 from Andrew Pinski  ---
This works correctly on all compilers to do what you want it to do:
template class First {
  public:
First() = default;

  private:
int GetId() const {
  return 1;
}

template
friend bool operator==(const First& lhs,
   const First& rhs);
};
template
bool operator==(const First& lhs,
const First& rhs) {
 return lhs.GetId() == rhs.GetId();
   }

int main() {
  First a;
  First b;

  return a == b;
}

Because you need the operator

I suspect the original testcase is invalid code and clang is incorrect in
accepting it.

[Bug c++/102995] Template friend class declaration of same class with different template parameters fails to allow private methods access

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

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

--- Comment #1 from Andrew Pinski  ---
Are you sure this is valid?  Both ICC and MSVC reject it for the same reason as
GCC.

Can a friend of First be made a friend of First via the friend, I
don't think so?

[Bug libgcc/103004] [12 regression] breaks lots on powerpc BE

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
   Target Milestone|--- |12.0

[Bug target/103010] Extra move to x0 for non-POD returns

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

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

--- Comment #1 from Andrew Pinski  ---
Note clang produces:
b   _Z2llv

Which is exactly what I would have expected.

[Bug target/103010] New: Extra move to x0 for non-POD returns

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

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

Bug ID: 103010
   Summary: Extra move to x0 for non-POD returns
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take the following C++ code:
void ll() noexcept(true);
struct k {
  ~k() noexcept(true);
};
k ice(k *a)
{
  k v;
  ll();
  return v;
}
 CUT 
Currently GCC produces:
stp x29, x30, [sp, -32]!
mov x29, sp
str x19, [sp, 16]
mov x19, x8
bl  _Z2llv
mov x0, x19
ldr x19, [sp, 16]
ldp x29, x30, [sp], 32

But the ABI does say x0 need to be set here at all.
So really the call to _Z2llv could even be a tail call.

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

[townsend at astro dot wisc.edu via Gcc-bugs]

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

Rich Townsend  changed:

   What|Removed |Added

 CC||townsend at astro dot wisc.edu

--- Comment #11 from Rich Townsend  ---
I can confirm this issue on macOS 12.0.1 and gcc/gfortran 10.2.

[Bug tree-optimization/102988] ICE with -fharden-conditional-branches and C++ and pass by reference return value

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Confirmed, reduced testcase the most I could do:
void ll();
struct k {
  ~k();
};
k ice(k *a)
{
  k v;
  if (!= a)
ll();
  return v;
}

[Bug tree-optimization/103007] [12 Regression] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Confirmed, reduced to:
typedef float MushMeshVector[4];
struct MushMeshQuaternionPair {
  void VectorRotate(MushMeshVector &);
  MushMeshVector m_first;
  MushMeshVector m_second;
};
void 
MushMeshQuaternionPair::
VectorRotate(MushMeshVector )  {
  ioVec[2] = (2 - m_first[1] + m_first[3] * 0);
  ioVec[3] = (m_first[3] + m_first[1] - m_first[2] * 0);
  float c = ioVec[2], d = ioVec[3];
  ioVec[2] = (0 - d * m_second[1]);
  ioVec[3] = (2 - c * m_second[1]);
}

[Bug tree-optimization/103007] [12 Regression] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug target/96892] [ARM]Wrong __stack_chk_guard for comparison

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||sylw.bar at gmail dot com

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

[Bug target/103009] [9 only] Weakness in stack-protector with no-pie active on ARM.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug target/96892] [ARM]Wrong __stack_chk_guard for comparison

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|10.4|10.3

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> Fixed in GCC 10.4 by r10-8823

Sorry 10.3.0

[Bug target/96892] [ARM]Wrong __stack_chk_guard for comparison

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|11.0|10.4
   Keywords||wrong-code

--- Comment #7 from Andrew Pinski  ---
Fixed in GCC 10.4 by r10-8823

[Bug target/96892] [ARM]Wrong __stack_chk_guard for comparison

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #6 from Andrew Pinski  ---
(In reply to John Dong from comment #5)
> Fixed after e94797250b403d66cb3624a594e41faf0dd76617

r11-3427

[Bug rtl-optimization/103006] [9/10/11/12 Regression] wrong code at -O1 or -O2 on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |rtl-optimization
   Keywords||ra

--- Comment #3 from Andrew Pinski  ---
This looks like a Register allocator issue.
IN GCC 6 we have:
.L8:
movq%rsp, b(%rip)
movq%rsp, 48(%rsp)
call_Z2ffv
movq112(%rsp), %rax
addq$160, %rsp
.cfi_def_cfa_offset 8
ret

While in GCC 7+ we get:
movl$2, f(%rip)
movl$6, e(%rip)
movq%rsp, b(%rip)
movq%rsp, 48(%rsp)
call_Z2ffv
movl48(%rsp), %eax
addq$96, %rsp
.cfi_def_cfa_offset 8
ret

[Bug d/102837] [12 regression] Many 32-bit gdc tests FAIL

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #5 from Iain Buclaw  ---
Testing this patch.

--- a/libphobos/libdruntime/gcc/deh.d
+++ b/libphobos/libdruntime/gcc/deh.d
@@ -207,7 +207,7 @@ struct ExceptionHeader
  */
 static void free(ExceptionHeader* eh) @nogc
 {
-*eh = ExceptionHeader.init;
+__builtin_memset(eh, 0, ExceptionHeader.sizeof);
 if (eh != )
 __builtin_free(eh);
 }

[Bug middle-end/103006] [9/10/11/12 Regression] wrong code at -O1 or -O2 on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11/12 Regression]
   |wrong code at -O2 (only) on |wrong code at -O1 or -O2 on
   |x86_64-linux-gnu|x86_64-linux-gnu
  Component|tree-optimization   |middle-end
  Known to fail||8.1.0
   Target Milestone|--- |9.5
   Keywords||wrong-code

--- Comment #2 from Andrew Pinski  ---
Since noipa does not work with GCC 7, the following fails all the back to GCC
7:

__attribute__((noipa,noinline,noclone)) void ff(void){asm("":::"memory");}
int a, *b, c, e, f;
__attribute__((always_inline))
static inline void g() {
  int *d[7];
  d[6] = b = (int *)d;
  ff();
}
__attribute__((noinline))
int i() {
  for (c = 0; c < 2; c++) {
long h[6][2];
for (e = 0; e < 6; e++)
  for (f = 0; f < 2; f++)
h[e][f] = 1;
if (c) {
  g();
  return h[3][0];
}
  }
  return 0;
}
int main() {
  if (i() != 1)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/103006] [9/10/11/12 Regression] wrong code at -O2 (only) on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed, here is one which is broken at -O1 and -O2 but ok at -O3:

__attribute__((noipa)) void ff(void){}
int a, *b, c, e, f;
__attribute__((always_inline))
static inline void g() {
  int *d[7];
  d[6] = b = (int *)d;
  ff();
}
__attribute__((noinline))
int i() {
  for (c = 0; c < 2; c++) {
long h[6][2];
for (e = 0; e < 6; e++)
  for (f = 0; f < 2; f++)
h[e][f] = 1;
if (c) {
  g();
  return h[3][0];
}
  }
  return 0;
}
int main() {
  if (i() != 1)
__builtin_abort ();
  return 0;
}

[Bug middle-end/102972] [OpenMP] Strictly-nested diagnostic missing

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

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

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

https://gcc.gnu.org/g:948d461954f2642ca187f86c19d297ba7a86320f

commit r12-4809-g948d461954f2642ca187f86c19d297ba7a86320f
Author: Tobias Burnus 
Date:   Sat Oct 30 23:45:32 2021 +0200

OpenMP: Add strictly nested API call check [PR102972]

The teams construct only permits omp_get_num_teams and omp_get_team_num
as API call in strictly nested regions - check for it.

Additionally, for Fortran, using DECL_NAME does not show the mangled
name, hence, DECL_ASSEMBLER_NAME had to be used to.

Finally, 'target device(ancestor:1)' wrongly rejected non-API calls
as well.

PR middle-end/102972
gcc/ChangeLog:

* omp-low.c (omp_runtime_api_call): Use DECL_ASSEMBLER_NAME to get
internal Fortran name; new permit_num_teams arg to permit
omp_get_num_teams and omp_get_team_num.
(scan_omp_1_stmt): Update call to it, add missing call for
reverse offload, and check for strictly nested API calls in teams.

gcc/testsuite/ChangeLog:

* c-c++-common/gomp/target-device-ancestor-3.c: Add non-API
routine test.
* gfortran.dg/gomp/order-6.f90: Add missing bind(C).
* c-c++-common/gomp/teams-3.c: New test.
* gfortran.dg/gomp/teams-3.f90: New test.
* gfortran.dg/gomp/teams-4.f90: New test.

libgomp/ChangeLog:
* testsuite/libgomp.c-c++-common/icv-3.c: Nest API calls inside
parallel construct.
* testsuite/libgomp.c-c++-common/icv-4.c: Likewise.
* testsuite/libgomp.c/target-3.c: Likewise.
* testsuite/libgomp.c/target-5.c: Likewise.
* testsuite/libgomp.c/target-6.c: Likewise.
* testsuite/libgomp.c/target-teams-1.c: Likewise.
* testsuite/libgomp.c/teams-1.c: Likewise.
* testsuite/libgomp.c/thread-limit-2.c: Likewise.
* testsuite/libgomp.c/thread-limit-3.c: Likewise.
* testsuite/libgomp.c/thread-limit-4.c: Likewise.
* testsuite/libgomp.c/thread-limit-5.c: Likewise.
* testsuite/libgomp.fortran/icv-3.f90: Likewise.
* testsuite/libgomp.fortran/icv-4.f90: Likewise.
* testsuite/libgomp.fortran/teams1.f90: Likewise.

[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #15 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582945.html

[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope

[gerald at pfeifer dot com via Gcc-bugs]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #14 from Gerald Pfeifer  ---
(In reply to H.J. Lu from comment #13)
> Please try this.

Thank you, H.J., and sorry it took me to run tests since I ran into
unrelated problems.

Good news: with your patch GCC is back to bootstrap on FreeBSD!


(Will you apply this to GCC and push it upstream to libsanitizer?)

[Bug c/103009] Weakness in stack-protector with no-pie active on ARM.

[sylw.bar at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Sylwester Baranski  ---
Created attachment 51711
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51711=edit
Save-temps output

[Bug target/103008] poor inlined builtin_fmod on x86_64

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
There's a mixture of single and double precision in the testcase variants.
I haven't checked thoroughly enough if both variants are really equivalent.

Do you see the issue if you have only single or only double precision?

[Bug c/103009] New: Weakness in stack-protector with no-pie active on ARM.

[sylw.bar at gmail dot com via Gcc-bugs]

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

Bug ID: 103009
   Summary: Weakness in stack-protector with no-pie active on ARM.
   Product: gcc
   Version: 9.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sylw.bar at gmail dot com
  Target Milestone: ---

Created attachment 51710
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51710=edit
Test program

During development for very space restricted Cortex-A5 based environment I
found potential weakness in stack-protector functionality in GCC 9.4.0.
Fortunatelly, I was able to reproduce problem using 32-bit Ubuntu Server 21.10
for Raspberry Pi (I used RPi4).
https://ubuntu.com/download/raspberry-pi

The problem: Not appropriate content of canary value put on the stack when
stack-protector is enabled and -fno-pie active.

In theory, for security reasons, the canary value should be randomly generated. 
During my development I realized that in my system the canary is constant and
holds address of __stack_chk_guard hidden variable.
The __stack_chk_guard variable is internal stack-protector variable that holds
random value that should be copied to tested function stack.
I prepared simple program that extracts real value of canary copied on test()
function stack.
The canary is hidden but it is located right after 12-byte buffer. I'm using
out of bound index in main() to extract canary which type is uintptr_t.

Important fact is that problem occurs when -fno-pie is set.
Here is test.c program:

#include 
#include 
#define BUF_LEN 12
extern uintptr_t __stack_chk_guard;

uintptr_t test(int idx)
{
   unsigned char buffer[BUF_LEN];
   return *((uintptr_t*)[idx]);
}

int main()
{
   printf("__stack_chk_guard: &%x = %x\n", (int)&__stack_chk_guard,
__stack_chk_guard);
   uintptr_t canary = test(BUF_LEN);
   printf("canary: %x\n", canary);
   return 0;
}

System: 32-bit Ubuntu Server 21.10 for Raspberry Pi on RPI4 with additional
packets: gcc-9 gcc-10 gcc-11:

GCC 10&11 show correct result:
ubuntu@ubuntu:~/work$ gcc-11 -Os -fno-pie -fstack-protector-all test.c  -o test
ubuntu@ubuntu:~/work$ ./test
__stack_chk_guard:  = 90148100
canary: 90148100

ubuntu@ubuntu:~/work$ gcc-10 -Os -fno-pie -fstack-protector-all test.c  -o test
ubuntu@ubuntu:~/work$ ./test
__stack_chk_guard:  = 1642cf00
canary: 1642cf00

GCC 9.4 reveals that address of __stack_chk_guard was copied to canary:
ubuntu@ubuntu:~/work$ gcc-9 -Os -fno-pie -fstack-protector-all test.c  -o test
ubuntu@ubuntu:~/work$ ./test
__stack_chk_guard:  = 69229c00
canary: b6f85298

ubuntu@ubuntu:~/work$ gcc-9 -v
Using built-in specs.
COLLECT_GCC=gcc-9
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/9/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.4.0-3ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libitm --disable-libquadmath
--disable-libquadmath-support --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a
--with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror
--enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 9.4.0 (Ubuntu 9.4.0-3ubuntu1)

Summary.
1. Problem (potential) is reproducible on 9.3.0 and 9.4.0 with -fno-pie.
2. Problem not visible on: 10.3.0, 11.2.0
3. stack-protector functionality is working fine, but lack of randomness of
canary is security risk.

Attaching function test() assemblies compiled on 9.4 and 10.3.
There are visible differences between addressing __stack_chk_guard using r3
register.

10.3:

test:
@ args = 0, pretend = 0, frame = 16
@ frame_needed = 0, uses_anonymous_args = 0
push{r0, r1, r2, r3, r4, lr}
ldr r3, .L3
ldr r3, [r3]
str r3, [sp, #12]
...

.L3:
.word   __stack_chk_guard


9.4:

test:
@ args = 0, pretend = 0, frame = 16
@ frame_needed = 0, uses_anonymous_args = 0
push{r0, r1, r2, r3, r4, lr}
ldr r3, .L3
ldr r3, [r3]
str r3, [sp, #12]
...

.L3:
.word   .LC0
.LC0:
.word   __stack_chk_guard

[Bug target/103008] poor inlined builtin_fmod on x86_64

[fx at gnu dot org via Gcc-bugs]

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

--- Comment #4 from Dave Love  ---
On further consideration, perhaps this is just a Fortran issue.  I thought
-ffast-math should turn off all the relevant checks to allow reducing mod to
the arithmetic expression, but it probably doesn't.  Also, MAQAO complained
about x87 instructions being generated, but I'm not sure about that either if
it's just for status.  Apologies if this is invalid, and correction welcome.

[Bug c++/103007] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced C++ code seems to be:

template  class MushMeshVector {
public:
  MushMeshVector(float, float, float, float);
  float Z() {
float __trans_tmp_3;
int inIndex = 2;
__trans_tmp_3 = m_value[inIndex];
return __trans_tmp_3;
  }
  float W() {
float __trans_tmp_4;
int inIndex = 3;
__trans_tmp_4 = m_value[inIndex];
return __trans_tmp_4;
  }
  void ZSet(float inValue) {
int inIndex = 2;
m_value[inIndex] = inValue;
  }
  void WSet(float inValue) {
int inIndex = 3;
m_value[inIndex] = inValue;
  }
  float m_value[D];
};
template  class MushMeshQuaternion : MushMeshVector<4> {
public:
  void PreMultiplyVector(MushMeshVector &) const;
  void PostMultiplyVector(MushMeshVector &) const;
};
template 
void MushMeshQuaternion::PreMultiplyVector(MushMeshVector ) const {
  ioVec.ZSet(2 - m_value[1] + m_value[3] * 0);
  ioVec.WSet(m_value[3] + m_value[1] - m_value[2] * 0);
}
template 
void MushMeshQuaternion::PostMultiplyVector(MushMeshVector ) const {
  T c = ioVec.Z(), d = ioVec.W();
  ioVec.ZSet(0 - d * m_value[1]);
  ioVec.WSet(2 - c * m_value[1]);
}
template  class MushMeshQuaternionPair {
public:
  void VectorRotate(MushMeshVector<4> &) const;
  MushMeshQuaternion m_first;
  MushMeshQuaternion m_second;
};
template 
void MushMeshQuaternionPair::VectorRotate(MushMeshVector<4> ) const {
  m_first.PreMultiplyVector(ioVec);
  m_second.PostMultiplyVector(ioVec);
}
class MushMeshPosticity {
public:
  MushMeshQuaternionPair AngPos();
};
class MushGamePiece {
public:
  MushMeshPosticity Post();
  void PostWRef();
};
class AdanaxisPieceProjectile : MushGamePiece {
  void Move();
  float m_acceleration;
};
void AdanaxisPieceProjectile::Move() {
  MushMeshVector<4> accVec(0, 0, 0, m_acceleration);
  Post().AngPos().VectorRotate(accVec);
  PostWRef();
}

[Bug target/103008] poor inlined builtin_fmod on x86_64

[fx at gnu dot org via Gcc-bugs]

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

--- Comment #3 from Dave Love  ---
Created attachment 51709
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51709=edit
gglx.s extract

[Bug target/103008] poor inlined builtin_fmod on x86_64

[fx at gnu dot org via Gcc-bugs]

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

--- Comment #2 from Dave Love  ---
Created attachment 51708
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51708=edit
ggl.s extract

[Bug target/103008] poor inlined builtin_fmod on x86_64

[fx at gnu dot org via Gcc-bugs]

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

--- Comment #1 from Dave Love  ---
Created attachment 51707
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51707=edit
gglx.f90

[Bug target/103008] New: poor inlined builtin_fmod on x86_64

[fx at gnu dot org via Gcc-bugs]

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

Bug ID: 103008
   Summary: poor inlined builtin_fmod on x86_64
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fx at gnu dot org
  Target Milestone: ---
Target: x86_64

Created attachment 51706
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51706=edit
ggl.f90

This is from looking at a Fortran benchmark set
, but presumably
isn't Fortran-specific.

One of the cases in that set (ac.f90) gets bottlenecked on a random
number routine (which may be rubbish, but it's there).  It uses DMOD,
which gets compiled to __builtin_fmod according to the tree dump, and
is inlined.  However, the benchmark performance is still 50% worse
with gfortran than Intel ifort, and if I replace DMOD with its
definition, gfortran is much closer to ifort.

I'll attach files ggl.f90, the original, and gglx.f90 which avoids the
call to the intrinsic, along with assembler from each.  The assembler
is from GCC 11.2.0, run (on SKX) as

  gfortran -Ofast -march=native

(I note that the generated fmod isn't inlined with -O3, which looks to
me like a Fortran miss that I should report.)

I only take benchmarks too seriously for understanding the results
but, at least with PDO, GCC is pretty much on a par with ifort on the
bottom line of that set, despite also #40770, and another poor case. :-)

[Bug fortran/99853] ICE: Cannot convert 'LOGICAL(4)' to 'INTEGER(8)' (etc.)

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-12.

Thanks for the report!

[Bug c++/103007] New: ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 103007
   Summary: ice in vect_normalize_conj_loc, at
tree-vect-slp-patterns.c:722
   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: ---

Created attachment 51705
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51705=edit
gzipped C++ source code

The attached C++ code, with compiler flag -O2 -march=bdver2, does this:

during GIMPLE pass: slp
Adanaxis/AdanaxisPieceProjectile.cpp: In member function ‘virtual void
AdanaxisPieceProjectile::Move(MushGameLogic&, Mushware::tVal)’:
Adanaxis/AdanaxisPieceProjectile.cpp:123:1: internal compiler error: in
vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722
0x8f64ab vect_normalize_conj_loc
../../trunk.git/gcc/tree-vect-slp-patterns.c:722

The bug seems to start sometime between git hash b343a29dbcbfc5ea
and 70c947e4dfaa6d63.

I will have my usual go at reducing the code.

[Bug tree-optimization/102981] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

--- Comment #3 from Aldy Hernandez  ---
*** Bug 102895 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/102895] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE
 CC||law at gcc dot gnu.org,
   ||matz at gcc dot gnu.org

--- Comment #3 from Aldy Hernandez  ---
This is *almost* a duplicate of PR102981.

Here we have the same scenario: the first iteration of a loop has unreachable
code.  But interestingly, the IL is sufficiently simple that DOM3 (post
loopdone) can see the threading opportunity:

a.c.192t.dom3:  [3] Registering jump thread: (2, 3) incoming edge;  (3, 4)
normal;

but... there's some limitation in the custom block copier the old forward
threader uses:

a.c.192t.dom3:Failure in thread_through_loop_header:   Cancelling jump thread:
(2, 3) incoming edge;  (3, 4) normal;

Again, the backward threader will refuse to thread this, regardless of
loopdone, because it is essentially peeling off the first iteration of a loop. 
This is the main issue we should address, regardless of DOM's limitation.

I'm going to mark this as a duplicate, because I doubt anyone has the
inclination of fixing the old forward threader's copier.

[FWIW, this supersedes the previous comment I made for this PR, as the threader
pipeline has changed in trunk.]

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

[Bug middle-end/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526

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

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

--- Comment #1 from Aldy Hernandez  ---
Is this still an issue with the new jump threader?

[Bug tree-optimization/103006] New: wrong code at -O2 (only) on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 103006
   Summary: wrong code at -O2 (only) on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This is quite long-latent, affecting GCC 7.* and later.

[856] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211030 (experimental) [master r12-4804-g75c9fa318e3] (GCC)
[857] %
[857] % gcctk -O1 small.c; ./a.out
0
[858] % gcctk -O2 small.c
[859] % ./a.out
0
Aborted
[860] %
[860] % cat small.c
int printf(const char *, ...);
int a, *b, c, e, f;
void g() {
  int *d[7];
  d[6] = b = (int *)d;
  printf("0\n");
}
int i() {
  for (c = 0; c < 2; c++) {
long h[6][2];
for (e = 0; e < 6; e++)
  for (f = 0; f < 2; f++)
h[e][f] = 1;
if (c) {
  g();
  return h[3][0];
}
  }
  return 0;
}
int main() {
  if (i() != 1)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/102981] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org,
   ||matz at gcc dot gnu.org

--- Comment #2 from Aldy Hernandez  ---
I'm not sure what to do here.  Perhaps one of the loop experts can opine.

The threadable path starting at 2->11 could elide the call to foo(), but...

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

   [local count: 177158542]:
  # c_12 = PHI <0(2), c_11(10)>
  # d_13 = PHI <0(2), d_18(10)>
  if (d_13 != 2)
goto ; [66.67%]
  else
goto ; [33.33%]

The pre-loop threaders chose not to thread because it would destroy loop form. 
The late DOM pass can't even thread it, because the IL is too complex for it. 
The backward threader can easily see the candidate, but it has restrictions in
place specifically to avoid peeling the first iteration of loops (regardless of
loopdone):

  // This is like path_crosses_loops in profitable_path_p but more
  // restrictive, since profitable_path_p allows threading the
  // first block because it would be redirected anyhow.
  //
  // If we loosened the restriction and used profitable_path_p()
  // here instead, we would peel off the first iterations of loops
  // in places like tree-ssa/pr14341.c.

I'm not sure massaging the above conditional will ultimately fix this, since
the IL is sufficiently different, but that's the gist of it.

This seems to be a special case where the first iteration of a loop has
unreachable code, and the overly aggressives threaders in earlier GCC releases
could elide it early in the pipeline.

It also looks like a highly contrived testcase.  Does this happen enough in
real life that we should handle it?  If so, should we try harder in the
threader, or could another pass pick up the slack?

[Bug libstdc++/103005] New: experimental simd sin and cos with big arguments returns values bigger than 1

[andreas_roever at web dot de via Gcc-bugs]

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

Bug ID: 103005
   Summary: experimental simd sin and cos with big arguments
returns values bigger than 1
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andreas_roever at web dot de
  Target Milestone: ---

Created attachment 51704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51704=edit
example program displaying the problem

there seems to be a bug in the sin and cos functions for the experimental/simd
header.

When giving a very big argument to those functions they return values outside
the range -1 .. 1. I understand that the result will be quite meaningless for
such big values. But I'd argue that it should always be in the range -1..1.

so calculating sin(-2985064393126969344) gives 2527133379.389218


This is on Linux

compiled with

g++-11.2.0 -g -march=native --std=c++20 test1.cpp

here the CPU info (for one core)

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 94
model name  : Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
stepping: 3
microcode   : 0xc2
cpu MHz : 3301.335
cache size  : 6144 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 22
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch
cpuid_fault invpcid_single pti ibrs ibpb stibp tpr_shadow vnmi flexpriority ept
vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx
rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida
arat pln pts hwp hwp_notify hwp_act_window hwp_epp
vmx flags   : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb
flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple
shadow_vmcs pml
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds
swapgs taa itlb_multihit srbds
bogomips: 6399.96
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual

[Bug target/102993] -fcf-protection=full produces segfaulting code when targeting 32-bit x86 (i686)

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #8 from Eric Botcazou  ---
We should probably reject any fancy new feature with SJLJ C++ exceptions since
nobody supports or tests them, including -fcf-protection.

[Bug tree-optimization/103003] [12 regression] ice in set_relation, at value-relation.cc:592

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug libgcc/103004] New: [12 regression] breaks lots on powerpc BE

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

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

Bug ID: 103004
   Summary: [12 regression] breaks lots on powerpc BE
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

commit b7561b5d2443f1d5f54f5177f0fb1a13c4205856
Author: Raphael Moreira Zinsly 
Date:   Tue Oct 5 15:32:52 2021 -0300

libgcc: Add a backchain fallback to _Unwind_Backtrace() on PowerPC


It looks like this change broke most if not all the asan tests on powerpc64 BE,
a bunch of the go tests, and several more.

These are from a run on a powerpc64 BE power 8 machine:

previous run: g:b47490c572c5938f887b54240af6096a7c90f640, r12-4415
this run: g:b7561b5d2443f1d5f54f5177f0fb1a13c4205856, r12-4416

New failures:

FAIL: archive/tar
FAIL: archive/zip
FAIL: bufio
FAIL: bytes
FAIL: c-c++-common/asan/alloca_big_alignment.c   -O0  output pattern test
FAIL: c-c++-common/asan/alloca_big_alignment.c   -O1  output pattern test
FAIL: c-c++-common/asan/alloca_big_alignment.c   -O2  output pattern test
FAIL: c-c++-common/asan/alloca_big_alignment.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  output pattern test
FAIL: c-c++-common/asan/alloca_big_alignment.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/alloca_big_alignment.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/alloca_big_alignment.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_detect_custom_size.c   -O0  output pattern test
FAIL: c-c++-common/asan/alloca_detect_custom_size.c   -O1  output pattern test
FAIL: c-c++-common/asan/alloca_detect_custom_size.c   -O2  output pattern test
FAIL: c-c++-common/asan/alloca_detect_custom_size.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  output pattern test
FAIL: c-c++-common/asan/alloca_detect_custom_size.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/alloca_detect_custom_size.c   -O3 -g  output pattern
test
FAIL: c-c++-common/asan/alloca_detect_custom_size.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_partial.c   -O0  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_partial.c   -O1  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_partial.c   -O2  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_partial.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_partial.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_partial.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_partial.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_right.c   -O0  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_right.c   -O1  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_right.c   -O2  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_right.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_right.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_right.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_right.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_underflow_left.c   -O0  output pattern test
FAIL: c-c++-common/asan/alloca_underflow_left.c   -O1  output pattern test
FAIL: c-c++-common/asan/alloca_underflow_left.c   -O2  output pattern test
FAIL: c-c++-common/asan/alloca_underflow_left.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  output pattern test
FAIL: c-c++-common/asan/alloca_underflow_left.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/alloca_underflow_left.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/alloca_underflow_left.c   -Os  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -O0  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -O1  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -O2  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -Os  output pattern test
FAIL: c-c++-common/asan/halt_on_error-1.c   -O0  execution test
FAIL: c-c++-common/asan/halt_on_error-1.c   -O1  execution test
FAIL: c-c++-common/asan/halt_on_error-1.c   -O2  execution test
FAIL: c-c++-common/asan/halt_on_error-1.c   

[Bug fortran/99853] ICE: Cannot convert 'LOGICAL(4)' to 'INTEGER(8)' (etc.)

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r12-4802-gd18e4cc416b832fa98ca8af13b09cf7fe904ba8f
Author: Steve Kargl 
Date:   Sat Oct 30 18:22:19 2021 +0200

Fortran: generate regular error on invalid conversions of CASE expressions

gcc/fortran/ChangeLog:

PR fortran/99853
* resolve.c (resolve_select): Generate regular gfc_error on
invalid conversions instead of an gfc_internal_error.

gcc/testsuite/ChangeLog:

PR fortran/99853
* gfortran.dg/pr99853.f90: New test.

[Bug c/103003] ice in set_relation, at value-relation.cc:592

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |amacleod at redhat dot 
com
 CC||amacleod at redhat dot com
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-10-30
 Ever confirmed|0   |1

--- Comment #3 from Andrew Macleod  ---
Created attachment 51703
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51703=edit
proposed patch

we know the result is true, so we are trying to register a "<=" expression for:
  _10 = _4 <= _4;
If the 2 ssa names are the same, there is no need o register any relation. 
equality is implied, and nothign else makes sense.

Untested patch for now.

[Bug c/103003] ice in set_relation, at value-relation.cc:592

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
I am not sure why the #include is in there.

Further reduced code is

typedef char int8_t;
int8_t c_4, uli_5;
unsigned short us_6;
func_1() {
  int uli_9;
  short ptr_16ptr_11 = _9;
  for (; us_6 <= 6;)
if ((us_6 *= uli_9) < (uli_5 || 0) ?: ((c_4 = us_6) >= us_6) - uli_5)
  uli_9 = 9;
}

Flag -O2 required.

[Bug c/103003] ice in set_relation, at value-relation.cc:592

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced C code seems to be

 #include 
int8_t c_4, uli_5;
uint16_t us_6;
func_1() {
  int uli_9 = 0;
  uint64_t ptr_11 = uli_9 |= uli_5 != 0;
  uint16_t ptr_16ptr_11 = _9;
  for (; us_6 <= 6;)
if ((us_6 *= uli_9) < (ptr_11 || 0) ?: ((c_4 = us_6) >= us_6) - uli_5)
  for (uli_9 = 9; uli_9;)
;
}

[Bug c/103003] New: ice in set_relation, at value-relation.cc:592

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 103003
   Summary: ice in set_relation, at value-relation.cc:592
   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: ---

Created attachment 51702
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51702=edit
C source code

The attached C code with recent gcc trunk, does this:

bug767.c: In function ‘func_1’:
bug767.c:10:1: internal compiler error: in set_relation, at
value-relation.cc:592
   10 | func_1() {
  | ^~
0x1c97b0c path_oracle::register_relation(basic_block_def*, tree_code,
tree_node*, tree_node*)
../../trunk.git/gcc/value-relation.cc:0

The code first goes wrong sometime between git hash 22d34a2a50651d01
and ec0124e0acb556cd.

I will try to reduce the code.

[Bug target/102953] Improvements to CET-IBT and ENDBR generation

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #22 from H.J. Lu  ---
(In reply to Andrew Cooper from comment #21)
> Another possibly-bug, but possibly mis-expectations on my behalf.
> 
> I've found some code in the depths of Xen which is causing a failure on
> final link due to a missing `__x86_indirect_thunk_nt_rax` symbol.
> 
>   $ cat fnptr-typeof.c
>   extern void (*fnptrs[])(char);
> 
>   void foo(int a)
>   {
>   typeof(foo) *bar = (void *)fnptrs[0];
>   bar(a);
>   }
> 
> I realise this  is wildly undefined behaviour, and I will try to address it
> in due course.  However, the instruction generation is bizarre.
> 
> When I compile with -fcf-protection=branch -mmanual-endbr, I get a plain
> `jmp *fnptrs(%rip)` instruction.  (This is fine.)
> 
> When I compile with -fcf-check-attribute=no as well, then I get `notrack jmp
> *fnptrs(%rip)`.  I'm not sure why the notrack is warranted here; for all GCC
> knows, the target does have a suitable ENDBR64 instruction.
> 

>From "info gcc":

 The 'nocf_check' attribute on a type of pointer to function is used
 to inform the compiler that a call through the pointer should not
 be instrumented when compiled with the '-fcf-protection=branch'
 option.  The compiler assumes that the function's address from the
 pointer is a valid target for a control-flow transfer.  A direct
 function call through a function name is assumed to be a safe call
 thus direct calls are not instrumented by the compiler.

That is why notrack is added.

[Bug libstdc++/102994] std::atomic::wait is not marked const

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rodgertq at gcc dot 
gnu.org
   Keywords||rejects-valid
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-10-30

[Bug c++/15795] No way to teach operator new anything about alignment requirements

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

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

--- Comment #45 from Jonathan Wakely  ---
C++17 added support for dynamic allocation of over-aligned types, and requires
std::allocator to use it. User-defined allocators are not required to support
over-aligned types.

Before C++17 it was implementation-defined whether std:allocator supports them.
When using GCC they are supported when -faligned-new is used (which is the
default for C++17 and can be enabled for earlier modes if needed).

[Bug rtl-optimization/102842] [10/11/12 Regression] ICE in cselib_record_set at -O2 or greater

[herrtimson at yahoo dot de via Gcc-bugs]

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

tt_1  changed:

   What|Removed |Added

Summary|[10 Regression] ICE in  |[10/11/12 Regression] ICE
   |cselib_record_set at -O2 or |in cselib_record_set at -O2
   |greater |or greater
 Status|CLOSED  |REOPENED
 Resolution|FIXED   |---

--- Comment #14 from tt_1  ---
reopened, there is a new fix for this in trunk.

[Bug target/102986] [12 Regression] ICE: in expand_shift_1, at expmed.c:2671 with a negative shift of a vector

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #5 from Roger Sayle  ---
Patch proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582931.html

[Bug tree-optimization/102981] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #1 from Aldy Hernandez  ---
In the pre-loop threaders (ethread, thread1, threadfull1), we can't touch
anything because it would cross loops, but by threadfull2 we should be able to.

There's a threadable path starting at the 2->6 edge here:

 [local count: 118111600]:
  # c_21 = PHI 
  # ivtmp.16_8 = PHI 
  a.1_26 = a;
  if (a.1_26 < 0)
goto ; [89.00%]
  else
goto ; [11.00%]

but we don't because doing so would peel off an iteration.   Hmmm, this is
really old code.  I'm going to have to think about this:

  // This is like path_crosses_loops in profitable_path_p but more
  // restrictive, since profitable_path_p allows threading the
  // first block because it would be redirected anyhow.
  //
  // If we loosened the restriction and used profitable_path_p()
  // here instead, we would peel off the first iterations of loops
  // in places like tree-ssa/pr14341.c.

[Bug tree-optimization/102943] [12 Regression] VRP threader compile-time hog with 521.wrf_r

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

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

--- Comment #6 from Aldy Hernandez  ---
Can this be re-checked now that the forward threader has been dropped post-VRP?

BTW, please CC me on any compile-time hogs related to the threader, especially
if it's not SPEC related, as I've yet to hunt down a copy.  So far this is the
only non-duplicate PR I'm CC'ed on with the threader as a suspect in compile
speed.