[Bug c++/85518] ICE mangling _FloatN types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85518 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.0 Status|UNCONFIRMED |RESOLVED --- Comment #6 from Andrew Pinski --- Fixed.
[Bug middle-end/82955] ICE when using -fdump-passes -fdisable-tree-einline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82955 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 93874 (note even though that bug report is newer, it was the one where the patch was recorded to fix it). *** This bug has been marked as a duplicate of bug 93874 ***
[Bug middle-end/93874] ICE due to command line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93874 Andrew Pinski changed: What|Removed |Added CC||mingw.android at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 82955 has been marked as a duplicate of this bug. ***
[Bug debug/77343] ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77343
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2021-08-25 00:00:00 |2024-3-24
--- Comment #2 from Andrew Pinski ---
Note the corrected testcase is:
```
int
crypto_cbc_decrypt_inplace(int bsize)
{
unsigned char last_iv[bsize];
}
```
That is you need to remove the static.
[Bug debug/68010] [11/12/13/14 Regression] ICE with -g and using namespace and namespace alias inside a template class with dependent inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68010 Andrew Pinski changed: What|Removed |Added Known to work||4.1.2 Known to fail||4.4.7, 4.5.3, 4.6.4 Target Milestone|--- |11.5 Summary|ICE with -g and using |[11/12/13/14 Regression] |namespace and namespace |ICE with -g and using |alias inside a template |namespace and namespace |class with dependent|alias inside a template |inheritance |class with dependent ||inheritance --- Comment #11 from Andrew Pinski --- This is actually a regression from at least GCC 4.1.2 which was able to compile this without an ICE.
[Bug debug/49162] ICE in in output_die, at dwarf2out.c:10568 with -femit-struct-debug-reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49162 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 47209 ***
[Bug debug/47209] ICE: SIGSEGV in should_emit_struct_debug (dwarf2out.c:627) with -f{no-,}emit-struct-debug-{baseonly,reduced} -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47209 Andrew Pinski changed: What|Removed |Added CC||pawel_sikora at zoho dot com --- Comment #8 from Andrew Pinski --- *** Bug 49162 has been marked as a duplicate of this bug. ***
[Bug debug/47209] ICE: SIGSEGV in should_emit_struct_debug (dwarf2out.c:627) with -f{no-,}emit-struct-debug-{baseonly,reduced} -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47209 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug debug/48315] ICE in mem_loc_descriptor, at dwarf2out.c:13899
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48315 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.7.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=48203 --- Comment #5 from Andrew Pinski --- Fixed long ago.
[Bug middle-end/44102] ICE with asm goto + __builtin_unreachable () in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44102 --- Comment #4 from Andrew Pinski --- (In reply to Steven Bosscher from comment #3) > This fix is wrong. > (http://gcc.gnu.org/viewcvs?view=revision=159495) > > There is a check at the start of cleanup_cfg to always set the > CLEANUP_CFGLAYOUT flag whenever we're in cfglayout mode: > > 120893 steven /* Set the cfglayout mode flag here. We could update > all the callers > 120893 steven but that is just inconvenient, especially given that > we eventually > 120893 steven want to have cfglayout mode as the default. */ > 120893 steven if (current_ir_type () == IR_RTL_CFGLAYOUT) > 120893 steven mode |= CLEANUP_CFGLAYOUT; > 120893 steven > > > So this part of your fix: > > - if ((mode & CLEANUP_CFGLAYOUT) > + if (current_ir_type () == IR_RTL_CFGLAYOUT) > > is incorrect. So the way I read this is that the fix is not wrong, just it uses the new check instead of the old way. Now I am not sure what about the status of always using cfglayout because what I remember is that is used all the way until post reload(RA) now.
[Bug target/39457] [power7-meissner] unable to find a register to spill in class 'LINK_OR_CTR_REGS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39457 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Fixed a long time ago.
[Bug driver/30640] Memory leak in lang_specific_driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30640 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-03-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed. The following files which contain lang_specific_driver has the same issue: c-family/cppspec.cc c/gccspec.cc cp/g++spec.cc d/d-spec.cc rust/rustspec.cc fortran/gfortranspec.cc (it does not have a memory leak really though it keeps around a pointer after its use though). go/gospec.cc m2/gm2spec.cc (similar to fortran)
[Bug c++/20357] Multiply defined assembler symbols for template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20357 --- Comment #3 from Andrew Pinski --- Just for reference here is the ICE that is produced: ``` :10:1: error: Two symbols with same comdat_group are not linked by the same_comdat_group list. 10 | } | ^ _ZN1XIXadL_Z1fvEEEC1Ev/8 (X::X() [with void (* f)() = f]) Type: function definition analyzed alias cpp_implicit_alias Visibility: semantic_interposition public weak comdat comdat_group:_ZN1XIXadL_Z1fvEEEC5Ev one_only Same comdat group as: _ZN1XIXadL_Z1fvEEEC2Ev/7 previous sharing asm name: 5 References: _ZN1XIXadL_Z1fvEEEC2Ev/7 (alias) Referring: Function flags: Called by: main/2 Calls: _ZN1XIXadL_Z1fvEEEC1Ev/5 (X::X() [with void (* f)() = f]) Type: function definition analyzed alias cpp_implicit_alias Visibility: semantic_interposition public weak comdat comdat_group:_ZN1XIXadL_Z1fvEEEC5Ev one_only Same comdat group as: _ZN1XIXadL_Z1fvEEEC2Ev/4 next sharing asm name: 8 References: _ZN1XIXadL_Z1fvEEEC2Ev/4 (alias) Referring: Function flags: Called by: _Z41__static_initialization_and_destruction_0v/9 Calls: ```
[Bug c++/103825] ICE on switch on enum class in bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103825 Andrew Pinski changed: What|Removed |Added CC||Alexandre.BUSTICO at enac dot fr --- Comment #2 from Andrew Pinski --- *** Bug 114451 has been marked as a duplicate of this bug. ***
[Bug c++/114451] regression : ICE on switch over enum class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114451 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- >12.2, 13.1 and 13.2 does not trigger the bug. Actually those do trigger the bug, just the trunk (in this case GCC 14), enables checking by default so you end up with an ICE there. If you use `-fchecking` for the released GCC, you get the ICE too. And if you use -fno-checking for the trunk, you don't get an ICE. So this is still a dup. *** This bug has been marked as a duplicate of bug 103825 ***
[Bug c++/114451] New: regression : ICE on switch over enum class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114451
Bug ID: 114451
Summary: regression : ICE on switch over enum class
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Alexandre.BUSTICO at enac dot fr
Target Milestone: ---
Same bug had been reported as BugID 103825 for gcc12.0.0 The bug has been fixed
for subsequent gcc version : 12.2, 13.1 and 13.2 does not trigger the bug. The
bug is exhibited again with gcc14.0.0 devel.
code that trigger ICE :
enum class En {A};
struct St {En field :1;};
int main(void)
{
volatile St s = {.field = En::A};
switch(s.field) {
case En::A : break;
}
}
error message :
: In function 'int main()':
:4:5: error: type precision mismatch in switch statement
4 | int main(void)
| ^~~~
switch (retval.0) , case 0: >
:4:5: internal compiler error: 'verify_gimple' failed
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See
[Bug c++/114450] -Wunused-but-set-variable false positive of static variable initialized by a lambda used by a generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114450
--- Comment #4 from Olof Gullnäs ---
(In reply to Andrew Pinski from comment #2)
> Reduced testcase:
> ```
>
> template
> void foreach(F f) {f(1);}
>
> void g ()
> {
> static constexpr auto lambda_2 = [](int) { };
> auto lambda_1 = [](auto id) { lambda_2(id); };
> foreach(lambda_1);
> }
> ```
Nice reduction!
[Bug analyzer/111289] [13 Regression] Unwarranted -Wanalyzer-va-arg-type-mismatch warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289 --- Comment #6 from Bruno Haible --- (In reply to John David Anglin from comment #5) > Don't include on hpux to avoid conflicting type declarations > for mode_t. This fixes test on houx. Why not entirely remove the '#include '? There is nothing in this file that needs it.
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #19 from Andrew Pinski --- (In reply to Andrew Pinski from comment #18) > Created attachment 57805 [details] > t1.cc ~/upstream-gcc-match/bin/g++ -flto t1.cc t2.cc -O1 -std=c++20 I attached the reduced testcase from the reduced testcase; 3 files including one header which is common between the 2 except for the constexpr. I will redo the reduction to make sure it is valid.
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #18 from Andrew Pinski --- Created attachment 57805 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57805=edit t1.cc
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #17 from Andrew Pinski --- Created attachment 57804 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57804=edit t2.cc
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #16 from Andrew Pinski --- Created attachment 57803 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57803=edit t.h
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #15 from Sam James --- Created attachment 57802 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57802=edit src_data_test_QualityValues.cpp.ii.orig.xz
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #14 from Sam James --- Created attachment 57801 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57801=edit src_data_test_MappedRead.cpp.ii.orig.xz Attaching the originals..
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #13 from Andrew Pinski --- (In reply to Sam James from comment #9) > ``` > $ gcc -std=c++20 -flto src_data_test_MappedRead.cpp.ii > src_data_test_QualityValues.cpp.ii -O1 > lto1: error: Alias and target’s comdat groups differs > _ZNSt6vectorIN6PacBio4Data12QualityValueESaIS2_EEC2ERKS4_/8 (__ct_base ) > Type: function definition analyzed > [...] > ``` This testcase seems undefined behavior ... The only difference between the 2 files is one has constexpr on the vector constructor and the other does not ...
[Bug middle-end/114448] Roundup not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114448 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-03-24 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug ada/114424] gnat: Ada.Calendar.Clock crashes on 32bit architectures with 64bit time_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114424 --- Comment #8 from Eric Botcazou --- But s-osprim__posix2008.adb dies not use gettimeofday, does it ?
[Bug analyzer/111289] [13 Regression] Unwarranted -Wanalyzer-va-arg-type-mismatch warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289 --- Comment #5 from John David Anglin --- Created attachment 57800 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57800=edit Patch Don't include on hpux to avoid conflicting type declarations for mode_t. This fixes test on houx.
[Bug ada/114424] gnat: Ada.Calendar.Clock crashes on 32bit architectures with 64bit time_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114424 --- Comment #7 from Matthias Klose --- something did change with Nicolas example: date '+Expected: %s'; ./foo Expected: 1711306699 local : 1711306700. 1362 System.OS_Primitives:-6017917000.119493888
[Bug middle-end/114448] Roundup not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114448 --- Comment #1 from Andrew Pinski --- Created attachment 57799 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57799=edit Full testcase Please next time attach or put inline the full testcase and not just a link to godbolt.
[Bug middle-end/114448] Roundup not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114448 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug ada/114424] gnat: Ada.Calendar.Clock crashes on 32bit architectures with 64bit time_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114424 --- Comment #6 from Matthias Klose --- still seen, when both posix2008 files are used.
[Bug middle-end/114449] bswap64 not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114449 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Severity|normal |enhancement
[Bug c++/110707] unused-but-set-variable in static lambda with deduced parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110707 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-24 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/114450] -Wunused-but-set-variable false positive of static variable initialized by a lambda used by a generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114450 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-03-24 Status|UNCONFIRMED |NEW Blocks||89180 --- Comment #3 from Andrew Pinski --- Confirmed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 [Bug 89180] [meta-bug] bogus/missing -Wunused warnings
[Bug c++/114450] -Wunused-but-set-variable false positive in lambda using another static auto lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114450
--- Comment #2 from Andrew Pinski ---
Reduced testcase:
```
template
void foreach(F f) {f(1);}
void g ()
{
static constexpr auto lambda_2 = [](int) { };
auto lambda_1 = [](auto id) { lambda_2(id); };
foreach(lambda_1);
}
```
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 Sam James changed: What|Removed |Added Summary|[14 Regression] lto1: |[14 Regression] lto1: |error: Alias and target's |error: Alias and target's |comdat groups differs |comdat groups differs since ||r14-5979-g99d114c15523e0 CC||mpolacek at gcc dot gnu.org --- Comment #12 from Sam James --- r14-5979-g99d114c15523e0is the first bad commit commit r14-5979-g99d114c15523e0 Author: Marek Polacek Date: Fri Nov 17 14:48:44 2023 -0500 c++: P2280R4, Using unknown refs in constant expr [PR106650]
[Bug c++/114450] -Wunused-but-set-variable false positive in lambda using another static auto lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114450 --- Comment #1 from Olof Gullnäs --- This is observed on a Suse Linux X86 system
[Bug c++/114450] New: -Wunused-but-set-variable false positive in lambda using another static auto lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114450
Bug ID: 114450
Summary: -Wunused-but-set-variable false positive in lambda
using another static auto lambda
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: olof.gullnas at gmail dot com
Target Milestone: ---
Created attachment 57798
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57798=edit
Code to produce warning
Using g++ where "g++-13 -v" print a last line with:
gcc version 13.2.1 20230912 [revision b96e66fd4ef3e36983969fb8cdd1956f551a074b
(SUSE Linux)
I compiling with g++-13 -Wall -Wextra.
This program gets a warning
variable ‘lambda_2’ set but not used [-Wunused-but-set-variable]
The variable IS used, so I think this is a "false positive"
The code is stripped down from a MUCH larger example so this code
does not do anything useful...
//#include // required if std::for_each or std::ranges::for_each is
used
#include // for "trace printouts", not needed if printouts are
removed
#include
// a MUCH simplified version of std::for_each
template
void foreach(I b, I e, F f)
{
for (auto ii= b; ii != e; ++ii)
{
f(*ii);
}
};
int main (int, char**)
{
std::vector v{ 2 };
// constexpr is not needed for warning to appear. static probably is
// If not static and "lambda_2" captured by lambda_1 then no
// warning. Likely that static variable being available
// to lambda_1 without explicit capture is required for warning to
// appear.
// A lambda that returns another lambda. A -Wunused-but-set-variable
// warning is generated. It IS used in lambda_1.
static /*constexpr*/ auto lambda_2 = [](auto id) {
std::cout << "lambda_2" << "\n";
return [id]( auto f) {
std::cout<< "lambda gen by lambda_2\n";
return f == id;
};
};
auto lambda_1 = []( auto& id)
{
auto f = lambda_2(id); // lambda_2 used here
// to avoid warning about unused f... If pgm executed without
// following line, lambda_2 is still called/used.
std::cout << f(2) << "\n";
};
#if 1
// using a local simplistic foreach template gives the warning
foreach(v.begin(), v.end(), lambda_1);
// as does using lambda_1 in std::for_each(...)
//std::for_each( v.begin(), v.end(), lambda_1); // requires #include
#else
// if std::for_each algorithm is replaced by a simple loop or
// a direct call to lambda_1 the warning disappears
//for ( auto it = v.begin(); it != v.end();++it) // no warning
//lambda_1(*it);
// or
//lambda_1(v[0]); // no warning
//
// A bit more surprising is that using
// std::ranges::for_each also avoids the warning!
std::ranges::for_each(v, lambda_1); // no warning, requires #include
#endif
}
[Bug target/108866] Allow to pass Windows resource file (.rc) as input to gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866 --- Comment #9 from Pali Rohár --- (In reply to peter0x44 from comment #7) > 5) windres --help has this list of "supported targets": > x86_64-w64-mingw32-windres: supported targets: pe-x86-64 pei-x86-64 > pe-bigobj-x86-64 elf64-x86-64 pe-i386 pei-i386 elf32-i386 elf32-iamcu > elf64-little elf64-big elf32-little elf32-big srec symbolsrec verilog tekhex > binary ihex plugin I reported this particular issue into the binutils bugzilla: https://sourceware.org/bugzilla/show_bug.cgi?id=31543
[Bug middle-end/114449] bswap64 not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114449 Xi Ruoyao changed: What|Removed |Added Keywords||missed-optimization Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-24 --- Comment #4 from Xi Ruoyao --- (In reply to Pali Rohár from comment #2) > Interesting... I was expecting that some -O3 or better -Ofast option tells > gcc to optimize the code as much as possible. Yes this is a bug. I'm only providing some clue about why this happens, not meaning we should rely on some #pragma to get the expected result. But generally unrolling loops too much pessimizes the code, so increase the default unrolling factor is a no-go. We need to invent some cleverer thing for this.
[Bug middle-end/114449] bswap64 not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114449 --- Comment #3 from Pali Rohár --- Note that clang optimizes it just with -O2 and does not require any special pragma.
[Bug middle-end/114449] bswap64 not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114449 --- Comment #2 from Pali Rohár --- Interesting... I was expecting that some -O3 or better -Ofast option tells gcc to optimize the code as much as possible. I added that pragma before for-loop in the first example and then gcc really optimized the code to just bswap instruction.
[Bug middle-end/114449] bswap64 not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114449 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- Adding #pragma GCC unroll 8 for the loop makes it optimized. IIRC by default GCC only unroll loops with a factor of 4 so it's not "fully" unrolled w/o the pragma.
[Bug target/114431] bpf: GCC generates unverifiable code for systemd restrict_fs_bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431 --- Comment #4 from Jose E. Marchesi --- Created attachment 57797 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57797=edit restrict-fs-.bpf.unstripped.i
[Bug target/114431] bpf: GCC generates unverifiable code for systemd restrict_fs_bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431 --- Comment #3 from Jose E. Marchesi --- Created attachment 57796 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57796=edit restrict-ifaces.bpf.unstripped.i
[Bug target/114431] bpf: GCC generates unverifiable code for systemd restrict_fs_bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431 --- Comment #2 from Jose E. Marchesi --- Created attachment 57795 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57795=edit socket-bind.bpf.unstripped.i preprocessed source
[Bug middle-end/114449] New: bswap64 not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114449
Bug ID: 114449
Summary: bswap64 not optimized
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pali at kernel dot org
Target Milestone: ---
https://godbolt.org/z/dc3br9dYT
gcc 13.2 with -O3 does not detect straightforward code for bswap64
functionality. It generates unoptimized code.
uint64_t bswap64_1(uint64_t num) {
uint64_t ret = 0;
for (size_t i = 0; i < sizeof(num); i++) {
ret |= ((num >> (8*(sizeof(num)-1-i))) & 0xff) << (8*i);
}
return ret;
}
Rewriting the code to manually unpack the loop cause that gcc produces
optimized code with single "bswap" instruction on x86-64.
uint64_t bswap64_2(uint64_t num) {
uint64_t ret = 0;
ret |= (((num >> 56) & 0xff) << 0);
ret |= (((num >> 48) & 0xff) << 8);
ret |= (((num >> 40) & 0xff) << 16);
ret |= (((num >> 32) & 0xff) << 24);
ret |= (((num >> 24) & 0xff) << 32);
ret |= (((num >> 16) & 0xff) << 40);
ret |= (((num >> 8) & 0xff) << 48);
ret |= (((num >> 0) & 0xff) << 56);
return ret;
}
Additional -funroll-all-loops argument for the first example does not help and
still produces unoptimized code.
[Bug c++/114439] [14 Regression] icu4c-73.2 build failure: invalid initializer for array member with initialization of array of struct containing arrays since r14-9622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114439 Xi Ruoyao changed: What|Removed |Added Priority|P3 |P1 --- Comment #3 from Xi Ruoyao --- To me this should be a P1 as the compiler is rejecting trivial valid code...
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 Sam James changed: What|Removed |Added Attachment #57792|0 |1 is obsolete|| --- Comment #11 from Sam James --- Created attachment 57794 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57794=edit src_data_test_QualityValues.cpp.ii
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 Sam James changed: What|Removed |Added Attachment #57791|0 |1 is obsolete|| --- Comment #10 from Sam James --- Created attachment 57793 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57793=edit src_data_test_MappedRead.cpp.ii
[Bug middle-end/114448] New: Roundup not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114448 Bug ID: 114448 Summary: Roundup not optimized Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pali at kernel dot org Target Milestone: --- https://godbolt.org/z/4fPKGzs1M Straightforward code which round up unsigned number to the next multiply of 4 is: (num % 4 == 0) ? num : num + (4 - num % 4); gcc -O2 generates: mov edx, edi mov eax, edi and edx, -4 add edx, 4 testdil, 3 cmovne eax, edx ret This is not optimal and branch/test can be avoided by using double modulo: num + (4 - num % 4) % 4; for which gcc -O2 generates: mov eax, edi neg eax and eax, 3 add eax, edi ret Optimal implementation for round up 4 is using bithacks: (num + 3) & ~3; for which gcc -O2 generates: lea eax, [rdi+3] and eax, -4 ret
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #9 from Sam James --- ``` $ gcc -std=c++20 -flto src_data_test_MappedRead.cpp.ii src_data_test_QualityValues.cpp.ii -O1 lto1: error: Alias and target’s comdat groups differs _ZNSt6vectorIN6PacBio4Data12QualityValueESaIS2_EEC2ERKS4_/8 (__ct_base ) Type: function definition analyzed [...] ```
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #8 from Sam James --- Created attachment 57792 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57792=edit src_data_test_QualityValues.cpp.ii
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #7 from Sam James --- Created attachment 57791 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57791=edit src_data_test_MappedRead.cpp.ii
[Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114441
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4 from Xi Ruoyao ---
(In reply to Yang Wang from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > This is not a GCC bug,
> >
> > You need to use -mcmodel=large if you have huge statically allocated arrays.
> >
> > The default -mcmodel=medium does not support more than 2GB size arrays
> >
> > See
> > https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/x86-Options.html#index-
> > mcmodel_003dlarge-3
>
> Thanks for your reply! Indeed, the compilation was successful when either
> the -mcmodel=medium or -mcmodel=large was enabled. However, I'm still
> curious why it can be compiled successfully at the -O3 optimization level
> when the default -mcmodel=small is enabled? As far as I know, the -O3
> optimization level is the highest.
Because the entire `c` function is optimized to empty. Note that `c` always
invokes undefined behavior:
t.cc: In function 'void c()':
t.cc:10:30: warning: iteration 1 invokes undefined behavior
[-Waggressive-loop-optimizations]
10 | a[d][e][f][g][i] = 2;
| ~^~~
t.cc:9:32: note: within this loop
9 | for (size_t i = 0; i < 16; ++i)
| ~~^~~~
So the compiler is allowed to optimize it into nothing.
A test case without undefined behavior:
#include
int a[1][1][1][1][1];
short b[6268435456];
void c() {
a[0][0][0][0][0] = 114514;
}
int main() {}
fails at -O3 too.
Also note that -O levels are for optimizing the *valid* programs, not for
debugging the compiler. It's wrong to report bugs solely because of "different
behaviors with different -O levels" (without analysing the validity of the test
case).
[Bug target/114416] SPARC V9 struct return with floating-point members violates ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #4 from Eric Botcazou --- My reading is that the ABI has overlooked this case though, so it is up to the implementation to make its opinion. That of the vendor's compiler is probably more in line with the spirit of the calling conventions, but GCC's has been so for a quarter of a century now.
[Bug target/114431] bpf: GCC generates unverifiable code for systemd restrict_fs_bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431 --- Comment #1 from Jose E. Marchesi --- $ bpf-gcc --version bpf-gcc (14-20240127-1+1) 14.0.1 20240127 (experimental) [master r14-8465-g5200ef26ac1] Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c/114447] -fstack-protector-explicit ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114447 --- Comment #1 from Andrew Pinski --- Hmm common.opt has: ``` fstack-protector Common Var(flag_stack_protect, 1) Init(-1) Optimization Use propolice as a stack protection method. fstack-protector-all Common RejectNegative Var(flag_stack_protect, 2) Init(-1) Optimization Use a stack protection method for every function. fstack-protector-strong Common RejectNegative Var(flag_stack_protect, 3) Init(-1) Optimization Use a smart stack protection method for certain functions. fstack-protector-explicit Common RejectNegative Var(flag_stack_protect, 4) Optimization Use stack protection method only for functions with the stack_protect attribute. ``` Maybe fstack-protector-explicit is missing `Init(-1)`.
[Bug c/114447] New: -fstack-protector-explicit ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114447
Bug ID: 114447
Summary: -fstack-protector-explicit ignored
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joakim.rosqvist at gmail dot com
Target Milestone: ---
When I compile (gcc -v says 13.2.0-4ubuntu3) this minimal C program to
assembly:
int main(int, char *[])
{
return 0;
}
>gcc -fverbose-asm -S -o foo.s foo.c
I can see in the generated foo.s file that a few extra options were given to
the compiler:
# options passed: -mtune=generic -march=x86-64 -fasynchronous-unwind-tables
-fstack-protector-strong -fstack-clash-protection -fcf-protection
Presumably, these are wisely chosen built-in defaults in gcc.
Now let's add another option to the command line:
>gcc -fno-stack-protector -fverbose-asm -S -o foo.s foo.c
In the generated assembly we now get:
# options passed: -mtune=generic -march=x86-64 -fno-stack-protector
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
I.e. -fno-stack-protector was added and -fstack-protector-strong was removed
as the compiler correctly deduced that these conflict with each other and so
let the user-supplied option "win". Everything is fine so far.
Now, let's compile like so:
>gcc -fstack-protector-explicit -fverbose-asm -S -o foo.s foo.c
The relevant resulting line is:
# options passed: -mtune=generic -march=x86-64 -fstack-protector-explicit
-fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection
-fcf-protection
I.e. this time the compiler did NOT understand that there is a conflict between
-fstack-protector-explicit and builtin -fstack-protector-strong.
The first one should generate stack protection code only for functions with the
stack-protector attribute, while the second one should generate stack
protection code for all functions when possible.
Here -fstack-protector-strong wins and all functions get stack protection
regardless of whether they have the attribute. So the user-supplied option is
effectively ignored.
[Bug ada/114424] gnat: Ada.Calendar.Clock crashes on 32bit architectures with 64bit time_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114424 --- Comment #5 from Eric Botcazou --- Any file whose name contain "posix2008" should be used in lieu of the simple "posix" variant, but that apparently makes only two of them.
