[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)
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 drop enum uses for values > MAX_INT? I think section 4.9 of gcc manual actually defines this: The integer type compatible with each enumerated type (C90 6.5.2.2, C99 and C11 6.7.2.2). Normally, the type is unsigned int if there are no negative values in the enumeration, otherwise int. So as long as all are unsigned, all is fine. So it remains to define what happens when there is an u/long (the case above).
[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)
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 gcc-13. That is not allowed by the
> > standard, IMO.
>
> C99, C11, and C17 all say:
>
> "The expression that defines the value of an enumeration constant shall be
> an integer
> constant expression that has a value representable as an int."
>
> So enum { A = 0x } is a constraint violation and not allowed by the
> standard anyway. Such code was always non-conforming and relying on an
> (undocumented?) GCC extension, so the standard has nothing to say about the
> type.
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 drop enum uses for values > MAX_INT?
[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)
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) and for C have been handled weirdly in the past (only specific
> enumerators that don't fit had wider types + the enum as whole).
> enum E { A = 0xdeadbeefcafebabeULL, B = 2 };
> int a = sizeof (enum E);
> int b = sizeof (A);
> int c = sizeof (B);
> above yielded a = 8, b = 8, c = 4 in C, a = b = c = 8 in C++ and now in GCC
> 13 in C too.
No problem having this in C2X. I'm not complaining about this feature. But
well, why does it happen in kernel's gnu11 (and in the example above too)? I
mean, I likely can fix the ata enum to be 1U << 31 (using BIT()) and alike so
that it all stays within uint. But how'd you propose to fix this:
(In reply to Martin Liška from comment #2)
> Note there's a similar issue I sent patch for:
> https://lore.kernel.org/all/f70c7a11-e81e-f6b9-a403-315117f4a...@suse.cz/
? I.e. how to %-format "B" in your example for both gcc-12 (c == 4) and gcc-13
(c == 8).
[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)
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 is not new in 13. With -pedantic, I can see at last: x.c:3:13: warning: ISO C restricts enumerator values to range of ‘int’ [-Wpedantic]
[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)
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 unsigned int constant
> and thus it likely leads to the promotion to a longer interger.
The problem is that is breaks existing code (which will be barely fixed as this
is clearly gcc-13's bug (or change of behavior at least)).
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 gcc-13. That is not allowed by the standard,
IMO.
[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)
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 is long even with gcc-12...
[Bug c/107405] New: enums can be long in gcc-13
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: 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', but argument 3 has type 'long in' [-Werror=format=]
That is:
enum {
Many members, see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/ata.h?id=4dc12f37a8e98e1dca5521c14625c869537b50b6#n25
};
...
#define PORT_IRQ_HANDLED \
(PORT_IRQ_SDB_FIS | PORT_IRQ_LEGACY | \
PORT_IRQ_TF_ERR | PORT_IRQ_IF_ERR | \
PORT_IRQ_CONNECT | PORT_IRQ_PHYRDY)
...
u32 port_stat;
...
dev_warn(>pdev->dev,
"Port stat errors %x unhandled\n",
(port_stat & ~PORT_IRQ_HANDLED));
So port_stat is uint, ~PORT_IRQ_HANDLED is derived from enum, which should be
int from standard.
Reduced testcase:
#include
enum { A = 0x, B = 1 << 31, };
int main() { printf("%lx %x %zu\n", A, B, sizeof(B)); }
$ gcc-13 -std=gnu99 x.c -Wall -O2 && ./a.out
x.c: In function ‘main’:
x.c:3:27: warning: format ‘%x’ expects argument of type ‘unsigned int’, but
argument 3 has type ‘long int’ [-Wformat=]
3 | int main() { printf("%lx %x %zu\n", A, B, sizeof(B)); }
| ~^~
| ||
| unsigned int long int
| %lx
8000 8
$ gcc-12 -std=gnu11 x.c -Wall -O2 && ./a.out
8000 4
[Bug lto/107014] flatten+lto fails the kernel build
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. Disabling flatten in the kernel completely does not sound about right. I wanted to confirm that this is not a compiler issue -- you guys say the function shoots to its leg by __flatten__. So thinking about the best approach...
[Bug lto/107014] flatten+lto fails the kernel build
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 on this function. Is that with any > config, or again some specific settings like gcov? Is there an existing lkml > thread about this? Yes, linked in the commit log: https://lore.kernel.org/all/cak8p3a2zwfnexksm8k_suhhwkor17jfo3xaplxjzfpqx0eu...@mail.gmail.com/
[Bug lto/107014] New: flatten+lto
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 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 completely, so that the build is able to finish -- in ~ 2 minutes, w/ 4G of RAM. With flatten enabled, the build didn't finish in 10 minutes, eating 40G of RAM at that point. There is only a single user of flatten in the kernel: pcpu_build_alloc_info(). Here: https://github.com/torvalds/linux/blob/bf682942cd26ce9cd5e87f73ae099b383041e782/mm/percpu.c#L2852-L2855 And that on its own makes the link not to finish in a reasonable time, with reasonable RAM. I suppose much inlining happens in such a long function. But: shouldn't really there be any limit? I am going to link this bug in the commit message disabling flatten on LTO, so that we have a reference of why/how...
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
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, reduced to:
>
> $ cat 1.i
> __attribute__((__always_inline__)) void *memcpy();
> void *foo = memcpy;
Provided I cannot reproduce on the current kernel, where exactly does this come
from?
I see:
arch/x86/include/asm/string_64.h:
#define __HAVE_ARCH_MEMCPY 1
extern void *memcpy(void *to, const void *from, size_t len);
extern void *__memcpy(void *to, const void *from, size_t len);
===
For KASAN also:
#if defined(CONFIG_KASAN) && !defined(__SANITIZE_ADDRESS__)
#undef memcpy
#define memcpy(dst, src, len) __memcpy(dst, src, len)
===
arch/x86/lib/memcpy_64.S:
SYM_FUNC_START(__memcpy)
...
SYM_FUNC_END(__memcpy)
...
SYM_FUNC_ALIAS_WEAK(memcpy, __memcpy)
===
$ nm ../lto/vmlinux|grep -wE '__memcpy|memcpy'
81dcf0b0 T __memcpy
81dcf0b0 W memcpy
===
arch/x86/lib/memcpy_32.c:
__used __visible void *memcpy(void *to, const void *from, size_t n)
{
return __memcpy(to, from, n);
}
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
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 an when (in what version)? FWIW it builds with the patch reverted using gcc 12.
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 Jiri Slaby changed: What|Removed |Added CC||jirislaby at gmail dot com --- Comment #11 from Jiri Slaby --- 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 an when (in what version)?
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
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 the same object. So I do not see, why it wouldn't work? I.e. where exactly this breaks the C specs?
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
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 they are not unrelated arrays. So what from the C standard actually makes (and allows) gcc think they are unrelated? And given gcc 7 is to be released yet, can we have a switch to disable this optimization?
[Bug middle-end/77981] New: gcc 7 miscompiles kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77981
Bug ID: 77981
Summary: gcc 7 miscompiles kernel
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
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 looping and page faulting inside
get_builtin_firmware:
{
#ifdef CONFIG_FW_LOADER
struct builtin_fw *b_fw;
for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
if (!strcmp(name, b_fw->name)) {
cd->size = b_fw->size;
cd->data = b_fw->data;
return true;
}
}
#endif
return false;
}
But
$ nm vmlinux-4.8.1-* |grep __.*_builtin_fw
81ac2158 R __end_builtin_fw
81ac2158 R __start_builtin_fw
And sure, the test b_fw != __end_builtin_fw seems to be removed from the code:
81049d20 :
81049d20: e8 fb bb 68 00 callq 816d5920
<__fentry__>
81049d25: 41 54 push %r12
81049d27: 49 89 fcmov%rdi,%r12
81049d2a: 55 push %rbp
81049d2b: 48 89 f5mov%rsi,%rbp
81049d2e: 53 push %rbx
81049d2f: 48 c7 c3 58 21 ac 81mov$0x81ac2158,%rbx
81049d36: eb 04 jmp81049d3c
<get_builtin_firmware+0x1c>
81049d38: 48 83 c3 18 add$0x18,%rbx
81049d3c: 48 8b 33mov(%rbx),%rsi
81049d3f: 48 89 efmov%rbp,%rdi
81049d42: e8 d9 3d 36 00 callq 813adb20
81049d47: 85 c0 test %eax,%eax
81049d49: 75 ed jne81049d38
<get_builtin_firmware+0x18>
81049d4b: 48 8b 43 10 mov0x10(%rbx),%rax
81049d4f: 49 89 44 24 08 mov%rax,0x8(%r12)
81049d54: 48 8b 43 08 mov0x8(%rbx),%rax
81049d58: 5b pop%rbx
81049d59: 5d pop%rbp
81049d5a: 49 89 04 24 mov%rax,(%r12)
81049d5e: b8 01 00 00 00 mov$0x1,%eax
81049d63: 41 5c pop%r12
81049d65: c3 retq
81049d66: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1)
81049d6d: 00 00 00
gcc-6 produces this:
81ac2230 R __end_builtin_fw
81ac2230 R __start_builtin_fw
and (chopped)
81049e39: 48 c7 c3 30 22 ac 81mov$0x81ac2230,%rbx
81049e40: 48 81 fb 30 22 ac 81cmp$0x81ac2230,%rbx
81049e47: 74 3f je 81049e88
<get_builtin_firmware+0x58>
The 'if' ^
81049e49: 48 89 f5mov%rsi,%rbp
81049e4c: 49 89 fcmov%rdi,%r12
81049e4f: eb 0d jmp81049e5e
<get_builtin_firmware+0x2e>
81049e51: 48 83 c3 18 add$0x18,%rbx
81049e55: 48 81 fb 30 22 ac 81cmp$0x81ac2230,%rbx
81049e5c: 74 2a je 81049e88
<get_builtin_firmware+0x58>
81049e5e: 48 8b 33mov(%rbx),%rsi
81049e61: 48 89 efmov%rbp,%rdi
81049e64: e8 f7 1e 36 00 callq 813abd60
81049e69: 85 c0 test %eax,%eax
81049e6b: 75 e4 jne81049e51
<get_builtin_firmware+0x21>
[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel
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 -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -pipe -fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0 -fstack-protector -Wno-unused-but-set-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -fasynchronous-unwind-tables -pg -mfentry -fno-inline-functions-called-once -fno-strict-overflow -fconserve-stack -fsanitize=kernel-address -fasan-shadow-offset=0xdc00 --param asan-stack=1 --param asan-globals=1 --param asan-instrumentation-with-call-threshold=1 -fsanitize-coverage=trace-pc -S -o - af_netlink.i And this simplified one produces the same around the call: gcc-6 -nostdinc -O2 -std=gnu89 -fsanitize=kernel-address -fasan-shadow-offset=0xdc00 --param asan-stack=1 --param asan-globals=1 --param asan-instrumentation-with-call-threshold=1 -fsanitize-coverage=trace-pc -S -o - af_netlink.i
[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel
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 before the memory accesses. If original address is NULL, the > shadow check will go to 0xdc00. I see such GPFs quite > frequently, so that's what I would assume first. I know, I thought so first too. But later, I debugged that to a gcc bug :). > If you just switched to gcc6, then it can be some latent bug (undefined > behavior), which started to fire with a new compiler. W/ CONFIG_KCOV=n (i.e. no -fsanitize-coverage), it works, apparently.
[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel
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 (experimental) (GCC) > $ gcc /tmp/af_netlink.c -c -O2 -fsanitize-coverage=trace-pc > -fsanitize=kernel-address --param asan-stack=1 --param asan-globals=1 > --param asan-instrumentation-with-call-threshold=1 > -fasan-shadow-offset=0xdc00 With this I see that too: movq%r12, %rdx #APP # 28 "../arch/x86/include/asm/arch_hweight.h" 1 661: call __sw_hweight32 662: #...more ALTINST crap #NO_APP addl720(%rbx), %eax shrq$3, %rdx movl%eax, %r13d movabsq $-2305847407260205056, %rax cmpb$0, (%rdx,%rax)
[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel
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.
[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel
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 "flags" and "rax"? Not at all, I suppose. See attachment #37552. __sw_hweight32 changes only retval (rax) and parameter (rdi). But __sw_hweight32 proper is as well instrumented by the coverage hook. And it changes whatever... In any way, what is the proper way of annotating asm() directive when there is a call inside?
[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel
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://github.com/dvyukov/linux/commits/kcov
[Bug c/69624] New: sanitize-coverage=trace-pc miscompiles kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624 Bug ID: 69624 Summary: sanitize-coverage=trace-pc miscompiles kernel Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jirislaby at gmail dot com Target Milestone: --- I have commit a8175057d14fa8ff8cc4589edf55a6855d9afdf4 Author: Dmitry Vyukov <dvyu...@google.com> Date: Mon Nov 9 19:59:08 2015 +0100 new coverage that uses shared buffer applied to kernel 4.4. I am seeing crashes in netlink_bind at 0xd5dc: d5bd: 4c 89 e2mov%r12,%rdx d5c0: e8 00 00 00 00 callq d5c5 <netlink_bind+0x485> d5c1: R_X86_64_PC32 __sw_hweight32-0x4 d5c5: 03 83 d0 02 00 00 add0x2d0(%rbx),%eax d5cb: 48 c1 ea 03 shr$0x3,%rdx d5cf: 41 89 c5mov%eax,%r13d d5d2: 48 b8 00 00 00 00 00movabs $0xdc00,%rax d5d9: fc ff df d5dc: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) because rdx is 0. rdx is fetched from r12, then __sw_hweight32 is called, it zeroes rdx and (%rdx,%rax,1) dereference is then rax == 0xdc00 dereference which leads to a crash.
[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel
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=edit __sw_hweight32 assembly
[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel
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=edit __sanitizer_cov_trace_pc implementation This guys actually changes rdx.
[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel
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.
[Bug c/65120] New: [gcc5] Wlogical-not-parentheses should not wanr about double exclamation !!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65120 Bug ID: 65120 Summary: [gcc5] Wlogical-not-parentheses should not wanr about double exclamation !! Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: 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 generates plenty of false positives (in the Linux kernel at least) and I doubt it can warn about an error at all. Better than papering over this as if ((!aa) = b) or by -Wno-logical-not-parentheses does not make much sense to me (opposing to the single ! case). Note: this is all about: logical not is only applied to the left hand side of comparison
[Bug c/65120] [gcc5] Wlogical-not-parentheses should not warn about double exclamation !!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65120 --- Comment #1 from Jiri Slaby jirislaby at gmail dot com --- (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)
[Bug c/65040] [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040
--- Comment #9 from Jiri Slaby jirislaby at gmail dot com ---
What about this?
#include stdio.h
void x(char *ch)
{
printf(%x\n, ch[10]);
}
It still produces the warning. (I cannot reopen as I am not a reporter.)
[Bug c/65040] [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040 --- Comment #12 from Jiri Slaby jirislaby at gmail dot com --- (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 make sure, that the format string is really wrong here. It should be %hhx. Ouch, that will be pain to fix all those 400 bad format strings in grub2, given they use Werror WFormat :D.
