On 7/1/22 08:01, Qing Zhao wrote:
On Jul 1, 2022, at 8:59 AM, Jakub Jelinek wrote:
On Fri, Jul 01, 2022 at 12:55:08PM +, Qing Zhao wrote:
If so, comparing to the current implemenation to have all the checking in
middle-end, what’s the
major benefit of moving part of the checking into F
On 1/21/21 10:34 AM, Florian Weimer wrote:
* Martin Sebor via Gcc-patches:
This patch depends on the fix for PR 98664 (already approved but
not yet checked in). I've tested it on x86_64-linux.
To avoid fallout I tried to keep the changes to a minimum, and
so the design isn't as rob
On 1/21/21 12:01 PM, Florian Weimer wrote:
* Martin Sebor:
On 1/21/21 10:34 AM, Florian Weimer wrote:
* Martin Sebor via Gcc-patches:
This patch depends on the fix for PR 98664 (already approved but
not yet checked in). I've tested it on x86_64-linux.
To avoid fallout I tried to kee
On 1/18/21 6:25 AM, Richard Biener wrote:
PS Here are my notes on the macros and the two related functions:
BLOCK: Denotes a lexical scope. Contains BLOCK_VARS of variables
declared in it, BLOCK_SUBBLOCKS of scopes nested in it, and
BLOCK_CHAIN pointing to the next BLOCK. Its BLOCK_SUPERCONTEX
The hack I put in compute_objsize() last January for pr93200 isn't
quite correct. It happened to suppress the false positive there
but, due to what looks like a thinko on my part, not in some other
test cases involving vectorized stores.
The attached change adjusts the hack to have compute_objsi
The initial patch I posted is missing initialization for a couple
of locals. I'd noticed it in testing but forgot to add the fix to
the patch before posting it. I have corrected that in the updated
revision and also added the test case from pr98512, and retested
the whole thing on x86_64-linux.
Attached is another attempt to fix the problem caused by allowing
front-end trees representing nontrivial VLA bound expressions to
stay in attribute access attached to functions. Since removing
these trees seems to be everyone's preference this patch does that
by extending the free_lang_data pass
Attached is an updated patch for both tree.h and the internals manual
documenting the most important BLOCK_ macros and what they represent.
On 1/21/21 2:52 PM, Martin Sebor wrote:
On 1/18/21 6:25 AM, Richard Biener wrote:
PS Here are my notes on the macros and the two related functions:
BLOCK:
Calling strncpy in libiberty's dyn_string_insert() with the last
argument equal to the length of the second triggers the warning:
/src/gcc/master/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output
truncated before terminating nul copying as many bytes from a string as
its length [-Wstringo
On 1/28/21 1:31 AM, Richard Biener wrote:
On Thu, Jan 28, 2021 at 12:08 AM Martin Sebor via Gcc-patches
wrote:
Attached is another attempt to fix the problem caused by allowing
front-end trees representing nontrivial VLA bound expressions to
stay in attribute access attached to functions
On 1/28/21 2:22 AM, Jakub Jelinek wrote:
On Thu, Jan 28, 2021 at 09:31:46AM +0100, Richard Biener via Gcc-patches wrote:
+ if (TREE_CODE (bound) == PLUS_EXPR
+ && integer_all_onesp (TREE_OPERAND (bound, 1)))
+{
+ bound = TREE_OPERAND (bound, 0);
+ if (TREE_CODE (bound) == NOP
The GCC 11 -Warray-bounds enhancement to diagnose accesses whose
leading offset is in bounds but whose trailing offset is not has
been causing some confusion. When the warning is issued for
an access to an in-bounds member via a pointer to a struct that's
larger than the pointed-to object, phrasi
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564059.html
On 1/21/21 4:38 PM, Martin Sebor wrote:
The hack I put in compute_objsize() last January for pr93200 isn't
quite correct. It happened to suppress the false positive there
but, due to what looks like a thinko on my part, no
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563894.html
On 1/19/21 5:56 PM, Martin Sebor wrote:
Similar to the problem reported for -Wstringop-overflow in pr98266
and already fixed, -Warray-bounds is also susceptible to false
positives in assignments and copies involving virtual
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html
On 1/21/21 4:46 PM, Martin Sebor wrote:
The initial patch I posted is missing initialization for a couple
of locals. I'd noticed it in testing but forgot to add the fix to
the patch before posting it. I have corrected tha
The initial -Wnonnull implementation in the middle end took place
too late in the pipeline (just before expansion), and as a result
was prone to false positives (bug 78817). In an attempt to avoid
the worst of those, the warning was moved to the ccp2 pass in
r243874. However, as the test case in
On 1/30/21 12:36 AM, Eric Gallager wrote:
On Thu, Jan 28, 2021 at 6:04 PM Martin Sebor via Gcc-patches
wrote:
The GCC 11 -Warray-bounds enhancement to diagnose accesses whose
leading offset is in bounds but whose trailing offset is not has
been causing some confusion. When the warning is
The warning reported in PR 98835 is a true positive but there was
no test for this aspect of it. I have added one on the attached
diff.
Martin
commit c2f8e378d64f65645e5f9c41a8221ca102c71208
Author: Martin Sebor
Date: Mon Feb 1 08:42:58 2021 -0700
Verify a warning for a class with a ref-
On 1/28/21 1:59 PM, Martin Sebor wrote:
On 1/28/21 1:31 AM, Richard Biener wrote:
On Thu, Jan 28, 2021 at 12:08 AM Martin Sebor via Gcc-patches
wrote:
Attached is another attempt to fix the problem caused by allowing
front-end trees representing nontrivial VLA bound expressions to
stay in
I have pushed the tree.h comments in g:6a2053773b8. I will wait
for an approval of the changes to the manual.
On 1/27/21 5:54 PM, Martin Sebor wrote:
Attached is an updated patch for both tree.h and the internals manual
documenting the most important BLOCK_ macros and what they represent.
On 1
On 2/1/21 9:27 AM, Jakub Jelinek wrote:
On Mon, Feb 01, 2021 at 09:11:20AM -0700, Martin Sebor via Gcc-patches wrote:
Because free_lang_data only frees anything when LTO is enabled and
we want these trees cleared regardless to keep them from getting
clobbered during gimplification, this change
The strlen pass initializes its pointer_query member object with
a cache consisting of a couple of vec's. Because vec doesn't
implement RAII its memory must be explicitly released to avoid
memory leaks. The attached patch adds a dtor to
the strlen_dom_walker to do that.
Tested on x86_64-linux a
On 2/2/21 2:29 PM, David Malcolm wrote:
On Tue, 2021-02-02 at 12:57 -0700, Martin Sebor via Gcc-patches wrote:
The strlen pass initializes its pointer_query member object with
a cache consisting of a couple of vec's. Because vec doesn't
implement RAII its memory must be explicitly r
On 2/3/21 5:01 AM, Richard Biener wrote:
On Mon, Feb 1, 2021 at 5:20 PM Martin Sebor wrote:
I have pushed the tree.h comments in g:6a2053773b8. I will wait
for an approval of the changes to the manual.
Sorry for not looking earlier.
Sorry, I thought you were fine with the text after your
On 2/3/21 2:57 PM, Jeff Law wrote:
On 1/28/21 4:03 PM, Martin Sebor wrote:
The GCC 11 -Warray-bounds enhancement to diagnose accesses whose
leading offset is in bounds but whose trailing offset is not has
been causing some confusion. When the warning is issued for
an access to an in-bounds me
The test case in the bug report shows that the C front end is
too permissive in accepting invalid redeclarations that involve
an incomplete enum and an otherwise compatible integer type as
return types of a function without a prototype, or as types of
an ordinary variable. For example, the redecl
On 2/3/21 5:15 PM, Joseph Myers wrote:
On Wed, 3 Feb 2021, Martin Sebor via Gcc-patches wrote:
+/* Return true of T1 and T2 are matching types for the purposes of
+ redeclaring a variable or a function without a prototype (i.e.,
+ considering just its return type). */
I think this
On 2/4/21 9:48 AM, Martin Sebor wrote:
On 2/3/21 5:15 PM, Joseph Myers wrote:
On Wed, 3 Feb 2021, Martin Sebor via Gcc-patches wrote:
+/* Return true of T1 and T2 are matching types for the purposes of
+ redeclaring a variable or a function without a prototype (i.e.,
+ considering just
Ping 2:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html
On 1/29/21 7:56 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html
On 1/21/21 4:46 PM, Martin Sebor wrote:
The initial patch I posted is missing initialization for a coupl
Ping 2:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563894.html
On 1/29/21 10:22 AM, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563894.html
On 1/19/21 5:56 PM, Martin Sebor wrote:
Similar to the problem reported for -Wstringop-overflow in pr98
Ping 2:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564059.html
On 1/29/21 10:20 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564059.html
On 1/21/21 4:38 PM, Martin Sebor wrote:
The hack I put in compute_objsize() last January for pr93200 is
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564597.html
On 1/31/21 5:31 PM, Martin Sebor wrote:
The initial -Wnonnull implementation in the middle end took place
too late in the pipeline (just before expansion), and as a result
was prone to false positives (bug 78817). In an
On 2/4/21 1:48 AM, Richard Biener wrote:
On Wed, Feb 3, 2021 at 6:12 PM Martin Sebor wrote:
On 2/3/21 5:01 AM, Richard Biener wrote:
On Mon, Feb 1, 2021 at 5:20 PM Martin Sebor wrote:
I have pushed the tree.h comments in g:6a2053773b8. I will wait
for an approval of the changes to the man
I noticed typos in the example of the new form of attribute malloc.
I pushed the attached patch to correct them.
Martin
commit fe2034e9c039c998fc5da730ed531c61cf2e0b7d
Author: Martin Sebor
Date: Sun Feb 7 17:21:32 2021 -0700
Correct typos in attribute malloc documentation.
gcc/Ch
On 2/8/21 12:59 PM, Jeff Law wrote:
On 1/19/21 5:56 PM, Martin Sebor via Gcc-patches wrote:
Similar to the problem reported for -Wstringop-overflow in pr98266
and already fixed, -Warray-bounds is also susceptible to false
positives in assignments and copies involving virtual inheritance
On 2/8/21 3:26 PM, Jeff Law wrote:
On 2/8/21 2:56 PM, Martin Sebor wrote:
On 2/8/21 12:59 PM, Jeff Law wrote:
On 1/19/21 5:56 PM, Martin Sebor via Gcc-patches wrote:
Similar to the problem reported for -Wstringop-overflow in pr98266
and already fixed, -Warray-bounds is also susceptible to
On 2/8/21 12:09 PM, Jeff Law wrote:
On 2/3/21 3:45 PM, Martin Sebor wrote:
On 2/3/21 2:57 PM, Jeff Law wrote:
On 1/28/21 4:03 PM, Martin Sebor wrote:
The GCC 11 -Warray-bounds enhancement to diagnose accesses whose
leading offset is in bounds but whose trailing offset is not has
been causi
On 2/9/21 12:41 AM, Richard Biener wrote:
On Tue, Feb 9, 2021 at 1:04 AM Martin Sebor via Gcc-patches
wrote:
On 2/8/21 12:09 PM, Jeff Law wrote:
On 2/3/21 3:45 PM, Martin Sebor wrote:
On 2/3/21 2:57 PM, Jeff Law wrote:
On 1/28/21 4:03 PM, Martin Sebor wrote:
The GCC 11 -Warray-bounds
On 2/8/21 4:11 PM, Jeff Law wrote:
On 2/8/21 3:44 PM, Martin Sebor wrote:
On 2/8/21 3:26 PM, Jeff Law wrote:
On 2/8/21 2:56 PM, Martin Sebor wrote:
On 2/8/21 12:59 PM, Jeff Law wrote:
On 1/19/21 5:56 PM, Martin Sebor via Gcc-patches wrote:
Similar to the problem reported for
On 2/8/21 4:26 PM, Jeff Law wrote:
On 2/8/21 4:07 PM, Martin Sebor wrote:
On 2/8/21 12:09 PM, Jeff Law wrote:
On 2/3/21 3:45 PM, Martin Sebor wrote:
On 2/3/21 2:57 PM, Jeff Law wrote:
On 1/28/21 4:03 PM, Martin Sebor wrote:
The GCC 11 -Warray-bounds enhancement to diagnose accesses who
I pushed the attached change documenting my GCC 11 changes.
I validated the file on https://validator.w3.org.
Martin
commit cf0d4e41a94bae204a8c5d2490063d58cdb1d4e3
Author: Martin Sebor
Date: Tue Feb 9 17:12:16 2021 -0700
Update new attribute malloc and document new and enhanced warnings
While editing changes.html I noticed a few missing links to the user
manual. I've pushed the attached change to add them.
Martin
commit 5a57e261bcfbb7691901bdf219ba114b449b690e
Author: Martin Sebor
Date: Tue Feb 9 17:40:01 2021 -0700
Move -Wtsan under New Warnings. Add more links to the
The attached patch replaces calls to print_generic_expr_to_str() with
a helper function that returns a std::string and releases the caller
from the responsibility to explicitly free memory.
With the patch installed, Valgrind shows more leaks in this code that
I'm not sure what to do about:
1) A
On 2/10/21 3:39 AM, Richard Biener wrote:
On Tue, Feb 9, 2021 at 4:37 PM Martin Sebor wrote:
On 2/9/21 12:41 AM, Richard Biener wrote:
On Tue, Feb 9, 2021 at 1:04 AM Martin Sebor via Gcc-patches
wrote:
On 2/8/21 12:09 PM, Jeff Law wrote:
On 2/3/21 3:45 PM, Martin Sebor wrote:
On 2/3
The bug was resolved by r11-4745. I pushed the test in r11-7180.
Martin
commit 21c6ad7a12fecc4c85ac26289d9096379b550585
Author: Martin Sebor
Date: Wed Feb 10 14:42:22 2021 -0700
Add test for PR tree-optimization/92879.
gcc/testsuite/ChangeLog:
PR tree-optimizati
On 2/10/21 3:33 PM, Marek Polacek wrote:
We ICE in handle_assume_aligned_attribute since r271338 which added
@@ -2935,8 +2936,8 @@ handle_assume_aligned_attribute (tree *node, tree name,
tree args, int,
/* The misalignment specified by the second argument
must be non-ne
On 2/11/21 12:59 AM, Richard Biener wrote:
On Wed, Feb 10, 2021 at 6:16 PM Martin Sebor wrote:
The attached patch replaces calls to print_generic_expr_to_str() with
a helper function that returns a std::string and releases the caller
from the responsibility to explicitly free memory.
I don't
On 2/11/21 1:09 AM, Richard Biener wrote:
On Wed, Feb 10, 2021 at 7:03 PM Martin Sebor wrote:
On 2/10/21 3:39 AM, Richard Biener wrote:
On Tue, Feb 9, 2021 at 4:37 PM Martin Sebor wrote:
On 2/9/21 12:41 AM, Richard Biener wrote:
On Tue, Feb 9, 2021 at 1:04 AM Martin Sebor via Gcc-patches
While trawling through old bugs I came across one from 2005: PR 21433
- The COMPONENT_REF case of expand_expr_real_1 is probably wrong.
The report looks correct in that argument 0 in COMPONENT_REF cannot
be a CONSTRUCTOR. In my tests it's only been one of the following
codes:
array_ref
comp
On 2/12/21 2:09 AM, Richard Biener via Gcc-patches wrote:
On Thu, Feb 11, 2021 at 6:41 PM Martin Liška wrote:
Hello.
This fixes 2 memory leaks I noticed.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
OK.
Thanks,
Martin
gcc/ChangeLog:
On 2/12/21 12:35 AM, Richard Biener wrote:
On Thu, Feb 11, 2021 at 7:35 PM Martin Sebor wrote:
On 2/11/21 12:59 AM, Richard Biener wrote:
On Wed, Feb 10, 2021 at 6:16 PM Martin Sebor wrote:
The attached patch replaces calls to print_generic_expr_to_str() with
a helper function that returns
On 2/12/21 9:56 AM, Martin Sebor wrote:
On 2/12/21 2:09 AM, Richard Biener via Gcc-patches wrote:
On Thu, Feb 11, 2021 at 6:41 PM Martin Liška wrote:
Hello.
This fixes 2 memory leaks I noticed.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
On 2/12/21 12:36 PM, Richard Biener wrote:
On February 12, 2021 7:21:25 PM GMT+01:00, Martin Sebor
wrote:
On 2/12/21 12:35 AM, Richard Biener wrote:
On Thu, Feb 11, 2021 at 7:35 PM Martin Sebor
wrote:
On 2/11/21 12:59 AM, Richard Biener wrote:
On Wed, Feb 10, 2021 at 6:16 PM Martin Sebor
The test case in PR 99074 invokes dynamic_cast with the this pointer
in a non-static member function called on a null pointer. The call
is, of course, undefined and other different circumstances would be
diagnosed by -Wnonnull. Unfortunately, in the test case, the null
pointer is the result of
Ping 3:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html
I submitted this as a fix for a fair number of false positives
reported by Fedora package maintainers. Last week Jakub committed
r11-7146, which is an alternate workaround for the same problem,
but one isolated to libstdc
Ping 3:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564059.html
This is a fix for two P2 bugs (false positives).
On 2/6/21 10:13 AM, Martin Sebor wrote:
Ping 2:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564059.html
On 1/29/21 10:20 AM, Martin Sebor wrote:
Ping: http
On 2/15/21 7:39 AM, Richard Biener wrote:
On Mon, Feb 15, 2021 at 2:46 PM Martin Liška wrote:
On 2/12/21 5:56 PM, Martin Sebor wrote:
On 2/12/21 2:09 AM, Richard Biener via Gcc-patches wrote:
On Thu, Feb 11, 2021 at 6:41 PM Martin Liška wrote:
Hello.
This fixes 2 memory leaks I noticed.
On 2/10/21 5:24 PM, Marek Polacek via Gcc-patches wrote:
On Wed, Feb 10, 2021 at 03:54:52PM -0700, Martin Sebor via Gcc-patches wrote:
On 2/10/21 3:33 PM, Marek Polacek wrote:
We ICE in handle_assume_aligned_attribute since r271338 which added
@@ -2935,8 +2936,8
-Warray-bounds makes a couple of assumptions about arrays that hold
neither for VLAs of zero-length arrays nor for zero-length arrays
of VLAs. The attached patch removes these assumptions and simplifies
the code that deals with them in the process.
This resolves a P2 GCC 9-11 regression so I'm l
On 2/17/21 6:56 AM, Jakub Jelinek wrote:
On Tue, Feb 16, 2021 at 08:34:41PM -0700, Martin Sebor via Gcc-patches wrote:
+ if (integer_all_onesp (nelts))
+ /* Zero length array. */
+ eltsize = 0;
+ else
{
- tree bnds
On 2/17/21 3:12 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
check_mem_ref builds artificial arrays for variables that don't have
array type.
The C standard says:
"For the purposes of these operators, a pointer to an object that is not an
element of an
array behaves the same as a pointer to the
On 2/17/21 1:47 PM, Jakub Jelinek wrote:
On Wed, Feb 17, 2021 at 01:27:55PM -0700, Martin Sebor wrote:
Not in this patch, but I've looked at what maxobjsize is and wonder why
the roundtrip tree -> HOST_WIDE_INT -> offset_int:
const offset_int maxobjsize = tree_to_shwi (max_object_size ());
Ca
On 2/17/21 1:56 PM, Jakub Jelinek wrote:
On Wed, Feb 17, 2021 at 01:38:56PM -0700, Martin Sebor wrote:
- reftype = build_array_type_nelts (reftype, 1);
+ {
+ if (overaligned_type_p (reftype))
+ reftype = TYPE_MAIN_VARIANT (reftype);
+ reftype = build_array_t
On 2/18/21 2:30 AM, Jakub Jelinek wrote:
On Wed, Feb 17, 2021 at 02:11:43PM -0700, Martin Sebor wrote:
On 2/17/21 1:47 PM, Jakub Jelinek wrote:
On Wed, Feb 17, 2021 at 01:27:55PM -0700, Martin Sebor wrote:
Not in this patch, but I've looked at what maxobjsize is and wonder why
the roundtrip tr
On 2/18/21 3:58 AM, Ayush Mittal via Gcc-patches wrote:
Dynamic memory referenced by 'buffer' was allocated using xmalloc but fails to
free it
when jump to 'error' label.
Issue as per static analysis tool.
The change looks okay to me although I can't approve it. Since GCC
is a regression fix
On 2/18/21 11:03 AM, Jakub Jelinek wrote:
On Thu, Feb 18, 2021 at 07:00:52PM +0100, Jakub Jelinek wrote:
The size of the VLA is zero regardless of its bound and accessing
it is invalid so the warning is expected.
Yes, some warning, but not the one you are giving, that is nonsensical.
Array sub
The "writing one too many bytes" form of -Wstringop-overflow is
designed to trigger for strcpy(d, s) calls into allocated destinations
whose size is the result of (or depends on) strlen(s). But the warning
is in code that's also called from handlers for bounded functions like
memcpy and strncpy,
On 2/18/21 2:22 AM, Richard Biener wrote:
On Tue, Feb 16, 2021 at 5:09 PM Martin Sebor wrote:
On 2/15/21 7:39 AM, Richard Biener wrote:
On Mon, Feb 15, 2021 at 2:46 PM Martin Liška wrote:
On 2/12/21 5:56 PM, Martin Sebor wrote:
On 2/12/21 2:09 AM, Richard Biener via Gcc-patches wrote:
On
The fix for PR 97172 that removes non-constant VLA bounds from
attribute access is incomplete: it inadvertently removes the bounds
corresponding to just the first VLA argument, and not from subsequent
arguments.
The attached change removes the vestigial condition that causes this
bug. Since it's
On 2/18/21 8:51 PM, Jeff Law wrote:
On 2/18/21 7:23 PM, Martin Sebor wrote:
The fix for PR 97172 that removes non-constant VLA bounds from
attribute access is incomplete: it inadvertently removes the bounds
corresponding to just the first VLA argument, and not from subsequent
arguments.
The a
On 2/19/21 2:48 AM, Franz Sirl wrote:
Am 2021-02-01 um 01:31 schrieb Martin Sebor via Gcc-patches:
The initial -Wnonnull implementation in the middle end took place
too late in the pipeline (just before expansion), and as a result
was prone to false positives (bug 78817). In an attempt to
Ping 4:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564059.html
On 2/14/21 5:43 PM, Martin Sebor wrote:
Ping 3:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564059.html
This is a fix for two P2 bugs (false positives).
On 2/6/21 10:13 AM, Martin Sebor wrote:
Ping 2:
htt
On 2/22/21 4:08 PM, Jason Merrill wrote:
On 2/13/21 7:31 PM, Martin Sebor wrote:
The test case in PR 99074 invokes dynamic_cast with the this pointer
in a non-static member function called on a null pointer. The call
is, of course, undefined and other different circumstances would be
diagnosed
On 2/22/21 5:48 PM, Hans-Peter Nilsson wrote:
Looking at commit de05c19d5fd6, that adjustment to these
tests apparently assumed that the testsuite is run (only) on
targets where structure memory layout has padding as per
"natural alignment". For cris-elf, a target with no padding
in structure me
5:56 PM, Martin Sebor via Gcc-patches wrote:
Similar to the problem reported for -Wstringop-overflow in pr98266
and already fixed, -Warray-bounds is also susceptible to false
positives in assignments and copies involving virtual inheritance.
Because the two warnings don't share code yet (hope
Adding attribute access to declarations of functions that take
VLA arguments relies on the front end adding attribute "arg spec"
to each VLA parameter. Like the VLA bounds in attribute access,
the same VLA bounds in attribute "arg spec" can cause trouble
during LTO streaming which expects front e
On 2/22/21 7:03 PM, Jason Merrill wrote:
On 2/22/21 8:00 PM, Martin Sebor wrote:
On 2/22/21 4:08 PM, Jason Merrill wrote:
On 2/13/21 7:31 PM, Martin Sebor wrote:
The test case in PR 99074 invokes dynamic_cast with the this pointer
in a non-static member function called on a null pointer. The
/8/21 2:56 PM, Martin Sebor wrote:
On 2/8/21 12:59 PM, Jeff Law wrote:
On 1/19/21 5:56 PM, Martin Sebor via Gcc-patches wrote:
Similar to the problem reported for -Wstringop-overflow in pr98266
and already fixed, -Warray-bounds is also susceptible to false
positives in assignments and copies
In r11-6900 (PR 98646 - static_cast confuses -Wnonnull) we decided
that issuing -Wnonnull for dereferencing the result of dynamic_cast
was helpful despite the false positives it causes when the pointer
is guaranteed not to be null because of a prior test.
The test case in PR 99251 along with the
On 2/24/21 5:13 AM, Jakub Jelinek via Gcc-patches wrote:
On Wed, Feb 24, 2021 at 11:50:10AM +0100, Richard Biener wrote:
In the PR using NOP_EXPR has been discussed as one possibility and has been
rejected because at expansion it will emit a superfluous & 1 operation.
I still think it is a good
On 2/25/21 9:06 AM, Christophe Lyon wrote:
Hi,
On Wed, 24 Feb 2021 at 09:57, Richard Biener via Gcc-patches
wrote:
On Tue, Feb 23, 2021 at 8:53 PM Martin Sebor via Gcc-patches
wrote:
Adding attribute access to declarations of functions that take
VLA arguments relies on the front end
On 2/24/21 8:13 PM, Jason Merrill wrote:
On 2/24/21 5:25 PM, Martin Sebor wrote:
In r11-6900 (PR 98646 - static_cast confuses -Wnonnull) we decided
that issuing -Wnonnull for dereferencing the result of dynamic_cast
was helpful despite the false positives it causes when the pointer
is guaranteed
The documentation change made for pr83023 - branch probabilities
pessimize malloc, introduced an ambiguity into the description of
attribute malloc pointed out in pr99295.
The change suggests that GCC assumes that most calls only to malloc
and calloc but not to realloc return non-null. Subsequen
:
On 2/8/21 3:44 PM, Martin Sebor wrote:
On 2/8/21 3:26 PM, Jeff Law wrote:
On 2/8/21 2:56 PM, Martin Sebor wrote:
On 2/8/21 12:59 PM, Jeff Law wrote:
On 1/19/21 5:56 PM, Martin Sebor via Gcc-patches wrote:
Similar to the problem reported for -Wstringop-overflow in
pr98266
and already fixed
On 2/25/21 4:40 PM, Jeff Law wrote:
On 2/8/21 3:44 PM, Martin Sebor wrote:
I think the underlying problem is the same. We're getting a size
that doesn't correspond to what's actually being accessed, and it
happens because of the virtual inheritance. In pr97595 Jason
suggested to use the dec
On 3/1/21 1:33 PM, Jason Merrill wrote:
On 3/1/21 12:10 PM, Martin Sebor wrote:
On 2/24/21 8:13 PM, Jason Merrill wrote:
On 2/24/21 5:25 PM, Martin Sebor wrote:
In r11-6900 (PR 98646 - static_cast confuses -Wnonnull) we decided
that issuing -Wnonnull for dereferencing the result of dynamic_cas
Ping 5:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564059.html
On 2/22/21 5:20 PM, Martin Sebor wrote:
Ping 4:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564059.html
On 2/14/21 5:43 PM, Martin Sebor wrote:
Ping 3:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/5
On 3/2/21 3:39 AM, Richard Biener wrote:
On Fri, Jan 22, 2021 at 12:39 AM Martin Sebor via Gcc-patches
wrote:
The hack I put in compute_objsize() last January for pr93200 isn't
quite correct. It happened to suppress the false positive there
but, due to what looks like a thinko on my
On 3/2/21 9:52 AM, Jeff Law via Gcc-patches wrote:
On 3/1/21 1:39 AM, Richard Biener wrote:
The default diagnostic tree printer relies on dump_generic_node which
for some reason manages to clobber the diagnostic pretty-printer state
so we see garbled diagnostics like
/home/rguenther/src/trunk
In PR 99276 a translator points out malformed warning message newly
introduced into GCC 11. In r11-7460 I have committed the attached
patch to remove the stray text.
Martin
commit e7ca37649e4f322e7512c6d11813992c61b0a4b3
Author: Martin Sebor
Date: Tue Mar 2 13:37:01 2021 -0700
PR middle-
]
On 2/9/21 10:49 AM, Martin Sebor wrote:
On 2/8/21 4:11 PM, Jeff Law wrote:
On 2/8/21 3:44 PM, Martin Sebor wrote:
On 2/8/21 3:26 PM, Jeff Law wrote:
On 2/8/21 2:56 PM, Martin Sebor wrote:
On 2/8/21 12:59 PM, Jeff Law wrote:
On 1/19/21 5:56 PM, Martin Sebor via Gcc-patches wrote
On 3/3/21 3:31 AM, Richard Biener wrote:
On Tue, Mar 2, 2021 at 9:23 PM Martin Sebor wrote:
On 3/2/21 3:39 AM, Richard Biener wrote:
On Fri, Jan 22, 2021 at 12:39 AM Martin Sebor via Gcc-patches
wrote:
The hack I put in compute_objsize() last January for pr93200 isn't
quite correct
On 3/3/21 10:33 PM, Jason Merrill wrote:
On 3/3/21 6:20 PM, Martin Sebor wrote:
...
I see what you mean, thanks, but I can't think of a test case to
trigger a false negative due to the smaller offset. Any suggestions?
My only ideas involve undefined behavior, casting the address to a
pointe
On 3/5/21 3:03 PM, Jason Merrill via Gcc-patches wrote:
On 3/4/21 9:37 PM, Marek Polacek wrote:
This PR complains that we issue a -Wconversion warning in
template struct X {};
template X foo();
saying "conversion from 'long unsigned int' to 'int' may change value".
While it's not techn
Attached is a revised patch with three changes:
1) use wi::to_offset (max_object_size ()) instead of tree_to_shwi()
as requested,
2) avoid warning for accesses to elements of arrays of empty types
(PR 99475 that I noticed while testing the original patch),
3) include the size of the destina
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 diagnose
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 t
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
-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 inad
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 cod
1 - 100 of 1046 matches
Mail list logo
