On 10/21/22 09:29, Qing Zhao wrote:
Hi,
(FAM below refers to Flexible Array Members):
I need inputs on how to handle the combination of -fstrict-flex-arrays +
-Warray-bounds.
Our initial goal is to update -Warray-bounds with multiple levels of
-fstrict-flex-arrays=N
to issue warnings
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
On 9/6/22 18:28, Qing Zhao wrote:
Add the following new option -fstrict-flex-arrays[=n] and a corresponding
attribute strict_flex_arrays to GCC:
'-fstrict-flex-arrays'
Treat the trailing array of a structure as a flexible array member
in a stricter way.
A minor problem with this
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
On 6/28/22 13:01, Qing Zhao wrote:
On Jun 28, 2022, at 2:49 PM, Jakub Jelinek wrote:
On Tue, Jun 28, 2022 at 06:29:01PM +, Qing Zhao wrote:
On Jun 28, 2022, at 2:22 PM, Jakub Jelinek wrote:
On Tue, Jun 28, 2022 at 06:15:58PM +, Qing Zhao wrote:
Because the flag just tells
On 6/28/22 01:16, Richard Biener wrote:
On Mon, Jun 27, 2022 at 4:20 PM Qing Zhao via Gcc-patches
wrote:
Hi,
Per our discussion in the bug report, I came up with the following patch:
===
PR101836: Add a new option -fstrict-flex-array[=n]
Add the new option and use it in
On 6/13/22 05:15, Richard Biener wrote:
On Fri, Jun 10, 2022 at 12:58 PM Eric Botcazou via Gcc-patches
wrote:
Hi,
gimple_set_location is mostly invoked on newly built GIMPLE statements, so
their location is UNKNOWN_LOCATION and setting it will clobber the warning
data of the passed location,
On 5/25/22 11:19, Martin Sebor wrote:
On 5/25/22 04:49, Richard Biener wrote:
...
[*] For example, no warning is issued for the following overread:
Scratch that, there is no overread with strncpy. When there is like
with memcpy, it is diagnosed as it should be.
struct A a;
void g (char
On 5/25/22 04:49, Richard Biener wrote:
There's heuristic to detect ptr[1].a[...] out of bound accesses
reasoning that if ptr points to an array of aggregates a trailing
incomplete array has to have size zero. The following more
thoroughly constrains the cases this applies to avoid false
On 5/19/22 05:39, Richard Biener wrote:
On Wed, 18 May 2022, Martin Sebor wrote:
On 5/18/22 00:26, Richard Biener wrote:
On Tue, 17 May 2022, Martin Sebor wrote:
On 5/16/22 03:16, Richard Biener wrote:
The following tries to correct get_origin_and_offset_r not handling
non-constant sizes
On 5/18/22 00:26, Richard Biener wrote:
On Tue, 17 May 2022, Martin Sebor wrote:
On 5/16/22 03:16, Richard Biener wrote:
The following tries to correct get_origin_and_offset_r not handling
non-constant sizes of array elements in ARRAY_REFs and non-constant
offsets of COMPONENT_REFs. It isn't
On 5/16/22 03:16, Richard Biener wrote:
The following tries to correct get_origin_and_offset_r not handling
non-constant sizes of array elements in ARRAY_REFs and non-constant
offsets of COMPONENT_REFs. It isn't exactly clear how such failures
should be treated in this API and existing handling
On 4/7/22 00:59, Richard Biener wrote:
On Wed, 6 Apr 2022, Martin Sebor wrote:
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
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
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've adjusted
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/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/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);
}
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/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
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 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
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
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 result
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
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
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
On 2/10/22 23:48, Richard Sandiford wrote:
Martin Sebor via Gcc-patches writes:
The -Warray-bounds description in the manual is out of date in
a couple of ways. First it claims that the option is only active
with optimization, which isn't entirely correct since at least one
instance is issued
The -Warray-bounds description in the manual is out of date in
a couple of ways. First it claims that the option is only active
with optimization, which isn't entirely correct since at least one
instance is issued even without it. Second, the description of
its level 2 suggests it controls the
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-pointer when the argument is used
to store the address of a local variable. Since the stored value is
not
On 2/9/22 00:12, Richard Biener wrote:
On Tue, 8 Feb 2022, Jeff Law wrote:
On 2/8/2022 12:03 AM, Richard Biener via Gcc-patches wrote:
The following improves early uninit diagnostics by computing edge
reachability using our value-numbering framework in its cheapest
mode and ignoring
Transforming a by-value arguments to by-reference as GCC does for some
class types can trigger -Wdangling-pointer when the argument is used
to store the address of a local variable. Since the stored value is
not accessible in the caller the warning is a false positive.
The attached patch
On 2/3/22 17:33, Martin Sebor wrote:
On 2/3/22 17:18, David Edelsohn wrote:
On Thu, Feb 3, 2022 at 6:09 PM Martin Sebor wrote:
On 2/3/22 15:56, David Edelsohn wrote:
This series of patches has exploded memory usage and I can no longer
bootstrap GCC on AIX.
As with the Ranger problem
On 2/3/22 17:18, David Edelsohn wrote:
On Thu, Feb 3, 2022 at 6:09 PM Martin Sebor wrote:
On 2/3/22 15:56, David Edelsohn wrote:
This series of patches has exploded memory usage and I can no longer
bootstrap GCC on AIX.
As with the Ranger problem exposed by Aldy's patch last September,
On 2/3/22 15:56, David Edelsohn wrote:
This series of patches has exploded memory usage and I can no longer
bootstrap GCC on AIX.
As with the Ranger problem exposed by Aldy's patch last September,
something is not freeing memory.
Even on systems where GCC still bootstrap, this excessive memory
On 2/3/22 09:45, Martin Liška wrote:
On 2/3/22 17:43, Martin Sebor wrote:
On 2/3/22 01:59, Martin Liška wrote:
On 2/3/22 09:24, Robin Dapp via Gcc-patches wrote:
Hi Martin,
Either this:
error ("% is unknown", orig_p);
or this would be better:
error ("attribute % is unknown",
On 2/3/22 01:59, Martin Liška wrote:
On 2/3/22 09:24, Robin Dapp via Gcc-patches wrote:
Hi Martin,
Either this:
error ("% is unknown", orig_p);
or this would be better:
error ("attribute % is unknown", orig_p);
The %< %> directives will render it in single quotes like keywords and
I committed r12-7009 to fix a couple of typos in the description
of the option.
https://gcc.gnu.org/pipermail/gcc-cvs/2022-February/360083.html
Martin
The third patch in the series adds a pointer_query instance to the wrestrict
pass and uses it for each invocation to check a function.
gcc/ChangeLog:
* gimple-ssa-warn-restrict.cc (class pass_wrestrict): Outline ctor.
(pass_wrestrict::m_ptr_qry): New member.
The second patch in the series adds a pointer_query instance to the array
bounds checker object and uses it for each invocation to check a function.
gcc/ChangeLog:
* gimple-array-bounds.cc (array_bounds_checker::array_bounds_checker):
Define ctor.
The first patch in the series make the pointer_query cache a private
member of the class and removes the ability to create an object of it
without one, or one with an external cache. It also simplifies existing
clients of the class that provide an external cache to avoid doing so.
gcc/ChangeLog:
Richard, as we discussed(*), this patch series enables the pointer_query
cache in the remaining two passes where it's currently disabled. Since
not using the cache is not an option anymore, the first patch in
the series makes it a private member of the pointer_query class and its
use
On 2/2/22 09:35, Robin Dapp via Gcc-patches wrote:
Hi,
this fixes the s390 bootstrap errors caused by -Werror=format-diag. It
simply splits the problematic format strings.
Either this:
error ("% is unknown", orig_p);
or this would be better:
error ("attribute % is unknown", orig_p);
On 2/1/22 17:15, Jonathan Wakely wrote:
On Wed, 2 Feb 2022 at 00:13, Martin Sebor wrote:
On 2/1/22 12:48, Jonathan Wakely wrote:
On Tue, 1 Feb 2022 at 18:54, Martin Sebor via Libstdc++
wrote:
Passing an uninitialized object to a function that takes its argument
by const reference is
On 2/1/22 12:48, Jonathan Wakely wrote:
On Tue, 1 Feb 2022 at 18:54, Martin Sebor via Libstdc++
wrote:
Passing an uninitialized object to a function that takes its argument
by const reference is diagnosed by -Wmaybe-uninitialized because most
such functions read the argument. The exceptions
The attached patch adjusts the placement of the warn-access pass
as the two of you suggested in the bug. Please let me know if
this is good to commit or if you want me to make some other tweaks.
The patch passes tests in an x86_64-linux bootstrap.
MartinPR middle-end/104260 - Misplaced
Passing an uninitialized object to a function that takes its argument
by const reference is diagnosed by -Wmaybe-uninitialized because most
such functions read the argument. The exceptions are functions that
don't access the object but instead use its address to compute
a result. This includes
On 1/27/22 16:47, Andrew Pinski wrote:
On Wed, Dec 8, 2021 at 8:50 AM Martin Sebor via Gcc-patches
wrote:
Even with -Wno-system-headers enabled, the -Winvalid-memory-order
code tries to make sure calls to atomic functions with invalid
memory orders are diagnosed even though the C atomic
The indiscriminate PHI handling by -Wuse-after-free has caused
the false positive reported in PR 104232. The attached patch
refines the handling to only consider PHIs all of whose operands
refer to the same object and disregard the rest.
Tested on x86_64-linux and by compiling a few toolchain
On 1/26/22 08:24, Jason Merrill via Gcc-patches wrote:
On 1/25/22 18:33, Marek Polacek wrote:
Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors
return, as mandated by the EABI. To be entirely correct, it only
requires it for C1 and C2 ctors and D2 and D1 dtors, but I don't
On 1/25/22 16:33, Marek Polacek via Gcc-patches wrote:
Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors
return, as mandated by the EABI. To be entirely correct, it only
requires it for C1 and C2 ctors and D2 and D1 dtors, but I don't feel
like changing that now and possibly
On 1/25/22 04:15, Richard Biener wrote:
On Mon, Jan 24, 2022 at 11:55 PM Martin Sebor wrote:
The pointer_query algorithm fails when it's unable to determine
the provenance of an pointer SSA variable. A failure prevents it
from making a record of the variable in the cache. Although this
The pointer_query::dump() function contains a duplicate block of
code that does the same thing as a prior block, just a little
differently. I removed the code after testing it on x86_linux.
The committed change is below for reference:
The pointer_query algorithm fails when it's unable to determine
the provenance of an pointer SSA variable. A failure prevents it
from making a record of the variable in the cache. Although this
doesn't happen often, one common cause of failures is PHI nodes:
e.g., because one of its arguments
The updated patch ensures the tighter bound isn't used to compute
the sprintf result and adds a test to verify that. (This is messy
in the strlen/sprintf pass and should be cleaned up to avoid this
mistake in the future.)
Rested on x86_64-linux.
On 1/19/22 18:20, Martin Sebor wrote:
The
On 1/20/22 10:03, Jakub Jelinek wrote:
On Thu, Jan 20, 2022 at 09:56:59AM -0700, Martin Sebor wrote:
With normal -Wformat I see all expected warnings in:
char *foo (const char *) __attribute__((format_arg(1)));
void bar (const char *, ...) __attribute__((format(printf, 1, 2)));
-Wformat-diag
On 1/20/22 09:43, Jakub Jelinek wrote:
On Thu, Jan 20, 2022 at 09:33:30AM -0700, Martin Sebor wrote:
Oh, and one more thing, but this time not about this source file but about
the warning. Does it handle the gettext case?
I think -Wformat generally does, gettext has format_arg attribute.
If
On 1/20/22 03:28, Jakub Jelinek wrote:
On Thu, Jan 20, 2022 at 11:17:28AM +0100, Jakub Jelinek via Gcc-patches wrote:
--- a/gcc/cp/error.cc
+++ b/gcc/cp/error.cc
@@ -768,6 +768,11 @@ class_key_or_enum_as_string (tree t)
return "struct";
}
+#if __GNUC__ >= 10
+#pragma GCC diagnostic push
The attached patch suppresses a class of unexpected -Wformat-overflow
(and -truncation) warnings introduced as a result of better range info
with the integration of the strlen pass with Ranger.
The sprintf warning code relies on the strlen pass data to determine
the lengths of string arguments
On 1/19/22 09:22, Richard Sandiford wrote:
Martin Sebor writes:
On 1/19/22 03:09, Richard Sandiford wrote:
Richard Biener writes:
On Tue, Jan 18, 2022 at 2:40 PM Richard Sandiford via Gcc-patches
wrote:
In this PR the waccess pass was fed:
D.10779 ={v} {CLOBBER};
On 1/19/22 03:09, Richard Sandiford wrote:
Richard Biener writes:
On Tue, Jan 18, 2022 at 2:40 PM Richard Sandiford via Gcc-patches
wrote:
In this PR the waccess pass was fed:
D.10779 ={v} {CLOBBER};
VIEW_CONVERT_EXPR(D.10779) = .MASK_LOAD_LANES (addr_5(D),
64B, _2);
_7 =
A -Wdangling-pointer false positive reported just the other day
on this list has disappeared after an unrelated change to
the gimplifier (r12-6694). In r12-6714 I've committed the regression
test for it, though I'm not sure I see what the warning code could
have done to avoid the false positive.
The regression test gcc.dg/torture/pr57147-2.c triggers a valid
warning by passing a variable with zero size to a function that
expects an array of size 1. The recent change to run the access
pass also earlier in the optimization pipeline has triggered
this warning. In r12-6713 I have committed
The new pointer_related_p() utility function added for -Wuse-after-free
is documented to conservatively return false when it cannot determine
relatedness but actually returns true. That has caused the false
positive reported in PR 104069. In r12-6712 I've committed as obvious
a fix for this
On 1/18/22 16:56, Jakub Jelinek wrote:
Hi!
As reported in the PR or as I've seen since the weekend, asan_test.C fails
because of many warnings like:
/home/jakub/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:1157:10: error:
using a dangling pointer to an unnamed temporary
On 1/18/22 06:37, Richard Sandiford wrote:
In this PR the waccess pass was fed:
D.10779 ={v} {CLOBBER};
VIEW_CONVERT_EXPR(D.10779) = .MASK_LOAD_LANES (addr_5(D),
64B, _2);
_7 = D.10779.__val[0];
However, the tracking of m_clobbers only looked at gassigns,
so it missed that the
On 1/18/22 01:36, Richard Biener wrote:
On Mon, 17 Jan 2022, Martin Sebor wrote:
On 1/17/22 07:32, Richard Biener via Gcc-patches wrote:
The warning control falls into the C++ trap of using a reference
to old hashtable contents for a put operation which can end up
re-allocating that before
On 1/17/22 06:46, Stephan Bergmann wrote:
On 10/01/2022 22:51, Martin Sebor via Gcc-patches wrote:
Last ping for this stage 1 feature before stage 3 ends:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585819.html
This hits somewhat unexpectedly at (test case reduced from a hit
On 1/17/22 07:32, Richard Biener via Gcc-patches wrote:
The warning control falls into the C++ trap of using a reference
to old hashtable contents for a put operation which can end up
re-allocating that before reading from the old freed referenced to
source. Fixed by introducing a temporary.
Martin, I've looked into removing the -Wno-error for this warning
for just a subset of targets. It seems doable with some hardcoding
in configure.ac but if you're planning to do the cleanup for all of
them I'm wondering if we should even bother. What do you think?
Martin
On 1/14/22 08:46,
On 1/11/22 15:40, Jason Merrill wrote:
On 11/30/21 17:32, Martin Sebor via Gcc-patches wrote:
Attached is a revised patch with the following changes based
on your comments:
1) Set and use statement uids to determine which statement
precedes which in the same basic block.
2) Avoid testing
On 1/14/22 11:29, Qing Zhao wrote:
On Jan 14, 2022, at 12:11 PM, Martin Sebor wrote:
On 1/14/22 09:30, Qing Zhao wrote:
On Jan 14, 2022, at 6:45 AM, Richard Biener wrote:
On Thu, Jan 13, 2022 at 2:45 AM Qing Zhao wrote:
Hi, Richard,
This is the updated version for the second patch,
On 1/14/22 09:30, Qing Zhao wrote:
On Jan 14, 2022, at 6:45 AM, Richard Biener wrote:
On Thu, Jan 13, 2022 at 2:45 AM Qing Zhao wrote:
Hi, Richard,
This is the updated version for the second patch, which is mainly the change for
"Enable -Wuninitialized + -ftrivial-auto-var-init for
Converting the strlen/sprintf pass to Ranger has considerably
improved the accuracy of -Wformat-overflow warnings: they can avoid
triggering for safe input even at -O0 while at the same time detect
provable overflow. The conversion didn't come with any tests so in
r12-6591 I committed one that
On 1/13/22 03:55, Thomas Schwinge wrote:
Hi!
This has fallen out of (unfinished...) work earlier in the year: pushed
to master branch commit 4bd8b1e881f0c26a5103cd1919809b3d63b60ef2
"Document current '-Wuninitialized'/'-Wmaybe-uninitialized' diagnostics
for OpenACC test cases".
Thanks for the
On 1/13/22 05:55, Richard Sandiford wrote:
Martin Sebor via Gcc-patches writes:
On 1/12/22 02:02, Martin Liška wrote:
Hello.
We've got -Wformat-diag for some time and I think we should start using it
in -Werror for GCC bootstrap. The following patch removes last pieces of
the warning
On 1/12/22 02:02, Martin Liška wrote:
Hello.
We've got -Wformat-diag for some time and I think we should start using it
in -Werror for GCC bootstrap. The following patch removes last pieces of
the warning
for rs6000 target.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
*
On 1/12/22 02:03, Martin Liška wrote:
Hello.
We've got -Wformat-diag for some time and I think we should start using it
in -Werror for GCC bootstrap. The following patch removes last pieces of
the warning
for s390x target.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
*
On 1/12/22 02:02, Martin Liška wrote:
Hello.
We've got -Wformat-diag for some time and I think we should start using it
in -Werror for GCC bootstrap. The following patch removes last pieces of
the warning
for rs6000 target.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
*
oice in my reply below:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583176.html
Martin
On 11/23/21 2:16 PM, Martin Sebor wrote:
On 11/22/21 6:32 PM, Jeff Law wrote:
On 11/1/2021 4:17 PM, Martin Sebor via Gcc-patches wrote:
Patch 1 in the series detects a small subset of uses of poi
Ping (CC'ing Jason as requested):
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587033.html
On 1/4/22 10:28, Martin Sebor wrote:
On 12/20/21 12:29 PM, Jeff Law wrote:
On 12/16/2021 12:56 PM, Martin Sebor via Gcc-patches wrote:
Enabling vectorization at -O2 caused quite a few tests
Last ping for this stage 1 feature before stage 3 ends:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585819.html
On 1/4/22 11:02, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585819.html
On 12/13/21 9:50 AM, Martin Sebor wrote:
Ping. This
On 1/6/22 8:10 AM, David Malcolm wrote:
On Thu, 2021-12-09 at 15:54 -0700, Martin Sebor wrote:
On 11/13/21 1:37 PM, David Malcolm via Gcc-patches wrote:
This patch adds a new:
__attribute__((untrusted))
for use by the C front-end, intended for use by the Linux kernel for
use with
On 1/5/22 1:45 AM, Martin Liška wrote:
On 12/8/21 17:49, Martin Sebor via Gcc-patches wrote:
Even with -Wno-system-headers enabled, the -Winvalid-memory-order
code tries to make sure calls to atomic functions with invalid
memory orders are diagnosed even though the C atomic functions
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585819.html
On 12/13/21 9:50 AM, Martin Sebor wrote:
Ping. This patch, originally submitted on Nov. 1, has not been
reviewed yet.
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585819.html
On 12/6/21 5:51 PM, Martin Sebor
On 11/22/21 6:32 PM, Jeff Law wrote:
On 11/1/2021 4:17 PM, Martin Sebor via Gcc-patches wrote:
Patch 1 in the series detects a small subset of uses of pointers
made indeterminate by calls to deallocation functions like free
or C++ operator delete. To control the conditions the warnings
are is
On 12/20/21 12:29 PM, Jeff Law wrote:
On 12/16/2021 12:56 PM, Martin Sebor via Gcc-patches wrote:
Enabling vectorization at -O2 caused quite a few tests for
warnings to start failing in GCC 12. These tests were xfailed
and bugs were opened to track the problems until they can be
fully
Enabling vectorization at -O2 caused quite a few tests for
warnings to start failing in GCC 12. These tests were xfailed
and bugs were opened to track the problems until they can be
fully analyzed and ultimately fixed before GCC 12 is released.
I've now started going through these and the first
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586402.html
Besides PR 99612 this also fixes the false positive reported
recently in PR 103372.
On 12/8/21 9:49 AM, Martin Sebor wrote:
Even with -Wno-system-headers enabled, the -Winvalid-memory-order
code tries to make sure calls
The attached patch avoids an ICE when using
the CLASSTYPE_IMPLICIT_INSTANTIATION() macro with an argument
that is not a class type but rather a typename_type.
The test case should trigger a warning but doesn't because
the code doesn't fully handle explicit instantiations.
Martin
Check for class
On 12/14/21 9:43 AM, Qing Zhao wrote:
Hi,
On Dec 9, 2021, at 12:13 PM, Qing Zhao via Gcc-patches
wrote:
+ return;
+
+ /* Get the variable declaration location from the def_stmt. */
+ var_decl_loc = gimple_location (def_stmt);
+
+ /* The LHS of the call
On 12/13/21 10:41 PM, Jason Merrill wrote:
On 12/13/21 14:22, Martin Sebor wrote:
On 12/11/21 10:39 PM, Jason Merrill via Gcc-patches wrote:
In reading C++ diagnostics, it's often hard to find the name of the
function
in the middle of the template header, return type, parameters, and
template
On 12/13/21 8:55 AM, Bill Schmidt via Gcc-patches wrote:
Hi!
PR103623 shows that we ICE if __builtin_pack_longdouble or
__builtin_unpack_longdouble
is used when long double is not defined to be the IBM-128 (double-double)
format.
To solve this, I introduce a new built-in function attribute
On 12/11/21 10:39 PM, Jason Merrill via Gcc-patches wrote:
In reading C++ diagnostics, it's often hard to find the name of the function
in the middle of the template header, return type, parameters, and template
arguments. So let's colorize it, and maybe the template argument bindings
while
On 12/12/21 3:13 AM, Andrea Monaco via Gcc-patches wrote:
Hello.
I propose to make that message more verbose. It sure would have helped
me once. You don't always have a Web search available :)
Warnings turned into errors have the [-Werror=...] tag at the end
so I'm not sure I see when
On 12/10/21 3:42 PM, Thomas Schwinge wrote:
Hi!
OK to push the attached "testsuite: Be more informative for ICEs"?
Adding more detail here seems like a useful improvement to me.
Martin
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße
Ping. This patch, originally submitted on Nov. 1, has not been
reviewed yet.
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585819.html
On 12/6/21 5:51 PM, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585819.html
On 11/30/21 3:55 PM, Martin Sebor
rationale for this choice in my reply below:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583176.html
Martin
On 11/23/21 2:16 PM, Martin Sebor wrote:
On 11/22/21 6:32 PM, Jeff Law wrote:
On 11/1/2021 4:17 PM, Martin Sebor via Gcc-patches wrote:
Patch 1 in the series detects a small subs
On 12/10/21 9:41 AM, Jakub Jelinek wrote:
On Fri, Dec 10, 2021 at 09:35:50AM -0700, Martin Sebor via Gcc-patches wrote:
The above was just a quick proof of concept experiment. You're
of course right that the final solution can't be so crude(*).
But if the required functions are always_inline
On 12/10/21 3:12 AM, Jonathan Wakely wrote:
On Fri, 10 Dec 2021 at 01:50, Martin Sebor via Libstdc++
wrote:
On 12/9/21 5:38 PM, Martin Sebor wrote:
On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote:
These warnings are triggered by perfectly valid code using std::string.
They're
1 - 100 of 1046 matches
Mail list logo
