Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554893.html
On 9/25/20 12:58 PM, Martin Sebor wrote:
The C and C++ representations of zero-length arrays are different:
C uses a null upper bound of the type's domain while C++ uses
SIZE_MAX. This makes the middle end logic
On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote:
On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
wrote:
On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches wrote:
On Linux/x86_64,
c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
commit c34db4b6f8a5d8
On 10/1/20 9:34 AM, Aldy Hernandez wrote:
On 10/1/20 3:22 PM, Andrew MacLeod wrote:
> On 10/1/20 5:05 AM, Aldy Hernandez via Gcc-patches wrote:
>>> Thanks for doing all this! There isn't anything I don't understand
>>> in the sprintf changes so no questions from me (well, almost none).
>>>
-Wstring-compare triggers under the same strict conditions as
the strcmp/strncmp call is folded into a constant: only when
all the uses of the result are [in]equality expressions with
zero. However, even when the call cannot be folded into
a constant because the result is in addition used in othe
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552903.html
(I lost track of this patch.)
On 9/9/20 3:42 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552903.html
On 8/28/20 11:12 AM, Martin Sebor wrote:
The gimple_call_alloc_size() function
Redeclaring a function that takes a VLA parameter with attribute
access that references the same parameter can cause conflicts
when the two aren't in sync. The conflicts are detected and
diagnosed but also have to be resolved. The code wasn't robust
enough to handle all cases gracefully, leading
On 9/30/20 3:57 AM, Jakub Jelinek wrote:
On Tue, Sep 29, 2020 at 03:40:40PM -0600, Martin Sebor via Gcc-patches wrote:
I will commit this patch later this week unless I hear concerns
or suggestions for changes.
That is not how the patch review process works.
The review process hasn't
I have committed & pushed the fix in r11-3540.
On 9/24/20 6:15 PM, Martin Sebor wrote:
The machinery recently added to support -Warray-parameter and
-Wvla-parameter also results in enhanced detection of null
pointer arguments to VLA function parameters. This enhancement
wasn't
To render the bounds as well as the static specifier in array
and VLA function parameters the new -Warray-parameter and
-Wvla-parameter warning builds a "synthetic" array type that
corresponds to the form of the parameter, sets its qualifiers
to match those of the pointer, and passes it to the pr
On 9/28/20 11:34 AM, Marek Polacek wrote:
On Fri, Sep 25, 2020 at 04:31:16PM -0600, Martin Sebor wrote:
On 9/24/20 6:05 PM, Marek Polacek via Gcc-patches wrote:
This new warning can be used to prevent expensive copies inside range-based
for-loops, for instance:
struct S { char arr[128
On 9/25/20 11:17 PM, Jason Merrill wrote:
On 9/22/20 4:05 PM, Martin Sebor wrote:
The rebased and retested patches are attached.
On 9/21/20 3:17 PM, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553906.html
(I'm working on rebasing the patch on t
On 9/25/20 11:41 AM, Andrew MacLeod wrote:
On 9/23/20 7:53 PM, Martin Sebor via Gcc-patches wrote:
On 9/18/20 12:38 PM, Aldy Hernandez via Gcc-patches wrote:
As part of the ranger work, we have been trying to clean up and
generalize interfaces whenever possible. This not only helps in
On 9/24/20 6:05 PM, Marek Polacek via Gcc-patches wrote:
This new warning can be used to prevent expensive copies inside range-based
for-loops, for instance:
struct S { char arr[128]; };
void fn () {
S arr[5];
for (const auto x : arr) { }
}
where auto deduces to S and then w
The C and C++ representations of zero-length arrays are different:
C uses a null upper bound of the type's domain while C++ uses
SIZE_MAX. This makes the middle end logic more complicated (and
prone to mistakes) because it has to be prepared for both. A recent
change to -Warray-bounds has the mi
The machinery recently added to support -Warray-parameter and
-Wvla-parameter also results in enhanced detection of null
pointer arguments to VLA function parameters. This enhancement
wasn't tested as comprehensively as it should have been and
so has some bugs. The attached patch fixes one that
On 9/18/20 12:38 PM, Aldy Hernandez via Gcc-patches wrote:
As part of the ranger work, we have been trying to clean up and
generalize interfaces whenever possible. This not only helps in
reducing the maintenance burden going forward, but provides mechanisms
for backwards compatibility between
On 9/24/20 12:46 AM, Aldy Hernandez wrote:
On 9/24/20 1:53 AM, Martin Sebor wrote:
Finally, unless both a type and function with the same name exist
in the same scope there is no reason to mention the class-id when
referencing a class name. I.e., this
value_range_equiv
On 9/18/20 12:38 PM, Aldy Hernandez via Gcc-patches wrote:
As part of the ranger work, we have been trying to clean up and
generalize interfaces whenever possible. This not only helps in
reducing the maintenance burden going forward, but provides mechanisms
for backwards compatibility between
Using DECL_SOURCE_LOCATION() with a tree node that's not a DECL
isn't a good idea, and neither is using EXPR_LOCATION() with
a node that is a DECL. Both trigger an ICE when presented with
a node they don't expect. Until a TREE_LOCATION() that's safe
to use with either is introduced, the attached
other configurations.
I have committed the patch below following the C front-end
approach of creating a zero-element array that does render as
expected regardless of data models.
Martin
commit 67aeddb785ddcc8688ee5736ecab3c81de34a214 (HEAD -> master,
origin/master, origin/HEAD)
Author: Mart
e ICE that it causes.
Martin
commit e92779db3304bc96a6b861f87c5edde8dd4d4030
Author: Martin Sebor
Date: Wed Sep 23 15:02:01 2020 -0600
Avoid assuming input corresponds to valid source code (PR c/97131).
gcc/c-family/ChangeLog:
PR c/97131
* c-w
On 9/23/20 9:44 AM, Szabolcs Nagy wrote:
The 09/23/2020 09:22, Szabolcs Nagy wrote:
The 09/21/2020 12:45, Martin Sebor via Gcc-patches wrote:
On 9/21/20 12:20 PM, Vaseeharan Vinayagamoorthy wrote:
After this patch, I am seeing this -Warray-parameter error:
In file included from ../include
The rebased and retested patches are attached.
On 9/21/20 3:17 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553906.html
(I'm working on rebasing the patch on top of the latest trunk which
has changed some of the same code but it'd be helpfu
any substantive modifications.)
Martin
On 9/14/20 4:01 PM, Martin Sebor wrote:
On 9/4/20 11:14 AM, Jason Merrill wrote:
On 9/3/20 2:44 PM, Martin Sebor wrote:
On 9/1/20 1:22 PM, Jason Merrill wrote:
On 8/11/20 12:19 PM, Martin Sebor via Gcc-patches wrote:
-Wplacement-new handles array indi
post this patch once I'm done
testing it.
Martin
commit 05193687dde2e5a6337164182a1946b584acfada
Author: Martin Sebor
Date: Mon Sep 21 14:33:29 2020 -0600
Avoid incidental failures due to implicit attribute access.
gcc/testsuite/ChangeLog:
PR c/50584
20/09/2020, 01:02, "Gcc-patches on behalf of Martin Sebor via Gcc-patches"
wrote:
On 9/17/20 4:38 PM, Joseph Myers wrote:
> On Wed, 16 Sep 2020, Martin Sebor via Gcc-patches wrote:
>
>> Attached is an updated revision of the patch. Besides the tweaks
On 9/20/20 12:39 AM, Aldy Hernandez wrote:
On 9/19/20 11:22 PM, Martin Sebor wrote:
On 9/18/20 12:29 AM, Aldy Hernandez wrote:
On 9/17/20 10:18 PM, Martin Sebor wrote:
On 9/17/20 12:39 PM, Andrew MacLeod wrote:
On 9/17/20 12:08 PM, Martin Sebor via Gcc-patches wrote:
On 9/16/20 9:23 PM
On 9/17/20 4:38 PM, Joseph Myers wrote:
On Wed, 16 Sep 2020, Martin Sebor via Gcc-patches wrote:
Attached is an updated revision of the patch. Besides the tweaks
above it also contains a cosmetic change to the warning issued
for mismatches in unspecified VLA bounds: it points at the decl
with
On 9/18/20 12:29 AM, Aldy Hernandez wrote:
On 9/17/20 10:18 PM, Martin Sebor wrote:
On 9/17/20 12:39 PM, Andrew MacLeod wrote:
On 9/17/20 12:08 PM, Martin Sebor via Gcc-patches wrote:
On 9/16/20 9:23 PM, Jeff Law wrote:
On 9/15/20 1:47 PM, Martin Sebor wrote:
Overflowing the size of a
On 9/18/20 3:09 PM, Andrew MacLeod wrote:
On 9/18/20 4:35 PM, Martin Sebor wrote:
On 9/18/20 11:36 AM, Andrew MacLeod wrote:
On
it works exactly like one would expect a simple allocator to work..
as long as the allcoator is "live", its allocations are live. once
it is destructe
On 9/18/20 11:36 AM, Andrew MacLeod wrote:
On 9/18/20 1:07 PM, Martin Sebor wrote:
On 9/18/20 8:10 AM, Aldy Hernandez via Gcc-patches wrote:
On 9/18/20 2:28 PM, David Malcolm wrote:
On Fri, 2020-09-18 at 07:49 +0200, Aldy Hernandez wrote:
On 9/18/20 3:43 AM, David Malcolm wrote:
On Thu
On 9/18/20 8:10 AM, Aldy Hernandez via Gcc-patches wrote:
On 9/18/20 2:28 PM, David Malcolm wrote:
On Fri, 2020-09-18 at 07:49 +0200, Aldy Hernandez wrote:
On 9/18/20 3:43 AM, David Malcolm wrote:
On Thu, 2020-09-17 at 12:36 +0200, Aldy Hernandez via Gcc-patches
wrote:
This is the irange s
On 9/17/20 12:39 PM, Andrew MacLeod wrote:
On 9/17/20 12:08 PM, Martin Sebor via Gcc-patches wrote:
On 9/16/20 9:23 PM, Jeff Law wrote:
On 9/15/20 1:47 PM, Martin Sebor wrote:
Overflowing the size of a dynamic allocation (e.g., malloc or VLA)
can lead to a subsequent buffer overflow
On 9/17/20 4:36 AM, Aldy Hernandez via Gcc-patches wrote:
This is the irange storage class. It is used to allocate the minimum
amount of storage needed for a given irange. Storage is automatically
freed at destruction.
It is meant for long term storage, as opposed to int_range_max which is
On 9/16/20 9:23 PM, Jeff Law wrote:
On 9/15/20 1:47 PM, Martin Sebor wrote:
Overflowing the size of a dynamic allocation (e.g., malloc or VLA)
can lead to a subsequent buffer overflow corrupting the heap or
stack. The attached patch diagnoses a subset of these cases where
the overflow
On 9/15/20 5:15 PM, Joseph Myers wrote:
On Wed, 9 Sep 2020, Martin Sebor via Gcc-patches wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552500.html
Aldy provided a bunch of comments on this patch but I'm still looking
for a formal approval.
This patch is OK.
On 9/15/20 5:02 PM, Joseph Myers wrote:
On Wed, 9 Sep 2020, Martin Sebor via Gcc-patches wrote:
Joseph, do you have any concerns with or comments on the most
recent patch or is it okay as is?
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html
I'm not yet convinced b
Overflowing the size of a dynamic allocation (e.g., malloc or VLA)
can lead to a subsequent buffer overflow corrupting the heap or
stack. The attached patch diagnoses a subset of these cases where
the overflow/wraparound is still detectable.
Besides regtesting GCC on x86_64-linux I also verified
The -Wuninitialized/-Wmaybe-uninitialized enhancement to warn when
a pointer or reference to an uninitialized object is passed to
a const-qualified function argument tries to avoid triggering for
objects of empty types. However, the suppression is incomplete
and lets the warning trigger in some c
The attached patch updates the manual to mention that Wuninitialized
and -Wmaybe-uninitialized are issued for both auto and allocated
objects, as well as for passing pointers to uninitialized objects
to const-qualified parameters. Both of these features are GCC 11
enhancements.
Martin
Document -
On 9/4/20 11:14 AM, Jason Merrill wrote:
On 9/3/20 2:44 PM, Martin Sebor wrote:
On 9/1/20 1:22 PM, Jason Merrill wrote:
On 8/11/20 12:19 PM, Martin Sebor via Gcc-patches wrote:
-Wplacement-new handles array indices and pointer offsets the same:
by adjusting them by the size of the element
In a recent change I added an incorrect adjustment to the conversion
of an offset range with inverted bounds (i.e., upper less than lower)
that caused a regression I overlooked in testing. Attached is a fix
for this tested on x86_64-linux, and with a more comprehensive test.
I plan to commit thi
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552500.html
Aldy provided a bunch of comments on this patch but I'm still looking
for a formal approval.
Martin
On 8/24/20 10:45 AM, Martin Sebor wrote:
On 8/24/20 4:59 AM, Aldy Hernandez wrote:
On 8/21/20 1:37 AM, Martin
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552903.html
On 8/28/20 11:12 AM, Martin Sebor wrote:
The gimple_call_alloc_size() function that determines the range
of sizes of allocated objects and constrains the bounds in calls
to functions like memcpy calls get_range() instead of
Joseph, do you have any concerns with or comments on the most
recent patch or is it okay as is?
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html
Martin
On 9/2/20 6:03 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html
On 8/25/20
On 9/8/20 3:47 AM, Tobias Burnus wrote:
Hi Martin, hi all,
currently, mklog searches for "PR" (and "DR") only in the
first line of a new 'testsuite' file.
I think in many cases, the PR is listed a bit later than
the first line – although, it is usually in the first few
lines; in my example, it
On 9/1/20 1:22 PM, Jason Merrill wrote:
On 8/11/20 12:19 PM, Martin Sebor via Gcc-patches wrote:
-Wplacement-new handles array indices and pointer offsets the same:
by adjusting them by the size of the element. That's correct for
the latter but wrong for the former, causing false posi
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html
On 8/25/20 12:44 PM, Martin Sebor wrote:
Joseph, do you have any more comments on the rest of the most recent
revision of the patch?
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html
Martin
On 8/19/20 6
On 9/1/20 4:22 PM, Jeff Law wrote:
On Tue, 2020-09-01 at 16:13 -0600, Martin Sebor wrote:
On 9/1/20 2:09 AM, Christophe Lyon wrote:
On Mon, 31 Aug 2020 at 23:50, Martin Sebor wrote:
On 8/31/20 4:51 AM, Christophe Lyon wrote:
Hi,
...
I pushed a small aarch64 patch as obvious:
2020
On 9/1/20 2:09 AM, Christophe Lyon wrote:
On Mon, 31 Aug 2020 at 23:50, Martin Sebor wrote:
On 8/31/20 4:51 AM, Christophe Lyon wrote:
Hi,
...
I pushed a small aarch64 patch as obvious:
2020-08-31 Christophe Lyon
gcc/testsuite/
* gcc.target/aarch64
ILP32 failures in a test added for the new -Wstringop-overread
option exposed an unnecessarily restrictive handling of offsets
in ranges with an upper bound that's apparently less than
the lower bound. I have relaxed the handling of this case to
avoid these failures and improve the efficacy of bo
On 8/31/20 3:50 PM, Martin Sebor wrote:
On 8/31/20 4:51 AM, Christophe Lyon wrote:
Hi,
...
I pushed a small aarch64 patch as obvious:
2020-08-31 Christophe Lyon
gcc/testsuite/
* gcc.target/aarch64/strcmpopt_6.c: Suppress
-Wstringop-overread.
(same as you added
On 8/31/20 4:51 AM, Christophe Lyon wrote:
Hi,
...
I pushed a small aarch64 patch as obvious:
2020-08-31 Christophe Lyon
gcc/testsuite/
* gcc.target/aarch64/strcmpopt_6.c: Suppress -Wstringop-overread.
(same as you added for i386)
Thank you!
On arm, there is a
The get_size_range() function is more appropriate to call than
get_range() in contexts where the range of object sizes is needed
because (as also mentioned in the patch for PR 92942 I submitted
last Friday) it has the necessary logic to constrain the range to
just the values that are valid for ob
The gimple_call_alloc_size() function that determines the range
of sizes of allocated objects and constrains the bounds in calls
to functions like memcpy calls get_range() instead of
get_size_range() to obtain its result. The latter is the right
function to call because it has the necessary logic
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551783.html
On 8/19/20 9:00 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551783.html
On 8/11/20 10:19 AM, Martin Sebor wrote:
-Wplacement-new handles array indices and pointer offsets the same
On 8/28/20 12:49 AM, Martin Liška wrote:
On 8/28/20 1:29 AM, Martin Sebor wrote:
With --enable-valgrind-annotations the change to the member function
signature in this patch triggers compilation errors during bootstrap:
I must confirm I didn't tested the configuration. Feel free to in
With --enable-valgrind-annotations the change to the member function
signature in this patch triggers compilation errors during bootstrap:
/src/gcc/trunk/gcc/ggc-common.c: In function ‘void gt_pch_save(FILE*)’:
/src/gcc/trunk/gcc/ggc-common.c:509:33: error: no matching function for
call to ‘vec:
The attached change has match_builtin_function_types() fail
for erroneous argument types to prevent an ICE due to assuming
they are necessarily valid.
Martin
PR c/96596 - ICE in match_builtin_function_types on a declaration of a built-in with invalid array argument
gcc/c/ChangeLog:
PR c/96596
On 8/26/20 7:37 AM, Nathan Sidwell wrote:
Hi,
I had a need to add a new type of informative message on the modules
branch, with an option to enable it. The message is not a warning or an
error, but just 'hey, you asked if X happens. It happens just here'.
This is emitted as a note. I chose
Joseph, do you have any more comments on the rest of the most recent
revision of the patch?
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html
Martin
On 8/19/20 6:09 PM, Joseph Myers wrote:
On Wed, 19 Aug 2020, Martin Sebor via Gcc-patches wrote:
I think you need a while loop
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
On 8/10/20 10:48 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
On 7/26/20 11:42 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
On 8/24/20 4:59 AM, Aldy Hernandez wrote:
On 8/21/20 1:37 AM, Martin Sebor wrote:
On 8/20/20 3:00 PM, Aldy Hernandez wrote:
Regardless, here are some random comments.
Thanks for the careful review!
diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 37214831538
On 8/19/20 6:09 PM, Joseph Myers wrote:
On Wed, 19 Aug 2020, Martin Sebor via Gcc-patches wrote:
I think you need a while loop there, not just an if, to account for the
case of multiple consecutive cdk_attrs. At least the GNU attribute syntax
direct-declarator:
[...]
( gnu
On 8/20/20 3:00 PM, Aldy Hernandez wrote:
First, didn't Marek say in the PR that the diagnostic code should go in
diagnose_mismatched_attributes?
My understanding of the structure of the attribute handling code
is that with just a few exceptions, for C and C++ it's pretty much
all in c-attribs.
On 8/17/20 4:09 PM, Joseph Myers wrote:
On Thu, 13 Aug 2020, Martin Sebor via Gcc-patches wrote:
* Maybe cdk_pointer is followed by cdk_attrs before cdk_id. In this case
the code won't return.
I think I see the problem you're pointing out (I just don't see how
to trigger it
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551783.html
On 8/11/20 10:19 AM, Martin Sebor wrote:
-Wplacement-new handles array indices and pointer offsets the same:
by adjusting them by the size of the element. That's correct for
the latter but wrong for the former, ca
The recent enhancement to memchr/memcmp folding introduced two bugs
(that I know of). The attached patch fixes the one where a call to
the string_constant function that would previously be guaranteed to
succeed now fails as a result of the function only handling strings
and not other types. The
On 8/15/20 8:19 AM, Christophe Lyon wrote:
Hi Martin,
On Sat, 15 Aug 2020 at 01:14, Martin Sebor via Gcc-patches
wrote:
On 8/13/20 11:44 AM, Martin Sebor wrote:
On 8/13/20 10:21 AM, Jeff Law wrote:
On Fri, 2020-07-31 at 17:55 -0600, Martin Sebor via Gcc-patches wrote:
The folders for
I committed the change below updating and completing the description
of the native_encode_expr function.
Martin
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 9fc4c2a06fb..7c4d1eff215 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -7875,11 +7875,12 @@ native_encode_string (const
On 8/13/20 11:44 AM, Martin Sebor wrote:
On 8/13/20 10:21 AM, Jeff Law wrote:
On Fri, 2020-07-31 at 17:55 -0600, Martin Sebor via Gcc-patches wrote:
The folders for these functions (and some others) call c_getsr
which relies on string_constant to return the representation of
constant strings
On 8/12/20 5:19 PM, Joseph Myers wrote:
On Fri, 7 Aug 2020, Martin Sebor via Gcc-patches wrote:
I don't see anything in the tests in this patch to cover this sort of case
(arrays of pointers, including arrays of pointers to arrays etc.).
I've added a few test cases and re
On 8/13/20 10:21 AM, Jeff Law wrote:
On Fri, 2020-07-31 at 17:55 -0600, Martin Sebor via Gcc-patches wrote:
The folders for these functions (and some others) call c_getsr
which relies on string_constant to return the representation of
constant strings. Because the function doesn't h
On 8/12/20 6:28 AM, Martin Liška wrote:
On 8/11/20 4:58 PM, Martin Sebor wrote:
On 8/11/20 5:36 AM, Martin Liška wrote:
Hello.
All right, I did it in 3 steps:
1) - new exact argument is added (no default value) - I tested the on
x86_64-linux-gnu
and I build all cross targets.
2) set default
-Wplacement-new handles array indices and pointer offsets the same:
by adjusting them by the size of the element. That's correct for
the latter but wrong for the former, causing false positives when
the element size is greater than one.
In addition, the warning doesn't even attempt to handle arr
On 8/11/20 5:36 AM, Martin Liška wrote:
Hello.
All right, I did it in 3 steps:
1) - new exact argument is added (no default value) - I tested the on
x86_64-linux-gnu
and I build all cross targets.
2) set default value of exact = false
3) change places which calculate its own growth to use the
On 8/10/20 2:08 PM, Andrew MacLeod wrote:
On 8/10/20 2:46 PM, Martin Sebor wrote:
On 8/10/20 11:50 AM, Andrew MacLeod wrote:
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
int_range is the type which allows for up to X subranges
On 8/10/20 11:50 AM, Andrew MacLeod wrote:
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
On 8/6/20 9:30 PM, Martin Sebor wrote:
On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote:
+ // Remove the unknown parts of a multi-range
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html
On 7/26/20 11:41 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html
On 7/16/20 4:53 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
On 7/26/20 11:42 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
On 7/13/20 6:05 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/551152.html
On 7/31/20 5:55 PM, Martin Sebor wrote:
The folders for these functions (and some others) call c_getsr
which relies on string_constant to return the representation of
constant strings. Because the function doesn't h
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
On 8/6/20 9:30 PM, Martin Sebor wrote:
On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote:
+ // Remove the unknown parts of a multi-range.
+ // This will transform [5,10][20,MAX] into [5,10].
Is this comment correct? Wouldn't this r
On 7/28/20 7:16 PM, Martin Sebor wrote:
Patch 1 adds the basic infrastructure to support array/VLA bounds
in attribute access. It extends the access string specification
to describe function parameters of array types (including VLAs),
extends the attr_access class to parse the string and store
On 7/29/20 12:12 PM, Joseph Myers wrote:
On Tue, 28 Jul 2020, Martin Sebor via Gcc-patches wrote:
+ /* A list of VLA variable bounds or null if not specified. */
+ tree vbchain = NULL_TREE;
+ if (parm->declarator->kind == cdk_array)
+ if (pd->kind != cdk_array)
+
On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote:
[Martin, does this sound reasonable to you?]
It mostly makes sense to me except one part:
The following patch converts get_size_range to the irange API, thus
removing the use of VR_ANTI_RANGE.
This was a bit tricky because of the gymn
On 8/6/20 10:00 AM, Jonathan Wakely wrote:
On 06/08/20 09:17 -0600, Martin Sebor via Libstdc++ wrote:
Sorry. I don't see this exercise as a complete waste of time
(but I understand why it feels like that to you).
What it highlights is the fact that the warning infrastructure
we have in
On 8/6/20 8:45 AM, Jonathan Wakely via Libstdc++ wrote:
On 06/08/20 15:01 +0100, Jonathan Wakely wrote:
On 06/08/20 15:26 +0200, Jakub Jelinek via Libstdc++ wrote:
On Thu, Aug 06, 2020 at 02:14:48PM +0100, Jonathan Wakely wrote:
template
__attribute__((__nonnull__(2), __access__(__write_on
On 8/6/20 7:30 AM, Jonathan Wakely via Libstdc++ wrote:
On 06/08/20 14:14 +0100, Jonathan Wakely via Libstdc++ wrote:
On 05/08/20 16:31 -0600, Martin Sebor via Libstdc++ wrote:
On 8/5/20 3:25 PM, Jonathan Wakely wrote:
P0487R1 resolved LWG 2499 for C++20 by removing the operator>>
ove
On 8/5/20 3:25 PM, Jonathan Wakely wrote:
P0487R1 resolved LWG 2499 for C++20 by removing the operator>> overloads
that have high risk of buffer overflows. They were replaced by
equivalents that only accept a reference to an array, and so can
guarantee not to write past the end of the array.
In
On 8/4/20 3:23 PM, Aldy Hernandez wrote:
On 8/4/20 9:34 PM, Martin Sebor wrote:
On 8/4/20 5:33 AM, Aldy Hernandez via Gcc-patches wrote:
This patch adapts the strlen pass to use the irange API.
I wasn't able to remove the one annoying use of VR_ANTI_RANGE, because
I'm not sure
On 8/4/20 5:33 AM, Aldy Hernandez via Gcc-patches wrote:
This patch adapts the strlen pass to use the irange API.
I wasn't able to remove the one annoying use of VR_ANTI_RANGE, because
I'm not sure what to do. Perhaps Martin can shed some light. The
current code has:
else if (rng == VR_ANT
On 8/4/20 8:11 AM, Aldy Hernandez wrote:
On Tue, Aug 4, 2020 at 3:59 PM Martin Sebor wrote:
On 8/4/20 5:21 AM, Aldy Hernandez via Gcc-patches wrote:
This is a rather obvious patch, but I'd like a nod before committing.
Martin, I've removed your anti-range check, as it is subsu
On 8/4/20 5:21 AM, Aldy Hernandez via Gcc-patches wrote:
This is a rather obvious patch, but I'd like a nod before committing.
Martin, I've removed your anti-range check, as it is subsumed by the
lower_bound/upper_bound code. However, you will have to adapt the code
for multi-ranges if desired.
The folders for these functions (and some others) call c_getsr
which relies on string_constant to return the representation of
constant strings. Because the function doesn't handle constants
of other types, including aggregates, memcmp or memchr calls
involving those are not folded when they coul
On 7/30/20 1:47 PM, Jason Merrill wrote:
On 7/30/20 12:25 PM, Martin Sebor wrote:
On 7/29/20 2:27 PM, Jason Merrill wrote:
On 7/23/20 3:08 PM, Martin Sebor wrote:
Another test case added to the bug since I posted the patch shows
that the no-warning bit set by the C++ front end is easily lost
On 7/29/20 2:27 PM, Jason Merrill wrote:
On 7/23/20 3:08 PM, Martin Sebor wrote:
Another test case added to the bug since I posted the patch shows
that the no-warning bit set by the C++ front end is easily lost
during early folding, triggering the -Wnonull again despite
the suppression. The
I've created a much more rudimentary setup for myself to deal
with the same problem. I copy tests from Bugzilla, sometimes
with tweaks, and compile them from time to time as I revisit
unresolved bugs. I've also thought about adding those to
the test suite and marking them XFAIL but I don't think
Patch 5 adds support for -Warray-bounds to detect out of bounds accesses
in functions that take array/VLA arguments. The changes also enable
the warning for dynamically allocated memory and with it the detection
of accesses that are only partially out of bounds (e.g., accessing
a four byte int in
Patch 4 adds support to the machinery behind -Wstringop-overflow
to issue warnings for (likely) out of bounds accesses in calls to
functions with the internal attribute access specification. This
implements the feature pr50584 asks for (plus more).
[4/5] - Extend -Wstringop-overflow to detect out
Patch 2 adds support for the internal attribute access specification
for array/VLA parameters to the C front end and two new options to
control warnings.
The attribute is added in two steps: first, push_parm_decl adds a new
attribute "arg spec" to each array parameter with a string describing
its
801 - 900 of 3588 matches
Mail list logo
