https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65109
--- Comment #4 from Martin Sebor msebor at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65109
--- Comment #5 from Martin Sebor msebor at gmail dot com ---
Created attachment 34809
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34809action=edit
Test patch to let it pass.
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
: 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
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 behavior
++
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
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 initialized
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
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 necessary
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 -c -o/dev/null u.cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60063
--- Comment #1 from Martin Sebor msebor at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59219
--- Comment #4 from Martin Sebor msebor at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59219
--- Comment #2 from Martin Sebor msebor at gmail dot com ---
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
: 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
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41138
--- Comment #3 from Martin Sebor msebor at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41138
Martin Sebor msebor at gmail dot com changed:
What|Removed |Added
CC||msebor at gmail dot
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
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47931
--- Comment #1 from Martin Sebor msebor at gmail dot com 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
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:
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 triplet: all
: unassigned at gcc dot gnu dot org
ReportedBy: msebor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44486
--- 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 diagnosed
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
at gmail dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41825
dot gnu dot org
ReportedBy: msebor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41672
--- 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).
Strictly speaking
: 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-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 to mention
--- 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
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
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
--- 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 (bool a, bool b) {
return a == b;
}
.file
Version: 4.4.0
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=40261
38 matches
Mail list logo
