[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 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=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 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 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 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 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 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 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 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 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 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 = 
  return 0;
}

[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).