[Bug rust/105913] gccrs doesn't compile on 32-bit targets

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Thomas Schwinge  ---
> But now really assuming fixed via additional
>  "Fix remaining misuses of format
> specifiers on 32-bit targets".

Now confirmed on both i386-pc-solaris2.11 and sparc-sun-solaris2.11
(which needs the hack from PR c++/106072).

[Bug tree-optimization/106114] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

--- Comment #6 from Zhendong Su  ---
Two additional recent miscompiles that are likedly related:

(1)

[638] % gcctk -O0 small.c; ./a.out
[639] % gcctk -O1 small.c
[640] % ./a.out
Aborted
[641] % cat small.c
int a, b;
int main() {
  int c = 0, d, e, f;
  for (e = 0; e < 3; e++) {
f = a;
if (!b)
  f = 1;
d = f;
  }
  if (d > 1 || d <= c)
__builtin_abort();
  return 0;
}


(2) 

[579] % gcctk -O1 small.c; ./a.out
[580] % gcctk -O2 small.c
[581] % timeout -s 9 5 ./a.out
Killed
[582] % cat small.c
int a, b, *c;
int f(int d, int e) { return !e || d && e == 1 ? 0 : d % e; }
int main() {
  int g = -4, h = -3;
  if (a)
h = b;
  while (h <= g || h > -1)
;
  if (f(1, a) > 3)
c = &h;
  return 0;
}

[Bug c++/106134] New: [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649

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

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

Bug ID: 106134
   Summary: [13 Regression] ICE in execute_todo, at passes.cc:2134
since r13-1204-gd68d366425369649
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr84136.c -Os
-funreachable-traps
during GIMPLE pass: local-pure-const
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr84136.c: In
function ‘main’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr84136.c:17:1:
internal compiler error: in execute_todo, at passes.cc:2140
   17 | }
  | ^
0x765840 execute_todo
/home/marxin/Programming/gcc/gcc/passes.cc:2140
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/106134] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-29

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

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

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

--- Comment #6 from Martin Liška  ---
(In reply to kargl from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > GCC 10.4 is being released, retargeting bugs to GCC 10.5.
> 
> That's a shame.  The patch in comment 1 and the correction
> noted in comment 2 where submitted 8 months ago.

So please test it and send to gcc-fortran mailing list :)

[Bug sanitizer/106132] ICE: in report_conflicting_sanitizer_options, at opts.cc:1011 with -fsanitize=thread,address,kernel-hwaddress

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-06-29

--- Comment #1 from Martin Liška  ---
Lemme fix that.

[Bug c++/106135] New: Found a bug in gcc

[85811545 at qq dot com via Gcc-bugs]

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

Bug ID: 106135
   Summary: Found a bug in gcc
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 85811545 at qq dot com
  Target Milestone: ---

This code will output wrong result when execute g++ code.cpp -o code -lm -O2
-DONLINE_JUDGE -std=c++11 using g++10.3.0, on Ubuntu 20.04，64bits. 


#include 
using namespace std;
vector>f;
int mg(pairx,pairy)
{
return max(x.second,y.second);
}
int main()
{
f={{0,-11}};
for(int J=0;J<=0;J++)
{
f[J]=f[0];
if(J==0)f[J]={0,2};
cout<

[Bug ipa/101279] Function attributes often block inlining

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

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

--- Comment #8 from Richard Biener  ---
(In reply to David Brown from comment #7)
> (In reply to rguent...@suse.de from comment #6)
> > Can you provide a specific example that you would allow this way?
> > 
> > 
> 
> I'd go back to my original example :
> 
> 
>   __attribute__((optimize("-fwrapv")))
>   static inline int wrapped_add(int a, int b) {
>   return a + b;
>   }
> 
>   int foo(int x, int y, int z) {
>   return wrapped_add(wrapped_add(x, y), z);
>   }
> 
> If you want to disable inlining of "wrapped_add" due to the change in the
> semantics of integer arithmetic, that's fair enough.  But if I /really/ want
> inlining, and write something like :
> 
>   __attribute__((optimize("-fwrapv"), always_inline))
>   static inline int wrapped_add(int a, int b) {
>   return a + b;
>   }
> 
> then I want the code treated as :
> 
>   return (__wrapping_int) a + (__wrapping_int) b;
> 
> or
> 
>   return __wrapping_add_int(a, b);
> 
> If the way gcc marks and handles "-fwrapv" arithmetic does not support
> something like that, which would allow inline mixing with other code, then
> that would result in a compiler warning or error message.

There is no way to do something like that for signed integer division because
the way GCC supports is using unsigned integer arithmetic and then an
unsigned to signed conversion.

GCC also currently does not support re-writing the inlined function
on-the-fly.

> It might be best to have a new attribute name here rather than using
> "always_inline" - I have not thought through the consequences.
> 
> It might also be that if the compiler can be changed to support inlining of
> a given optimisation attribute, then the attribute in question can be
> whitelisted for inlining for everyone.  I suppose what I am saying is that
> if the compiler can't be sure that inlining is safe, then it could be
> cautious by default while letting the programmer override that caution
> explicitly.

Indeed what we are missing is a diagnostic on the cases where always_inline
(or any other exception) overrides the explicit list of problematic
option mismatches.

For an example I was more looking into a case where there it is not one of
the explicitly rejected cases.  Like if people do

__attribute__((optimize("-fno-tree-pre")))
static inline int foo (...) { ... }

int bar (...) { ... foo (); ... }

there isn't a way to honor disabling PRE for the inlined code portion but
still enabling it for the code originating from bar.  So we can't fulfil
users expectation honoring the optimize attribute and inlining at the same
time.  Would you prioritize inlining here?  We most of the time prioritize
the 'optimize' attribute and -Winline diagnoses this fact.

[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p

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

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

--- Comment #7 from Richard Biener  ---
(In reply to Segher Boessenkool from comment #5)
> Thanks for tracking this down!
> 
> Interesting it survived so long.  We could use some RTL checking on this :-)

We have almost no "RTL IL checking", but surely having that would be nice
(like we have verify_gimple_*).

[Bug tree-optimization/106112] [10/11/12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r10-2711-g3ed01d5408045d80

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

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

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

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

commit r13-1341-g2dbb45d6dc0d20dc159b3d8e27ebb6825074827a
Author: Richard Biener 
Date:   Tue Jun 28 13:57:29 2022 +0200

tree-optimization/106112 - fix CSE from wider operation

The following fixes a mistake in looking up an extended operand
in the CSE of a truncated operation.

2022-06-28  Richard Biener  

PR tree-optimization/106112
* tree-ssa-sccvn.cc (valueized_wider_op): Properly extend
a constant operand according to its type.

* gcc.dg/torture/pr106112.c: New testcase.

[Bug sanitizer/106136] New: gcc-12.1.1 - libsanitizer fails when compiled for MIPS

[immoloism at googlemail dot com via Gcc-bugs]

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

Bug ID: 106136
   Summary: gcc-12.1.1 - libsanitizer fails when compiled for MIPS
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: immoloism at googlemail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 53222
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53222&action=edit
GCC Build.log

When cross compiling GCC-12.1.1 for my MIPS device it will always fail on the
libsanitizer section for a reason I can't find for the root cause for as of yet
so reporting in the hopes someone here will know what is causing it to fix.

The current workaround is to build with '--disable-libsanitizer'.

All flags used are included in the build.log for ease.

[Bug bootstrap/106137] New: baremetal cross builds broken in libgfortran since g:133d0d422ebd18dbd215cfa5394aff9f938e7060

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

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

Bug ID: 106137
   Summary: baremetal cross builds broken in libgfortran since
g:133d0d422ebd18dbd215cfa5394aff9f938e7060
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: aarch64-none-linux-gnu
Target: aarch64-none-elf

Cross builds fail with:

make[1]: [Makefile:1786: aarch64-none-elf/bits/largefile-config.h] Error 1
(ignored)
make[1]: [Makefile:1787: aarch64-none-elf/bits/largefile-config.h] Error 1
(ignored)
In file included from
/opt/buildAgent/work/ca23804305872d31/gcc-src/libgfortran/caf/libcaf.h:32,
 from
/opt/buildAgent/work/ca23804305872d31/gcc-src/libgfortran/caf/single.c:26:
/opt/buildAgent/work/ca23804305872d31/gcc-src/libgfortran/libgfortran.h:62:11:
fatal error: quadmath_weak.h: No such file or directory
   62 | # include "quadmath_weak.h"
  |   ^
compilation terminated.

But admittedly I don't understand why the change in the header which seems to
tighten the condition makes it fail now...

[Bug tree-optimization/106112] [10/11/12 Regression] wrong code at -Os and above on x86_64-linux-gnu since r10-2711-g3ed01d5408045d80

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||12.1.0
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] wrong
   |wrong code at -Os and above |code at -Os and above on
   |on x86_64-linux-gnu since   |x86_64-linux-gnu since
   |r10-2711-g3ed01d5408045d80  |r10-2711-g3ed01d5408045d80
  Known to work||13.0
   Priority|P3  |P2
   Keywords||wrong-code

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.

[Bug target/105938] [12/13 Regression] ICE in get_insn_temp late, at final.cc:2050 on nvptx-none

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
I've verified r13-285-ge7d9fdf5e0 fixes that, both on x86_64 and powerpc64le
when building the nvptx-none offloading compiler.

[Bug target/105938] [12/13 Regression] ICE in get_insn_temp late, at final.cc:2050 on nvptx-none

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

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

--- Comment #5 from Jakub Jelinek  ---
I mean backport thereof to 12 branch.

[Bug c++/106135] Found a bug caused by -O2 optimization transitions in gcc

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Looks like a dup of PR 106131

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

[Bug c++/106131] -fstrict-aliasing breaks normal program that does not use any pointer or reference

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||85811545 at qq dot com

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

[Bug target/105938] [12/13 Regression] ICE in get_insn_temp late, at final.cc:2050 on nvptx-none

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

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

--- Comment #6 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #5)
> I mean backport thereof to 12 branch.

Can you push it?

[Bug sanitizer/106136] gcc-12.1.1 - libsanitizer fails when compiled for MIPS

[immoloism at googlemail dot com via Gcc-bugs]

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

Immolo  changed:

   What|Removed |Added

  Attachment #53222|0   |1
is obsolete||

--- Comment #1 from Immolo  ---
Created attachment 53223
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53223&action=edit
GCC Build.log

Fixed attaching wrong build.log before

[Bug bootstrap/105551] [13 Regression] [nvptx] ICE in final_scan_insn_1, at final.cc:2629 when building libgcc2.c since r13-259-g76db543db88727789a6c117608a23edc2eace713

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

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

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

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

commit r12-8526-ga6a0f3423f3053999c0eb6e7183319c1dca6455d
Author: Richard Biener 
Date:   Wed May 11 10:47:34 2022 +0200

bootstrap/105551 - restore nvptx build

The following makes sure to disable var-tracking if only
dwarf2-line debuginfo is present.

2022-05-11  Richard Biener  

PR bootstrap/105551
* opts.cc (finish_options): Also disable var-tracking if
!DWARF2_DEBUGGING_INFO.

(cherry picked from commit e7d9fdf5e0ee4c34a880139254340b4165016289)

[Bug target/105938] [12/13 Regression] ICE in get_insn_temp late, at final.cc:2050 on nvptx-none

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

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

commit r12-8526-ga6a0f3423f3053999c0eb6e7183319c1dca6455d
Author: Richard Biener 
Date:   Wed May 11 10:47:34 2022 +0200

bootstrap/105551 - restore nvptx build

The following makes sure to disable var-tracking if only
dwarf2-line debuginfo is present.

2022-05-11  Richard Biener  

PR bootstrap/105551
* opts.cc (finish_options): Also disable var-tracking if
!DWARF2_DEBUGGING_INFO.

(cherry picked from commit e7d9fdf5e0ee4c34a880139254340b4165016289)

[Bug bootstrap/106137] baremetal cross builds broken in libgfortran since g:133d0d422ebd18dbd215cfa5394aff9f938e7060

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

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

--- Comment #1 from Jakub Jelinek  ---
Could you please attach
*/libgfortran/Makefile
*/libgfortran/config.h
from the build dir before/after that commit?

I believe aarch64 has IEEE754 quad long double, doesn't build libquadmath as it
isn't needed, doesn't support __float128, does support _Float128 (distinct? but
functionally equivalent type to long double), does support f128/F128 suffixes
on floating point constants and to my surprise also supports q/Q suffixes on
floating point constants (why?).

[Bug testsuite/106120] [13 regression] g++.dg/warn/Wstringop-overflow-4.C fails since r13-1268-g8c99e307b20c50

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|other   |testsuite
   Target Milestone|--- |13.0

[Bug target/106122] [12/13 Regression] ICE in fixup_args_size_notes, at expr.cc:4493

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.2

[Bug ipa/106124] [11/12/13 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.cc:23254

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.4

[Bug tree-optimization/106126] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2022-06-29
 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection
 Ever confirmed|0   |1

--- Comment #6 from Richard Biener  ---
a released SSA name in the IL after if-to-switch

[Bug lto/106129] [12/13 Regression] LTO option merging broken

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |12.2

[Bug c++/106134] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Version|12.0|13.0

--- Comment #1 from Richard Biener  ---
IIRC there's a duplicate

[Bug bootstrap/106137] baremetal cross builds broken in libgfortran since g:133d0d422ebd18dbd215cfa5394aff9f938e7060

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

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 53224
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53224&action=edit
gcc13-pr106137.patch

Perhaps this patch could fix this?
We no longer need __float128 type in libgfortran (except I think for the
powerpc64le __*ieee128 prototypes), but want to keep HAVE_FLOAT128 being
defined where it was defined before, which is targets where _Float128 is
supported and long double isn't IEEE quad (which is equivalent to targets where
__float128 is supported, the latter is only supported if long double isn't IEEE
quad and _Float128 is supported).

[Bug bootstrap/106137] baremetal cross builds broken in libgfortran since g:133d0d422ebd18dbd215cfa5394aff9f938e7060

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

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

--- Comment #3 from Tamar Christina  ---
(In reply to Jakub Jelinek from comment #1)
> Could you please attach
> */libgfortran/Makefile
> */libgfortran/config.h
> from the build dir before/after that commit?

Waiting for a build to finish to grab them

> Perhaps this patch could fix this?

Will kick off a build with the patch! thanks!

[Bug lto/106103] ICE in binds_to_current_def_p when source object files are compiled with -flto -Os

[ivanka2012 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Ivan  ---
Created attachment 53225
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53225&action=edit
Single file and smaller version of the original testcase

To compile this, do:
x86_64-w64-mingw32-g++ -r -flto -Os -std=gnu++14 -o /dev/null full.ii
-lkernel32

[Bug ipa/106124] [11/12/13 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.cc:23254

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

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

--- Comment #2 from Jakub Jelinek  ---
int q;
struct A
{
  typedef int T;
  #pragma omp declare reduction (x : T : omp_out += omp_in + [] (){ return q;
}()) initializer (omp_priv = [](){ return 0; }())
  static void foo ();
};
void bar (int &, int &);
void
A::foo ()
{
  int r = 0, s = 0;
  #pragma omp parallel reduction (x : r, s)
  bar (r, s);
}

ICEs too with the same options, but in a different spot.

[Bug tree-optimization/106126] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
(In reply to David Binderman from comment #5)
> Seems good. Current range appears to be [607118dfa47a1865, f1fcd6e3ad911945].

Tried 57424087e82db140 and that looked bad, so current range is
[607118dfa47a1865, 57424087e82db140].

Trying 70454c50b4592fe6.

A hot candidate for troublesome patch is 57424087e82db140.

[Bug tree-optimization/106126] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
I seem strangely unable to add email address xionghu...@tencent.com to this
email,
for their opinion on this bug report.

[Bug bootstrap/106137] baremetal cross builds broken in libgfortran since g:133d0d422ebd18dbd215cfa5394aff9f938e7060

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

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

--- Comment #4 from Tamar Christina  ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 53224 [details]
> gcc13-pr106137.patch
> 
> Perhaps this patch could fix this?

The patch does fix the build! I also have the 4 files you asked for, but assume
you no longer need them?

[Bug sanitizer/106136] gcc-12.1.1 - libsanitizer fails when compiled for MIPS

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
I think it's dup.

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

[Bug sanitizer/105614] mips64: sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||immoloism at googlemail dot com

--- Comment #9 from Martin Liška  ---
*** Bug 106136 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/106126] [12 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|tree check fail in  |[12 Regression] tree check
   |useless_type_conversion_p,  |fail in
   |at gimple-expr.cc:87|useless_type_conversion_p,
   ||at gimple-expr.cc:87 since
   ||r13-1184-g57424087e82db140
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Keywords|needs-bisection |

--- Comment #9 from Martin Liška  ---
Started with r13-1184-g57424087e82db140.
I'm going to take a look.

[Bug rtl-optimization/106082] [13 Regression] Recent change broke m68k

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

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

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

https://gcc.gnu.org/g:0282c4acf720e4cc073cf95594aa890444c5ca82

commit r13-1342-g0282c4acf720e4cc073cf95594aa890444c5ca82
Author: Richard Biener 
Date:   Tue Jun 28 13:08:33 2022 +0200

rtl-optimization/106082 - preserve EH note for no non-local goto

The following makes sure we preserve EH notes on call insns that
indicate the call doesn't perform a non-local goto when distributing
notes after combining insns.

2022-06-28  Richard Biener  

PR rtl-optimization/106082
* combine.cc (distribute_notes): Preserve notes when
they indicate a call doesn't perform a non-local goto.

[Bug tree-optimization/106126] [12 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140

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

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

--- Comment #10 from Martin Liška  ---
(In reply to David Binderman from comment #8)
> I seem strangely unable to add email address xionghu...@tencent.com to this
> email,
> for their opinion on this bug report.

Yeah, he hasn't registered a bugzilla account. I'm going to write him an email.

[Bug rtl-optimization/106082] [13 Regression] Recent change broke m68k

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

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

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

Bug 106082 Summary: [13 Regression] Recent change broke m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106082

   What|Removed |Added

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

[Bug target/106122] [12/13 Regression] ICE in fixup_args_size_notes, at expr.cc:4493 since r12-6106-gef26c151c14a8717

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||sayle at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
Summary|[12/13 Regression] ICE in   |[12/13 Regression] ICE in
   |fixup_args_size_notes, at   |fixup_args_size_notes, at
   |expr.cc:4493|expr.cc:4493 since
   ||r12-6106-gef26c151c14a8717

--- Comment #1 from Martin Liška  ---
Started with r12-6106-gef26c151c14a8717.

[Bug c++/106123] ICE in walk_tree_1, at tree.cc:11243

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||qing.zhao at oracle dot com

--- Comment #1 from Martin Liška  ---
It's there since -ftrivial-auto-var-init=zero was added.

[Bug target/106122] [12/13 Regression] ICE in fixup_args_size_notes, at expr.cc:4493 since r12-6106-gef26c151c14a8717

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-29
 CC||roger at nextmovesoftware dot 
com
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com

--- Comment #2 from Roger Sayle  ---
Mine.  Currently testing the (obvious) one line fix:

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 125a3b4..3b6f362 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -2588,7 +2588,8 @@
   "optimize_insn_for_size_p () && optimize_size > 1
&& operands[1] != const0_rtx
&& IN_RANGE (INTVAL (operands[1]), -128, 127)
-   && !ix86_red_zone_used"
+   && !ix86_red_zone_used
+   && REGNO (operands[0]) != SP_REG"
   [(set (match_dup 2) (match_dup 1))
(set (match_dup 0) (match_dup 3))]
 {

[Bug c/106138] New: Inefficient code generation for cases when results can be deduced at compile time

[pavel.morozkin at gmail dot com via Gcc-bugs]

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

Bug ID: 106138
   Summary: Inefficient code generation for cases when results can
be deduced at compile time
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel.morozkin at gmail dot com
  Target Milestone: ---

_Bool f(char x)
{
_Bool b1 = x == 4;
_Bool b2 = x & 0x3;
return b1 && b2;
}

Invocation: gcc -O3

Actual generated code:
f:
testdil, 3
setne   al
cmp dil, 4
setedl
and eax, edx
ret

Expected generated code:
f:
xor eax, eax
ret

The Summary needs to be adjusted perhaps.

[Bug d/106139] New: d: aggregate value used where floating point was expected

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 106139
   Summary: d: aggregate value used where floating point was
expected
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Casting from vector to static array is permitted, and the frontend generates a
reinterpret cast, but casting back the other way results in an error.
---
__vector(int[4]) vec = [1,2,3,4];
int[4] arr;

arr = cast(int[4])vec;// OK
vec = cast(__vector(int[4]))arr;  // Error

[Bug c/106119] Bogus use-after-free warning triggered by optimizer

[tom.cosgrove at arm dot com via Gcc-bugs]

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

--- Comment #2 from Tom Cosgrove  ---
Further addendum:

If you use a `void *` to save the value of the pointer, you don't get the
warning!

See https://gcc.godbolt.org/z/fof8a747z


i.e. this code does not generate the warning:

#include 
#include 
#include 

void calloc_self_test( __attribute__ ((unused)) int verbose )
{
void *buffer1 = calloc( 1, 1 );
void *old_buffer1 = buffer1;
free( buffer1 );
buffer1 = calloc( 1, 1 );
int same = ( old_buffer1 == buffer1 );
if( verbose )
printf( "  CALLOC(1 again): passed (%s address)\n",
same ? "same" : "different" );
free( buffer1 );
}

[Bug tree-optimization/106138] Inefficient code generation for cases when results can be deduced at compile time

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

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

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

--- Comment #7 from Steve Kargl  ---
On Wed, Jun 29, 2022 at 08:11:01AM +, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
> 
> --- Comment #6 from Martin Liška  ---
> (In reply to kargl from comment #5)
> > (In reply to Jakub Jelinek from comment #4)
> > > GCC 10.4 is being released, retargeting bugs to GCC 10.5.
> > 
> > That's a shame.  The patch in comment 1 and the correction
> > noted in comment 2 where submitted 8 months ago.
> 
> So please test it and send to gcc-fortran mailing list :)
> 

I'm not subscribed to fortran@ or gcc-patches@.
Even If I subscribe to a list what good would it
do to send an email?  Someone might glance at 
it.  Then what?  I cannot commit as I don't use
git (an unfortunate consequence of dropping svn)?

I don't add patches to a PR if they do not fix
the problem.

[Bug bootstrap/106137] baremetal cross builds broken in libgfortran since g:133d0d422ebd18dbd215cfa5394aff9f938e7060

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

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

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

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

commit r13-1344-gc022c0de2a6c9110350cd50275be97d061a19530
Author: Jakub Jelinek 
Date:   Wed Jun 29 17:04:50 2022 +0200

libgfortran: Fix up LIBGFOR_CHECK_FLOAT128 [PR106137]

My recent gfortran + libgfortran patch apparently broke (some?) aarch64
builds.  While it is desirable to use just _Float128 rather than
__float128,
we only want to use it (and e.g. define HAVE_FLOAT128) on targets where
_Float128 is supported and long double isn't IEEE quad precision.
Which is targets that support __float128 type which we have been testing
for before - _Float128 is supported on those targets and on targets where
long double is IEEE quad precision.

So, the following patch restores check for whether __float128 is supported
into the LIBGFOR_CHECK_FLOAT128 check which determines whether
HAVE_FLOAT128 is defined or whether to use libquadmath, so that e.g. on
aarch64 where long double is IEEE quad we don't do that.

2022-06-29  Jakub Jelinek  

PR bootstrap/106137
* acinclude.m4 (LIBGFOR_CHECK_FLOAT128): Adjust comment.
Also test for __float128.
(HAVE_FLOAT128): Adjust description.
* config.h.in: Regenerated.
* configure: Regenerated.

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[rjmccall at gmail dot com via Gcc-bugs]

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

--- Comment #4 from John McCall  ---
Ah, thank you, we weren't aware of -fexcess-precision=16.  If that's the
precedent, we can certainly follow it.

The idea around "16" was to make it clear that this just affects _Float16?  If
the option were named -fexcess-precision=none, then I suppose someone who had
started passing it years ago to prevent float/double promotion on i386 would
now unintentionally be affected by it for _Float16.  Put another way, there's
an implicit assumption in the re-use of a single option that targets will have
a linear history of support for more floating point types, such that there's
only one kind of emulation in use at once.

[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p

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

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

--- Comment #8 from Segher Boessenkool  ---
There is structural RTL checking in rtl.h (see RTL_CHECK{1,2,C1,C2,C3} and the
various ELT and INT accessors).  This would be easier to use here if we used
some STRICT_LOW_PART_P everywhere :-)

[Bug preprocessor/100125] -Wunused-macros generated while should be ignored; if undef is seen?

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Lewis Hyatt  ---
The reason it works without #undef is that cpp_finish() is called late by the
C++ frontend, after it has processed everything including pragmas. With #undef,
the warning is generated immediately by libcpp and so is subject to PR53431.
There is a patch waiting for review that will resolve it.

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

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||gcc at behdad dot org

--- Comment #50 from Lewis Hyatt  ---
*** Bug 100125 has been marked as a duplicate of this bug. ***

[Bug fortran/106121] ICE in gfc_simplify_extends_type_of, at fortran/simplify.cc:3109

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

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

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

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

commit r13-1349-gb8f284d3673004dffae714b56ed663467c2a52a7
Author: Harald Anlauf 
Date:   Tue Jun 28 22:29:28 2022 +0200

Fortran: improve error recovery for EXTENDS_TYPE_OF() [PR106121]

gcc/fortran/ChangeLog:

PR fortran/106121
* simplify.cc (gfc_simplify_extends_type_of): Do not attempt to
simplify when one of the arguments is a CLASS variable that was
not properly declared.

gcc/testsuite/ChangeLog:

PR fortran/106121
* gfortran.dg/extends_type_of_4.f90: New test.

Co-authored-by: Steven G. Kargl 

[Bug fortran/106121] ICE in gfc_simplify_extends_type_of, at fortran/simplify.cc:3109

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Fixed for gcc-13.

Thanks for the report!

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #5 from joseph at codesourcery dot com  ---
The idea with "16" is to say that's the exact FLT_EVAL_METHOD value 
(defined in C23 Annex H) whose semantics should be followed.  It would 
affect float/double promotion on i386 as well (the back end gives an error 
that the combination of that option with -mfpmath=387 is unsupported).

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[rjmccall at gmail dot com via Gcc-bugs]

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

--- Comment #6 from John McCall  ---
Ah, I can see how the FLT_EVAL_METHOD schema gives us a unifying scheme, thank
you.  Just to be clear, though, the actual value of FLT_EVAL_METHOD in that
mode should be 0, correct?

[Bug tree-optimization/106114] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #7 from Andrew Macleod  ---
The routine which tries to fold relations in && or || statements is getting
stale information.

GORI maintains a dependency cache which is mostly use by the temporal mechanism
to decide when statements are out of date.  It is a shortcut that is used to
prevent constant re-scanning of statements to find any ssa-names in the operand
list.

AS its intended use is dependency tracking, it is allowed to get out of date if
statements are rewritten (additional dependencies may just result in missed
opportunities)

IN this case, _16 and _17 is dependent on a.0_1, and DOM rewrites them, and
eventually the new name a.1_15 is processed and that dependency is added.

relation_fold_and_or erroneously accesses these cache values thinking its a
shortcut to looking at the statements, and then things the 2 relations feeding 
_18 = _16 | _17
are  comparisons between a.0_1 and a.1_15, and with a < and >=,  decides the
condition can be folded.

Using the cache for this purpose is incorrect.  Instead, it should simply query
the operands and ensure they are both ssa-names, and proceed.

Patch in testing.

This is less likely to occur in GCC12 as less places rewrite the IL under the
covers, but it should still be applied ot that branch just in case.

[Bug rtl-optimization/104637] [10/11 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -Og -fno-forward-propagate -mavx since r9-5221-gd8fcab689435a29d

[herrtimson at yahoo dot de via Gcc-bugs]

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

--- Comment #16 from tt_1  ---
May I kindly ask why this was retargeted to gcc-10.5.0? It seems to me that all
the patches were merged into gcc-10.4.0, is there more to come?

[Bug middle-end/103993] -Wismatched-new-delete due to difference in inlining decisions

[ed at catmur dot uk via Gcc-bugs]

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

--- Comment #4 from Ed Catmur  ---
And another example, provoked by throwing new (this only happens at -Og):

#include 
struct D {
D();
static void* operator new (std::size_t s) {
if (void* p = ::malloc(s))
return p;
throw "bad_alloc";
}
static void operator delete (void* p) { ::free(p); }
};
int main() { new D; }

[Bug fortran/95372] ICE in find_array_section, at fortran/expr.c:1687

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED
   Target Milestone|--- |10.5

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed in gcc-10+, thus closing.

[Bug c++/106102] gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Sergei Trofimovich :

https://gcc.gnu.org/g:49d508065bdd36fb1a9b6aad9666b1edb5e06474

commit r13-1350-g49d508065bdd36fb1a9b6aad9666b1edb5e06474
Author: Sergei Trofimovich 
Date:   Mon Jun 27 23:42:44 2022 +0100

jit: avoid calloc() poisoning on musl [PR106102]

On musl  uses calloc() (via ). jit/ includes
it directly and exposes use of poisoned calloc():

/build/build/./prev-gcc/xg++ ...
../../gcc-13-20220626/gcc/jit/jit-playback.cc
make[3]: *** [Makefile:1143: jit/libgccjit.o] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from /<>/musl-1.2.3-dev/include/pthread.h:30,
 from ../../gcc-13-20220626/gcc/jit/jit-playback.cc:44:
/<>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use
poisoned "calloc"
   84 | void *calloc(size_t, size_t);
  |   ^
/<>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use
poisoned "calloc"
  124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
  |^

The change moves  inclusion to "system.h" under new
INCLUDE_PTHREAD_H guard and uses this mechanism in libgccjit.

gcc/

PR c++/106102
* system.h: Introduce INCLUDE_PTHREAD_H macros to include
.

gcc/jit/

PR c++/106102
* jit-playback.cc: Include  via "system.h" to avoid
calloc()
poisoning.
* jit-recording.cc: Ditto.
* libgccjit.cc: Ditto.

[Bug tree-optimization/106114] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[amacleod at redhat dot com via Gcc-bugs]

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

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

Patch in testing

[Bug rtl-optimization/104637] [10/11 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -Og -fno-forward-propagate -mavx since r9-5221-gd8fcab689435a29d

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #17 from Uroš Bizjak  ---
(In reply to tt_1 from comment #16)
> May I kindly ask why this was retargeted to gcc-10.5.0? It seems to me that
> all the patches were merged into gcc-10.4.0, is there more to come?

No, just the PR was not closed in time.

[Bug c++/106131] [10/11/12/13 Regression] -fstrict-aliasing breaks normal program that does not use any pointer or reference

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.2
Summary|-fstrict-aliasing breaks|[10/11/12/13 Regression]
   |normal program that does|-fstrict-aliasing breaks
   |not use any pointer or  |normal program that does
   |reference   |not use any pointer or
   ||reference
   Keywords||needs-bisection,
   ||needs-reduction

--- Comment #4 from Andrew Pinski  ---
This feels like a front-end issue ...

[Bug c++/106131] [10/11/12/13 Regression] -fstrict-aliasing breaks normal program that does not use any pointer or reference

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|12.2|10.5

[Bug rtl-optimization/104637] [10/11 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -Og -fno-forward-propagate -mavx since r9-5221-gd8fcab689435a29d

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|10.5|10.4

[Bug tree-optimization/106131] [10/11/12/13 Regression] -fstrict-aliasing breaks normal program that does not use any pointer or reference

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||mpolacek at gcc dot gnu.org
  Component|c++ |tree-optimization
   Priority|P3  |P2

[Bug tree-optimization/106131] [10/11/12/13 Regression] -fstrict-aliasing breaks normal program that does not use any pointer or reference

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug c++/106131] [10/11/12/13 Regression] -fstrict-aliasing breaks normal program that does not use any pointer or reference

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

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

--- Comment #5 from Marek Polacek  ---
Started with

commit 8403c2cf5f66758fc78a01a675b0d218fded0202
Author: Richard Biener 
Date:   Mon Nov 24 14:07:18 2014 +

re PR target/63679 ([AArch64] Failure to constant fold.)

2014-11-24  Richard Biener  

PR tree-optimization/63679
* tree-ssa-sccvn.c: Include ipa-ref.h, plugin-api.h and cgraph.h.
(copy_reference_ops_from_ref): Fix non-constant ADDR_EXPR case
to properly leave off at -1.
(fully_constant_vn_reference_p): Generalize folding from
constant initializers.
(vn_reference_lookup_3): When looking through aggregate copies
handle offsetted reads and try simplifying the result to
a constant.
* gimple-fold.h (fold_ctor_reference): Export.
* gimple-fold.c (fold_ctor_reference): Likewise.

* gcc.dg/tree-ssa/ssa-fre-42.c: New testcase.
* gcc.dg/tree-ssa/20030807-5.c: Avoid folding read from global to
zero.
* gcc.target/i386/ssetype-1.c: Likewise.
* gcc.target/i386/ssetype-3.c: Likewise.
* gcc.target/i386/ssetype-5.c: Likewise.

From-SVN: r218019

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Steve,

when using your patch from comment#2 and moving it up slightly, it will
also improve error handling for unlimited polymorphic entities.  This fixes
a few more PRs.

Taking.

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

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

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-June/057972.html

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #7 from joseph at codesourcery dot com  ---
FLT_EVAL_METHOD of 0 gives _Float16 excess precision ("evaluate all 
operations and constants, whose semantic type comprises a set of values 
that is a strict subset of the values of float, to the range and precision 
of float; evaluate all other operations and constants to the range and 
precision of the semantic type").  See the -fpermitted-flt-eval-methods= 
option that's used to control whether FLT_EVAL_METHOD may be defined to a 
value such as 16 that's not part of C11.

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

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

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

--- Comment #11 from Steve Kargl  ---
On Wed, Jun 29, 2022 at 07:42:30PM +, anlauf at gcc dot gnu.org wrote:
> 
> when using your patch from comment#2 and moving it up slightly, it will
> also improve error handling for unlimited polymorphic entities.  This fixes
> a few more PRs.
> 

Saw you email to fortran@.

Thanks for grabbing it.  I think it's ok to commit,
but I fully understand wanting to get another set
of eyes on it.

[Bug d/106139] d: aggregate value used where floating point was expected

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #1 from Iain Buclaw  ---
Note, gdc-11 and gdc-10 error as a result to a different issue.
---
cannot resolve type for cast(__vector(int[8]))arr
---

Fix was made in a newer version of upstream dmd, so that'll be handled in the
backport.

https://github.com/dlang/dmd/pull/10532

[Bug d/106139] d: aggregate value used where floating point was expected

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:329bef49da30158d30fed1106002bb71674776bd

commit r13-1351-g329bef49da30158d30fed1106002bb71674776bd
Author: Iain Buclaw 
Date:   Wed Jun 29 21:52:39 2022 +0200

d: Fix error: aggregate value used where floating point was expected

Casting from vector to static array is permitted, and the frontend
generates a reinterpret cast, but casting back the other way resulted in
an error.  This has been fixed to be properly handled in the code
generation pass of VectorExp, and the conversion for lvalue and rvalue
handling done in convert_expr and convert_for_rvalue respectively.

PR d/106139

gcc/d/ChangeLog:

* d-convert.cc (convert_expr): Handle casting from array to vector.
(convert_for_rvalue): Rewrite vector to array casts of the same
element type into a constructor.
(convert_for_assignment): Return calling convert_for_rvalue.
* expr.cc (ExprVisitor::visit (VectorExp *)): Handle generating a
vector expression from a static array.
* toir.cc (IRVisitor::visit (ReturnStatement *)): Call
convert_for_rvalue on return value.

gcc/testsuite/ChangeLog:

* gdc.dg/pr106139a.d: New test.
* gdc.dg/pr106139b.d: New test.
* gdc.dg/pr106139c.d: New test.
* gdc.dg/pr106139d.d: New test.

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[rjmccall at gmail dot com via Gcc-bugs]

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

--- Comment #8 from John McCall  ---
Oh, that's what I get for having two different draft standards open at once. 
Thanks.

[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load

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

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #53186|0   |1
is obsolete||

--- Comment #16 from H.J. Lu  ---
Created attachment 53227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53227&action=edit
The v4 patch

Here is a different approach by supporting 2/4/8 byte constant vector stores.

[Bug analyzer/106140] New: RFE: analyzer could complain about misuses of socket APIs

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

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

Bug ID: 106140
   Summary: RFE: analyzer could complain about misuses of socket
APIs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106003
  Target Milestone: ---

POSIX has numerous API entrypoints for working with sockets, and, presumably,
numerous ways of misusing them.  They're expressed in terms of
file-descriptors, and so checking them would interact with PR 106003.

One specific example: the Juliet 1.3 testsuite 
  https://samate.nist.gov/SARD/test-suites
has a subdirectory:

  C/testcases/CWE666_Operation_on_Resource_in_Wrong_Phase_of_Lifetime/

which has e.g. tests that sockets have calls to:
  bind then listen then accept  (good)
rather than, say:
  accept then bind then listen  (bad)

This could be modeled as part of a state machine, possibly as part of the FD
state machine.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
[Bug 106003] RFE: -fanalyzer could complain about misuse of file-descriptors

[Bug c++/104477] [C++23] Implement P2255R2, type trait to detect reference binding to temporary

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/104477] [C++23] Implement P2255R2, type trait to detect reference binding to temporary

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

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

--- Comment #3 from Andrew Pinski  ---
I am going to be like Johnathan and say I wish these compiler intrinsic were
defined by the standard rather than having  to define them ourselves.

[Bug c++/100157] Support `__type_pack_element` like Clang

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-29
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug c++/100157] Support `__type_pack_element` like Clang

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/100157] Support `__type_pack_element` like Clang

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

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

--- Comment #1 from Jonathan Wakely  ---
GCC doesn't support template-like built-ins, but I have a patch to add a
function-like __builtin_type_pack_element(N, T...) instead. I don't like the
name "type pack element" much though. To me that doesn't really suggest
selecting an element by its index.

[Bug jit/105812] type mismatch in binary expression

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Antoni Boucher :

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

commit r13-1353-ge3a5c77388ae3791afed4f4286ec7e41e5b9f7c3
Author: Antoni Boucher 
Date:   Wed Jun 29 19:56:56 2022 -0400

libgccjit: Fix bug where unary_op will return an integer type instead of
the correct type

2022-06-29  Antoni Boucher  

gcc/jit/
PR jit/105812
* jit-playback.cc: Use the correct return type when folding in
as_truth_value.

gcc/testsuite/
PR jit/105812
* jit.dg/test-asm.cc: Add include missing to make the test pass.
* jit.dg/test-pr105812-bool-operations.c: New test.

[Bug jit/105812] type mismatch in binary expression

[bouanto at zoho dot com via Gcc-bugs]

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

Antoni  changed:

   What|Removed |Added

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

--- Comment #3 from Antoni  ---
Fixed on master.

[Bug target/106095] Some AVX builtins produce invalid asm with -masm=intel

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Antoni Boucher :

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

commit r13-1355-ge484755aecd543b4c9e2adb4f348118c1e43cfd0
Author: Antoni Boucher 
Date:   Sun Jun 26 18:49:15 2022 -0400

target: Fix asm generation for AVX builtins when using -masm=intel
[PR106095]

gcc/ChangeLog:
PR target/106095
* config/i386/sse.md: Fix asm generation.

gcc/testsuite/ChangeLog:
PR target/106095
* gcc.target/i386/pr106095.c: Add test using those AVX builtins.

[Bug target/106095] Some AVX builtins produce invalid asm with -masm=intel

[bouanto at zoho dot com via Gcc-bugs]

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

Antoni  changed:

   What|Removed |Added

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

--- Comment #3 from Antoni  ---
Fixed in master.

[Bug tree-optimization/106131] [10/11/12/13 Regression] -fstrict-aliasing breaks normal program that does not use any pointer or reference

[18307130172 at fudan dot edu.cn via Gcc-bugs]

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

--- Comment #6 from Xue Zhenliang <18307130172 at fudan dot edu.cn> ---
I'm trying to reducing it further. Now I've eliminated the dependency on STL:

struct Pair {
int a, b;

Pair(const Pair &) = default;
Pair(int _a, int _b) : a(_a), b(_b) {}
Pair &operator=(const Pair &z) {
a = z.a;
b = z.b;
return *this;
}
};

const int &max(const int &a, const int &b) {
return a < b ? b : a;
}

int foo(Pair x, Pair y) {
return max(x.b, y.b);
}

int main() {
auto f = new Pair[3] {{0, -11}, {0, -8}, {0, 2}};
for (int i = 0; i < 1; i++) {
f[i] = f[0];
if(i == 0)
f[i] = f[2];
if (foo(f[i], f[1]) != 2)
__builtin_abort();
}
}

[Bug tree-optimization/106114] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:918bb0e78ae42bfcf808a1e93a8f6b9d02ea

commit r13-1356-g918bb0e78ae42bfcf808a1e93a8f6b9d02ea
Author: Andrew MacLeod 
Date:   Wed Jun 29 13:34:05 2022 -0400

Don't use gori dependencies to optimize.

  The routine fold_using_range::relation_fold_and_or needs to veriyf that
both
operands of 2 stmts are the same, and uses GORIs dependency cache for this.
This cache cannot be counted on to reflect the current contents of a
stmt, expecially in the presence of an IL changing pass.  Instead, look at
the
statement operands.

PR tree-optimization/106114
gcc/
* gimple-range-fold.cc (fold_using_range::relation_fold_and_or):
Check
statement operands instead of GORI cache.
gcc/testsuite/
* gcc.dg/pr106114.c: New.

[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #12 from Xi Ruoyao  ---
Fixed at r13-1337 and r12-8252.

Interesting: why aren't we receiving a cvs-commit notification here?

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

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

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

Bug 106097 Summary: undefined behaviors regarding integer shifts in 
loongarch_build_integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097

   What|Removed |Added

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

[Bug testsuite/102690] [11/12/13 regression] g++.dg/warn/Warray-bounds-16.C fails

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

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Kito Cheng :

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

commit r13-1357-g0f6eef398045deb2a62d18b526831719c7c20c8a
Author: Kito Cheng 
Date:   Tue Jun 28 18:43:42 2022 +0800

testsuite/102690: Only check warning for lp64 in Warray-bounds-16.C

That warning won't happen on ilp32 targets, seems like Andrew Pinski
already mention that[1] before.

Verified on riscv32-unknown-elf and riscv64-unknown-elf.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879#c1

gcc/testsuite/ChangeLog:

PR testsuite/102690
* g++.dg/warn/Warray-bounds-16.C: XFAIL only on lp64 for the
warning.

[Bug target/106113] wrong codegen for _mm_[u]comineq_{ss,sd} and need to return PF result.

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

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-30
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||hjl.tools at gmail dot com

[Bug tree-optimization/106126] [12 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140

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

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

--- Comment #11 from luoxhu at gcc dot gnu.org ---
Sorry for breaking, my bugzilla account is luo...@gcc.gnu.org.

The patch seems reasonable to fold 65-90 ('A'-'Z') to switch statement, 

4,6c4,6
< ;; Canonical GIMPLE case clusters: 33 60 62 126
< ;; BT can be built: BT(values:3 comparisons:6 range:30 density: 20.00%):33-62
126
< pr106126.c:3:28: optimized: Condition chain with 4 BBs transformed into a
switch statement.
---
> ;; Canonical GIMPLE case clusters: 33 60 62 65-90 126
> ;; BT can be built: BT(values:3 comparisons:6 range:30 density: 20.00%):33-62 
> 65-90 126
> pr106126.c:3:28: optimized: Condition chain with 5 BBs transformed into a 
> switch statement.

...

96,97c108,109
<:
<   switch (_13)  [INV], case 33:  [INV], case 60: 
[INV], case 62:  [INV], case 126:  [INV]>
---
>:
>   switch (_13)  [INV], case 33:  [INV], case 60:  
> [INV], case 62:  [INV], case 65 ... 90:  [INV], case 126:  
> [INV]>




complete pr106126.bad.c.046t.iftoswitch:

;; Function pool_conda_matchspec (pool_conda_matchspec, funcdef_no=0,
decl_uid=1979, cgraph_uid=1, symbol_order=1)

;; Canonical GIMPLE case clusters: 33 60 62 65-90 126
;; BT can be built: BT(values:3 comparisons:6 range:30 density: 20.00%):33-62
65-90 126

pr106126.c:3:28: optimized: Condition chain with 5 BBs transformed into a
switch statement.
Removing basic block 9
;; basic block 9, loop depth 2
;;  pred:
if (_13 != 62)
  goto ; [INV]
else
  goto ; [INV]
;;  succ:   10
;;  12


Removing basic block 10
;; basic block 10, loop depth 2
;;  pred:
if (_13 != 33)
  goto ; [INV]
else
  goto ; [INV]
;;  succ:   11
;;  12


Removing basic block 11
;; basic block 11, loop depth 2
;;  pred:
if (_13 != 126)
  goto ; [INV]
else
  goto ; [INV]
;;  succ:   3
;;  12


Removing basic block 3
;; basic block 3, loop depth 2
;;  pred:
_3 = (unsigned char) _13;
_4 = _3 + 191;
if (_4 <= 25)
  goto ; [INV]
else
  goto ; [INV]
;;  succ:   14
;;  13


Expanded into a new gimple STMT: switch (_13)  [INV], case 33:
 [INV], case 60:  [INV], case 62:  [INV], case 65 ... 90: 
[INV], case 126:  [INV]>

Removing basic block 13
;; basic block 13, loop depth 2
;;  pred:
:
goto ; [100.00%]
;;  succ:   6


Removing basic block 14
;; basic block 14, loop depth 1
;;  pred:
:
;;  succ:   4


fix_loop_structure: fixing up loops for function
void pool_conda_matchspec ()
{
  unsigned char _8;
  char _10;
  char * var_1.3_11;
  char _13;
  unsigned char _14;
  char * var_1.3_15;

   :
  goto ; [INV]

   :
  # _14 = PHI <_3(7)>
  # var_1.3_15 = PHI 
:
  _8 = _14 + 65;
  _10 = (char) _8;
  *var_1.3_15 = _10;

   :

   :
:
  var_1.3_11 = var_1;
  if (var_1.3_11 != 0B)
goto ; [INV]
  else
goto ; [INV]

   :
  _13 = *var_1.3_11;
  if (_13 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  switch (_13)  [INV], case 33:  [INV], case 60: 
[INV], case 62:  [INV], case 65 ... 90:  [INV], case 126: 
[INV]>

   :
:
  return;
  _8 = _14 + 65;
  _10 = (char) _8;
  *var_1.3_15 = _10;

   :

   :
:
  var_1.3_11 = var_1;
  if (var_1.3_11 != 0B)
goto ; [INV]
  else
goto ; [INV]

   :
  _13 = *var_1.3_11;
  if (_13 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  switch (_13)  [INV], case 33:  [INV], case 60: 
[INV], case 62:  [INV], case 65 ... 90:  [INV], case 126: 
[INV]>

   :
:
  return;

}


The problem is _3 is removed in basic block 3, but _14 is still using it.

[Bug target/106113] wrong codegen for _mm_[u]comineq_{ss,sd} and need to return PF result.

[lingling.kong7 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from kong lingling  ---
(In reply to Jakub Jelinek from comment #1)
> Has the definition of these intrinsics changed over time?
  Yes, intrinsic `_mm_comieq_ss ` old operation is `RETURN ( a[31:0] == b[31:0]
) ? 1 : 0`, and new operation update is `RETURN ( a[31:0] != NaN AND b[31:0] !=
NaN AND a[31:0] == b[31:0] ) ? 1 : 0`.
> Because e.g. clang up to 3.8.1 also matches gcc behavior of testing LTGT for
> the *neq* and UNEQ for *eq* intrinsics.
> Note, changing all UNEQ to EQ and LTGT to NE in the COMI section of
> i386-builtin.def doesn't do the trick.

[Bug tree-optimization/106126] [12 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140

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

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

--- Comment #12 from luoxhu at gcc dot gnu.org ---
conditions_in_bbs->is_empty doesn't mean that range is at the start of switch
condition:(, so couldn't assume to ignore the no_side_effect_bb check?

[Bug sanitizer/105614] mips64: sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #10 from Xi Ruoyao  ---
We've not backported MIPS64 libsanitizer support to GCC 11 so it should not be
enabled.  In configure.tgt we have:

  mips*64*-*-linux*)
# This clause is only here to not match the supported mips*-*-linux*.
UNSUPPORTED=1

so I'm not sure how libsanitizer is even being built with 11.3.0 for you.  If
you "played" something with the code, don't do that.  Otherwise, the only real
bug is "libsanitizer enabled for MIPS64 with GCC 11.3.0 while it's not
supported".