[Bug ada/68849] Bug box when using a type with static predicate as formal parameter of generic procedure

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |12.2
 Resolution|--- |FIXED

--- Comment #3 from Eric Botcazou  ---
.

[Bug c/108140] New: tzcnt gives different result in debug vs release

[levo.delellis at gmail dot com via Gcc-bugs]

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

Bug ID: 108140
   Summary: tzcnt gives different result in debug vs release
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: levo.delellis at gmail dot com
  Target Milestone: ---

This might be more than one bug and I gotten the compiler to crash. Tested on
apple ventura with an M2 but it may happen on ARMv8 linux. This slightly
different test also fails with O2 on my mac https://godbolt.org/z/xv883jMb9

gcc docs says 0 might be undefined, I understand that

> Built-in Function: int __builtin_ctz (unsigned int x) 
> Returns the number of trailing 0-bits in x, starting at the least 
> significant bit position. If x is 0, the result is undefined. 

>From my understanding armv8 doesn't have count trailing zero, it implements it
using rbits (reverse bits) and clz. clz says when you give it a 64bit register
it'll return 64 on 0. 
https://developer.arm.com/documentation/ddi0596/2020-12/Base-Instructions/CLZ--Count-Leading-Zeros-

Now here's the problem. I would think __builtin_ctz would be those two
instructions. So I tried the below, compiled and ran using `gcc -Wall -Wextra
test.c && ./a.out` and saw that it worked as expected. However mistake was
stopping there. Using `gcc -O2 -Wall -Wextra test.c && ./a.out` gets 456
instead, no warnings or anything. Looking at the assembly it appears the check
has been optimized out and 456 is used. 

Looking at the "ARM C Language Extensions Architecture Specification" it
suggested including arm_acle.h. So I replaced the line below with the following
line and still got the incorrect result

unsigned long long tz = __clz((unsigned long long)__rbit(input));

I'm not sure if this is another bug but this crashes with -O2
https://godbolt.org/z/xv883jMb9 it also doesn't give me the result I expected.
rbit appears to give me 32 no matter what I write. Doc says it should give 64
https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/RBIT--vector---Reverse-Bit-order--vector--?lang=en

Anyway I would like to be warned against these problems somehow. Homebrew on
mac doesn't seem to have undefined behavior sanitizer (although I'm new to mac
and may have set it up incorrectly). The ubsan would be great to warn against
this. Alternative a flag such as -Wprefer-intrinsic could help, when either the
built ins don't match the CPU behavior.

>From what I can tell __builtin_ctzll doesn't seem to return 32, it seems like
it does return 64, when you compare the variable the optimizer seems to think
it will never be greater than 32 which was a problem in my code because I was
using bits >= 60 so I can't simply do >= 32.


#include
int main(int argc, char *argv[])
{   
unsigned long long input = argc-1;
unsigned long long v = __builtin_ctzll(input);
printf("%d %d\n", argc, v >= 64 ? 123 : 456);
}

[Bug c++/108138] g++ 9+ takes 7-10x longer compiling constexpr

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
Patrick, is there anything that can be done on the GCC 10/11 branches for this
regression from GCC 8?

[Bug tree-optimization/108139] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection, wrong-code
Summary|wrong code with "-O1|[13 Regression] wrong code
   |-ftree-vrp" on  |with "-O1 -ftree-vrp" on
   |x86_64-linux-gnu|x86_64-linux-gnu
Version|unknown |13.0
   Target Milestone|--- |13.0

[Bug c/108140] tzcnt gives different result in debug vs release

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
If you call __builtin_ctzll with argument 0, it is undefined behavior, you
can't make any assumptions, regardless what instructions you assume will be
used or are actually used.
If you write your code as x ? __builtin_ctzll (x) : 64 or similar, GCC if it
uses an instruction that guarantees that result for 0 might actually fold it
back into just that instruction unconditionally.

[Bug c/108140] tzcnt gives different result in debug vs release

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

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

--- Comment #2 from Jakub Jelinek  ---
And -fsanitize=undefined is able to sanitize those.

[Bug rtl-optimization/108086] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

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

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

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

https://gcc.gnu.org/g:711e0acdbb2645f5a8aa89014488c24e89ccb0f7

commit r13-4738-g711e0acdbb2645f5a8aa89014488c24e89ccb0f7
Author: Richard Biener 
Date:   Fri Dec 16 09:25:40 2022 +0100

middle-end/108086 - more operand scanner reduction in inlining

There's another round of redundant operand scanning in
remap_gimple_stmt.  The following removes this and also improves
one special-case to call a cheaper inline function.

PR middle-end/108086
* tree-inline.cc (remap_gimple_stmt): Add stmts to the
sequence without updating them.  Simplify x == x detection.

[Bug c/108140] tzcnt gives different result in debug vs release

[levo.delellis at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Levo DeLellis  ---
It's late and realized I meant to write rbitll but I can't seem to edit/correct
my post

Jakub ty I'll do just that.

Do you happen to know if clang uses the same sanitizers? I didn't seem to get
that on clang but it isn't the latest release.

[Bug testsuite/108141] New: [13 Regression] gcc.target/i386/pr64110.c FAIL since r13-4727 on ia32

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

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

Bug ID: 108141
   Summary: [13 Regression] gcc.target/i386/pr64110.c FAIL since
r13-4727 on ia32
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

On ia32, I get
+FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[t ]
starting with r13-4727-g12abd5a7d13209f79664ea603b3f3517f71b8c4f
The emitted code is quite different, though without larger analysis I can't
tell if it is worse or better.

[Bug testsuite/108141] [13 Regression] gcc.target/i386/pr64110.c FAIL since r13-4727 on ia32

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||vmakarov at gcc dot gnu.org
   Target Milestone|--- |13.0

[Bug testsuite/108141] [13 Regression] gcc.target/i386/pr64110.c FAIL since r13-4727 on ia32

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

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

--- Comment #1 from Jakub Jelinek  ---
Just counting number of instructions it is shorter though:
--- pr64110.s.r13-4726  2022-12-16 03:57:42.0 -0500
+++ pr64110.s.r13-4727  2022-12-16 03:57:48.0 -0500
@@ -11,106 +11,105 @@ bar:
pushl   %ebx
andl$-32, %esp
subl$64, %esp
-   movzwl  8(%ebp), %edi
+   movzwl  8(%ebp), %eax
+   movw%ax, 30(%esp)
movla, %eax
-   vmovd   %edi, %xmm1
+   vpbroadcastw30(%esp), %xmm2
+   vpbroadcastw30(%esp), %ymm0
leal-1(%eax), %edx
-   vmovd   %edi, %xmm0
movl%edx, a
-   vpbroadcastw%xmm1, %xmm1
-   vpbroadcastw%xmm0, %ymm0
+   vmovdqa %xmm2, (%esp)
testl   %eax, %eax
-   je  .L24
-   movw%di, 62(%esp)
-   vmovdqa %xmm1, 32(%esp)
-   vmovdqa %ymm0, (%esp)
-   vzeroupper
+   je  .L23
.p2align 4,,10
.p2align 3
 .L2:
+   vmovdqa %ymm0, 32(%esp)
+   vzeroupper
callfoo
+   vmovdqa 32(%esp), %ymm0
testl   %eax, %eax
jle .L3
-   leal-1(%eax), %edi
+   leal-1(%eax), %esi
movlb, %ebx
-   movl%edi, 52(%esp)
-   cmpl$14, %edi
+   movl%esi, 24(%esp)
+   cmpl$14, %esi
jbe .L10
movl%eax, %ecx
movl%ebx, %edx
shrl$4, %ecx
sall$5, %ecx
-   leal(%ecx,%ebx), %esi
+   leal(%ecx,%ebx), %edi
andl$32, %ecx
-   jne .L21
-   movzwl  62(%esp), %edi
-   vmovdqa (%esp), %ymm0
+   je  .L5
+   leal32(%ebx), %edx
+   vmovdqu %ymm0, (%ebx)
+   cmpl%edi, %edx
+   je  .L22
.p2align 4,,10
.p2align 3
 .L5:
vmovdqu %ymm0, (%edx)
addl$64, %edx
vmovdqu %ymm0, -32(%edx)
-   cmpl%esi, %edx
+   cmpl%edi, %edx
jne .L5
-   movw%di, 62(%esp)
 .L22:
movl%eax, %edx
andl$-16, %edx
-   movl%edx, %esi
+   movl%edx, %edi
leal(%ebx,%edx,2), %ecx
cmpl%edx, %eax
-   je  .L29
-   vzeroupper
+   je  .L6
 .L4:
-   movl%eax, %edi
-   subl%esi, %edi
-   movl%edi, 56(%esp)
-   decl%edi
-   cmpl$6, %edi
+   movl%eax, %esi
+   subl%edi, %esi
+   movl%esi, 32(%esp)
+   decl%esi
+   cmpl$6, %esi
jbe .L7
-   movl56(%esp), %edi
-   vmovdqa 32(%esp), %xmm2
-   vmovdqu %xmm2, (%ebx,%esi,2)
-   movl%edi, %esi
-   andl$-8, %esi
-   addl%esi, %edx
-   leal(%ecx,%esi,2), %ecx
-   movl%edi, %esi
-   andl$7, %esi
+   movl32(%esp), %esi
+   vmovdqa (%esp), %xmm1
+   vmovdqu %xmm1, (%ebx,%edi,2)
+   movl%esi, %edi
+   andl$-8, %edi
+   addl%edi, %edx
+   leal(%ecx,%edi,2), %ecx
+   movl%esi, %edi
+   andl$7, %edi
je  .L6
 .L7:
-   movzwl  62(%esp), %edi
-   leal1(%edx), %esi
-   movw%di, (%ecx)
-   cmpl%esi, %eax
-   jle .L6
-   leal2(%edx), %esi
-   movw%di, 2(%ecx)
-   cmpl%esi, %eax
-   jle .L6
-   leal3(%edx), %esi
-   movw%di, 4(%ecx)
-   cmpl%esi, %eax
-   jle .L6
-   leal4(%edx), %esi
-   movw%di, 6(%ecx)
-   cmpl%esi, %eax
-   jle .L6
-   leal5(%edx), %esi
-   movw%di, 8(%ecx)
-   cmpl%esi, %eax
+   movzwl  30(%esp), %esi
+   leal1(%edx), %edi
+   movw%si, (%ecx)
+   cmpl%edi, %eax
+   jle .L6
+   leal2(%edx), %edi
+   movw%si, 2(%ecx)
+   cmpl%edi, %eax
+   jle .L6
+   leal3(%edx), %edi
+   movw%si, 4(%ecx)
+   cmpl%edi, %eax
+   jle .L6
+   leal4(%edx), %edi
+   movw%si, 6(%ecx)
+   cmpl%edi, %eax
+   jle .L6
+   leal5(%edx), %edi
+   movw%si, 8(%ecx)
+   cmpl%edi, %eax
jle .L6
addl$6, %edx
-   movw%di, 10(%ecx)
+   movw%si, 10(%ecx)
cmpl%edx, %eax
jle .L6
-   movw%di, 12(%ecx)
+   movw%si, 12(%ecx)
 .L6:
leal(%ebx,%eax,2), %eax
-   movzwl  62(%esp), %ecx
+   movzwl  30(%esp), %ecx
movl%eax, b
-   movl52(%esp), %eax
+   movl24(%esp), %eax
movw%cx, (%ebx,%eax,2)
 .L3:
movla, %eax
@@ -118,39 +117,19 @@ bar:
movl%edx, a
testl   %eax, %eax
jne .L2
+.L23:
+   vzeroupper
leal-12(%ebp), %esp
popl%ebx
popl%esi
popl%edi
popl%ebp
ret
-   .p2align 4,,10
-   .p2align 3
-.L21:
-   vmovdqa (%esp), %ymm3
-

[Bug sanitizer/108106] [13 Regression] /usr/bin/ld: .libs/hwasan_setjmp_x86_64.o: relocation R_X86_64_PC32 against symbol `__interceptor_sigsetjmp' can not be used when making a shared object; recompi

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

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

--- Comment #5 from Jakub Jelinek  ---
protected visibility is almost always a bad answer for anything.
Wouldn't it be better to get rid of it in libhwasan and use something
different?
Say an hidden alias to an exported function?

[Bug rtl-optimization/106751] [10/11/12/13 Regression] internal compiler error: in purge_dead_edges with inline-asm goto

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

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

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

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

commit r13-4739-gddcaa60983b50378bde1b7e327086fe0ce101795
Author: Jakub Jelinek 
Date:   Fri Dec 16 10:19:22 2022 +0100

loop-invariant: Split preheader edge if the preheader bb ends with jump
[PR106751]

The RTL loop passes only request simple preheaders, but don't require
fallthru preheaders, while move_invariant_reg apparently assumes the
latter, that it can just append instruction(s) to the end of the preheader
basic block.

The following patch fixes that by splitting the preheader edge if
the preheader bb ends with a JUMP_INSN (asm goto in this case).
Without that we get control flow in the middle of a bb.

2022-12-16  Jakub Jelinek  

PR rtl-optimization/106751
* loop-invariant.cc (move_invariant_reg): If preheader bb ends
with a JUMP_INSN, split the preheader edge and emit invariants
into the new preheader basic block.

* gcc.c-torture/compile/pr106751.c: New test.

[Bug rtl-optimization/106751] [10/11/12 Regression] internal compiler error: in purge_dead_edges with inline-asm goto

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
   |internal compiler error: in |internal compiler error: in
   |purge_dead_edges with   |purge_dead_edges with
   |inline-asm goto |inline-asm goto

--- Comment #13 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/107065] GCC treats rvalue as an lvalue

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

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

--- Comment #15 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug tree-optimization/108095] powerpc-linux / powerpc64-linux: ICEs when building Linux's arch/powerpc/kernel/align.c (asm goto)

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

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

--- Comment #9 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug fortran/64290] [F03] No finalization at deallocation of LHS

[drikosev at gmail dot com via Gcc-bugs]

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

Ev Drikos  changed:

   What|Removed |Added

  Attachment #49990|0   |1
is obsolete||

--- Comment #6 from Ev Drikos  ---
Created attachment 54109
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54109&action=edit
Deallocation on Intrinsic Assignment

Hello, 

This message follows a post by P. Thomas to c.l.f:
https://groups.google.com/g/comp.lang.fortran/c/n62ukWe3TmY/m/5t4RWHELBAAJ

So, I'd like to add to this PR a patch with few relevant test cases. The test
case "realloc_class_8.f95" has been confirmed by feedback at:
https://fortran-lang.discourse.group/t/deallocation-on-intrinsic-assignment/567

Ev. Drikos

[Bug rtl-optimization/108086] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

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

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

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

https://gcc.gnu.org/g:340ddeae6611f6ab524211a009e97a85b4bba549

commit r13-4740-g340ddeae6611f6ab524211a009e97a85b4bba549
Author: Richard Biener 
Date:   Fri Dec 16 09:46:25 2022 +0100

middle-end/108086 - remove PR28238 fix superseeded by PR34018 fix

There's quite special code in copy_bb that handles inline substitution
of a non-invariant address in place of an invariant one that's
now handled by more generic handling of this case in remap_gimple_op_r
so this removes the special casing that happens in a hot path, providing
a small speedup.

PR middle-end/108086
* tree-inline.cc (copy_bb): Remove handling of (foo *)&this->m
substitution which is done in remap_gimple_op_r via
re-gimplifying.

[Bug middle-end/108140] ICE expanding __rbit

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org
   Keywords||ice-on-valid-code
  Component|c   |middle-end
 Target||aarch64-*-*
Summary|tzcnt gives different   |ICE expanding __rbit
   |result in debug vs release  |

--- Comment #4 from Alexander Monakov  ---
When comment #0 says "this crashes at -O2", it means ICE in expand for the
'__rbit' intrinsic on this testcase, which is reproducible on 12.2 and trunk:

#include
#include
int main(int argc, char *argv[])
{   
unsigned long long input = argc-1;
unsigned long long v = __clz(__rbit(input));
printf("%d %d\n", argc, v >= 64 ? 123 : 456);
}

I've edited the bug title to reflect this.

[Bug c++/108138] g++ 9+ takes 7-10x longer compiling constexpr

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

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

--- Comment #6 from Jonathan Wakely  ---
Just for the record, since nobody seems to have said it yet, the slowdown is
independent of the -std option. GCC 8 is fast even with -std=gnu++17 (instead
of the default gnu++14) and GCC 11 is slow even with -std=gnu++14 (instead of
the default -std=gnu++17).

[Bug libgomp/108098] OpenMP/nvptx reverse offload execution test FAILs

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-16

--- Comment #2 from Thomas Schwinge  ---
(In reply to Tom de Vries from comment #1)
> I'm not sure if it matters for triggering this problem

It doesn't:

> version:  440.118.02

Same set of FAILs.

[Bug modula2/108142] New: Many empty directories created in the build directory

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

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

Bug ID: 108142
   Summary: Many empty directories created in the build directory
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Seems a lot of new empty directories are created in the build directory during
toplevel configure:
stage{1,2,3,4}/m2
m2/ (lots of subdirectories)
They are created regardless of whether m2 is in --enable-languages= or not,
both when
using absolute pathnames and relative (/whatever/configure
--enable-languages=m2 or
../configure --enable-languages=m2 or ../configure --enable-languages=c etc.)
and from what I can see, they remain empty (don't contain any non-directories)
for the whole duration of build or bootstrap.
Can we get rid of those, or create them only before they'd be actually used?
And, preferably without those stage{1,2,3,4} toplevel directories at least (say
move the stages into m2/ or even gcc/m2 subdirectory of the build directory).

[Bug modula2/108143] New: LONGREAL and powerpc64le-linux

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

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

Bug ID: 108143
   Summary: LONGREAL and powerpc64le-linux
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

If LONGREAL in Modula-2 is the same type as C long double, I assume we have
with the libm2* libraries same problems we've dealt with in libstdc++-v3 with
r11-6169-g7c1e7eed891a7b8fd8 etc. for GCC 11 or in libgfortran with
r12-6492 through r12-6508 etc. for GCC 12, i.e. that the libraries will likely
only support the default configured ABI and will be ABI incompatible between
gcc configured
--with-long-double-format=ieee vs. --with-long-double-format=ibm (default).

[Bug modula2/108143] LONGREAL and powerpc64le-linux

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

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

--- Comment #1 from Richard Biener  ---
Since the frontend is "new" we might want to say m2 only supports IEEE long
double on powerpc?

[Bug modula2/108143] LONGREAL and powerpc64le-linux

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

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

--- Comment #2 from Jakub Jelinek  ---
For powerpc64le-linux, yes, sure.  The question is if Modula has any C (etc.)
interoperability and what would such a change mean to it.
And, long double uses in the library
find gcc/m2 -type f | xargs grep long.double | wc -l
222
seems to be in quite a few places, so some work would need to be done to
use some typedef that would be long double on most but _Float128 on
powerpc64le-linux.
Another problem is if the library uses libm that glibc only has the *f128
support
starting with glibc 2.26.  So question is what to do if gcc is configured
against older glibc.

[Bug testsuite/108141] [13 Regression] gcc.target/i386/pr64110.c FAIL since r13-4727 on ia32

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com
 Target||i?86-*-*

--- Comment #2 from Richard Biener  ---
it looks better overall but the key difference is:

-   movzwl  8(%ebp), %edi
+   movzwl  8(%ebp), %eax
+   movw%ax, 30(%esp)
...
-   vmovd   %edi, %xmm1
+   vpbroadcastw30(%esp), %xmm2
+   vpbroadcastw30(%esp), %ymm0
...
-   vmovd   %edi, %xmm0
...
-   vpbroadcastw%xmm1, %xmm1
-   vpbroadcastw%xmm0, %ymm0

I wonder whether optimal would be

vpbroadcasstw 8(%ebp), %xmm2
vpbroadcasstw 8(%ebp), %ymm0

though.

[Bug c++/108138] g++ 9+ takes 7-10x longer compiling constexpr

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #7 from Jonathan Wakely  ---
The slowdown began with r9-942-ge079dced7a8383

CWG 1581: When are constexpr member functions defined?

* constexpr.c (instantiate_cx_fn_r, instantiate_constexpr_fns):
New.
(cxx_eval_outermost_constant_expr): Call instantiate_constexpr_fns.

[Bug rtl-optimization/108086] [11/12/13 Regression] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|internal compiler error: in |[11/12/13 Regression]
   |set_accesses, at|internal compiler error: in
   |rtl-ssa/internals.inl:449   |set_accesses, at
   ||rtl-ssa/internals.inl:449
   Target Milestone|--- |11.4
  Known to fail||11.3.0
   Priority|P3  |P2
   Keywords|needs-reduction |ice-on-valid-code
  Known to work||10.4.0

--- Comment #12 from Richard Biener  ---
A regression from GCC 10 which compiles this in 90s at -O1.

Richard?  Can you please look at this special-case of BB0 insn_info?

[Bug rtl-optimization/108086] [11/12/13 Regression] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

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

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

--- Comment #13 from Richard Biener  ---
(In reply to Richard Biener from comment #12)
> A regression from GCC 10 which compiles this in 90s at -O1.
> 
> Richard?  Can you please look at this special-case of BB0 insn_info?

The following might be one way to "fix" it (until we do a bigger testcase)

diff --git a/gcc/rtl-ssa/insns.h b/gcc/rtl-ssa/insns.h
index f7215972845..b0144f258b2 100644
--- a/gcc/rtl-ssa/insns.h
+++ b/gcc/rtl-ssa/insns.h
@@ -403,8 +403,7 @@ private:
   // MAX_RECOG_OPERANDS is the maximum number of pseudos that can be
   // defined by an instruction, so the number of definitions should fit
   // easily in 16 bits.
-  unsigned int m_num_uses;
-  unsigned int m_num_defs : 16;
+  unsigned int m_num_uses : 24;

   // Flags returned by the accessors above.
   unsigned int m_is_debug_insn : 1;
@@ -412,9 +411,13 @@ private:
   unsigned int m_is_asm : 1;
   unsigned int m_has_pre_post_modify : 1;
   unsigned int m_has_volatile_refs : 1;
+  // For future expansion.
+  unsigned int m_spare : 3;

+  // Keep 32bit aligned
+  unsigned int m_num_defs : 24;
   // For future expansion.
-  unsigned int m_spare : 11;
+  unsigned int m_spare : 8;

   // The program point at which the instruction occurs.
   //

[Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs

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

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

Bug ID: 108144
   Summary: m2 does not respect
--enable-version-specific-runtime-libs
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

When I build Modula-2 with --enable-version-specific-runtime-libs and install
it, I get:

$ ~/bin/gcc> find . -name '*\.so*' | sort
...
./lib64/gcc/x86_64-pc-linux-gnu/libm2cor.so
./lib64/gcc/x86_64-pc-linux-gnu/libm2cor.so.17
./lib64/gcc/x86_64-pc-linux-gnu/libm2cor.so.17.0.0
./lib64/gcc/x86_64-pc-linux-gnu/libm2iso.so
./lib64/gcc/x86_64-pc-linux-gnu/libm2iso.so.17
./lib64/gcc/x86_64-pc-linux-gnu/libm2iso.so.17.0.0
./lib64/gcc/x86_64-pc-linux-gnu/libm2log.so
./lib64/gcc/x86_64-pc-linux-gnu/libm2log.so.17
./lib64/gcc/x86_64-pc-linux-gnu/libm2log.so.17.0.0
./lib64/gcc/x86_64-pc-linux-gnu/libm2min.so
./lib64/gcc/x86_64-pc-linux-gnu/libm2min.so.17
./lib64/gcc/x86_64-pc-linux-gnu/libm2min.so.17.0.0
./lib64/gcc/x86_64-pc-linux-gnu/libm2pim.so
./lib64/gcc/x86_64-pc-linux-gnu/libm2pim.so.17
./lib64/gcc/x86_64-pc-linux-gnu/libm2pim.so.17.0.0

while other libraries are properly placed under:

...
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libatomic.so.1
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libatomic.so.1.2.0
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libgomp.so
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libgomp.so.1
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libgomp.so.1.0.0
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libitm.so
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libitm.so.1
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libitm.so.1.0.0
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libquadmath.so
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libquadmath.so.0
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libquadmath.so.0.0.0
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libssp.so
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libssp.so.0
...

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |13.0
   Last reconfirmed||2022-12-16

[Bug testsuite/108141] [13 Regression] gcc.target/i386/pr64110.c FAIL since r13-4727 on ia32

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

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

--- Comment #3 from Jakub Jelinek  ---
Yeah.
For the PR64110:
typedef short V __attribute__((vector_size (32)));
V
foo (short x)
{
  return (V) { x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x };
}
we emit with -m64 -O2 -mavx2
vmovd   %edi, %xmm0
vpbroadcastw%xmm0, %ymm0
which is I think right and for -m32 -O2 -mavx2
vpbroadcastw8(%ebp), %ymm0
which again is optimal.
Though, in the pr64110.c test we went with -O3 -march=core-avx2 -m32
from r219682:
movzwl  (%ecx), %esi
movw%si, -28(%ebp)
vpbroadcastw-28(%ebp), %ymm1
vmovdqa %ymm1, -88(%ebp)
to r219683:
movzwl  (%ecx), %esi
vmovd   %esi, %xmm1
vpbroadcastw%xmm1, %ymm1
vmovdqa %ymm1, -88(%ebp)
to r13-4726:
movzwl  8(%ebp), %edi
vmovd   %edi, %xmm1
vpbroadcastw%xmm1, %xmm1
vmovdqa %xmm1, 32(%esp)
to r13-4727:
movzwl  8(%ebp), %eax
movw%ax, 30(%esp)
vpbroadcastw30(%esp), %xmm2
vmovdqa %xmm2, (%esp)
while
vpbroadcastw8(%ebp), %xmm2
vmovdqa %xmm2, (%esp)
would be best.  From this POV I think r13-4727 is actually a step backwards
because previously we were at least loading it into GPR, moving to SSE and
broadcasting there,
while now we move into GPR, spill to memory and broadcast from memory.
Before combine we have:
(insn 2 8 3 2 (set (reg:SI 120 [ x ])
(mem/c:SI (reg/f:SI 16 argp) [2 x+0 S4 A32])) "pr64110.c":11:1 83
{*movsi_internal}
 (nil))
(insn 3 2 4 2 (set (reg/v:HI 119 [ x ])
(subreg:HI (reg:SI 120 [ x ]) 0)) "pr64110.c":11:1 84 {*movhi_internal}
 (expr_list:REG_DEAD (reg:SI 120 [ x ])
(nil)))
...
and in another bb
(insn 63 140 35 3 (set (reg:V8HI 140)
(vec_duplicate:V8HI (reg/v:HI 119 [ x ]))) "pr64110.c":16:7 7985
{*vec_dupv8hi}
 (nil))
(insn 35 63 18 3 (set (reg:V16HI 141 [ vect_cst__52 ])
(vec_duplicate:V16HI (reg/v:HI 119 [ x ]))) 7984 {*vec_dupv16hi}
 (nil))
so I bet that is the reason why combine doesn't merge those into just the
broadcast.
As for the xmm vs. ymm, it is only loop-invariant that moves those 2 dups (insn
63 and 35) next to each other, and the question is what kind of optimization
pass could figure out that insn 35 is a superset of insn 63 and change it into
insn 35 + lowpart subreg to set pseudo 140 from low half of 141.

[Bug sanitizer/108072] [13 Regression] gcc/libbacktrace/elf.c:5144: multiple definition of `backtrace_uncompress_zstd' with --with-build-config=bootstrap-asan since r13-4547-g9df1ba9a35b86e

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug testsuite/108141] [13 Regression] gcc.target/i386/pr64110.c FAIL since r13-4727 on ia32

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

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

--- Comment #4 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #3)
[...]
... From this POV I think r13-4727 is actually a step backwards
> because previously we were at least loading it into GPR, moving to SSE and
> broadcasting there,
> while now we move into GPR, spill to memory and broadcast from memory.
> Before combine we have:
> (insn 2 8 3 2 (set (reg:SI 120 [ x ])
> (mem/c:SI (reg/f:SI 16 argp) [2 x+0 S4 A32])) "pr64110.c":11:1 83
> {*movsi_internal}
>  (nil))
> (insn 3 2 4 2 (set (reg/v:HI 119 [ x ])
> (subreg:HI (reg:SI 120 [ x ]) 0)) "pr64110.c":11:1 84
> {*movhi_internal}
>  (expr_list:REG_DEAD (reg:SI 120 [ x ])
> (nil)))
> ...
> and in another bb
> (insn 63 140 35 3 (set (reg:V8HI 140)
> (vec_duplicate:V8HI (reg/v:HI 119 [ x ]))) "pr64110.c":16:7 7985
> {*vec_dupv8hi}
>  (nil))
> (insn 35 63 18 3 (set (reg:V16HI 141 [ vect_cst__52 ])
> (vec_duplicate:V16HI (reg/v:HI 119 [ x ]))) 7984 {*vec_dupv16hi}
>  (nil))
> so I bet that is the reason why combine doesn't merge those into just the
> broadcast.

Yep.  And probably fwprop doesnt consider MEMs (or even two defs) at all.
I suppose we don't want to combine insn 2 + 3 into a HImode MEM by itself?
OTOH there's no fwprop after combine.

> As for the xmm vs. ymm, it is only loop-invariant that moves those 2 dups
> (insn 63 and 35) next to each other, and the question is what kind of
> optimization pass could figure out that insn 35 is a superset of insn 63 and
> change it into insn 35 + lowpart subreg to set pseudo 140 from low half of
> 141.

There's only a peephole or alternatively scheduling heuristic + CSE (we
need the V16HI duplicate before the V8HI one) I can think of.

CSE could also tentatively record "larger" computations and modify the
earlier stmt if uses of that larger compute appears.

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

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

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

--- Comment #1 from Richard Biener  ---
I think libatomic configure.ac / Makefile.am has the bits to copy here.

[Bug middle-end/108140] ICE expanding __rbit

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |12.3
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-12-16
 Status|UNCONFIRMED |ASSIGNED

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Confirmed the ICE and I'm testing a patch to fix that, thanks for the report

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

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

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

--- Comment #2 from Richard Biener  ---
but the code is there, maybe it's confused by the subdirs?

[Bug ipa/108130] [13 Regression] LTO compile time hog seen on bootstrap-lto config since r13-4684-g7450b25566b7a7

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

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

--- Comment #1 from Richard Biener  ---
We probably have all the "external" summaries multiple times now?

[Bug rtl-optimization/108086] [11/12/13 Regression] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

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

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

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

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

commit r13-4743-gda85bfc75024a92b97e60e4436863dd5789786ec
Author: Richard Biener 
Date:   Fri Dec 16 13:01:40 2022 +0100

middle-end/108086 - avoid unshare_expr when remapping SSA names

r0-89280-g129a37fc319db8 added unsharing to remap_ssa_name but
that wasn't in the version of the patch posted.  That has some
non-trivial cost through mostly_copy_tree_r and copy_tree_r but
more importantly it doesn't seem to be necessary.  I've successfully
bootstrapped and tested with an assert we only get
tree_node_can_be_shared trees here.

Bootstrapped and tested on x86_64-unknown-linux-gnu with all
languages.

PR middle-end/108086
* tree-inline.cc (remap_ssa_name): Do not unshare the
result from the decl_map.

[Bug tree-optimization/108139] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1938-g87dd4c8c83768aaf

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[13 Regression] wrong code  |[13 Regression] wrong code
   |with "-O1 -ftree-vrp" on|with "-O1 -ftree-vrp" on
   |x86_64-linux-gnu|x86_64-linux-gnu since
   ||r13-1938-g87dd4c8c83768aaf
   Keywords|needs-bisection |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-16
 Ever confirmed|0   |1
 CC||amacleod at redhat dot com,
   ||marxin at gcc dot gnu.org
   Priority|P3  |P1

--- Comment #1 from Martin Liška  ---
Started with r13-1938-g87dd4c8c83768aaf.

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

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

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

--- Comment #3 from Gaius Mulley  ---
Awesome - thanks for the pointer - will examine the subdirs problem
simultaneously

[Bug c++/108138] g++ 9+ takes 7-10x longer compiling constexpr

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-16
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org

[Bug c++/108138] g++ 9+ takes 7-10x longer compiling constexpr

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

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

--- Comment #8 from Martin Liška  ---
(In reply to Andrew Pinski from comment #4)
> I think it was fixed by the patch which fixed/improved PR 102780:
> r12-4769-g9927ecbb42d5b

I can confirm this!

[Bug c/108043] [13 Regression] ICE: in fold_convert_loc, at fold-const.cc:2618 on invalid function braced initializer since r13-2205-g14cfa01755a66afb

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.
Both C99 and C2X say for compound literals:
The type name shall specify an object type or an array of unknown size, but not
a variable length array type.
resp.
The type name shall specify a complete object type or an array of unknown size,
but not a variable length array type.
Before the recent changes it actually wasn't that important to diagnose
non-object type because the initializer had to be non-empty in that case and
there was no way to specify initializer expression of function type as it would
promote to function pointer type, so we'd error differently.
But when empty initializers are allowed, there is nothing to diagnose that.

[Bug tree-optimization/108137] [12/13 Regression] ICE: segfault during GIMPLE pass: warn-printf since r12-523-g2254b3233b5bfa69

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[12/13 Regression] ICE: |[12/13 Regression] ICE:
   |segfault during GIMPLE  |segfault during GIMPLE
   |pass: warn-printf   |pass: warn-printf since
   ||r12-523-g2254b3233b5bfa69
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started with r12-523-g2254b3233b5bfa69.

[Bug tree-optimization/108137] [12/13 Regression] ICE: segfault during GIMPLE pass: warn-printf since r12-523-g2254b3233b5bfa69

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
I can fix that.

[Bug target/108145] New: [13 regression] ICE in from_reg_br_prob_base, at profile-count.h:259

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

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

Bug ID: 108145
   Summary: [13 regression] ICE in from_reg_br_prob_base, at
profile-count.h:259
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.11

Between 20221214 (330b9a8d87dd73e10539da618496ad4964fee26d) and 20221216
(711e0acdbb2645f5a8aa89014488c24e89ccb0f7), Solaris/x86 bootstrap broke
building
the 64-bit gmon.o.

$ cc1 -fpreprocessed gmon.i -quiet -m64 -mtune=generic -march=x86-64 -O2 -o
gmon.s
[...]
during RTL pass: expand
/vol/gcc/src/hg/master/local/libgcc/config/sol2/gmon.c: In function
‘monstartup’:
/vol/gcc/src/hg/master/local/libgcc/config/sol2/gmon.c:150:1: internal compiler
error: in from_reg_br_prob_base, at profile-count.h:259
  150 | }
  | ^

Thread 2 hit Breakpoint 1, 0x0a514206 in fancy_abort(char const*, int, char
const*) ()
(gdb) bt
#0  0x0a514206 in fancy_abort(char const*, int, char const*) ()
#1  0x0926e3b4 in profile_probability::from_reg_br_prob_base(int) [clone
.part.0] ()
#2  0x0926ed0e in guess_outgoing_edge_probabilities(basic_block_def*) [clone
.cold] ()
#3  0x0a225ee3 in find_many_sub_basic_blocks(simple_bitmap_def*) ()
#4  0x08dca2e2 in (anonymous namespace)::pass_expand::execute(function*) ()
#5  0x0923de4f in execute_one_pass(opt_pass*) ()
#6  0x0923e795 in execute_pass_list_1(opt_pass*) ()
#7  0x0923e7de in execute_pass_list(function*, opt_pass*) ()
#8  0x08e10c74 in cgraph_node::expand() ()
#9  0x08e121a9 in symbol_table::compile() [clone .part.0] ()
#10 0x08e14b96 in symbol_table::finalize_compilation_unit() ()
#11 0x09346fe1 in compile_file() ()
#12 0x0934a28e in toplev::main(int, char**) ()
#13 0x0a4f0761 in main ()

[Bug target/108145] [13 regression] ICE in from_reg_br_prob_base, at profile-count.h:259

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

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

--- Comment #1 from Rainer Orth  ---
Created attachment 54111
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54111&action=edit
preprocessed input

[Bug target/108145] [13 regression] ICE in from_reg_br_prob_base, at profile-count.h:259

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug gcov-profile/108146] New: gcc -pg does not produce gmon.out

[Sid.Touati at inria dot fr via Gcc-bugs]

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

Bug ID: 108146
   Summary: gcc -pg does not produce gmon.out
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Sid.Touati at inria dot fr
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54112
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54112&action=edit
source code (C and h files) + makefile. Just type make, then run a.out.

Hi,
please find enclosed my archive that contains my source files and make.
Juste type make to generate a.out, then execute a.out to see the problem.

The problem is that the file gmon.out is not generated. I checked the assembly
generated by gcc, gmon functions are inserted correctly. When I debug the
binary code, it seems that gmon functions are not called... This is a nightmare
to understand why :)

I checked that this problem does not happen with many other C applications. I
do not understand why it happens here. I checked this "bug" on two distinct
machines. 

Here is my current configuration: 
touati@:~/tmp/mypb> uname -a
Linux  6.0.12-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Dec 8 16:58:47 UTC
2022 x86_64 x86_64 x86_64 GNU/Linux

It is a fedora 37 workstation.

Maybe it is a bug in "gcc -pg". 

Regards
S.T.

[Bug libgomp/108098] OpenMP/nvptx reverse offload execution test FAILs

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

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

--- Comment #3 from Tobias Burnus  ---
The problem - at least when testing on a system with:
  NVIDIA-SMI 440.118.02   Driver Version: 440.118.02   CUDA Version: 10.2

seems to be that libgomp/plugin/plugin-nvptx.c's GOMP_OFFLOAD_load_image has:

   fn_entries == 3 - and rev_fn_table != NULL (i.e. expect offloading)

and then runs:

  r = CUDA_CALL_NOCHECK (cuModuleGetGlobal, &var, &bytes, module,
 "$offload_func_table");
  if (r != CUDA_SUCCESS)
GOMP_PLUGIN_fatal ("cuModuleGetGlobal error: %s", cuda_error (r));
  assert (bytes == sizeof (uint64_t) * fn_entries);
  *rev_fn_table = GOMP_PLUGIN_malloc (sizeof (uint64_t) * fn_entries);
  r = CUDA_CALL_NOCHECK (cuMemcpyDtoH, *rev_fn_table, var, bytes);
  if (r != CUDA_SUCCESS)
GOMP_PLUGIN_fatal ("cuMemcpyDtoH error: %s", cuda_error (r));

So far so good - but all entries are NULL. This then disables the checking for
reverse offload on the host side. (It is not quite clear to me why it doesn't
run into an endless loop on the device side.)

The generated PTX code for reverse-offload-1{,-aux}.c is for that offload
table:

".version 6.0"
".target sm_35"
".file 1 \"\""
".extern .func tg_fn$_omp_fn$0$nohost$0 (.param .u64 %in_ar0);"
".extern .func main$_omp_fn$2$nohost$1 (.param .u64 %in_ar0);"
".visible .global .align 8 .u64 $offload_func_table[] = {"
"tg_fn$_omp_fn$0$nohost$0,"
"main$_omp_fn$2$nohost$1,"
"0,"
"0};\n";

which seems to be OK – and works with CUDA 11.  It looks as if the '>= sm_35'
is only one required criterion but that there are additional ones.

 * * *

I am relatively sure that it did work before, but it could well be that I only
checked that the device->host notification worked w/o trying any actual offload
(and before adding all NULL -> no reverse offload). And later when doing the
actual offload tests, I might have missed that machine. — Or I did something
different back then, but I don't know what.

 * * *

In patch "nvptx: Support global constructors/destructors via 'collect2'",
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607749.html , Thomas
uses a dummy entry - possibly that would be also a solution:

+/* For example with old Nvidia Tesla K20c, Driver Version: 361.93.02, the
+   function pointers stored in the '__CTOR_LIST__', '__DTOR_LIST__' arrays
+   evidently evaluate to NULL in JIT compilation.  Avoiding the use of
+   assembler names ('write_list_with_asm') doesn't help, but defining a dummy
+   function next to the arrays apparently does work around this issue...

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #10 from Jakub Jelinek  ---
Some extra food for thought:
void bar (void);

void
foo (double x)
{
  if (x >= -16.0 && x <= 16.0)
{
  double y = x + 32.0;
  double z = y * 42.5;
  if (z < 600.0 || z > 3000.0)
bar ();
}
}
with the usual default -O2 aka -O2 -ftrapping-math.
frange can correctly prove that bar () will be never called and with -O2
-fno-trapping-math it is perfectly fine to optimize the whole function out, z
is known to be [680., 2040.] and not NaN.
Now, even the comparisons aren't strictly needed, comparisons trap only on NaNs
(< and > are not quiet, so any kind of them, but after all, frange doesn't
track sNaNs vs. qNaNs) and we know z is not NaN.  But x comparisons can raise
invalid on NaNs (both qNaN and sNaN), the addition is known not to raise
invalid (x is not NaN), nor overflow (limited range), not sure right now if it
can raise underflow or inexact, but at least the latter quite possibly.  The
multiplication I'm quite sure can raise inexact though,
so I think we need to keep everything until the z = computation, and either
replace the comparison(s) of z with some dummy (asm?) use of z, or keep the
comparisons but say turn the bar () call into __builtin_unreachable () or
__builtin_trap () and make sure we don't optimize away the former later?

The reason I want to show this is mainly that even when the actual operation
(comparisons here) we'd like to fold into constant are known not to raise any
exceptions (and we should use frange info to find that out), it might be some
intermediate calculation that might still raise exceptions.

I was considering to do some hack at least in my Fedora test mass rebuilds this
month like for flag_trapping_math pretend no floating point range is singleton,
but that still wouldn't cover comparisons.

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #11 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #10)
> Some extra food for thought:
> void bar (void);
> 
> void
> foo (double x)
> {
>   if (x >= -16.0 && x <= 16.0)
> {
>   double y = x + 32.0;
>   double z = y * 42.5;
>   if (z < 600.0 || z > 3000.0)
>   bar ();
> }
> }
> with the usual default -O2 aka -O2 -ftrapping-math.
> frange can correctly prove that bar () will be never called and with -O2
> -fno-trapping-math it is perfectly fine to optimize the whole function out,
> z is known to be [680., 2040.] and not NaN.
> Now, even the comparisons aren't strictly needed, comparisons trap only on
> NaNs
> (< and > are not quiet, so any kind of them, but after all, frange doesn't
> track sNaNs vs. qNaNs) and we know z is not NaN.  But x comparisons can
> raise invalid on NaNs (both qNaN and sNaN), the addition is known not to
> raise invalid (x is not NaN), nor overflow (limited range), not sure right
> now if it can raise underflow or inexact, but at least the latter quite
> possibly.  The multiplication I'm quite sure can raise inexact though,
> so I think we need to keep everything until the z = computation, and either
> replace the comparison(s) of z with some dummy (asm?) use of z, or keep the
> comparisons but say turn the bar () call into __builtin_unreachable () or
> __builtin_trap () and make sure we don't optimize away the former later?
> 
> The reason I want to show this is mainly that even when the actual operation
> (comparisons here) we'd like to fold into constant are known not to raise
> any exceptions (and we should use frange info to find that out), it might be
> some intermediate calculation that might still raise exceptions.
> 
> I was considering to do some hack at least in my Fedora test mass rebuilds
> this month like for flag_trapping_math pretend no floating point range is
> singleton, but that still wouldn't cover comparisons.

For the comparisons I think we need to split them out of the GIMPLE_COND
(who do not have side-effects), so like with -fnon-call-exceptions do

_3 = z < 6.0e+2;
if (_3 != 0) goto ; else goto ;

then we can simplify the GIMPLE_CONDs just fine, we just need to keep
the comparison in some way.

For sNaN vs. qNaN I suppose we can use a tree predicate and go by
the kind of definition we see - sNaNs can only appear via a few
constrained operations (loads and init from a sNaN literal).

[Bug sanitizer/108106] [13 Regression] /usr/bin/ld: .libs/hwasan_setjmp_x86_64.o: relocation R_X86_64_PC32 against symbol `__interceptor_sigsetjmp' can not be used when making a shared object; recompi

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

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

--- Comment #6 from Thomas Schwinge  ---
Comment on attachment 54106
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54106
An updated patch

Yes, that does resolve the the libsanitizer/HWASan build failure.

[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #16 from Georg-Johann Lay  ---
Created attachment 54113
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54113&action=edit
More elaborate C test case.

This is a more complicated test case, compile with

> avr-gcc -c pi-i.c -mmcu=atmega8 -Os -mcall-prologues -fno-tree-loop-optimize 
> -fno-move-loop-invariants && avr-size pi-i.o

Code sizes are:

664 with avr-gcc v8.5
992 with avr-gcc v11.3
834 with avr-gcc master with the change from comment #13

So there is a clear improvement with patch #13, but size is still +25% compared
to v8. What also has an effect is -fno-split-wide-types.

The test case mostly operates on float; unfortunately I don't have a similar
test-case for 32-bit integers at hand.

[Bug gcov-profile/108146] gcc -pg does not produce gmon.out

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Hey, it's related to the fact the mcount in glibc enters GMON_PROF_ERROR state.
That happens in:

(gdb) bt
#0  __mcount_internal (frompc=, selfpc=5075099) at mcount.c:173
#1  0x15407968 in mcount () at ../sysdeps/x86_64/_mcount.S:50
#2  0x004d709b in updateExclu (data=0x7ffd3b18, res=0x7ffcc5c0)
at main.c:64359
#3  0x004b8e25 in main (argc=1, argv=0x7fffd758) at main.c:54437

(gdb) p _gmonparam.state
$10 = 2

And that's why no gmon.out file is created. Please report it to glibc guys.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

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

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

Bug 108127 Summary: FP due to combination of -Warray-bounds and UBSAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108127

   What|Removed |Added

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

[Bug middle-end/108127] FP due to combination of -Warray-bounds and UBSAN

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Martin Liška  ---
It's expected behavior.

[Bug libgcc/108146] gcc -pg does not produce gmon.out

[Sid.Touati at inria dot fr via Gcc-bugs]

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

Sid.Touati at inria dot fr changed:

   What|Removed |Added

  Component|gcov-profile|libgcc

--- Comment #2 from Sid.Touati at inria dot fr ---
Hi,
this bug has been reported to the gcov-profile component [Bug
gcov-profile/108146], Martin Liška found that it is more appropriate to submit
it to glibC guys. 

could you check it please ?

Regards
S.

[Bug libstdc++/108118] std::weak_ptr lacks a self-usurp check on move

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

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

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

https://gcc.gnu.org/g:92eb0adc14a5f84acce7e5bc780b81b1544b24aa

commit r13-4745-g92eb0adc14a5f84acce7e5bc780b81b1544b24aa
Author: Jonathan Wakely 
Date:   Thu Dec 15 09:52:48 2022 +

libstdc++: Fix self-move for std::weak_ptr [PR108118]

I think an alternative fix would be something like:

  _M_ptr = std::exchange(rhs._M_ptr, nullptr);
  _M_refcount = std::move(rhs._M_refcount);

The standard's move-and-swap implementation generates smaller code at
all levels except -O0 and -Og, so it seems simplest to just do what the
standard says.

libstdc++-v3/ChangeLog:

PR libstdc++/108118
* include/bits/shared_ptr_base.h (weak_ptr::operator=):
Implement as move-and-swap exactly as specified in the standard.
* testsuite/20_util/weak_ptr/cons/self_move.cc: New test.

[Bug c++/108138] g++ 9+ takes 7-10x longer compiling constexpr

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #9 from Patrick Palka  ---
I'll look into backporting the PR102780 fix

[Bug libgomp/108098] OpenMP/nvptx reverse offload execution test FAILs

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

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

--- Comment #4 from Tobias Burnus  ---
Indeed, the following seems to also help with an older CUDA / JIT compiler.
Motivated by Thomas' work.

If we are sure that CUDA 11.0 fixes it, we could generate that code only for:

  if (version2[0] < 7 || sm_ver2[0] < 8)

given that sm_80 is only supported since CUDA 11.0 and, likewise, CUDA 11.0
introduces PTX ISA version 7.0.

--- a/gcc/config/nvptx/mkoffload.cc
+++ b/gcc/config/nvptx/mkoffload.cc
@@ -358,4 +358,9 @@ process (FILE *in, FILE *out, uint32_t omp_requires)
   fprintf (out, "\"\n\t\".file 1 \\\"\\\"\"\n");

+  fprintf (out, "\n\t\".func __dummy$func ( );\"\n");
+  fprintf (out, "\t\".func __dummy$func ( )\"\n");
+  fprintf (out, "\t\"{\"\n");
+  fprintf (out, "\t\"}\"\n");
+
   size_t fidx = 0;
   for (id = func_ids; id; id = id->next)

[Bug modula2/108143] LONGREAL and powerpc64le-linux

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

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

--- Comment #3 from Gaius Mulley  ---
> find gcc/m2 -type f | xargs grep long.double | wc -l
> 222

its not perhaps quite as bad as 222, I think 100 cases as the directories
pge-boot and mc-boot contain machine generated source code. 

find gcc/m2/pge-boot -type f | xargs grep long.double | wc -l
69
find gcc/m2/mc-boot -type f | xargs grep long.double | wc -l
53

happy to defer to your knowledge and implement what is decided

[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate

[m101010a at gmail dot com via Gcc-bugs]

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

m101010a at gmail dot com changed:

   What|Removed |Added

 CC||m101010a at gmail dot com

--- Comment #7 from m101010a at gmail dot com ---
I have written a GCC plugin (available at
https://github.com/m42a/gcc-noexcept-plugin ) based on comment #6 that
consistently prevents stack unwinding in this case.

[Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2

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

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

Bug ID: 108147
   Summary: Bootstrap failure on powerpc64le-linux with m2
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Bootstrap fails on powerpc64le-linux when modula 2 is enabled.
../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release
--enable-targets=powerpcle-linux --disable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-gcc-major-version-only
--enable-libstdcxx-backtrace --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-13.0.0-20221215/obj-ppc64le-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-secureplt
--with-long-double-128 --with-long-double-format=ieee --with-cpu-32=power8
--with-tune-32=power8 --with-cpu-64=power8 --with-tune-64=power8
--build=ppc64le-redhat-linux
and the ICE I get is on:
/builddir/build/BUILD/gcc-13.0.0-20221215/obj-ppc64le-redhat-linux/./gcc/gm2
-B/builddir/build/BUILD/gcc-13.0.0-20221215/obj-ppc64le-redhat-linux/./gcc/ -c
-O2 -fexceptions -g -grecord-gcc-switches -Wall -Wformat-security
-Wp,-D_GLIBCXX_ASSERTIONS -mcpu=power8 -mtune=power8
-fasynchronous-unwind-tables -fstack-clash-protection -O2 -fexceptions -g
-grecord-gcc-switches -Wall -Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS
-mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables
-fstack-clash-protection -I.
-I/builddir/build/BUILD/gcc-13.0.0-20221215/gcc/m2/gm2-libs-min
-I/builddir/build/BUILD/gcc-13.0.0-20221215/gcc/m2/gm2-libs -fno-exceptions
-fno-m2-plugin -fno-scaffold-dynamic -fno-scaffold-main
../../../../libgm2/libm2min/../../gcc/m2/gm2-libs-min/M2RTS.mod -o M2RTS.lo
/builddir/build/BUILD/gcc-13.0.0-20221215/obj-ppc64le-redhat-linux/./gcc/cc1gm2
-msecure-plt -quiet -dumpbase M2RTS.mod -dumpbase-ext .mod -mcpu=power8
-mtune=power8 -mcpu=power8 -mtune=power8 -g -g -grecord-gcc-switches -O2 -O2
-Wall -Wformat-security -version -fasynchronous-unwind-tables
-fstack-clash-protection -fno-exceptions -fno-m2-plugin -fno-scaffold-dynamic
-fno-scaffold-main -B
/builddir/build/BUILD/gcc-13.0.0-20221215/obj-ppc64le-redhat-linux/./gcc/ -c
-fasynchronous-unwind-tables -fstack-clash-protection -fno-exceptions
-fno-m2-plugin -fno-scaffold-dynamic -fno-scaffold-main -I . -I
/builddir/build/BUILD/gcc-13.0.0-20221215/gcc/m2/gm2-libs-min -I
/builddir/build/BUILD/gcc-13.0.0-20221215/gcc/m2/gm2-libs -I
/usr/lib/gcc/ppc64le-redhat-linux/13/tune=power8/m2/m2pim -I
/usr/lib/gcc/ppc64le-redhat-linux/13/tune=power8/m2/m2log -I
/usr/lib/gcc/ppc64le-redhat-linux/13/tune=power8/m2/m2iso
../../../../libgm2/libm2min/../../gcc/m2/gm2-libs-min/M2RTS.mod -o
/tmp/ccAHJQJE.s
cc1gm2: warning: command-line option '-Wformat-security' is valid for
C/C++/ObjC/ObjC++ but not for Modula-2
GNU Modula-2 (GCC) version 13.0.0 20221215 (Red Hat 13.0.0-0)
(ppc64le-redhat-linux)
compiled by GNU C version 13.0.0 20221215 (Red Hat 13.0.0-0), GMP
version 6.2.1, MPFR version 4.1.1-p1, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Modula-2 (GCC) version 13.0.0 20221215 (Red Hat 13.0.0-0)
(ppc64le-redhat-linux)
compiled by GNU C version 13.0.0 20221215 (Red Hat 13.0.0-0), GMP
version 6.2.1, MPFR version 4.1.1-p1, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
/builddir/build/BUILD/gcc-13.0.0-20221215/gcc/m2/gm2-libs-min/M2RTS.def:41:27:
warning: In procedure 'RegisterModule': unused parameter 'name' in procedure
'RegisterModule'
   41 | PROCEDURE RegisterModule (name: ADDRESS;
  |   ^~~~
terminate called after throwing an instance of 'unsigned int'
cc1gm2: internal compiler error: Aborted
0x103c716b crash_signal
../../gcc/toplev.cc:317
0x116465d7 __gnu_cxx::__verbose_terminate_handler()
../../../../libstdc++-v3/libsupc++/vterminate.cc:95
0x11644e13 __cxxabiv1::__terminate(void (*)())
../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
0x11644edf std::terminate()
../../../../libstdc++-v3/libsupc++/eh_terminate.cc:58
0x116451a3 __cxa_throw
../../../../libstdc++-v3/libsupc++/eh_throw.cc:98
0x111327df InvokeHandler
m2/gm2-libs-boot/RTExceptions.c:483
0x111327df RTExceptions_Raise
m2/gm2-libs-boot/RTExceptions.c:943
0x1113a717 sigbusDespatcher
../../gcc/m2/gm2-libs-ch/SysExceptio

[Bug modula2/108143] LONGREAL and powerpc64le-linux

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

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

--- Comment #4 from Segher Boessenkool  ---
(In reply to Richard Biener from comment #1)
> Since the frontend is "new" we might want to say m2 only supports IEEE long
> double on powerpc?

No, the vast majority of powerpc*-* targets only supports double and/or
double-double as long double.

[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2

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

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

--- Comment #1 from Jakub Jelinek  ---
The ICE seems to be during
#0  0x10ffc2e8 in m2linemap_WarningAtf (location=456515,
message=0x11f57210 "In procedure 'RegisterModule': unused parameter 'name' in
procedure 'RegisterModule'")
at ../../gcc/m2/gm2-gcc/m2linemap.cc:202
#1  0xbb08 in M2Emit_EmitError (error=,
note=, token=, message=) at
m2/gm2-compiler-boot/M2Emit.c:85
#2  0x1102fb0c in FlushAll (e=0x11f52ee0, FatalStatus=0) at
m2/gm2-compiler-boot/M2Error.c:2418
#3  0x1102c2c0 in Compile (s=0x11f06160) at
m2/gm2-compiler-boot/M2Comp.c:208
#4  M2Comp_compile (filename=) at
m2/gm2-compiler-boot/M2Comp.c:760
#5  0x11007048 in init_PerCompilationInit (filename=0x7641
"../../../../libgm2/libm2min/../../gcc/m2/gm2-libs-min/M2RTS.mod") at
../../gcc/m2/gm2-gcc/init.cc:195
#6  0x10fd505c in gm2_parse_input_files (filename_count=1,
filenames=0x11ef2fd0) at ../../gcc/m2/gm2-lang.cc:451
#7  gm2_langhook_parse_file () at ../../gcc/m2/gm2-lang.cc:458
#8  0x1127f54c in compile_file () at ../../gcc/toplev.cc:447
#9  0x10892d0c in do_compile (no_backend=false) at
../../gcc/toplev.cc:2128
#10 toplev::main (this=, argc=, argv=) at ../../gcc/toplev.cc:2282
#11 0x10895c98 in main (argc=49, argv=0x7fffee38) at
../../gcc/main.cc:39
in particular in:
#0  vec::using_auto_storage (this=) at ../../gcc/vec.h:2218
#1  vec::release (this=0x7fffe570) at
../../gcc/vec.h:1909
#2  auto_vec::~auto_vec (this=0x7fffe570,
__in_chrg=) at ../../gcc/vec.h:1574
#3  diagnostic_info::inlining_info::~inlining_info (this=0x7fffe570,
__in_chrg=) at ../../gcc/diagnostic.h:137
#4  diagnostic_info::~diagnostic_info (this=0x7fffe528,
__in_chrg=) at ../../gcc/diagnostic.h:111
#5  m2linemap_WarningAtf (location=, message=0x11f57210 "In
procedure 'RegisterModule': unused parameter 'name' in procedure
'RegisterModule'")
at ../../gcc/m2/gm2-gcc/m2linemap.cc:211
inside of that.
Seems the problem is that the return address is clobbered on the stack.
M2Emit_EmitError at the start saves the link register to 16(r1):
   0xbab0 :lis r2,4563
   0xbab4 :addir2,r2,29696
=> 0xbab8 :mflrr0
   0xbabc :   std r31,-8(r1)
   0xbac0 :   std r0,16(r1)
(0x1102fb0c is stored to 0x7fffe610 in my case).
But then:
Dump of assembler code for function m2linemap_WarningAtf(location_t, char
const*, ...):
   0x10ffc2e0 <+0>: lis r2,4563
   0x10ffc2e4 <+4>: addir2,r2,29696
   0x10ffc2e8 <+8>: mflrr0
   0x10ffc2ec <+12>:std r30,-16(r1)
   0x10ffc2f0 <+16>:std r31,-8(r1)
   0x10ffc2f4 <+20>:std r0,16(r1)
   0x10ffc2f8 <+24>:stdur1,-368(r1)
   0x10ffc2fc <+28>:vspltisw v0,0
   0x10ffc300 <+32>:lis r11,-32768
   0x10ffc304 <+36>:mr  r30,r4
   0x10ffc308 <+40>:ori r11,r11,8
   0x10ffc30c <+44>:std r5,416(r1)
   0x10ffc310 <+48>:std r6,424(r1)
   0x10ffc314 <+52>:xxswapd vs0,vs32
   0x10ffc318 <+56>:li  r0,0
   0x10ffc31c <+60>:clrldi  r11,r11,32
   0x10ffc320 <+64>:std r7,432(r1)
=> 0x10ffc324 <+68>:std r8,440(r1)
overwrites it.
Now the sizes of the automatic variables in m2linemap_WarningAtf are:
(gdb) p sizeof (diagnostic)
$42 = 136
(gdb) p sizeof (ap)
$43 = 8
(gdb) p sizeof (richloc)
$44 = 168
sum 312 bytes, the frame is 368 bytes.  But where do those std r{5,6,7,8}
stores to 4{16,24,32,40}(r1) come from is something I haven't figured out yet,
probably register saves, but why does that overwrite the saved link register?

[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2

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

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

--- Comment #2 from Jakub Jelinek  ---
M2Emit_EmitError is:
71  extern "C" void M2Emit_EmitError (unsigned int error, unsigned int
note, unsigned int token, DynamicStrings_String message)
72  {
73if (error)
74  {
75m2linemap_ErrorAtf (M2LexBuf_TokenToLocation (token),
DynamicStrings_string (message));
76  }
77else if (note)
78  {
79/* avoid dangling else.  */
80m2linemap_NoteAtf (M2LexBuf_TokenToLocation (token),
DynamicStrings_string (message));
81  }
82else
83  {
84/* avoid dangling else.  */
85m2linemap_WarningAtf (M2LexBuf_TokenToLocation (token),
DynamicStrings_string (message));
86  }
87  }
Dump of assembler code for function M2Emit_EmitError(unsigned int, unsigned
int, unsigned int, DynamicStrings_String):
   0xbab0 <+0>: lis r2,4563
   0xbab4 <+4>: addir2,r2,29696
   0xbab8 <+8>: mflrr0
   0xbabc <+12>:std r31,-8(r1)
   0xbac0 <+16>:std r0,16(r1)
   0xbac4 <+20>:stdur1,-48(r1)
   0xbac8 <+24>:cmpdi   r3,0
   0xbacc <+28>:mr  r31,r6
   0xbad0 <+32>:mr  r3,r5
   0xbad4 <+36>:bne 0xbb60 
   0xbad8 <+40>:cmpdi   r4,0
   0xbadc <+44>:bne 0xbb20 
   0xbae0 <+48>:bl  0x11054d48

   0xbae4 <+52>:nop
   0xbae8 <+56>:mr  r9,r3
   0xbaec <+60>:mr  r3,r31
   0xbaf0 <+64>:mr  r31,r9
   0xbaf4 <+68>:bl  0xf118

   0xbaf8 <+72>:nop
   0xbafc <+76>:mr  r4,r3
   0xbb00 <+80>:mr  r3,r31
   0xbb04 <+84>:bl  0x10ffc2e8

   0xbb08 <+88>:nop
   0xbb0c <+92>:addir1,r1,48
   0xbb10 <+96>:ld  r0,16(r1)
   0xbb14 <+100>:   ld  r31,-8(r1)
   0xbb18 <+104>:   mtlrr0
   0xbb1c <+108>:   blr
   0xbb20 <+112>:   bl  0x11054d48

   0xbb24 <+116>:   nop
   0xbb28 <+120>:   mr  r9,r3
   0xbb2c <+124>:   mr  r3,r31
   0xbb30 <+128>:   mr  r31,r9
   0xbb34 <+132>:   bl  0xf118

   0xbb38 <+136>:   nop
   0xbb3c <+140>:   mr  r4,r3
   0xbb40 <+144>:   mr  r3,r31
   0xbb44 <+148>:   bl  0x10ffc448

   0xbb48 <+152>:   nop
   0xbb4c <+156>:   addir1,r1,48
   0xbb50 <+160>:   ld  r0,16(r1)
   0xbb54 <+164>:   ld  r31,-8(r1)
   0xbb58 <+168>:   mtlrr0
   0xbb5c <+172>:   blr
   0xbb60 <+176>:   bl  0x11054d48

   0xbb64 <+180>:   nop
   0xbb68 <+184>:   mr  r9,r3
   0xbb6c <+188>:   mr  r3,r31
   0xbb70 <+192>:   mr  r31,r9
   0xbb74 <+196>:   bl  0xf118

   0xbb78 <+200>:   nop
   0xbb7c <+204>:   mr  r4,r3
   0xbb80 <+208>:   mr  r3,r31
   0xbb84 <+212>:   bl  0x10ffc188

   0xbb88 <+216>:   nop
   0xbb8c <+220>:   addir1,r1,48
   0xbb90 <+224>:   ld  r0,16(r1)
   0xbb94 <+228>:   ld  r31,-8(r1)
   0xbb98 <+232>:   mtlrr0
   0xbb9c <+236>:   blr
   0xbba0 <+240>:   .long 0x0
   0xbba4 <+244>:   .long 0x1000900
   0xbba8 <+248>:   .long 0x180
while the callee is:
200 void
201 m2linemap_WarningAtf (location_t location, const char *message, ...)
202 {
203   diagnostic_info diagnostic;
204   va_list ap;
205   rich_location richloc (line_table, location);
206 
207   va_start (ap, message);
208   diagnostic_set_info (&diagnostic, message, &ap, &richloc,
DK_WARNING);
209   diagnostic_report_diagnostic (global_dc, &diagnostic);
210   va_end (ap);
211 }
with full disassembly above.

[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2

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

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

--- Comment #3 from Segher Boessenkool  ---
>0x10ffc2e0 <+0>:   lis r2,4563
>0x10ffc2e4 <+4>:   addir2,r2,29696
>0x10ffc2e8 <+8>:   mflrr0
>0x10ffc2ec <+12>:  std r30,-16(r1)
>0x10ffc2f0 <+16>:  std r31,-8(r1)
>0x10ffc2f4 <+20>:  std r0,16(r1)
>0x10ffc2f8 <+24>:  stdur1,-368(r1)
>0x10ffc2fc <+28>:  vspltisw v0,0
>0x10ffc300 <+32>:  lis r11,-32768
>0x10ffc304 <+36>:  mr  r30,r4
>0x10ffc308 <+40>:  ori r11,r11,8
>0x10ffc30c <+44>:  std r5,416(r1)
>0x10ffc310 <+48>:  std r6,424(r1)
>0x10ffc314 <+52>:  xxswapd vs0,vs32
>0x10ffc318 <+56>:  li  r0,0
>0x10ffc31c <+60>:  clrldi  r11,r11,32
>0x10ffc320 <+64>:  std r7,432(r1)
> => 0x10ffc324 <+68>:  std r8,440(r1)
> overwrites it.
> Now the sizes of the automatic variables in m2linemap_WarningAtf are:
> (gdb) p sizeof (diagnostic)
> $42 = 136
> (gdb) p sizeof (ap)
> $43 = 8
> (gdb) p sizeof (richloc)
> $44 = 168
> sum 312 bytes, the frame is 368 bytes.  But where do those std r{5,6,7,8}
> stores to 4{16,24,32,40}(r1) come from is something I haven't figured out
> yet, probably register saves, but why does that overwrite the saved link
> register?

Those look like register saves yes.  But the saved LR is at 384, not at 440?

[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2

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

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

--- Comment #4 from Jakub Jelinek  ---
=> 0xbac0 :   std r0,16(r1)
(gdb) p/x $r0
$46 = 0x1102fb0c
(gdb) p/x $r1
$47 = 0x7fffe600
so lr stored to 0x7fffe610, then
   0xbac4 :   stdur1,-48(r1)
On entry to m2linemap_WarningAtf r1 is still 0x7fffe5d0, and the function
then does
   0x10ffc2f8 <+24>:stdur1,-368(r1)
and 0x7fffe5d0 - 368 + 432:
   0x10ffc320 <+64>:std r7,432(r1)
   0x10ffc324 <+68>:std r8,440(r1)
is exactly at 0x7fffe610 where it overwrites the saved lr of parent.

I have double checked and M2Emit.c should see the
EXTERN void m2linemap_WarningAtf (location_t location, const char *message,
...);
prototype for the function, so both should agree it is varargs.

[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #5 from Segher Boessenkool  ---
Ah, it overwrites the saved LR some frame up, it writes to some wrong location
on the stack.  It thinks the parameter save area is there.

This is eerily like PR100799.

[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2

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

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

--- Comment #6 from Jakub Jelinek  ---
Actually, I see:
grep WarningAtf /tmp/*.ii
/tmp/M2Emit.ii:extern void m2linemap_WarningAtf (m2linemap_location_t location,
void * message);
/tmp/M2Emit.ii:  m2linemap_WarningAtf (M2LexBuf_TokenToLocation (token),
DynamicStrings_string (message));
/tmp/m2linemap.ii:extern "C" void m2linemap_WarningAtf (location_t location,
const char *message, ...);
/tmp/m2linemap.ii:extern "C" void WarningAtf (location_t location, const char
*message, ...);
/tmp/m2linemap.ii:m2linemap_WarningAtf (location_t location, const char
*message, ...)
so there is indeed a mismatch between the caller which is told
m2linemap_WarningAtf is not varargs function,
and callee which compiles varargs function.
The preprocessed source says the wrong prototype comes from
m2/gm2-gcc/Gm2linemap.h
and I see the mismatch even in my x86_64-linux bootstrap, just the calling
convention doesn't care,
while powerpc64le-linux one clearly does care.

The first two lines of Gm2linemap.h are
/* do not edit automatically generated by mc from m2linemap.  */
/* m2linemap.def provides access to GCC location_t.

m2linemap.def contains:
PROCEDURE ErrorAt (location: location_t; message: ADDRESS) ;
(*
PROCEDURE ErrorAtf (location: location_t; message: ADDRESS; ...) ;
PROCEDURE WarningAtf (location: location_t; message: ADDRESS; ...) ;
PROCEDURE NoteAtf (location: location_t; message: ADDRESS; ...) ;
*)
PROCEDURE ErrorAtf (location: location_t; message: ADDRESS) ;
PROCEDURE WarningAtf (location: location_t; message: ADDRESS) ;
PROCEDURE NoteAtf (location: location_t; message: ADDRESS) ;
so I guess it is known there is a mismatch and perhaps it isn't representable
in Modula-2,
but still this will never work on powerpc64le.  So, could there be some
wrappers around the ... functions that just pass no arguments to them and are
callable from Modula-2?

[Bug sanitizer/108106] [13 Regression] /usr/bin/ld: .libs/hwasan_setjmp_x86_64.o: relocation R_X86_64_PC32 against symbol `__interceptor_sigsetjmp' can not be used when making a shared object; recompi

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

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

--- Comment #7 from H.J. Lu  ---
It is about -mshared:

[hjl@gnu-cfl-3 tmp]$ cat foo.s
jmp   __interceptor_sigsetjmp

.globl __interceptor_sigsetjmp
__interceptor_sigsetjmp:
nop
[hjl@gnu-cfl-3 tmp]$ as -o foo.o foo.s
[hjl@gnu-cfl-3 tmp]$ readelf -rW foo.o

There are no relocations in this file.
[hjl@gnu-cfl-3 tmp]$ as -o foo.o foo.s -mshared
[hjl@gnu-cfl-3 tmp]$ readelf -rW foo.o

Relocation section '.rela.text' at offset 0xc8 contains 1 entry:
Offset Info Type   Symbol's Value 
Symbol's Name + Addend
0001  00010004 R_X86_64_PLT32 0005
__interceptor_sigsetjmp - 4
[hjl@gnu-cfl-3 tmp]$ 

The assembler option:

'-mno-shared'
 On ELF target, the assembler normally optimizes out non-PLT
 relocations against defined non-weak global branch targets with
 default visibility.  The '-mshared' option tells the assembler to
 generate code which may go into a shared library where all non-weak
 global branch targets with default visibility can be preempted.
 The resulting code is slightly bigger.  This option only affects
 the handling of branch instructions.

The older assembler generates R_X86_64_PC32 relocation.

[Bug sanitizer/108106] [13 Regression] /usr/bin/ld: .libs/hwasan_setjmp_x86_64.o: relocation R_X86_64_PC32 against symbol `__interceptor_sigsetjmp' can not be used when making a shared object; recompi

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

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #54106|0   |1
is obsolete||

--- Comment #8 from H.J. Lu  ---
Created attachment 54114
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54114&action=edit
Add __interceptor_sigsetjmp_internal

Try this one.

[Bug c++/97720] Sometimes std::current_exception does not work properly in the terminate handler

[m101010a at gmail dot com via Gcc-bugs]

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

--- Comment #3 from m101010a at gmail dot com ---
After looking into this more, I have confirmed that this is definitely the
cause of bug 97339, and found a simpler reproduction in bug 55918 comment #4:

#include 
class Foo
{
public:
Foo() { std::cout << "Foo::Foo()\n"; }
~Foo() { std::cout << "Foo::~Foo()\n"; }
};

void bad_guy() noexcept {
  try {
Foo foo;
throw 0;
  } catch (float) {
// Don't catch int.
  }
}

void level1() {
  bad_guy();
  throw "dead code";
}

int main() {
  try {
level1();
  } catch (int) {
  }
}

[Bug target/108145] [13 regression] ICE in from_reg_br_prob_base, at profile-count.h:259

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

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

Rainer Orth  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #2 from Rainer Orth  ---
A reghunt identified this patch

commit 12abd5a7d13209f79664ea603b3f3517f71b8c4f
Author: Vladimir N. Makarov 
Date:   Thu Dec 15 14:11:05 2022 -0500

IRA: Check that reg classes contain a hard reg of given mode in reg move
cost calculation

as the culprit.

[Bug rtl-optimization/108148] New: ICE on valid code with "-O3 -fno-inline-functions-called-once -fno-inline-small-functions -fno-tree-ccp -fno-tree-dce -fno-tree-vrp" on x86_64-linux-gnu: maximum num

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

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

Bug ID: 108148
   Summary: ICE on valid code with "-O3
-fno-inline-functions-called-once
-fno-inline-small-functions -fno-tree-ccp
-fno-tree-dce -fno-tree-vrp" on x86_64-linux-gnu:
maximum number of generated reload insns per insn
achieved (90)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression.

Compiler Explorer: https://godbolt.org/z/MdYbTr93j


[592] % 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/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221216 (experimental) [master r13-4745-g92eb0adc14a] (GCC) 
[593] % 
[593] % gcctk -O3 -fno-inline-functions-called-once -fno-inline-small-functions
-fno-tree-ccp -fno-tree-dce -fno-tree-vrp small.c
during RTL pass: reload
small.c: In function ‘p.constprop’:
small.c:31:1: internal compiler error: maximum number of generated reload insns
per insn achieved (90)
   31 | }
  | ^
0xd1bf66 lra_constraints(bool)
../../gcc-trunk/gcc/lra-constraints.cc:5137
0xd0794a lra(_IO_FILE*)
../../gcc-trunk/gcc/lra.cc:2375
0xcbfa99 do_reload
../../gcc-trunk/gcc/ira.cc:5949
0xcbfa99 execute
../../gcc-trunk/gcc/ira.cc:6135
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[594] % 
[594] % cat small.c
struct a {
  unsigned b;
  int c;
  int d;
  unsigned : 5;
} l, n;
struct e {
  unsigned b;
  int f;
  int a;
} j;
int g, i, k, m;
unsigned h;
const struct a o;
static struct a p(const struct a q) {
  if (m) {
goto L;
  L:
for (; g; g++) {
  struct e a[8] = {j};
  for (; h < 2; h++)
l = q;
  if (i) {
k = 0;
for (; k < 2; k++)
  ;
  }
}
  }
  return q;
}
int main() {
  n = p(o);
  return 0;
}

[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|gaius at gcc dot gnu.org   |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-12-16

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

Untested fix.
One thing I wonder about though, does the FE guarantee that the % chars never
appear in the diagnostic strings?  If not, we should incrementally call the
varargs functions with "%s", message rather than message (including error_at
and
internal_function).

[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2

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

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

--- Comment #8 from Jakub Jelinek  ---
Short test that shows that on powerpc64le-linux:
void foo (int, ...);
void bar (int);
int baz (void) { foo (1); return 0; }
int qux (void) { bar (1); return 0; }
one gets at -O2 96 byte sized frame in baz case while only 32 byte sized frame
in qux.

[Bug rtl-optimization/108086] [11/12/13 Regression] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #15 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug testsuite/108141] [13 Regression] gcc.target/i386/pr64110.c FAIL since r13-4727 on ia32

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Vladimir Makarov :

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

commit r13-4749-gb50fe16a3b2214c418ecc5febc0bb21bc17912b7
Author: Vladimir N. Makarov 
Date:   Fri Dec 16 13:16:31 2022 -0500

Revert "IRA: Check that reg classes contain a hard reg of given mode in reg
move cost calculation"

The patch resulted in new PRs:

PR target/108145
PR testsuite/108141

So I am reverting the patch.

This reverts commit 12abd5a7d13209f79664ea603b3f3517f71b8c4f.

[Bug target/108145] [13 regression] ICE in from_reg_br_prob_base, at profile-count.h:259

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Vladimir Makarov :

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

commit r13-4749-gb50fe16a3b2214c418ecc5febc0bb21bc17912b7
Author: Vladimir N. Makarov 
Date:   Fri Dec 16 13:16:31 2022 -0500

Revert "IRA: Check that reg classes contain a hard reg of given mode in reg
move cost calculation"

The patch resulted in new PRs:

PR target/108145
PR testsuite/108141

So I am reverting the patch.

This reverts commit 12abd5a7d13209f79664ea603b3f3517f71b8c4f.

[Bug sanitizer/108106] [13 Regression] /usr/bin/ld: .libs/hwasan_setjmp_x86_64.o: relocation R_X86_64_PC32 against symbol `__interceptor_sigsetjmp' can not be used when making a shared object; recompi

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

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

--- Comment #9 from Thomas Schwinge  ---
Comment on attachment 54114
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54114
Add __interceptor_sigsetjmp_internal

Voilà:

$ size
build-gcc/x86_64-pc-linux-gnu/libsanitizer/hwasan/.libs/libhwasan.so.0.0.0
   textdata bss dec hex filename
 445414   16620 5381552 5843586  592a82
build-gcc/x86_64-pc-linux-gnu/libsanitizer/hwasan/.libs/libhwasan.so.0.0.0

[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2

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

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

--- Comment #9 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #8)
> Short test that shows that on powerpc64le-linux:
> void foo (int, ...);
> void bar (int);
> int baz (void) { foo (1); return 0; }
> int qux (void) { bar (1); return 0; }
> one gets at -O2 96 byte sized frame in baz case while only 32 byte sized
> frame in qux.

This is because of crtl->outgoing_args_size for varargs functions.  It is not
specific to ELFv2 afaics?  Not sure why it seems to be easier to hit problems
there either.

[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2

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

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to Segher Boessenkool from comment #9)
> This is because of crtl->outgoing_args_size for varargs functions.  It is not
> specific to ELFv2 afaics?  Not sure why it seems to be easier to hit problems
> there either.

We only build ppc64le these days in Fedora, so that is the only power arch I
was testing (plus x86_64, i686, aarch64 and s390x).

[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR

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

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

--- Comment #17 from Vladimir Makarov  ---
I've reverted my patch as it resulted in two new PRs.  I'll do more work on
this PR and I'll start this job in Jan.

[Bug rust/108113] Rust and --enable-link-serialization=1

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #2 from Thomas Schwinge  ---
Marc, given Jakub's approval in
, are you
going to push "rust: fix link serialization [PR108113]" to GCC upstream master
branch, too?

---

There's no reason, in opinion, to block such ongoing development/fixes on the
GCC/Rust backlog upstreaming process.

[Bug tree-optimization/108139] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1938-g87dd4c8c83768aaf

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

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

--- Comment #2 from Andrew Pinski  ---
Folding statement: if (a.3_5 != 0)
Folding predicate a.3_5 != 0 to 1
Folded into: if (1 != 0)

I don't see how that could be possible. There is some issue coming from the
(not used on this path) uninitialized variable c too.

[Bug other/108146] gcc -pg does not produce gmon.out

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Sid.Touati from comment #2)
> Hi,
> this bug has been reported to the gcov-profile component [Bug
> gcov-profile/108146], Martin Liška found that it is more appropriate to
> submit it to glibC guys. 

He meant filing it to https://sourceware.org/bugzilla/ .

[Bug analyzer/106479] FAIL: gcc.dg/analyzer/pr104308.c (test for warnings, line 9)

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

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

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

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

commit r13-4750-g2fdc8546b5c6cb1fe254e40b5bdd19ed6fbb44da
Author: David Malcolm 
Date:   Fri Dec 16 14:50:07 2022 -0500

analyzer: add src_region param to region_model::check_for_poison [PR106479]

PR analyzer/106479 notes that we don't always show the region-creation
event for a memmove from an uninitialized stack region.  This occurs
when using kf_memcpy_memmove.  Fix by passing a src_region hint to
region_model::check_for_poison.

gcc/analyzer/ChangeLog:
PR analyzer/106479
* kf.cc (kf_memcpy_memmove::impl_call_pre): Pass in source region
to region_model::check_for_poison.
* region-model-asm.cc (region_model::on_asm_stmt): Pass NULL
region to region_model::check_for_poison.
* region-model.cc (region_model::check_for_poison): Add
"src_region" param, and pass it to poisoned_value_diagnostic.
(region_model::on_assignment): Pass NULL region to
region_model::check_for_poison.
(region_model::get_rvalue): Likewise.
* region-model.h (region_model::check_for_poison): Add
"src_region" param.
* sm-fd.cc (fd_state_machine::on_accept): Pass in source region
to region_model::check_for_poison.
* varargs.cc (kf_va_copy::impl_call_pre): Pass NULL region to
region_model::check_for_poison.
(kf_va_arg::impl_call_pre): Pass in source region to
region_model::check_for_poison.

gcc/testsuite/ChangeLog:
PR analyzer/106479
* gcc.dg/analyzer/pr104308.c (test_memmove_within_uninit): Remove
xfail on region creation event.

Signed-off-by: David Malcolm 

[Bug middle-end/99579] gmon.out not created with -O0 but otherwise is

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |MOVED

--- Comment #4 from Andrew Pinski  ---
Moved to a glibc issue.

[Bug other/108146] gcc -pg does not produce gmon.out

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #4 from Andrew Pinski  ---
Already reported to glibc, see the two bug reports in the see also. Also a dup
of bug 99579 too.

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

[Bug middle-end/99579] gmon.out not created with -O0 but otherwise is

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||Sid.Touati at inria dot fr

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

[Bug analyzer/106479] FAIL: gcc.dg/analyzer/pr104308.c (test for warnings, line 9)

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Thanks; should be fixed by the above patch (lightly tested with hppa-linux-gnu
and riscv32-unknown-linux-gnu).

[Bug analyzer/106479] FAIL: gcc.dg/analyzer/pr104308.c (test for warnings, line 9)

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

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

--- Comment #3 from David Malcolm  ---
(In reply to David Malcolm from comment #2)
> Thanks; should be fixed by the above patch (lightly tested with
> hppa-linux-gnu and riscv32-unknown-linux-gnu).

...referring to the FAIL at line 9.

I believe the FAIL at line 10 was fixed by
g:cf80a23e19db83b7cb2220371d21642aa08261e0

[Bug tree-optimization/108139] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1938-g87dd4c8c83768aaf

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Andrew Macleod  ---
(In reply to Andrew Pinski from comment #2)
> Folding statement: if (a.3_5 != 0)
> Folding predicate a.3_5 != 0 to 1
> Folded into: if (1 != 0)
> 
> I don't see how that could be possible. There is some issue coming from the
> (not used on this path) uninitialized variable c too.

   [local count: 59055799]:
  a.3_5 = a;
  b.2_4 = b;

   [local count: 114863530]:
  # c_2 = PHI 

   [local count: 1073741824]:
  if (a.3_5 != 0)
goto ; [94.50%]
  else
goto ; [5.50%]

The problem is that c_9 is an undefined value in the PHI..  with only 2
arguments, we try to be clever (and this is important in other places), and
say, ok, we'll assume it has the same value as the other argument and we create
an equivalence between c_2 and the other argument, a.3_5

The only way to get to the 6->9 edge is to have processed the if statement
already, and therefore we'd know that a.3_5 is ~[0, 0], sowe determine that c_2
is also ~[0,0].

When we visit the if statement, we know a.3_5 is varying, but we also look at
what equivalences a.3_5 has, and voila c_2 is equivlant o a.3_5, so we refine
the value to match c_2 and then decide we can fold away the if as always true.

we don't seem to run into this at hihger optimization levels because bb6 and
bb7 are merged, and with the PHI in the same block,we don't trigger the
outgoing edge equivalence evaluations :-P  so we pick up the original VARYING
result for a.3_5 and don't adjust it with its "equivalence c_2". 

hum.

[Bug tree-optimization/108139] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1938-g87dd4c8c83768aaf

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #4 from Andrew Macleod  ---
9->6 edge, not 6->9...

[Bug c++/107768] Bogus -Wzero-as-null-pointer-constant in coroutine

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

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

commit r13-4751-g0b1d66658ecdcc3d9251641a0b902b4c73ace303
Author: Andrew Pinski 
Date:   Thu Dec 8 22:34:16 2022 +

coroutines: Build pointer initializers with nullptr_node [PR107768]

The PR reports that using integer_zero_node triggers a warning for
-Wzero-as-null-pointer-constant which comes from compiler-generated code so
makes no sense to the end user.

Co-Authored-By: Iain Sandoe 

PR c++/107768

gcc/cp/ChangeLog:

* coroutines.cc (coro_rewrite_function_body): Initialize pointers
from nullptr_node.  (morph_fn_to_coro): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr107768.C: New test.

[Bug libstdc++/72792] [6/7 Regression] allocator_traits is too strict about rebinding

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

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

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

https://gcc.gnu.org/g:64c986b49558a7c356b85bda85195216936c29a3

commit r13-4752-g64c986b49558a7c356b85bda85195216936c29a3
Author: Jonathan Wakely 
Date:   Wed Dec 14 15:21:32 2022 +

libstdc++: Diagnose broken allocator rebind members

This adds a static assertion to std::allocator_traits::rebind_alloc to
diagnose violations of the rule that rebinding an allocator to its own
value type yields the same allocator type.

This helps to catch the easy mistake of deriving from std::allocator but
forgetting to override the rebind behaviour (no longer an issue in C++20
as std::allocator doesn't have a rebind member that can be inherited).
It also catches bugs like in 23_containers/vector/52591.cc where a typo
means the rebound allocator is a completely different type.

I initially wanted to put this static assert into the body of
allocator_traits:

  static_assert(is_same, _Alloc>::value,
"rebind_alloc must be Alloc");

However, this causes a regression in the test for PR libstdc++/72792.
It seems that instantiating std::allocator_traits should be allowed for
invalid allocator types as long as you don't try to rebind them. To
support that, only assert in the __allocator_traits_base::__rebind class
template (in both the primary template and the partial specialization).
As a result, the bug in 20_util/scoped_allocator/outermost.cc is not
diagnosed, because nothing in that test rebinds the allocator.

libstdc++-v3/ChangeLog:

* include/bits/alloc_traits.h (__allocator_traits_base::__rebind):
Add static assert for rebind requirement.
* testsuite/20_util/allocator_traits/members/rebind_alloc.cc:
Fix invalid rebind member in test allocator.
* testsuite/20_util/allocator_traits/requirements/rebind_neg.cc:
New test.
* testsuite/20_util/scoped_allocator/outermost.cc: Add rebind to
test allocator.
* testsuite/23_containers/forward_list/48101_neg.cc: Prune new
static assert error.
* testsuite/23_containers/unordered_multiset/48101_neg.cc:
Likewise.
* testsuite/23_containers/unordered_set/48101_neg.cc:
Likewise.
* testsuite/23_containers/vector/52591.cc: Fix typo in rebind.

[Bug c++/108138] g++ 9+ takes 7-10x longer compiling constexpr

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:71d2567a678b01a3a59064d22e0f9165be9e93c3

commit r11-10424-g71d2567a678b01a3a59064d22e0f9165be9e93c3
Author: Patrick Palka 
Date:   Thu Oct 28 10:05:14 2021 -0400

c++: quadratic constexpr behavior for left-assoc logical exprs [PR102780]

In the testcase below the two left fold expressions each expand into a
constant logical expression with 1024 terms, for which potential_const_expr
takes more than a minute to return true.  This happens because p_c_e_1
performs trial evaluation of the first operand of a &&/|| in order to
determine whether to consider the potentiality of the second operand.
And because the expanded expression is left-associated, this trial
evaluation causes p_c_e_1 to be quadratic in the number of terms of the
expression.

This patch fixes this quadratic behavior by making p_c_e_1 preemptively
compute potentiality of the second operand of a &&/||, and perform trial
evaluation of the first operand only if the second operand isn't
potentially constant.  We must be careful to avoid emitting bogus
diagnostics during the preemptive computation; to that end, we perform
this shortcut only when tf_error is cleared, and when tf_error is set we
now first check potentiality of the whole expression quietly and replay
the check noisily for diagnostics.

Apart from fixing the quadraticness for left-associated logical exprs,
this change also reduces compile time for the libstdc++ testcase
20_util/variant/87619.cc by about 15% even though our  uses
right folds instead of left folds.  Likewise for the testcase in the PR,
for which compile time is reduced by 30%.  The reason for these speedups
is that p_c_e_1 no longer performs expensive trial evaluation of each term
of large constant logical expressions when determining their potentiality.

PR c++/102780
PR c++/108138

gcc/cp/ChangeLog:

* constexpr.c (potential_constant_expression_1) :
When tf_error isn't set, preemptively check potentiality of the
second operand before performing trial evaluation of the first
operand.
(potential_constant_expression_1): When tf_error is set, first
check
potentiality quietly and return true if successful, otherwise
proceed noisily to give errors.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/fold13.C: New test.

(cherry picked from commit 9927ecbb42d5be48fa933adc26f8601fab5007ca)