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
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
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
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
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
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
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_object_size ());
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
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
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:
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
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
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
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
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 links to
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
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
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.
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
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
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 released
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
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
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
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
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
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
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 part,
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,
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) ==
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
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:
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
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.
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
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
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 keep
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 robust as I'd
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
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
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
More exhaustively testing the MEM_REF formatting change by
pretty-printing every MEM_REF the tree-ssa-uninit pass encounters
triggered another ICE, this one due to assuming SSA_NAME_IDENTIFIER
is non- null. I have committed as "obvious" the attached patch to
remove the assumption after testing
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
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[ + off] into some
A recent improvement to MEM_REF formatting introduced a few invalid
assumptions that didn't get exposed during testing and ended up
causing ICEs in downstream packages and some distress to their
maintainers. I have committed the attached patch to remove two
of these assumptions and unblock the
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. The GCC
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
Fixing the ICE in MEM_REF formatting (or the enhancements that
came along with the fix) introduced another, ICE plus a plugin
test failure. I have committed the attached simple patch to
fix both.
Martin
PS There are outstanding bugs to fix/improvements to be made
to the MEM_REF formatting
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
The previous fix for PR 98160 was incomplete and while it fixed
the more interesting aspect of the problem (a false positive) it
didn't remedy the ICE that showed up only with LTO. I have
reduced (again) the problem to a non-LTO test case and committed
the attached trivial fix in r11-6329 after
get_offset_range() expects integer and pointer arguments but can't
deal with others such as C++ OFFSET_TYPE. The attached fix has
the function fail for arguments of such types. I have committed
the trivial change in r11-6328 after regression-testing in on
x86_64-linux.
Martin
commit
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
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 also
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?
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 1046 matches
Mail list logo
