https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
Jiri Slaby changed:
What|Removed |Added
CC||jirislaby at gmail dot com
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #12 from Jiri Slaby ---
(In reply to Jiri Slaby from comment #11)
> Looking at the kernel patch, it says:
> This is fixed now in gcc, but work around it on older compilers
> by using a wrapper.
>
> If so, how was this fixed a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #14 from Jiri Slaby ---
(In reply to Richard Biener from comment #13)
> The testcase still does not work on master or with 12.2, thus reconfirmed.
Hmm:
(In reply to Martin Liška from comment #0)
> Noticed by Andi Kleen in kernel, re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
Bug ID: 107014
Summary: flatten+lto
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #4 from Jiri Slaby ---
(In reply to Alexander Monakov from comment #3)
> It was added to force inlining of small helpers that outgrow limits when
> building with gcov profiling:
(with clang)
> I am surprised that "flatten" blows up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #6 from Jiri Slaby ---
(In reply to Alexander Monakov from comment #5)
> I mean now, about compile time blowup with LTO.
No, LTO is not supported by upstream (yet) ;).
The point is what should I do when submitting the LTO support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405
Bug ID: 107405
Summary: enums can be long in gcc-13
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405
--- Comment #1 from Jiri Slaby ---
(In reply to Jiri Slaby from comment #0)
> Reduced testcase:
> #include
> enum { A = 0x, B = 1 << 31, };
> int main() { printf("%lx %x %zu\n", A, B, sizeof(B)); }
It's also interesting to me, that A i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405
--- Comment #4 from Jiri Slaby ---
(In reply to Martin Liška from comment #3)
> > enum { A = 0x, B = 1 << 31, };
> > int main() { printf("%lx %x %zu\n", A, B, sizeof(B)); }
> >
>
> Apparently, 0x is treated by the compiler as u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405
--- Comment #5 from Jiri Slaby ---
(In reply to Jiri Slaby from comment #4)
> Also sizeof of that enum
> (if one gives it a name) is 8 with gcc-13. That is not allowed by the
> standard, IMO.
I'm correcting myself, this was always the case and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405
--- Comment #7 from Jiri Slaby ---
(In reply to Jakub Jelinek from comment #6)
> That is how C++ behaves for years and C2X mandates such behavior too.
> Enumerators that don't fit into int were a GNU extensions (-pedantic-errors
> rejects them)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405
--- Comment #10 from Jiri Slaby ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Jiri Slaby from comment #4)
> > Another question is why B is affected by A at all? Also sizeof of that enum
> > (if one gives it a name) is 8 with g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405
--- Comment #11 from Jiri Slaby ---
(In reply to Jiri Slaby from comment #10)
> Ah, that's correct. So the question then is: is it a feature we can rely on
> (even if undocumented -- can the behavior can be documented in gcc?), or we
> should dr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116627
Bug ID: 116627
Summary: armv6l: ICE in kernel's net/ipv4/ipmr.c
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116627
--- Comment #1 from Jiri Slaby ---
Created attachment 59058
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59058&action=edit
preprocessed source (compressed as it is 4.4M)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116627
Jiri Slaby changed:
What|Removed |Added
Known to work||13.3.1
--- Comment #2 from Jiri Slaby ---
16 matches
Mail list logo
