[Bug c/96739] attribute(constructor) vs format NULL check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96739 --- Comment #3 from Dr. David Alan Gilbert --- Hi Martin, Thanks for the response. I've added a slightly less boiled down test that I think is still valid. I agree with that you say in the case of the call from help_all->help_oneline because cmd and ct are related; however int he original, and new attachment, there's another independent call to help_oneline via help_onecmd->help_oneline where the cmd is argv[1]. So while it's true, that as you say, in the help_all->help_oneline case, if the cmd is NULL then so is ct->name, this is only true for one caller of help_oneline.
[Bug c/96739] attribute(constructor) vs format NULL check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96739 --- Comment #2 from Dr. David Alan Gilbert --- Created attachment 49108 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49108&action=edit less boiled down test
[Bug c/96739] New: attribute(constructor) vs format NULL check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96739 Bug ID: 96739 Summary: attribute(constructor) vs format NULL check Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dgilbert at redhat dot com Target Milestone: --- Created attachment 49096 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49096&action=edit boiled down test file The following is boiled down (too far?) from current (d6f83a72a7db94a3ede9f5cc4fb39f9c8e89f954) qemu-io-cmds.c and generates the warning: ioprob.c:28:5: warning: ‘%s’ directive argument is null [-Wformat-overflow=] 28 | printf("%s ", ct->name); | ^~~ unless the __attribute((constructor)) is removed from init_qemuio_commands I think the problem here is that ct comes from cmdtab which is a static and it doesn't notice that it's initialised, and therefore decides it's NULL? cc -O1 -Wformat -Wformat-security -c ioprob.c -Wunused In function ‘help_oneline’, inlined from ‘help_all’ at ioprob.c:34:5, inlined from ‘help_f’ at ioprob.c:39:5: ioprob.c:28:5: warning: ‘%s’ directive argument is null [-Wformat-overflow=] 28 | printf("%s ", ct->name); | ^~~ [dgilbert@dgilbert-t580 try]$ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.1 20200723 (Red Hat 10.2.1-1) (GCC)
[Bug c/89990] New: request warning: Use of out of bound compound initialised struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990 Bug ID: 89990 Summary: request warning: Use of out of bound compound initialised struct Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dgilbert at redhat dot com Target Milestone: --- gcc version 9.0.1 20190312 (Red Hat 9.0.1-0.10) (GCC) on Fedora 30, x86-64 We tripped over code like this in qemu which seems obvious enough that a warning would be nice: int foo(mytype *ptr) { if (!ptr) { ptr = &(mytype) { }; } if (ptr->p) } which worked OK on gcc 8, but seg'd on gcc 9 because ptr->p contained rubbish since the compiler had noticed that the &() { }; went out of scope at the end of the if. So a warning would be nice if: a) A pointer is initialised to point to an initialiser like that b) That goes out of scope c) The pointer is then unconditionally used. The original qemu code is: https://git.qemu.org/?p=qemu.git;a=blob;f=tests/libqos/qgraph.c;h=122efc1b7b8413bc69d81f2906c89f06eccd994a;hb=HEAD#l75 75 static void add_edge(const char *source, const char *dest, 76 QOSEdgeType type, QOSGraphEdgeOptions *opts) 77 { 78 char *key; 79 QOSGraphEdgeList *list = g_hash_table_lookup(edge_table, source); 80 81 if (!list) { 82 list = g_new0(QOSGraphEdgeList, 1); 83 key = g_strdup(source); 84 g_hash_table_insert(edge_table, key, list); 85 } 86 87 if (!opts) { 88 opts = &(QOSGraphEdgeOptions) { }; 89 } 90 91 QOSGraphEdge *edge = g_new0(QOSGraphEdge, 1); 92 edge->type = type; 93 edge->dest = g_strdup(dest); 94 edge->edge_name = g_strdup(opts->edge_name ?: dest); 95 edge->arg = g_memdup(opts->arg, opts->size_arg);
[Bug c++/78014] -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014 Dr. David Alan Gilbert changed: What|Removed |Added CC||dgilbert at redhat dot com --- Comment #7 from Dr. David Alan Gilbert --- A similar variant is: #include int main(int argc, char *argv[]) { size_t s = 42; printf("%d\n", s); } t.c:7:12: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘size_t {aka long unsigned int}’ [-Wformat=] printf("%d\n", s); ~^ %ld I'd expect it to be suggesting %zd here. The difference in this case is it's already generating a warning - just not the one I'd expect (and it already knows it's size_t).
[Bug middle-end/80346] pessimistic stringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346 --- Comment #9 from Dr. David Alan Gilbert --- (In reply to Paolo Bonzini from comment #8) > g_assertion_message_cmpnum is not declared anymore as noreturn since glib > 2.38. > https://bugzilla.gnome.org/show_bug.cgi?id=692125 :-O !!!? Oh in that case, that one isn't a gcc bug I guess.
[Bug middle-end/80346] pessimistic stringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346 --- Comment #7 from Dr. David Alan Gilbert --- (In reply to Martin Sebor from comment #6) > The reduced test case from comment #4 doesn't trigger a warning because in > it the value of n is unknown. The original test case does trigger it > because in it n's range is known. This is evident from the VRP dump which > shows: > > Value ranges after VRP: > > __n_5: ~[1, 18446744071562067967] > ... > test_acpi_piix4_tcg () > { > ... > g_assertion_message_cmpnum (0B, "bug2.c", 59, &__func__, "tables_nr > 0", > _71, ">", 0.0, 105); > __n_5 = (gsize) tables_nr_69; > __p_58 = g_malloc0_n (__n_5, 4); > > > The anti-range implies that the variable's value is either zero or greater > than 18446744071562067967 (0x7fff) so the allocation request is > either for zero bytes or some positive multiple of the excessive size. > Since zero is not considered a valid size (unless it's constant) and > 18446744071562067967 is too big the warning triggers. > > The inlining context of the call is shown in the full output of the warning. > It might help shed light on where the range comes from. > > In function ‘test_acpi_rsdt_table’, > inlined from ‘test_acpi_one.constprop’ at pr80346-2.c:19334:5, > inlined from ‘test_acpi_piix4_tcg’ at pr80346-2.c:19346:5: > pr80346-2.c:19319:59: warning: argument 1 range [18446744071562067968, > 18446744073709551615] exceeds maximum object size 9223372036854775807 > [-Walloc-size-larger-than=] > / __s)) __p = g_malloc0 (__n * __s); else __p = g_malloc0_n > (__n, __s); __p; })); > > ^~~~ The original code is here: http://git.qemu-project.org/?p=qemu.git;a=blob;f=tests/bios-tables-test.c;h=88dbf9785353d6ac82a7000357d4bd4c658319e7;hb=HEAD#l96 (I had boiled it down a bit for this) but what confuses me is we start if with 'tables_nr' which is an int This is x86 - so it's 32bit we then do an assert to guarantee it's positive -> So the possible range is now 0..0x7fff Then I expect it gets multiplied by sizeof(uint32_t) -> Range is now 0..0x1ffc the range gcc's warning us about looks like it sign extended a -ve 32bit integer - but our assert makes sure that can't happen.
[Bug middle-end/80346] pessimistic stringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346 --- Comment #2 from Dr. David Alan Gilbert --- Created attachment 41147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41147&action=edit a different signed/size case Here's another case (law said to attach it to the same bug), this is giving: In function ‘test_acpi_rsdt_table’, inlined from ‘test_acpi_one.constprop’ at bug2a.c:19334:5, inlined from ‘test_acpi_piix4_tcg’ at bug2a.c:19346:5: bug2a.c:19319:59: error: argument 1 range [18446744071562067968, 18446744073709551615] exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=] / __s)) __p = g_malloc0 (__n * __s); else __p = g_malloc0_n (__n, __s); __p; })); ^~~~ bug2a.c: In function ‘test_acpi_piix4_tcg’: bug2a.c:6004:10: note: in a call to allocation function ‘g_malloc0_n’ declared here gpointer g_malloc0_n (gsize n_blocks, ^~~ this is the preprocessed output of the original and that error was: In file included from /usr/include/glib-2.0/glib/glist.h:32:0, from /usr/include/glib-2.0/glib/ghash.h:33, from /usr/include/glib-2.0/glib.h:50, from /home/dgilbert/git/qemu/include/glib-compat.h:19, from /home/dgilbert/git/qemu/include/qemu/osdep.h:107, from bug2.c:13: In function ‘test_acpi_rsdt_table’, inlined from ‘test_acpi_one.constprop’ at bug2.c:80:5, inlined from ‘test_acpi_piix4_tcg’ at bug2.c:98:5: /usr/include/glib-2.0/glib/gmem.h:216:10: error: argument 1 range [18446744071562067968, 18446744073709551615] exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=] __p = g_##func##_n (__n, __s); \ ^ /usr/include/glib-2.0/glib/gmem.h:278:42: note: in expansion of macro ‘_G_NEW’ #define g_new0(struct_type, n_structs) _G_NEW (struct_type, n_structs, malloc0) ^~ bug2.c:62:14: note: in expansion of macro ‘g_new0’ tables = g_new0(uint32_t, tables_nr); ^~ bug2.c: In function ‘test_acpi_piix4_tcg’: /usr/include/glib-2.0/glib/gmem.h:96:10: note: in a call to allocation function ‘g_malloc0_n’ declared here gpointer g_malloc0_n (gsize n_blocks, ^~~ but immediately before that g_new0 we have a : g_assert_cmpint(tables_nr, >, 0); and the range it's complaing about is 8000 and which is very odd. For ref this is the tests/bios-tables-test.c from qemu.
[Bug c/80346] New: pessimistic stringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346 Bug ID: 80346 Summary: pessimistic stringop-overflow Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dgilbert at redhat dot com Target Milestone: --- Created attachment 41146 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41146&action=edit source file that triggers warning The attached code (from QEMU's test suite) triggers the following warning - I wonder if this is the same as pr 79095 ? In file included from /usr/include/string.h:639:0, from cut-down.c:4: In function ‘memcpy’, inlined from ‘iov_from_buf.constprop’ at cut-down.c:49:9, inlined from ‘test_to_from_buf_1’ at cut-down.c:128:14, inlined from ‘test_to_from_buf’ at cut-down.c:143:9: /usr/include/bits/string3.h:53:10: error: ‘__builtin_memcpy’: specified size 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); ^~ In function ‘memcpy’, inlined from ‘iov_to_buf.constprop’ at cut-down.c:62:9, inlined from ‘test_to_from_buf_1’ at cut-down.c:134:14, inlined from ‘test_to_from_buf’ at cut-down.c:143:9: /usr/include/bits/string3.h:53:10: error: ‘__builtin_memcpy’: specified size 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); from Fedora 26's: Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 7.0.1 20170309 (Red Hat 7.0.1-0.12) (GCC) I have some sympathy for the -1 size_t cast and it's worrying that (size_t)-1 <= iov_len could be true ???
[Bug c/69825] False -Wdiv-by-zero warning when it should be short-circuited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69825 --- Comment #1 from Dr. David Alan Gilbert --- Oops, forgot to mention; this is on fedora 23 x86-64.
[Bug c/69825] New: False -Wdiv-by-zero warning when it should be short-circuited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69825 Bug ID: 69825 Summary: False -Wdiv-by-zero warning when it should be short-circuited Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dgilbert at redhat dot com Target Milestone: --- gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) $ cat bug.c void bug(void) { static unsigned int counter = 0; static const unsigned int frequency = 0; if (frequency && (!(counter % frequency))) { } counter++; } $ gcc bug.c -Wall -c -O2 bug.c: In function ‘bug’: bug.c:6:33: warning: division by zero [-Wdiv-by-zero] if (frequency && (!(counter % frequency))) { ^ I'm told it also triggers on trunk, 4.6, 5.3 but not 4.8.5
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64614 --- Comment #8 from Dr. David Alan Gilbert --- Richard: Thanks for the fix, and apologies again for my screwed up regression test.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64614 Dr. David Alan Gilbert changed: What|Removed |Added Summary|bogus used initialized |bogus used initialized |warning (in gcc 4.9.2 not |warning (in gcc 4.9.2); |in 4.8.3); switch statement |switch statement versus & |versus &| --- Comment #4 from Dr. David Alan Gilbert --- Apologies, yes, you're right, it does also do it on 4.8.3. Sorry again, I think I probably missed either the -O or -Wall when I tried to reproduce on 4.8.3.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64614 --- Comment #2 from Dr. David Alan Gilbert --- (In reply to Marek Polacek from comment #1) > We have tons of these -W*uninitialized bugs, so there's likely a dup. Yep, it's possible - I couldn't find an obvious match; but two things to note that might make this case easier to track down: a) It seems a regression from 4.8.3 to 4.9.2 b) To me it seems specific to the if/switch combination Dave
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64614 Bug ID: 64614 Summary: bogus used initialized warning (in gcc 4.9.2 not in 4.8.3); switch statement versus & Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dgilbert at redhat dot com gcc t.c -O1 -Wall -Wextra (Any -O value 1 or above) t.c: In function ‘foo’: t.c:15:15: warning: ‘tmp’ may be used uninitialized in this function [-Wmaybe-uninitialized] tmp[11] = 15; ^ (This code is similar to qemu's arch_init.c/ram_load loop where I hit this) Gcc doesn't seem to be spotting that the tmp = baz initialiser will always happen for the switch cases that use tmp. this is using the Fedora 21 gcc: gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC) package: gcc-4.9.2-1.fc21.x86_64 It doesn't trigger for me on gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) char *foo(int bar, char *baz) { char *tmp; if (bar & 3) { tmp = baz; } switch (bar) { case 1: tmp[5] = 7; break; case 2: tmp[11] = 15; break; default: tmp = 0; break; } return tmp; }