[Bug other/105335] libiberty does not handle script exit codes correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105335 --- Comment #3 from LIU Hao --- Windows uses a full-width 32-bit exit status, but there is no standard convention for them. 1. If a process has exited successfully, the status is zero. This matches POSIX. 2. If a process has exited due to a fault, the status is an enumeration of `NTSTATUS`, for example it's `0xC01D` for illegal instructions, and `0xC005` for invalid memory access, and so on. The guarantee of these codes is that the lowest byte is never zero. 3. The MSYS2 bash (N.B. I don't know whether they have made such behavior different from Cygwin, but I suspect not) checks whether a child process exits successfully. If not, and the `-e` option is passed, it exits with `(SIGNAL << 8) | (STATUS & 0xFF)`, where `SIGNAL` is the same with Linux, and in the case of normal exit, `STATUS` is the lowest byte passed to `exit()`, which is also the same with Linux. It's probably not necessary to make the exit status very precise for describing the signal for this circumstance.
[Bug middle-end/105342] [Extended Asm]Memory barrier geater than a function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105342 --- Comment #4 from 。 <570070308 at qq dot com> --- (In reply to Richard Biener from comment #1) > Is it really important though? The doc says that "The asm statement allows you to include assembly instructions directly within C code. This may help you to maximize performance in time-sensitive code or to access assembly instructions that are not readily available to C programs.", and I use extended-asm rather than writing a whole function with assembly just for maximize performance. I try my best for not using "memory" clobber, but in some cases I have to use it, for example, using the asm to operate a list structure like the `struct list_head` in Linux. It is impossible to list all the list elements in the Input/OutputOperands.
[Bug middle-end/105342] [Extended Asm]Memory barrier geater than a function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105342
--- Comment #3 from Richard Biener ---
(In reply to Andrew Pinski from comment #2)
> Yes it is greater than a function call as it has to be a barrier to even
> memory which does NOT escape the function.
>
> Yes inlining does change it from dealing with escaped memory to even local
> ones. I doubt it can be fixed though because you have to mark which memory
> was active in the function where it was inlined from and such.
The question is whether we allow an asm (""::: "memory") to clobber
arbitrary parts of the stack the asm somehow magically can associate with
an automatic variable (the compiler could have promoted to a register!).
Basically it currently prevents optimization of stack storage across the
asm the asm cannot rely on being stack storage and thus has to assume it's
in registers. The docs say
--
@item "memory"
The @code{"memory"} clobber tells the compiler that the assembly code
performs memory
reads or writes to items other than those listed in the input and output
operands (for example, accessing the memory pointed to by one of the input
parameters). To ensure memory contains correct values, GCC may need to flush
specific register values to memory before executing the @code{asm}. Further,
the compiler does not assume that any values read from memory before an
@code{asm} remain unchanged after that @code{asm}; it reloads them as
needed.
Using the @code{"memory"} clobber effectively forms a read/write
memory barrier for the compiler.
Note that this clobber does not prevent the @emph{processor} from doing
speculative reads past the @code{asm} statement. To prevent that, you need
processor-specific fence instructions.
--
I think clarifying that it does not protect 'memory' that can be elided
by the compiler wouldn't make it behave different in practice.
[Bug middle-end/105342] [Extended Asm]Memory barrier geater than a function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105342 Andrew Pinski changed: What|Removed |Added Keywords||inline-asm Severity|normal |enhancement
[Bug middle-end/105342] [Extended Asm]Memory barrier geater than a function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105342 --- Comment #2 from Andrew Pinski --- Yes it is greater than a function call as it has to be a barrier to even memory which does NOT escape the function. Yes inlining does change it from dealing with escaped memory to even local ones. I doubt it can be fixed though because you have to mark which memory was active in the function where it was inlined from and such.
[Bug middle-end/105342] [Extended Asm]Memory barrier geater than a function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105342 Richard Biener changed: What|Removed |Added Keywords||missed-optimization CC||rguenth at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-04-22 --- Comment #1 from Richard Biener --- I think this is on purpose - on GIMPLE at least. One would need to analyze what RTL disambiguation does with ASMs (I would guess nothing, just like GIMPLE). I agree that it might be more consistent to only consider things clobbered by a call, but then we need to look at the explicit memory outputs/clobbers. Is it really important though?
[Bug rtl-optimization/105338] [12 Regression] Regression: jump or cmove generated for pattern (x ? CST : 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105338 Richard Biener changed: What|Removed |Added Summary|Regression: jump or cmove |[12 Regression] Regression: |generated for pattern (x ? |jump or cmove generated for |CST : 0)|pattern (x ? CST : 0) Target Milestone|--- |12.0
[Bug middle-end/100810] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100810 --- Comment #13 from Richard Biener --- *** Bug 105337 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/105337] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105337 Richard Biener changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #8 from Richard Biener --- I can confirm that both the original and the reduced testcase work fine with the yet unreviewed patch for PR100810 installed. I've added the reduced testcase to the pending patch. *** This bug has been marked as a duplicate of bug 100810 ***
[Bug sanitizer/105336] truncated address sanitizer stack traces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336 --- Comment #2 from Richard Biener --- Can you provide a testcase that exhibits such behavior?
[Bug other/105335] libiberty does not handle script exit codes correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105335 Richard Biener changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Richard Biener --- The patch probably works but I'm not sure if it's the best we can do since I'm not familiar with the pex internals.
[Bug middle-end/105342] New: [Extended Asm]Memory barrier geater than a function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105342
Bug ID: 105342
Summary: [Extended Asm]Memory barrier geater than a function
call
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: 570070308 at qq dot com
Target Milestone: ---
This is an enhancement request, not a bug.
According to doc, using the "memory" clobber effectively forms a read/write
memory barrier for the compiler. Through my tests, the memory barrier's range
in Extended-Asm is even greater than a function call, it will barrier the
memory in the function's own stack. I think it is useless and it may even
generate more complex code with inline funtion.
For example in the test case:
```test.c
extern unsigned long int x[512];
void test(long int,long int,long int,long int,long int);
void test1(long int);
void test2();
int kkk()
{
unsigned long int k[512];
for (size_t i=0; i<512; ++i )
{
k[i]=x[i];
}
test1(k[0]);
k[1]=3;
k[2]=3;
k[3]=3;
k[4]=3;
k[5]=3;
test2();
test(k[1], k[2], k[3], k[4], k[5]);
return 0;
}
```
and
```test2.c
void test2()
{
__asm__ volatile
(""
:
:
:"memory"
);
}
```
compile with
```
gcc-12 -fno-stack-protector -fcf-protection=none
-fno-asynchronous-unwind-tables -mgeneral-regs-only -O3 -S test.c test2.c
```
than generate
```test.s:
kkk:
subq$4096, %rsp
orq $0, (%rsp)
subq$8, %rsp
leaqx(%rip), %rsi
movl$512, %ecx
movq%rsp, %rdi
rep movsq
movq(%rsp), %rdi
calltest1@PLT
xorl%eax, %eax
calltest2@PLT
movl$3, %r8d
movl$3, %ecx
movl$3, %edx
movl$3, %esi
movl$3, %edi
calltest@PLT
xorl%eax, %eax
addq$4104, %rsp
ret
```
```test2.s
test2:
ret
```
The kkk's assembly code looks neat.
However, if I put the contents of test2.c in test.c, then it will generate:
```test.s
kkk:
subq$4096, %rsp
orq $0, (%rsp)
subq$8, %rsp
leaqx(%rip), %rsi
movl$512, %ecx
movq%rsp, %rdi
rep movsq
movq(%rsp), %rdi
calltest1@PLT
movq$3, 8(%rsp)
movq$3, 16(%rsp)
movq$3, 24(%rsp)
movq$3, 32(%rsp)
movq$3, 40(%rsp)
movq40(%rsp), %r8
movq32(%rsp), %rcx
movq24(%rsp), %rdx
movq16(%rsp), %rsi
movq8(%rsp), %rdi
calltest@PLT
xorl%eax, %eax
addq$4104, %rsp
ret
test2:
ret
```
The compiler automatically inline the function test2() and think k[1], k[2],
k[3], k[4], k[5] is barrier with the extended-asm, so the inlining test2() is
even slower than not inlining it.
The gcc-12 is installed by apt on ubuntu 22.04. Full compile log:
```
$ gcc-12 -fno-stack-protector -fcf-protection=none
-fno-asynchronous-unwind-tables -mgeneral-regs-only -O3 -S test.c test2.c -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-20220319-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-OcsLtf/gcc-12-12-20220319/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-OcsLtf/gcc-12-12-20220319/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 20220319 (experimental) [master r12-7719-g8ca61ad148f]
(Ubuntu 12-20220319-1ubuntu1)
COLLECT_GCC_OPTIONS='-fno-stack-protector' '-fcf-protection=none'
'-fno-asynchronous-unwind-tables' '-mgeneral-regs-only' '-O3' '-S' '-v'
'-mtune=generic' '-march=x86-64'
/usr/lib/gc
[Bug target/105334] [12 Regression] ICE in curr_insn_transform, at lra-constraints.cc:4168 (error: unable to generate reloads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105334 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c++/105297] [12 Regression] new modules 'xtreme' test cases FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105297
--- Comment #15 from Jiu Fu Guo ---
(In reply to Patrick Palka from comment #13)
> (In reply to Jiu Fu Guo from comment #11)
> > (In reply to Patrick Palka from comment #10)
> > >
> > > Interestingly that doesn't seem to make a difference. What seems to
> > > matter
> > > is whether the constexpr function modifies the CONSTRUCTOR that it
> > > returns:
> > >
> > > constexpr auto foo() {
> > > struct S { int d; } t = {};
> > > t.d = 0; // doesn't ICE if this line is commented out
> > > return t;
> > > }
> > >
> > > template
> > > int bar() {
> > > constexpr auto t = foo();
> > > return 0;
> > > }
> >
> > Right, it is weird. Some PRs on Xtreme-* failure (including ICE) were also
> > reported before. e.g. PR100052, PR101853, PR99910. As commented in those
> > PRs, these may be random failures, and changes in headers that could expose
> > the ICE.
> > I'm also wondering if this may be an issue hidden inside somewhere (GC?).
>
> In this case I suspect it's just a bug in the modules code, I opened
> PR105322 to track it.
Oh, thanks! This failure seems only about the module code on 'struct member
cross functions'.
[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612 Andrew Pinski changed: What|Removed |Added CC||MF21330112 at smail dot nju.edu.cn --- Comment #45 from Andrew Pinski --- *** Bug 105341 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/105341] Load introduction when writing a global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105341 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed in GCC 11 by the patch for PR 39612 which is exactly the same issue as here. *** This bug has been marked as a duplicate of bug 39612 ***
[Bug c/105341] New: Load introduction when writing a global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105341
Bug ID: 105341
Summary: Load introduction when writing a global variable
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: MF21330112 at smail dot nju.edu.cn
Target Milestone: ---
Considering the following code:
int g1;
static short g2[3][6] =
{{(-8L),0xD50FL,(-8L),0x6E22L,0xD50FL,0x52F6L},{(-8L),0xECAFL,0x6E22L,0x6E22L,0xECAFL,(-8L)},{(-8L),0xA927L,0x52F6L,0x6E22L,0xA927L,0x6E22L}};
short func_35(unsigned char p1, long long p2)
{
int l1 = 8L;
if (((unsigned char)p1 + (unsigned char)1L))
{
unsigned short l2[7] = {0xE3C8L,0xE3C8L,0xE3C8L,
0xE3C8L,0xE3C8L,0xE3C8L,0xE3C8L};
for (p2 = 6; (p2 >= 2); p2 -= 1)
{
int *l3 = &g1;
short l4[4][4] =
{{0L,0x153EL,0x3343L,0xEF57L},{0L,0x3343L,0xCB45L,0x3343L},{0xCB45L,0x3343L,0L,0xEF57L},{0xF2DBL,0xEF57L,0L,(-2L)}};
if (l2[p2])
continue;
(*l3) = (unsigned long long)((l1 != &g2[1][4]) - (unsigned long
long)(l4[1][1] &= p1));
}
}
return p2;
}
int main(){
func_35(0,0);
printf("%d\n", g1);
}
g1's value may be modified by writing to its address held by l3. However, after
compiled with -O1 or -O2 on gcc 9.3.0, a redundant load instruction has been
generated and will be executed. This may cause some vulnerabilities of this
program:
func_35:
...
0x122b <+11>:mov0x2de3(%rip),%ecx# 0x4014
...
0x1274 <+84>:cmpw $0x0,0xa(%rax)
0x1279 <+89>:mov$0x1,%esi
0x127e <+94>:cmove %edi,%ecx
0x1281 <+97>:cmove %esi,%edx
0x1284 <+100>: sub$0x2,%rax
0x1288 <+104>: cmp%r8,%rax
0x128b <+107>: jne0x1274
0x128d <+109>: test %dl,%dl
0x128f <+111>: je 0x1297
0x1291 <+113>: mov%ecx,0x2d7d(%rip)# 0x4014
[Bug driver/105340] xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105340
--- Comment #5 from Andrew Pinski ---
(In reply to okay from comment #4)
> When compiling gcc from source code, which parameter should give to
> configure script? such as ${BINUTILS_SOURCE_DIR}/configure
> --prefix=${NATIVE_PREFIX} --with-sysroot=${CROSS_PREFIX} etc.
I don't understand your question and questions like these are better answered
on the gcc-help mailing list rather than here.
[Bug driver/105340] xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105340
--- Comment #4 from okay ---
When compiling gcc from source code, which parameter should give to configure
script? such as ${BINUTILS_SOURCE_DIR}/configure --prefix=${NATIVE_PREFIX}
--with-sysroot=${CROSS_PREFIX} etc.
[Bug driver/105340] xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105340 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #3 from Andrew Pinski --- >/home/gcc-7.5.0/host-aarch64-unknown-linux-gnu/gcc/xgcc Invoking xgcc without any -B is not very useful. You either need to install GCC before running or use a few -B options to get the correct directories. This is not normal way of running GCC either.
[Bug libstdc++/79700] std::fabsf and std::fabsl missing from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700 --- Comment #19 from Jiang An --- Oh... I was wrong. TR1 mentioned -f and -l variants of "new" (C99) function families (e.g. truncf), but no those of "old" (C89) math function families.
[Bug driver/105340] xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105340
--- Comment #2 from okay ---
[root]# cat main.c
int main()
{
return 0;
}
[root]# /home/gcc-7.5.0/host-aarch64-unknown-linux-gnu/gcc/xgcc -o main main.c
xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.
[Bug driver/105340] xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105340 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-04-22 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- First off don't compile in the source tree. Second can you show the exact command line that is being involved?
[Bug target/105339] [x86] missing AVX-512F scalef functions when optimization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105339
--- Comment #2 from Hongtao.liu ---
We need to add macro for _mm_{mask,maskz}_scalef_round_{sd,ss} intriniscs for
gcc-9/10/11/12
[Bug c/105340] New: xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105340 Bug ID: 105340 Summary: xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found Product: gcc Version: 7.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: szy_mailbox at 126 dot com Target Milestone: --- When compiled with a helloword program, it reports the above error, how to solve? does it exist in high version gcc? My gcc version is: [root]# /home/gcc-7.5.0/host-aarch64-unknown-linux-gnu/gcc/xgcc -v Using built-in specs. COLLECT_GCC=/home/gcc-7.5.0/host-aarch64-unknown-linux-gnu/gcc/xgcc Target: aarch64-unknown-linux-gnu Configured with: ./configure Thread model: posix gcc version 7.5.0 (GCC) which is compiled from source code.
[Bug target/105339] [x86] missing AVX-512F scalef functions when optimization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105339 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #1 from Hongtao.liu --- Hmm 3316#define _mm_mask_scalef_sd(W, U, A, B) \ 3317_mm_mask_scalef_round_sd ((W), (U), (A), (B), _MM_FROUND_CUR_DIRECTION) 3318 3319#define _mm_maskz_scalef_sd(U, A, B) \ 3320_mm_maskz_scalef_round_sd ((U), (A), (B), _MM_FROUND_CUR_DIRECTION) 3321 3322#define _mm_mask_scalef_ss(W, U, A, B) \ 3323_mm_mask_scalef_round_ss ((W), (U), (A), (B), _MM_FROUND_CUR_DIRECTION) 3324 3325#define _mm_maskz_scalef_ss(U, A, B) \ 3326_mm_maskz_scalef_round_ss ((U), (A), (B), _MM_FROUND_CUR_DIRECTION) they're defined as macros, but _mm_maskz_scalef_round_ss is only available under __OPTIMIZE__.
[Bug tree-optimization/102892] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892
jiawei changed:
What|Removed |Added
CC||jiawei at iscas dot ac.cn
--- Comment #11 from jiawei ---
(In reply to Eric Botcazou from comment #8)
I use the RISC-V target test and get the same result, and link fail with
'undefined reference to `foo`'.
> The test fails (to link) on SPARC though, here's the .optimized dump at -O3:
>
> ;; Function main (main, funcdef_no=0, decl_uid=1488, cgraph_uid=1,
> symbol_order=1) (executed once)
>
> Removing basic block 8
> Removing basic block 9
> Removing basic block 10
> Removing basic block 11
> int main ()
> {
> unsigned int ivtmp.8;
> long int a;
> long int _1;
> void * _2;
> unsigned int _17;
>
>[local count: 44232128]:
> if (a_9(D) != 1)
> goto ; [89.00%]
> else
> goto ; [11.00%]
>
>[local count: 715863673]:
> # ivtmp.8_23 = PHI
> bar ();
> _2 = (void *) ivtmp.8_23;
> _1 = MEM[(long int *)_2];
> if (_1 == 1)
> goto ; [20.24%]
> else
> goto ; [79.76%]
>
>[local count: 144890806]:
> foo ();
>
>[local count: 715863674]:
> ivtmp.8_24 = ivtmp.8_23 + 4;
> if (_17 != ivtmp.8_24)
> goto ; [66.67%]
> else
> goto ; [33.33%]
>
>[local count: 238597362]:
> ivtmp.8_7 = (unsigned int) &b;
> _17 = ivtmp.8_7 + 8;
> goto ; [100.00%]
>
>[local count: 44232131]:
> return 0;
> }
[Bug target/105334] [12 Regression] ICE in curr_insn_transform, at lra-constraints.cc:4168 (error: unable to generate reloads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105334
--- Comment #5 from Kewen Lin ---
Oops, sorry that I just verified the original case in PR103623 previously,
missed to find it doesn't have pack bif.
Maybe we could add one test case to cover both unpack and pack ICEs, such as:
$cat gcc/testsuite/gcc.target/powerpc/pr105334.c
/* { dg-skip-if "" { powerpc*-*-darwin* } } */
/* { dg-options "-mlong-double-128 -msoft-float" } */
/* Verify there is no ICE. */
#include
#include
#include
#if defined(__LONG_DOUBLE_IEEE128__)
/* If long double is IEEE 128-bit, we need to use the __ibm128 type instead of
long double, and to use the appropriate pack/unpack routines. We can't use
__ibm128 on systems that don't support IEEE 128-bit floating point, because
the type is not enabled on those systems. */
#define PACK __builtin_pack_ibm128
#define UNPACK __builtin_unpack_ibm128
#define LDOUBLE __ibm128
#elif defined(__LONG_DOUBLE_IBM128__)
#define PACK __builtin_pack_longdouble
#define UNPACK __builtin_unpack_longdouble
#define LDOUBLE long double
#else
#error "long double must be either IBM 128-bit or IEEE 128-bit"
#endif
extern LDOUBLE bar (LDOUBLE);
int
main (void)
{
double high = pow (2.0, 60);
double low = 2.0;
LDOUBLE a = ((LDOUBLE) high) + ((LDOUBLE) low);
double x0 = UNPACK (a, 0);
double x1 = UNPACK (a, 1);
LDOUBLE b = PACK (x0, x1);
LDOUBLE c = bar (b);
return c > a;
}
---
I confirmed this case will ICE if without Segher's proposed patch and even also
reverted Segher's r12-8091.
[Bug target/105339] New: [x86] missing AVX-512F scalef functions when optimization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105339 Bug ID: 105339 Summary: [x86] missing AVX-512F scalef functions when optimization is disabled Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: e...@coeus-group.com Target Milestone: --- Several AVX-512F functions scalef functions are only declared when __OPTIMIZE__ is defined: * _mm_maskz_scalef_ss * _mm_mask_scalef_sd * _mm_maskz_scalef_sd There may be others; I haven't done an exhaustive check.
[Bug target/105334] [12 Regression] ICE in curr_insn_transform, at lra-constraints.cc:4168 (error: unable to generate reloads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105334 --- Comment #4 from Segher Boessenkool --- Created attachment 52849 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52849&action=edit proposed patch
[Bug target/105334] [12 Regression] ICE in curr_insn_transform, at lra-constraints.cc:4168 (error: unable to generate reloads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105334 --- Comment #3 from Segher Boessenkool --- Oh duh, this is pack, not unpack. I see the problem now.
[Bug tree-optimization/105329] Bogus restrict warning when assigning 1-char string literal to std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 --- Comment #3 from Andrew Macleod --- Just to bookmark where the analysis is since im out for a few days, in the restrict pass, with ranger tracing on, the code sequence is: [local count: 14831835]: __nleft_49 = (const size_type) _48; __builtin_memcpy (_22, "5", __nleft_49); and the ranger trace from wrestrict shows: TRUE : (5628) range_of_expr (_48) long int [-INF, 0][2, +INF] TRUE : (5617) range_of_stmt (__nleft_49) const size_type [2, 9223372036854775807] So we know _48 is non-zero, and when I further delve into things, ranger is calculating __nleft_49 correct as [0, 0][2, +INF], but when it merges this with the current known global range, THAT has been set somewhere as [2, 9223372036854775807] Im trying to find where the global value is first set. when I put a breakpoint in the set and get routines, the very first thing that triggers is: #0 gimple_range_global (name=0x7fffefd0be10) at /opt/notnfs/amacleod/master/gcc/gcc/value-query.cc:419 #1 0x02e73534 in ranger_cache::get_global_range (this=0x41797b8, r=..., name=0x7fffefd0be10) at /opt/notnfs/amacleod/master/gcc/gcc/gimple-range-cache.cc:925 #2 0x02e73580 in ranger_cache::get_global_range (this=0x41797b8, r=..., name=0x7fffefd0be10, current_p=@0x7fff9c37: false) at /opt/notnfs/amacleod/master/gcc/gcc/gimple-range-cache.cc:939 #3 0x02e6f731 in gimple_ranger::range_of_stmt (this=0x4179790, r=..., s=0x7fffef265000, name=0x7fffefd0be10) at /opt/notnfs/amacleod/master/gcc/gcc/gimple-range.cc:307 #4 0x02e6edc2 in gimple_ranger::range_on_entry (this=0x4179790, r=..., bb=0x7fffeecc4340, name=0x7fffefd0be10) at /opt/notnfs/amacleod/master/gcc/gcc/gimple-range.cc:151 #5 0x02e6ec40 in gimple_ranger::range_of_expr (this=0x4179790, r=..., expr=0x7fffefd0be10, stmt=0x7fffeeca8f78) at /opt/notnfs/amacleod/master/gcc/gcc/gimple-range.cc:128 #6 0x01b4cd0d in get_range (val=0x7fffefd0be10, stmt=0x7fffeeca8f78, minmax=0x7fffbe10, rvals=0x4179790) at /opt/notnfs/amacleod/master/gcc/gcc/tree-ssa-strlen.cc:219 #7 0x016f8fae in get_offset_range (x=0x7fffefd0be10, stmt=0x7fffeeca8f78, r=0x7fffc0b0, rvals=0x4179790) at /opt/notnfs/amacleod/master/gcc/gcc/pointer-query.cc:92 #8 0x01702c2f in handle_ssa_name (ptr=0x7fffef8d20d8, addr=false, ostype=0, pref=0x7fffc5d0, snlim=..., qry=0x4167468) at /opt/notnfs/amacleod/master/gcc/gcc/pointer-query.cc:2157 #9 0x0170375b in compute_objsize_r (ptr=0x7fffef8d20d8, stmt=0x7fffeeca8f78, addr=false, ostype=0, pref=0x7fffc5d0, snlim=..., qry=0x4167468) at /opt/notnfs/amacleod/master/gcc/gcc/pointer-query.cc:2321 #10 0x01703907 in compute_objsize (ptr=0x7fffef8d20d8, stmt=0x7fffeeca8f78, ostype=0, pref=0x7fffc5d0, ptr_qry=0x4167468) at /opt/notnfs/amacleod/master/gcc/gcc/pointer-query.cc:2355 #11 0x016ff4e4 in pointer_query::get_ref (this=0x4167468, ptr=0x7fffef8d20d8, stmt=0x7fffeeca8f78, pref=0x7fffc5d0, ostype=0) at /opt/notnfs/amacleod/master/gcc/gcc/pointer-query.cc:1505 #12 0x013b99c3 in (anonymous namespace)::pass_waccess::check_dangling_stores (this=0x4167410, bb=0x7fffeecc4340, stores=..., bbs=...) at /opt/notnfs/amacleod/master/gcc/gcc/gimple-ssa-warn-access.cc:4528 with p vr.dump(stderr) const size_type [1, 9223372036854775807] I also have a breakpoint in set_range_info for this name which hasn't been triggered. So either the set routine have been bypassed or perhaps inlining is setting this global value? Im still trying to figure out who and where has decided that __nleft_49 is [2, 0x7FFF] instead of [2, 0x]
[Bug c++/96957] [9/10/11/12 Regression] GCC thinks a non-dependent base is dependent because of template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96957 Marek Polacek changed: What|Removed |Added Status|NEW |SUSPENDED CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- DR1390 is still not resolved.
[Bug preprocessor/44317] ,##__VA_ARGS__ comma not eaten with -std=c++0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44317 Kaz Kylheku changed: What|Removed |Added CC||kkylheku at gmail dot com --- Comment #12 from Kaz Kylheku --- (In reply to Harald van Dijk from comment #9) > The comma should not be eaten, as the invocation of FAIL() is valid in > standard C++. The rules of concatenation of empty pp-token sequences are > well-defined: the empty sequences are replaced by placemarker preprocessor > tokens, and concatenating any non-placeholder token with a placemarker > preprocessor token produces the former, see [cpp.concat]. And thus, more directly to the point, here is the fix: cpp -std=gnu++0x test.cpp The behavior does not reproduce then; the comma eating works. If you want GNU extensions, request the GNU dialect which most closely corresponds to the ISO dialect you want. The issue here is that ## __VA_ARGS__ is a conforming extension in C, and so it can work even when an ISO dialect is selected. The documentation does not mention that ## __VA_ARGS__ might be valid in some dialects of C++ and so has to be enabled as a nonconforming extension. Also this is an opton. The following workaround also works for me, on gcc 10.x on Debian 11: #define ASSERT( cnd, ... ) SomeClass() __VA_OPT__(,) __VA_ARGS__ #define FAIL( ... )SomeClass() __VA_OPT__(,) __VA_ARGS__ This works with "cpp" with no options, with "-std=gnu++0x", and with "-std=c++0x". This may be a better workaround for someone who doesn't want to broadly switch to the GNU dialect. __VA_OPT__ didn't exist when this bug was opened.
[Bug target/103197] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197 --- Comment #14 from CVS Commits --- The master branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:748d46cd049c89a799f99f14547267ebae915af6 commit r12-8222-g748d46cd049c89a799f99f14547267ebae915af6 Author: Segher Boessenkool Date: Thu Apr 21 18:35:32 2022 + rs6000/testsuite: xfail bswap-brw.c This testcase does not generate anywhere near optimal code for 32-bit code. For p10 it actually now fails this testcase, after the previous patch. Let's xfail it. 2022-04-21 Segher Boessenkool gcc/testsuite/ PR target/103197 PR target/102146 * gcc.target/powerpc/bswap-brw.c: Add xfail on scan-assembler for -m32.
[Bug target/102146] [11 regression] several test cases fails after r11-8940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146 --- Comment #12 from CVS Commits --- The master branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:748d46cd049c89a799f99f14547267ebae915af6 commit r12-8222-g748d46cd049c89a799f99f14547267ebae915af6 Author: Segher Boessenkool Date: Thu Apr 21 18:35:32 2022 + rs6000/testsuite: xfail bswap-brw.c This testcase does not generate anywhere near optimal code for 32-bit code. For p10 it actually now fails this testcase, after the previous patch. Let's xfail it. 2022-04-21 Segher Boessenkool gcc/testsuite/ PR target/103197 PR target/102146 * gcc.target/powerpc/bswap-brw.c: Add xfail on scan-assembler for -m32.
[Bug target/103197] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
--- Comment #13 from CVS Commits ---
The master branch has been updated by Segher Boessenkool :
https://gcc.gnu.org/g:26fa464f42622c60d6929720dd37143a21054ede
commit r12-8221-g26fa464f42622c60d6929720dd37143a21054ede
Author: Segher Boessenkool
Date: Sun Jan 2 14:08:35 2022 +
rs6000: Disparage lfiwzx and similar
RA now chooses GEN_OR_VSX_REGS in most cases. This is great in most
cases, but we often (or always?) use {l,st}{f,xs}iwzx now, which is
problematic because the integer load and store insns can use cheaper
addressing modes. We can fix that by putting a small penalty on the
instruction alternatives for those.
2022-04-21 Segher Boessenkool
PR target/103197
PR target/102146
* config/rs6000/rs6000.md (zero_extendqi2 for EXTQI):
Disparage
the "Z" alternatives in {l,st}{f,xs}iwzx.
(zero_extendhi2 for EXTHI): Ditto.
(zero_extendsi2 for EXTSI): Ditto.
(*movsi_internal1): Ditto.
(*mov_internal1 for QHI): Ditto.
(movsd_hardfloat): Ditto.
[Bug target/102146] [11 regression] several test cases fails after r11-8940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #11 from CVS Commits ---
The master branch has been updated by Segher Boessenkool :
https://gcc.gnu.org/g:26fa464f42622c60d6929720dd37143a21054ede
commit r12-8221-g26fa464f42622c60d6929720dd37143a21054ede
Author: Segher Boessenkool
Date: Sun Jan 2 14:08:35 2022 +
rs6000: Disparage lfiwzx and similar
RA now chooses GEN_OR_VSX_REGS in most cases. This is great in most
cases, but we often (or always?) use {l,st}{f,xs}iwzx now, which is
problematic because the integer load and store insns can use cheaper
addressing modes. We can fix that by putting a small penalty on the
instruction alternatives for those.
2022-04-21 Segher Boessenkool
PR target/103197
PR target/102146
* config/rs6000/rs6000.md (zero_extendqi2 for EXTQI):
Disparage
the "Z" alternatives in {l,st}{f,xs}iwzx.
(zero_extendhi2 for EXTHI): Ditto.
(zero_extendsi2 for EXTSI): Ditto.
(*movsi_internal1): Ditto.
(*mov_internal1 for QHI): Ditto.
(movsd_hardfloat): Ditto.
[Bug tree-optimization/105329] Bogus restrict warning when assigning 1-char string literal to std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 --- Comment #2 from Andrew Macleod --- The problem goes away if we use --param=evrp-mode-legacy. Ranger picks up a few more things and we eliminate a couple of latter comparisons which in turn affect threading, etc etc. and we present the restrict pass with something different that causes issues. I'm in the middle of analyzing it and will post the results when I'm done.
[Bug d/102185] d: STRING_CSTs converted back into StringExp include null pointer in length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102185 --- Comment #4 from Andreas Schwab --- The test fails on riscv because it doesn't handle floatABI == "double".
[Bug fortran/100813] Function of array of pointers to abstract class returning an array since r6-202-gf3b0bb7a560be0f0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100813 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #2 from Mikael Morin --- It seems to work with a recent master (12.0.1 20220410).
[Bug target/105334] [12 Regression] ICE in curr_insn_transform, at lra-constraints.cc:4168 (error: unable to generate reloads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105334 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2022-04-21 Resolution|DUPLICATE |--- Ever confirmed|0 |1 Status|RESOLVED|REOPENED --- Comment #2 from Segher Boessenkool --- It actually still ICEs? Huh.
[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623 --- Comment #34 from Segher Boessenkool --- *** Bug 105334 has been marked as a duplicate of this bug. ***
[Bug target/105334] [12 Regression] ICE in curr_insn_transform, at lra-constraints.cc:4168 (error: unable to generate reloads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105334 Segher Boessenkool changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Keywords|accepts-invalid,| |ice-on-invalid-code | --- Comment #1 from Segher Boessenkool --- Dup of PR103623. *** This bug has been marked as a duplicate of bug 103623 ***
[Bug rtl-optimization/105338] New: Regression: jump or cmove generated for pattern (x ? CST : 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105338
Bug ID: 105338
Summary: Regression: jump or cmove generated for pattern (x ?
CST : 0)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
int f(int i) {
return i ? 5 : 0;
}
int g(int i) {
return i ? -2 : 0;
}
int h(int b) {
return !!b * -2;
}
int i(int b) {
return !!b * 5;
}
int j(int b) {
if (!b) return 0;
return -2;
}
-
With -02 gcc 11.2 the five functions above output branchless code like:
f(int):
neg edi
sbb eax, eax
and eax, 5
ret
g(int):
neg edi
sbb eax, eax
and eax, -2
ret
...
--
Whereas -02 gcc 12 now outputs a cmov or jump depending of sign of the
constant:
f(int):
mov eax, edi
testedi, edi
mov edx, 5
cmovne eax, edx
ret
g(int):
mov eax, edi
testedi, edi
jne .L11
ret
.L11:
mov eax, -2
ret
h(int):
mov eax, edi
testedi, edi
jne .L17
ret
.L17:
mov eax, -2
ret
i(int):
mov eax, edi
testedi, edi
mov edx, 5
cmovne eax, edx
ret
j(int):
mov eax, edi
testedi, edi
mov edx, -2
cmovne eax, edx
ret
---
Alternatively, with the following code
int k(int b) {
bool b2 = b;
return b2 * 5;
}
Both gcc 12 and 11.2 are outputing
k(int):
xor eax, eax
testedi, edi
setne al
lea eax, [rax+rax*4]
ret
[Bug fortran/104845] Wrong array size for component of CLASS array element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104845 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- (In reply to Tobias Burnus from comment #0) > > allocate (t :: var%ct2%d(3,2), var%ct2a(5,4,2)%d(3,2)) > allocate (t :: cvar%ct2%d(3,2), cvar%ct2a(5,4,2)%d(3,2)) > > Thus, the expected array size is 3*2 = 6. However, the result is > 6 0 6 0 > for > print *, size(var%ct2%d), size(var%ct2a(5,3,2)%d), & >size(cvar%ct2%d), size(cvar%ct2a(5,3,2)%d) > > where 'ct2' is scalar > and 'ct2a(5,3,2)' is an array element (also scalar) ct2a(5,3,2)%d isn’t allocated, should it be ct2a(5,4,2)%d ?
[Bug fortran/93256] Assumed-shape unlimited polymorphic variable passes values incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93256 --- Comment #2 from Thomas Koenig --- Works for 12.0., fails with 9.4.0. So, I assume this has been fixed in the meantime, it would be interesting to see when.
[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #13 from Mikael Morin --- Fixed?
[Bug c++/105321] [9/10/11 Regression] "non-constant condition" issued for function containing a short-circuited unevaluated non-constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105321 --- Comment #8 from James Touton --- Thanks for the quick action on this!
[Bug tree-optimization/105337] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105337 --- Comment #7 from Jakub Jelinek --- Perhaps similar or dup of PR100810?
[Bug tree-optimization/105337] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105337 Jakub Jelinek changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- I'd say that ivopts is at fault here. Before that we have: [local count: 312727306]: [local count: 805306369]: # b_14 = PHI # c_15 = PHI # ivtmp_3 = PHI a.0_1 = a; if (a.0_1 == 0) goto ; [5.50%] else goto ; [94.50%] ... [local count: 44291850]: # b_4 = PHI [local count: 312727306]: # b_10 = PHI return b_10; as the path actually taken at runtime, yes, we use uninitialized c in the PHI, but that doesn't correspond to UB at runtime. But ivopts changes that to: [local count: 312727306]: _19 = (unsigned int) c_5(D); _20 = _19 + 4294967293; _21 = (int) _20; [local count: 805306369]: # c_15 = PHI _13 = (unsigned int) c_5(D); _12 = (unsigned int) c_15; _11 = -_12; _18 = _11 + _13; b_14 = (int) _18; a.0_1 = a; if (a.0_1 == 0) goto ; [5.50%] else goto ; [94.50%] ... [local count: 44291850]: # b_4 = PHI [local count: 312727306]: # b_10 = PHI return b_10; and now it uses the uninitialized value in arithmetics in the actually executed code. And, even the return value which gets a copy of b_14 now depends on that uninitialized value. I think we had some other PR about this... Then comes ccp4 and figures out that many values are UNDEFINED and optimizes it into return 3;
[Bug fortran/93256] Assumed-shape unlimited polymorphic variable passes values incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93256 Mikael Morin changed: What|Removed |Added Status|NEW |WAITING CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin --- Can’t reproduce, it prints 10, 20, 30 in order.
[Bug tree-optimization/105337] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105337
--- Comment #5 from Jakub Jelinek ---
printf isn't really needed. This fails even with -O2, doesn't with -O1 or -O0:
__attribute__((noipa)) void
bar (int x)
{
(void) x;
}
int a;
int
foo (void)
{
int b, c;
for (b = 0; b < 3; b++)
{
if (!a)
break;
c--;
bar (c);
}
return b;
}
int
main ()
{
if (foo ())
__builtin_abort ();
return 0;
}
[Bug tree-optimization/105337] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105337 --- Comment #4 from Marek Polacek --- Eh, disregard previous comment, sorry.
[Bug tree-optimization/105337] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105337 --- Comment #3 from Marek Polacek --- Ah, but the testcase has UB: c is used uninitialized.
[Bug other/105335] libiberty does not handle script exit codes correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105335 --- Comment #1 from Andrew Pinski --- The reason for the lower byte only is because posix says exit value is truncated to char. This seems like libiberty not knowing that win32 does not truncate to byte unlike posix. Note I thought the c standard says the same too.
[Bug tree-optimization/105337] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105337 Marek Polacek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Target Milestone|--- |12.0 CC||aoliva at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Keywords||wrong-code Last reconfirmed||2022-04-21 Summary|wrong code at -Os and above |[12 Regression] wrong code |on x86_64-linux-gnu |at -Os and above on ||x86_64-linux-gnu --- Comment #2 from Marek Polacek --- Confirmed. Started with r12-397-gda9e6e63d1ae22, in particular this hunk: --- a/gcc/passes.def +++ b/gcc/passes.def @@ -336,8 +336,9 @@ along with GCC; see the file COPYING3. If not see NEXT_PASS (pass_thread_jumps); NEXT_PASS (pass_vrp, false /* warn_array_bounds_p */); /* Threading can leave many const/copy propagations in the IL. -Clean them up. */ - NEXT_PASS (pass_copy_prop); +Clean them up. Instead of just copy_prop, we use ccp to +compute alignment and nonzero bits. */ + NEXT_PASS (pass_ccp, true /* nonzero_p */); NEXT_PASS (pass_warn_restrict); NEXT_PASS (pass_dse); NEXT_PASS (pass_cd_dce, true /* update_address_taken_p */);
[Bug tree-optimization/105337] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105337 --- Comment #1 from Zhendong Su --- Compiler Explorer: https://godbolt.org/z/1bds4P7c7
[Bug tree-optimization/105337] New: wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105337
Bug ID: 105337
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
[586] % 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 20220421 (experimental) [master r12-8217-g605a80bb733] (GCC)
[587] %
[587] % gcctk -O1 small.c; ./a.out
[588] %
[588] % gcctk -Os small.c
[589] % ./a.out
Aborted
[590] %
[590] % cat small.c
int printf(const char *, ...);
int a;
int f() {
int b, c;
for (b = 0; b < 3; b++) {
if (!a)
break;
c--;
printf("%d", c);
}
return b;
}
int main() {
if (f())
__builtin_abort ();
return 0;
}
[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Mikael Morin --- (In reply to Jürgen Reuter from comment #5) > I checked again, and I don't see any issues any more. There might still be > some memory leaks, I haven't checked. Would it make sense to close this one > and open a new report in case there is a definite reproducer? Yes, assuming fixed. Closing.
[Bug tree-optimization/105276] [12 Regression] executed once loop not optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105276 --- Comment #3 from Andrew Macleod --- Created attachment 52848 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52848&action=edit proposed patch When I removed the recursion from range_of_stmt, I neglected to incorporate the existing known global range for an ssa-name into the calculated value. Range_of_stmt does this, but the prefill calculation missed it. This patch fixes that oversight.
[Bug c++/105321] [9/10/11 Regression] "non-constant condition" issued for function containing a short-circuited unevaluated non-constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105321 Marek Polacek changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |"non-constant condition"|"non-constant condition" |issued for function |issued for function |containing a|containing a |short-circuited unevaluated |short-circuited unevaluated |non-constant expression |non-constant expression --- Comment #7 from Marek Polacek --- Fixed on trunk so far.
[Bug fortran/99308] [OOP] passing array of object as class(TYPE) to procedure leads to incorrect length of array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99308 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- Possible duplicate of PR57590, which has lengthy explanations.
[Bug libstdc++/96592] [10 Regression] Tuple element w/ member reference to incomplete template type rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96592 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d65b274f1f44c59382b7dad7759cfaf3c8397cf8 commit r11-9927-gd65b274f1f44c59382b7dad7759cfaf3c8397cf8 Author: Jonathan Wakely Date: Fri Nov 26 17:46:47 2021 + libstdc++: Remove workaround for FE bug in std::tuple [PR96592] The FE bug was fixed, so we don't need this workaround now. libstdc++-v3/ChangeLog: PR libstdc++/96592 * include/std/tuple (tuple::is_constructible): Remove. (cherry picked from commit 76c6be48b7841524974754f8ea7533b82c7de77e)
[Bug c++/102177] Implement C++17 P0418R2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102177 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fef3d31bd35f53cbcacaec63b279d38c38b78abe commit r11-9926-gfef3d31bd35f53cbcacaec63b279d38c38b78abe Author: Jonathan Wakely Date: Thu Sep 2 15:29:22 2021 +0100 libstdc++: Remove "no stronger" assertion in compare exchange [PR102177] P0418R2 removed some preconditions from std::atomic::compare_exchange_* but we still enforce them via __glibcxx_assert. This removes those assertions. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR c++/102177 * include/bits/atomic_base.h (__is_valid_cmpexch_failure_order): New function to check if a memory order is valid for the failure case of compare exchange operations. (__atomic_base::compare_exchange_weak): Simplify assertions by using __is_valid_cmpexch_failure_order. (__atomic_base::compare_exchange_strong): Likewise. (__atomic_base::compare_exchange_weak): Likewise. (__atomic_base::compare_exchange_strong): Likewise. (__atomic_impl::compare_exchange_weak): Add assertion. (__atomic_impl::compare_exchange_strong): Likewise. * include/std/atomic (atomic::compare_exchange_weak): Likewise. (atomic::compare_exchange_strong): Likewise. (cherry picked from commit dba1ab212292839572fda60df00965e094a11252)
[Bug c/105180] [9/10/11/12 Regression] K&R style definition does not evaluate array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105180 Joseph S. Myers changed: What|Removed |Added Summary|K&R style definition does |[9/10/11/12 Regression] K&R |not evaluate array size |style definition does not ||evaluate array size Status|UNCONFIRMED |NEW Target Milestone|--- |9.5 Ever confirmed|0 |1 Last reconfirmed||2022-04-21
[Bug libquadmath/105101] incorrect rounding for sqrtq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #13 from Michael_S ---
It turned out that on all micro-architectures that I care about (and majority
of those that I don't care) double precision floating point division is quite
fast.
It's so fast that it easily beats my clever reciprocal estimator.
Which means that this simple code is faster than complicated code above.
Not by much, but faster. And much simpler.
#include
#include
#include
static __inline uint64_t umulx64(uint64_t mult1, uint64_t mult2, int rshift)
{
return (uint64_t)(((unsigned __int128)mult1 * mult2)>>rshift);
}
static __inline uint64_t umulh64(uint64_t mult1, uint64_t mult2)
{
return umulx64(mult1, mult2, 64);
}
static __inline void set__float128(__float128* dst, uint64_t wordH, uint64_t
wordL) {
unsigned __int128 res_u128 = ((unsigned __int128)wordH << 64) | wordL;
memcpy(dst, &res_u128, sizeof(*dst)); // hopefully __int128 and __float128
have the endianness
}
// return number of leading zeros
static __inline int normalize_float128(uint64_t* pMantH, uint64_t* pMantL) {
const uint64_t MANT_H_MSK = (uint64_t)-1 >> 16;
uint64_t mantH = *pMantH, mantL = *pMantL;
int lz;
if (mantH == 0) {
lz = __builtin_clzll(mantL);
mantL <<= lz + 1; // shift out all leading zeroes and first leading 1
mantH = mantL >> 16;
mantL = mantL << 48;
lz += 48;
} else {
lz = __builtin_clzll(mantH)-16;
mantH = (mantH << (lz+1)) | mantL >> (63-lz);
mantL = mantL << (lz + 1);
}
mantH &= MANT_H_MSK;
*pMantH = mantH;
*pMantL = mantL;
return lz;
}
static __inline uint64_t d2u(double x) {
uint64_t y;
memcpy(&y, &x, sizeof(y));
return y;
}
static __inline double u2d(uint64_t x) {
double y;
memcpy(&y, &x, sizeof(y));
return y;
}
// calc_reciprocal
// calculate lower estimate for r = floor(2**64/(1 + mantHi*2**(-48) +
mantLo*2**(-112)))
static __inline uint64_t calc_reciprocal(uint64_t mantHi, uint64_t mantLo)
{
const uint64_t DBL_1PLUS = ((uint64_t)0x3FF << 52) + 18;
uint64_t mant_u = (mantHi << 4) + DBL_1PLUS;
uint64_t r1 = d2u(2.0/u2d(mant_u)) << 11; // scale = 2**64, nbits=64
// r1 is low estimate
// r1 is in range [0x7fffe000..0xfffee000 ]
// r1*x is in range [0.99595..0.999889]
// Est. Precisions: ~47.81 bits
//
// Improve precision of the estimate by canonical 1st-order NR iteration
// r = r1*(2-r1*x)
// At this point precision is of high importance, so evaluation is done in a
way
// that minimizes impact of truncation.
// The transformed equation is r = r1 + r1*(1-r1*x)
//
uint64_t mant64 = (mantHi << 16)|(mantLo >> 48); // Upper 64 bits of
mantissa, not including leading 1
uint64_t rx1= umulh64(r1,mant64) + r1 + 2; // r1*(2**64+x+1), scale =
2**64; nbits=64
// rx1 calculated with x2_u=x+1 instead of x2=x, in order to assure that
// for any possible values of 48 LS bits of x, the estimate r2 is lower than
exact values of r
uint64_t r = r1 + umulh64(0-rx1, r1);// scale = 2**64, nbits=64
// r is low estimate
// r is in range [0x7fff..0xfffd]
// r*x is in range
[0.999_999_999_999_999_999_783..0.999_999_999_999_999_999_999_957]
// Est. Precisions: ~62.00069 bits
// max(r*x-1) ~= 3.998079 * 2**-64
return r;
}
void my__divtf3(__float128* result, const __float128* num, const __float128*
den)
{
typedef unsigned __int128 __uint128;
__uint128 u_num, u_den;
memcpy(&u_num, num, sizeof(u_num));
memcpy(&u_den, den, sizeof(u_den));
const uint64_t BIT_48 = (uint64_t)1 << 48;
const uint64_t BIT_63 = (uint64_t)1 << 63;
const uint64_t SIGN_BIT = BIT_63;
const uint64_t SIGN_OFF_MSK = ~SIGN_BIT;
const uint64_t MANT_H_MSK = (uint64_t)-1 >> 16;
const uint64_t EXP_MSK = (uint64_t)0x7FFF << 48;
const uint64_t pNAN_MSW = (uint64_t)0x7FFF8 << 44;// +NaN
const uint64_t pINF_MSW = EXP_MSK;// +Inf
// const uint64_t nNAN_MSW = (uint64_t)0x8 << 44; // -NaN
// parse num and handle special cases
uint64_t numHi = (uint64_t)(u_num >> 64);
uint64_t numLo = (uint64_t)u_num;
uint64_t denHi = (uint64_t)(u_den >> 64);
uint64_t denLo = (uint64_t)u_den;
unsigned numSexp = numHi >> 48;
unsigned numExp = numSexp & 0x7FFF;
int inumExp = numExp;
uint64_t numMantHi = numHi & MANT_H_MSK;
uint64_t resSign = (numHi ^ denHi) & SIGN_BIT;
if (numExp - 1 >= 0x7FFF - 1) { // special cases
if (numExp == 0x7FFF) { // inf or Nan
if ((numMantHi | numLo)==0) { // inf
numHi = resSign | pINF_MSW; // Inf with proper sign
if ((denLo == 0) && ((denHi & SIGN_OFF_MSK)==pINF_MSW)) { // den inf
numHi = pNAN_MSW; // Inf/Inf => NaN
}
}
set__float128(result, numHi, numLo);
return;
}
// numExp == 0 - zero or sub-normal
if (((numHi & SIGN_OFF_MSK) | numLo)==0) { // zero
if ((denHi & EXP_MSK)==pINF_MSW)
[Bug sanitizer/105336] truncated address sanitizer stack traces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336 --- Comment #1 from Avi Kivity --- I guess I should mention the programs uses C++20 coroutines, and it could be the case that debug information for coroutines is generated incorrectly.
[Bug fortran/105310] ICE when UNION is after the 8th field in a DEC STRUCTURE with -finit-derived -finit-local-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105310 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Fritz Reese : https://gcc.gnu.org/g:30e6e43f0bbd84ac01cfcbfbd4b60f4495365b7d commit r9-10022-g30e6e43f0bbd84ac01cfcbfbd4b60f4495365b7d Author: Fritz Reese Date: Tue Apr 19 16:45:46 2022 -0400 fortran: Fix conv of UNION constructors [PR105310] This fixes an ICE when a UNION is the (1+8*2^n)-th field in a DEC STRUCTURE when compiled with -finit-derived -finit-local-zero. The problem was CONSTRUCTOR_APPEND_ELT from within gfc_conv_union_initializer modified the vector pointer, but the pointer was passed by-value, so the old pointer from the caller (gfc_conv_structure) pointed to freed memory. PR fortran/105310 gcc/fortran/ChangeLog: * trans-expr.c (gfc_conv_union_initializer): Pass vec* by reference. gcc/testsuite/ChangeLog: * gfortran.dg/dec_union_12.f90: New test. (cherry picked from commit c049f638da4f7b32b11e4d895184e0960bae5291)
[Bug fortran/105310] ICE when UNION is after the 8th field in a DEC STRUCTURE with -finit-derived -finit-local-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105310 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Fritz Reese : https://gcc.gnu.org/g:592a59bcee098060493ffe8847f69fb3bd22b4aa commit r10-10550-g592a59bcee098060493ffe8847f69fb3bd22b4aa Author: Fritz Reese Date: Tue Apr 19 16:45:46 2022 -0400 fortran: Fix conv of UNION constructors [PR105310] This fixes an ICE when a UNION is the (1+8*2^n)-th field in a DEC STRUCTURE when compiled with -finit-derived -finit-local-zero. The problem was CONSTRUCTOR_APPEND_ELT from within gfc_conv_union_initializer modified the vector pointer, but the pointer was passed by-value, so the old pointer from the caller (gfc_conv_structure) pointed to freed memory. PR fortran/105310 gcc/fortran/ChangeLog: * trans-expr.c (gfc_conv_union_initializer): Pass vec* by reference. gcc/testsuite/ChangeLog: * gfortran.dg/dec_union_12.f90: New test. (cherry picked from commit c049f638da4f7b32b11e4d895184e0960bae5291)
[Bug sanitizer/105336] New: truncated address sanitizer stack traces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336
Bug ID: 105336
Summary: truncated address sanitizer stack traces
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: avi at scylladb dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Trying to debug a program with gcc 11 branch
(d26c3e4f733fcb07d90680491dd1d7a9d08c4705), I get truncated asan stack traces:
seastar::internal::repeater(flush_permit&)
const::{lambda()#1}>
=
==313819==ERROR: AddressSanitizer: heap-use-after-free on address
0x6143f848 at pc 0x040627a3 bp 0x7fff62f15fb0 sp 0x7fff62f15fa8
READ of size 8 at 0x6143f848 thread T0
#0 0x40627a2 in seastar::debug_shared_ptr_counter_type::check() const
seastar/include/seastar/core/shared_ptr_debug_helper.hh:63
#1 0x505eab6 in seastar::debug_shared_ptr_counter_type::operator long()
const seastar/include/seastar/core/shared_ptr_debug_helper.hh:40
#2 0x505eab6 in seastar::lw_shared_ptr::use_count()
const seastar/include/seastar/core/shared_ptr.hh:356
#3 0x505eab6 in operator() replica/table.cc:620
#4 0x5061947 in
invoke)>&,
seastar::future > seastar/include/seastar/core/future.hh:2141
#5 0x5061947 in operator() seastar/include/seastar/core/future.hh:1658
#6 0x5061947 in call
seastar/include/seastar/util/noncopyable_function.hh:153
#7 0x45d1383 in seastar::noncopyable_function
(seastar::future&&)>::operator()(seastar::future&&) const
seastar/include/seastar/util/noncopyable_function.hh:209
#8 0x45d1383 in
seastar::future::then_wrapped_nrvo,
seastar::noncopyable_function (seastar::future&&)>
>(seastar::noncopyable_function
(seastar::future&&)>&&)::{lambda(seastar::internal::promise_base_with_type&&,
seastar::noncopyable_function
(seastar::future&&)>&,
seastar::future_state&&)#1}::operator()(seastar::internal::promise_base_with_type&&,
seastar::noncopyable_function
(seastar::future&&)>&,
seastar::future_state&&)
const::{lambda()#1}::operator()() const
seastar/include/seastar/core/future.hh:1674
#9 0x45d1383 in void seastar::futurize
>::satisfy_with_result_of::then_wrapped_nrvo,
seastar::noncopyable_function (seastar::future&&)>
>(seastar::noncopyable_function
(seastar::future&&)>&&)::{lambda(seastar::internal::promise_base_with_type&&,
seastar::noncopyable_function
(seastar::future&&)>&,
seastar::future_state&&)#1}::operator()(seastar::internal::promise_base_with_type&&,
seastar::noncopyable_function
(seastar::future&&)>&,
seastar::future_state&&)
const::{lambda()#1}>(seastar::internal::promise_base_with_type&&,
seastar::future::then_wrapped_nrvo,
seastar::noncopyable_function (seastar::future&&)>
>(seastar::noncopyable_function
(seastar::future&&)>&&)::{lambda(seastar::internal::promise_base_with_type&&,
seastar::noncopyable_function
(seastar::future&&)>&,
seastar::future_state&&)#1}::operator()(seastar::internal::promise_base_with_type&&,
seastar::noncopyable_function
(seastar::future&&)>&,
seastar::future_state&&) const::{lambda()#1}&&)
seastar/include/seastar/core/future.hh:2126
#10 0x45d2191 in
seastar::future::then_wrapped_nrvo,
seastar::noncopyable_function (seastar::future&&)>
>(seastar::noncopyable_function
(seastar::future&&)>&&)::{lambda(seastar::internal::promise_base_with_type&&,
seastar::noncopyable_function
(seastar::future&&)>&,
seastar::future_state&&)#1}::operator()(seastar::internal::promise_base_with_type&&,
seastar::noncopyable_function
(seastar::future&&)>&,
seastar::future_state&&) const
seastar/include/seastar/core/future.hh:1673
#11 0x45d2191 in
seastar::continuation,
seastar::noncopyable_function (seastar::future&&)>,
seastar::future::then_wrapped_nrvo,
seastar::noncopyable_function (seastar::future&&)>
>(seastar::noncopyable_function
(seastar::future&&)>&&)::{lambda(seastar::internal::promise_base_with_type&&,
seastar::noncopyable_function
(seastar::future&&)>&,
seastar::future_state&&)#1},
void>::run_and_dispose() seastar/include/seastar/core/future.hh:773
#12 0x17fc8b74 in
seastar::reactor::run_tasks(seastar::reactor::task_queue&)
seastar/src/core/reactor.cc:2344
#13 0x17fcd0ec in seastar::reactor::run_some_tasks()
seastar/src/core/reactor.cc:2754
#14 0x17fd2b00 in seastar::reactor::do_run()
seastar/src/core/reactor.cc:2923
#15 0x17fceba8 in seastar::reactor::run() seastar/src/core/reactor.cc:2806
#16 0x17d0a3e0 in seastar::app_template::run_deprecated(int, char**,
std::function&&) seastar/src/core/app-template.cc:265
#17 0x17d07eb0 in seastar::app_template::run(int, char**,
std::function ()>&&) seastar/src/core/app-template.cc:156
#18 0x3d67f67 in scylla_main /home/avi/scylla
[Bug other/105335] New: libiberty does not handle script exit codes correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105335 Bug ID: 105335 Summary: libiberty does not handle script exit codes correctly. Product: gcc Version: 11.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- Created attachment 52847 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52847&action=edit proposed patch A few days ago I was playing with linker plugins. I created a bug in the LTO plugin that it segfaulted when the process was about to terminate. While I was attempt to bootstrap GCC with this modified piece of code, it failed during stage1 with a mysterious message: ``` configure:3566: /d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/./gcc/xgcc -B/d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/./gcc/ -L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include -B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem /mingw64/x86_64-w64-mingw32/include -isystem /mingw64/x86_64-w64-mingw32/sys-include -fno-checking -o conftest -g -march=x86-64 -mtune=generic -O2 -pipe -pipe conftest.c >&5 C:\MSYS2\mingw64\x86_64-w64-mingw32\bin\ld.exe: cannot find -lgcc: No such file or directory C:\MSYS2\mingw64\x86_64-w64-mingw32\bin\ld.exe: cannot find -lgcc_eh: No such file or directory C:\MSYS2\mingw64\x86_64-w64-mingw32\bin\ld.exe: cannot find -lgcc: No such file or directory C:\MSYS2\mingw64\x86_64-w64-mingw32\bin\ld.exe: cannot find -lgcc_eh: No such file or directory configure:3669: error: C compiler cannot create executables ``` Later I found that it was because configure couldn't tell whether the stage1 compiler should fail, as it always returned zero, indicating success. But how? Apparently ld failed with errors, and GCC should not have exited with zero. I used GDB to dig for a while. There didn't seem anything wrong with GCC. It was collect2 that returned zero. collect2 seemed to invoke ld indirectly, so I set a breakpoint on `GetExitCodeProcess()`. This of course got the exit code of ld (I thought so, but it was wrong! see below), which was 2816, so it failed, but in liberty `pex_win32_wait()` took merely its lowest byte and consider it the exit status, which was zero, which was incorrect. Later I set a breakpoint on `CreateProcessA()` and realized the aforementioned process that exited with 2816 was actually created by `spawn_script()`, which attempted to parse the shebang of `collect-ld`, which should denote `/bin/sh`. I had a working MSYS2 shell at the moment, and it correctly detected the segfault and returned 2816 = (11 << 8), indicating the signal 11 = SIGSEGV. So far we can conclude that there is a bug in libiberty: It only takes the lowest byte as the child process's exit status. If the child (bash) fails with 2816 then it is mistaken as having exited successfully. Untested patch attached.
[Bug fortran/105310] ICE when UNION is after the 8th field in a DEC STRUCTURE with -finit-derived -finit-local-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105310 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Fritz Reese : https://gcc.gnu.org/g:15798c5d50f1318fcc0c0e7b0e71281f9a38433c commit r11-9922-g15798c5d50f1318fcc0c0e7b0e71281f9a38433c Author: Fritz Reese Date: Tue Apr 19 16:45:46 2022 -0400 fortran: Fix conv of UNION constructors [PR105310] This fixes an ICE when a UNION is the (1+8*2^n)-th field in a DEC STRUCTURE when compiled with -finit-derived -finit-local-zero. The problem was CONSTRUCTOR_APPEND_ELT from within gfc_conv_union_initializer modified the vector pointer, but the pointer was passed by-value, so the old pointer from the caller (gfc_conv_structure) pointed to freed memory. PR fortran/105310 gcc/fortran/ChangeLog: * trans-expr.c (gfc_conv_union_initializer): Pass vec* by reference. gcc/testsuite/ChangeLog: * gfortran.dg/dec_union_12.f90: New test. (cherry picked from commit c049f638da4f7b32b11e4d895184e0960bae5291)
[Bug c++/105321] [9/10/11/12 Regression] "non-constant condition" issued for function containing a short-circuited unevaluated non-constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105321 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:93b65ed9706e2ceb4be7b28c9ff9be759e68a614 commit r12-8216-g93b65ed9706e2ceb4be7b28c9ff9be759e68a614 Author: Marek Polacek Date: Wed Apr 20 16:02:52 2022 -0400 c++: wrong error with constexpr COMPOUND_EXPR [PR105321] Here we issue a bogus error for the first assert in the test. Therein we have = (void) (VIEW_CONVERT_EXPR(yes) || handle_error ());, VIEW_CONVERT_EXPR(value); which has a COMPOUND_EXPR, so we get to cxx_eval_constant_expression . The problem here is that we call 7044 /* Check that the LHS is constant and then discard it. */ 7045 cxx_eval_constant_expression (ctx, op0, 7046 true, non_constant_p, overflow_p, 7047 jump_target); where lval is always true, so the PARM_DECL 'yes' is not evaluated into its value. Fixed by always passing false for 'lval' in cxx_eval_logical_expression; there's no case where we actually expect an lvalue from a TRUTH_*. PR c++/105321 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_logical_expression): Always pass false for lval to cxx_eval_constant_expression. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-105321.C: New test.
[Bug fortran/105310] ICE when UNION is after the 8th field in a DEC STRUCTURE with -finit-derived -finit-local-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105310 --- Comment #3 from CVS Commits --- The master branch has been updated by Fritz Reese : https://gcc.gnu.org/g:c049f638da4f7b32b11e4d895184e0960bae5291 commit r12-8215-gc049f638da4f7b32b11e4d895184e0960bae5291 Author: Fritz Reese Date: Tue Apr 19 16:45:46 2022 -0400 fortran: Fix conv of UNION constructors [PR105310] This fixes an ICE when a UNION is the (1+8*2^n)-th field in a DEC STRUCTURE when compiled with -finit-derived -finit-local-zero. The problem was CONSTRUCTOR_APPEND_ELT from within gfc_conv_union_initializer modified the vector pointer, but the pointer was passed by-value, so the old pointer from the caller (gfc_conv_structure) pointed to freed memory. PR fortran/105310 gcc/fortran/ChangeLog: * trans-expr.cc (gfc_conv_union_initializer): Pass vec* by reference. gcc/testsuite/ChangeLog: * gfortran.dg/dec_union_12.f90: New test.
[Bug rtl-optimization/105333] [10/11/12 Regression] ICE: in simplify_subreg, at simplify-rtx.cc:7346 with -Og -fno-tree-coalesce-vars -fno-tree-fre since r10-1094-g9919f5fe87a3def1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105333 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 52846 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52846&action=edit gcc12-pr105333.patch Untested fix.
[Bug libstdc++/101709] [12 Regression] Yesterday's patch on std::filesystem breaks windows target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101709 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:df783ecbaaea340297df8a3bd068ce131a33 commit r11-9921-gdf783ecbaaea340297df8a3bd068ce131a33 Author: Jonathan Wakely Date: Mon Aug 2 15:52:41 2021 +0100 libstdc++: Fix filesystem::temp_directory_path [PR101709] Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101709 * src/filesystem/ops-common.h (get_temp_directory_from_env): Add error_code parameter. * src/c++17/fs_ops.cc (fs::temp_directory_path): Pass error_code argument to get_temp_directory_from_env and check it. * src/filesystem/ops.cc (fs::temp_directory_path): Likewise. (cherry picked from commit 38fb24ba4d67254cea78731fc8d961903dad9646)
[Bug c++/105297] [12 Regression] new modules 'xtreme' test cases FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105297 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Patrick Palka --- Fixed, hopefully.
[Bug c++/105297] [12 Regression] new modules 'xtreme' test cases FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105297
--- Comment #13 from Patrick Palka ---
(In reply to Jiu Fu Guo from comment #11)
> (In reply to Patrick Palka from comment #10)
> >
> > Interestingly that doesn't seem to make a difference. What seems to matter
> > is whether the constexpr function modifies the CONSTRUCTOR that it returns:
> >
> > constexpr auto foo() {
> > struct S { int d; } t = {};
> > t.d = 0; // doesn't ICE if this line is commented out
> > return t;
> > }
> >
> > template
> > int bar() {
> > constexpr auto t = foo();
> > return 0;
> > }
>
> Right, it is weird. Some PRs on Xtreme-* failure (including ICE) were also
> reported before. e.g. PR100052, PR101853, PR99910. As commented in those
> PRs, these may be random failures, and changes in headers that could expose
> the ICE.
> I'm also wondering if this may be an issue hidden inside somewhere (GC?).
In this case I suspect it's just a bug in the modules code, I opened PR105322
to track it.
[Bug target/97140] [10/11/12 Regression] ICE in error: unable to generate reloads for since r10-400-gecfdb16c54ad06ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97140 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #6 from Arseny Solokha --- In fact, it is just [10 Regression] for quite some time already.
[Bug target/105334] New: [12 Regression] ICE in curr_insn_transform, at lra-constraints.cc:4168 (error: unable to generate reloads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105334
Bug ID: 105334
Summary: [12 Regression] ICE in curr_insn_transform, at
lra-constraints.cc:4168 (error: unable to generate
reloads)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: accepts-invalid, ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: bergner at gcc dot gnu.org, linkw at gcc dot gnu.org,
segher at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc 12.0.1 20220417 snapshot (g:000c1b89d259fadb466e1f2e63c79da45fd17372) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/powerpc/pack02.c, w/ -mcpu=401:
long double
foo (void)
{
return __builtin_pack_longdouble (1.0, 1.0);
}
% powerpc-e300c3-linux-gnu-gcc-12.0.1 -mcpu=401 -c eqozx4uz.c
eqozx4uz.c: In function 'foo':
eqozx4uz.c:5:1: error: unable to generate reloads for:
5 | }
| ^
(insn 7 6 10 2 (set (reg:TF 117 [ _1 ])
(unspec:TF [
(reg:DF 119)
(reg:DF 120)
] UNSPEC_PACK_128BIT)) "eqozx4uz.c":4:10 1070 {packtf}
(expr_list:REG_DEAD (reg:DF 120)
(expr_list:REG_DEAD (reg:DF 119)
(nil
during RTL pass: reload
eqozx4uz.c:5:1: internal compiler error: in curr_insn_transform, at
lra-constraints.cc:4168
0x690c51 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/rtl-error.cc:108
0x66b2b7 curr_insn_transform
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/lra-constraints.cc:4168
0xc9a615 lra_constraints(bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/lra-constraints.cc:5203
0xc848ba lra(_IO_FILE*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/lra.cc:2375
0xc3b989 do_reload
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/ira.cc:5940
0xc3b989 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/ira.cc:6126
[Bug tree-optimization/105226] [10 Regression] ICE in gimple_split_edge with -O3/fast and setjmp (returns twice) since r10-1057-g2778a719bebf7a32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105226 Richard Biener changed: What|Removed |Added Known to work||10.3.1 Known to fail||10.3.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- Fixed.
[Bug ada/104861] s-oscons.ads should use target_noncanonical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104861 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Richard Biener --- Fixed as far as I plan backporting.
[Bug middle-end/100786] [9/10 Regression] ICE: in fold_convert_loc with alias attribute and different types and different sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100786 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:1e1b247774e0239f73b59e07f30db4e400f9b4eb commit r10-10549-g1e1b247774e0239f73b59e07f30db4e400f9b4eb Author: Richard Biener Date: Thu Jan 20 14:25:51 2022 +0100 middle-end/100786 - constant folding from incompatible alias The following avoids us ICEing doing constant folding from variables with aliases of different types. The issue appears both in folding and CCP and FRE can do more fancy stuff to still constant fold cases where the load is smaller than the initializer so defer it to there. 2022-01-20 Richard Biener PR middle-end/100786 * gimple-fold.c (get_symbol_constant_value): Only return values of compatible type to the symbol. * gcc.dg/torture/pr100786.c: New testcase. (cherry picked from commit 5c12507f5d0bc080e4f346af99824e039236e61c)
[Bug tree-optimization/103361] [9/10 Regression] ICE in adjust_unroll_factor, at gimple-loop-jam.c:407 since r12-3677-gf92901a508305f29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103361 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:4ed8728e2646897c98826cf43be2e4682d04fc2c commit r10-10548-g4ed8728e2646897c98826cf43be2e4682d04fc2c Author: Richard Biener Date: Tue Nov 23 10:11:41 2021 +0100 tree-optimization/103361 - fix unroll-and-jam direction vector handling This properly uses lambda_int instead of truncating the direction vector to int which leads to false unexpected negative values. 2021-11-23 Richard Biener PR tree-optimization/103361 * gimple-loop-jam.c (adjust_unroll_factor): Use lambda_int for the dependence distance. * tree-data-ref.c (print_lambda_vector): Properly print a lambda_int. * g++.dg/torture/pr103361.C: New testcase. (cherry picked from commit 6cd440670078af89d82cbb67e01a5ecec8eec238)
[Bug tree-optimization/103596] [9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:88 since r8-565-g7581ce9a1ad6df9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103596 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:8a7dd8900d0a183d843e9d8ec91e091dbe4fbd5b commit r10-10547-g8a7dd8900d0a183d843e9d8ec91e091dbe4fbd5b Author: Richard Biener Date: Tue Dec 7 11:13:39 2021 +0100 tree-optimization/103596 - fix missed propagation into switches may_propagate_copy unnecessarily restricts propagating non-abnormals into places that currently contain an abnormal SSA name but are not the PHI argument for an abnormal edge. This causes VN to not elide a CFG path that it assumes is elided, resulting in released SSA names in the IL. The fix is to enhance the may_propagate_copy API to specify the destination is _not_ a PHI argument. I chose to not update only the relevant caller in VN and the may_propagate_copy_into_stmt API at this point because this is a regression and needs backporting. 2021-12-07 Richard Biener PR tree-optimization/103596 * tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_stmt): Note we are not propagating into a PHI argument to may_propagate_copy. * tree-ssa-propagate.h (may_propagate_copy): Add argument specifying whether we propagate into a PHI arg. * tree-ssa-propagate.c (may_propagate_copy): Likewise. When not doing so we can replace an abnormal with something else. (may_propagate_into_stmt): Update may_propagate_copy calls. (replace_exp_1): Move propagation checking code to propagate_value and rename to ... (replace_exp): ... this and elide previous wrapper. (propagate_value): Perform checking with adjusted may_propagate_copy call and dispatch to replace_exp. * gcc.dg/torture/pr103596.c: New testcase. (cherry picked from commit 6e8a31275fda445fb3e8d98e53f5e1541f4727af)
[Bug debug/104337] [9/10 Regression] ICE when compiling with optimize attribute and always_inline at -m32 -g3 -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104337 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:f058e124350d3b19a79b3b7754b2ccab59bec7b1 commit r10-10546-gf058e124350d3b19a79b3b7754b2ccab59bec7b1 Author: Richard Biener Date: Thu Feb 3 11:20:59 2022 +0100 debug/104337 - avoid messing with the abstract origin chain in NRV The following avoids NRV from massaging DECL_ABSTRACT_ORIGIN after variable creation since NRV runs _after_ the function was inlined and thus affects the inlined variables copy indirectly. We may adjust the abstract origin of a variable only at the point we create it, not further along the path since otherwise the (new) invariant that the abstract origin is always the ultimate origin cannot be maintained. The intent of what NRV does is OK I guess and it may improve the debug experience. But I also notice we do SET_DECL_VALUE_EXPR (found, result); DECL_HAS_VALUE_EXPR_P (found) = 1; the code is there since the merge from tree-ssa which added tree-nrv.c. Jakub added the DECL_VALUE_EXPR in g:938650d8fddb878f623e315f0b7fd94b217efa96 and Jason added the abstract origin setting conditional in g:7716876bbd3a The follwoing takes the radical approach and remove the attempt to "optimize" the debug info. The gdb testsuites show no regressions. 2022-02-03 Richard Biener PR debug/104337 * tree-nrv.c (pass_nrv::execute): Remove tieing result and found together via DECL_ABSTRACT_ORIGIN. * gcc.dg/debug/pr104337.c: New testcase. (cherry picked from commit 1d5c7584fd6e72bfdbede86cef5ff04ae35f9744)
[Bug middle-end/104786] [9/10 Regression] ICE with VLA type and "=X" constraint on inline-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104786 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:e513d5641077d41ff85e6f877f8997e173886cd6 commit r10-10545-ge513d5641077d41ff85e6f877f8997e173886cd6 Author: Richard Biener Date: Wed Mar 9 10:55:49 2022 +0100 middle-end/104786 - ICE with asm and VLA The following fixes an ICE observed with a MEM_REF allows_mem asm operand referencing a VLA. The following makes sure to not attempt to go the temporary creation way when we cannot. 2022-03-09 Richard Biener PR middle-end/104786 * cfgexpand.c (expand_asm_stmt): Do not generate a copy for VLAs without an upper size bound. * gcc.dg/pr104786.c: New testcase. (cherry picked from commit ba3ff5e35144e2afff4ccef4ccaba9870afb)
[Bug ada/104861] s-oscons.ads should use target_noncanonical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104861 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:eb077526a705da3f29db47824efefdcfc0072df2 commit r10-10544-geb077526a705da3f29db47824efefdcfc0072df2 Author: Richard Biener Date: Thu Mar 10 13:35:46 2022 +0100 ada/104861 - use target_noncanonial for Target_Name The following arranges for s-oscons.ads to record target_noncanonical for Target_Name, matching the install directory layout and what gcc -dumpmachine says. This fixes build issues with gprbuild. 2022-03-10 Richard Biener PR ada/104861 gcc/ada/ * gcc-interface/Makefile.in (target_noncanonical): Substitute. (OSCONS_CPP): Pass target_noncanonical as TARGET. (cherry picked from commit 9467e7331188705ec16c086b77e1809c5b0aab7d)
[Bug tree-optimization/105226] [10 Regression] ICE in gimple_split_edge with -O3/fast and setjmp (returns twice) since r10-1057-g2778a719bebf7a32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105226 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:813b14ede7207555e65e6ce976ff0c04ab2b7875 commit r10-10543-g813b14ede7207555e65e6ce976ff0c04ab2b7875 Author: Richard Biener Date: Tue Apr 12 09:40:15 2022 +0200 tree-optimization/105226 - avoid splitting abnormal edges Vectorizer loop versioning tries to version outer loops if possible but fails to check whether it can actually split the single exit edge as it will do. 2022-04-12 Richard Biener PR tree-optimization/105226 * tree-vect-loop-manip.c (vect_loop_versioning): Verify we can split the exit of an outer loop we choose to version. * gcc.dg/pr105226.c: New testcase. (cherry picked from commit 62d5bb0f35fb6ec373eaac942755585a633528a0)
[Bug debug/105070] [9/10 Regression] Missing debug info for switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105070 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:b285999440c000685c4e4dae9c2a9a8a8fe9e176 commit r10-10542-gb285999440c000685c4e4dae9c2a9a8a8fe9e176 Author: Richard Biener Date: Mon Mar 28 10:07:53 2022 +0200 tree-optimization/105070 - annotate bit cluster tests with locations The following makes sure to annotate the tests generated by switch lowering bit-clustering with locations which otherwise can be completely lost even at -O0. 2022-03-28 Richard Biener PR tree-optimization/105070 * tree-switch-conversion.h (bit_test_cluster::hoist_edge_and_branch_if_true): Add location argument. * tree-switch-conversion.c (bit_test_cluster::hoist_edge_and_branch_if_true): Annotate cond with location. (bit_test_cluster::emit): Annotate all generated expressions with location. (cherry picked from commit bc86a86a4f2c057bc0e0be94dcbb8c128ae7f717)
[Bug libstdc++/103848] [11 Regression] std::deque<>::iterator operator- uses "0" for nullptr check, triggers "zero-as-null-pointer-constant" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103848 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Jonathan Wakely --- Fixed for 11.4
[Bug c++/105324] std::from_chars() assertion at floating_from_chars.cc:78 when parsing 1.11111111....
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105324 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for 11.4
[Bug rtl-optimization/105333] [10/11/12 Regression] ICE: in simplify_subreg, at simplify-rtx.cc:7346 with -Og -fno-tree-coalesce-vars -fno-tree-fre since r10-1094-g9919f5fe87a3def1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105333 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||ubizjak at gmail dot com Summary|[10/11/12 Regression] ICE: |[10/11/12 Regression] ICE: |in simplify_subreg, at |in simplify_subreg, at |simplify-rtx.cc:7346 with |simplify-rtx.cc:7346 with |-Og -fno-tree-coalesce-vars |-Og -fno-tree-coalesce-vars |-fno-tree-fre |-fno-tree-fre since ||r10-1094-g9919f5fe87a3def1 --- Comment #2 from Martin Liška --- Started with r10-1094-g9919f5fe87a3def1.
[Bug libstdc++/93602] [9/10 Regression] Missing reference to libiconv in 9.x libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602 Jonathan Wakely changed: What|Removed |Added Summary|[9/10/11 Regression]|[9/10 Regression] Missing |Missing reference to|reference to libiconv in |libiconv in 9.x libstdc++ |9.x libstdc++ Known to work||11.3.1, 12.0 Known to fail||10.3.0, 11.3.0 --- Comment #22 from Jonathan Wakely --- Fixed for 11.4 too.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 104966, which changed state. Bug 104966 Summary: [11/12 Regression] Yet another bogus -Warray-bounds warning in libstdc++ headers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/104966] [11/12 Regression] Yet another bogus -Warray-bounds warning in libstdc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jonathan Wakely --- Fixed for 11.4
[Bug c++/105297] [12 Regression] new modules 'xtreme' test cases FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105297 --- Comment #12 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:1e6c0e69af8da436e1d1d2d23d8c38410d78ecf2 commit r12-8214-g1e6c0e69af8da436e1d1d2d23d8c38410d78ecf2 Author: Patrick Palka Date: Thu Apr 21 08:34:59 2022 -0400 libstdc++: Work around modules ICE in [PR105297] This makes the initializer for __table in __from_chars_alnum_to_val dependent in an artificial way, which works around the reported modules testsuite ICE by preventing the compiler from evaluating the initializer parse time. Compared to the alternative workaround of using a non-local class type for __table, this workaround has the advantage of slightly speeding up compilation of , since now the table won't get built (via constexpr evaluation) until the integer std::from_chars overload is instantiated. PR c++/105297 PR c++/105322 libstdc++-v3/ChangeLog: * include/std/charconv (__from_chars_alnum_to_val): Make initializer for __table dependent in an artificial way.
[Bug c++/105322] [modules] ICE with constexpr object of local class type from another function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105322 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:1e6c0e69af8da436e1d1d2d23d8c38410d78ecf2 commit r12-8214-g1e6c0e69af8da436e1d1d2d23d8c38410d78ecf2 Author: Patrick Palka Date: Thu Apr 21 08:34:59 2022 -0400 libstdc++: Work around modules ICE in [PR105297] This makes the initializer for __table in __from_chars_alnum_to_val dependent in an artificial way, which works around the reported modules testsuite ICE by preventing the compiler from evaluating the initializer parse time. Compared to the alternative workaround of using a non-local class type for __table, this workaround has the advantage of slightly speeding up compilation of , since now the table won't get built (via constexpr evaluation) until the integer std::from_chars overload is instantiated. PR c++/105297 PR c++/105322 libstdc++-v3/ChangeLog: * include/std/charconv (__from_chars_alnum_to_val): Make initializer for __table dependent in an artificial way.
[Bug c++/105324] std::from_chars() assertion at floating_from_chars.cc:78 when parsing 1.11111111....
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105324 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d26c3e4f733fcb07d90680491dd1d7a9d08c4705 commit r11-9920-gd26c3e4f733fcb07d90680491dd1d7a9d08c4705 Author: Jonathan Wakely Date: Thu Apr 21 11:26:49 2022 +0100 libstdc++: Remove bogus assertion in std::from_chars [PR105324] I'm not sure what I was thinking when I added this assertion, maybe it was supposed to be alignment == 1 (which is what the pmr::string actually uses). The simplest fix is to just remove the assertion. The assertion is no longer enabled by default on trunk, but it's still there for the --enablke-libstdcxx-debug build, and is still wrong. The fix is needed on the gcc-11 branch. libstdc++-v3/ChangeLog: PR libstdc++/105324 * src/c++17/floating_from_chars.cc (buffer_resource::do_allocate): Remove assertion. * testsuite/20_util/from_chars/pr105324.cc: New test. (cherry picked from commit cf37107522f465d9e12af01ba68d2d1df0f18d46)
