In computing the size of expected output for non-constant floating
arguments the sprintf pass doesn't consider the possibility that
the argument value may be not finite (i.e., it can be infinity or
NaN). Infinities and NaNs are formatted as "inf" or "infinity"
and "nan". As a result, any floatin
The pretty-printer formats NaNs simply as Nan, even though
there is much more to a NaN than than that. At the very
least, one might like to know if the NaN is signaling or
quiet, negative or positive. If it's not in a canonical
form, one might also be interested in the significand
and exponent p
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01509.html
On 06/24/2018 03:05 PM, Martin Sebor wrote:
Storing integer command line option arguments in type int
limits options such as -Wlarger-than= or -Walloca-larger-than
to at most INT_MAX (see bug 71905). Larger values wrap around
zero
Committed to trunk in r86274. Jakub/Richard, can you please
also review and approve the corresponding fix for the release
branches?
Martin
On 07/03/2018 06:32 PM, Jeff Law wrote:
On 07/03/2018 04:50 PM, Martin Sebor wrote:
In computing the size of expected output for non-constant floating
On 07/03/2018 08:33 PM, Jeff Law wrote:
On 06/29/2018 09:54 AM, Martin Sebor wrote:
All the warnings I have seen are because of declarations like
the one in the test below that checks for the presence of symbol
sin in the library:
char sin ();
int main () { return sin (); }
GCC has
On 07/04/2018 08:04 AM, Christophe Lyon wrote:
Hi,
On Wed, 4 Jul 2018 at 09:26, Richard Biener wrote:
On Tue, 3 Jul 2018, Martin Sebor wrote:
Committed to trunk in r86274. Jakub/Richard, can you please
also review and approve the corresponding fix for the release
branches?
If it is a
A change of mine to the strlen pass assumes that the strlen
argument points to an object of the correct type and does
not correctly handle GIMPLE where the argument has the wrong
type such as in:
extern char a[1][2];
n = strlen (*a);
where the strlen pass actually sees
n = strlen (a);
Th
On 07/05/2018 09:46 AM, Qing Zhao wrote:
Hi,
I have sent two emails with the updated patches on 7/3:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00065.html
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00070.html
however, these 2 emails were not successfully forwarded to the
gcc-patches@gc
GCC folds accesses to members of constant aggregates except
for character arrays/strings. For example, the strlen() call
below is not folded:
const char a[][4] = { "1", "12" };
int f (void) { retturn strlen (a[1]); }
The attached change set enhances the string_constant() function
to make i
GCC folds strlen() calls to empty substrings within arrays
whose elements are explicitly initialized with NULs but
fails to do the same for elements that are zeroed out
implicitly. For example:
const char a[7] = "123\000\000\000";
int f (void)
{
return strlen (a + 5); // folded
}
While working on other string folding improvements (PR 77357)
I came across another distinct case where GCC could do better:
it doesn't consider as candidates strings that have as many
elements as the size of the array they are stored in, even if
their length is within the bounds of the array. Fo
On 07/06/2018 09:52 AM, Richard Biener wrote:
On Fri, Jul 6, 2018 at 1:54 AM Martin Sebor wrote:
GCC folds accesses to members of constant aggregates except
for character arrays/strings. For example, the strlen() call
below is not folded:
const char a[][4] = { "1", "1
On 07/09/2018 01:28 PM, Qing Zhao wrote:
Hi, Martin,
thanks a lot for your comments.
On Jul 5, 2018, at 11:30 AM, Martin Sebor wrote:
One of the basic design principles that I myself have
accidentally violated in the past is that warning options
should not impact the emitted object code. I
On 07/09/2018 01:51 PM, Jeff Law wrote:
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
{ dg-do run }
{ do-options "-O2 -fno-tree-strlen" } */
I don't think this is doing anything.
If you look at the test run you can see that -fno-tree-strlen is never
passed (I think you actually mea
ange info earlier?
At the time I wrote the test I didn't realize the statement
range info was being computed only in the sprintf pass --
I thought it was done as "a basic service for the greater
good" by VRP. It seems that it should be such a service.
Let me look into tweaking the
On 07/09/2018 06:40 AM, Richard Biener wrote:
On Sun, Jul 8, 2018 at 4:56 AM Martin Sebor wrote:
On 07/06/2018 09:52 AM, Richard Biener wrote:
On Fri, Jul 6, 2018 at 1:54 AM Martin Sebor wrote:
GCC folds accesses to members of constant aggregates except
for character arrays/strings. For
Ping #2: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01509.html
On 07/03/2018 08:12 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01509.html
On 06/24/2018 03:05 PM, Martin Sebor wrote:
Storing integer command line option arguments in type int
limits options
On 07/10/2018 01:12 AM, Richard Biener wrote:
On Mon, Jul 9, 2018 at 11:26 PM Martin Sebor wrote:
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
{ dg-do run }
{ do-options "-O2 -fno-tree-strlen" } */
I don't think this is doing anything.
If you look at the test
On 07/10/2018 08:34 AM, Jeff Law wrote:
On 07/10/2018 08:25 AM, Richard Biener wrote:
On Tue, Jul 10, 2018 at 4:10 PM Martin Sebor wrote:
On 07/10/2018 01:12 AM, Richard Biener wrote:
On Mon, Jul 9, 2018 at 11:26 PM Martin Sebor wrote:
On 07/09/2018 08:36 AM, Aldy Hernandez wrote
On 07/10/2018 09:14 AM, Qing Zhao wrote:
On Jul 9, 2018, at 3:25 PM, Martin Sebor wrote:
check_access() calls warning_at() to issue warnings, and that
function only issues warnings if they are enabled, so the guard
isn't necessary to make it work this way.
Okay I see.
then, in the cu
On 07/11/2018 07:50 AM, Andre Vieira (lists) wrote:
On 11/07/18 11:00, Andre Vieira (lists) wrote:
On 09/07/18 22:44, Martin Sebor wrote:
On 07/09/2018 06:40 AM, Richard Biener wrote:
On Sun, Jul 8, 2018 at 4:56 AM Martin Sebor wrote:
On 07/06/2018 09:52 AM, Richard Biener wrote:
On Fri
The attached change set adjusts the attribute exclusion code
to detect and reject incompatible attributes before attribute
handlers are called to have a chance to make changes despite
the exclusions. The handlers are not run when a conflict is
found.
Tested on x86_64-linux. I expected the fallo
On 07/13/2018 02:53 AM, Christophe Lyon wrote:
Hi,
On Thu, 12 Jul 2018 at 00:04, Martin Sebor wrote:
The attached change set adjusts the attribute exclusion code
to detect and reject incompatible attributes before attribute
handlers are called to have a chance to make changes despite
the
+/* Checks one MEM_REF in REF, located at LOCATION, for out-of-bounds
+ references to string constants. If VRP can determine that the array
+ subscript is a constant, check if it is outside valid range.
+ If the array subscript is a RANGE, warn if it is non-overlapping
+ with valid range.
On 05/02/2018 01:22 AM, Richard Biener wrote:
On Fri, Jan 26, 2018 at 3:16 AM, Martin Sebor wrote:
PR tree-optimization/83776 - [6/7/8 Regression] missing
-Warray-bounds indexing past the end of a string literal,
identified a not-so-recent improvement to constant propagation
as the reason for
On 07/16/2018 09:36 AM, Bernd Edlinger wrote:
Hi,
this fixes PR middle-end/86528.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks -- the string_constant change also fixes bug 86532.
There is another problem in the subsequent handling of
the CONSTRUCTOR -- it i
Ping #3: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01509.html
On 07/09/2018 09:13 PM, Martin Sebor wrote:
Ping #2: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01509.html
On 07/03/2018 08:12 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01509.html
On 06/24
My enhancement to extract constant strings out of complex
aggregates committed last week introduced a couple of bugs in
dealing with non-constant indices and offsets. One of the bugs
was fixed earlier today (PR 86528) but another one remains. It
causes strlen (among other functions) to incorrect
On 07/17/2018 09:38 AM, Jeff Law wrote:
On 07/17/2018 09:19 AM, Martin Sebor wrote:
My enhancement to extract constant strings out of complex
aggregates committed last week introduced a couple of bugs in
dealing with non-constant indices and offsets. One of the bugs
was fixed earlier today (PR
If there are no objections I'd like to backport the solution
for PR 85602 to avoid a class of unnecessary warnings for
safe uses of nonstring arrays. With the release coming up
later this week I'll go ahead and commit the patch tomorrow.
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=261
managed trigger
it.
On 07/17/2018 09:19 AM, Martin Sebor wrote:
My enhancement to extract constant strings out of complex
aggregates committed last week introduced a couple of bugs in
dealing with non-constant indices and offsets. One of the bugs
was fixed earlier today (PR 86528) but another one
On 07/18/2018 02:31 AM, Richard Biener wrote:
On Tue, 17 Jul 2018, Martin Sebor wrote:
The attached update takes care of a couple of problems pointed
out by Bernd Edlinger in his comments on the bug. The ICE he
mentioned in comment #20 was due mixing sizetype, ssizetype,
and size_type_node in
On 07/04/2018 04:23 AM, marxin wrote:
gcc/ChangeLog:
2018-07-11 Martin Liska
* align.h: New file.
Martin,
I'm seeing lots of warnings for this file:
/ssd/src/gcc/svn/gcc/align.h:53:32: warning: extended initializer lists
only available with -std=c++11 or -std=gnu++11
The code
On 07/18/2018 09:09 AM, Franz Sirl wrote:
Am 2018-07-18 um 01:50 schrieb Martin Sebor:
If there are no objections I'd like to backport the solution
for PR 85602 to avoid a class of unnecessary warnings for
safe uses of nonstring arrays. With the release coming up
later this week I'l
+ while (TREE_CODE (chartype) != INTEGER_TYPE)
+chartype = TREE_TYPE (chartype);
This is a bit concerning. First under what conditions is chartype not
going to be an INTEGER_TYPE? And under what conditions will extracting
its type ultimately lead to something that is an INTEGER_TYPE?
On 07/19/2018 12:04 PM, Bernd Edlinger wrote:
Hi,
this fixes a few minor nits, which I spotted while
looking at the string folding functions:
Please hold off until the patch for bug 86532 has been reviewed,
approved, and committed. I'm making changes in this area,
partly to address some of y
On 07/19/2018 01:17 AM, Richard Biener wrote:
On Wed, 18 Jul 2018, Martin Sebor wrote:
+ while (TREE_CODE (chartype) != INTEGER_TYPE)
+chartype = TREE_TYPE (chartype);
This is a bit concerning. First under what conditions is chartype not
going to be an INTEGER_TYPE? And under what
On 07/19/2018 12:19 AM, Bernd Edlinger wrote:
if (TREE_CODE (idx) != INTEGER_CST
&& TREE_CODE (argtype) == POINTER_TYPE)
{
/* From a pointer (but not array) argument extract the variable
index to prevent get_addr_base_and_unit_off
On 07/19/2018 07:23 AM, Bernd Edlinger wrote:
@@ -633,12 +642,17 @@ c_strlen (tree src, int only_value)
return ssize_int (0);
/* We don't know the starting offset, but we do know that the string
-has no internal zero bytes. We can assume that the offset falls
-wit
In the discussion of my patch for pr86532 Bernd noted that
GCC silently accepts constant character arrays with no
terminating nul as arguments to strlen (and other string
functions).
The attached patch is a first step in detecting these kinds
of bugs in strlen calls by issuing -Wstringop-overflow
geLog
===
--- gcc/ChangeLog (revision 262891)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2018-07-19 Martin Sebor
+
+ * align.h (align_flags): Use member initialization.
+
2018-07-19 David Malcolm
* Makefile.in (OBJS): Add optinfo.o.
n 07/19/2018 01:49 PM, Martin Sebor wrote:
On 07/19/2018 01:17 AM, Richard Biener wrote:
On Wed, 18 Jul 2018, Martin Sebor wrote:
+ while (TREE_CODE (chartype) != INTEGER_TYPE)
+chartype = TREE_TYPE (chartype);
This is a bit concerning. First under what conditions is chartype not
On 07/19/2018 02:45 PM, Bernd Edlinger wrote:
@@ -11413,8 +11429,10 @@ string_constant (tree arg, tree *ptr_offset)
const char a[4] = "abc\000\000";
The excess elements contribute to TREE_STRING_LENGTH()
but not to strlen(). */
- unsigned HOST_WIDE_INT length
-= strnlen (TREE
On 07/19/2018 03:51 PM, Jeff Law wrote:
On 07/13/2018 05:45 PM, Martin Sebor wrote:
+ offset_int ofr[] = {
+ wi::to_offset (fold_convert (ptrdiff_type_node, vr->min)),
+ wi::to_offset (fold_convert (ptrdiff_type_node, vr->max))
+ };
huh. Do you maybe want
On 07/20/2018 05:34 AM, Rainer Orth wrote:
Hi Martin,
On 07/19/2018 03:51 PM, Jeff Law wrote:
On 07/13/2018 05:45 PM, Martin Sebor wrote:
+ offset_int ofr[] = {
+ wi::to_offset (fold_convert (ptrdiff_type_node, vr->min)),
+ wi::to_offset (fold_convert (ptrdiff_type_node,
On 07/19/2018 04:31 PM, Jeff Law wrote:
On 06/24/2018 03:05 PM, Martin Sebor wrote:
Storing integer command line option arguments in type int
limits options such as -Wlarger-than= or -Walloca-larger-than
to at most INT_MAX (see bug 71905). Larger values wrap around
zero. The value zero is
As the last observation in PR 82063 Jim points out that
Both -Warray-bounds and -Warray-bounds= are listed in the c.opt
file as being enabled by -Wall, but they are the same option,
and it causes this one option to be processed twice in the
C_handle_option_auto function in the generated o
On 07/20/2018 08:51 AM, Bernd Edlinger wrote:
Martin,
when I look at tree-ssa-forwprop.c:
str1 = string_constant (src1, &off1);
if (str1 == NULL_TREE)
break;
if (!tree_fits_uhwi_p (off1)
|| compare_tree_int (off1,
On 07/20/2018 03:11 PM, Bernd Edlinger wrote:
I think I have found a valid test case where the latest patch
does generate invalid code:
This is due to another bug in string_constant() that's latent
on trunk but that's exposed by the patch. Trunk only "works"
because of a bug/limitation in c_st
On 07/21/2018 06:42 PM, H.J. Lu wrote:
On Fri, Jul 20, 2018 at 1:57 PM, Martin Sebor wrote:
On 07/19/2018 04:31 PM, Jeff Law wrote:
On 06/24/2018 03:05 PM, Martin Sebor wrote:
Storing integer command line option arguments in type int
limits options such as -Wlarger-than= or -Walloca-larger
On 07/22/2018 02:00 AM, Bernd Edlinger wrote:
On 07/21/18 00:15, Martin Sebor wrote:
On 07/20/2018 08:51 AM, Bernd Edlinger wrote:
Martin,
when I look at tree-ssa-forwprop.c:
str1 = string_constant (src1, &off1);
if (str1 == NULL_TREE)
b
On 07/22/2018 03:03 AM, Bernd Edlinger wrote:
On 07/21/18 01:58, Martin Sebor wrote:
On 07/20/2018 03:11 PM, Bernd Edlinger wrote:
I think I have found a valid test case where the latest patch
does generate invalid code:
This is due to another bug in string_constant() that's latent
on
On 07/22/2018 04:47 PM, Martin Sebor wrote:
On 07/22/2018 02:00 AM, Bernd Edlinger wrote:
On 07/21/18 00:15, Martin Sebor wrote:
On 07/20/2018 08:51 AM, Bernd Edlinger wrote:
Martin,
when I look at tree-ssa-forwprop.c:
str1 = string_constant (src1, &off1);
On 07/23/2018 02:18 AM, Jakub Jelinek wrote:
On Sun, Jul 22, 2018 at 04:43:17PM -0600, Martin Sebor wrote:
OK with the nit fixed. IF you need to update the doc changes as a
result of the -faligned-* changes, those are pre-approved.
I had to adjust a few more tests and make a couple of minor
On 07/23/2018 02:05 AM, Jakub Jelinek wrote:
On Sun, Jul 22, 2018 at 04:47:45PM -0600, Martin Sebor wrote:
No, I mean something like:
$ cat y.c
const char a[2][3] = { "1234", "xyz" };
char b[6];
int main ()
{
__builtin_memcpy(b, a, 4);
__builtin_
(David, I'm hoping your your help here. Please see the end.)
While looking into a recent -Warray-bounds instance in Glibc
involving inlining of large functions it became apparent that
GCC could do a better job of pinpointing the source of
the problem.
The attached patch makes a few adjustments
On 07/23/2018 07:20 PM, David Malcolm wrote:
On Mon, 2018-07-23 at 17:49 -0600, Martin Sebor wrote:
(David, I'm hoping your your help here. Please see the end.)
While looking into a recent -Warray-bounds instance in Glibc
involving inlining of large functions it became apparent that
GCC
On 07/24/2018 03:24 AM, Franz Sirl wrote:
Am 2018-07-20 um 23:22 schrieb Martin Sebor:
As the last observation in PR 82063 Jim points out that
Both -Warray-bounds and -Warray-bounds= are listed in the c.opt
file as being enabled by -Wall, but they are the same option,
and it causes
On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
Hi!
This patch makes strlen range computations more conservative.
Firstly if there is a visible type cast from type A to B before passing
then value to strlen, don't expect the type layout of B to restrict the
possible return value range of strlen.
On 07/24/2018 11:05 AM, David Malcolm wrote:
On Mon, 2018-07-23 at 20:56 -0600, Martin Sebor wrote:
On 07/23/2018 07:20 PM, David Malcolm wrote:
On Mon, 2018-07-23 at 17:49 -0600, Martin Sebor wrote:
(David, I'm hoping your your help here. Please see the end.)
While looking into a r
On 07/20/2018 04:20 AM, Richard Biener wrote:
On Thu, 19 Jul 2018, Martin Sebor wrote:
Here's one more update with tweaks addressing a couple more
of Bernd's comments:
1) correct the use of TREE_STRING_LENGTH() where a number of
array elements is expected and not bytes
2) set CHARTY
On 07/24/2018 01:48 PM, Franz Sirl wrote:
Am 2018-07-24 um 17:35 schrieb Martin Sebor:
On 07/24/2018 03:24 AM, Franz Sirl wrote:
Am 2018-07-20 um 23:22 schrieb Martin Sebor:
As the last observation in PR 82063 Jim points out that
Both -Warray-bounds and -Warray-bounds= are listed in the
The very large option argument enhancement committed last week
inadvertently introduced an assumption about the LP64 data model
that makes the -Wxxx-larger-than options have a different effect
at their default documented setting of PTRDIFF_MAX between ILP32
and LP64. As a result, the options are
On 07/25/2018 02:34 AM, Richard Biener wrote:
On Wed, Jul 25, 2018 at 4:07 AM Martin Sebor wrote:
The very large option argument enhancement committed last week
inadvertently introduced an assumption about the LP64 data model
that makes the -Wxxx-larger-than options have a different effect
at
On 07/25/2018 08:57 AM, Jakub Jelinek wrote:
On Wed, Jul 25, 2018 at 08:54:13AM -0600, Martin Sebor wrote:
I don't mean for the special value to be used except internally
for the defaults. Otherwise, users wanting to override the default
will choose a value other than it. I'
One other example I have found in one of the test cases:
char c;
if (strlen(&c) != 0) abort();
this is now completely elided, but why?
Because the only string that can be stored in an array of one
element is the empty string. Expanding that call to strlen()
is in all likelihood going to resu
BUT - for the string_constant and c_strlen functions we are,
in all cases we return something interesting, able to look
at an initializer which then determines that type. Hopefully.
I think the strlen() folding code when it sets SSA ranges
now looks at types ...?
Consider
struct X { int i; char
Aldy pointed out that the runtime test I added in r261705 to
exercise the new strnlen() built-in makes use of directives
that are ignored by the test harness.
I have removed the directives via r262981.
Martin
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01124.html
The fix for bug 86532 has been checked in so this enhancement
can now be applied on top of it (with only minor adjustments).
On 07/19/2018 02:08 PM, Martin Sebor wrote:
In the discussion of my patch for pr86532 Bernd noted that
GCC
On 07/26/2018 02:38 AM, Richard Biener wrote:
On Wed, Jul 25, 2018 at 5:54 PM Martin Sebor wrote:
On 07/25/2018 08:57 AM, Jakub Jelinek wrote:
On Wed, Jul 25, 2018 at 08:54:13AM -0600, Martin Sebor wrote:
I don't mean for the special value to be used except internally
for the def
On 06/29/2018 11:05 AM, Jeff Law wrote:
On 06/07/2018 09:57 AM, Martin Sebor wrote:
The attached patch enhances the strlen pass to more consistently
deal with MEM_REF assignments (PR 86042) and to track string
lengths across calls to memcpy that overwrite parts of a string
with sequences of non
On 07/26/2018 08:58 AM, Martin Sebor wrote:
On 07/26/2018 02:38 AM, Richard Biener wrote:
On Wed, Jul 25, 2018 at 5:54 PM Martin Sebor wrote:
On 07/25/2018 08:57 AM, Jakub Jelinek wrote:
On Wed, Jul 25, 2018 at 08:54:13AM -0600, Martin Sebor wrote:
I don't mean for the special value
On 07/27/2018 03:05 AM, Eric Botcazou wrote:
I missed your approval and didn't get to committing the patch
until today. While retesting it on top of fresh trunk I noticed
a few test failures due to other recent strlen changes. I made
adjustments to the patch to avoid most of them and opened bug
My yesterday's change to tree-ssa-strlen.c introduced a test
for INTEGER_TYPE where INTEGRAL_TYPE_P should have been used,
causing a subsequent ICE when the latter was supplied.
The attached patch corrects the test and also makes the subsequent
code more robust and be prepared for the test to fai
On 07/27/2018 10:17 AM, Eric Botcazou wrote:
FWIW, there are 128 failures in the GCC test suite on x86_64.
Many of these have been there for weeks (e.g., the lto failures
due to PR86004), even years (guality). My script to compare
the results against a baseline uses the following regular
express
I committed this in r263032.
On 07/27/2018 09:53 AM, Martin Sebor wrote:
My yesterday's change to tree-ssa-strlen.c introduced a test
for INTEGER_TYPE where INTEGRAL_TYPE_P should have been used,
causing a subsequent ICE when the latter was supplied.
The attached patch corrects the tes
On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
Hi!
This fixes two wrong code bugs where string_constant
returns over length string constants. Initializers
like that are rejected in C++, but valid in C.
If by valid you are referring to declarations like the one in
the added test:
const cha
On 07/30/2018 12:57 AM, Richard Biener wrote:
On Sun, 29 Jul 2018, Martin Sebor wrote:
On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
Hi!
This fixes two wrong code bugs where string_constant
returns over length string constants. Initializers
like that are rejected in C++, but valid in C
On 07/30/2018 05:51 AM, Bernd Edlinger wrote:
Hi,
this is how I would like to handle the over length strings issue in the C FE.
If the string constant is exactly the right length and ends in one explicit
NUL character, shorten it by one character.
I thought Martin would be working on it, but a
On 07/30/2018 09:28 AM, Jakub Jelinek wrote:
On Sun, Jul 29, 2018 at 08:35:39PM +0200, Iain Buclaw wrote:
Since r262910, it was noticed that new -Walloca-larger-than= warnings
started appearing when building the D frontend's standard library.
These have been checked and verified as valid, and ap
[] = { 'a', 'b', 'c' }; I am testing
an independent solution for those (bug 86552). Once those
are handled the warning will be able to detect those as well.
Tested on x86_64-linux.
On 07/25/2018 05:38 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2018
On 07/26/2018 02:53 AM, Bernd Edlinger wrote:
@@ -567,13 +597,17 @@ string_length (const void *ptr, unsigned eltsize,
unsigned maxelts)
accesses. Note that this implies the result is not going to be emitted
into the instruction stream.
+ When ARR is non-null and the string is not prop
On 07/30/2018 09:24 AM, Bernd Edlinger wrote:
On 07/30/18 01:05, Martin Sebor wrote:
On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
Hi!
This fixes two wrong code bugs where string_constant
returns over length string constants. Initializers
like that are rejected in C++, but valid in C.
If
The enhanced handling of MEM_REFs in -Warray-bounds assumes
the object from whose address an offset is being computed has
a complete type. Since the size of such objects isn't known,
whether the offset (or index) from its beginning is valid
cannot be reliably determined. The attached patch avoid
The middle-end contains code to determine the lengths of constant
character arrays initialized by string literals. The code is used
in a number of optimizations and warnings.
However, the code is unable to deal with constant arrays initialized
using the braced initializer syntax, as in
const
On 07/27/2018 12:48 AM, Bernd Edlinger wrote:
I have one more example similar to PR86259, that resembles IMHO real world code:
Consider the following:
int fun (char *p)
{
char buf[16];
assert(strlen(p) < 4); //here: security relevant check
sprintf(buf, "echo %s - %s", p, p); //here: se
On 07/30/2018 03:11 PM, Bernd Edlinger wrote:
Hi,
@@ -621,6 +674,12 @@ c_strlen (tree src, int only_value)
maxelts = maxelts / eltsize - 1;
}
+ /* Unless the caller is prepared to handle it by passing in a non-null
+ ARR, fail if the terminating nul doesn't fit in the array
On 07/30/2018 02:21 PM, Bernd Edlinger wrote:
On 07/30/18 21:52, Martin Sebor wrote:
On 07/30/2018 09:24 AM, Bernd Edlinger wrote:
On 07/30/18 01:05, Martin Sebor wrote:
On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
Hi!
This fixes two wrong code bugs where string_constant
returns over
On 07/31/2018 07:38 AM, Jason Merrill wrote:
On Tue, Jul 31, 2018 at 9:51 AM, Martin Sebor wrote:
The middle-end contains code to determine the lengths of constant
character arrays initialized by string literals. The code is used
in a number of optimizations and warnings.
However, the code
On 07/31/2018 12:38 AM, Jakub Jelinek wrote:
On Mon, Jul 30, 2018 at 09:45:49PM -0600, Martin Sebor wrote:
Even without _FORTIFY_SOURCE GCC diagnoses (some) writes past
the end of subobjects by string functions. With _FORTIFY_SOURCE=2
it calls abort. This is the default on popular
05:49 PM, Martin Sebor wrote:
(David, I'm hoping your your help here. Please see the end.)
While looking into a recent -Warray-bounds instance in Glibc
involving inlining of large functions it became apparent that
GCC could do a better job of pinpointing the source of
the problem.
The att
The GCC internal %G directive takes a gcall* argument and prints
the call's inlining stack in diagnostics. The argument type makes
it unsuitable for gimple expressions such as those diagnosed by
-Warray-bounds.
As the first step in adding inlining context to -Warray-bounds
warnings the attached
I can't approve patches but this one seems to be in
the obvious category so I think it could be checked in
without formal approval.
It is however missing a couple of things: 1) a test case,
and 2) a reference to the bug it fixes in the ChangeLog
and in the test.
With that, if no one objects, I w
On 07/31/2018 09:48 AM, Jakub Jelinek wrote:
On Tue, Jul 31, 2018 at 09:17:52AM -0600, Martin Sebor wrote:
On 07/31/2018 12:38 AM, Jakub Jelinek wrote:
On Mon, Jul 30, 2018 at 09:45:49PM -0600, Martin Sebor wrote:
Even without _FORTIFY_SOURCE GCC diagnoses (some) writes past
the end of
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01690.html
On 10/17/2019 10:28 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01690.html
Other than the suggestions I got for optimization (for GCC 11)
and additional buffer overflow detection for [static] arrays
Other than the comments from Joseph any feedback on the patch
itself and my questions?
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01015.html
On 10/14/2019 02:41 PM, Martin Sebor wrote:
Attached is a more fleshed out version of the built-in implemented
to run in a pass of its own. I
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00860.html
Should I add something like the -Wzero-length-array-bounds option
to allow some of the questionable idioms seen in the kernel?
On 10/11/2019 10:34 AM, Martin Sebor wrote:
On 9/10/19 4:35 PM, Jeff Law wrote:
On 9/6/19 1:27 PM
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00570.html
On 10/14/2019 08:34 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00570.html
On 10/8/19 5:51 PM, Martin Sebor wrote:
Attached is a resubmission of the -Wrestrict implementation for
the sprintf family
other similar built-ins
(e.g., __has_attribute) and since Clang has at least one bug
report about this, I left it as is and just raised PR 91961
for the record.
On 10/11/2019 09:23 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00062.html
On 10/1/19 11:16 AM, Martin
A recent enhancement to take advantage of non-constant strlen
results constrained to a known range interacts badly with
the nul-over-nul optimization. The optimization eliminates
nul stores that overwrite the exiting terminating nul of
the destination string. This interaction causes the nul
stor
1 - 100 of 3588 matches
Mail list logo
