[Bug c++/29455] Issues with -Wchar-subscripts
--- Comment #7 from h dot b dot furuseth at usit dot uio dot no 2006-10-24 08:20 --- Subject: Re: Issues with -Wchar-subscripts gdr at integrable-solutions dot net writes: > The absence of warning in C is OK -- literal characters have type int > in C. Yes, but see previous comments. > The warning in C++ is arguably bogus because the value of the > character '%' is known at compile-time, consequently the warning > is unwarranted (unless it really is negative). unwarranted unless it _could_ be negative on some host. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug c/30054] New: -Wc++-compat does not catch goto past initialization
gcc -Wc++-compat is quiet about goto crossing/skipping initialization.
g++ says they are errors.
bash$ cat a.c
void foo(void)
{
{
goto bar;
int i = 0; // C++ error
{ int j = 0; } // Not C++ error (just for comparison)
bar:
return;
}
goto bar;
}
bash$ gcc -fsyntax-only -Wc++-compat a.c
bash$ g++ -fsyntax-only a.c
a.c: In function 'void foo()':
a.c:7: error: jump to label 'bar'
a.c:4: error: from here
a.c:5: error: crosses initialization of 'int i'
a.c:7: error: jump to label 'bar'
a.c:10: error: from here
a.c:5: error: skips initialization of 'int i'
--
Summary: -Wc++-compat does not catch goto past initialization
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30054
[Bug other/30055] New: while(__builtin_expect()) pessimizes loop
while(__builtin_expect(len != 0, 1)) below produces a slower
loop than without the __builtin_expect(). It adds a jmp
which makes an extra testl instruction needed in the loop.
__builtin_expect(..., 1) and __builtin_expect(..., 0)
produce the same code in this case, maybe that is relevant.
-fprofile-arcs/-fbranch-probabilities are OK, they produce
the same code as without __builtin_expect().
bash$ cat sum.c
#ifdef E
#define EXPECT(c) __builtin_expect(c, E)
#else
#define EXPECT(c) (c)
#endif
unsigned __attribute__((fastcall, noinline))
Sum(const unsigned *data, unsigned len)
{
unsigned s = 0;
for (; EXPECT(len != 0); len--)
s += *data++;
return s;
}
#ifdef TEST
unsigned data[65536];
int main(void)
{
unsigned i;
for (i = 0; i < 1000; i++)
Sum(data, sizeof (data) / sizeof (*data));
return 0;
}
#endif /* TEST */
bash$ : without __builtin_expect:
bash$ gcc -S -O -fomit-frame-pointer sum.c -o- | sed -ne '/Sum:/,/ret/p'
Sum:
movl$0, %eax
testl %edx, %edx
je .L4
movl$0, %eax
.L5:
addl(%ecx), %eax
addl$4, %ecx
decl%edx
jne .L5
.L4:
ret
bash$ : with __builtin_expect:
bash$ gcc -DE=1 -S -O -fomit-frame-pointer sum.c -o- | sed -ne '/Sum:/,/ret/p'
Sum:
movl$0, %eax
jmp .L2
.L3:
addl-4(%ecx), %eax
decl%edx
.L2:
addl$4, %ecx
testl %edx, %edx
jne .L3
ret
bash$ : time without __builtin_expect:
bash$ gcc -DTEST -O -fomit-frame-pointer sum.c && time ./a.out
real0m0.172s
user0m0.168s
sys 0m0.001s
bash$ : time with __builtin_expect:
bash$ gcc -DE=1 -DTEST -O -fomit-frame-pointer sum.c && time ./a.out
real0m0.254s
user0m0.252s
sys 0m0.001s
--
Summary: while(__builtin_expect()) pessimizes loop
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30055
[Bug other/30055] [4.0/4.1 Regression] while(__builtin_expect()) pessimizes loop
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2006-12-03 15:49 --- Subject: Re: [4.0/4.1 Regression] while(__builtin_expect()) pessimizes loop pinskia at gcc dot gnu dot org writes: > Fixed for 4.2.0: > (...) > Status|UNCONFIRMED |RESOLVED > Resolution||FIXED > Summary|while(__builtin_expect()) |[4.0/4.1 Regression] Hm. When you mark it as [4.0/4.1 Regression], should FIXED mean "fixed for 4.0/4.1"? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30055
[Bug other/30240] New: -fno-inline-functions does not work, and doc bugs
The -f(no-)inline-functions option does not work. Its documented
effect is controlled by -f(no-)inline, both in gcc and g++.
(Don't ask me how that jibes with Bug #27881:-)
The doc says -finline-functions is only invoked by -O3. I suggest
you preserve -O's current functionality: Move -finline-functions
from -O3 to -O and document that (under -fno-inline-functions).
The two first compile commands below work with gcc-3.4.4, but the
third does not:
-fno-inline -finline-functions
does not inline foo().
That's possibly a doc bug: (gcc)Optimize Options says
`-fno-inline'
Don't pay attention to the `inline' keyword. Normally this option
is used to keep the compiler from expanding any functions inline.
(...)
One of these sentences is wrong. Does -fno-inline only mean "ignore
the inline keyword", or does it mean "inline nothing, regardless of
other inlining options or keywords/attributes", or something else?
Doc bugs in Info node (gcc)Inline:
"(If you are writing a header file to be included in ISO C programs,
write `__inline__' instead of `inline'...")
Should now be "ISO C90" programs.
"Some calls cannot be integrated for various reasons (in particular,
calls that precede the function's definition cannot be integrated,..."
Except with -funit-at-a-time. Which is also turned on by -O even though
it's documented as an -O2 option.
$ cat bug.c
static int foo(void){ return 9; }
int bar(void) { return foo(); }
$ gcc -O -fno-inline-functions -S bug.c -o-
.file "bug.c"
.text
.globl bar
.type bar, @function
bar:
pushl %ebp
movl%esp, %ebp
movl$9, %eax
popl%ebp
ret
.size bar, .-bar
.ident "GCC: (GNU) 4.1.1"
.section.note.GNU-stack,"",@progbits
$ gcc -O -fno-inline -S bug.c -o-
.file "bug.c"
.text
.type foo, @function
foo:
pushl %ebp
movl%esp, %ebp
movl$9, %eax
popl%ebp
ret
.size foo, .-foo
.globl bar
.type bar, @function
bar:
pushl %ebp
movl%esp, %ebp
callfoo
popl%ebp
ret
.size bar, .-bar
.ident "GCC: (GNU) 4.1.1"
.section.note.GNU-stack,"",@progbits
$ gcc -O -fno-inline -finline-functions -S bug.c -o-
--
Summary: -fno-inline-functions does not work, and doc bugs
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30240
[Bug other/30240] -fno-inline-functions does not work, and doc bugs
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2006-12-19 11:27 --- Subject: Re: -fno-inline-functions does not work, and doc bugs pinskia at gcc dot gnu dot org writes: > You want -fno-inline-functions-called-once which was added in 4.2.0 > IIRC (...) I see. (Eventually. At first your reply just confused me.) Anyway, then this is a pure doc bug, in addition to the doc problems I already mentioned: -f(no-)inline is not documented to inline functions which do not have the "inline" keyword. And no, what I want is -fno-inline, since I'm not waiting for 4.2.0 to use profiling tools etc. properly with optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30240
[Bug other/30240] -fno-inline-functions does not work, and doc bugs
--- Comment #3 from h dot b dot furuseth at usit dot uio dot no 2006-12-19 11:31 --- Subject: Re: -fno-inline-functions does not work, and doc bugs I just noticed another doc bug: > http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options That page says: -O2 (...) The compiler does not perform (...) function inlining when you specify -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30240
[Bug c/28492] -Wmissing-format-attribute causes warning for vsnprintf()
--- Comment #1 from h dot b dot furuseth at usit dot uio dot no 2007-01-13 18:40 --- The warning is a bit misleading, "function might be possible candidate for 'printf' format attribute" means the _calling_ function might be such a candidate, not the function being called on the line it warns about. The warning is still spurious in this case though, and gcc could tell that: A function cannot be such a candidate if it has a prototype without variable arguments. Here is another example of such a spurious warning: Hallvard -- h dot b dot furuseth at usit dot uio dot no changed: What|Removed |Added CC| |h dot b dot furuseth at usit | |dot uio dot no http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28492
[Bug c/30457] New: Please warn about va_start(ap, invalid)
Here is some undefined behavior which it would be nice if gcc
warned about, since stdarg is such a hairy part of the standard:
#include
void foo(register short paramN, ...)
{
va_list ap;
va_start(ap, paramN); // Undefined by C99 7.15.1.4p4 (va_start):
// "If the parameter parmN is declared with the register storage
// class, with a function or array type, or with a type that is
// not compatible with the type that results after application of
// the default argument promotions, the behavior is undefined."
// gcc does warn about the following, undefined by C99 7.15.1.1p2:
(void) va_arg(ap, char);
// "warning: 'char' is promoted to 'int' when passed through '...'
// warning: (so you should pass 'int' not 'char' to 'va_arg')
// note: if this code is reached, the program will abort"
va_end(ap);
}
--
Summary: Please warn about va_start(ap, invalid)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30457
[Bug preprocessor/38161] New: #elif breaks
#ifndef FOO
#define FOO sizeof(void *)
#elif FOO
#endif
t.c:3:7: error: missing binary operator before token "("
I expect it's caused by the fix to bug #36320.
--
Summary: #elif breaks
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161
[Bug preprocessor/38161] [4.4 regression] #elif breaks
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2008-11-17 20:15 --- Subject: Re: [4.4 regression] #elif breaks Yes, I should have read the #36320 text more carefully. I merely noticed that its empty #elif cannot expand to anything correct, while my example can (and does in the real-life case which produced it). I thought C99 6.10p7 was what saved it: The preprocessing tokens within a preprocessing directive are not subject to macro expansion unless otherwise stated. but maybe not. 6.10.1p3 doesn't say anything about some #elif branches not being evaluated:-( Hopefully that's just overly standard-lawerly though. Maybe comp.std.c would have been a better place to ask. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161
[Bug preprocessor/36123] New: wrong #if 1/-2 and (-1)/2 overflow warnings
gcc dislikes this prefix to a program depending on C99 integer division:
$ cat bug.c
#if 1/-2 || (-1)/2
# error "integer division rounding away from zero not supported"
#endif
$ gcc-4.2.2 -fsyntax-only bug.c
bug.c:1:12: warning: integer overflow in preprocessor expression
bug.c:1:21: warning: integer overflow in preprocessor expression
It doesn't complain about #if 1/2 || (-1)/(-2), nor nonzero expressions
#if 3/-2 || (-3)/2.
(Well, the latter reaches the #error directive of course.)
Checked for gcc 4.2.2, 4.0.2 and 3.4.6.
--
Summary: wrong #if 1/-2 and (-1)/2 overflow warnings
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36123
[Bug middle-end/10138] warn for uninitialized arrays passed as const* arguments
--- Comment #22 from h dot b dot furuseth at usit dot uio dot no 2007-08-20 22:45 --- Subject: Re: warn for uninitialized arrays passed as const* arguments manu at gcc dot gnu dot org writes: > But it seems that the current policy of GCC is to not assume that such > functions actually take this into account, since when optimizing > constants are not propagated beyond a call to such function. This is > either the intended behaviour or a missed-optimisation. > It would be nice if it would be a missed-optimisation. A "const" in a function parameter in C is not a promise to the compiler; it would break the C standard to optimize on it. > Otherwise, if this > is the intended behaviour, then both PRs are invalid as Andrew said. They are requests for warning messages, not error messages, because they are _likely_ to be programmer errors. That's what warnings are for. -Wuninitialized is giving false positives anyway, on code which the compiler cannot tell is correct but the programmer can. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
[Bug c++/29455] New: Issues with -Wchar-subscripts
[This is both a C and C++ bug report, not sure how to classify that.]
int a[256];
int A(char c) { return a[c]; } // C and C++ warnings, OK.
int D(void) { return a['%'];} // Spurious C++ warning, no C warning
int B(void) { return a['å'];} // C++ warning, missing C warning
int C(void) { return a['\300']; } // C++ warning, missing C warning
So,
g++ -Wchar-subscripts warns "array subscript has type 'char'" about
arr['%'] even though the index is guaranteed positive. gcc does not.
OTOH, gcc does not warn about a['\300'] or a['å'] (8-bit a-ring), even
with -fsigned-char which ensures that the subscript is negative.
Note, arr['@'] COULD be a bug in the program with characters like @ which
are not in the basic execution character set: C99 5.2.1p3; I haven't got
the C++ standard. Only characters in that character set are guaranteed
to be positive: C99 6.2.5p3. If the program is intended to be portable
to other character sets, it is buggy. Even if gcc doesn't support a
machine with that charset - if anyone does these days:-) So it might
make sense to have a -Wchar-subscripts=2 warning which only assumes the
basic execution character set, not the current character set.
In preprocessor expressions I don't know if it should check the source
or execution character set, or both...
--
Summary: Issues with -Wchar-subscripts
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug c++/29455] Issues with -Wchar-subscripts
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2006-10-14 17:06 --- Subject: Re: Issues with -Wchar-subscripts -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug c++/29455] Issues with -Wchar-subscripts
--- Comment #3 from h dot b dot furuseth at usit dot uio dot no 2006-10-14
17:52 ---
Subject: Re: Issues with -Wchar-subscripts
Sorry about the empty answer.
pinskia at gcc dot gnu dot org writes:
> 'a' in C is not of the type char but instead int so not warning there
> is correct really.
Hmm, yes, it fits the documentation. I guess what I'm asking is for a
change in the warning's spec. array['8-bit char'] is almost certainly
wrong in an iso646-derived charset, since for a portable program the
programmer can't know if the index is positive or negative. I don't
know if enough information is available in C at the time the warning is
given do do that, though.
> Also you forgot one thing '%' does not have to match up with the ANSI
> character set so it could be negative in signed char which means char
> (which could default to signed char) would be different.
No. In a conforming C implementation, the character *which C interprets
as '%'* must have a positive value. Maybe you are thinking of the
opposite case: What its glyph _looks like_ on some display device is out
of scope for the C standard.
In the 7-bit days we had screens with the Norwegian charset NS_4551-1,
but the C compiler (like most of the American-made computer) thought
it received ASCII. Thus we had to write
main() æ printf("Hello, world!Øn"); return 0; å
for the ASCII compiler to see
main() { printf("Hello, world!\n"); return 0; }
The ANSI Rationale blessed this behavior since it already was
common (and more readable than trigraphs), the example there was
the Yen sign. I can probably dig it up if you are interested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug c++/29455] Issues with -Wchar-subscripts
--- Comment #5 from h dot b dot furuseth at usit dot uio dot no 2006-10-17
12:49 ---
Subject: Re: Issues with -Wchar-subscripts
pinskia at gcc dot gnu dot org writes:
> 'a' in C is not of the type char but instead int so not warning
> there is correct really.
How about a -Warray-bounds option, maybe in -Wall, which tries to
catch array[negative index] and (when the array length is known)
array[too large positive index]? That will also catch array['\300']
when the program meets a host where char is signed.
It'll give false alarms for fake variable-length arrays, but those are
not common and can be replaced with the real thing now. This, I mean:
struct Foo { blah blah; char array[1]; };
struct Foo *foo = malloc(sizeof(struct Foo) + strlen(str));
strcpy(foo->array, str);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug other/29534] New: ICE in "gcc -O -ftrapv" with decreasing array index
bash$ cat bug.c
int foo(int arr[]) {
int i = 2;
while (arr[--i]) ;
return i;
}
bash$ gcc -O -ftrapv -c bug.c
gcc: Internal error: Segmentation fault (program cc1)
bash$ g++ -O -ftrapv -c bug.c
g++: Internal error: Segmentation fault (program cc1plus)
Compilation succeeds if -O is removed. OTOH, it still crashes
with -O -fno-:
bash$ gcc -O -fno-defer-pop -fno-delayed-branch \
-fno-guess-branch-probability -fno-cprop-registers -fno-loop-optimize \
-fno-if-conversion -fno-if-conversion2 -fno-tree-ccp -fno-tree-dce \
-fno-tree-dominator-opts -fno-tree-dse -fno-tree-ter -fno-tree-lrs \
-fno-tree-sra -fno-tree-copyrename -fno-tree-fre -fno-tree-ch \
-fno-merge-constants -fno-omit-frame-pointer \
-ftrapv -c bug.c
gcc: Internal error: Segmentation fault (program cc1)
--
Summary: ICE in "gcc -O -ftrapv" with decreasing array index
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29534
[Bug c/22414] New: assert(i) gives "will never be executed" due to noreturn
assert(i) gives "will never be executed" on Linux.
assert(0) and assert(1) are silent.
I've tried to vary the assert() definition, e.g. give __assert_fail()
return type int and do (void)(i ? 0 : (0 & __assert_fail(...))), but
only removing __attribute__((noreturn)) seems to kill the warning.
I don't want to do that.
gcc configuration:
../gcc-4.0.1/configure --quiet --prefix=/scratch/install
--program-suffix=-4.0.1 --enable-version-specific-runtime-libs
--enable-languages=c,c++
bash$ gcc-4.0.1 -save-temps -fsyntax-only -Wunreachable-code foo.cfoo.c: In
function 'Noisy_a':
foo.c:4: warning: will never be executed
bash$ cat -s foo.i
# 1 "foo.c"
# 1 ""
# 1 ""
# 1 "foo.c"
# 1 "/usr/include/assert.h" 1 3 4
# 36 "/usr/include/assert.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 296 "/usr/include/features.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 297 "/usr/include/features.h" 2 3 4
# 319 "/usr/include/features.h" 3 4
# 1 "/usr/include/gnu/stubs.h" 1 3 4
# 320 "/usr/include/features.h" 2 3 4
# 37 "/usr/include/assert.h" 2 3 4
# 65 "/usr/include/assert.h" 3 4
extern void __assert_fail (__const char *__assertion, __const char *__file,
unsigned int __line, __const char *__function)
__attribute__ ((__noreturn__));
extern void __assert_perror_fail (int __errnum, __const char *__file,
unsigned int __line,
__const char *__function)
__attribute__ ((__noreturn__));
extern void __assert (const char *__assertion, const char *__file, int __line)
__attribute__ ((__noreturn__));
# 2 "foo.c" 2
void Noisy_a(int i) {
((void) ((i) ? 0 : (__assert_fail ("i", "foo.c", 4, __PRETTY_FUNCTION__),
0)));
}
void Silent_b() {
((void) ((0) ? 0 : (__assert_fail ("0", "foo.c", 7, __PRETTY_FUNCTION__),
0)));
}
void Silent_c() {
((void) ((1) ? 0 : (__assert_fail ("1", "foo.c", 10, __PRETTY_FUNCTION__),
0)));
}
--
Summary: assert(i) gives "will never be executed" due to noreturn
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22414
[Bug middle-end/20644] bogus uninitialized warning on unused variable
--- Comment #4 from h dot b dot furuseth at usit dot uio dot no 2005-11-02 19:52 --- I think I'd appreciate that warning when writing portable code: The warning can be useful if the 1 is replaced with a macro which may or may not expand to 1, or an enum defined in an #ifdef, or an implementation-dependent expression like ((char)-1 < 0). But of course, it depends on how many false positives the warning tends to give for normal programs. Maybe there could be a warning option to turn on and off some warnings that do not apply with the particular #defines and constants being used. (And also turn on/off -Wunreachable for this case.) -- h dot b dot furuseth at usit dot uio dot no changed: What|Removed |Added CC| |h dot b dot furuseth at usit | |dot uio dot no http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20644
[Bug c/40530] New: Suggestion: -Wsignless-bitfields
I imagine a bitfield which does not specify 'signed' or 'unsigned'
will often be a bug in user code - maybe the programmer did not
know or did not remember that 'int i:3;' can be unsigned.
I suggest a warning for that in user code. Maybe included in
-Wextra, but I cannot guess how much such correct code is around.
The warning should be quiet about system headers, which may know
how the system compiler treats such bitfields.
--
Summary: Suggestion: -Wsignless-bitfields
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40530
[Bug preprocessor/36887] New: Please report #pragma GCC poison" location
The warning -- Summary: Please report #pragma GCC poison" location Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: h dot b dot furuseth at usit dot uio dot no GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36887
[Bug preprocessor/36887] Please report #pragma GCC poison" location
--- Comment #1 from h dot b dot furuseth at usit dot uio dot no 2008-07-21 11:36 --- Subject: Re: New: Please report #pragma GCC poison" location Sorry about the empty report. Anyway: The warning a.c:2:5: attempt to use poisoned "foo" is not intelligle if one does not know about #pragma GCC poison. (When the poisoning was done by a header file written by someone else.) Please add an additional message foo.h:10: note: "foo" was poisoned here -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36887
[Bug c/37481] New: -pedantic accepts flexible array member = "string" initialization
struct Foo { int i; char a[]; } foo = { 1, "" }; // No warning
struct Bar { int i; char a[]; } bar = { 1, {0} }; // Warning
Line 1 passes -pedantic, but C99 6.7.2.1p16 says it is invalid:
Flexible array members are ignored except with ',', '->',
and for aligning the size of the struct.
Related: Bug 20407: g++ does reject it, even without -pedantic.
--
Summary: -pedantic accepts flexible array member = "string"
initialization
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37481
