[Bug c/91432] gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 --- Comment #7 from Joe Perches --- What could be useful is to add yet another --extra-strict-fallthrough warning flag that would make it possible for these cases to have a warning.
[Bug c/91432] New: gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
Bug ID: 91432
Summary: gcc -Wimplicit-fallthrough does not warn when
fallthrough to break;
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joe at perches dot com
Target Milestone: ---
This code does not emit a fallthrough warning:
int foo(int i)
{
switch (i) {
case 1:
i = 0;
default:
break;
}
return i;
}
Basically any case block that falls through to another
block of just a break statement does not get a warning.
Is this a defect or what was the logic behind this decision?
[Bug c/80522] New: Enhancement request: __attribute((warn_untested_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80522
Bug ID: 80522
Summary: Enhancement request:
__attribute((warn_untested_result))
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joe at perches dot com
Target Milestone: ---
A possibly useful addition similar to:
__attribute__((warn_unused_result))
might be
__attribute__((warn_untested_result))
for things like allocation failures that
are not verified before use.
For instance:
void *malloc(size_t size);
could become
void * __attribute((warn_untested_result)) malloc(size_t size)
so that
#include
struct foo {
int bar;
};
struct foo *alloc_foo(void)
{
struct foo *baz = malloc(sizeof(struct foo));
baz->bar = 1;
return baz;
}
The compiler could emit a warning on the set
of baz->bar as an intermediate test of baz
is not performed before any use of baz.
struct foo *alloc_foo(void)
{
struct foo *baz = malloc(sizeof(struct foo));
if (baz) baz->bar = 1;
return baz;
}
This variant would not emit a warning.
Similarly, alloc_foo could use that new attribute.
Martin Sebor also mentioned that non-allocation
functions like fopen could also use this __attribute__
mechanism.
[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65812 --- Comment #3 from Joe Perches joe at perches dot com --- Thank you both for your very prompt replies. It might be useful to have a -Wunused-eliminated type extra warning though that might be very noisy.
[Bug c/65812] New: gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65812
Bug ID: 65812
Summary: gcc 4.9.1 doesn't warn about uninitialized variable
use declared in a switch/case statement when compiled
with -O
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joe at perches dot com
Created attachment 35365
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35365action=edit
sample code
Here is a small example:
$ cat t.c
struct foo {
int bar[100];
};
void foo_1(void)
{
unsigned int m;
extern struct foo *array[100];
struct foo *a = array[m];
a = a;
}
void foo_2(void)
{
int i = 1;
switch (i) {
case 1: {
unsigned int m;
extern struct foo *array[100];
struct foo *a = array[m];
a = a;
break;
}
}
}
$
gcc warns properly about both foo_1 and foo_2 without -O
$ gcc -c -Wall t.c
t.c: In function ‘foo_1’:
t.c:9:14: warning: ‘m’ is used uninitialized in this function [-Wuninitialized]
struct foo *a = array[m];
^
t.c: In function ‘foo_2’:
t.c:21:15: warning: ‘m’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
struct foo *a = array[m];
^
$
but gcc warns about foo_1 but not foo_2 with -O
$ gcc -c -Wall -O t.c
t.c: In function ‘foo_1’:
t.c:9:14: warning: ‘m’ is used uninitialized in this function [-Wuninitialized]
struct foo *a = array[m];
^
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.1-16ubuntu6'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6)
[Bug c/42382] New: _Bool foo = bar; vs _Bool foo = foo bar; vs _Bool foo = foo bar; emitted code different
gcc 4.4.1 produces different code for these equivalent inputs.
optimization levels -Os -O2 -O3
It'd be good if the produced code were identical.
#include stdio.h
#include stdlib.h
#include stdbool.h
int main(int argc, char** argv)
{
_Bool foo;
_Bool bar;
foo = !!rand();
bar = !!rand();
foo = bar;
printf(%u %u\n, foo, bar);
foo = !!rand();
bar = !!rand();
foo = foo bar;
printf(%u %u\n, foo, bar);
foo = !!rand();
bar = !!rand();
foo = foo bar;
printf(%u %u\n, foo, bar);
return 0;
}
--
Summary: _Bool foo = bar; vs _Bool foo = foo bar; vs _Bool
foo = foo bar; emitted code different
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joe at perches dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42382
