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
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
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
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
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
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 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
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 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
git a/libiberty/ChangeLog b/libiberty/ChangeLog
index e472553..96cacba 100644
--- a/libiberty/ChangeLog
+++ b/libiberty/ChangeLog
@@ -1,3 +1,7 @@
+2021-02-18 Ayush Mittal
+
+ * argv.c (expandargv): Fix memory leak for buffer allocated to read
file contents.
+
2021-02-01 Martin Seb
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 roun
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
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_
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 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
-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/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
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
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
cares about this) if you consider this
patch too intrusive at this point let me know and I'll stop pinging
it and resubmit it for GCC 12.
On 2/6/21 10:12 AM, Martin Sebor wrote:
Ping 2:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html
On 1/29/21 7:56 PM, Martin Sebor wr
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
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
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: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
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:
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/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
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
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
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
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 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
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 lin
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
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
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/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 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
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: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
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
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
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
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
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
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
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
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
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 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
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/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
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/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
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
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
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/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 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
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 corr
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
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
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
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
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
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
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
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
linux.
On 1/19/21 11:58 AM, Martin Sebor wrote:
std::string tends to trigger a class of false positive out of bounds
access warnings for code GCC cannot prove is unreachable because of
missing aliasing constrains, and that ends up expanded inline into
user code. Simply inserting the contents
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
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
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/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
Similar to pr96003, bug 98646 reports a spurious instance of -Wnonnull
calling a member function on the result of static_cast. The difference
here is that the cast argument is a function call, and, besides casting
down an inheritance hierarchy, the cast also adds the const qualifier.
GCC sets the
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 (hopefully in GCC 12)
the attached patch adds its own w
std::string tends to trigger a class of false positive out of bounds
access warnings for code GCC cannot prove is unreachable because of
missing aliasing constrains, and that ends up expanded inline into
user code. Simply inserting the contents of a constant char array
does that. In GCC 10 these
er testing it on x86_64-linux.
Martin
commit 192105b6a2a1f24f974de98c933f372b06c1e06d (HEAD -> master)
Author: Martin Sebor
Date: Sun Jan 17 15:27:08 2021 -0700
Avoid assuming SSA_NAME_IDENTIFIER is nonnull.
gcc/c-family/ChangeLog:
* c-pretty-print.c (c_p
On 1/15/21 12:44 AM, Richard Biener wrote:
On Thu, Jan 14, 2021 at 8:13 PM Martin Sebor via Gcc-patches
wrote:
One aspect of PR 98465 - Bogus warning stringop-overread for std::string
is the inconsistency between -g and -g0 which turns out to be due to
GCC eliminating apparently unused scope
One aspect of PR 98465 - Bogus warning stringop-overread for std::string
is the inconsistency between -g and -g0 which turns out to be due to
GCC eliminating apparently unused scope blocks from inlined functions
that aren't explicitly declared inline and artificial. PR 98664 tracks
just this part
On 1/14/21 12:43 AM, Richard Biener wrote:
On Wed, 13 Jan 2021, Jakub Jelinek wrote:
Hi!
The following patch doesn't actually fix the print_mem_ref bugs, I've kept
it for now as broken as it was, but at least improves the cases where
we can unambiguously map back MEM[&something + off] into som
ncover any outstanding bugs.
Martin
commit 5a9cfad2de92f2d65585774acb524b3fa17621b5
Author: Martin Sebor
Date: Tue Jan 12 12:58:27 2021 -0700
Avoid a couple more ICEs in print_mem_ref (PR c/98597).
Resolves:
PR c/98597 - ICE in -Wuninitialized printing a MEM_REF
PR c/9859
On 1/11/21 9:30 AM, Matthias Klose wrote:
On 1/10/21 10:18 PM, Martin Sebor wrote:
On 1/10/21 3:29 AM, Matthias Klose wrote:
is the newline intended? It's followed by a debug_rtx call.
To avoid the warning there shouldn't be any trailing punctuation
or whitespace in the message
On 1/10/21 3:29 AM, Matthias Klose wrote:
On 1/9/21 11:22 PM, Jakub Jelinek wrote:
On Sat, Jan 09, 2021 at 07:44:31PM +0100, Matthias Klose wrote:
These warnings, including the suggested fixes are seen on power*-linux builds.
warning: misspelled term 'builtin function' in format; use 'bult-in
In PR 98097 Richard expects -Wstring-compare for a call to strcmp()
with a member array and a string literal of larger size, used in
an equality test.
In virtually all cases the test will indicate the two are unequal
because the string stored in the member must be shorter (to fit
the terminating
On 1/7/21 2:37 PM, Jakub Jelinek wrote:
On Thu, Jan 07, 2021 at 02:29:50PM -0700, Martin Sebor via Gcc-patches wrote:
--- a/gcc/c-family/c-pretty-print.c
+++ b/gcc/c-family/c-pretty-print.c
@@ -1844,22 +1844,25 @@ print_mem_ref (c_pretty_printer *pp, tree e)
}
}
- const tree
On 1/7/21 1:26 AM, Jakub Jelinek wrote:
On Sat, Jan 02, 2021 at 03:22:25PM -0700, Martin Sebor via Gcc-patches wrote:
PR c++/95768 - pretty-printer ICE on -Wuninitialized with allocated storage
gcc/c-family/ChangeLog:
PR c++/95768
* c-pretty-print.c (c_pretty_printer
(though hopefully no more ICEs) that
I found while testing the attached fix. I xfailed the tests
and opened the referenced bugs to keep track of them.
commit 178f0afce3611282170de380fcea9db9d6e3ff0c
Author: Martin Sebor
Date: Thu Jan 7 14:20:39 2021 -0700
PR middle-end/98578 - ICE warning on
On 1/5/21 5:38 AM, Richard Biener wrote:
On Mon, Jan 4, 2021 at 9:53 PM Martin Sebor wrote:
On 1/4/21 12:23 PM, Jeff Law wrote:
On 1/4/21 12:19 PM, Jakub Jelinek wrote:
On Mon, Jan 04, 2021 at 12:14:15PM -0700, Jeff Law via Gcc-patches wrote:
Doing the STRING_CST is certainly less
On 1/4/21 2:10 PM, Jeff Law wrote:
On 1/4/21 1:53 PM, Martin Sebor wrote:
On 1/4/21 12:23 PM, Jeff Law wrote:
On 1/4/21 12:19 PM, Jakub Jelinek wrote:
On Mon, Jan 04, 2021 at 12:14:15PM -0700, Jeff Law via Gcc-patches
wrote:
Doing the STRING_CST is certainly less fragile since the SSA
On 1/4/21 12:23 PM, Jeff Law wrote:
On 1/4/21 12:19 PM, Jakub Jelinek wrote:
On Mon, Jan 04, 2021 at 12:14:15PM -0700, Jeff Law via Gcc-patches wrote:
Doing the STRING_CST is certainly less fragile since the SSA names
created at gimplification time could even be ggc_freed when no longer
used
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562141.html
On 12/16/20 7:10 PM, Martin Sebor wrote:
The -Wmismatched-new-delete detection of operator members of class
template instantiations is incomplete and overly simplistic, leading
to incorrect results and false positives
Attached is another revision of a patch I posted last July to keep
the pretty-printer from crashing on MEM_REFs with void* arguments:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549746.html
Besides avoiding the ICE and enhancing the MEM_REF detail and
improving its format, this revision
after regtesting in on
x86_64-linux.
Martin
commit 0df311657dc8c2a7f6ce3464c9d9ae5d5033840c
Author: Martin Sebor
Date: Wed Dec 23 16:34:12 2020 -0700
PR middle-end/98160 - ICE in warn_dealloc_offset on member placement new and delete
gcc/ChangeLog:
PR middle-end/
ommit fdd8560cce9f10fe5dcd26483440be136b81701d
Author: Martin Sebor
Date: Wed Dec 23 16:28:06 2020 -0700
PR c++/98413 - ICE on placement new and member pointer
gcc/ChangeLog:
PR c++/98413
* builtins.c (get_offset_range): Avoid non-integers/-pointers.
On 12/23/20 10:07 AM, Martin Liška wrote:
Hello.
I'm not fully familiar with code in warn_dealloc_offset, but I guess
the following can work.
Martin, what do you think?
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks for looking into it!
On 12/19/20 12:48 AM, Richard Biener via Gcc-patches wrote:
On December 19, 2020 1:55:02 AM GMT+01:00, Martin Sebor via Gcc-patches
wrote:
To keep tree expressions stored by the front end in attribute
access for nontrivial VLA bounds from getting corrupted during
Gimplification and to avoid
To keep tree expressions stored by the front end in attribute
access for nontrivial VLA bounds from getting corrupted during
Gimplification and to avoid breaking the preconditions verified
by the LTO streamer that no such trees exist in the IL,
the attached patch replaces those bounds with a strin
On 12/17/20 12:12 PM, H.J. Lu wrote:
On Thu, Dec 17, 2020 at 11:07 AM Martin Sebor via Gcc-patches
wrote:
The top of trunk fails to build with the error below. I haven't
spent any time debugging it except to look at git log where
the description for r11-6238 mentions the function
The top of trunk fails to build with the error below. I haven't
spent any time debugging it except to look at git log where
the description for r11-6238 mentions the function also referenced
in the error message. Could the patch be responsible for this?
https://gcc.gnu.org/pipermail/gcc-cvs/2020
The -Wmismatched-new-delete detection of operator members of class
template instantiations is incomplete and overly simplistic, leading
to incorrect results and false positives. Rather than reinventing
the wheel and parsing the mangled qualified names of the operators
the attached patch uses the
601 - 700 of 3588 matches
Mail list logo