[Bug fortran/114922] fsyntax-only need the modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922 --- Comment #5 from Axel Ehrich --- Thank you for the explanation. This resolves the issue.
[Bug middle-end/113179] [11/12/13/14/15 Regression] MIPS: INS is used for long long, before SLL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179 --- Comment #7 from Andrew Pinski --- (In reply to YunQiang Su from comment #6) > With some test on some CPUs, in fact, the lacking of `sll` won't make > troubles to us. > It seems that most of MIPS64 CPUs can process it well as expected. When I was working at Marvell(Cavium), only the Octeon simulator which cause issues with the lacking of `sll` rather than the actual hardware.
[Bug middle-end/113179] [11/12/13/14/15 Regression] MIPS: INS is used for long long, before SLL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179 --- Comment #6 from YunQiang Su --- With some test on some CPUs, in fact, the lacking of `sll` won't make troubles to us. It seems that most of MIPS64 CPUs can process it well as expected.
[Bug middle-end/113179] [11/12/13/14/15 Regression] MIPS: INS is used for long long, before SLL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179 YunQiang Su changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from YunQiang Su --- Fixed in GCC 15. Should we backport it to the previous versions?
[Bug middle-end/113179] [11/12/13/14/15 Regression] MIPS: INS is used for long long, before SLL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179
--- Comment #4 from GCC Commits ---
The master branch has been updated by YunQiang Su :
https://gcc.gnu.org/g:7d5d2b879ae7636ca118fb4f3a08b22705cdeacb
commit r15-171-g7d5d2b879ae7636ca118fb4f3a08b22705cdeacb
Author: YunQiang Su
Date: Mon Apr 29 00:33:44 2024 +0800
expmed: TRUNCATE value1 if needed in store_bit_field_using_insv
PR target/113179.
In `store_bit_field_using_insv`, we just use SUBREG if value_mode
>= op_mode, while in some ports, a sign_extend will be needed,
such as MIPS64:
If either GPR rs or GPR rt does not contain sign-extended 32-bit
values (bits 63..31 equal), then the result of the operation is
UNPREDICTABLE.
The problem happens for the code like:
struct xx {
int a:4;
int b:24;
int c:3;
int d:1;
};
void xx (struct xx *a, long long b) {
a->d = b;
}
In the above code, the hard register contains `b`, may be note well
sign-extended.
gcc/
PR target/113179
* expmed.cc(store_bit_field_using_insv): TRUNCATE value1 if
needed.
gcc/testsuite
PR target/113179
* gcc.target/mips/pr113179.c: New tests.
[Bug target/114955] marco DATA_ALIGNMENT may conflict with pragma pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114955 --- Comment #2 from Andrew Pinski --- Also DATA_ALIGNMENT (and LOCAL_ALIGNMENT) does not conflict with `pragma pack`. The documentation says https://gcc.gnu.org/onlinedocs/gcc/Structure-Layout-Pragmas.html : ``` that change the maximum alignment of members of structures (other than zero-width bit-fields), unions, and classes subsequently defined. ``` This does not mean a target is not free to increase the alignment of a global (or local) variable to begin with. It just means the alignment of a struct is that so that pointers of that struct will be with the lower alignment. Targets/GCC could increase alignment of global and local variables even without worrying about the alignment of the struct.
[Bug target/114943] X86 AVX2: inefficient code generated to convert SIMD Vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114943 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #1 from Hongtao Liu --- For convert3, we already have a patch for it, and will post soon. For convert, the current loop vectorizer has a limitation to keep the same vector length while vectorizing, thus generating extra packing/unpacking instructions compared to convert2. But there's no such limitation in BB vectorizer, so w/ -O3 -march=x86-64-v3 -fno-tree-loop-vectorize, convert is as good as convert2
[Bug c/114957] New: pragma pack is not in the concept index for the manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114957 Bug ID: 114957 Summary: pragma pack is not in the concept index for the manual Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- I noticed the `#pragma pack` is not in the concept index but there exists a page for it: https://gcc.gnu.org/onlinedocs/gcc/Structure-Layout-Pragmas.html
[Bug target/114955] marco DATA_ALIGNMENT may conflict with pragma pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114955 Andrew Pinski changed: What|Removed |Added Component|c |target Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2024-05-06 --- Comment #1 from Andrew Pinski --- No comment in the bug. Maybe press return too soon.
[Bug sanitizer/114956] New: Segmentation fault with -fsanitize=address -fsanitize=null -O2 when attribute no_sanitize_address is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114956
Bug ID: 114956
Summary: Segmentation fault with -fsanitize=address
-fsanitize=null -O2 when attribute no_sanitize_address
is enabled
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail 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
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/33rbWdf49
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/home/gcc_set/gcc-trunk/bin/gcc
COLLECT_LTO_WRAPPER=/home/gcc_set/gcc-trunk/libexec/gcc/aarch64-unknown-linux-gnu/15.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/home/gcc_set/gcc-trunk
--with-gmp=/home/build_essential --with-mpfr=/home/build_essential
--with-mpc=/home/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leakcd CC=gcc CXX=g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240430 (experimental) (GCC)
git version: 22b20ac6c6aead2d3f36c413a77dd0b80adfec39
***
Program:
$ cat mutant.c
int **a;
__attribute__((always_inline)) int *c() {
int b[1];
b;
}
__attribute__((no_sanitize_address)) static char d() { *a = c(); }
void e() { d(); }
***
Command Lines:
$ gcc -fsanitize=address -fsanitize=null -O2 -c mutant.c
mutant.c:2:37: warning: 'always_inline' function might not be inlinable unless
also declared 'inline' [-Wattributes]
2 | __attribute__((always_inline)) int *c() {
| ^
during GIMPLE pass: sanopt
mutant.c: In function 'd.isra':
mutant.c:6:50: internal compiler error: Segmentation fault
6 | __attribute__((no_sanitize_address)) static char d() { *a = c(); }
| ^
0xf2d49b crash_signal
../../gcc/gcc/toplev.cc:319
0xf3fcfc contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3769
0xf3fcfc build_shadow_mem_access
../../gcc/gcc/asan.cc:2552
0xf4b90f asan_expand_mark_ifn(gimple_stmt_iterator*)
../../gcc/gcc/asan.cc:3854
0xf5f6bf execute
../../gcc/gcc/sanopt.cc:1379
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/114955] New: marco DATA_ALIGNMENT may conflict with pragma pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114955 Bug ID: 114955 Summary: marco DATA_ALIGNMENT may conflict with pragma pack Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hanwei62 at huawei dot com Target Milestone: ---
[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008 --- Comment #15 from Luke Dalessandro --- (In reply to Jonathan Wakely from comment #5) > > IMO the ideal solution is for GCC to stop using whether a function is inline > as an optimisation hint. Then we wouldn't need some extra GCC-specific way > to override that. I'd vote to just do this and provide an attribute that's weaker than [[gnu::always_inline]] for those that need it. No need to change any underlying language stuff.
[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008 --- Comment #14 from Chris Elrod --- To me, an "inline" function is one that the compiler inlines. It just happens that the `inline` keyword also means both comdat semantics, and possibly hiding the symbol to make it internal (-fvisibility-inlines-hidden). It also just happens to be the case that the vast majority of the time I mark a function `inline`, it is because of this, not because of the compiler hint. `static` of course also specifies internal linkage, but I generally prefer the comdat semantics: I'd rather merge than duplicate the definitions. If there is a new keyword or pragma meaning comdat semantics (and preferably also specifying internal linkage), I would rather have the name reference that. I'd rather have a positive name about what it does, than negative: "quasi_inline: like inline, except it does everything inline does except the inline part". Why define as a set diff -- naming it after the thing it does not do! -- if you could define it in the affirmative, based on what it does in the first place?
[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008 --- Comment #13 from Eric Gallager --- (In reply to Jonathan Wakely from comment #12) > There's nothing fake about them, they are definitely inline functions as far > as the language rules. But in some cases we don't want the compiler to use > that fact as an optimisation hint. "quasi_inline"? "pseudo_inline"? "unoptimizable_inline"? "strictly_inline"? "honorary_inline"? "inline_in_name_only"? "ceremonially_inline"?
[Bug c++/71482] Add -Wglobal-constructors warning option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71482 --- Comment #9 from Eric Gallager --- (In reply to Jonathan Wakely from comment #8) > (In reply to Eric Gallager from comment #6) > > Another reason this warning might be wanted: name mangling and demangling of > > global constructors has been buggy for awhile now; see bug 54254 > > Looks like that's just a problem demangling the symbol name to print it in a > human-readable form. What's buggy about the mangling? Well, I guess I was just remembering that "mangler dogfooding" proposal that would have added a checking option to ensure that every mangling of a symbol name that the mangler emits can also be demangled by the demangler... that didn't go in, did it? If it had, this would be an example of something that might trip it up...
[Bug c++/114954] New: [modules] ICE in write_class_def with templated union type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114954
Bug ID: 114954
Summary: [modules] ICE in write_class_def with templated union
type
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nshead at gcc dot gnu.org
Blocks: 103524
Target Milestone: ---
The following sample crashes on trunk:
export module main;
template
union U {
private:
char a[N + 1];
int b;
};
U<4> p;
With 'g++ -fmodules-ts -S main.cpp':
~/ice/main.cpp:1:8: internal compiler error: in write_class_def, at
cp/module.cc:12118
1 | export module main;
|^~
0x1010c67 write_class_def
../../gcc/gcc/cp/module.cc:12118
0x1014d91 write_definition
../../gcc/gcc/cp/module.cc:12731
0x101880e depset::hash::find_dependencies(module_state*)
../../gcc/gcc/cp/module.cc:13640
0x1026a62 module_state::write_begin(elf_out*, cpp_reader*,
module_state_config&, unsigned int&)
../../gcc/gcc/cp/module.cc:18253
0x102e39f finish_module_processing(cpp_reader*)
../../gcc/gcc/cp/module.cc:20693
0xf50556 c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.cc:5393
0x131e75f c_common_parse_file()
../../gcc/gcc/c-family/c-opts.cc:1329
The assertion that fails is
/* Every class but __as_base has a type-specific. */
gcc_checking_assert (!TYPE_LANG_SPECIFIC (type) == IS_FAKE_BASE_TYPE (type));
The issue looks to be that a union `__as_base` type doesn't satisfy the
'IS_FAKE_BASE_TYPE', which only applies to RECORD_TYPEs.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue
[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 --- Comment #20 from Andrew Pinski --- New patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650757.html It was simplier than I had expected too.
[Bug testsuite/114953] New: libstdc++'s 30_threads/semaphore/try_acquire_posix.cc can sometimes fail (while running under qemu)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114953 Bug ID: 114953 Summary: libstdc++'s 30_threads/semaphore/try_acquire_posix.cc can sometimes fail (while running under qemu) Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: testsuite-fail Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- The testcase has: ``` auto const dur = 250ms; ... auto const at = std::chrono::system_clock::now() + dur; auto const t0 = std::chrono::steady_clock::now(); VERIFY( !s._M_try_acquire_until(at) ); auto const diff = std::chrono::steady_clock::now() - t0; VERIFY( diff >= dur ); ``` So the difference here might be less than 250ms because it might be that t0 might have been a few (one or two?) microseconds after at was set. This testcase failed for me with -std=c++26 but passed for -std=c++20 while running in the testsuite but on a semi-loaded system and running under qemu. So it just happened to hit the failure in that case. I suspect it could fail while not running under qemu but with a heavy load on the system and it just happens to be time sliced out between the 2 calls to now(). Maybe there should only 1 call to now before until so you don't run into spurious failure like this.
[Bug tree-optimization/114952] False positive -Wmaybe-uninitialized starting at -O3 in libbpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114952 --- Comment #1 from Andrew Pinski --- Most likely GCC does not know errno is non-zero after the call to elf_open and checking `fd < 0`. Adding: if (ret == 0) __builtin_unreachable(); After the assignment of `ret = -errono;` fixes the warning.
[Bug c/114952] New: False positive -Wmaybe-uninitialized starting at -O3 in libbpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114952 Bug ID: 114952 Summary: False positive -Wmaybe-uninitialized starting at -O3 in libbpf Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kacper.slominski72 at gmail dot com Target Milestone: --- Created attachment 58105 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58105=edit Preprocessed elf.c source code When compiling libbpf (both as a part of the Linux kernel build, and as a standalone library), starting with at least GCC 11.1, there are some false positive -Wmaybe-uninitalized warnings generated when compiling with -O3. In function ‘elf_close’, inlined from ‘elf_close’ at elf.c:53:6, inlined from ‘elf_find_func_offset_from_file’ at elf.c:384:2: elf.c:57:9: warning: ‘elf_fd.elf’ may be used uninitialized [-Wmaybe-uninitialized] 57 | elf_end(elf_fd->elf); | ^~~~ elf.c: In function ‘elf_find_func_offset_from_file’: elf.c:377:23: note: ‘elf_fd.elf’ was declared here 377 | struct elf_fd elf_fd; | ^~ In function ‘elf_close’, inlined from ‘elf_close’ at elf.c:53:6, inlined from ‘elf_find_func_offset_from_file’ at elf.c:384:2: elf.c:58:9: warning: ‘elf_fd.fd’ may be used uninitialized [-Wmaybe-uninitialized] 58 | close(elf_fd->fd); | ^ elf.c: In function ‘elf_find_func_offset_from_file’: elf.c:377:23: note: ‘elf_fd.fd’ was declared here 377 | struct elf_fd elf_fd; | ^~ >From a quick look at the source code, as far as I can see, elf_fd is always initialized at this point (looking at elf_find_func_offset_from_file), and I think inlining has something to do with this (and hence it doesn't show up at -O2). Attached is a preprocessed copy of elf.c. To reproduce, run: $ gcc preprocessed.c -c -O3 -Wmaybe-uninitialized
[Bug other/114951] Incorrect documentation link emitted for warning options ending in =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114951 Andrew Pinski changed: What|Removed |Added Known to work||14.0 --- Comment #1 from Andrew Pinski --- This looks to be fixed in GCC 14 (most likely by r14-6921-g5bb18475a10d05) .
[Bug other/114951] New: Incorrect documentation link emitted for warning options ending in =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114951
Bug ID: 114951
Summary: Incorrect documentation link emitted for warning
options ending in =
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: peter0x44 at disroot dot org
Target Milestone: ---
For the following code:
#include
int main(void) { printf("%f", 1); }
GCC generates a warning with the following link:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat=
That does not properly link to the correct paragraph in the documentation.
Removing the = works:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat
or, encoding = as _003d:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat_003d
[Bug target/114942] [14/15 Regression] ICE on valid code at -O1 with "-fno-tree-sra -fno-guess-branch-probability": in extract_constrain_insn, at recog.cc:2713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
--- Comment #3 from Uroš Bizjak ---
Reload starts with:
(insn 39 38 48 6 (parallel [
(set (strict_low_part (subreg:QI (reg/v:HI 108 [ f ]) 0))
(ior:QI (subreg:QI (zero_extract:HI (reg/v:HI 108 [ f ])
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)
(reg:QI 121 [ _7 ])))
(clobber (reg:CC 17 flags))
]) "pr114942.c":19:7 626 {*iorqi_exthi_1_slp}
(expr_list:REG_DEAD (reg:QI 121 [ _7 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
Choosing alt 1 in insn 39: (0) (1) !qm (2) Q {*iorqi_exthi_1_slp}
and then allocates:
(insn 39 56 57 6 (parallel [
(set (strict_low_part (reg:QI 2 cx [orig:108 f ] [108]))
(ior:QI (subreg:QI (zero_extract:HI (reg/v:HI 2 cx [orig:108 f
] [108])
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)
(reg:QI 0 ax [orig:121 _7 ] [121])))
(clobber (reg:CC 17 flags))
]) "pr114942.c":19:7 626 {*iorqi_exthi_1_slp}
not taking into account the earlyclobber of operand 0.
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #12 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:21e7aa5f3ea44ca2fef8deb8788edffc04901b5c commit r15-168-g21e7aa5f3ea44ca2fef8deb8788edffc04901b5c Author: Harald Anlauf Date: Mon Apr 29 19:52:52 2024 +0200 Fortran: fix issues with class(*) assignment [PR114827] gcc/fortran/ChangeLog: PR fortran/114827 * trans-array.cc (gfc_alloc_allocatable_for_assignment): Take into account _len of unlimited polymorphic entities when calculating the effective element size for allocation size and array span. Set _len of lhs to _len of rhs. * trans-expr.cc (trans_class_assignment): Take into account _len of unlimited polymorphic entities for allocation size. gcc/testsuite/ChangeLog: PR fortran/114827 * gfortran.dg/asan/unlimited_polymorphic_34.f90: New test.
[Bug tree-optimization/114948] [14/15 Regression] ICE on valid code at -O3 with "-fno-tree-ccp -fno-tree-ch" on x86_64-linux-gnu: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114948 Andrew Pinski changed: What|Removed |Added Summary|ICE on valid code at -O3|[14/15 Regression] ICE on |with "-fno-tree-ccp |valid code at -O3 with |-fno-tree-ch" on|"-fno-tree-ccp |x86_64-linux-gnu: in|-fno-tree-ch" on |check_loop_closed_ssa_def, |x86_64-linux-gnu: in |at |check_loop_closed_ssa_def, |tree-ssa-loop-manip.cc:647 |at ||tree-ssa-loop-manip.cc:647 Keywords||ice-checking Ever confirmed|0 |1 Last reconfirmed||2024-05-05 Target Milestone|--- |14.0 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/114950] New: [modules] ICE in binding_cmp when merging friend functions in partitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114950
Bug ID: 114950
Summary: [modules] ICE in binding_cmp when merging friend
functions in partitions
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nshead at gcc dot gnu.org
Blocks: 103524
Target Milestone: ---
The following code ICEs on trunk:
// format.h
template
struct A {
friend void x();
};
template
struct B {
virtual void f() { A r; }
};
template struct B;
// a.cpp
module M:a;
extern "C++" {
#include "format.h"
}
// b.cpp
module M:b;
extern "C++" {
#include "format.h"
}
// m.cpp
export module M;
import :a;
import :b;
Compiled with 'g++ -fmodules-ts -S [abm].cpp' results in:
~/ice/m.cpp:1:8: internal compiler error: in binding_cmp, at cp/module.cc:13712
1 | export module M;
|^~
0x1018b62 binding_cmp
../../gcc/gcc/cp/module.cc:13712
0x3893656 cmp1
../../gcc/gcc/sort.cc:151
0x3892f8e netsort
../../gcc/gcc/sort.cc:168
0x38927cd mergesort
../../gcc/gcc/sort.cc:205
0x389249a gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
../../gcc/gcc/sort.cc:268
0x1019128 depset::hash::finalize_dependencies()
../../gcc/gcc/cp/module.cc:13788
0x1026a71 module_state::write_begin(elf_out*, cpp_reader*,
module_state_config&, unsigned int&)
../../gcc/gcc/cp/module.cc:18255
0x102e39f finish_module_processing(cpp_reader*)
../../gcc/gcc/cp/module.cc:20693
0xf50556 c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.cc:5393
0x131e75f c_common_parse_file()
../../gcc/gcc/c-family/c-opts.cc:1329
The issue looks to be that the friend function is added to multiple depsets.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue
[Bug gcov-profile/114949] New: Missing function return count in JSON format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114949 Bug ID: 114949 Summary: Missing function return count in JSON format Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: michael.foerderer at gmx dot de Target Milestone: --- While adding support for GCOV JSON intermediate format to GCOVR (https://github.com/gcovr/gcovr/pull/766) we found out that the return count of functions are missing. Only the execution count is available. In the GCOV text representation following informations were available for a function: function Foo::inc() called 0 returned 0% blocks executed 0%
[Bug tree-optimization/114948] New: ICE on valid code at -O3 with "-fno-tree-ccp -fno-tree-ch" on x86_64-linux-gnu: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114948
Bug ID: 114948
Summary: ICE on valid code at -O3 with "-fno-tree-ccp
-fno-tree-ch" on x86_64-linux-gnu: in
check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
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: ---
It appears to be a recent regression as it doesn't reproduce with 13.2 and
earlier.
Compiler Explorer: https://godbolt.org/z/szY6nz1W3
[522] % 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/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240505 (experimental) (GCC)
[523] %
[523] % gcctk -O3 -fno-tree-ccp -fno-tree-ch small.c
during GIMPLE pass: cunroll
small.c: In function ‘main’:
small.c:2:5: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
2 | int main() {
| ^~~~
0x89471d check_loop_closed_ssa_def
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:647
0x130e654 check_loop_closed_ssa_bb
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:661
0x131023e verify_loop_closed_ssa(bool, loop*)
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:697
0x131023e verify_loop_closed_ssa(bool, loop*)
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:681
0x12f54fe tree_unroll_loops_completely
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1569
0x12f5583 execute
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1673
0x12f5583 execute
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1663
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.
[524] %
[524] % cat small.c
int a, b, c, d;
int main() {
int *e = 0;
for (; d; d++)
L1:
;
L2:
if (a) {
for (c = 0; c < 2; ++c) {
int *h;
int **i =
int **const *j =
int **const **k =
if (c) {
if (b)
goto L2;
a = *e;
}
}
goto L1;
}
return 0;
}
[Bug libgcc/114907] __trunchfbf2 should be renamed to __extendhfbf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #7 from Hongtao Liu --- (In reply to Jakub Jelinek from comment #6) > Neither of the modes is a subset or superset of the other, so truncate vs. > extend makes no sense. The choice was arbitrary. It sounds to me we need to define an alias of strong_alias (__trunchfbf2, __extendhfbf2)
[Bug c++/114947] New: [modules] ICE when processing class-scope constrained partial specialisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114947
Bug ID: 114947
Summary: [modules] ICE when processing class-scope constrained
partial specialisations
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nshead at gcc dot gnu.org
Target Milestone: ---
The following code ICEs on trunk:
// part.cpp
module M:part;
struct A {
template struct R;
template requires false struct R;
template requires true struct R;
};
template int foo(T, int);
template int foo(T, A);
void go() { foo(0, 0); }
// m.cpp
export module M;
export import :part;
This is ultimately because 'set_defining_module' is not called on the partial
specialisation declarations of R. This is a regression since r15-101, found
while reducing the following testcase that also ICEs even before this change:
// a.cpp
module;
#include
export module M:a;
// b.cpp
module;
#include
export module M:b;
// m.cpp
export module M;
export import :a;
export import :b;
