atus: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msebor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40261
--- Comment #1 from msebor at gmail dot com 2009-09-12 23:33 ---
Code involving bool variables is similarly suboptimal:
$ cat t.cpp && gcc -O2 -S t.cpp && cat t.s
bool foo (bool a, bool b) {
return a && b || !a && !b;
}
bool bar (boo
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msebor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41423
--
msebor at gmail dot com changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41423
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msebor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41540
--- Comment #2 from msebor at gmail dot com 2009-10-02 16:39 ---
I don't have a strong objection to not including __FILE__ and the rest of
standard predefined macros (e.g., __LINE__, __DATE__ and __TIME__) in the
output if that's by design but I would expect the documentation
--- Comment #4 from msebor at gmail dot com 2009-10-02 18:00 ---
I understand that the values of __FILE__ and __LINE__ change within the same
translation unit and thus may not be meaningful in the output of -dM -E. But
the values of __DATE__ and __TIME__ do not change within a
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msebor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41561
--- Comment #2 from msebor at gmail dot com 2009-10-04 16:08 ---
I'm not positive which stage issues the warning but the preprocessor does not
warn on large integer literals in preprocessor directives involving integer
arithmetic (e.g., #if 0x123456789abcd > LONG_MAX).
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msebor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41672
ow warning on function argument in local
class
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msebor
n: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msebor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47931
Summary: missing -Waddress warning for comparison with NULL
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: una
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47931
--- Comment #1 from Martin Sebor 2011-02-28 19:38:15
UTC ---
To add a suggested solution to my report: Since many (most?) comparisons will
be against NULL which can be defined as either 0 or (void*)0 I think it would
be best to diagnose both form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47932
Summary: __typeof__ prevents VLA from being evaluated
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig..
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gmail dot com
The __builtin___xxx_chk intrinsics are useful in detecting buffer overflows via
the Object Size Checking feature. But in a freestanding/embeeded environment
with its own implementation of function xxx
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gmail dot com
GCC 4.8.2 and prior incorrectly issue a warning for one-byte struct members
declared with the packed attribute when the member is of an over-aligned type.
The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59219
--- Comment #2 from Martin Sebor ---
I'm suggesting that when -fno-builtin is used, __builtin___memcpy_chk (and
other __bultin_xxx_chk) invocations that are determined not to exceed the size
of the buffer boundaries expand to a call to memcpy inst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59219
--- Comment #4 from Martin Sebor ---
I understand. The current semantics of __builtin__xxx_chk are to:
a) check the constraints of the xxx function at compile time, and
b) diagnose constraint violations detected in (a) and call __xxx_chk, or
c) e
--- Comment #5 from msebor at gmail dot com 2010-02-15 20:51 ---
I second Ulrich's request.
Besides nonnull, this enhancement would be useful in attribute printf
as well. For example, in the program below, both calls to printf() have
undefined behavior in C99 and should be diag
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gmail dot com
GCC 4.8.2 issues the following bogus warning on the defintion of Y in bar
despite attribute used. The same definition in an ordinary function emits no
warning
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gmail dot com
GCC 4.8.2 issues the bogus error below on the following valid C++ '98 program.
Instantiating C (or the whole definition of foo) isn't ne
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gmail dot com
GCC 4.8.2 and all versions prior to it fail to diagnose the following
ill-formed C++ '98 program:
$ cat u.cpp && g++ -Wall -Wextra -Werror -pedantic -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60063
--- Comment #1 from Martin Sebor ---
I confused attribute used with unused in the test case. With the latter, the
warning is not emitted as one would expect. Attribute used isn't documented for
types, so it's not completely clear whether the test
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gmail dot com
The documentation for the -Wmaybe-uninitialized option includes an example
similar to the one below to demonstrate the conditions under which GCC is
expected to issue a diagnostic. However, GCC fails to
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gmail dot com
The -Wmaybe-uninitialized option is documented like so: "For an automatic
variable, if there exists a path from the function entry to a use of the
variable that is initia
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gmail dot com
According to 7.24.2.1 of C11, "If copying takes place between objects that
overlap, the behavior [of memcpy] is undefined." The script below shows that
GCC generates code with undefined be
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gmail dot com
libstdc++ string goes to quite a bit of trouble to avoid self-modifying calls
that could potentially corrupt the controlled sequence but there is at least
one case that has escaped this treatment. The
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gmail dot com
The precondition on char_traits::copy(s, p, n), namely that p not be in the
range [s, s + n), is weaker than the precondition on a call to memcpy(s, p, n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65109
--- Comment #4 from Martin Sebor ---
There's the following comment in the test:
/* Testcase could break on future gcc's, if parameter regs
are changed before this asm. */
Moving the locals out of the function lets the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65109
--- Comment #5 from Martin Sebor ---
Created attachment 34809
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34809&action=edit
Test patch to let it pass.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gmail dot com
In GCC 4.5 and later, and at -O and above, attribute weak (but not weak alias)
is silently ignored on declarations of function templates and calls to
specializations of such templates are inlined into
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48985
Summary: bogus buffer overflow warning and abort on static
flexible array member
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
ignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msebor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44486
tatement
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msebor at gmail dot com
GCC build triplet: all
GCC host trip
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41138
Martin Sebor changed:
What|Removed |Added
CC||msebor at gmail dot com
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41138
--- Comment #3 from Martin Sebor 2011-06-10 17:44:47
UTC ---
Here's another test case, one that does involve slicing and where a consistent
but differently phrased warning would, IMO, be useful. Perhaps something like:
warning: slicing high orde
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49535
Summary: __builtin_object_size incorrect for array arguments
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: un
38 matches
Mail list logo
