[Bug c/104804] New: [12.0] x86_64 Extended asm always failed with "+=m" in Output Operands and wrong error info

[570070308 at qq dot com via Gcc-bugs]

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

Bug ID: 104804
   Summary: [12.0] x86_64 Extended asm always failed with "+=m" in
Output Operands and wrong error info
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 570070308 at qq dot com
  Target Milestone: ---

When using "+&m" in the Output Operands, the compile will always failed,
however, the "+&r" is ok.

And the error info seen to be wrong:
```
error: input operand constraint contains ‘&’
```
It is the onput operand constraint not input.


test2.c:
```
ig@ig-virtual-machine:~/temp$ cat test2.c
int main()
{
char a, b;
__asm__
(
 "\n"
 :"+&m"( a )
 :"r"( b )
 :"cc"
 );
return 0;
}
ig@ig-virtual-machine:~/temp$
```
compile error log:
```
ig@ig-virtual-machine:~/temp$ gcc-12 test2.c -S  -v
Using built-in specs.
COLLECT_GCC=gcc-12
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12-20220302-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-VlTCdr/gcc-12-12-20220302/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-VlTCdr/gcc-12-12-20220302/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220302 (experimental) [master r12-7448-g58394373a70]
(Ubuntu 12-20220302-1ubuntu1) 
COLLECT_GCC_OPTIONS='-S' '-v' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/12/cc1 -quiet -v -imultiarch x86_64-linux-gnu
test2.c -quiet -dumpbase test2.c -dumpbase-ext .c -mtune=generic -march=x86-64
-version -o test2.s -fasynchronous-unwind-tables -fstack-protector-strong
-Wformat -Wformat-security -fstack-clash-protection -fcf-protection
GNU C17 (Ubuntu 12-20220302-1ubuntu1) version 12.0.1 20220302 (experimental)
[master r12-7448-g58394373a70] (x86_64-linux-gnu)
compiled by GNU C version 12.0.1 20220302 (experimental) [master
r12-7448-g58394373a70], GMP version 6.2.1, MPFR version 4.1.0, MPC version
1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/12/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/12/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/12/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C17 (Ubuntu 12-20220302-1ubuntu1) version 12.0.1 20220302 (experimental)
[master r12-7448-g58394373a70] (x86_64-linux-gnu)
compiled by GNU C version 12.0.1 20220302 (experimental) [master
r12-7448-g58394373a70], GMP version 6.2.1, MPFR version 4.1.0, MPC version
1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3929bb57dd80f5cc2d4f3202c349e2dc
test2.c: In function ‘main’:
test2.c:4:5: error: input operand constraint contains ‘&’
4 | __asm__
  | ^~~
ig@ig-virtual-machine:~/temp$
```

and this is ok:
```
int main()
{
char a, b;
__asm__
(
 "\n"
 :"+&r"( a )
 :"r"( b )
 :"cc"
 );
return 0;
}
```

the gcc is installed by apt on ubuntu 22.04

[Bug c/104804] [12.0] x86_64 Extended asm always failed with "+&m" in Output Operands and wrong error info

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
+m is handled as =m with corresponding m, early clobber for that doesn't make
sense, on one side you require that the input is the same as the output, on the
other hand you require that no input can be equal to the output because the
output might be overwritten before the inputs are read.
Just don't do that.

[Bug c/104804] [12.0] x86_64 Extended asm always failed with "+&m" in Output Operands and wrong error info

[570070308 at qq dot com via Gcc-bugs]

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

--- Comment #2 from 。 <570070308 at qq dot com> ---
(In reply to Jakub Jelinek from comment #1)
> +m is handled as =m with corresponding m, early clobber for that doesn't
> make sense, on one side you require that the input is the same as the
> output, on the other hand you require that no input can be equal to the
> output because the output might be overwritten before the inputs are read.
> Just don't do that.

Thanks for Reply

According to the doc in
https://gcc.gnu.org/onlinedocs/gcc/Modifiers.html#Modifiers and
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#OutputOperands, in my
understanding, if an OutputOperand('+'or'=') is written before reading from any
OutputOperands(+) or IutputOperands except the OutputOperand itself, it should
be added '&'.
So if +m is handled as =m with corresponding m, I think +&m should be handle as
+m and =m too.
for example in:
```
__asm__(
"read a"
"write a"
"read b"
:"+&m"(a)
:"g"(b)
:
);
```

[Bug c/104805] New: [12.0] x86_64 Extended asm may use rbp register to input/output even thougth "rbp" is in the clobber list when "rsp" and "rbp" are both in the in the clobber list

[570070308 at qq dot com via Gcc-bugs]

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

Bug ID: 104805
   Summary: [12.0] x86_64 Extended asm may use rbp register to
input/output even thougth "rbp" is in the clobber list
when "rsp" and "rbp" are both in the in the clobber
list
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 570070308 at qq dot com
  Target Milestone: ---

test.c:
```
void kkk()
{
char a;
__asm__ volatile (
"%0"
:"+m"(a)
:
: "rsp","rbp"
);
}
```

assembly code:
```
#APP
# 4 "test.c" 1
-9(%rbp)
# 0 "" 2
#NO_APP
```

can see that it use `-9(%rbp)` to represent `a`. Accouding to
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers,
the rbp should not be use to represent any operands because it is in the
clobber list.

compile log:
```
ig@ig-virtual-machine:~/temp$ gcc-12 -S test.c -O1 -v
Using built-in specs.
COLLECT_GCC=gcc-12
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12-20220302-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-VlTCdr/gcc-12-12-20220302/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-VlTCdr/gcc-12-12-20220302/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220302 (experimental) [master r12-7448-g58394373a70]
(Ubuntu 12-20220302-1ubuntu1) 
COLLECT_GCC_OPTIONS='-S' '-O1' '-v' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/12/cc1 -quiet -v -imultiarch x86_64-linux-gnu
test.c -quiet -dumpbase test.c -dumpbase-ext .c -mtune=generic -march=x86-64
-O1 -version -o test.s -fasynchronous-unwind-tables -fstack-protector-strong
-Wformat -Wformat-security -fstack-clash-protection -fcf-protection
GNU C17 (Ubuntu 12-20220302-1ubuntu1) version 12.0.1 20220302 (experimental)
[master r12-7448-g58394373a70] (x86_64-linux-gnu)
compiled by GNU C version 12.0.1 20220302 (experimental) [master
r12-7448-g58394373a70], GMP version 6.2.1, MPFR version 4.1.0, MPC version
1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/12/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/12/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/12/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C17 (Ubuntu 12-20220302-1ubuntu1) version 12.0.1 20220302 (experimental)
[master r12-7448-g58394373a70] (x86_64-linux-gnu)
compiled by GNU C version 12.0.1 20220302 (experimental) [master
r12-7448-g58394373a70], GMP version 6.2.1, MPFR version 4.1.0, MPC version
1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3929bb57dd80f5cc2d4f3202c349e2dc
test.c: In function ‘kkk’:
test.c:4:5: warning: listing the stack pointer register ‘rsp’ in a clobber list
is deprecated [-Wdeprecated]
4 | __asm__ volatile (
  | ^~~
test.c:4:5: note: the value of the stack pointer after an ‘asm’ statement must
be the same as it was before the statement
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/12/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/li

[Bug c/104804] [12.0] x86_64 Extended asm always failed with "+&m" in Output Operands and wrong error info

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

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

--- Comment #3 from Jakub Jelinek  ---
As I wrote, the only way to implement +m reliably in gcc is to lower it
immediately as "=m" (whatever) ... "0" (whatever) with ensuring that
side-effects in whatever are evaluated just once.
And, in that case & prevents overlap not just with other inputs, but also with
the "0" input which is just another one.

What exactly are you trying to achieve (because & on your testcase makes no
sense at all, the other input is "r" and therefore can't ever match the
memory)?

[Bug c/104805] [12.0] x86_64 Extended asm may use rbp register to input/output even thougth "rbp" is in the clobber list when "rsp" and "rbp" are both in the in the clobber list

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Clobber of "rsp" makes no sense, you can't change the value of the stack
pointer in inline asm without restoring it back before the end of inline asm.

[Bug c/104805] [12.0] x86_64 Extended asm may use rbp register to input/output even thougth "rbp" is in the clobber list when "rsp" and "rbp" are both in the in the clobber list

[570070308 at qq dot com via Gcc-bugs]

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

--- Comment #2 from 。 <570070308 at qq dot com> ---
(In reply to Jakub Jelinek from comment #1)
> Clobber of "rsp" makes no sense, you can't change the value of the stack
> pointer in inline asm without restoring it back before the end of inline asm.

I know that changing rsp is dangerous, and the gcc will give a warning if you
use rsp. I have never changed rsp in my inline-asm coding, or put "rsp" in the
clobber list. I'm just for finding bug and make gcc better.

what about:

__asm__
(
"pushq %%rax\n\t"
"popq %%rax"
:
:
:"rsp"
);

[Bug c/104804] [12.0] x86_64 Extended asm always failed with "+&m" in Output Operands and wrong error info

[570070308 at qq dot com via Gcc-bugs]

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

--- Comment #4 from 。 <570070308 at qq dot com> ---
(In reply to Jakub Jelinek from comment #3)

> What exactly are you trying to achieve (because & on your testcase makes no
> sense at all, the other input is "r" and therefore can't ever match the
> memory)?

Yes, in x86 that's true.
But if there is an Instruction Set, which support 
```
 movq ((%rax)), %rax
```

And in
test.c :
```
void kkk()
{
char a;
char *pa=&a;
char *ppa=&pa;
__asm__ (
:"+m"(pa)
:"m"(a)
:
);
}
```

gcc can use %rax to represent ppa, (%rax) to represent pa, ((%rax)) to
represent a., then "+&m"(pa) will make difference.

[Bug c/104805] [12.0] x86_64 Extended asm may use rbp register to input/output even thougth "rbp" is in the clobber list when "rsp" and "rbp" are both in the in the clobber list

[570070308 at qq dot com via Gcc-bugs]

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

--- Comment #3 from 。 <570070308 at qq dot com> ---
(In reply to Jakub Jelinek from comment #1)
> Clobber of "rsp" makes no sense, you can't change the value of the stack
> pointer in inline asm without restoring it back before the end of inline asm.

And, this bug is about "rbp" not "rsp". GCC uses "rbp" to represent input
operand even though the "rbp" is in the clobber list.

[Bug libstdc++/104801] std::ranges::view_interface::empty is overconstrained

[reconnoo at gmail dot com via Gcc-bugs]

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

Pawel P  changed:

   What|Removed |Added

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

--- Comment #2 from Pawel P  ---
I understand. Thank you for clarification

[Bug libstdc++/104801] std::ranges::view_interface::empty is overconstrained

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #3 from 康桓瑋  ---
(In reply to Pawel P from comment #2)
> I understand. Thank you for clarification

You should close with RESOLVED INVALID since there is nothing to fix.

[Bug libstdc++/104801] std::ranges::view_interface::empty is overconstrained

[reconnoo at gmail dot com via Gcc-bugs]

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

Pawel P  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug c/104805] [12.0] x86_64 Extended asm may use rbp register to input/output even thougth "rbp" is in the clobber list when "rsp" and "rbp" are both in the in the clobber list

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

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

--- Comment #4 from Jakub Jelinek  ---
rbp is hard frame pointer, so depending on whether the function needs a frame
pointer (at -O0 I think all functions do), the register isn't available for use
(and therefore for clobbering) in inline asm.
Only in functions where it isn't needed, it is not fixed then and can be used
for other purposes.

[Bug c++/104806] New: Weird error message: did you mean "__dt "

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 104806
   Summary: Weird error message: did you mean "__dt "
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Input
=
struct S{};
int main() { S s; s.__d; }

Observed

g++ -c x.cpp
gcc version 11.2.1 20220103 [revision d4a1d3c4b377f1d4acb34fe1b55b5088a3f293f6]
(SUSE Linux) 

x.cpp: In function ‘int main()’:
x.cpp:2:21: error: ‘struct S’ has no member named ‘__d’; did you mean ‘__dt ’?
2 | int main() { S s; s.__d; }
  | ^~~
  | __dt 

Expected

x.cpp: did you mean "__dt"?

That is, without the extra space. In addition, where does __dt come from? I
have not even included anything. This in the source code git repo looks like
the culprit.

gcc/cp/decl.cc:{"__dt ", &dtor_identifier, cik_dtor},

[Bug c/104805] [12.0] x86_64 Extended asm may use rbp register to input/output even thougth "rbp" is in the clobber list when "rsp" and "rbp" are both in the in the clobber list

[570070308 at qq dot com via Gcc-bugs]

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

--- Comment #5 from 。 <570070308 at qq dot com> ---
(In reply to Jakub Jelinek from comment #4)
> rbp is hard frame pointer, so depending on whether the function needs a
> frame pointer (at -O0 I think all functions do), the register isn't
> available for use (and therefore for clobbering) in inline asm.
> Only in functions where it isn't needed, it is not fixed then and can be
> used for other purposes.

So you explained why "rbp" cann't be in the clobber list with -O0, and may be
can be in the clobber list with -O1,-O2 or -O3(when the function don't needs a
frame pointer), I understand this now.

But when the "rbp" is in the clobber list successfully, it should not be used
to represent any input/output operands according to the doc because user may
change the %rbp and make the input/output operands wrong.

for example:
```
void kkk()
{
char a;
__asm__ volatile (
"writing %%rbp\n\t"
// %0 may point to error memory because %rbp change
// for example -9(%rbp) represent char a
"reading %0\n\t"
"writing %0"
:"+m"(a)
:
: "rsp","rbp"
);
}
```

I have done a lot of experiments, if a register is list in the clobber list, it
will never appear to represent in the input/output operands, and the doc say so
too. Only "rbp" is an exception.

https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers
```
When the compiler selects which registers to use to represent input and output
operands, it does not use any of the clobbered registers. As a result,
clobbered registers are available for any use in the assembler code.
```

[Bug middle-end/90597] [9/10/11/12 Regression] FAIL: gcc.dg/attr-vector_size.c (internal compiler error)

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Target Milestone|9.5 |12.0
 CC||roger at nextmovesoftware dot 
com
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Roger Sayle  ---
This should be fixed on mainline for GCC 12.

[Bug c++/104636] implicit use of explicit constructor

[gcc at ebasoft dot com.pl via Gcc-bugs]

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

--- Comment #4 from Artur Bać  ---
So conclusion from Your arguments is to me that -std=c++20 doesn't guarantee
strict c++20 compatibility as another switches are required to force explicit
constructor be used only explicitly and disallow implicit construction with
explicit constructor.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #12 from Eric Gallager  ---
(In reply to Roland Illig from comment #11)
> Is there a general plan of fixing these "trivial" nits? Half of my reports
> from 2019 are still open after 3 years.

I think there's a few things going on here: people don't want to run the entire
bootstrap/regression-test cycle for such tiny changes, which kinda kills the
motivation for fixing them, and also the original authors of the strings being
copyedited might not be aware of these bugs open against them. Martin Liška
recently swapped the build from -Wno-error=format-diag to -Werror=format-diag,
so maybe he can help...

[Bug target/96248] Closing quote in wrong position in config/rs6000/rs6000.c

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

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90148
   Severity|normal  |trivial
 Depends on|40883   |
 Blocks||40883
 CC||egallager at gcc dot gnu.org
   Keywords||easyhack

--- Comment #2 from Eric Gallager  ---
I think the "depends on" field was supposed to be in the "blocks" field;
swapping them


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
[Bug 40883] [meta-bug] Translation breakage with trivial fixes

[Bug target/104795] inconsistent wording in diagnostics

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||ubizjak at gmail dot com

--- Comment #1 from Eric Gallager  ---
The first message is now located in gcc/config/i386/i386-options.cc (git blame
says Uros wrote it in 716bb02b), and the second message only seems to exist in
pofiles now, so I dunno what happened to it...

[Bug target/104795] inconsistent wording in diagnostics

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

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack
   Severity|normal  |trivial
 Blocks||40883


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
[Bug 40883] [meta-bug] Translation breakage with trivial fixes

[Bug target/104796] ABI change is not mentioned in HTML changelog

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
git blame says Jakub wrote it in 3159da6c

[Bug target/104797] too many parentheses in diagnostic for __delay_cycles

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

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

Eric Gallager  changed:

   What|Removed |Added

   Severity|normal  |trivial
 CC||egallager at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Keywords||easyhack
 Blocks||40883

--- Comment #1 from Eric Gallager  ---
git blame says the last person to touch these strings was Martin Liška in
58385f6a (which, ironically, was a -Wformat-diag fix)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
[Bug 40883] [meta-bug] Translation breakage with trivial fixes

[Bug target/99297] wrong diagnostic style in rx.c

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

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack
   Severity|normal  |trivial

--- Comment #2 from Eric Gallager  ---
git blame says the last person to touch this string was Martin Liška in
58385f6a (same commit as from the last bug I was checking; a -Wformat-diag
fix), and no, it shouldn't be difficult to fix, at least not beyond the usual
steps for testing and submitting patches...

[Bug translation/90148] Closing quote in wrong position in plugin.c

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #8 from Eric Gallager  ---
These are mostly from Martin Liška's a3f9f006; it looks like
contrib/check-internal-format-escaping.py could use some fixes...

[Bug c++/104636] implicit use of explicit constructor

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Yes, see
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-pedantic-1
and
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-pedantic-errors-1

[Bug c++/104636] implicit use of explicit constructor

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

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

--- Comment #6 from Jakub Jelinek  ---
If you have something in between {}s it will be an error, not a pedwarn
(pedwarn will emit a warning with -Wpedantic and error with -pedantic-errors).
I believe the reason why it is a pedwarn in the {} case is mentioned in
https://gcc.gnu.org/pipermail/gcc-patches/2015-October/432285.html
that the C++ standard kept changing on what actually is valid and what is not
and therefore it was kept as a pedantic diagnostics only.

[Bug c/104805] [12.0] x86_64 Extended asm may use rbp register to input/output even thougth "rbp" is in the clobber list when "rsp" and "rbp" are both in the in the clobber list

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

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

--- Comment #6 from Andrew Pinski  ---
See
https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Optimize-Options.html#index-fomit-frame-pointer

[Bug libstdc++/104807] New: x86_64-w64-mingw32 target does not have visibility setting

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 104807
   Summary: x86_64-w64-mingw32 target does not have visibility
setting
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 52569
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52569&action=edit
error message

Recent changes to libstdc++ breaks build for windows targets

[Bug c++/104808] New: unclear diagnostic "MAP %qD TO %qT"

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 104808
   Summary: unclear diagnostic "MAP %qD TO %qT"
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

cp/constraint.cc says:
> if (TYPE_P (parm))
>   verbatim ("MAP %qD TO %qT", TEMPLATE_TYPE_DECL (parm), arg);
> else
>   verbatim ("MAP %qD TO %qE", TEMPLATE_PARM_DECL (parm), arg);

As the German translator, what am I supposed to translate here?

If "MAP" and "TO" are keywords, there is nothing to translate, in which case
the string should not be marked for translation at all.

If "MAP" and "TO" are part of an English sentence (as the GCC conventions for
diagnostics recommend), I don't understand why they are in uppercase.  That
wouldn't make sense in locale "C" either.

Please put a /* TRANSLATORS: explanation */ comment above these two messages,
or at least the upper one.

[Bug c++/104806] Weird error message: did you mean "__dt "

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

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

--- Comment #1 from Andrew Pinski  ---
Actually "__dt " should not be recommended at all.

[Bug c++/104808] unclear diagnostic "MAP %qD TO %qT"

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

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

--- Comment #1 from Andrew Pinski  ---
these are in debug_* functions so they don't need to be translated as they are
not user visible at all.
That is they are only used while debugging GCC.

[Bug c++/104809] New: Explain ELRoND to translators

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 104809
   Summary: Explain ELRoND to translators
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

>From cp/module.cc:
> not Encapsulated Lazy Records of Named Declarations

Is this message trying to be funny? As the German translator, I got the
abbreviation, but according to a Google search the GCC source code is the only
place where it is used.

I don't think that elves and dwarfs only live in Middle Earth, and that the
diagnostic thus discriminates elves living in other parts of the world of the
universe, whichever is more inclusive.

Please add a /* TRANSLATORS */ comment above this message, detailing how close
to the words I should translate this message or whether a simple "There are no
elfs in this forest" is enough.  No, I don't have humor.  This is GCC, not an
RPG, so I strongly prefer clear, actionable diagnostics.

[Bug c++/104810] New: Wrong order of "note: ... this enumerator %qD"

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 104810
   Summary: Wrong order of "note: ... this enumerator %qD"
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic, testsuite-fail
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

>From cp/module.cc:
> inform (DECL_SOURCE_LOCATION (new_decl),
> "... this enumerator %qD", new_decl);
> inform (DECL_SOURCE_LOCATION (known_decl),
> "enumerator %qD does not match ...", known_decl);

In the source code, these two calls should be swapped, to allow reading the
source code from top to bottom.

The diagnostics in enum-bad-1_b.C are extremely hard to read in their current
form, I had to manually wrap the lines in order to see the order of the
messages.  No wonder nobody noticed that the grammar of the diagnostics didn't
make sense.

There must be a way for large dg-regexp annotations to be split into multiple
lines.  To understand the diagnostics, I reformatted it to:
> // { dg-regexp {
> // In module [^\n]*enum-bad-1_a.H, imported at [^\n]*enum-bad-1_b.C:8:\n
> // [^\n]*enum-bad-1_a.H:5:6: error: definition of 'enum ONE' does not match\n
> // [^\n]*enum-bad-1_b.C:3:6: note: existing definition 'enum ONE'\n
> // In module [^\n]*enum-bad-1_a.H, imported at [^\n]*enum-bad-1_b.C:8:\n
> // [^\n]*enum-bad-1_a.H:5:11: note: ... this enumerator 'A'\n
> // [^\n]*enum-bad-1_b.C:3:11: note: enumerator 'Q' does not match ...\n
> // [^\n]*enum-bad-1_b.C:15:1: note: during load of binding '::ONE'\n
> // }
> // }

This clearly shows that the two "..." do not match.

Marked as "testsuite-fail" since it is a classical fail of the testsuite to not
provide enough stylistic freedom to make the source code of the tests readable
without manual editing.

[Bug translation/104552] Mistakes in strings to be translated in GCC 12

[roland.illig at gmx dot de via Gcc-bugs]

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

--- Comment #24 from Roland Illig  ---
>From cp/module.cc:
> error_at (loc, "compiled module is %sversion %s",
>   IS_EXPERIMENTAL (their_ver) ? "experimental " : "",
>   their_string);

The word "experimental" must be translatable into other languages such as
German, French, Russian, currently it isn't.  Fixing this properly requires to
split this message into 2 separate messages since the word "experimental" alone
is too ambiguous to translate without further context.

[Bug translation/104552] Mistakes in strings to be translated in GCC 12

[roland.illig at gmx dot de via Gcc-bugs]

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

--- Comment #25 from Roland Illig  ---
>From cp/module.cc:
  inform (loc, "compiler is %sversion %s%s%s",
  IS_EXPERIMENTAL (my_ver) ? "experimental " : "",
  my_string,
  reject_p ? "" : flag_module_version_ignore
  ? ", be it on your own head!" : ", close enough?",
  reject_p ? "" : " \xc2\xaf\\_(\xe3\x83\x84)_/\xc2\xaf");

Are you sure that you want to output this UTF-8 sequence in locale "C"? 
Furthermore, the conditional strings must be translatable.  See the GCC
diagnostics guidelines for more information.

[Bug translation/104552] Mistakes in strings to be translated in GCC 12

[roland.illig at gmx dot de via Gcc-bugs]

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

--- Comment #26 from Roland Illig  ---
>From cp/module.cc:
> returning to the gate for a mechanical issue

This diagnostic is a fatal error.  Fatal errors must be actionable.  This
diagnostic isn't actionable, instead it increases confusion for no reason.  As
a general rule, don't try to be funny if the GCC user is having a problem right
now and is already mad at you.

[Bug c++/104808] unclear diagnostic "MAP %qD TO %qT"

[roland.illig at gmx dot de via Gcc-bugs]

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

--- Comment #2 from Roland Illig  ---
(In reply to Andrew Pinski from comment #1)
> these are in debug_* functions so they don't need to be translated as they
> are not user visible at all.
> That is they are only used while debugging GCC.

If they do not need to be translated, why are they marked for translation then?
 If they weren't in gcc.pot, I wouldn't have complained.

[Bug c++/104809] Explain ELRoND to translators

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-03-07
 Ever confirmed|0   |1
   Severity|normal  |trivial

--- Comment #1 from Andrew Pinski  ---
>  error_at (loc, "not Encapsulated Lazy Records of Named Declarations");

Maybe it should be:
  error_at (loc, "encapsulated file in the wrong format, not an ELF
file.");

All of the error messages in elf_in::begin in cp/modules.cc should definitely
be improved, though I don't think they will show up that often.

[Bug c++/104615] [Concepts] ICE in explicit instantiation when multiple candidates are valid (CWG2421)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=68608
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-03-07

[Bug target/104613] ICE in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1189

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

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

--- Comment #1 from Andrew Pinski  ---
struct _Unwind_Context _Unwind_Resume_or_Rethrow_this_context;

void offset (int);

struct _Unwind_Context {
  void *reg[7];
} _Unwind_Resume_or_Rethrow() {
  struct _Unwind_Context cur_contextcur_context =
  _Unwind_Resume_or_Rethrow_this_context;
  offset(0);
  __builtin_eh_return ((long) offset, 0);
}

[Bug c++/104616] -Wconversion diagnostic on operator `/` with short ints, only when -fsanitize=undefined is passed

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-07
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed. Most likely the front-end inserts the -fsanitize=undefined before
the processing of the -Wconversion warnings.

[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code

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

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

HaoChen Gui  changed:

   What|Removed |Added

 CC||guihaoc at gcc dot gnu.org

--- Comment #15 from HaoChen Gui  ---
I drafted a patch to define separate expanders for V1TI. It works. I wonder if
I shall add V1TI into VEC_I and define an unified expander for V16QI V8HI V4SI
V2DI and V1TI. Also some insn patterns should be merged then. Please advice.
Thanks a lot.

[Bug fortran/104811] New: maxloc/minloc cannot accept character arguments without `dim` optional argument.

[a.shahmoradi at gmail dot com via Gcc-bugs]

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

Bug ID: 104811
   Summary: maxloc/minloc cannot accept character arguments
without `dim` optional argument.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a.shahmoradi at gmail dot com
  Target Milestone: ---

The following code appears to be standard-conforming. 

```
character(1) :: str(3)
str = ["a", "c", "a"]
print *, maxloc(str) ! requires dim = 1 argument to function.
print *, minloc(str) ! requires dim = 1 argument to function.
end
```

However, gfortran 11 or newer versions generate code that crashes with a
segfault error at runtime,

```
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7faba0a82642 in ???
#1  0x7faba0a81815 in ???
#2  0x7faba070020f in ???
#3  0x7faba0c70caa in ???
#4  0x40125b in MAIN__
at /app/example.f90:3
#5  0x4010bc in main
at /app/example.f90:5
```

The above code snippet can be readily tested here to reproduce the segfault:
https://godbolt.org/z/jGchG7zq3

If we add `dim = 1` to the maxloc/minloc calls, then the error is resolved. But
the dim argument is optional and should not be needed. Intel ifort compiles and
generates a correct answer with the above code.

[Bug fortran/104811] maxloc/minloc cannot accept character arguments without `dim` optional argument.

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org,
   ||tkoenig at netcologne dot de

--- Comment #1 from kargl at gcc dot gnu.org ---
Compiles and executes without optimization or if -fno-frontend-optimize is used
with optimization.

% gfcx -o z -fcheck=all -O3 a.f90
% ./z
Segmentation fault (core dumped)
% gfcx -o z -fcheck=all -O3 -fno-frontend-optimize a.f90
% ./z
   2
   1

[Bug fortran/104812] New: Construct-name with same variable name in scope

[fruitclover at gmail dot com via Gcc-bugs]

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

Bug ID: 104812
   Summary: Construct-name with same variable name in scope
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fruitclover at gmail dot com
  Target Milestone: ---

Is this expected behavior for s1 to disallow construct-name with the same name
as declared variable? 

$ cat -n test.f90
 1  subroutine s1
 2logical :: x
 3x: if (x) then
 4end if x
 5  end
 6  
 7  subroutine s2
 8logical :: x
 9x: block
10end block x
11  end

$ gfortran test.f90 -fsyntax-only -Wall -Wextra
test.f90:3:11:

3 |   x: if (x) then
  |   1
Error: Symbol at (1) is not appropriate for an expression
test.f90:4:5:

4 |   end if x
  | 1
Error: Expecting END SUBROUTINE statement at (1)

[Bug target/101929] [12 Regression] r12-7319 regress x264_r by 4% on CLX.

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

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

--- Comment #7 from Richard Biener  ---
diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index 9188d727e33..7f1f12fb6c6 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -2374,7 +2375,7 @@ fail:
n_vector_builds++;
}
}
-  if (all_uniform_p
+  if ((all_uniform_p && !two_operators)
  || n_vector_builds > 1
  || (n_vector_builds == children.length ()
  && is_a  (stmt_info->stmt)))


will re-enable the vectorization - it evades the vect_construct cost bump
by instead using scalar_to_vec (aka splat) which has not yet been fixed to
account for a possible gpr to xmm move (so it would be a temporary "solution"
at best).

Another change to mute the effect somewhat (but not fixing x264) that was
mentioned is

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index b2bf90576d5..acf2cc977b4 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -22595,7 +22595,7 @@ ix86_builtin_vectorization_cost (enum
vect_cost_for_stmt type_of_cost,
   case vec_construct:
{
  /* N element inserts into SSE vectors.  */
- int cost = TYPE_VECTOR_SUBPARTS (vectype) * ix86_cost->sse_op;
+ int cost = (TYPE_VECTOR_SUBPARTS (vectype) - 1) * ix86_cost->sse_op;
  /* One vinserti128 for combining two SSE vectors for AVX256.  */
  if (GET_MODE_BITSIZE (mode) == 256)
cost += ix86_vec_cost (mode, ix86_cost->addss);

which makes sense as the cost of the initial value of the xmm destination is
now costed separately when from GPR and free when from xmm.

[Bug target/104762] [12 Regression] x86_64 538.imagick_r 8%-28% regressions and 10% 525.x264_r regressions after r12-7319-g90d693bdc9d718

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-03-07
Summary|x86_64 538.imagick_r 8%-28% |[12 Regression] x86_64
   |regressions and 10% |538.imagick_r 8%-28%
   |525.x264_r regressions  |regressions and 10%
   |after   |525.x264_r regressions
   |r12-7319-g90d693bdc9d718|after
   ||r12-7319-g90d693bdc9d718

--- Comment #3 from Richard Biener  ---
See PR101929 comment#7 for two possible things we can do at this stage that
might "fix" the regression.

[Bug ipa/104813] New: ICE on valid code at -O3 on x86_64-linux-gnu: in adjust_references_in_caller, at ipa-cp.cc:4963

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

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

Bug ID: 104813
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu: in
adjust_references_in_caller, at ipa-cp.cc:4963
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

It appears to be a recent regression.

[550] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220307 (experimental) [master r12-7507-gaad3d935189] (GCC) 
[551] % 
[551] % gcctk -O2 small.c; ./a.out
[552] % 
[552] % gcctk -O3 small.c
during IPA pass: cp
small.c:29:1: internal compiler error: in adjust_references_in_caller, at
ipa-cp.cc:4963
   29 | }
  | ^
0x1c6da79 adjust_references_in_caller
../../gcc-trunk/gcc/ipa-cp.cc:4963
0x1c6db04 adjust_refs_in_act_callers
../../gcc-trunk/gcc/ipa-cp.cc:4912
0x8afd26 cgraph_node::call_for_symbol_thunks_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool, bool)
../../gcc-trunk/gcc/cgraph.cc:2447
0x1c6d969 adjust_references_in_caller
../../gcc-trunk/gcc/ipa-cp.cc:4994
0x1c70f63 create_specialized_node
../../gcc-trunk/gcc/ipa-cp.cc:5124
0x1c74530 decide_whether_version_node
../../gcc-trunk/gcc/ipa-cp.cc:6238
0x1c757fb ipcp_decision_stage
../../gcc-trunk/gcc/ipa-cp.cc:6354
0x1c757fb ipcp_driver
../../gcc-trunk/gcc/ipa-cp.cc:6542
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
[553] % 
[553] % cat small.c
int a, b, c, d, *e;
void f(int h) {
  if (b) {
int g;
while (g++)
  d = *e;
e++;
  }
}
static void i();
static void j(int *h, int k, int *l) {
  if (c) {
int *o = h, m;
f(*l);
i(m);
j(o, 1, o);
for (;;)
  ;
  }
}
void i() {
  int *n = &a;
  while (1)
j(n, 1, n);
}
int main() {
  j(&a, 0, &a);
  return 0;
}

[Bug ipa/104813] ICE on valid code at -O3 on x86_64-linux-gnu: in adjust_references_in_caller, at ipa-cp.cc:4963

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

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

--- Comment #1 from Zhendong Su  ---
Compiler Explorer: https://godbolt.org/z/6cfcq4Wed