On 3/12/21 7:02 AM, Martin Liška wrote:
On 3/12/21 2:56 PM, David Malcolm wrote:
On Fri, 2021-03-12 at 09:45 +0100, Martin Liška wrote:
Identified by my check that compares documentation of params
with content of --help=param output.
Pushed as obvious.
Martin
Thanks.
Which check is this, BT
On 3/16/21 3:08 AM, Martin Liška wrote:
On 3/15/21 9:57 PM, Martin Sebor wrote:
Any plans to integrate it into the testsuite? (That way we presumably
wouldn't need to remember to run it by hand.)
Likely not, I'm not so big friend with DejaGNU.
Are you willing to help me with that?
I'm not a
On 3/16/21 11:56 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
Honza has fairly recently changed operand_equal_p to compare
DECL_FIELD_OFFSET for COMPONENT_REFs when comparing addresses.
As the first testcase in this patch shows, while that is very nice
for optimizations, for the -Wduplicated-bra
On 3/17/21 2:36 AM, Jakub Jelinek wrote:
On Tue, Mar 16, 2021 at 06:28:46PM -0600, Martin Sebor via Gcc-patches wrote:
It seems sort of "inverted:" I'd expect OEP_LEXICOGRAPHIC on its
own to do a lexicographical comparison, without having to set
an additional bit to ask for
On 3/16/21 2:24 PM, Jason Merrill wrote:
On 3/11/21 1:06 PM, Martin Sebor wrote:
More extensive testing of the patch I just committed in r11-7563 to
avoid the false positive -Warray-bounds on accesses to members of
virtual bases has exposed a couple of problems that cause many false
negatives fo
On 3/17/21 1:40 PM, Jason Merrill wrote:
On 3/17/21 3:03 PM, Martin Sebor wrote:
On 3/16/21 2:24 PM, Jason Merrill wrote:
On 3/11/21 1:06 PM, Martin Sebor wrote:
More extensive testing of the patch I just committed in r11-7563 to
avoid the false positive -Warray-bounds on accesses to members o
On 3/17/21 4:01 PM, Sandra Loosemore wrote:
I've checked in this patch, after having received a report a few days
ago that the nios2 back end was not building. Most of the changes here
are purely cosmetic.
Swapping out my nios2 maintainer hat for the documentation maintainer
one, though: the
On 3/18/21 4:46 AM, Martin Liška wrote:
Hey.
Recently, I noticed a cumbersome construct we use for string startswith
function
(most notably in a situation when the prefix is a string literal).
Commonly used patterns are:
1) strncmp (arg, "--sysroot=", 10) == 0
2) strncmp (name, "not found", s
On 3/18/21 8:58 AM, Jeff Law via Gcc-patches wrote:
On 3/18/2021 8:37 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
Similar issue as in strlenopt-73.c, various spots in this test rely
on MOVE_MAX >= 8, this time it uses a target selector to pick up a couple
of targets, and all of them but power
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564483.html
The review of this patch digressed into a design discussion of a new,
more capable implementation of -Wstrict-aliasing, but the proposed
patch turning just this one instance of -Warray-bounds into
-Wstrict-aliasing and makin
On 3/19/21 12:49 PM, Jakub Jelinek via Gcc-patches wrote:
On Fri, Mar 19, 2021 at 02:17:39PM -0400, Jason Merrill wrote:
--- gcc/cp/decl.c.jj2021-03-16 21:17:41.014498713 +0100
+++ gcc/cp/decl.c 2021-03-18 19:31:22.430149523 +0100
@@ -8629,6 +8629,11 @@ cp_finish_decomp (tree decl, tre
On 3/20/21 10:48 AM, Jeff Law via Gcc-patches wrote:
On 3/18/2021 4:18 PM, Martin Sebor via Gcc-patches wrote:
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564483.html
The review of this patch digressed into a design discussion of a new,
more capable implementation of -Wstrict
On 3/17/21 6:00 PM, Sandra Loosemore wrote:
On 3/17/21 4:40 PM, Martin Sebor wrote:
[*] Does -Wformat-diag really trigger when using older GCC to build?
I thought it only triggered in stage 2 and 3 when using the same GCC
to rebuild itself.
I always end up hopelessly confused by anything invo
On 3/24/21 5:44 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566821.html
P1 PR99565 fix.
Marek has acked the gcc/c/ and gcc/c-family/ part of that patch, but it still
has gcc/cp/ and gcc/ parts that weren't acked.
If you
On 3/24/21 10:40 AM, Jakub Jelinek wrote:
On Wed, Mar 24, 2021 at 09:45:31AM -0600, Martin Sebor via Gcc-patches wrote:
E.g., OEP_IGNORE_MEMBER_OFFSET or OEP_SAME_MEMBER_OFFSET (for
the converse of the first) or something like that, but hopefully
you get the idea.
Neither of these look like a
PR tree-optimization/44547 - -Wuninitialized reports false warning
in nested switch statements, has been resolved for some time. In
r11-7839 I've committed the test and resolved the bug as fixed.
Martin
All the test cases in the bug but one pass. The one that doesn't
seems sufficiently different to track separately. I've committed
a test with the test cases in r11-7840 and resolved the bug.
Martin
The bug was fixed in GCC 5.0 but never resolved. I've added a test
case in the commit below and resolved it:
https://gcc.gnu.org/g:e88ca9f42306e291d3cb2d34dd7f2b017a3c1e52
Martin
The bug has been fixed for a few years now. r11-7869 adds the test
for it: https://gcc.gnu.org/g:980b12cc81979e52f491bf0dfe961d30c07fe864
Martin
r11-7932 adds a test case for another ancient -Wuninitialized bug
fixed eons ago:
https://gcc.gnu.org/g:31199d95de1304e200554bbf98b2d8a6a7298bec
Martin
On 4/1/21 7:30 AM, Martin Liška wrote:
Hey.
I've returned to the David's project and I'm willing to finish his transition
effort.
I believe using Sphinx documentation can rapidly improve readability, both HTML
and PDF version,
of various GCC manuals ([1]). I've spent some time working on the D
On 4/2/21 9:40 AM, Jan Hubicka wrote:
This breaks bootstrap on riscv64:
In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool
’,
inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at
../../gcc/gimple-ssa-warn-alloca.c:295:25:
../../gcc/gimple-ss
The attached patch fixes a couple of typos. Not sure they qualify
as regressions but it seems like a trivial fix worth making even
now. I'll go ahead and commit it as obvious if no-one objects.
Martin
PR middle-end/99883 - A couple of minor misspellings
gcc/c-family/ChangeLog:
* c.opt (Wmism
The C front end ordinarily merges function type attributes upon
the redeclaration of a function but it doesn't do that for those
at local scope, unless the declaration refers to a built-in.
Because the new -Warray-parameter warning relies on the internal
access attribute on the type of the functi
On 4/9/21 2:25 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
pthread_setspecific second argument is const void *, so that one can
call it even with pointers to const, but the function only stores the
pointer and does nothing else, so the new assumption of -Wmaybe-uninitialized
that functions taki
On 4/9/21 10:30 AM, Jakub Jelinek wrote:
On Fri, Apr 09, 2021 at 10:28:47AM -0600, Martin Sebor wrote:
pthread_setspecific second argument is const void *, so that one can
call it even with pointers to const, but the function only stores the
pointer and does nothing else, so the new assumption o
The false positive warning disappeared years ago. r11-8099 adds
a test but I leave the bug open since it's a request for a better
suppression mechanism that what's available in GCC today.
Martin
On 4/12/21 3:53 PM, H.J. Lu via Gcc-patches wrote:
On Mon, Apr 12, 2021 at 2:21 AM Richard Biener
wrote:
On Sat, Apr 10, 2021 at 5:11 PM H.J. Lu via Gcc-patches
wrote:
Add inline_ignore_target function attribute to inform the compiler that
target specific option mismatch on functions with t
On 4/12/21 7:03 PM, H.J. Lu wrote:
On Mon, Apr 12, 2021 at 4:55 PM Martin Sebor wrote:
On 4/12/21 3:53 PM, H.J. Lu via Gcc-patches wrote:
On Mon, Apr 12, 2021 at 2:21 AM Richard Biener
wrote:
On Sat, Apr 10, 2021 at 5:11 PM H.J. Lu via Gcc-patches
wrote:
Add inline_ignore_target functio
On 4/13/21 10:07 AM, Jeff Law wrote:
On 4/8/2021 4:15 PM, Martin Sebor via Gcc-patches wrote:
The C front end ordinarily merges function type attributes upon
the redeclaration of a function but it doesn't do that for those
at local scope, unless the declaration refers to a built-in.
Be
The issue has been fixed so r11-8161 just adds the test case:
https://gcc.gnu.org/g:8084ab15a3e300e3b2c537e56e0f3a1b00778aec
Martin
The bug was fixed years ago. r11-8162 adds the test case to the test
suite.
https://gcc.gnu.org/g:af7128621e54f04b90589bb0c3e1ef271c239265
Martin
On 4/14/21 2:11 AM, Christophe Lyon wrote:
On Tue, 13 Apr 2021 at 21:50, Martin Sebor via Gcc-patches
wrote:
The issue has been fixed so r11-8161 just adds the test case:
https://gcc.gnu.org/g:8084ab15a3e300e3b2c537e56e0f3a1b00778aec
Hi,
This new test fails on arm (and aarch64 with
On 4/15/21 5:01 AM, Richard Biener wrote:
This adds a deprecation note to the undocumented gimple-builder.h
API only used by asan and sancov.
Pushed.
2021-04-15 Richard Biener
* gimple-builder.h: Add deprecation note.
---
gcc/gimple-builder.h | 2 ++
1 file changed, 2 insertions(
The false positives have disappeared thanks to
g:520d5ad337eaa15860a5a964daf7ca46cf31c029. I have added the two
test cases in the attached diff in r11-8202 after testing on aarch64,
arm, powerpc64le, and x86_64, out of an abundance of caution.
Martin
commit 2dbbbe893f75f587c48111ab4c97cf5e74fb91
The selftests at the end of many source files are only rarely read
or modified, but they contribute to the size/complexity of the files
and make moving within the rest of the code more difficult.
Would anyone be opposed to moving any of them into new files of their
own? E.g., those in tree.c to t
On 4/19/21 2:03 PM, David Malcolm wrote:
On Mon, 2021-04-19 at 13:47 -0600, Martin Sebor via Gcc-patches wrote:
The selftests at the end of many source files are only rarely read
or modified, but they contribute to the size/complexity of the files
and make moving within the rest of the code
On 4/19/21 3:13 PM, Koning, Paul wrote:
On Apr 19, 2021, at 4:50 PM, Martin Sebor via Gcc-patches
wrote:
On 4/19/21 2:03 PM, David Malcolm wrote:
On Mon, 2021-04-19 at 13:47 -0600, Martin Sebor via Gcc-patches wrote:
The selftests at the end of many source files are only rarely read
or
On 4/21/21 2:15 AM, Martin Liška wrote:
Hello.
It's addressing the following Clang warning:
cp/lex.c:170:45: warning: result of comparison of constant 64 with expression
of type 'enum ovl_op_code' is always true
[-Wtautological-constant-out-of-range-compare]
Patch can bootstrap on x86_64-linu
On 4/21/21 1:30 AM, Uros Bizjak wrote:
On Thu, Apr 15, 2021 at 12:39 AM H.J. Lu wrote:
commit 87c753ac241f25d222d46ba1ac66ceba89d6a200
Author: H.J. Lu
Date: Fri Aug 21 09:42:49 2020 -0700
x86: Add target("general-regs-only") function attribute
is incomplete since it is impossible to
On 4/14/21 4:39 PM, H.J. Lu wrote:
commit 87c753ac241f25d222d46ba1ac66ceba89d6a200
Author: H.J. Lu
Date: Fri Aug 21 09:42:49 2020 -0700
x86: Add target("general-regs-only") function attribute
is incomplete since it is impossible to call integer intrinsics from
a function with general-re
On 4/21/21 2:58 PM, H.J. Lu wrote:
On Wed, Apr 21, 2021 at 10:09 AM Martin Sebor wrote:
On 4/14/21 4:39 PM, H.J. Lu wrote:
commit 87c753ac241f25d222d46ba1ac66ceba89d6a200
Author: H.J. Lu
Date: Fri Aug 21 09:42:49 2020 -0700
x86: Add target("general-regs-only") function attribute
is
On 4/22/21 2:52 AM, Jonathan Wakely wrote:
On Thu, 22 Apr 2021, 08:47 Martin Liška, wrote:
On 4/21/21 6:11 PM, Martin Sebor wrote:
> On 4/21/21 2:15 AM, Martin Liška wrote:
>> Hello.
>>
>> It's addressing the following Clang warning:
>> cp/lex.c:170:45: warning: resu
On 4/22/21 9:41 AM, Jonathan Wakely wrote:
On Thu, 22 Apr 2021 at 15:59, Martin Sebor wrote:
On 4/22/21 2:52 AM, Jonathan Wakely wrote:
On Thu, 22 Apr 2021, 08:47 Martin Liška, wrote:
On 4/21/21 6:11 PM, Martin Sebor wrote:
> On 4/21/21 2:15 AM, Martin Liška wrote:
>> Hello.
On 6/14/21 6:17 AM, Jonathan Wakely via Gcc-patches wrote:
PR c++/101052
gcc/c-family/ChangeLog:
* known-headers.cc (get_stdlib_header_for_name): Add known
headers for EXIT_FAILURE, EXIT_SUCCESS, abort, atexit, calloc,
exit, and getenv.
gcc/testsuite/ChangeLog:
On 6/14/21 12:36 AM, Richard Biener via Gcc-patches wrote:
On Sun, Jun 13, 2021 at 7:00 PM Giuliano Belinassi via Gcc-patches
wrote:
This patch proposes a fix to PR 100944 by improving the array boundary
computation when the flexible array has no clear constructor: if no
constructor were found
On 6/13/21 11:00 AM, Giuliano Belinassi wrote:
This patch proposes a fix to PR 100944 by improving the array boundary
Thanks for the patch!
computation when the flexible array has no clear constructor: if no
constructor were found in the input code, we compute the size of the
array as:
of
On 6/13/21 5:45 PM, Jeff Law wrote:
On 6/2/2021 3:40 PM, Martin Sebor via Gcc-patches wrote:
The two forms of placement operator new defined in return their
pointer argument and may not be displaced by user-defined functions.
But because they are ordinary (not built-in) functions this
On 6/2/21 3:46 PM, Marek Polacek wrote:
On Wed, Jun 02, 2021 at 03:40:49PM -0600, Martin Sebor via Gcc-patches wrote:
+ if (!gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
+{
+ /* See if this is a call to placement new. */
+ if (!fn
+ || !DECL_IS_OPERATOR_NEW_P (fn
On 6/14/21 4:29 PM, Giuliano Belinassi wrote:
Hi,
I will give an quick answer to this mail. I will analyze carefully what
richi said when I have more time available.
On Mon, 2021-06-14 at 15:55 -0600, Martin Sebor wrote:
On 6/13/21 11:00 AM, Giuliano Belinassi wrote:
This patch proposes a fix
On 6/14/21 10:25 AM, Jonathan Wakely via Gcc-patches wrote:
I think this is an improvement on the current structure of the docs,
but I'd like to hear what others think.
The text looks more detailed and arguably more accurate but also
makes it sound more complicated and rigid than necessary. It
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571971.html
I got the go ahead to commit the Ada and Objective-C subset (patches
2 and 11). Most of the rest of the patches are mechanical replacements
and so nearly obvious but I'm still looking for a review/approval of
the warning infra
On 6/14/21 11:59 PM, Trevor Saunders wrote:
- Unfortunately using_auto_storage () needs to handle m_vec being null.
- Handle self move of an auto_vec to itself.
- punt on defining copy or move operators for auto_vec with inline storage,
until there is a need for them and we can decide what sem
On 6/15/21 3:39 AM, Jonathan Wakely wrote:
On Tue, 15 Jun 2021 at 01:12, Martin Sebor wrote:
On 6/14/21 10:25 AM, Jonathan Wakely via Gcc-patches wrote:
I think this is an improvement on the current structure of the docs,
but I'd like to hear what others think.
The text looks more detailed a
On 6/15/21 4:58 AM, Christophe Lyon wrote:
Hi,
On Tue, 15 Jun 2021 at 00:58, Martin Sebor via Gcc-patches
wrote:
On 6/2/21 3:46 PM, Marek Polacek wrote:
On Wed, Jun 02, 2021 at 03:40:49PM -0600, Martin Sebor via Gcc-patches wrote:
+ if (!gimple_call_builtin_p (stmt, BUILT_IN_NORMAL
On 6/11/21 11:04 AM, David Malcolm wrote:
On Thu, 2021-06-10 at 17:26 -0600, Martin Sebor wrote:
This diff introduces the diagnostic infrastructure changes to support
controlling warnings at any call site in the inlining stack and
printing
the inlining context without the %K and %G directives.
On 6/15/21 12:23 AM, Richard Biener wrote:
On Mon, Jun 14, 2021 at 7:32 PM Martin Sebor wrote:
On 6/14/21 12:36 AM, Richard Biener via Gcc-patches wrote:
On Sun, Jun 13, 2021 at 7:00 PM Giuliano Belinassi via Gcc-patches
wrote:
This patch proposes a fix to PR 100944 by improving the array
While debugging locations I noticed the semi_embedded_vec template
in line-map.h doesn't declare a copy ctor or copy assignment, but
is being copied in a couple of places in the C++ parser (via
gcc_rich_location). It gets away with it most likely because it
never grows beyond the embedded buffer.
On 6/16/21 6:38 AM, David Malcolm wrote:
On Tue, 2021-06-15 at 19:48 -0600, Martin Sebor wrote:
Thanks for writing the patch.
While debugging locations I noticed the semi_embedded_vec template
in line-map.h doesn't declare a copy ctor or copy assignment, but
is being copied in a couple of plac
On 6/16/21 5:48 AM, Jakub Jelinek wrote:
On Tue, Jun 15, 2021 at 06:11:27PM +0200, Richard Biener wrote:
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -915,6 +915,12 @@ create_access (tree expr, gimple *stmt, bool
write)
if (!DECL_P (base) || !bitmap_bit_p (candidate_bitmap, DECL_UID
(base)))
On 6/16/21 6:46 AM, Richard Sandiford via Gcc-patches wrote:
Richard Biener via Gcc-patches writes:
On Tue, Jun 15, 2021 at 8:02 AM Trevor Saunders wrote:
This makes it clear the caller owns the vector, and ensures it is cleaned up.
Signed-off-by: Trevor Saunders
bootstrapped and regteste
On 6/16/21 9:06 AM, David Malcolm wrote:
On Wed, 2021-06-16 at 08:52 -0600, Martin Sebor wrote:
On 6/16/21 6:38 AM, David Malcolm wrote:
On Tue, 2021-06-15 at 19:48 -0600, Martin Sebor wrote:
Thanks for writing the patch.
While debugging locations I noticed the semi_embedded_vec template
in
On 6/16/21 4:13 AM, Richard Biener via Gcc-patches wrote:
On Wed, Jun 16, 2021 at 5:18 AM Trevor Saunders wrote:
- Unfortunately using_auto_storage () needs to handle m_vec being null.
- Handle self move of an auto_vec to itself.
- Make sure auto_vec defines the classes move constructor and as
On 6/16/21 10:35 AM, Jason Merrill wrote:
On 6/16/21 12:11 PM, Martin Sebor wrote:
On 6/16/21 9:06 AM, David Malcolm wrote:
On Wed, 2021-06-16 at 08:52 -0600, Martin Sebor wrote:
On 6/16/21 6:38 AM, David Malcolm wrote:
On Tue, 2021-06-15 at 19:48 -0600, Martin Sebor wrote:
Thanks for writin
A user pointed out to me that the manual documented the wrong
defaults for the -Wmismatched-dealloc and -Wmismatched-new-delete
options. I pushed the correction in r12-1544 (also attached).
Martin
commit 139564821dd2e4a9cbb08677ff12cf291d7d0218
Author: Martin Sebor
Date: Wed Jun 16 16:49:56 2
On 6/17/21 12:03 AM, Richard Biener wrote:
On Wed, Jun 16, 2021 at 6:01 PM Martin Sebor wrote:
On 6/16/21 6:46 AM, Richard Sandiford via Gcc-patches wrote:
Richard Biener via Gcc-patches writes:
On Tue, Jun 15, 2021 at 8:02 AM Trevor Saunders wrote:
This makes it clear the caller owns th
On 6/18/21 4:38 AM, Richard Biener wrote:
On Thu, Jun 17, 2021 at 4:43 PM Martin Sebor wrote:
On 6/17/21 12:03 AM, Richard Biener wrote:
On Wed, Jun 16, 2021 at 6:01 PM Martin Sebor wrote:
On 6/16/21 6:46 AM, Richard Sandiford via Gcc-patches wrote:
Richard Biener via Gcc-patches writes:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571973.html
Looking for a review of v2 of the diagnostic infrastructure bits.
On 6/4/21 3:41 PM, Martin Sebor wrote:
The attached patch introduces the suppress_warning(),
warning_suppressed(), and copy_no_warning() APIs without making
us
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571974.html
I'm looking for a review of the mostly mechanical C front end changes
to the new suppress_warning() API.
On 6/4/21 3:41 PM, Martin Sebor wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the C front
end with t
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571975.html
I'm looking for a review of the mostly mechanical shared subset of
the C and C++ front end changes to the new suppress_warning() API.
On 6/4/21 3:42 PM, Martin Sebor wrote:
The attached patch replaces the uses of TREE_NO_WARN
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571977.html
Looking for a review of the C++ front end changes to switch to the new
suppress_warning() API.
On 6/4/21 3:42 PM, Martin Sebor wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the C++
front end with the new s
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571978.html
Looking for an approval of the 99% mechanical changes to switch
the FORTRAN front end from TREE_NO_WARNING to the new suppress_warning()
API. There's only one place in this patch where a specific warning is
being suppressed -
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571980.html
Looking for a review of the LTO changes to switch TREE_NO_WARNING to
the suppress_warning() API.
On 6/4/21 3:43 PM, Martin Sebor wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the LTO
front end with the new
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571981.html
Looking for a review of the middle end changes to replace the uses
of TREE_NO_WARNING and gimple_{get,set}_no_warning with the new
warning group APIs. Most of the changes are a mechanical search
and replace kind, just a handfu
-Warray-bounds relies on similar logic as -Wstringop-overflow et al.,
but using its own algorithm, including its own bugs such as PR 100137.
The attached patch takes the first step toward unifying the logic
between the warnings. It changes a subset of -Warray-bounds to call
compute_objsize() to d
On 6/21/21 8:35 PM, Kewen.Lin wrote:
Hi Richi and Martin,
Thanks Richi! One draft (not ready for review) is attached for the further
discussion. It follows the idea of RAII-style cleanup. I noticed that
Martin suggested stepping forward to make tree_predictive_commoning_loop
and its callees
On 6/21/21 1:15 AM, Richard Biener wrote:
On Fri, Jun 18, 2021 at 6:03 PM Martin Sebor wrote:
On 6/18/21 4:38 AM, Richard Biener wrote:
On Thu, Jun 17, 2021 at 4:43 PM Martin Sebor wrote:
On 6/17/21 12:03 AM, Richard Biener wrote:
On Wed, Jun 16, 2021 at 6:01 PM Martin Sebor wrote:
On
Ping: David, I'm still looking for approval of the semi_embedded_vec
change in the originally posted patch (independent of the already
approved subsequent change to rich_location).
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572845.html
On 6/15/21 7:48 PM, Martin Sebor wrote:
While debu
On 6/22/21 5:28 PM, David Malcolm wrote:
On Tue, 2021-06-22 at 19:18 -0400, David Malcolm wrote:
On Fri, 2021-06-04 at 15:41 -0600, Martin Sebor wrote:
The attached patch introduces the suppress_warning(),
warning_suppressed(), and copy_no_warning() APIs without making
use of them in the rest o
On 6/23/21 1:43 AM, Richard Biener wrote:
On Wed, Jun 23, 2021 at 7:23 AM Trevor Saunders wrote:
On Tue, Jun 22, 2021 at 02:01:24PM -0600, Martin Sebor wrote:
On 6/21/21 1:15 AM, Richard Biener wrote:
[...]
But maybe I'm misunderstanding C++ too much :/
Well, I guess b) from above means a
On 6/22/21 11:23 PM, Trevor Saunders wrote:
On Tue, Jun 22, 2021 at 02:01:24PM -0600, Martin Sebor wrote:
On 6/21/21 1:15 AM, Richard Biener wrote:
On Fri, Jun 18, 2021 at 6:03 PM Martin Sebor wrote:
On 6/18/21 4:38 AM, Richard Biener wrote:
On Thu, Jun 17, 2021 at 4:43 PM Martin Sebor wro
On 6/24/21 3:27 AM, Richard Biener wrote:
On Thu, Jun 24, 2021 at 12:56 AM Martin Sebor wrote:
On 6/23/21 1:43 AM, Richard Biener wrote:
On Wed, Jun 23, 2021 at 7:23 AM Trevor Saunders wrote:
On Tue, Jun 22, 2021 at 02:01:24PM -0600, Martin Sebor wrote:
On 6/21/21 1:15 AM, Richard Biener
On 6/24/21 3:32 AM, Richard Biener wrote:
On Mon, Jun 21, 2021 at 11:55 PM Martin Sebor via Gcc-patches
wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571980.html
Looking for a review of the LTO changes to switch TREE_NO_WARNING to
the suppress_warning() API.
Hmm, since
On 6/23/21 11:26 PM, Jeff Law wrote:
On 6/23/2021 1:47 PM, Martin Sebor via Gcc-patches wrote:
On 6/22/21 5:28 PM, David Malcolm wrote:
On Tue, 2021-06-22 at 19:18 -0400, David Malcolm wrote:
On Fri, 2021-06-04 at 15:41 -0600, Martin Sebor wrote:
The attached patch introduces the
On 6/23/21 11:09 PM, Jeff Law wrote:
On 6/4/2021 3:41 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the C front
end with the new suppress_warning(), warning_suppressed_p(), and
copy_warning() APIs.
gcc-no-warning-c.diff
Add support for
On 6/23/21 11:06 PM, Jeff Law wrote:
On 6/4/2021 3:42 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the shared
C family front end with the new suppress_warning(),
warning_suppressed_p(), and copy_warning() APIs.
gcc-no-warning-c
On 6/23/21 11:12 PM, Jeff Law wrote:
On 6/4/2021 3:42 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the C++
front end with the new suppress_warning(), warning_suppressed_p(),
and copy_warning() APIs.
gcc-no-warning-cp.diff
Add support for
On 6/23/21 11:15 PM, Jeff Law wrote:
On 6/4/2021 3:43 PM, Martin Sebor via Gcc-patches wrote:
The attached patch introduces declarations of the new
suppress_warning(), warning_suppressed_p(), and copy_warning() APIs,
and replaces the uses of TREE_NO_WARNING in the middle end with them.
gcc
On 6/1/21 3:38 PM, Jason Merrill wrote:
On 6/1/21 3:56 PM, Martin Sebor wrote:
On 5/27/21 2:53 PM, Jason Merrill wrote:
On 4/27/21 11:52 AM, Martin Sebor via Gcc-patches wrote:
On 4/27/21 8:04 AM, Richard Biener wrote:
On Tue, Apr 27, 2021 at 3:59 PM Martin Sebor wrote:
On 4/27/21 1:58 AM
On 6/25/21 4:11 PM, Jason Merrill wrote:
On 6/25/21 4:51 PM, Martin Sebor wrote:
On 6/1/21 3:38 PM, Jason Merrill wrote:
On 6/1/21 3:56 PM, Martin Sebor wrote:
On 5/27/21 2:53 PM, Jason Merrill wrote:
On 4/27/21 11:52 AM, Martin Sebor via Gcc-patches wrote:
On 4/27/21 8:04 AM, Richard
I just glanced at the patch out of curiosity and the first hunk
caught my eye. There's nothing wrong with the change and I like
how you make the APIs const-correct! Just a note that it looks
like the const in on the basic_block declaration might be missing
an underscore (it should be const_basic
Yesterday's r12-1805 resulted in an informational note being
printed unconditionally, even when the warning it goes with
is disabled. It caused an analyzer test to fail but I missed
that in my test results. I pushed the attached fix to avoid
printing them.
Martin
PR middle-end/101216 - spurious
wrote:
On 4/27/21 11:52 AM, Martin Sebor via Gcc-patches wrote:
On 4/27/21 8:04 AM, Richard Biener wrote:
On Tue, Apr 27, 2021 at 3:59 PM Martin Sebor
wrote:
On 4/27/21 1:58 AM, Richard Biener wrote:
On Tue, Apr 27, 2021 at 2:46 AM Martin Sebor via Gcc-patches
wrote:
PR 90904 notes that
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572839.html
On 6/15/21 5:00 PM, Martin Sebor wrote:
On 6/11/21 11:04 AM, David Malcolm wrote:
On Thu, 2021-06-10 at 17:26 -0600, Martin Sebor wrote:
This diff introduces the diagnostic infrastructure changes to support
controlling warni
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573349.html
On 6/21/21 4:25 PM, Martin Sebor wrote:
-Warray-bounds relies on similar logic as -Wstringop-overflow et al.,
but using its own algorithm, including its own bugs such as PR 100137.
The attached patch takes the first step towar
On 6/23/21 11:07 PM, Jeff Law wrote:
On 6/4/2021 3:41 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the Ada front
end with the new suppress_warning(), warning_suppressed_p(), and
copy_warning() APIs.
gcc-no-warning-ada.diff
Add support
On 6/23/21 11:05 PM, Jeff Law wrote:
On 6/4/2021 3:42 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the FORTRAN
front end with the new suppress_warning() API.
gcc-no-warning-fortran.diff
Add support for per-location warning groups.
gcc
On 6/23/21 11:04 PM, Jeff Law wrote:
On 6/4/2021 3:42 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in libcc1 with
the new suppress_warning() API.
gcc-no-warning-libcc1.diff
Add support for per-location warning groups.
libcc1/ChangeLog
On 6/23/21 11:02 PM, Jeff Law wrote:
On 6/4/2021 3:43 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in
the Objective-C front end with the new suppress_warning(),
warning_suppressed_p(), and copy_warning() APIs.
gcc-no-warning-objc.diff
Add
On 6/23/21 10:56 PM, Jeff Law wrote:
On 6/4/2021 3:43 PM, Martin Sebor via Gcc-patches wrote:
The attached patch adds regression tests for two closely related bugs
resolved by the patch series.
gcc-no-warning-tests.diff
Regression tests for TREE_NO_WARNING enhancement to warning groups.
PR
901 - 1000 of 1046 matches
Mail list logo
