https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964
--- Comment #22 from Jiri Slaby ---
(In reply to Andrew Pinski from comment #19)
> *** Bug 106939 has been marked as a duplicate of this bug. ***
Provided that many duplicates (even nested -- see that bug too) -- everyone
expects this to work. W
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 ---
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)
nt: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jirislaby at gmail dot com
Target Milestone: ---
With SUSE's:
> Name: cross-arm-none-gcc14-bootstrap
> Version : 14.2.0+git10526
> Release : 150300.28.1
> Architecture: x86_64
> Install
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=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 #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 #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 #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 #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
Assignee: unassigned at gcc dot gnu.org
Reporter: jirislaby at gmail dot com
Target Milestone: ---
While compiling the kernel (next/master -- 89bf6e28373beef9) with gcc-13, I
see:
drivers/block/mtip32xx/mtip32xx.c:722:25: error: format '%x' expects argument
of type 'unsigned int
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=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
: unassigned at gcc dot gnu.org
Reporter: jirislaby at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Maybe this is simply a dup of bug 77472, but I am not sure what the proper
solution is supposed to be.
In the kernel, when LTO is enabled, we disable flatten
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=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
Jiri Slaby changed:
What|Removed |Added
CC||jirislaby at gmail dot com
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964
--- Comment #16 from Jiri Slaby ---
(In reply to Jakub Jelinek from comment #15)
> lots of them that rely on pointer arithmetics being defined only within the
> same object.
Sure, but the two pointers (taken implicitly of the arrays) are within
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964
--- Comment #14 from Jiri Slaby ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Markus Trippelsdorf from comment #9)
> > Is subtracting undefined, too?
> Yes. Comparing two unrelated arrays or subtracting them is undefined.
But
Assignee: unassigned at gcc dot gnu.org
Reporter: jirislaby at gmail dot com
Target Milestone: ---
I am using
gcc-7 (SUSE Linux) 7.0.0 20161007 (experimental)
from martin liska's
https://build.opensuse.org/project/show/home:marxin:syzkaller
And the kernel does not boot. It is loopin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #15 from Jiri Slaby ---
(In reply to Dmitry Vyukov from comment #14)
> If you apply the latest kcov patch "[PATCH v6] kernel: add kcov code
> coverage", it should work.
Could you please push that to the syzkaller tree [1] then?
[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #12 from Jiri Slaby ---
(In reply to Jiri Slaby from comment #11)
> __sw_hweight32 changes only retval (rax) and parameter (rdi).
... and rdi is stored to and restored from stack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #11 from Jiri Slaby ---
(In reply to Jakub Jelinek from comment #10)
> If you are calling a function (__sw_hweight32) without letting gcc know you
> do that, are you sure that function call does not modify any registers other
> than "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #9 from Jiri Slaby ---
(In reply to Dmitry Vyukov from comment #8)
> First of all, are you sure that r12 is not 0 before the call?
Yes.
> Deference of 0xdc00 is how KASAN reacts on NULL deref, it does
> shadow check befo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #7 from Jiri Slaby ---
(In reply to Dmitry Vyukov from comment #6)
> Also what gcc version?
$ gcc-6 --version
gcc-6 (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670]
> I've tried:
> gcc version 6.0.0 20160105 (exper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #5 from Jiri Slaby ---
(In reply to Jakub Jelinek from comment #4)
> What gcc options are you using on the preprocessed source to trigger this?
By default this:
gcc-6 -nostdinc -fno-strict-aliasing -fno-common -std=gnu89 -mno-sse -mn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #3 from Jiri Slaby ---
Preprocessed code:
http://www.fi.muni.cz/~xslaby/sklad/af_netlink.i
This one results in the code from initial description. I.e. rdx is loaded
before a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #2 from Jiri Slaby ---
Created attachment 37553
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37553&action=edit
__sanitizer_cov_trace_pc implementation
This guys actually changes rdx.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #1 from Jiri Slaby ---
Created attachment 37552
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37552&action=edit
__sw_hweight32 assembly
Assignee: unassigned at gcc dot gnu.org
Reporter: jirislaby at gmail dot com
Target Milestone: ---
I have
commit a8175057d14fa8ff8cc4589edf55a6855d9afdf4
Author: Dmitry Vyukov
Date: Mon Nov 9 19:59:08 2015 +0100
new coverage that uses shared buffer
applied to kernel 4.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65120
--- Comment #1 from Jiri Slaby ---
(In reply to Jiri Slaby from comment #0)
> Better than papering over this as
> "if ((!aa) = b)"
Pardon me, it should write:
"if ((!!aa) = b)"
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jirislaby at gmail dot com
While warning about
"if (!a == b)"
is perfectly fine and I like it, I do not like warning about
"if (!!a = b)"
at all. It gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040
--- Comment #12 from Jiri Slaby ---
(In reply to Marek Polacek from comment #10)
> That's because on your architecture char is signed by default. Try adding
> "unsigned" or using -funsigned-char and the warning should be gone.
Ok, I wanted to m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040
--- Comment #9 from Jiri Slaby ---
What about this?
#include
void x(char *ch)
{
printf("%x\n", ch[10]);
}
It still produces the warning. (I cannot reopen as I am not a reporter.)
34 matches
Mail list logo
