On 10/20/2015 10:57 AM, Joseph Myers wrote:
On Tue, 20 Oct 2015, Martin Sebor wrote:
An array subscript is out of range, even if an object is apparently
accessible with the given subscript (as in the lvalue expression
a[1][7] given the declaration int a[4][5]) (6.5.6).
Just-past-the
Attached is a slightly updated patch that tweaks the diagnostic
messages to avoid assuming the English punctuation, and adds
a few test cases exercising the text of the diagnostics.
Martin
On 10/13/2015 11:22 AM, Martin Sebor wrote:
C++ placement new expression is susceptible to buffer
this
message.
Attached is patch 1 with the changes to opts.c you mention
below, adding periods to the help output printed by the driver,
and some tweaks to the test suite, plus changelogs for both
sets.
Martin
gcc/ChangeLog:
2015-10-21 Martin Sebor
PR driver/68043
* o
On 10/22/2015 04:24 AM, Eric Botcazou wrote:
Martin,
some subdirectories have their own ChangeLog file so you need to move...
2015-10-21 Martin Sebor
PR driver/68043
* opts.c (undocumented_msg, use_diagnosed_msg): New globals.
(print_filtered_help): Reference
://gcc.gnu.org/ml/gcc-patches/2015-10/msg02224.html
gcc/ChangeLog:
2015-10-22 Martin Sebor
PR driver/68043
* config/i386/i386.opt: Add missing periods to the ends of sentences.
* config/msp430/msp430.opt: Same.
gcc/testsuite/ChangeLog:
2015-10-22 Martin Sebor
PR driver/68043
* gcc.misc-tests
On 10/22/2015 03:47 PM, Joseph Myers wrote:
On Thu, 22 Oct 2015, Martin Sebor wrote:
While fixing up the ChangeLogs for the commit (as requested below)
I noticed that a number of new options have been added with help
text with no period at the end. The attached patch fixes those
up and adds a
[Sending to the right list this time]
The documentation of the -Q --help=optimizers options leads some
to expect that when options are reported as enabled imply the
corresponding optimization will take place. (See the following
question on gcc-help:
https://gcc.gnu.org/ml/gcc-help/2015-10/msg001
On 10/23/2015 05:13 AM, Bernd Schmidt wrote:
On 10/21/2015 12:10 AM, Joseph Myers wrote:
On Tue, 20 Oct 2015, Bernd Schmidt wrote:
How about
&a.v[2].a
and
&a.v[2].b
I don't think either is valid.
typedef struct FA5_7 {
int i;
char a5_7 [5][7];
} FA5_7;
__builtin_offsetof
On 10/23/2015 11:45 AM, Bernd Schmidt wrote:
On 10/23/2015 06:50 PM, Joseph Myers wrote:
On Fri, 23 Oct 2015, Martin Sebor wrote:
But now that I'm re-reading the answer above I see that Joseph
was suggesting that a5_7[5][0] should be diagnosed when the patch
accepts it as an extensio
[CC Jason]
When you have a chance, the patch is at the link below for review:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02001.html
On 10/20/2015 01:57 PM, Martin Sebor wrote:
Attached is a slightly updated patch that tweaks the diagnostic
messages to avoid assuming the English punctuation
[CC Jason]
The patch is at the link below:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01803.html
Thanks
On 10/19/2015 12:50 PM, Martin Sebor wrote:
This is a patch for two C++ bugs:
67913 - new expression with negative size not diagnosed
67927 - array new expression with excessive
Ping. Thanks in advance for a review.
On 10/22/2015 08:12 PM, Martin Sebor wrote:
[Sending to the right list this time]
The documentation of the -Q --help=optimizers options leads some
to expect that when options are reported as enabled imply the
corresponding optimization will take place
I guess this is a case where I could say either "I wrote the patch" or
"I requested changes to a patch in review"; in the latter case I can
approve it. Joseph seems on board with what we've discussed, so I'd say
please wait until Tuesday for objections then commit.
I didn't get to committing the
On 11/03/2015 05:35 AM, Aurelio Remonda wrote:
Currently, whenever operator new (std::nothrow) fails to allocate memory, it'll
check if there is a new-handler function available. If there is, it'll call
the handler and then try to allocate again. Otherwise, it'll return a null
pointer.
This ret
Besides violating the requirement of the C++ standard, replacing
Could you please point us to the relevant section where this behavior
is enforced? We couldn't find it so far.
The Required behavior of the nothrow operator new reads:
This nothrow version of operator new returns a pointer obt
On 11/03/2015 04:08 PM, Mike Stump wrote:
On Nov 3, 2015, at 1:10 PM, Martin Sebor wrote:
The "as if" requirement implies that any observable effects of
"the (possibly replaced) ordinary version" must be preserved.
The repeated calls to the new handler are among such e
I share your concerns, but I'm also sympathetic to the changes that
the Taller Technologies team are trying to make, to allow libstdc++ to
be more useful in exception-free systems.
At the very least the patch to doc/xml/manual/configure.xml must
document that this option enables behaviour that vi
On 11/02/2015 07:40 PM, Jason Merrill wrote:
On 10/26/2015 09:48 PM, Martin Sebor wrote:
+ while (TREE_CODE (oper) == NOP_EXPR)
+oper = TREE_OPERAND (oper, 0);
This is STRIP_NOPS.
+ to placement new is not checked since it's unknownwhat it might
Missing space.
+ el
On 11/03/2015 03:19 AM, Alexander Monakov wrote:
On Thu, 22 Oct 2015, Martin Sebor wrote:
[Sending to the right list this time]
The documentation of the -Q --help=optimizers options leads some
to expect that when options are reported as enabled imply the
corresponding optimization will take
eliminate
the final else and do some other cleanup. Attached is an updated
patch.
Tested on x86_64 by botstrapping C and C++ and running make check.
Martin
gcc ChangeLog
2015-11-04 Martin Sebor
PR c++/67942
* invoke.texi (-Wplacement-new): Document new option.
* gcc/testsuite/g++.d
On 11/04/2015 06:09 PM, Sandra Loosemore wrote:
On 11/04/2015 04:52 PM, Martin Sebor wrote:
gcc/ChangeLog:
2015-11-04 Martin Sebor
* opts.c (print_filtered_help): Indicate when an optimization option
is disabled as a result of -O0.
* doc/invoke.texi: Further clarify the effect
On 11/04/2015 09:27 PM, Jason Merrill wrote:
On 11/04/2015 07:15 PM, Martin Sebor wrote:
There was a lot of discussion of C++ aliasing rules at the recent
meeting; we really seem to be moving in the direction of being stricter
about which union member is active. So I think we do want to
On 11/05/2015 03:48 AM, Alexander Monakov wrote:
On Thu, 5 Nov 2015, Joseph Myers wrote:
On Wed, 4 Nov 2015, Martin Sebor wrote:
Improving the compiler output is a good idea. The attached patch
prints "[disabled by -O0]" instead of "[enabled]" when an optimization
option i
If we use gcc_checking_assert it won't fire in release builds; let's go
with that.
Okay. Attached is an updated patch with that change.
Martin
gcc ChangeLog
2015-11-05 Martin Sebor
PR c++/67942
* invoke.texi (-Wplacement-new): Document new option.
* gcc/testsuite/g
On 11/05/2015 10:10 AM, Joseph Myers wrote:
On Thu, 5 Nov 2015, Martin Sebor wrote:
optimiziation. We seem to have consensus that even though there
might be exceptions (do we know what some of them are?) the vast
majority optimizations that have -fxxx options are in fact not
performed at -O0
On 11/05/2015 11:07 AM, Joseph Myers wrote:
On Thu, 5 Nov 2015, Martin Sebor wrote:
There are several options marked Optimization that are actually matters of
language semantics that I don't think have anything to do with -O options,
e.g. -fexceptions and -fcx-limited-range. The Optimiz
On 11/02/2015 09:55 PM, Jason Merrill wrote:
On 10/26/2015 10:06 PM, Martin Sebor wrote:
+ if (TREE_CONSTANT (maybe_constant_value (outer_nelts)))
+{
+ if (tree_int_cst_lt (max_outer_nelts_tree, outer_nelts))
maybe_constant_value may return a constant, but that doesn't mean
On 11/05/2015 10:09 AM, Segher Boessenkool wrote:
On Thu, Nov 05, 2015 at 08:58:25AM -0700, Martin Sebor wrote:
I don't think that reiterating in a condensed form what the manual
doesn't make clear in many more words will help. First, even users
who do find the relevant text in the ma
On 11/05/2015 11:13 AM, Jason Merrill wrote:
OK, thanks.
I'm afraid the last patch that I just committed breaks libstdc++
bootstrap with the following error:
/home/msebor/scm/fsf/gcc-svn/libstdc++-v3/src/c++98/ios_init.cc: In
static member function ‘static bool std::ios_base::sync_with_stdio(
On 11/05/2015 04:41 PM, Martin Sebor wrote:
On 11/05/2015 11:13 AM, Jason Merrill wrote:
OK, thanks.
I'm afraid the last patch that I just committed breaks libstdc++
bootstrap with the following error:
I committed a slightly more robust fix that avoids assuming that
either the size o
On 11/05/2015 04:30 PM, Segher Boessenkool wrote:
On Thu, Nov 05, 2015 at 02:04:47PM -0700, Martin Sebor wrote:
On 11/05/2015 10:09 AM, Segher Boessenkool wrote:
On Thu, Nov 05, 2015 at 08:58:25AM -0700, Martin Sebor wrote:
I don't think that reiterating in a condensed form what the m
On 11/06/2015 05:55 AM, Rainer Orth wrote:
Martin Sebor writes:
If we use gcc_checking_assert it won't fire in release builds; let's go
with that.
Okay. Attached is an updated patch with that change.
Unfortunately, this breaks i386-pc-solaris2.10 bootstrap:
/vol/gcc/src/hg/t
workflow to avoid this problem in the future. If there is a page
on the Wiki or somewhere with best practices or recommended steps
that someone knows about, I'd be grateful for a pointer.
Again, sorry for the breakage.
Martin
2015-11-05 Martin Sebor
PR c++/67942
On 11/06/2015 05:50 AM, Andreas Schwab wrote:
I see this failure on m68k:
FAIL: g++.dg/warn/Wplacement-new-size.C -std=gnu++11 (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20151106/gcc/testsuite/g++.dg/warn/Wplacement-new-size.C:189:19:
warning: placement new constructing an o
On 11/07/2015 04:38 PM, Segher Boessenkool wrote:
On Tue, Oct 20, 2015 at 10:10:44PM +, Joseph Myers wrote:
typedef struct FA5_7 {
int i;
char a5_7 [5][7];
} FA5_7;
__builtin_offsetof (FA5_7, a5_7 [0][7]), // { dg-warning "index" }
__builtin_offsetof (FA5_7, a5_7 [1]
On 11/10/2015 09:36 AM, Marek Polacek wrote:
While both C and C++ FEs are able to reject e.g.
int a[__SIZE_MAX__ / sizeof(int)];
they are accepting code such as
int (*a)[__SIZE_MAX__ / sizeof(int)];
As Joseph pointed out, any construction of a non-VLA type whose size is half or
more of the addre
cp/
2015-11-11 Martin Sebor
PR c++/68208
* init.c (perform_member_init): Use location of member-initializer
in -Wself-init rather than that of the ctor.
gcc/testsuite/
2015-11-11 Martin Sebor
PR c++/68208
* b/gcc/testsuite/g++.dg/warn/Winit-self-4.C: New test.
diff --git a/gcc/cp/i
Oh, and we could also be more informative and print the size of an array,
or the number of elements, as clang does.
Yes, that's pretty nice. It helps but the diagnostic must point at
the right dimension. GCC often just points at the whole expression
or some token within it.
void* foo ()
{
e
On 11/11/2015 02:48 AM, Jonathan Wakely wrote:
As described in the PR, we have operator~ overloads defined for
enumeration types which produce values outside the range of valid
values for the type. In C++11 that can be trivially solved by giving
the enumeration types a fixed underlying type, but
On 11/12/2015 10:08 AM, Jonathan Wakely wrote:
On 12/11/15 08:48 -0700, Martin Sebor wrote:
On 11/11/2015 02:48 AM, Jonathan Wakely wrote:
As described in the PR, we have operator~ overloads defined for
enumeration types which produce values outside the range of valid
values for the type. In C
On 11/13/2015 05:56 AM, Jonathan Wakely wrote:
This is a non-conforming implementation of
https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#reflection.src_loc
It doesn't provide any column numbers, and fails to meet the
requirement that using current() in a NSDMI will refer t
On 11/13/2015 08:21 AM, Martin Sebor wrote:
On 11/13/2015 05:56 AM, Jonathan Wakely wrote:
This is a non-conforming implementation of
https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#reflection.src_loc
It doesn't provide any column numbers, and fails to mee
Attached is a patch fixing the ICE caused by a prior change of mine:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=230081
Tested on x86_64, committing to trunk as per Jason via IRC.
Martin
gcc/ChangeLog:
2015-11-17 Martin Sebor
PR c++/68308
* cp/in
On 11/18/2015 09:26 PM, Jason Merrill wrote:
The rs6000 target was hitting a bootstrap failure due to
-Werror=type-limits. Since warn_tautological_cmp and other warnings
avoid warning if one of the operands comes from a macro, I thought it
would make sense to do that here as well.
The also dis
Hmm, it looks like using expansion_point_if_in_system_header might avoid
the first issue you mention.
Thus.
Great, thanks! (I'll have to remember the trick for my own use!)
Martin
artin
gcc/
2015-11-20 Martin Sebor
PR c++/42121
* c/c-decl.c (grokdeclarator): Mention type size in a diagnostic.
(finish_struct): Same.
gcc/cp/
2015-11-20 Martin Sebor
PR c++/42121
* cp/class.c (layout_class_type): Mention type size in a diagnostic.
(all_bases_empty_p, f
On 11/26/2015 04:33 AM, Ramana Radhakrishnan wrote:
Cookies on ARM are 8-bytes [1], but sizeof ((size_t) n) is only 4-bytes,
so this check will fail (We'll ask for 500 bytes, the test here will only
be looking for 496).
Would it undermine the test for other architectures if I were to swap out
On 11/26/2015 10:45 AM, Martin Sebor wrote:
On 11/26/2015 04:33 AM, Ramana Radhakrishnan wrote:
Cookies on ARM are 8-bytes [1], but sizeof ((size_t) n) is only 4-bytes,
so this check will fail (We'll ask for 500 bytes, the test here will
only
be looking for 496).
Would it undermine the
specification for flexible array members).
Tested by bootstrapping and running C and C++ tests (including
libstdc++) on x86_64.
I'm not sure if this is appropriate for this stage or if it needs
to wait until after the release. Either is fine with me.
Martin
On 11/21/2015 03:17 PM, Martin Sebor wrote:
/testsuite/ChangeLog:
2015-12-05 Martin Sebor
PR c++/68711
* g++.dg/other/offsetof8.C: New test.
gcc/cp/ChangeLog:
2015-12-05 Martin Sebor
PR c++/68711
* typeck.c (build_class_member_access_expr): Strip NOPs before
testing a potentially null operand for equality to zero.
Ind
ct B { int n, a[]; };
struct C: A, B { };
but this is rejected:
struct D: B, A { };
My replies to your comments are below.
On 12/04/2015 10:51 AM, Jason Merrill wrote:
On 12/03/2015 11:42 PM, Martin Sebor wrote:
+ if (next && TREE_CODE (next) == FIELD_DECL)
This will break
clarifications to -Wextra, and adds
an example to the -Wplacement-new option.
Martin
2015-12-09 Martin Sebor
* invoke.texi (Warning Options): Update -Wall options. Clarify
when some -Wextra options are enabled. Add -Wplacement-new example.
Index: invoke.texi
@@ -471,6 +471,20 @@ c_parser_peek_2nd_token (c_parser *parser)
return &parser->tokens[1];
}
+/* Return a pointer to the Nth token from PARSER, reading it
+ in if necessary. The N-1th token is already read in. */
+
+static c_token *
+c_parser_peek_nth_token (c_parser *parser, unsigned i
On 11/23/2015 10:52 AM, David Malcolm wrote:
This patch fixes PR c/68473 by bulletproofing the new
diagnostic_show_locus implementation against ranges that finish before
they start (which can happen when using the C preprocessor), falling
back to simply printing a caret.
Successfully bootstrappe
On 12/10/2015 04:57 AM, Bernd Schmidt wrote:
On 12/10/2015 12:07 AM, Martin Sebor wrote:
* invoke.texi (Warning Options): Update -Wall options. Clarify
when some -Wextra options are enabled. Add -Wplacement-new example.
I tried to check this list against c.opt - I figure this
The improved checking of flexible array members committed in r231665
(and later) deliberately excluded anonymous structs and unions
(unnamed members of types with no tags) to allow a harmless extension
that was accepted by G++ prior to the change. However, being overly
broad, the exemption preven
On 2/18/20 1:41 AM, Stephan Bergmann wrote:
On 03/12/2019 22:49, Martin Sebor wrote:
I added another warning: -Wredundant-tags to point out instances
where the class-key or enum-key can safely be dropped. Both warnings
are off by default.
I think -Wredundant-tags would be more useful if it
On 2/18/20 9:55 AM, Jon Beniston wrote:
Hi,
The patch adds space for the string terminator, as the function is called
with test_strcpy_strcmp_abc ("abcd")
That looks right. Please go ahead and commit it.
Thanks!
Martin
ChangeLog
gcc/testsuite
2020-02-18 Jon Beniston
* gcc.dg
The -Wredundant-tags warning, new in GCC 10, issues false positives
for some declarations involving typename. Typename isn't a C++
class-key so the warning is not intended in these cases. Attached
is a simple fix tested on x86_64-linux.
Martin
PR c++/93801 - False -Wmismatched-tags upon redunda
PR 93804 points out that issuing -Wredundant-tags for declarations
in C headers included in C++ isn't helpful because the tags cannot
be removed without breaking C programs that depend on the headers.
Attached is a patch that avoids the warning in these cases tested
on x86_64-linux. While strict
On 2/18/20 5:35 PM, Jim Wilson wrote:
On Sun, Feb 16, 2020 at 9:02 PM Kito Cheng wrote:
It cause the __builtin_strlen not optimized/folded in test_local_cpy_4,
and the reason is blocked by __builtin_memcpy, it's same issue in
strlenopt-80.c, so I there is two way to fix this issue:
Another po
On 2/19/20 4:51 PM, Jason Merrill wrote:
On 2/18/20 12:06 AM, Martin Sebor wrote:
The improved checking of flexible array members committed in r231665
(and later) deliberately excluded anonymous structs and unions
(unnamed members of types with no tags) to allow a harmless extension
that was
The buffer overflow detection for multi-char stores uses the size
of a source array even when what's actually being accessed (read
and stored) is a pointer to the array. That leads to incorrect
warnings in some cases.
The attached patch corrects the function that computes the size of
the access
On 2/19/20 5:09 PM, Jason Merrill wrote:
On 2/19/20 1:02 AM, Martin Sebor wrote:
PR 93804 points out that issuing -Wredundant-tags for declarations
in C headers included in C++ isn't helpful because the tags cannot
be removed without breaking C programs that depend on the headers.
Attach
Ping: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00883.html
On 2/14/20 3:41 PM, Martin Sebor wrote:
Because attribute weakref introduces a kind of a definition, it can
only be applied to declarations of symbols that are not defined. GCC
normally issues a warning when the attribute is
On 2/17/20 10:54 AM, Jason Merrill wrote:
On 2/14/20 9:06 PM, Martin Sebor wrote:
On 2/13/20 3:59 PM, Jason Merrill wrote:
On 2/12/20 9:21 PM, Martin Sebor wrote:
On 2/11/20 5:28 PM, Jason Merrill wrote:
On 2/11/20 9:00 PM, Martin Sebor wrote:
r270155, committed in GCC 9, introduced a
-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those. According to the reported that's
making it harder to use the warning to clean up LibreOffice.
The attached patch extends -Wredundant
Release checking has exposed a bug in the transformation of
attribute access to the condensed internal format: the handler
modifies the declaration's type in place, which subsequently
triggers an ICE. A fix also exposed another bug where
the condensed format sets the attribute argument's value
di
GCC accepts attribute format even on functions without a prototype.
However, when such a function is subsequently redeclared with
a prototype the attribute validation runs into trouble. To avoid
the ICE I considered a) dropping the attribute on functions declared
without a prototype (like Clang d
On 2/26/20 3:09 PM, Jeff Law wrote:
On Wed, 2020-02-19 at 17:26 -0700, Martin Sebor wrote:
The buffer overflow detection for multi-char stores uses the size
of a source array even when what's actually being accessed (read
and stored) is a pointer to the array. That leads to incorrect
war
On 2/26/20 1:44 PM, Marek Polacek wrote:
r7-2111 introduced maybe_constant_value in cp_fully_fold.
maybe_constant_value uses cxx_eval_outermost_constant_expr, which
can clear TREE_CONSTANT:
6510 else if (non_constant_p && TREE_CONSTANT (r))
[...]
6529 TREE_CONSTANT (r) = false;
In this t
GCC considers valid explicit declarations of built-ins whose return
types match in their modes, even if the types themselves are
incompatible (say integer and pointer of the same size). This is
more permissive than for argument types where a pointer/integer
mismatch disqualifies the redeclaration
Pushed.
Martin
commit ab466f73bb3bd24965cb2c7635b0339509dafbe3 (HEAD -> master)
Author: Martin Sebor
Date: Thu Feb 27 16:53:01 2020 -0700
Document that -Wbuiltin-declaration-mismatch is enabled by default.
gcc/ChangeLog:
* doc/invoke.texi (-Wbuiltin-declarat
On 2/28/20 9:58 AM, Jason Merrill wrote:
On 2/24/20 6:58 PM, Martin Sebor wrote:
-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those. According to the reported that
Ping: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00883.html
On 2/21/20 9:49 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00883.html
On 2/14/20 3:41 PM, Martin Sebor wrote:
Because attribute weakref introduces a kind of a definition, it can
only be applied to
The wide_int APIs expect operands to have the same precision and
abort when they don't. This is especially insidious in code where
the operands normally do have the same precision but where mixed
precision arguments can come up as a result of unusual combinations
optimization options. That is al
On 3/3/20 2:42 AM, Richard Biener wrote:
On Tue, Mar 3, 2020 at 12:04 AM Martin Sebor wrote:
The wide_int APIs expect operands to have the same precision and
abort when they don't. This is especially insidious in code where
the operands normally do have the same precision but where
On 3/3/20 2:12 AM, Claudiu Zissulescu wrote:
Add ARC entry for gcc-10/changes.html
---
htdocs/gcc-10/changes.html | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 53d0ca08..4e27c05b 100644
--- a/ht
On 3/3/20 11:50 AM, Richard Biener wrote:
On March 3, 2020 4:39:34 PM GMT+01:00, Martin Sebor wrote:
On 3/3/20 2:42 AM, Richard Biener wrote:
On Tue, Mar 3, 2020 at 12:04 AM Martin Sebor
wrote:
The wide_int APIs expect operands to have the same precision and
abort when they don't.
On 3/4/20 8:54 AM, Jeff Law wrote:
Martin, I'd like your thoughts here.
As noted in the BZ our #pragmas aren't working to suppress a warning.
I did some debugging and ultimately found that the location passed down to the
diagnostic code is indeed outside the scope of the pragmas.
Further digg
The bug has been fixed for a while. I added the two tests from
the report in 97bd1d6b513..3ca63e1c76b (attached).
Martin
commit 3ca63e1c76b7693b5d3f5ba2567421defc764249 (HEAD -> master)
Author: Martin Sebor
Date: Wed Mar 4 10:23:49 2020 -0700
PR middle-end/81401 - false posit
A 2017 change that propagated call location to GIMPLE statements
had the unexpected (though not incorrect) effect of setting
the location on calls to __builtin_alloca. When such calls are
the result of the expansion of the alloca macro defined in
a system header like , the change prevents -Walloc
On 3/4/20 10:41 AM, Jason Merrill wrote:
On 2/14/20 3:06 PM, Martin Sebor wrote:
On 2/13/20 3:59 PM, Jason Merrill wrote:
On 2/12/20 9:21 PM, Martin Sebor wrote:
On 2/11/20 5:28 PM, Jason Merrill wrote:
On 2/11/20 9:00 PM, Martin Sebor wrote:
r270155, committed in GCC 9, introduced a
On 3/4/20 4:49 PM, Jeff Law wrote:
On Wed, 2020-03-04 at 09:22 -0700, Martin Sebor wrote:
I don't remember why the code in -Wrestrict unconditionally overwrites
the statement location rather than only when it's not available, but
I do remember adding conditional code like in you
On 3/5/20 12:51 AM, Richard Biener wrote:
On Thu, Mar 5, 2020 at 12:49 AM Jeff Law wrote:
On Wed, 2020-03-04 at 09:22 -0700, Martin Sebor wrote:
I don't remember why the code in -Wrestrict unconditionally overwrites
the statement location rather than only when it's not available
Treating incompatible redeclarations of built-in functions as built-ins
is a problem not just for the middle-end but even for the C front-end
itself, when different parts of it make different assumptions about
what is and isn't valid. The test case that is the subject of this
bug report (a GCC 9
On 2/28/20 1:24 PM, Jason Merrill wrote:
On 2/28/20 12:45 PM, Martin Sebor wrote:
On 2/28/20 9:58 AM, Jason Merrill wrote:
On 2/24/20 6:58 PM, Martin Sebor wrote:
-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struc
On 3/5/20 5:26 PM, Jeff Law wrote:
On Fri, 2020-02-14 at 15:41 -0700, Martin Sebor wrote:
Because attribute weakref introduces a kind of a definition, it can
only be applied to declarations of symbols that are not defined. GCC
normally issues a warning when the attribute is applied to a
On 3/9/20 1:40 PM, Jason Merrill wrote:
On 3/9/20 12:31 PM, Martin Sebor wrote:
On 2/28/20 1:24 PM, Jason Merrill wrote:
On 2/28/20 12:45 PM, Martin Sebor wrote:
On 2/28/20 9:58 AM, Jason Merrill wrote:
On 2/24/20 6:58 PM, Martin Sebor wrote:
-Wredundant-tags doesn't consider
I committed r276105 fixing these two issues plus one more that
Jeff noticed yesterday.
Martin
On 9/21/19 6:03 PM, Martin Sebor wrote:
The new get_range_strlen_dynamic function has a couple of bugs
where it assumes that the length range bounds it gets back from
get_range_strlen are non-null
GCC declares bcmp, bcopy, and bzero without the nonnull attribute.
This was a deliberate decision as is reflected in the comment in
builtins.def:
/* bcmp, bcopy and bzero have traditionally accepted NULL pointers
when the length parameter is zero, so don't apply attribute
"nonnull". */
But
-Wstringop-overflow detects a subset of past-the-end read and write
accesses by built-in functions such as memcpy and strcpy. It relies
on the functions' effects the knowledge of which is hardwired into
GCC. Although it's possible for users to create wrappers for their
own functions to detect si
On 9/30/19 1:37 AM, Richard Biener wrote:
On Sun, Sep 29, 2019 at 9:52 PM Martin Sebor wrote:
-Wstringop-overflow detects a subset of past-the-end read and write
accesses by built-in functions such as memcpy and strcpy. It relies
on the functions' effects the knowledge of which is hard
On 9/30/19 3:34 PM, Joseph Myers wrote:
On Sun, 29 Sep 2019, Martin Sebor wrote:
PR 83859 asks to expose the same checking that GCC does natively for
built-in calls via a function attribute that associates a pointer
argument with the size argument, such as:
I'll also note that, as ment
Attached is an implementation of the __has_builtin special
preprocessor operator/macro analogous to __has_attribute and
(hopefully) compatible with the synonymous Clang feature (I
couldn't actually find tests for it in the Clang test suite
but if someone points me at them I'll verify it).
Tested
On 10/1/19 11:38 AM, Jakub Jelinek wrote:
On Tue, Oct 01, 2019 at 11:16:10AM -0600, Martin Sebor wrote:
Attached is an implementation of the __has_builtin special
preprocessor operator/macro analogous to __has_attribute and
(hopefully) compatible with the synonymous Clang feature (I
couldn&#
The attached patch adds an optional argument to
compute_builtin_object_size to let it return the DECL of the object
whose size it's called to compute. This lets -Wstringop-overflow
point to the object in more instances of the warning than it does
now (but by no means all of them -- more work is n
The count_nonzero_bytes() function that computes the range of bytes
stored by a multi-byte assignment is overly conservative and fails
to determine the number of bytes to store for expressions involving
MEM_REF with DECL operands without a constant initializer. Even
though it's not possible to de
-Wclass-memaccess doesn't trigger for access to arrays of
objects whose type it's designed to trigger for. It looks
to me like a simple oversight in maybe_warn_class_memaccess.
Attached is a trivial patch to correct it tested on
x86_64-linux.
Martin
PR c++/92001 - missing -Wclass-memaccess with
Last week's enhancement to detect one-byte buffer overflows exposed
a bug that let the warning use the size of a prior MEM_REF access
and "override" the size of the actual store to the character array.
When the store was smaller than the prior access (e.g., one byte,
vs an 8-byte null pointer read
301 - 400 of 3588 matches
Mail list logo
