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 the
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;
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() i
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", see a
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/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/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. As yo
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 n
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 and
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 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 othe
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
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
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 functi
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
moving one to a later point in the file, increasing the diff;
the body of the
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 b
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 of rele
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 nul
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 to
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 ne
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()) includ
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 atta
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 si
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 int
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 get
Hello Nathan & Joern,
Richard has asked me to give you a heads up that we will be enabling
an informational note for all instances of the GCC -Wuninitialized
warning. You added the helpful note pretty much exactly 15 years ago
to the day (in http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=11656
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578135.html
Are there any further comments on the patch?
Richard, you were kind enough to review the first two patches in this
series. Would you mind doing the same for this one? It continues in
the same vein.
Martin
On 8/25/21 3:26
A typo in maybe_warn_alloc_args_overflow() has it compare the address
of an array for equality to null when it actually means to compare
the value of the array's element. This is apparently caught by
Converity (and Jason who pointed it out to me -- thanks again).
In r12-3268 I've pushed the chang
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
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 -
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
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
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
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/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/wraparou
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/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/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/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, 2
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 destructed, all the me
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/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/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
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
The SRA pass relies on the absence of function type attributes
to enable optimization like unused argument elision. The intent
appears to be to avoid messing with the positions of arguments
that may be relied on by some type attributes.
The recent enhancement to detect out-of-bounds accesses by
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
/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 positives when
the element size is greater than one.
In a
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 new warn_parm_ptrarray_mismatch() function can be called even
for invalid source code. It tries to handle some of it by checking
for error_mark_node but that's not enough since some invalid input
can apparently result in nodes being null. I have committed
the patch below to avoid the ICE tha
One of the recently added -Warray-bounds tests fails in ILP32
because the warning code calls build_array_type_nelts(type, zero)
and naively expects it to create an array type that renders as
type[0] in warnings. While that works in LP64, it apparently
isn't enough to produce such a type in other
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
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 *allocate_value_ra
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
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
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
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
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
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. That's correct for
the latter but wrong for
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]; };
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
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 tested as compreh
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
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
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 t
-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
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).
>>>
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
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 more com
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 indices and poin
On 10/5/20 3:51 AM, Aldy Hernandez via Gcc-patches wrote:
The walloca pass is a mess. It has all sorts of heuristics to divine
problematic ranges fed into alloca, none of them very good, and all of
them unreadable. The mess therein was actually one of the original
motivators for the ranger pr
On 10/5/20 8:50 AM, Aldy Hernandez via Gcc-patches wrote:
[Martin, as the original author of this pass, do you have any concerns?]
No concerns, just a few minor things.
This patch converts the -Wrestrict pass to use an on-demand ranger
instead of global ranges.
No effort was made to conver
On 10/6/20 3:45 AM, Aldy Hernandez wrote:
- builtin_memref dstref (dst, dstsize);
- builtin_memref srcref (src, srcsize);
+ builtin_memref dstref (query, call, dst, dstsize);
+ builtin_memref srcref (query, call, src, srcsize);
/* Create a descriptor of the access. This may adjust both
On 10/6/20 8:42 AM, Andrew MacLeod wrote:
On 10/6/20 10:30 AM, Martin Sebor wrote:
On 10/6/20 3:45 AM, Aldy Hernandez wrote:
- builtin_memref dstref (dst, dstsize);
- builtin_memref srcref (src, srcsize);
+ builtin_memref dstref (query, call, dst, dstsize);
+ builtin_memref srcref (query, c
On 10/6/20 1:52 AM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 06, 2020 at 09:37:21AM +0200, Aldy Hernandez via Gcc-patches wrote:
Pushed as obvious.
gcc/ChangeLog:
* value-range.h (irange_allocator::allocate): Increase
newir storage by one.
---
gcc/value-range.h | 2 +-
On 10/5/20 5:12 PM, David Malcolm via Gcc-patches wrote:
This work-in-progress patch generalizes the malloc/free problem-checking
in -fanalyzer so that it can work on arbitrary acquire/release API pairs.
It adds a new __attribute__((deallocated_by(FOO))) that could be used
like this in a library
On 10/5/20 8:18 PM, Andrew MacLeod wrote:
On 10/5/20 4:16 PM, Martin Sebor wrote:
On 10/5/20 8:50 AM, Aldy Hernandez via Gcc-patches wrote:
[Martin, as the original author of this pass, do you have any concerns?]
@@ -1270,7 +1271,21 @@ get_size_range (tree exp, tree range[2], bool
allow_zer
On 10/6/20 11:58 AM, Andrew MacLeod wrote:
On 10/6/20 1:48 PM, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 01:41:54PM -0400, Andrew MacLeod wrote:
On 10/6/20 1:32 PM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 06, 2020 at 10:42:12AM -0600, Martin Sebor wrote:
The manual documents the [
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 indices and pointer offsets the
same:
by adjust
. I don't expect the rebase to
require 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 wro
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
positives when
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555225.html
On 9/30/20 6:14 PM, Martin Sebor wrote:
-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
On 10/7/20 3:01 PM, Jason Merrill wrote:
On 10/7/20 4:11 PM, Martin Sebor wrote:
...
For the various member functions, please include the comments
with the definition as well as the in-class declaration.
Only one access_ref member function is defined out-of-line:
offset_bounded(). I've adj
On 10/8/20 1:40 PM, Jason Merrill wrote:
On 10/8/20 3:18 PM, Martin Sebor wrote:
On 10/7/20 3:01 PM, Jason Merrill wrote:
On 10/7/20 4:11 PM, Martin Sebor wrote:
...
For the various member functions, please include the comments
with the definition as well as the in-class declaration.
Only
On 10/9/20 9:13 AM, Jason Merrill wrote:
On 10/9/20 10:51 AM, Martin Sebor wrote:
On 10/8/20 1:40 PM, Jason Merrill wrote:
On 10/8/20 3:18 PM, Martin Sebor wrote:
On 10/7/20 3:01 PM, Jason Merrill wrote:
On 10/7/20 4:11 PM, Martin Sebor wrote:
...
For the various member functions, please in
On 9/28/22 13:17, Qing Zhao wrote:
Hi, Martin,
Thanks for the comments. And sorry for my late reply till now (I just came back
home from LPC, GNU Cauldron and then a one-week vacation after that…)
On Sep 12, 2022, at 12:42 PM, Martin Sebor wrote:
On 9/6/22 18:28, Qing Zhao wrote:
Add the f
On 3/1/22 11:41, Jakub Jelinek wrote:
Hi!
The following testcase emits bogus -Wdangling-pointer warnings.
The bug is that when it sees that ptr immediate use is a call that
returns one of its arguments, it will assume that the return value
is based on ptr, but that is the case only if ptr is pas
Pinging the two patches here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590230.html
On 2/10/22 16:04, Martin Sebor wrote:
On 2/8/22 15:37, Jason Merrill wrote:
On 2/8/22 16:59, Martin Sebor wrote:
Transforming a by-value arguments to by-reference as GCC does for some
class types
The -Wdangling-pointer code tests the EDGE_DFS_BACK but the pass never
calls the mark_dfs_back_edges() function that initializes the bit (I
didn't know about it). As a result the bit is not set when expected,
which can cause false positives under the right conditions.
The attached patch adds a c
On 3/3/22 01:01, Jakub Jelinek wrote:
On Wed, Mar 02, 2022 at 04:15:09PM -0700, Martin Sebor via Gcc-patches wrote:
The -Wdangling-pointer code tests the EDGE_DFS_BACK but the pass never
calls the mark_dfs_back_edges() function that initializes the bit (I
didn't know about it). As a resul
On 3/14/22 23:31, Siddhesh Poyarekar wrote:
The size argument in strncmp only describe the maximum length to which
to compare two strings and is not an indication of sizes of the two
source strings. Do not warn if it is larger than the two input strings
because it is entirely likely that the siz
On 3/15/22 10:40, Siddhesh Poyarekar wrote:
On 15/03/2022 21:09, Martin Sebor wrote:
The strncmp function takes arrays as arguments (not necessarily
strings). The main purpose of the -Wstringop-overread warning
for calls to it is to detect calls where one of the arrays is
not a nul-terminated s
On 3/9/22 06:17, Richard Biener wrote:
On Fri, Feb 11, 2022 at 12:05 AM Martin Sebor via Gcc-patches
wrote:
On 2/8/22 15:37, Jason Merrill wrote:
On 2/8/22 16:59, Martin Sebor wrote:
Transforming a by-value arguments to by-reference as GCC does for some
class types can trigger -Wdangling
On 3/15/22 19:24, Siddhesh Poyarekar wrote:
On 16/03/2022 02:06, Martin Sebor wrote:
The intended use of the strncmp bound is to limit the comparison to
at most the size of the arrays or (in a subset of cases) the length
of an initial substring. Providing an arbitrary bound that's not
related to
On 3/17/22 11:22, Siddhesh Poyarekar wrote:
On 17/03/2022 22:16, Jeff Law wrote:
#include
char a[] = "abc";
char b[] = "abcd";
int f (void)
{
return strncmp (a, b, 8);
}
where I get
t.c:7:10: warning: ‘strncmp’ specified bound 8 exceeds source size 5
On 3/17/22 12:02, Siddhesh Poyarekar wrote:
On 17/03/2022 23:21, Martin Sebor wrote:
On 3/17/22 11:22, Siddhesh Poyarekar wrote:
On 17/03/2022 22:16, Jeff Law wrote:
#include
char a[] = "abc";
char b[] = "abcd";
int f (void)
{
return strncmp (a, b, 8);
}
w
On 3/23/22 07:01, David Malcolm wrote:
On Mon, 2022-03-14 at 16:18 -0600, Martin Sebor wrote:
On 3/9/22 14:57, David Malcolm via Gcc wrote:
On Wed, 2022-03-09 at 13:30 -0800, Andrew Pinski wrote:
On Wed, Mar 9, 2022 at 1:25 PM David Malcolm via Gcc
wrote:
We gained __attribute__ ((access, .
On 3/25/22 12:45, David Malcolm wrote:
On Wed, 2022-03-23 at 17:52 +0100, Sebastian Huber wrote:
On 23/03/2022 17:31, Martin Sebor via Gcc-patches wrote:
The concern is that the constraints implied by atttributes access
and
nonnull are independent of each other. I would suggest to document
On 3/29/22 03:24, Thomas Schwinge wrote:
Hi!
On 2022-01-15T17:00:11-0700, Martin Sebor via Gcc-patches
wrote:
On 1/11/22 15:40, Jason Merrill wrote:
On 11/30/21 17:32, Martin Sebor via Gcc-patches wrote:
[default setting of the option]
Let's put =2 in -Wall for now.
I'v
On 4/6/22 03:23, Richard Biener wrote:
This avoids -Wvector-operation-performance diagnostics for vectorizer
produced code. It's unfortunate the warning_at code in
tree-vect-generic.cc needs adjustments but the diagnostic suppression
code doesn't magically suppress those otherwise.
It seems li
101 - 200 of 1046 matches
Mail list logo
