[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #8 from nightstrike --- (In reply to Andrew Pinski from comment #1) > This one looks like a mising '()': > ../../../gcc/gcc/ira-conflicts.cc:153:25: warning: format '%ld' expects > argument of type 'long int', but argument 3 has type 'long long unsigned > int' [-Wformat=] > 153 |"+++Allocating %ld bytes for conflict table (uncompressed > size %ld)\n", > | ~~^ > | | > | long int > | %lld > 154 |(long) allocated_words_num * sizeof (IRA_INT_TYPE), > |~~ > | | > | long long unsigned int > > Maybe it should have been `(long) (allocated_words_num * sizeof > (IRA_INT_TYPE))` > Likewise for the next one: > > 155 |(long) object_set_words * ira_objects_num * sizeof > (IRA_INT_TYPE)); > > Should have been `(long)(object_set_words * ira_objects_num * sizeof > (IRA_INT_TYPE))` This part should be fixed now after PR43613 and r14-8898-g2bb4556220285e.
[Bug target/113978] Misoptimize for long vector load operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113978
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #1)
> This is an ABI issue. I am not sure if GCC is correct or LLVM is correct.
The psABI doesn't cover that. It only talks about __m128, __m256 and __m512
types, and
as both compilers use the GNU vector_size attribute extension under the hood
for those types, that is how __attribute__((vector_size ({16,32,64}))) should
behave.
Smaller vectors (vector_size 2, 4, 8) on x86_64 are in GCC passed like __m128
(I think), larger vectors or even __m256/__m512 if AVX/AVX512 isn't supported
are classified as MEMORY like > 16 byte structures/unions.
> But basically clang/LLVM is returning in %zmm0 and %zmm1 while GCC is
> returning via memory.
There is certainly not anything in the psABI that would return something in
%zmm0/%zmm1 pair I believe.
[Bug target/43613] Some architecture-dependent codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613 --- Comment #10 from nightstrike --- Patch thread started here: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644674.html https://inbox.sourceware.org/gcc-patches/4700e066-1b50-4e7b-92f7-d8c33a330...@gmail.com/ and ended with this solution: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644701.html https://inbox.sourceware.org/gcc-patches/Zbu34FTR73081bMb@tucnak/ which was committed in r14-8898-g2bb4556220285e. I believe based on comment 7, this can now be closed.
[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976 Sam James changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-18 Ever confirmed|0 |1
[Bug target/113978] Misoptimize for long vector load operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113978 --- Comment #6 from 严 逍宇 --- (In reply to Andrew Pinski from comment #5) > As I mentioned, that works on linux just fine: Thank you for your time. And when can I use this feature on mingw? I think the behavior of swap two long vectors should be platform-independent.
[Bug target/113978] Misoptimize for long vector load operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113978 --- Comment #5 from Andrew Pinski --- (In reply to 严 逍宇 from comment #4) > I find an example without abi problem: As I mentioned, that works on linux just fine: ``` vmovdqa64 (%rdi), %zmm1 vmovdqa64 64(%rdi), %zmm0 vmovdqa64 (%rsi), %zmm3 vmovdqa64 64(%rsi), %zmm2 vmovdqa64 %zmm3, (%rdi) vmovdqa64 %zmm2, 64(%rdi) vmovdqa64 %zmm1, (%rsi) vmovdqa64 %zmm0, 64(%rsi) vzeroupper ret ```
[Bug target/113978] Misoptimize for long vector load operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113978
--- Comment #4 from 严 逍宇 ---
I find an example without abi problem:
===
Source Code
===
using v [[using gnu: vector_size(128)]] = char;
void f(v *pa, v *pb) noexcept
{
v a{*pa}, b{*pb};
*pa = b;
*pb = a;
}
===
Command
===
g++ test.cpp -Ofast -march=znver4 -S
===
Result
===
_Z1fPDv128_cS0_:
.LFB0:
subq$376, %rsp
.seh_stackalloc 376
.seh_endprologue
vmovdqa64 (%rcx), %zmm1
vmovdqa64 64(%rcx), %zmm0
leaq127(%rsp), %rax
andq$-128, %rax
vmovdqa64 (%rdx), %zmm3
vmovdqa64 64(%rdx), %zmm2
vmovdqa64 %zmm1, 128(%rax)
vmovdqa64 %zmm0, 192(%rax)
vmovdqa64 %zmm3, (%rcx)
vmovdqa64 %zmm2, 64(%rcx)
vmovdqa64 %zmm3, (%rax)
vmovdqa64 %zmm2, 64(%rax)
vmovdqa64 %zmm1, (%rdx)
vmovdqa64 %zmm0, 64(%rdx)
vzeroupper
addq$376, %rsp
ret
But clang can do this right:
_Z1fPDv128_cS0_:# @_Z1fPDv128_cS0_
# %bb.0:
vmovaps (%rcx), %zmm0
vmovaps 64(%rcx), %zmm1
vmovaps (%rdx), %zmm2
vmovaps 64(%rdx), %zmm3
vmovaps %zmm2, (%rcx)
vmovaps %zmm3, 64(%rcx)
vmovaps %zmm0, (%rdx)
vmovaps %zmm1, 64(%rdx)
vzeroupper
retq
[Bug target/113978] Misoptimize for long vector load operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113978 --- Comment #3 from Andrew Pinski --- >GCC generates extra stack operation That is basically to realign the stack just in case there was a spill, this happens more on mingw compiling than linux really.
[Bug target/113978] Misoptimize for long vector load operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113978 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv ||m-project/issues/82151 --- Comment #2 from Andrew Pinski --- Filed https://github.com/llvm/llvm-project/issues/82151 for the corresponding LLVM issue for ABI compatibility.
[Bug target/113978] Misoptimize for long vector load operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113978 Andrew Pinski changed: What|Removed |Added Keywords||ABI Component|c++ |target Target||x86_64-linux-gnu --- Comment #1 from Andrew Pinski --- This is an ABI issue. I am not sure if GCC is correct or LLVM is correct. But basically clang/LLVM is returning in %zmm0 and %zmm1 while GCC is returning via memory.
[Bug c++/113978] New: Misoptimize for long vector load operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113978
Bug ID: 113978
Summary: Misoptimize for long vector load operation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xjkp2283572185 at gmail dot com
Target Milestone: ---
===
Compiler
===
Using built-in specs.
COLLECT_GCC=D:\Tools\gcc\bin\g++.exe
COLLECT_LTO_WRAPPER=D:/Tools/gcc/bin/../libexec/gcc/x86_64-w64-mingw32/14.0.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../configure --disable-werror
--prefix=/home/luo/x86_64-w64-mingw32-native-gcc14 --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --enable-multilib --enable-languages=c,c++
--disable-sjlj-exceptions --enable-threads=win32
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240130 (experimental) (GCC)
===
Source Code
===
using v [[using gnu: vector_size(128)]] = char;
auto f(v* p) noexcept
{
return *p;
}
===
Command
===
g++ test.cpp -Ofast -march=znver4
===
Result
===
_Z1fPDv128_c:
.LFB0:
subq$248, %rsp
.seh_stackalloc 248
.seh_endprologue
vmovdqa64 (%rdx), %zmm0
movq%rcx, %rax
vmovdqa64 %zmm0, (%rcx)
vmovdqa64 64(%rdx), %zmm0
vmovdqa64 %zmm0, 64(%rcx)
vzeroupper
addq$248, %rsp
ret
GCC generates extra stack operation. But clang just generates two load:
_Z1fPDv128_c: # @_Z1fPDv128_c
# %bb.0:
vmovaps (%rcx), %zmm0
vmovaps 64(%rcx), %zmm1
retq
[Bug tree-optimization/109885] gcc does not generate movmskps and testps instructions (clang does)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109885
--- Comment #4 from Hongtao Liu ---
int sum() {
int ret = 0;
for (int i=0; i<8; ++i) ret +=(0==v[i]);
return ret;
}
int sum2() {
int ret = 0;
auto m = v==0;
for (int i=0; i<8; ++i) ret += m[i];
return ret;
}
For sum, gcc tries to reduce for an {0/1, 0/1, ...} vector, for sum2, it tries
to reduce {0/-1,0/-1,...} vector. But LLVM tries to reduce {0/1, 0/1, ... }
vector for both sum and sum2. Not sure which is correct?
[Bug libcc1/113977] debug info for alignment of structure is unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977 --- Comment #8 from Andrew Pinski --- >(which is likely inherited from the default structure alignment requirement on >the platform) That is wrong assumption really. Since the ABI (the platform) says the alignment is type depedent and in this case the types are arrays of 7,8,9 in size of type char which definition has an alignment of 1 for the ABI. Anyways this is definitely a gdb bug in "mis"understanding the ABI.
[Bug libcc1/113977] debug info for alignment of structure is unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=31397 --- Comment #7 from Andrew Pinski --- Moved to https://sourceware.org/bugzilla/show_bug.cgi?id=31397 since this is almost definitely a bug in gdb's gcc_convert_symbol or gdb's understanding of the struct.
[Bug libcc1/113977] debug info for alignment of structure is unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977 --- Comment #6 from Andrew Pinski --- trunk gdb fails too.
[Bug libcc1/113977] debug info for alignment of structure is unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977 --- Comment #5 from Andrew Pinski --- (In reply to Tan Senqi from comment #4) > (In reply to Andrew Pinski from comment #3) > I think gcc can generate a DW_AT_alignment for my struct to solve this > problem. But why the alignment is considered as 8, I am not sure about this. > If it is inherited from the default structure alignment requirement on the > platform, then gcc should specify alignment for those whose alignment is not > 8. Or 8 is not the default value by DWARF5(i.e. undefined), then it is > surely a bug in gdb. So reading the definition of DW_AT_alignment, it is if the alignment is not the default for that type. In this case it should be 1 as char arrays have alignment of 1 inside structs. See https://dwarfstd.org/issues/140528.1.html for the definition. in this case the ABI specifies the alignment and GCC does not need to emit DW_AT_alignment since it is not different from the ABI. This would mean the bug is in gdb's gcc_convert_symbol, eg.: ``` gcc_convert_symbol "z": local symbol gdb command line:1:1: error: size of array element is not a multiple of its alignment ``` I am testing the trunk gdb right now to see if it was fixed.
[Bug libcc1/113977] debug info for alignment of structure is unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977 --- Comment #4 from Tan Senqi --- (In reply to Andrew Pinski from comment #3) > For me with the trunk GCC we get: > ``` > (gdb) expr z[0]._[0] = 1 > gdb command line:1:1: error: size of array element is not a multiple of its > alignment > Compilation failed. > (gdb) expr y[0]._[0] = 1 > (gdb) expr x[0]._[0] = 1 > gdb command line:1:1: error: alignment of array elements is greater than > element size > Compilation failed. > > ``` > > I am starting to think this is a gdb issue ... I think gcc can generate a DW_AT_alignment for my struct to solve this problem. But why the alignment is considered as 8, I am not sure about this. If it is inherited from the default structure alignment requirement on the platform, then gcc should specify alignment for those whose alignment is not 8. Or 8 is not the default value by DWARF5(i.e. undefined), then it is surely a bug in gdb.
[Bug libcc1/113977] debug info for alignment of structure is unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977 --- Comment #3 from Andrew Pinski --- For me with the trunk GCC we get: ``` (gdb) expr z[0]._[0] = 1 gdb command line:1:1: error: size of array element is not a multiple of its alignment Compilation failed. (gdb) expr y[0]._[0] = 1 (gdb) expr x[0]._[0] = 1 gdb command line:1:1: error: alignment of array elements is greater than element size Compilation failed. ``` I am starting to think this is a gdb issue ...
[Bug libcc1/113977] debug info for alignment of structure is unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977 Andrew Pinski changed: What|Removed |Added Component|debug |libcc1 --- Comment #2 from Andrew Pinski --- Or is it is a bug in libcc1.
[Bug debug/113977] debug info for alignment of structure is unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977 --- Comment #1 from Andrew Pinski --- This seems like a bug in gdb really. GCC produces: ``` .uleb128 0x3# (DIE (0x2e) DW_TAG_structure_type) .ascii "s7\0" # DW_AT_name .byte 0x7 # DW_AT_byte_size # DW_AT_decl_file (1, /app/example.cpp) .byte 0x1 # DW_AT_decl_line # DW_AT_decl_column (0x8) .long 0x41 # DW_AT_sibling .uleb128 0x4# (DIE (0x38) DW_TAG_member) .ascii "_\0"# DW_AT_name # DW_AT_decl_file (1, /app/example.cpp) .byte 0x1 # DW_AT_decl_line # DW_AT_decl_column (0x12) .long 0x41 # DW_AT_type # DW_AT_data_member_location (0) .byte 0 # end of children of DIE 0x2e .uleb128 0x2# (DIE (0x41) DW_TAG_array_type) .long 0x58 # DW_AT_type .long 0x51 # DW_AT_sibling ``` ``` .ascii "x\0"# DW_AT_name # DW_AT_decl_file (1, /app/example.cpp) .byte 0x7 # DW_AT_decl_line # DW_AT_decl_column (0xd) .long 0xf1 # DW_AT_type .uleb128 0x2# DW_AT_location .byte 0x91 # DW_OP_fbreg .sleb128 -30 ``` ``` .uleb128 0x2# (DIE (0xf1) DW_TAG_array_type) .long 0x2e # DW_AT_type .long 0x101 # DW_AT_sibling .uleb128 0x1# (DIE (0xfa) DW_TAG_subrange_type) .long 0x51 # DW_AT_type .byte 0x1 # DW_AT_upper_bound .byte 0 # end of children of DIE 0xf1 ```
[Bug testsuite/108192] g++.dg/cet-notrack-1.C searching for wrong function on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192 jyong at gcc dot gnu.org changed: What|Removed |Added CC||jyong at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from jyong at gcc dot gnu.org --- Changed to use __mingw_*printf.
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #57 from Hongtao Liu --- > For dg-do run testcases I really think we should avoid those -march= > options, because it means a lot of other stuff, BMI, LZCNT, ... Make sense.
[Bug debug/113977] New: debug info for alignment of structure is unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977 Bug ID: 113977 Summary: debug info for alignment of structure is unspecified Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: tsqurt at outlook dot com Target Milestone: --- Created attachment 57454 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57454&action=edit src.c GCC does not generate complete debug information for my C code when generating debug information. The alignment requirement for my structures is 1, but the debugger believes their alignment requirement is 8 (which is likely inherited from the default structure alignment requirement on the platform). I'm using the AMD64 instruction set, and the operating system is Ubuntu 20.04.6 LTS on Windows Subsystem for Linux. To reproduce this issue, follow these steps with the attached code: gcc src.c -gdwarf-5 -o a.out && gdb a.out (gdb) b 13 Breakpoint 1 at 0x1170: file src.c, line 13. (gdb) run Starting program: a.out Breakpoint 1, main () at src.c:13 13return 0; (gdb) expr z[0]._[0] = 1 (gdb) expr y[0]._[0] = 1 (gdb) expr x[0]._[0] = 1 gdb command line:1:1: error: alignment of array elements is greater than element size Compilation failed. (gdb) GDB reports that the alignment requirement for these structures is 8, but it is 1.
[Bug modula2/113889] Incorrect constant string value if declared in a definition module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113889 --- Comment #2 from Gaius Mulley --- Created attachment 57453 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57453&action=edit Proposed fix Here is a proposed patch and associated testcases.
[Bug middle-end/113974] Attribute common ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113974 --- Comment #2 from Andrew Pinski --- Note clang since 4.0 has the same behavior as GCC here ...
[Bug target/113971] [14 Regression] failure to build on arm64 musl (#error "Unsupported AArch64 platform for heap trampolines")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971
--- Comment #1 from Iain Sandoe ---
the intent was not to enable this feature for platforms we could not test.
but libgcc/config.host has "aarch64*-*-linux*" so we have inadvertently enabled
it for aarch64-linux-musl.
assuming linux-musl defines __linux__ ... something like:
diff --git a/libgcc/config/aarch64/heap-trampoline.c
b/libgcc/config/aarch64/heap-trampoline.c
index 9d5b19983b1..1e3460b1601 100644
--- a/libgcc/config/aarch64/heap-trampoline.c
+++ b/libgcc/config/aarch64/heap-trampoline.c
@@ -29,7 +29,7 @@ void *allocate_trampoline_page (void);
void __gcc_nested_func_ptr_created (void *chain, void *func, void *dst);
void __gcc_nested_func_ptr_deleted (void);
-#if defined(__gnu_linux__)
+#if defined(__linux__)
static const uint32_t aarch64_trampoline_insns[] = {
0xd503245f, /* hint34 */
0x58b1, /* ldr x17, .+20 */
@@ -82,7 +82,7 @@ allocate_trampoline_page (void)
{
void *page;
-#if defined(__gnu_linux__)
+#if defined(__linux__)
page = mmap (0, getpagesize (), PROT_WRITE | PROT_EXEC,
MAP_ANON | MAP_PRIVATE, 0, 0);
#elif __APPLE__
[Bug middle-end/113974] Attribute common ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113974 Andrew Pinski changed: What|Removed |Added Component|other |middle-end --- Comment #1 from Andrew Pinski --- I am not totally sure it matters if it is in .bss or .lcomm really. In the case with -fdata-sections, cc is put in .bss.cc section which is the named section after the name of the variable. Since it is a local variable, the "common" part is really ignored and still put in bss but via the assembler.
[Bug ada/113862] error: "others" choice not allowed here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113862 --- Comment #3 from Eric Botcazou --- Well, this is very irregular if it happens to be legal, since it would be illegal if the raise was replaced by anything else. More of a bug in the language than in the compiler if you ask me...
[Bug target/113971] [14 Regression] failure to build on arm64 musl (#error "Unsupported AArch64 platform for heap trampolines")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971 Andrew Pinski changed: What|Removed |Added Keywords||build Summary|failure to build on arm64 |[14 Regression] failure to |musl (#error "Unsupported |build on arm64 musl (#error |AArch64 platform for heap |"Unsupported AArch64 |trampolines") |platform for heap ||trampolines") Target Milestone|--- |14.0 Target||aarch64-linux-musl
[Bug c++/113970] [14 Regression] pch/system-{1,2}.C fails on darwin after r14-8987-gdd9d14f7d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- If I read this correctly, it is the debug info that is different rather than the code itself being different?
[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976 Andrew Pinski changed: What|Removed |Added Summary|explicit instantiation of |[11/12/13/14 Regression] |const variable template |explicit instantiation of |following implicit |const variable template |instantiation is assembled |following implicit |in .rodata instead of .bss |instantiation is assembled ||in .rodata instead of .bss Target Milestone|--- |11.5 Known to work||5.1.0, 6.1.0, 7.1.0, 7.5.0 Keywords||needs-bisection Known to fail||10.1.0, 8.1.0, 9.1.0 --- Comment #1 from Andrew Pinski --- Confirmed. Worked in GCC 7.x series and before.
[Bug c++/113976] New: explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976
Bug ID: 113976
Summary: explicit instantiation of const variable template
following implicit instantiation is assembled in
.rodata instead of .bss
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tamiko at gentoo dot org
Target Milestone: ---
The following snippet of code:
inline int mpi_type_id(const unsigned long int *) { return 42; }
/* same for inline, static, extern */
template
const int mpi_type_id_for_type = mpi_type_id(static_cast(nullptr));
/* implicit instantiation */
void broadcast() {
int ierr = mpi_type_id_for_type;
}
/* explicit instantiation */
template const int mpi_type_id_for_type;
int main() {}
leads to a segfault:
% g++ segfault.cc -o segfault
% ./segfault
segmentation fault (core dumped) ./segfault
The segfault happens because the int mpi_type_id_for_type gets
assembled into the .rodata section:
% objdump -xd segfault | grep mpi_type | c++filt
2004 u O .rodata 0004
mpi_type_id_for_type
4018 u O .bss0008 guard variable for
mpi_type_id_for_type
and consequently the static initialization segfaults when trying to write into
the read only data section:
114a <_Z41__static_initialization_and_destruction_0v>:
1167: c6 00 01movb $0x1,(%rax)
116a: bf 00 00 00 00 mov$0x0,%edi
116f: e8 18 00 00 00 call 118c <_Z11mpi_type_idPKm>
1174: 89 05 8a 0e 00 00 mov%eax,0xe8a(%rip)# 2004
<_Z20mpi_type_id_for_typeImE>
Note that *any* other combination of
- only broadcast() function definition
- only explicit template instantiation
- explicit template instantiation *before* broadcast() function definition
assembles mpi_type_id_for_type correctly into the .bss section
Furthermore, linkage (inline, static, extern) of mpi_type_id_for_type also
doesn't seem to matter.
Reproduced with gcc-13.2.1, gcc-12.3.1, gcc-11.4.1 on gentoo and gcc-13.2.0 on
debian.
(gentoo) % gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/13/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/13
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/13/python
--enable-objc-gc --enable-languages=c,c++,go,objc,obj-c++,fortran
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --disable-libunwind-exceptions
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 13.2.1_p20240210 p13'
--with-gcc-major-version-only --enable-libstdcxx-time --enable-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --enable-cet
--disable-systemtap --disable-valgrind-annotations --enable-vtable-verify
--with-zstd --with-isl --disable-isl-version-check --enable-default-pie
--enable-default-ssp --with-build-config=bootstrap-cet
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20240210 (Gentoo Hardened 13.2.1_p20240210 p13)
(debian) % gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 13.2.0-13'
--with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --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-libstdcxx-backtrace --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --enable-defa
[Bug libfortran/113897] Consecutive tab edits in format are not processed correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113897 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #1) > Adding to my list, but I do not see any priority needed for it. I've just reopened pr109358, as it is not only tabs, but also nX. > Even though it is nonsensical to do this, Format strings could be machine generated, like other program text. Some of the changes (like line-length, statement length) of F2023 seem to be made to support such stuff, so let's expect the worst...
[Bug fortran/113892] Missing temporary in assignment for array-valued function referencing host-associated array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113892 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-02-17 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- Note that in F2023 we could use the new attribute SIMPLE to control which optimizations could be done in an assignment. Here the referenced functions are only PURE.
[Bug fortran/113975] function returning array is not fully evaluated before assignement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113975 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. See also PR113892. *** This bug has been marked as a duplicate of bug 113892 ***
[Bug fortran/113892] Missing temporary in assignment for array-valued function referencing host-associated array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113892 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||comptes at ugo235 dot fr --- Comment #1 from anlauf at gcc dot gnu.org --- *** Bug 113975 has been marked as a duplicate of this bug. ***
[Bug fortran/113911] [14 Regression] Length is lost passing deferred-length character to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed.
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #15 from anlauf at gcc dot gnu.org --- Jerry, I tend to think the fix does not cover loopholes like multiple tabbing or nX without printing anything in between. Consider the enhanced test: program tabs implicit none integer :: fd open(newunit=fd, file="test-stream.txt", form="formatted", access="stream") write(fd, "(a)") "12345678901234567890123456789" write(fd, "(i4, t25, t2, i4.4)") 1234, 0123 ! wrong write(fd, "(i4, t25, 1x, t2, i4.4)") 1234, 0123 ! wrong write(fd, "(i4, t21, a, t2, i4.4)") 1234, "good", 0123 ! OK write(fd, "(i4, t40, i4, t20, i5.5)") 1234, , 67890 ! OK close(fd) open(newunit=fd, file="test.txt", form="formatted") write(fd, "(a)") "12345678901234567890123456789" write(fd, "(i4, t25, t2, i4.4)") 1234, 0123 ! wrong write(fd, "(i4, t25, 1x, t2, i4.4)") 1234, 0123 ! wrong write(fd, "(i4, t21, a, t2, i4.4)") 1234, "good", 0123 ! OK write(fd, "(i4, t40, i4, t20, i5.5)") 1234, , 67890 ! OK close(fd) end program tabs Expected: ==> test-stream.txt <== 12345678901234567890123456789 10123 10123 10123 good 1234 67890 ==> test.txt <== 12345678901234567890123456789 10123 10123 10123 good 1234 67890 With gcc-13/gcc-14 after your patch I get: ==> test-stream.txt <== 12345678901234567890123456789 12340123 1234 0123 10123 good 1234 67890 ==> test.txt <== 12345678901234567890123456789 12340123 1234 0123 10123 good 1234 67890 Can you have a further look?
[Bug c++/113970] [14 Regression] pch/system-{1,2}.C fails on darwin after r14-8987-gdd9d14f7d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
Iain Sandoe changed:
What|Removed |Added
Component|pch |c++
CC||nshead at gcc dot gnu.org
Summary|[14 Regression] |[14 Regression]
|pch/system-{1,2}.C fails on |pch/system-{1,2}.C fails on
|darwin |darwin after
||r14-8987-gdd9d14f7d53
Keywords|needs-bisection |
Target Milestone|--- |14.0
--- Comment #1 from Iain Sandoe ---
Bisected to r14-8987-gdd9d14f7d53; reverting that commit on current trunk
(r14-9043) also clears the issue.
[Bug fortran/113975] New: function returning array is not fully evaluated before assignement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113975 Bug ID: 113975 Summary: function returning array is not fully evaluated before assignement Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: comptes at ugo235 dot fr Target Milestone: --- The following code is poorly designed, yet I think it is standard-conforming: == module foo implicit none integer, parameter :: n=3 integer :: a(n,n) contains pure function bar() integer :: bar(n,n) bar = transpose(a) end function bar end module foo program main use foo implicit none integer :: i a = reshape([ 11, 12, 13 & , 21, 22, 23 & , 31, 32, 33 ], shape=[n,n], order=[2,1] ) a = bar() do i = 1, n print*, a(i,:) end do end program main == In `a = bar()`, `bar()` should be fully evaluated before the result is assigned to `a`, and it seems this is not the case. Consequently, the output of the program compiled with gfortran 13.2 (without any option) is not the transpose of the matrix that is entered in the code: == Program returned: 0 Program stdout 11 12 13 12 22 23 13 23 33 ==
[Bug c++/113966] [14 Regression] Internal compiler error in `do_auto_deduction`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113966
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
--- Comment #7 from Patrick Palka ---
template concept C = T::value;
template
struct A {
template requires requires { { T() } -> C; }
friend void f(A) { }
};
template struct A;
We probably don't want to do do_auto_deduction at all during partial
substitution, since that could cause requirements to get checked out of order.
[Bug libfortran/83282] missing comma in format changes output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282 --- Comment #6 from Jerry DeLisle --- $ gfc -Wall -Werror -pedantic pr83282.f90 pr83282.f90:1:4: 1 |write(*,'(aa)') "ab", "bc" |1 Error: Unclassifiable statement at (1) This is not very useful either. :o
[Bug libfortran/83282] missing comma in format changes output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282 --- Comment #5 from Jerry DeLisle --- With -std=f95 we get: $ gfc -std=f95 pr83282.f90 pr83282.f90:1:13: 1 |write(*,'(aa)') "ab", "bc" | 1 Error: GNU Extension: Missing comma at (1) pr83282.f90:2:17: 2 |write(*,'(a"bc")') "ab" | 1 Error: GNU Extension: Missing comma at (1) pr83282.f90:3:17: 3 |write(*,'(a"cd"a)') "ab", "bc" | 1 Error: GNU Extension: Missing comma at (1) and -pedantic gives: $ gfc -pedantic pr83282.f90 pr83282.f90:1:13: 1 |write(*,'(aa)') "ab", "bc" | 1 Warning: GNU Extension: Missing comma at (1) pr83282.f90:2:17: 2 |write(*,'(a"bc")') "ab" | 1 Warning: GNU Extension: Missing comma at (1) pr83282.f90:3:17: 3 |write(*,'(a"cd"a)') "ab", "bc" | 1 Warning: GNU Extension: Missing comma at (1) I wonder if we should reject the missing comma outright and only allow it for -std=legacy?
[Bug ada/113862] error: "others" choice not allowed here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113862 --- Comment #2 from Pascal Pignard --- Nevertheless, theses examples of code come from AARM Ada 2022: 11.3 Raise Statements and Raise Expressions ... All of the following are legal, no additional parens are needed: 2.a.10/4Pre : Boolean := (if not Is_Valid(Param) then raise Not_Valid_Error); A : A_Tagged := (Some_Tagged'(raise TBD_Error) with Comp => 'A'); B : Some_Array := (1, 2, 3, others => raise Not_Valid_Error); C : Natural:= Func (Val => raise TBD_Error);
[Bug c++/113966] [14 Regression] Internal compiler error in `do_auto_deduction`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113966 --- Comment #6 from Andrew Pinski --- Created attachment 57452 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57452&action=edit semi reduced testcase Reduced somewhat. There is some more to go but I will leave that for someone else. Some concepts can be removed still but it looks like that has to be done manually.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #27 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:a71d87431d0c4e04a402ef6566be090c470b2b53 commit r14-9050-ga71d87431d0c4e04a402ef6566be090c470b2b53 Author: Jerry DeLisle Date: Sat Feb 17 09:24:58 2024 -0800 libgfortran: [PR105473] Fix checks for decimal='comma'. PR libfortran/105473 libgfortran/ChangeLog: * io/list_read.c (eat_separator): Reject comma as a seprator when it is being used as a decimal point. (parse_real): Reject a '.' when is should be a comma. (read_real): Likewise. * io/read.c (read_f): Add more checks for ',' and '.' conditions. gcc/testsuite/ChangeLog: * gfortran.dg/pr105473.f90: New test.
[Bug other/113336] [14 Regression] libatomic (testsuite) regressions on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113336 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Roger Sayle --- This should now be fixed on mainline.
[Bug c++/113969] ICE: SIGSEGV in finish_enum_value_list (decl.cc:17143) (or build_enumerator (decl.cc:17438) ) on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113969 Marek Polacek changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=95935 --- Comment #3 from Marek Polacek --- Bug 95935 is also related; see my #c3 there.
[Bug fortran/113503] [14 Regression] xtb test miscompilation starting with r14-870
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113503 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug other/113974] New: Attribute common ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113974 Bug ID: 113974 Summary: Attribute common ignored Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- __attribute__((common,used)) static int cc; when this code is compiled with -S -fdata-sections then cc is not put into .lcomm (and is not .local .comm either): .section.bss.cc,"aw",@nobits .align 4 .type cc, @object .size cc, 4 cc: .zero 4 .ident "GCC: (GNU) 13.2.1 20231022" with -fno-data-sections, though, it works as expected: .local cc .comm cc,4,4
[Bug fortran/113503] [14 Regression] xtb test miscompilation starting with r14-870
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113503
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:296284a9dbb7df4485cc5f1d3e975fdb4b8a10b8
commit r14-9049-g296284a9dbb7df4485cc5f1d3e975fdb4b8a10b8
Author: Jakub Jelinek
Date: Sat Feb 17 16:54:08 2024 +0100
fortran: gfc_trans_subcomponent_assign fixes [PR113503]
The r14-870 changes broke xtb package tests (reduced testcase is the first
one below) and caused ICEs on a test derived from that (the second one).
For the
x = T(u = trim (us(1)))
statement, before that change gfortran used to emit weird code with
2 trim calls:
_gfortran_string_trim (&len.2, (void * *) &pstr.1, 20, &us[0]);
if (len.2 > 0)
{
__builtin_free ((void *) pstr.1);
}
D.4275 = len.2;
t.0.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR
<(sizetype) D.4275, 1>);
t.0._u_length = D.4275;
_gfortran_string_trim (&len.4, (void * *) &pstr.3, 20, &us[0]);
(void) __builtin_memcpy ((void *) t.0.u, (void *) pstr.3, (unsigned
long) NON_LVALUE_EXPR );
if (len.4 > 0)
{
__builtin_free ((void *) pstr.3);
}
That worked at runtime, though it is wasteful.
That commit changed it to:
slen.3 = len.2;
t.0.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR
<(sizetype) slen.3, 1>);
t.0._u_length = slen.3;
_gfortran_string_trim (&len.2, (void * *) &pstr.1, 20, &us[0]);
(void) __builtin_memcpy ((void *) t.0.u, (void *) pstr.1, (unsigned
long) NON_LVALUE_EXPR );
if (len.2 > 0)
{
__builtin_free ((void *) pstr.1);
}
which results in -Wuninitialized warning later on and if one is unlucky and
the uninitialized len.2 variable is smaller than the trimmed length, it
results in heap overflow and often crashes later on.
The bug above is clear, len.2 is only initialized in the
_gfortran_string_trim (&len.2, (void * *) &pstr.1, 20, &us[0]);
call, but used before that. Now, the
slen.3 = len.2;
t.0.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR
<(sizetype) slen.3, 1>);
t.0._u_length = slen.3;
statements come from the alloc_scalar_allocatable_subcomponent call,
while
_gfortran_string_trim (&len.2, (void * *) &pstr.1, 20, &us[0]);
from the gfc_conv_expr (&se, expr); call which is done before the
alloc_scalar_allocatable_subcomponent call, but is only appended later on
with gfc_add_block_to_block (&block, &se.pre);
Now, obviously the alloc_scalar_allocatable_subcomponent emitted statements
can depend on the se.pre sequence statements which can compute variables
used by alloc_scalar_allocatable_subcomponent like the length.
On the other side, I think the se.pre sequence really shouldn't depend
on the changes done by alloc_scalar_allocatable_subcomponent, that is
initializing the FIELD_DECLs of the destination allocatable subcomponent
only, the gfc_conv_expr statements are already created, so all they could
in theory depend above is on t.0.u or t.0._u_length, but I believe if the
rhs dependened on the lhs content (which is allocated by those statements
but really uninitialized), it would need to be discovered by the dependency
analysis and forced into a temporary.
So, in order to fix the first testcase, the second hunk of the patch just
emits the se.pre block before the alloc_scalar_allocatable_subcomponent
changes rather than after it.
The second problem is an ICE on the second testcase. expr in the caller
(expr2 inside of alloc_scalar_allocatable_subcomponent) has
expr2->ts.u.cl->backend_decl already set, INTEGER_CST 20, but
alloc_scalar_allocatable_subcomponent overwrites it to a new VAR_DECL
which it assigns a value to before the malloc. That can work if the only
places the expr2->ts is ever used are in the same local block or its
subblocks (and only if it is dominated by the code emitted by
alloc_scalar_allocatable_subcomponent, so e.g. not if that call is inside
of a conditional code and use later unconditional), but doesn't work
if expr2->ts is used before that block or after it. So, the exact ICE is
because of:
slen.1 = 20;
static character(kind=1) us[1][1:20] = {"foo "};
x.u = 0B;
x._u_length = 0;
{
struct t t.0;
struct t D.4308;
{
integer(kind=8) slen.1;
slen.1 = 20;
t.0.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR
<(sizetype) slen.1, 1>);
t.0._u_length = slen.1;
(void) __builtin_memcpy ((void *) t.0.u, (void *) &us[0], 20);
}
where the first slen.1 = 20; is emitted because it sees us has a VAR_DECL
ts.u.cl
[Bug c++/113969] ICE: SIGSEGV in finish_enum_value_list (decl.cc:17143) (or build_enumerator (decl.cc:17438) ) on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113969 Marek Polacek changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96441 --- Comment #2 from Marek Polacek --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96441#c2 seems related.
[Bug c++/96496] Conversion to enum with underlying type bool produces wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96496 Marek Polacek changed: What|Removed |Added Last reconfirmed|2020-08-06 00:00:00 |2024-2-17 --- Comment #5 from Marek Polacek --- Comment 3 test still doesn't work.
[Bug c++/96360] ICE in tree check: expected integer_cst, have truth_orif_expr in get_len, at tree.h:5954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96360 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Fixed by r12-7574.
[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068 --- Comment #9 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:fccfe6625121512f247cb59888e50eb9dcc84409 commit r14-9048-gfccfe6625121512f247cb59888e50eb9dcc84409 Author: Jerry DeLisle Date: Fri Feb 16 17:06:37 2024 -0800 libgfortran: Fix namelist read. PR libfortran/107068 libgfortran/ChangeLog: * io/list_read.c (read_logical): When looking for a possible variable name, check for left paren, indicating a possible array reference. gcc/testsuite/ChangeLog: * gfortran.dg/pr107068.f90: New test.
[Bug c/113973] New: Pleas issue a warning when using plain character values in bitwise operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113973
Bug ID: 113973
Summary: Pleas issue a warning when using plain character
values in bitwise operations
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
Target Milestone: ---
This example program compiles without any kind of warning in gcc:
static char x = 0xD8;
int main(void)
{
return 0x1200 | x;
}
The value returned from main is 0xFFD8 on architectures with 32-bit int and
signed characters by default. After just fixing a bug that was caused by an
unexpected sign expansion when building an int from individual bytes, I'd
rather have a warning if
1) A variable of type char is promoted to int.
2) The int value is used in an bitwise expression
3) More than 8 bits of the results are actually used
4) More than 8 bits may be non-zero
Because of condition 3, this will yiels no warning on "char y = x | 0x40;" (top
bits truncated, so condition 3 fails) and no warning on "int y = x & 0x40;"
(all high bits are guaranteed to be zero, so condition 4 fails).
The real-world bug that motivates this enhancement proposal is
https://github.com/hfst/hfst-ospell/issues/43
[Bug c++/113966] [14 Regression] Internal compiler error in `do_auto_deduction`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113966
--- Comment #5 from Marek Polacek ---
/* Check any placeholder constraints against the deduced type. */
if (processing_template_decl && context == adc_unify)
/* Constraints will be checked after deduction. */;
else if (tree constr = NON_ERROR (PLACEHOLDER_TYPE_CONSTRAINTS (auto_node)))
{
if (processing_template_decl)
{
gcc_checking_assert (context == adc_variable_type
|| context == adc_return_type
|| context == adc_decomp_type);
(gdb) p context
$2 = adc_requirement
Maybe we just have to allow adc_requirement in the assert?
[Bug ada/113972] New: ICE on container map for aggregate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113972 Bug ID: 113972 Summary: ICE on container map for aggregate. Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: p.p11 at orange dot fr CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 57451 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57451&action=edit Reproducer. With the following map for aggregate code: M := [for Key1 of Keys => Integer'Image (Key1)]; It is ok when checking but issues a bug box when compiling: $ gcc -c -gnat2022 test_20240217_map_for_agg.adb +===GNAT BUG DETECTED==+ | 13.2.0 (x86_64-apple-darwin21.6.0) Program_Error sem_type.adb:811 explicit raise| | Error detected at test_20240217_map_for_agg.adb:38:9 | | Compiling test_20240217_map_for_agg.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). 2024/test_20240217_map_for_agg.adb compilation abandoned
[Bug c++/113966] [14 Regression] Internal compiler error in `do_auto_deduction`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113966 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Summary|Internal compiler error in |[14 Regression] Internal |`do_auto_deduction` |compiler error in ||`do_auto_deduction` Target Milestone|--- |14.0 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Last reconfirmed||2024-02-17 Priority|P3 |P1 --- Comment #4 from Marek Polacek --- Started to ICE with r14-8770: commit 686b5eb9c9ee623a604dde5c49fa11c23f384c62 Author: Patrick Palka Date: Fri Feb 2 19:07:08 2024 -0500 c++: requires-exprs and partial constraint subst [PR110006]
[Bug c++/113969] ICE: SIGSEGV in finish_enum_value_list (decl.cc:17143) (or build_enumerator (decl.cc:17438) ) on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113969 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-02-17 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW
[Bug c++/113968] ICE: in create_tmp_var, at gimple-expr.cc:488 with -fcontracts and invalid member in contract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113968 Marek Polacek changed: What|Removed |Added Last reconfirmed||2024-02-17 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/113158] [11/12/13 Regression] Erroneous "looser exception specification" error for class template and depedent noexcept value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113158 Marek Polacek changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] |Erroneous "looser exception |Erroneous "looser exception |specification" error for|specification" error for |class template and depedent |class template and depedent |noexcept value |noexcept value --- Comment #5 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/113158] [11/12/13/14 Regression] Erroneous "looser exception specification" error for class template and depedent noexcept value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113158 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:876fa432ef4074053fa65b1855e7d43320515576 commit r14-9047-g876fa432ef4074053fa65b1855e7d43320515576 Author: Marek Polacek Date: Thu Feb 15 17:07:43 2024 -0500 c++: wrong looser excep spec for dep noexcept [PR113158] Here we find ourselves in maybe_check_overriding_exception_spec in a template context where we can't instantiate a dependent noexcept. That's OK, but we have to defer the checking otherwise we give wrong errors. PR c++/113158 gcc/cp/ChangeLog: * search.cc (maybe_check_overriding_exception_spec): Defer checking when a noexcept couldn't be instantiated & evaluated to false/true. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/noexcept83.C: New test.
[Bug fortran/113911] [14 Regression] Length is lost passing deferred-length character to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911 --- Comment #7 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:76aac40f5ecbc9cfb3b8734d181599e1b5a24bdf commit r14-9045-g76aac40f5ecbc9cfb3b8734d181599e1b5a24bdf Author: Harald Anlauf Date: Fri Feb 16 22:33:16 2024 +0100 Fortran: deferred length of character variables shall not get lost [PR113911] PR fortran/113911 gcc/fortran/ChangeLog: * trans-array.cc (gfc_trans_deferred_array): Do not clobber deferred length for a character variable passed as dummy argument. gcc/testsuite/ChangeLog: * gfortran.dg/allocatable_length_2.f90: New test. * gfortran.dg/bind_c_optional-2.f90: Enable deferred-length test.
[Bug target/113971] New: failure to build on arm64 musl (#error "Unsupported AArch64 platform for heap trampolines")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971 Bug ID: 113971 Summary: failure to build on arm64 musl (#error "Unsupported AArch64 platform for heap trampolines") Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: csfore at posteo dot net Target Milestone: --- Created attachment 57450 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57450&action=edit build.log Steps to reproduce: 1. Attempt to build latest snapshot on ARM64 with Musl 2. Failure to build with error below Musl version: 1.2.3 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-gentoo-linux-musl/13/lto-wrapper Target: aarch64-gentoo-linux-musl Configured with: /var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/configure --host=aarch64-gentoo-linux-musl --build=aarch64-gentoo-linux-musl --prefix=/usr --bindir=/usr/aarch64-gentoo-linux-musl/gcc-bin/13 --includedir=/usr/lib/gcc/aarch64-gentoo-linux-musl/13/include --datadir=/usr/share/gcc-data/aarch64-gentoo-linux-musl/13 --mandir=/usr/share/gcc-data/aarch64-gentoo-linux-musl/13/man --infodir=/usr/share/gcc-data/aarch64-gentoo-linux-musl/13/info --with-gxx-include-dir=/usr/lib/gcc/aarch64-gentoo-linux-musl/13/include/g++-v13 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/aarch64-gentoo-linux-musl/13/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 13.2.1_p20240113-r1 p12' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-multilib --disable-fixed-point --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --without-isl --enable-default-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.2.1 20240113 (Gentoo 13.2.1_p20240113-r1 p12) Error: /var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/gcc-14-20240211/libgcc/config/aarch64/heap-trampoline.c:53:2: error: #error "Unsupported AArch64 platform for heap trampolines" 53 | #error "Unsupported AArch64 platform for heap trampolines" | ^ /var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/gcc-14-20240211/libgcc/config/aarch64/heap-trampoline.c: In function '__gcc_nested_func_ptr_created': /var/tmp/portage/sys-devel/gcc-14.0.1_pre20240211-r1/work/gcc-14-20240211/libgcc/config/aarch64/heap-trampoline.c:146:30: error: 'aarch64_trampoline_insns' undeclared (first use in this function); did you mean 'aarch64_trampoline'? 146 | memcpy (trampoline->insns, aarch64_trampoline_insns, | ^~~~ | aarch64_trampoline
[Bug pch/113970] [14 Regression] pch/system-{1,2}.C fails on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2024-02-17 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug pch/113970] New: [14 Regression] pch/system-{1,2}.C fails on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
Bug ID: 113970
Summary: [14 Regression] pch/system-{1,2}.C fails on darwin
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: needs-bisection, wrong-code
Severity: normal
Priority: P3
Component: pch
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Target: *-darwin*
somewhere between r14-8885 and r14-9043
FAIL: g++.dg/pch/system-1.C -g assembly comparison
FAIL: g++.dg/pch/system-1.C -O2 -g assembly comparison
FAIL: g++.dg/pch/system-2.C -g assembly comparison
FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison
lots of lines like:
line #354
< .long 0x11ac1
> .long 0x11ac2
line #691
< .uleb128 0x22
> .uleb128 0x21
line #703
< .uleb128 0x22
> .uleb128 0x21
line #805
< .uleb128 0x22
> .uleb128 0x21
presumably something has changed size or alignment.
[Bug target/112294] thread_local13.C and thread_local14.C fail on x86_64-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112294 Iain Sandoe changed: What|Removed |Added Target|x86_64-apple-darwin21 |x86_64-apple-darwin* Build|x86_64-apple-darwin21 |x86_64-apple-darwin* Last reconfirmed|2023-10-30 00:00:00 |2024-2-17 Host|x86_64-apple-darwin21 |x86_64-apple-darwin* --- Comment #1 from Iain Sandoe --- I think this is probably a dup of PR106435 (the patch for that needs some rework)
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 110893, which changed state. Bug 110893 Summary: [modules] ICE Segmentation fault during GIMPLE pass modref https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110893 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/110893] [modules] ICE Segmentation fault during GIMPLE pass modref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110893 Nathaniel Shead changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||nshead at gcc dot gnu.org --- Comment #2 from Nathaniel Shead --- This looks to be fixed on GCC 14 trunk.
[Bug sanitizer/113728] libasan uses incorrect prctl prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113728 --- Comment #2 from Florian Weimer --- This has been worked around in glibc. Should we close this issue?
[Bug c++/113969] ICE: SIGSEGV in finish_enum_value_list (decl.cc:17143) (or build_enumerator (decl.cc:17438) ) on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113969
--- Comment #1 from Zdenek Sojka ---
Created attachment 57449
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57449&action=edit
very similar testcase, ICEing in build_enumerator instead
$ x86_64-pc-linux-gnu-gcc testcase2.C -wrapper valgrind,-q
testcase2.C:2:40: error: expected '}' before 'd'
2 | template enum struct b {
e
|~ ^
testcase2.C:2:40: error: expected '>' before 'd'
testcase2.C:2:42: error: expected unqualified-id before '}' token
2 | template enum struct b {
e
| ^
testcase2.C:2:42: error: expected declaration before '}' token
==13010== Invalid read of size 2
==13010==at 0xFA2DF0: build_enumerator(tree_node*, tree_node*, tree_node*,
tree_node*, unsigned int) (decl.cc:17438)
==13010==by 0x10930C7: cp_parser_enumerator_definition (parser.cc:21903)
==13010==by 0x10930C7: cp_parser_enumerator_list (parser.cc:21823)
==13010==by 0x10930C7: cp_parser_enum_specifier(cp_parser*)
(parser.cc:21754)
==13010==by 0x10772CE: cp_parser_type_specifier(cp_parser*, int,
cp_decl_specifier_seq*, bool, int*, bool*) (parser.cc:20034)
==13010==by 0x1078E2D: cp_parser_decl_specifier_seq(cp_parser*, int,
cp_decl_specifier_seq*, int*) (parser.cc:16590)
==13010==by 0x10AE38A: cp_parser_single_declaration(cp_parser*,
vec*, bool, bool, bool*)
(parser.cc:33137)
==13010==by 0x10AFA00: cp_parser_explicit_specialization(cp_parser*)
(parser.cc:19945)
==13010==by 0x10B3EC5: cp_parser_declaration(cp_parser*, tree_node*)
(parser.cc:15499)
==13010==by 0x10B461A: cp_parser_toplevel_declaration (parser.cc:15594)
==13010==by 0x10B461A: cp_parser_translation_unit (parser.cc:5279)
==13010==by 0x10B461A: c_parse_file() (parser.cc:51202)
==13010==by 0x1203D81: c_common_parse_file() (c-opts.cc:1311)
==13010==by 0x18172DD: compile_file() (toplev.cc:447)
==13010==by 0xEC6EDB: do_compile (toplev.cc:2152)
==13010==by 0xEC6EDB: toplev::main(int, char**) (toplev.cc:2308)
==13010==by 0xEC86ED: main (main.cc:39)
==13010== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==13010==
testcase2.C:2:72: internal compiler error: Segmentation fault
2 | template enum struct b {
e
|
^
0x1816fe2 crash_signal
/repo/gcc-trunk/gcc/toplev.cc:317
0xfa2df0 build_enumerator(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int)
/repo/gcc-trunk/gcc/cp/decl.cc:17438
0x10930c7 cp_parser_enumerator_definition
/repo/gcc-trunk/gcc/cp/parser.cc:21903
0x10930c7 cp_parser_enumerator_list
/repo/gcc-trunk/gcc/cp/parser.cc:21823
0x10930c7 cp_parser_enum_specifier
/repo/gcc-trunk/gcc/cp/parser.cc:21754
0x10772ce cp_parser_type_specifier
/repo/gcc-trunk/gcc/cp/parser.cc:20034
0x1078e2d cp_parser_decl_specifier_seq
/repo/gcc-trunk/gcc/cp/parser.cc:16590
0x10ae38a cp_parser_single_declaration
/repo/gcc-trunk/gcc/cp/parser.cc:33137
0x10afa00 cp_parser_explicit_specialization
/repo/gcc-trunk/gcc/cp/parser.cc:19945
0x10b3ec5 cp_parser_declaration
/repo/gcc-trunk/gcc/cp/parser.cc:15499
0x10b461a cp_parser_toplevel_declaration
/repo/gcc-trunk/gcc/cp/parser.cc:15594
0x10b461a cp_parser_translation_unit
/repo/gcc-trunk/gcc/cp/parser.cc:5279
0x10b461a c_parse_file()
/repo/gcc-trunk/gcc/cp/parser.cc:51202
0x1203d81 c_common_parse_file()
/repo/gcc-trunk/gcc/c-family/c-opts.cc:1311
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/113967] [14 Regression] ICE: in exact_div, at poly-int.h:2156 with -O -mavx512f since r14-3381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113967 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 57448 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57448&action=edit gcc14-pr113967.patch Untested fix.
[Bug c++/113969] New: ICE: SIGSEGV in finish_enum_value_list (decl.cc:17143) on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113969
Bug ID: 113969
Summary: ICE: SIGSEGV in finish_enum_value_list (decl.cc:17143)
on invalid code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 57447
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57447&action=edit
auto-reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.C -wrapper valgrind,-q
testcase.C:2:40: error: expected '}' before 'd'
2 | template enum struct b {
|~ ^
testcase.C:2:40: error: expected '>' before 'd'
testcase.C:2:42: error: expected unqualified-id before '}' token
2 | template enum struct b {
| ^
testcase.C:2:42: error: expected declaration before '}' token
testcase.C:2:71: error: expected identifier at end of input
2 | template enum struct b {
| ^
testcase.C:2:71: error: expected '}' at end of input
2 | template enum struct b {
| ~^
==8124== Invalid read of size 2
==8124==at 0xF95EFF: finish_enum_value_list(tree_node*) (decl.cc:17143)
==8124==by 0x1092B26: cp_parser_enum_specifier(cp_parser*)
(parser.cc:21792)
==8124==by 0x10772CE: cp_parser_type_specifier(cp_parser*, int,
cp_decl_specifier_seq*, bool, int*, bool*) (parser.cc:20034)
==8124==by 0x1078E2D: cp_parser_decl_specifier_seq(cp_parser*, int,
cp_decl_specifier_seq*, int*) (parser.cc:16590)
==8124==by 0x10AE38A: cp_parser_single_declaration(cp_parser*,
vec*, bool, bool, bool*)
(parser.cc:33137)
==8124==by 0x10AFA00: cp_parser_explicit_specialization(cp_parser*)
(parser.cc:19945)
==8124==by 0x10B3EC5: cp_parser_declaration(cp_parser*, tree_node*)
(parser.cc:15499)
==8124==by 0x10B461A: cp_parser_toplevel_declaration (parser.cc:15594)
==8124==by 0x10B461A: cp_parser_translation_unit (parser.cc:5279)
==8124==by 0x10B461A: c_parse_file() (parser.cc:51202)
==8124==by 0x1203D81: c_common_parse_file() (c-opts.cc:1311)
==8124==by 0x18172DD: compile_file() (toplev.cc:447)
==8124==by 0xEC6EDB: do_compile (toplev.cc:2152)
==8124==by 0xEC6EDB: toplev::main(int, char**) (toplev.cc:2308)
==8124==by 0xEC86ED: main (main.cc:39)
==8124== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==8124==
testcase.C:2:71: internal compiler error: Segmentation fault
^C
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9043-20240217001708-gd70f155b074-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9043-20240217001708-gd70f155b074-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240217 (experimental) (GCC)
[Bug c++/113968] New: ICE: in create_tmp_var, at gimple-expr.cc:488 with -fcontracts and invalid member in contract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113968
Bug ID: 113968
Summary: ICE: in create_tmp_var, at gimple-expr.cc:488 with
-fcontracts and invalid member in contract
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 57446
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57446&action=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -fcontracts testcase.C
testcase.C:4:20: error: 'struct A' has no member named 'm'
4 | void f(A a)[[pre:a.m]] {}
|^
testcase.C: In function 'void f(A)':
testcase.C:4:22: internal compiler error: in create_tmp_var, at
gimple-expr.cc:488
4 | void f(A a)[[pre:a.m]] {}
| ^
0x85aa24 create_tmp_var(tree_node*, char const*)
/repo/gcc-trunk/gcc/gimple-expr.cc:488
0x85aa24 create_tmp_var(tree_node*, char const*)
/repo/gcc-trunk/gcc/gimple-expr.cc:478
0x14b275a create_tmp_from_val
/repo/gcc-trunk/gcc/gimplify.cc:568
0x14b275a lookup_tmp_var
/repo/gcc-trunk/gcc/gimplify.cc:590
0x14b275a internal_get_tmp_var
/repo/gcc-trunk/gcc/gimplify.cc:645
0x14ad29f get_formal_tmp_var(tree_node*, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:673
0x14ad29f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:18804
0x14c0011 gimplify_expr
/repo/gcc-trunk/gcc/gimplify.cc:18849
0x14c0011 gimplify_arg(tree_node**, gimple**, unsigned int, bool)
/repo/gcc-trunk/gcc/gimplify.cc:3751
0x14c06b3 gimplify_call_expr
/repo/gcc-trunk/gcc/gimplify.cc:4036
0x14adc56 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:17749
0x14c5b43 gimplify_cleanup_point_expr
/repo/gcc-trunk/gcc/gimplify.cc:7480
0x14adc37 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:18173
0x14c5195 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7480
0x14c5195 gimplify_body(tree_node*, bool)
/repo/gcc-trunk/gcc/gimplify.cc:19047
0x14c55dc gimplify_function_tree(tree_node*)
/repo/gcc-trunk/gcc/gimplify.cc:19246
0x12d2657 cgraph_node::analyze()
/repo/gcc-trunk/gcc/cgraphunit.cc:685
0x12d5277 analyze_functions
/repo/gcc-trunk/gcc/cgraphunit.cc:1249
0x12d61fd symbol_table::finalize_compilation_unit()
/repo/gcc-trunk/gcc/cgraphunit.cc:2556
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9043-20240217001708-gd70f155b074-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9043-20240217001708-gd70f155b074-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240217 (experimental) (GCC)
[Bug tree-optimization/113967] [14 Regression] ICE: in exact_div, at poly-int.h:2156 with -O -mavx512f since r14-3381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113967 Jakub Jelinek changed: What|Removed |Added Summary|[14 Regression] ICE: in |[14 Regression] ICE: in |exact_div, at |exact_div, at |poly-int.h:2156 with -O |poly-int.h:2156 with -O |-mavx512f |-mavx512f since r14-3381 Priority|P3 |P1 CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r14-3381-g27de9aa152141e7f3ee66372647d0f2cd94c4b90 (at least #c2).
[Bug tree-optimization/113967] [14 Regression] ICE: in exact_div, at poly-int.h:2156 with -O -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113967
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2024-02-17
Status|UNCONFIRMED |NEW
--- Comment #2 from Andrew Pinski ---
Reduced testcase that fails on most (all) targets even:
```
typedef unsigned short W __attribute__((__vector_size__ (8)));
void
bar3 (W *x1)
{
W x = *x1;
W y = {};
__builtin_memmove (&y, 1 + (char *) &x, 2);
*x1 = y;
}
```
[Bug tree-optimization/113967] [14 Regression] ICE: in exact_div, at poly-int.h:2156 with -O -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113967 --- Comment #1 from Andrew Pinski --- Most likely r14-3381-g27de9aa152141e ...
[Bug tree-optimization/113967] [14 Regression] ICE: in exact_div, at poly-int.h:2156 with -O -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113967 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 CC||pinskia at gcc dot gnu.org
[Bug tree-optimization/113967] New: [14 Regression] ICE: in exact_div, at poly-int.h:2156 with -O -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113967 Bug ID: 113967 Summary: [14 Regression] ICE: in exact_div, at poly-int.h:2156 with -O -mavx512f Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57445 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57445&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -mavx512f testcase.c during GIMPLE pass: forwprop testcase.c: In function 'bar3': testcase.c:25:1: internal compiler error: in exact_div, at poly-int.h:2156 25 | } | ^ 0x8f2762 poly_int<1u, poly_result::is_poly>::type, poly_coeff_pair_traits::is_poly>::type>::result_kind>::type> exact_div<1u, unsigned long, unsigned long>(poly_int<1u, unsigned long> const&, unsigned long) /repo/gcc-trunk/gcc/poly-int.h:2156 0x8f2762 poly_int<1u, poly_result::is_poly>::type, poly_coeff_pair_traits::is_poly>::type>::result_kind>::type> exact_div<1u, unsigned long, unsigned long>(poly_int<1u, unsigned long> const&, unsigned long) /repo/gcc-trunk/gcc/poly-int.h:2150 0x8f2762 gimple_simplify_BIT_INSERT_EXPR(gimple_match_op*, gimple**, tree_node* (*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*, tree_node*) /repo/build-gcc-trunk-amd64/gcc/gimple-match-5.cc:16981 0x1cd5853 gimple_resimplify3 /repo/gcc-trunk/gcc/gimple-match-exports.cc:1107 0x1cd6a12 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node* (*)(tree_node*), tree_node* (*)(tree_node*)) /repo/gcc-trunk/gcc/gimple-match-exports.cc:898 0x116c817 fold_stmt_1 /repo/gcc-trunk/gcc/gimple-fold.cc:6359 0x166c5d5 execute /repo/gcc-trunk/gcc/tree-ssa-forwprop.cc:3950 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9043-20240217001708-gd70f155b074-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-9043-20240217001708-gd70f155b074-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240217 (experimental) (GCC)
[Bug c++/113966] Internal compiler error in `do_auto_deduction`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113966 --- Comment #3 from Andrew Pinski --- Reducing ...
[Bug c++/113966] Internal compiler error in `do_auto_deduction`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113966 --- Comment #2 from Andrew Pinski --- Note next time also attach the preprocessed source.
[Bug c++/113966] Internal compiler error in `do_auto_deduction`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113966 --- Comment #1 from Andrew Pinski --- Created attachment 57444 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57444&action=edit Preprocessed source
