[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;
}
