On 10/21/21 1:17 AM, Aldy Hernandez wrote:
On Wed, Oct 20, 2021 at 10:01 PM Jeff Law wrote:
On 10/20/2021 9:15 AM, Aldy Hernandez wrote:
On Wed, Oct 20, 2021 at 4:35 PM Martin Sebor wrote:
I appreciate the heads up. I'm happy that the threader has
improved. I'm obviously not pleased
On 10/7/21 4:14 PM, Siddhesh Poyarekar wrote:
Handle either static sizes in function parameters or hints provided by
__attribute__ ((access (...))) to compute sizes for objects.
It's been my hope to eventually teach __builtin_object_size about
attribute access but implementing it in the new
On 10/20/21 4:28 AM, Aldy Hernandez via Gcc-patches wrote:
Sometimes we can solve a candidate path without having to recurse
further back. This can mostly happen in fully resolving mode, because
we can ask the ranger what the range on entry to the path is, but
there's no reason this can't
On 10/17/21 10:38 PM, Hongtao Liu wrote:
On Fri, Oct 15, 2021 at 11:37 PM Martin Sebor wrote:
On 10/14/21 1:11 AM, liuhongt wrote:
Hi Kewen:
Cound you help to verify if this patch fix those regressions
for rs6000 port.
As discussed in [1], this patch add xfail/target selector to those
On 10/14/21 1:11 AM, liuhongt wrote:
Hi Kewen:
Cound you help to verify if this patch fix those regressions
for rs6000 port.
As discussed in [1], this patch add xfail/target selector to those
testcases, also make a copy of them so that they can be tested w/o
vectorization.
Just to make
On 10/9/21 12:47 PM, Aldy Hernandez via Gcc-patches wrote:
We seem to be passing a lot of context around in the strlen code. I
certainly don't want to contribute to more.
Most of the handle_* functions are passing the gsi as well as either
ptr_qry or rvals. That looks a bit messy. May I
On 10/13/21 2:25 AM, Richard Biener wrote:
On Wed, Oct 13, 2021 at 3:32 AM Martin Sebor via Gcc-patches
wrote:
On 10/11/21 6:26 PM, Joseph Myers wrote:
The testcase uses the __seg_fs address space, which is x86-specific, but
it isn't in an x86-specific directory or otherwise restricted
On 10/13/21 1:43 AM, Kewen.Lin wrote:
on 2021/10/13 下午2:29, Hongtao Liu via Gcc-patches wrote:
On Wed, Oct 13, 2021 at 11:34 AM Hongtao Liu wrote:
On Tue, Oct 12, 2021 at 11:49 PM Martin Sebor wrote:
On 10/11/21 8:31 PM, Hongtao Liu wrote:
On Tue, Oct 12, 2021 at 4:08 AM Martin Sebor via
On 10/11/21 6:26 PM, Joseph Myers wrote:
The testcase uses the __seg_fs address space, which is x86-specific, but
it isn't in an x86-specific directory or otherwise restricted to x86
targets; thus, I'd expect it to fail for other architectures.
This is not a review of the rest of the patch.
On 10/12/21 12:52 AM, Richard Biener wrote:
On Mon, Oct 11, 2021 at 11:25 PM Martin Sebor wrote:
The attached change extends GCC's warnings for out-of-bounds
stores to cover atomic (and __sync) built-ins.
Rather than hardcoding the properties of these built-ins just
for the sake of the out
On 10/12/21 12:33 PM, Siddhesh Poyarekar wrote:
The warning is falsely triggered for THREAD_SELF in glibc when
accessing TCB through the segment register.
Thanks for looking into it! The Glibc warning is being tracked
in PR 102630. The root cause behind it is in compute_objsize_r
in
On 10/12/21 10:18 AM, Segher Boessenkool wrote:
Hi!
On Tue, Oct 12, 2021 at 09:49:19AM -0600, Martin Sebor wrote:
Coming back to the xfail conditionals, do you think you'll
be able to put together some target-supports magic so they
don't have to enumerate all the affected targets
On 10/11/21 8:31 PM, Hongtao Liu wrote:
On Tue, Oct 12, 2021 at 4:08 AM Martin Sebor via Gcc-patches
wrote:
On 10/11/21 11:43 AM, Segher Boessenkool wrote:
On Mon, Oct 11, 2021 at 10:23:03AM -0600, Martin Sebor wrote:
On 10/11/21 9:30 AM, Segher Boessenkool wrote:
On Mon, Oct 11, 2021
The attached change extends GCC's warnings for out-of-bounds
stores to cover atomic (and __sync) built-ins.
Rather than hardcoding the properties of these built-ins just
for the sake of the out-of-bounds detection, on the assumption
that it might be useful for future optimizations as well, I
On 10/11/21 11:43 AM, Segher Boessenkool wrote:
On Mon, Oct 11, 2021 at 10:23:03AM -0600, Martin Sebor wrote:
On 10/11/21 9:30 AM, Segher Boessenkool wrote:
On Mon, Oct 11, 2021 at 10:47:00AM +0800, Kewen.Lin wrote:
- For generic test cases, it follows the existing suggested
practice
On 10/11/21 9:30 AM, Segher Boessenkool wrote:
Hi!
On Mon, Oct 11, 2021 at 10:47:00AM +0800, Kewen.Lin wrote:
As PR102658 shows, commit r12-4240 enables vectorization at O2,
some cases need to be adjusted accordingly for rs6000 port.
- For target specific test cases, this adds
When determining the size of an object compute_objsize_r() assumes
that addresses derived from null pointers are not derefernceable
because null pointers themselves are not, without calling
targetm.addr_space.zero_address_valid() to see if that assumption
is supported for the pointer on the
On 10/9/21 10:19 AM, Martin Sebor wrote:
On 10/9/21 9:04 AM, Aldy Hernandez wrote:
On Fri, Oct 8, 2021 at 6:52 PM Martin Sebor wrote:
On 10/8/21 9:12 AM, Aldy Hernandez via Gcc-patches wrote:
The following patch converts the strlen pass from evrp to ranger,
leaving DOM as the last remaining
On 10/9/21 9:04 AM, Aldy Hernandez wrote:
On Fri, Oct 8, 2021 at 6:52 PM Martin Sebor wrote:
On 10/8/21 9:12 AM, Aldy Hernandez via Gcc-patches wrote:
The following patch converts the strlen pass from evrp to ranger,
leaving DOM as the last remaining user.
Thanks for doing this. I know I
On 10/8/21 4:49 AM, Aldy Hernandez via Gcc-patches wrote:
On Thu, Sep 23, 2021 at 8:32 AM Richard Biener via Gcc-patches
wrote:
On Thu, 23 Sep 2021, Hongtao Liu wrote:
On Thu, Sep 23, 2021 at 9:48 AM Hongtao Liu wrote:
On Wed, Sep 22, 2021 at 10:21 PM Martin Sebor wrote:
On 9/21/21 7
On 10/8/21 11:56 AM, Andrew MacLeod wrote:
On 10/8/21 12:51 PM, Martin Sebor via Gcc-patches wrote:
I.e., in the test:
void g (char *s1, char *s2)
{
char b[1025];
size_t n = __builtin_strlen (s1), d = __builtin_strlen (s2);
if (n + d + 1 >= 1025)
return;
sprintf (b, "%s
On 10/8/21 9:12 AM, Aldy Hernandez via Gcc-patches wrote:
The following patch converts the strlen pass from evrp to ranger,
leaving DOM as the last remaining user.
Thanks for doing this. I know I said I'd work on it but I'm still
bogged down in my stage 1 work that's not going so great :( I
On 10/6/21 11:03 AM, Aldy Hernandez wrote:
FWIW, I've opened a PR with both testcases:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
Okay, thanks. I see what you mean that reducing it to a test case
is challenging. I'll see if I can find some time to distill it to
something useful.
On 10/6/21 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...every single change to the threading code shines the light on
some warning bug.
If you take the calls.ii file from the aarch64
While resolving the recent -Waddress enhancement request (PR
PR102103) I came across a 2007 problem report about GCC 4 having
stopped warning for using the address of inline functions in
equality comparisons with null. With inline functions being
commonplace in C++ this seems like an important
On 9/30/21 1:35 PM, Joseph Myers wrote:
On Thu, 30 Sep 2021, Martin Sebor via Gcc-patches wrote:
Jason, since you approved the C++ changes, would you mind looking
over the C bits and if they look good to you giving me the green
light to commit the patch?
https://gcc.gnu.org/pipermail/gcc
On 9/30/21 8:50 AM, Marek Polacek via Gcc-patches wrote:
This patch addresses one of my leftovers from GCC 11. C++20 introduced
[depr.array.comp]:
"Equality and relational comparisons between two operands of array type are
deprecated."
so this patch adds -Wdeprecated-array-compare (enabled by
Jason, since you approved the C++ changes, would you mind looking
over the C bits and if they look good to you giving me the green
light to commit the patch?
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579693.html
Thanks in advance for your help!
On 9/24/21 8:31 AM, Martin Sebor
On 9/26/21 3:52 PM, Daniil Stas via Gcc-patches wrote:
This option is enabled by default when -Wformat option is enabled. A
user can specify -Wno-format-same-precision to disable emitting
warnings about an argument passed to printf-like function having a
different type from the one specified in
On 9/28/21 2:31 PM, Qing Zhao via Gcc-patches wrote:
Hi,
This is the patch for the gcc12 changes per your request.
Kees provided most of the wording.
Please take a look and let’s know whether it’s good for commit?
thanks.
Qing
From: qing
On 9/28/21 1:20 AM, Richard Biener wrote:
On Mon, 27 Sep 2021, sunil.k.pandey wrote:
On Linux/x86_64,
d06dc8a2c73735e9496f434787ba4c93ceee5eea is the first bad commit
commit d06dc8a2c73735e9496f434787ba4c93ceee5eea
Author: Richard Biener
Date: Mon Sep 27 13:36:12 2021 +0200
Ping: Jeff, with the C++ part approved, can you please confirm your
approval with the C parts of the patch?
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579693.html
On 9/21/21 6:34 PM, Martin Sebor wrote:
On 9/21/21 3:40 PM, Jason Merrill wrote:
The C++ changes are OK
On 9/23/21 9:32 PM, Hongtao Liu wrote:
On Thu, Sep 23, 2021 at 11:18 PM Martin Sebor wrote:
On 9/23/21 12:30 AM, Richard Biener wrote:
On Thu, 23 Sep 2021, Hongtao Liu wrote:
On Thu, Sep 23, 2021 at 9:48 AM Hongtao Liu wrote:
On Wed, Sep 22, 2021 at 10:21 PM Martin Sebor wrote:
On 9
On 9/23/21 12:30 AM, Richard Biener wrote:
On Thu, 23 Sep 2021, Hongtao Liu wrote:
On Thu, Sep 23, 2021 at 9:48 AM Hongtao Liu wrote:
On Wed, Sep 22, 2021 at 10:21 PM Martin Sebor wrote:
On 9/21/21 7:38 PM, Hongtao Liu wrote:
On Mon, Sep 20, 2021 at 4:13 AM Martin Sebor wrote
On 9/22/21 8:21 AM, Martin Sebor wrote:
On 9/21/21 7:38 PM, Hongtao Liu wrote:
On Mon, Sep 20, 2021 at 4:13 AM Martin Sebor wrote:
...
diff --git a/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c
b/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c
index 1d79930cd58..9351f7e7a1a 100644
On 9/21/21 7:38 PM, Hongtao Liu wrote:
On Mon, Sep 20, 2021 at 4:13 AM Martin Sebor wrote:
...
diff --git a/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c
b/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c
index 1d79930cd58..9351f7e7a1a 100644
--- a/gcc/testsuite/c-c++-common/Wstringop
On 9/21/21 3:40 PM, Jason Merrill wrote:
On 9/17/21 12:02, Martin Sebor wrote:
On 9/8/21 2:06 PM, Jason Merrill wrote:
On 9/2/21 7:53 PM, Martin Sebor wrote:
@@ -4622,28 +4622,94 @@ warn_for_null_address (location_t location,
tree op, tsubst_flags_t complain)
if (!warn_address
After the front end passes control to the middle end cfun is never
null (I'm pretty sure) but when a middle end helper is called
from the C++ front end cfun can be null for a namespace scope
initializer expression. A recent change of mine to the helper
introduced an assumption to the contrary,
On 9/18/21 3:14 PM, Martin Sebor wrote:
On 9/18/21 12:46 PM, Martin Sebor wrote:
On 9/17/21 10:08 PM, Jeff Law wrote:
On 9/17/2021 4:05 PM, Martin Sebor wrote:
On 9/2/21 10:28 AM, Jeff Law via Gcc-patches wrote:
On 8/30/2021 2:03 PM, Martin Sebor via Gcc-patches wrote:
The predicate
On 9/16/21 3:03 AM, Hongtao Liu via Gcc-patches wrote:
On Thu, Sep 16, 2021 at 4:23 PM Richard Biener via Gcc-patches
wrote:
On Thu, 16 Sep 2021, liuhongt wrote:
Ping
rebased on latest trunk.
gcc/ChangeLog:
* common.opt (ftree-vectorize): Add Var(flag_tree_vectorize).
*
On 9/18/21 12:46 PM, Martin Sebor wrote:
On 9/17/21 10:08 PM, Jeff Law wrote:
On 9/17/2021 4:05 PM, Martin Sebor wrote:
On 9/2/21 10:28 AM, Jeff Law via Gcc-patches wrote:
On 8/30/2021 2:03 PM, Martin Sebor via Gcc-patches wrote:
The predicate analysis subset of the tree-ssa-uninit pass
On 9/17/21 10:08 PM, Jeff Law wrote:
On 9/17/2021 4:05 PM, Martin Sebor wrote:
On 9/2/21 10:28 AM, Jeff Law via Gcc-patches wrote:
On 8/30/2021 2:03 PM, Martin Sebor via Gcc-patches wrote:
The predicate analysis subset of the tree-ssa-uninit pass isn't
necessarily specific
On 9/2/21 10:28 AM, Jeff Law via Gcc-patches wrote:
On 8/30/2021 2:03 PM, Martin Sebor via Gcc-patches wrote:
The predicate analysis subset of the tree-ssa-uninit pass isn't
necessarily specific to the detection of uninitialized reads.
Suitably parameterized, the same core logic could be used
On 9/8/21 2:06 PM, Jason Merrill wrote:
On 9/2/21 7:53 PM, Martin Sebor wrote:
@@ -4622,28 +4622,94 @@ warn_for_null_address (location_t location,
tree op, tsubst_flags_t complain)
if (!warn_address
|| (complain & tf_warning) == 0
|| c_inhibit_evaluation_warnings
When computing the size of an object pointed to by the result of
a MIN/MAX_EXPR, the handle_min_max_size() function tries to deal
gracefully with operands that designate distinct objects. But
the handling fails to consider an edge case when one of
the operands is a PHI one of whose operands
On 9/3/21 8:41 AM, Aldy Hernandez via Gcc-patches wrote:
[Andrew, do you see any problem with using the minus relational code
here? It seems like everything matches up.]
I've seen cases in the upcoming jump threader enhancements where we see
a difference of two pointers that are known to be
;
}
But the optimized code doesn't have the second test so I'm not sure
that the address attribute here does what I think it does (I'd
expect the test to be folded to true). If you have a better test
case or other targets for me to try I can look into it some more.
Martin
On 9/2/21 8:39 AM, Martin Sebor wrote
On 8/27/21 5:23 PM, Jeff Law wrote:
On 8/26/2021 1:30 PM, Martin Sebor via Gcc-patches wrote:
On 8/26/21 10:38 AM, Martin Sebor wrote:
On 8/26/21 1:00 AM, Richard Biener wrote:
On Wed, Aug 25, 2021 at 10:03 PM Martin Sebor wrote:
Richard, some time ago you mentioned you'd had trouble
On 9/2/21 7:43 AM, Jason Merrill wrote:
On 9/1/21 6:27 PM, Martin Sebor wrote:
On 9/1/21 3:39 PM, Jason Merrill wrote:
On 9/1/21 4:33 PM, Martin Sebor wrote:
On 9/1/21 1:21 PM, Jason Merrill wrote:
On 8/31/21 10:08 PM, Martin Sebor wrote:
A Coverity run recently uncovered a latent bug
-16T14:10:00-0600, Martin Sebor wrote:
On 8/16/21 6:44 AM, Thomas Schwinge wrote:
On 2021-08-12T17:15:44-0600, Martin Sebor via Gcc wrote:
On 8/6/21 10:57 AM, Thomas Schwinge wrote:
So I'm trying to do some C++... ;-)
Given:
/* A map from SSA names or var decls to record fields
On 9/1/21 1:35 PM, Thomas Schwinge wrote:
Hi!
On 2021-06-23T13:47:08-0600, Martin Sebor via Gcc-patches
wrote:
On 6/22/21 5:28 PM, David Malcolm wrote:
On Tue, 2021-06-22 at 19:18 -0400, David Malcolm wrote:
On Fri, 2021-06-04 at 15:41 -0600, Martin Sebor wrote:
The attached patch
On 9/1/21 3:39 PM, Jason Merrill wrote:
On 9/1/21 4:33 PM, Martin Sebor wrote:
On 9/1/21 1:21 PM, Jason Merrill wrote:
On 8/31/21 10:08 PM, Martin Sebor wrote:
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself: comparing the address of a declared
On 9/1/21 1:21 PM, Jason Merrill wrote:
On 8/31/21 10:08 PM, Martin Sebor wrote:
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself: comparing the address of a declared object
for equality to null, similar to:
int f (void)
{
int a[2][2
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself: comparing the address of a declared object
for equality to null, similar to:
int f (void)
{
int a[2][2];
return == 0;
}
GCC issues -Waddress for this code, but the bug Coverity found
the change below to fix this. I'm testing
an enhancement to -Waddress to let GCC detect it as well.
Martin
commit r12-3268-gb3aa3288a958a75744df256d70e7f8e90ccab724
Author: Martin Sebor
Date: Tue Aug 31 11:16:37 2021 -0600
Avoid valid Coverity warning for comparing array to zero
:26 PM, Martin Sebor wrote:
On 8/25/21 10:14 AM, Andrew MacLeod wrote:
On 8/25/21 11:20 AM, Martin Sebor wrote:
Ping: Andrew, did I answer your questions? Do you (or anyone else)
have any other comments on the latest patch below?
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577865.html
_end_locus,
- location))
-inform (var_loc, "%qD was declared here", var);
+ inform (var_loc, "%qD was declared here", var);
}
struct check_defs_data
Regards
Martin
On 8/27/21 11:30 AM, Richard Biener wrote:
On August 27, 2021 5:20:57 PM GMT+02:00, Martin Sebor wrote:
On 8/27/21 12:23 AM, Richard Biener wrote:
On Thu, Aug 26, 2021 at 9:30 PM Martin Sebor wrote:
On 8/26/21 10:38 AM, Martin Sebor wrote:
On 8/26/21 1:00 AM, Richard Biener wrote:
On Wed, Aug 25, 2021 at 10:03 PM Martin Sebor wrote:
Richard, some time ago you mentioned you'd had trouble
On 8/26/21 10:38 AM, Martin Sebor wrote:
On 8/26/21 1:00 AM, Richard Biener wrote:
On Wed, Aug 25, 2021 at 10:03 PM Martin Sebor wrote:
Richard, some time ago you mentioned you'd had trouble getting
-Wuninitialized to print the note pointing to the uninitialized
variable. I said I'd look
On 8/26/21 1:00 AM, Richard Biener wrote:
On Wed, Aug 25, 2021 at 10:03 PM Martin Sebor wrote:
Richard, some time ago you mentioned you'd had trouble getting
-Wuninitialized to print the note pointing to the uninitialized
variable. I said I'd look into it, and so I did. The attached
patch
On 8/25/21 5:00 PM, Jeff Law wrote:
On 8/25/2021 2:03 PM, Martin Sebor via Gcc-patches wrote:
Richard, some time ago you mentioned you'd had trouble getting
-Wuninitialized to print the note pointing to the uninitialized
variable. I said I'd look into it, and so I did. The attached
patch
On 8/25/21 1:34 PM, Andrew MacLeod wrote:
On 8/25/21 3:15 PM, Martin Sebor wrote:
On 8/25/21 11:46 AM, Andrew MacLeod wrote:
On 8/25/21 1:25 PM, Martin Sebor wrote:
I noticed that the output of -fdump-tree-walloca (and probably all
passes that call gimple_ranger::export_global_ranges
Andrew, based on your remarks in our discussion Re: enable ranger
and caching in pass_waccess, I've added some comments to struct
function and get_range_query() and declared the latter with
attribute returns_nonnull to make it explicit both to readers
and to GCC that the x_range_query member is
On 8/25/21 10:14 AM, Andrew MacLeod wrote:
On 8/25/21 11:20 AM, Martin Sebor wrote:
Ping: Andrew, did I answer your questions? Do you (or anyone else)
have any other comments on the latest patch below?
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577865.html
I wasn't attempting
Richard, some time ago you mentioned you'd had trouble getting
-Wuninitialized to print the note pointing to the uninitialized
variable. I said I'd look into it, and so I did. The attached
patch simplifies the warn_uninit() function to get rid of some
redundant cruft: besides a few pointless
On 8/25/21 11:46 AM, Andrew MacLeod wrote:
On 8/25/21 1:25 PM, Martin Sebor wrote:
I noticed that the output of -fdump-tree-walloca (and probably all
passes that call gimple_ranger::export_global_ranges()) includes
the following two lines for all functions, even when there's
nothing else
I noticed that the output of -fdump-tree-walloca (and probably all
passes that call gimple_ranger::export_global_ranges()) includes
the following two lines for all functions, even when there's
nothing else of relevance after them:
Exported global range table
===
I was a
Ping: Andrew, did I answer your questions? Do you (or anyone else)
have any other comments on the latest patch below?
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577865.html
On 8/20/21 4:16 PM, Martin Sebor wrote:
On 8/20/21 7:09 AM, Andrew MacLeod wrote:
On 8/19/21 7:09 PM, Martin
When determining the properties of objects referenced by a PHI's
arguments, compute_objsize() has logic to filter out null pointers.
It also has special logic that tries to deal with arguments that
refer to the same object (as opposed to different objects). A bug
in the former prevents the
On 8/20/21 7:09 AM, Andrew MacLeod wrote:
On 8/19/21 7:09 PM, Martin Sebor via Gcc-patches wrote:
The attached patch changes the new access warning pass to use
the per-function ranger instance. To do that it makes a number
of the global static functions members of the pass (that involved
On 8/19/21 7:38 PM, Kewen.Lin wrote:
Hi Martin,
on 2021/8/20 上午12:30, Martin Sebor wrote:
On 8/19/21 9:03 AM, Martin Sebor wrote:
On 8/18/21 11:56 PM, Kewen.Lin wrote:
Hi David,
on 2021/8/19 上午11:26, David Edelsohn via Gcc-patches wrote:
Hi, Martin
A few PowerPC-specific testcases started
The attached patch changes the new access warning pass to use
the per-function ranger instance. To do that it makes a number
of the global static functions members of the pass (that involved
moving one to a later point in the file, increasing the diff;
the body of the function hasn't changed
On 8/19/21 9:36 AM, Segher Boessenkool wrote:
On Thu, Aug 19, 2021 at 09:03:44AM -0600, Martin Sebor via Gcc-patches wrote:
On 8/18/21 11:56 PM, Kewen.Lin wrote:
To get rid of GTY variable alloc_object_size_limit looks suspicious,
maybe tree objects returned by alloc_max_size after the change
The changes in last night's patch to the new access warning pass
(somewhat prematurely) included a call to enable_ranger() with no
matching call to disable_ranger(). The two calls must be paired
in order for the latter to release resources allocated by
the former, otherwise the resources leak
Hey Aldy & Andrew,
I introduced a leak by calling enable_ranger() without pairing it
with one to disable_ranger() on the same function (PR 101984).
I didn't realize (or look to see) that enable_ranger() dynamically
allocates memory.
The patch below adds comments to make it clear that the calls
On 8/19/21 9:03 AM, Martin Sebor wrote:
On 8/18/21 11:56 PM, Kewen.Lin wrote:
Hi David,
on 2021/8/19 上午11:26, David Edelsohn via Gcc-patches wrote:
Hi, Martin
A few PowerPC-specific testcases started failing yesterday on AIX with
a strange failure mode: the compiler runs out of memory
On 8/18/21 11:56 PM, Kewen.Lin wrote:
Hi David,
on 2021/8/19 上午11:26, David Edelsohn via Gcc-patches wrote:
Hi, Martin
A few PowerPC-specific testcases started failing yesterday on AIX with
a strange failure mode: the compiler runs out of memory. As you may
expect from telling you this in an
On 8/17/21 2:51 AM, Richard Biener wrote:
On Tue, Aug 17, 2021 at 3:52 AM Martin Sebor via Gcc-patches
wrote:
The attached patch continues with the move of warning code from
builtins.c and calls.c into a more suitable home. As before, it
is mostly free of functional changes. The one
On 8/17/21 12:40 AM, Thomas Schwinge wrote:
Hi!
On 2021-08-16T14:10:00-0600, Martin Sebor wrote:
On 8/16/21 6:44 AM, Thomas Schwinge wrote:
[...], to document the current behavior, I propose to
"Add more self-tests for 'hash_map' with Value type with non-trivial
constructor/destructor&
The attached patch continues with the move of warning code from
builtins.c and calls.c into a more suitable home. As before, it
is mostly free of functional changes. The one exception is that
as pleasant a side-effect, moving the attribute access checking
from initialize_argument_information()
On 8/16/21 6:44 AM, Thomas Schwinge wrote:
Hi!
On 2021-08-12T17:15:44-0600, Martin Sebor via Gcc wrote:
On 8/6/21 10:57 AM, Thomas Schwinge wrote:
So I'm trying to do some C++... ;-)
Given:
/* A map from SSA names or var decls to record fields. */
typedef hash_map field_map_t
On 8/6/21 4:50 AM, Tamar Christina wrote:
Hi All,
The build is broken since a3d3e8c362c2 since it's deleted the ability to pass
vec<> by value and now much be past by reference.
However some language hooks used by AArch64 were not updated and breaks the
build on AArch64. This patch updates
On 7/30/21 9:06 AM, Jason Merrill wrote:
On 7/27/21 2:56 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575690.html
Are there any other suggestions or comments or is the latest revision
okay to commit?
OK.
I had to make a few more adjustments to fix up
-Wmismatched-new-delete partly relies on valid_new_delete_pair_p()
to detect matching calls to operator new and delete. The function
returns a conservative result which, when indicating a mismatch,
the warning then works to make more accurate before it triggers.
As it turns out, the logic is
As I mentioned in the description of the access warning pass when
I submitted it in July(*), I planned to change the -Wstringop-xxx
code in the pass to run on the GIMPLE IL instead of on trees in
builtins.c (and elsewhere). The attached patch implements this
change along with moving more warning
On 8/3/21 1:17 AM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs, because nelts is NOP_EXPR around INTEGER_CST
- it is a VLA whose extent folds into a constant - and get_parm_array_spec
has specific INTEGER_CST handling and otherwise strips nops from nelts
and stores it into a TREE_LIST
The write_only mode to attribute access specifies that the pointer
applies to is used to write to the referenced object but not read
from it.
A function that uses the pointer to read the referenced object might
rely on the contents of uninitialized memory and so such attempts
should be
On 7/30/21 2:21 PM, Tom de Vries wrote:
On 7/30/21 6:17 PM, Martin Sebor wrote:
On 7/28/21 9:20 AM, Tom de Vries wrote:
Hi,
Improve nonnull attribute documentation in a number of ways:
Reorganize discussion of effects into:
- effects for calls to functions with nonnull-marked parameters
On 7/28/21 9:20 AM, Tom de Vries wrote:
Hi,
Improve nonnull attribute documentation in a number of ways:
Reorganize discussion of effects into:
- effects for calls to functions with nonnull-marked parameters, and
- effects for function definitions with nonnull-marked parameters.
This makes it
On 7/29/21 2:26 AM, Andrew Burgess wrote:
* Martin Sebor [2021-07-28 10:16:59 -0600]:
On 7/28/21 5:14 AM, Andrew Burgess wrote:
* Martin Sebor via Gcc-patches [2021-07-19 09:08:35
-0600]:
On 7/17/21 2:36 PM, Jan-Benedict Glaw wrote:
Hi Martin!
On Fri, 2021-06-04 15:27:04 -0600, Martin
On 7/23/21 10:39 AM, Jeff Law wrote:
On 7/22/2021 3:58 PM, Martin Sebor via Gcc-patches wrote:
The code that computes the size of an access to an object in
-Wuninitialized is limited to declared objects and so doesn't
apply to allocated objects, and doesn't correctly account for
an offset
On 7/28/21 3:23 AM, Richard Biener wrote:
On Fri, Jul 16, 2021 at 12:42 AM Martin Sebor via Gcc-patches
wrote:
A number of access warnings as well as their supporting
infrastructure (compute_objsize et al.) are implemented in
builtins.{c,h} where they (mostly) operate on trees and run
just
On 7/28/21 5:14 AM, Andrew Burgess wrote:
* Martin Sebor via Gcc-patches [2021-07-19 09:08:35
-0600]:
On 7/17/21 2:36 PM, Jan-Benedict Glaw wrote:
Hi Martin!
On Fri, 2021-06-04 15:27:04 -0600, Martin Sebor wrote:
This is a revised patch series to add warning control by group and
location
On 7/28/21 8:51 AM, Aldy Hernandez via Gcc-patches wrote:
On 7/28/21 4:32 PM, Jeff Law wrote:
...
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 863f1256811..0e205a41ac3 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -223,6 +223,11 @@ gimple-match.o-warn = -Wno-unused
When mentioning the type of the accessed object -Warray-bounds
treats singleton objects as arrays of one element for simplicity.
But because the code doesn't distinguish between function and
object pointers, a warning for an out-of-bounds index into
a singleton function pointer object attempts to
to operand_equal_p() to look up the parameter's position
in the function declaration based on its name.
commit a0f9a5dcc3bbe6c7de499e17d201d0f2cb512649
Author: Martin Sebor
Date: Tue Jul 27 13:51:55 2021 -0600
Use OEP_DECL_NAME when comparing VLA bounds [PR101585].
Resolves:
PR
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575690.html
Are there any other suggestions or comments or is the latest revision
okay to commit?
On 7/20/21 12:34 PM, Martin Sebor wrote:
On 7/14/21 10:23 AM, Jason Merrill wrote:
On 7/14/21 10:46 AM, Martin Sebor wrote:
On 7/13/21 9
On 7/27/21 9:16 AM, Jonathan Wakely via Gcc-patches wrote:
Should we make this change?
Firstly, these bullet points are full sentences and so should end with
a period (or smiley, in some cases).
I'd expect that to be relatively uncontroversial ;)
Secondly, releases are not issued by the
gcc/
* calls.c (maybe_warn_rdwr_sizes): Correct argument
numbers in warning that were switched.
gcc/testsuite/
* gcc.dg/Wnonnull-4.c: Correct argument numbers in warnings.
I'll defer to Martin Sebor on this.
Martin S., can you cover the review of this patch from Martin U?
The pa
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575377.html
On 7/15/21 4:39 PM, Martin Sebor wrote:
A number of access warnings as well as their supporting
infrastructure (compute_objsize et al.) are implemented in
builtins.{c,h} where they (mostly) operate on trees and run
just
201 - 300 of 3587 matches
Mail list logo
