The attached patch replaces TREE_NO_WARNING, gimple_get_no_warning_p
and gimple_set_no_warning with the new APIs, get_no_warning,
set_no_warning, and copy_no_warning.
Add support for per-location warning groups.
gcc/ChangeLog:
* builtins.c (warn_string_no_nul): Replace uses of TREE_NO_WARNING,
On 5/24/21 5:08 PM, David Malcolm wrote:
On Mon, 2021-05-24 at 16:02 -0600, Martin Sebor wrote:
Having just one bit control whether an expression or statement should
be allowed to trigger warnings has been a source of bug reports about
false negatives for years. PR 74765 has a representative te
On 5/24/21 5:08 PM, David Malcolm via Gcc-patches wrote:
On Mon, 2021-05-24 at 16:16 -0600, Martin Sebor via Gcc-patches wrote:
The attached patch replaces TREE_NO_WARNING, gimple_get_no_warning_p
and gimple_set_no_warning with the new APIs, get_no_warning,
set_no_warning, and copy_no_warning
On 5/25/21 7:32 AM, Jason Merrill via Gcc-patches wrote:
On 5/25/21 2:57 AM, Richard Biener wrote:
On Fri, 21 May 2021, Jason Merrill wrote:
On 5/21/21 8:33 AM, Richard Biener wrote:
This adds support for the clang __builtin_shufflevector extension to
the C and C++ frontends. The builtin is
On 5/25/21 4:38 AM, Robin Dapp wrote:
Hi Martin and Jason,
The removal of the dead code looks good to me. The change to
"re-init lastalign" doesn't seem right. When it's zero it means
the conflict is between two attributes on the same declaration,
in which case the note shouldn't be printed (
On 5/25/21 8:01 AM, Iain Sandoe via Gcc-patches wrote:
Hi Martin
Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in
the Objective-C front end.
I’ve been gradually trying to improve/add locations in the ObjC stuff.
To that end, I wonder if it
On 5/25/21 10:17 AM, Aldy Hernandez via Gcc-patches wrote:
Adjustments per discussion.
OK pending tests?
Aldy
I have no concern with the alloca changes. The xfail removals from
the two tests in this patch (a nice improvement) don't seem to be
related to alloca so I'd expect them to fail unle
On 5/25/21 3:04 AM, Richard Biener wrote:
On Tue, May 25, 2021 at 2:53 AM Martin Sebor via Gcc-patches
wrote:
On 5/24/21 5:08 PM, David Malcolm wrote:
On Mon, 2021-05-24 at 16:02 -0600, Martin Sebor wrote:
The rare expressions that have no location
continue to have just one bit[1
On 5/26/21 8:00 AM, Jason Merrill wrote:
On 5/13/21 9:07 PM, Jason Merrill wrote:
On 5/13/21 7:38 PM, Martin Sebor wrote:
On 5/13/21 1:28 PM, Jason Merrill via Gcc-patches wrote:
Ping.
On 4/28/21 9:32 AM, Jason Merrill wrote:
-Wdeprecated-copy was depending only on the state of the warning
The -Wvla-parameter checking of the bounds of VLA parameters in
function redeclarations has a few bugs: a) it scans the string
that encodes the attribute access representation of the VLA
bounds from the end, failing to consider that the string may
be followed by another for a subsequent VLA, b) it
While checking objects whose addresses are passed to functions
declared to take const pointers and making sure they're initialized
the GCC 11 -Wmaybe-uninitialized enhancement assumes that the actual
argument is a pointer.
That's normally a safe assumption because for nonpointer arguments
the fro
When attribute nonnull is applied to an argument of an erroneous
type the attribute positional argument validation function ICEs
while printing a warning that mentions the invalid type.
The attached patch changes the validation function to ignore
erroneous types on the assumption that they must h
On 5/27/21 5:19 AM, Richard Sandiford wrote:
Thanks for doing this.
Martin Sebor via Gcc-patches writes:
[…]
On 5/24/21 5:08 PM, David Malcolm wrote:
On Mon, 2021-05-24 at 16:02 -0600, Martin Sebor wrote:
Subsequent patches then replace invocations of the TREE_NO_WARNING()
macro and the
, Apr 27, 2021 at 2:46 AM Martin Sebor via Gcc-patches
wrote:
PR 90904 notes that auto_vec is unsafe to copy and assign because
the class manages its own memory but doesn't define (or delete)
either special function. Since I first ran into the problem,
auto_vec has grown a move ctor and
On 5/25/21 2:59 AM, Eric Botcazou wrote:
[PATCH 2/11] use xxx_no_warning APIs in Ada.
Looks good to me, but remove the useless pair of parentheses in the 3rd hunk.
The hunk was actually incorrect, thanks for drawing my attention
to it! The second argument to the function is the option. To
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, Richard Biener wrote:
On Tue, Apr 27, 2021 at 2:46 AM Martin Sebor via Gcc
On 6/2/21 12:55 AM, Richard Biener wrote:
On Tue, Jun 1, 2021 at 9: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
On 5/31/21 7:25 AM, Martin Liška wrote:
Hello.
I've made quite some progress with the porting of the documentation and
I would like to present it to the community now:
https://splichal.eu/scripts/sphinx/
Just a few issues I noticed in the warnings section:
The headings of some warnings mentio
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 property
isn't reflected in their declarations alone, and there's no user-
level attribute to annotate t
On 6/3/21 4:56 AM, Martin Liška wrote:
On 6/2/21 10:41 PM, Martin Sebor wrote:
On 5/31/21 7:25 AM, Martin Liška wrote:
Hello.
I've made quite some progress with the porting of the documentation and
I would like to present it to the community now:
https://splichal.eu/scripts/sphinx/
Hello.
On 6/1/21 11:04 PM, Kewen Lin via Gcc-patches wrote:
As Segher suggested, this patch is to emit the error message
if the split condition of define_insn_and_split is empty while
the insn condition isn't.
gcc/ChangeLog:
* gensupport.c (process_rtx): Emit error message for empty
sp
This is a revised patch series to add warning control by group and
location, updated based on feedback on the initial series.
v2 changes include:
1) Use opt_code rather than int for the option argument to the new
APIs. This let me find and fix a bug in the original Ada change.
2) Use suppres
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.
Add support for per-location warning groups.
gcc/ada/ChangeLog:
* gcc-interface/trans.c (Handled_Sequence_Of_Statements_to_gnu):
Replac
The attached patch introduces the suppress_warning(),
warning_suppressed(), and copy_no_warning() APIs without making
use of them in the rest of GCC. They are in three files:
diagnostic-spec.{h,c}: Location-centric overloads.
warning-control.cc: Tree- and gimple*-centric overloads.
The loca
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.
Add support for per-location warning groups.
gcc/c/ChangeLog:
* c-decl.c (pop_scope): Replace direct uses of TREE_NO_WARNING with
warning
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.
Add support for per-location warning groups.
gcc/c-family/ChangeLog:
* c-common.c (c_wrap_maybe_const): Remove TREE_NO_WARNI
The attached patch replaces the uses of TREE_NO_WARNING in the RL78
back end with the new suppress_warning() and warning_suppressed_p()
APIs.
Add support for per-location warning groups.
gcc/ChangeLog:
* config/rl78/rl78.c (rl78_handle_naked_attribute): Replace a direct
use of TREE_NO_WARNING
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.
Add support for per-location warning groups.
* call.c (build_over_call): Replace direct uses of TREE_NO_WARNING
with warning_suppressed_
The attached patch replaces the uses of TREE_NO_WARNING in the FORTRAN
front end with the new suppress_warning() API.
Add support for per-location warning groups.
gcc/fortran/ChangeLog:
* trans-array.c (trans_array_constructor): Replace direct uses
of TREE_NO_WARNING with warning_suppressed_p,
The attached patch replaces the uses of TREE_NO_WARNING in libcc1 with
the new suppress_warning() API.
Add support for per-location warning groups.
libcc1/ChangeLog:
* libcp1plugin.cc (record_decl_address): Replace a direct use
of TREE_NO_WARNING with suppress_warning.
diff --git a/libcc1/lib
The attached patch replaces the uses of TREE_NO_WARNING in the LTO
front end with the new suppress_warning() API. It adds a couple of
FIXMEs that I plan to take care of in a follow up.
Add support for per-location warning groups.
gcc/lto/ChangeLog:
* gimple-streamer-out.c (output_gimple_stmt):
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.
Add support for per-location warning groups.
gcc/ChangeLog:
* builtins.c (warn_string_no_nul): Replace
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.
Add support for per-location warning groups.
gcc/objc/ChangeLog:
* objc-act.c (objc_maybe_build_modify_expr): Replace direct use
The attached patch removes the definitions of the TREE_NO_WARNING macro
and the gimple_get_no_warning_p() and gimple_set_no_warning() functions.
Remove legacy TREE_NO_WARNING amd gimple_*no_warning* APIs.
gcc/ChangeLog:
* tree.h (TREE_NO_WARNING): Remove.
* gimple.h (gimple_no_warning_p): Remo
The attached patch adds regression tests for two closely related bugs
resolved by the patch series.
Regression tests for TREE_NO_WARNING enhancement to warning groups.
PR middle-end/74765 - missing uninitialized warning (parenthesis, TREE_NO_WARNING abuse)
PR middle-end/74762 - [9/10/11/12 Regres
On 6/7/21 8:46 AM, Richard Biener via Gcc-patches wrote:
On Wed, Jun 2, 2021 at 11:29 AM Kewen.Lin wrote:
Hi,
As Richi suggested in PR100794, this patch is to remove
some unnecessary update_ssa calls with flag
TODO_update_ssa_only_virtuals, also do some refactoring.
Bootstrapped/regtested on
On 6/7/21 2:51 AM, Richard Biener wrote:
On Thu, Jun 3, 2021 at 10:29 AM Trevor Saunders wrote:
On Wed, Jun 02, 2021 at 10:04:03AM -0600, Martin Sebor via Gcc-patches wrote:
On 6/2/21 12:55 AM, Richard Biener wrote:
On Tue, Jun 1, 2021 at 9:56 PM Martin Sebor wrote:
On 5/27/21 2:53 PM
On 6/3/21 2:29 AM, Trevor Saunders wrote:
On Wed, Jun 02, 2021 at 10:04:03AM -0600, Martin Sebor via Gcc-patches wrote:
On 6/2/21 12:55 AM, Richard Biener wrote:
On Tue, Jun 1, 2021 at 9:56 PM Martin Sebor wrote:
On 5/27/21 2:53 PM, Jason Merrill wrote:
On 4/27/21 11:52 AM, Martin Sebor
On 6/8/21 3:30 AM, Kewen.Lin wrote:
on 2021/6/7 下午10:46, Richard Biener wrote:
On Wed, Jun 2, 2021 at 11:29 AM Kewen.Lin wrote:
Hi,
As Richi suggested in PR100794, this patch is to remove
some unnecessary update_ssa calls with flag
TODO_update_ssa_only_virtuals, also do some refactoring.
Bo
On 6/8/21 6:48 PM, Trevor Saunders wrote:
Hello,
This makes things a good bit shorter, and reduces complexity by removing
a bunch of index variables.
Very nice cleanup! Thank you!
Martin
bootstrapped and regtested on x86_64-linux-gnu, ok?
Trev
gcc/analyzer/ChangeLog:
* call-str
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571777.html
On 6/2/21 3:40 PM, Martin Sebor 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) function
On 6/7/21 12:29 PM, Aldy Hernandez via Gcc-patches wrote:
On 6/7/21 3:30 PM, Richard Biener wrote:
On Mon, Jun 7, 2021 at 12:10 PM Aldy Hernandez via Gcc-patches
wrote:
The substitute_and_fold_engine which evrp uses is expecting symbolics
from value_of_expr / value_on_edge / etc, which rang
On 6/9/21 12:50 PM, Aldy Hernandez wrote:
On 6/9/21 7:10 PM, Martin Sebor wrote:
On 6/7/21 12:29 PM, Aldy Hernandez via Gcc-patches wrote:
Mostly just a question of the type choices in the implementation
of the ssa_equiv_stack class: m_stack is an auto_vec while
m_replacements is a plain
Sebor via Gcc-patches wrote:
Martin and I had a chat about this patch, but it's best to discuss code
on the mailing list rather than in a silo, so here goes...
The initial patch I posted is missing initialization for a couple
of locals. I'd noticed it in testing but forgot to add
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.
Improve warning suppression for inlined functions.
Resolves:
PR middle-end/98871 - Cannot silence -
This diff removes the uses of %G and %K from all warning_at() calls
throughout GCC front end and middle end. The inlining context is
included in diagnostic output whenever it's present.
Improve warning suppression for inlined functions.
Resolves:
PR middle-end/98871 - Cannot silence -Wmaybe-unin
This patch removes the uses of %K from error() calls in the aarch64
and arm back ends. I tested this change only by building a cross-
compiler but I can't easily run the tests so I'd appreciate some help
validating it. The fallout from the change should be limited to changes
to error messages so
This final diff removes the handlers for %G and %K from the pretty
printer and the support for the directives from c-format.c so that
using them will be diagnosed.
gcc/c-family/ChangeLog:
* c-format.c (gcc_tdiag_char_table): Remove support for %G and %K.
(gcc_cdiag_char_table): Same.
(gcc_cx
On 6/10/21 7:18 AM, Martin Liška wrote:
On 6/10/21 11:07 AM, Martin Liška wrote:
Doing that, one has 2 unique links, that would be needed for get_option_url function.
Plus, both :option:`-Wfoo` and :option:`-Wno-foo` references are going to work.
And I've actually did the transformation and
On 6/11/21 3:58 AM, Richard Sandiford wrote:
Martin Sebor via Gcc-patches writes:
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 7b37e1b602c..7cdc824730c 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -13242,13 +13242,8 @@ bounds_check (rtx operand
On 6/11/21 7:10 AM, Christophe Lyon wrote:
On Fri, 11 Jun 2021 at 09:53, Christophe Lyon
wrote:
On Fri, 11 Jun 2021 at 01:29, Martin Sebor via Gcc-patches
wrote:
This patch removes the uses of %K from error() calls in the aarch64
and arm back ends. I tested this change only by building a
On 9/30/21 8:50 AM, Marek Polacek via Gcc-patches wrote:
This patch addresses one of my leftovers from GCC 11. C++20 introduced
[depr.array.comp]:
"Equality and relational comparisons between two operands of array type are
deprecated."
so this patch adds -Wdeprecated-array-compare (enabled by de
On 9/30/21 1:35 PM, Joseph Myers wrote:
On Thu, 30 Sep 2021, Martin Sebor via Gcc-patches wrote:
Jason, since you approved the C++ changes, would you mind looking
over the C bits and if they look good to you giving me the green
light to commit the patch?
https://gcc.gnu.org/pipermail/gcc
While resolving the recent -Waddress enhancement request (PR
PR102103) I came across a 2007 problem report about GCC 4 having
stopped warning for using the address of inline functions in
equality comparisons with null. With inline functions being
commonplace in C++ this seems like an important us
On 10/6/21 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...every single change to the threading code shines the light on
some warning bug.
If you take the calls.ii file from the aarch64 bootstr
On 10/6/21 11:03 AM, Aldy Hernandez wrote:
FWIW, I've opened a PR with both testcases:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
Okay, thanks. I see what you mean that reducing it to a test case
is challenging. I'll see if I can find some time to distill it to
something useful. U
On 10/8/21 9:12 AM, Aldy Hernandez via Gcc-patches wrote:
The following patch converts the strlen pass from evrp to ranger,
leaving DOM as the last remaining user.
Thanks for doing this. I know I said I'd work on it but I'm still
bogged down in my stage 1 work that's not going so great :( I j
On 10/8/21 11:56 AM, Andrew MacLeod wrote:
On 10/8/21 12:51 PM, Martin Sebor via Gcc-patches wrote:
I.e., in the test:
void g (char *s1, char *s2)
{
char b[1025];
size_t n = __builtin_strlen (s1), d = __builtin_strlen (s2);
if (n + d + 1 >= 1025)
return;
sprintf (b, "%s
On 10/8/21 4:49 AM, Aldy Hernandez via Gcc-patches wrote:
On Thu, Sep 23, 2021 at 8:32 AM Richard Biener via Gcc-patches
wrote:
On Thu, 23 Sep 2021, Hongtao Liu wrote:
On Thu, Sep 23, 2021 at 9:48 AM Hongtao Liu wrote:
On Wed, Sep 22, 2021 at 10:21 PM Martin Sebor wrote:
On 9/21/21 7:3
On 10/9/21 9:04 AM, Aldy Hernandez wrote:
On Fri, Oct 8, 2021 at 6:52 PM Martin Sebor wrote:
On 10/8/21 9:12 AM, Aldy Hernandez via Gcc-patches wrote:
The following patch converts the strlen pass from evrp to ranger,
leaving DOM as the last remaining user.
Thanks for doing this. I know I s
On 10/9/21 10:19 AM, Martin Sebor wrote:
On 10/9/21 9:04 AM, Aldy Hernandez wrote:
On Fri, Oct 8, 2021 at 6:52 PM Martin Sebor wrote:
On 10/8/21 9:12 AM, Aldy Hernandez via Gcc-patches wrote:
The following patch converts the strlen pass from evrp to ranger,
leaving DOM as the last remaining
When determining the size of an object compute_objsize_r() assumes
that addresses derived from null pointers are not derefernceable
because null pointers themselves are not, without calling
targetm.addr_space.zero_address_valid() to see if that assumption
is supported for the pointer on the target
On 10/11/21 9:30 AM, Segher Boessenkool wrote:
Hi!
On Mon, Oct 11, 2021 at 10:47:00AM +0800, Kewen.Lin wrote:
As PR102658 shows, commit r12-4240 enables vectorization at O2,
some cases need to be adjusted accordingly for rs6000 port.
- For target specific test cases, this adds -fno-tree-vector
On 10/11/21 11:43 AM, Segher Boessenkool wrote:
On Mon, Oct 11, 2021 at 10:23:03AM -0600, Martin Sebor wrote:
On 10/11/21 9:30 AM, Segher Boessenkool wrote:
On Mon, Oct 11, 2021 at 10:47:00AM +0800, Kewen.Lin wrote:
- For generic test cases, it follows the existing suggested
practice with nece
The attached change extends GCC's warnings for out-of-bounds
stores to cover atomic (and __sync) built-ins.
Rather than hardcoding the properties of these built-ins just
for the sake of the out-of-bounds detection, on the assumption
that it might be useful for future optimizations as well, I took
On 10/11/21 8:31 PM, Hongtao Liu wrote:
On Tue, Oct 12, 2021 at 4:08 AM Martin Sebor via Gcc-patches
wrote:
On 10/11/21 11:43 AM, Segher Boessenkool wrote:
On Mon, Oct 11, 2021 at 10:23:03AM -0600, Martin Sebor wrote:
On 10/11/21 9:30 AM, Segher Boessenkool wrote:
On Mon, Oct 11, 2021 at
On 10/12/21 10:18 AM, Segher Boessenkool wrote:
Hi!
On Tue, Oct 12, 2021 at 09:49:19AM -0600, Martin Sebor wrote:
Coming back to the xfail conditionals, do you think you'll
be able to put together some target-supports magic so they
don't have to enumerate all the affected targets?
There shoul
On 10/12/21 12:33 PM, Siddhesh Poyarekar wrote:
The warning is falsely triggered for THREAD_SELF in glibc when
accessing TCB through the segment register.
Thanks for looking into it! The Glibc warning is being tracked
in PR 102630. The root cause behind it is in compute_objsize_r
in pointer-q
On 10/12/21 12:52 AM, Richard Biener wrote:
On Mon, Oct 11, 2021 at 11:25 PM Martin Sebor wrote:
The attached change extends GCC's warnings for out-of-bounds
stores to cover atomic (and __sync) built-ins.
Rather than hardcoding the properties of these built-ins just
for the sake of the out-of
On 10/11/21 6:26 PM, Joseph Myers wrote:
The testcase uses the __seg_fs address space, which is x86-specific, but
it isn't in an x86-specific directory or otherwise restricted to x86
targets; thus, I'd expect it to fail for other architectures.
This is not a review of the rest of the patch.
G
On 10/13/21 1:43 AM, Kewen.Lin wrote:
on 2021/10/13 下午2:29, Hongtao Liu via Gcc-patches wrote:
On Wed, Oct 13, 2021 at 11:34 AM Hongtao Liu wrote:
On Tue, Oct 12, 2021 at 11:49 PM Martin Sebor wrote:
On 10/11/21 8:31 PM, Hongtao Liu wrote:
On Tue, Oct 12, 2021 at 4:08 AM Martin Sebor via
On 10/13/21 2:25 AM, Richard Biener wrote:
On Wed, Oct 13, 2021 at 3:32 AM Martin Sebor via Gcc-patches
wrote:
On 10/11/21 6:26 PM, Joseph Myers wrote:
The testcase uses the __seg_fs address space, which is x86-specific, but
it isn't in an x86-specific directory or otherwise restrict
On 10/9/21 12:47 PM, Aldy Hernandez via Gcc-patches wrote:
We seem to be passing a lot of context around in the strlen code. I
certainly don't want to contribute to more.
Most of the handle_* functions are passing the gsi as well as either
ptr_qry or rvals. That looks a bit messy. May I sugge
On 10/14/21 1:11 AM, liuhongt wrote:
Hi Kewen:
Cound you help to verify if this patch fix those regressions
for rs6000 port.
As discussed in [1], this patch add xfail/target selector to those
testcases, also make a copy of them so that they can be tested w/o
vectorization.
Just to make sure
On 10/17/21 10:38 PM, Hongtao Liu wrote:
On Fri, Oct 15, 2021 at 11:37 PM Martin Sebor wrote:
On 10/14/21 1:11 AM, liuhongt wrote:
Hi Kewen:
Cound you help to verify if this patch fix those regressions
for rs6000 port.
As discussed in [1], this patch add xfail/target selector to those
te
On 10/20/21 4:28 AM, Aldy Hernandez via Gcc-patches wrote:
Sometimes we can solve a candidate path without having to recurse
further back. This can mostly happen in fully resolving mode, because
we can ask the ranger what the range on entry to the path is, but
there's no reason this can't always
On 10/7/21 4:14 PM, Siddhesh Poyarekar wrote:
Handle either static sizes in function parameters or hints provided by
__attribute__ ((access (...))) to compute sizes for objects.
It's been my hope to eventually teach __builtin_object_size about
attribute access but implementing it in the new bui
On 10/21/21 1:17 AM, Aldy Hernandez wrote:
On Wed, Oct 20, 2021 at 10:01 PM Jeff Law wrote:
On 10/20/2021 9:15 AM, Aldy Hernandez wrote:
On Wed, Oct 20, 2021 at 4:35 PM Martin Sebor wrote:
I appreciate the heads up. I'm happy that the threader has
improved. I'm obviously not pleased th
On 10/21/21 1:02 PM, Andrew MacLeod via Gcc-patches wrote:
As I'm tweaking installing ranger as the VRP2 pass, I am getting a stage
2 bootstrap failure now:
In file included from
/opt/notnfs/amacleod/master/gcc/gcc/fortran/trans-decl.c:28:
/opt/notnfs/amacleod/master/gcc/gcc/tree.h: In functio
On 10/22/21 5:22 AM, Aldy Hernandez wrote:
On Thu, Oct 21, 2021 at 4:51 PM Martin Sebor wrote:
I'd like to see gimple-ssa-array-bounds invoked from the access
pass too (instead of from VRP), and eventually -Wrestrict as well.
You can do that right now. The pass has been converted to the new
On 10/22/21 9:18 AM, Aldy Hernandez wrote:
On Fri, Oct 22, 2021 at 4:27 PM Martin Sebor wrote:
On 10/22/21 5:22 AM, Aldy Hernandez wrote:
On Thu, Oct 21, 2021 at 4:51 PM Martin Sebor wrote:
I'd like to see gimple-ssa-array-bounds invoked from the access
pass too (instead of from VRP), and
On 10/4/21 3:37 PM, Jason Merrill wrote:
On 10/4/21 14:42, Martin Sebor wrote:
While resolving the recent -Waddress enhancement request (PR
PR102103) I came across a 2007 problem report about GCC 4 having
stopped warning for using the address of inline functions in
equality comparisons with null
Somewhat belatedly following Aldy's lead on finishing
the conversion to Ranger, the attached patch modifies
gimple-ssa-warn-access and other passes that use
the pointer_query machinery to provide Ranger with
the statement it's being called to determine ranges for.
The changes are almost completely
Attached is a revised patch for just the access warning pass
to diagnose out-of-bounds stores by atomic functions, with
no attr-fnspec changes.
Is this okay for trunk?
Martin
PS Just to clarify the effect of the original patch in case
it wasn't: it didn't enable optimizations of atomic built-in
The detection of overlapping sprintf calls has a limitation
that leads to both false positives (PR 102919) and negatives
(PR 102238) in corner cases involving members of aggregates.
The false positives result from the overlap logic not using
the size of the member used as an argument to %s to cons
On 10/20/21 7:22 AM, Richard Biener via Gcc-patches wrote:
This maps -ftrapv to -fsanitize=signed-integer-overflow
-fsanitize-undefined-trap-on-error, effectively removing
flag_trapv (or rather making it always false).
It sounds like C/C++ programmers might benefit from this change
but users of
On 10/25/21 12:57 PM, Jeff Law wrote:
On 10/23/2021 5:49 PM, Martin Sebor via Gcc-patches wrote:
Somewhat belatedly following Aldy's lead on finishing
the conversion to Ranger, the attached patch modifies
gimple-ssa-warn-access and other passes that use
the pointer_query machinery to pr
On 10/25/21 12:57 PM, Jeff Law wrote:
On 10/23/2021 5:49 PM, Martin Sebor via Gcc-patches wrote:
Somewhat belatedly following Aldy's lead on finishing
the conversion to Ranger, the attached patch modifies
gimple-ssa-warn-access and other passes that use
the pointer_query machinery to pr
On 10/25/21 2:24 PM, Jeff Law wrote:
On 10/25/2021 1:31 PM, Martin Sebor wrote:
On 10/25/21 12:57 PM, Jeff Law wrote:
On 10/23/2021 5:49 PM, Martin Sebor via Gcc-patches wrote:
Somewhat belatedly following Aldy's lead on finishing
the conversion to Ranger, the attached patch mod
On 10/27/21 7:30 AM, Jakub Jelinek wrote:
On Tue, Oct 26, 2021 at 10:22:19PM -0700, sunil.k.pandey via Gcc-patches wrote:
FAIL: libgomp.c/doacross-1.c (test for excess errors)
I don't see this failure in my logs (or the other one) or any
evidence of the libhomp tests having run. Does the libg
On 10/27/21 9:48 AM, Tobias Burnus wrote:
On 27.10.21 17:36, Martin Sebor via Gcc-patches wrote:
On 10/27/21 7:30 AM, Jakub Jelinek wrote:
On Tue, Oct 26, 2021 at 10:22:19PM -0700, sunil.k.pandey via
Gcc-patches wrote:
FAIL: libgomp.c/doacross-1.c (test for excess errors)
I don't see
On 10/27/21 3:59 AM, apinski--- via Gcc-patches wrote:
From: Andrew Pinski
The problem here is tree-ssa-forwprop.c likes to produce
&MEM [(void *)_4 + 152B] which is the same as
_4 p+ 152 which the rest of GCC likes better.
This implements this transformation back to pointer plus to
improve be
On 7/2/21 5:55 AM, Richard Biener wrote:
This adds the -fmove-loop-stores option, mainly as a way to disable
the store-motion part of GIMPLE invariant motion (-ftree-loop-im)
which is enabled by default. It might be sensible to turn off
-fmove-loop-stores at -O1 since it can result in compile-ti
On 6/29/21 11:35 PM, Trevor Saunders wrote:
This makes it possible to assert if input_location is used during the lifetime
of a scope. This will allow us to find places that currently use it within a
function and its callees, or prevent adding uses within the lifetime of a
function after all exi
To avoid a class of false negatives for sanitized code
-Wuninitialized recognizes the ASAN_MARK internal function
doesn't modify its argument. But the warning code doesn't do
the same for any sanitizer built-ins even though they don't
modify user-supplied arguments either. This leaves another
cl
On 7/2/21 2:52 PM, David Malcolm wrote:
...
@@ -11425,10 +11425,10 @@ expand_expr_real_1 (tree exp, rtx
target, machine_mode tmode,
DECL_ATTRIBUTES
(fndecl))) != NULL)
{
const char *ident = lang_hooks.decl_printable_name
(fndecl, 1
On 7/6/21 3:57 AM, Richard Biener wrote:
On Mon, 5 Jul 2021, Richard Biener wrote:
On Fri, 2 Jul 2021, Martin Sebor wrote:
On 7/2/21 5:55 AM, Richard Biener wrote:
This adds the -fmove-loop-stores option, mainly as a way to disable
the store-motion part of GIMPLE invariant motion (-ftree-loo
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 auto_vec is unsafe to
On 7/3/21 4:13 AM, Bernhard Reutner-Fischer wrote:
On Fri, 2 Jul 2021 13:21:10 -0600
Martin Sebor via Gcc-patches wrote:
--- a/gcc/tree-ssa-uninit.c
+++ b/gcc/tree-ssa-uninit.c
@@ -228,9 +228,26 @@ check_defs (ao_ref *ref, tree vdef, void *data_)
gimple *def_stmt = SSA_NAME_DEF_STMT (vdef
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573349.html
On 6/28/21 1:33 PM, Martin Sebor wrote:
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
401 - 500 of 1046 matches
Mail list logo
