Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/11/20 3:30 PM, Martin Sebor wrote: On 3/11/20 2:10 PM, Jason Merrill wrote: On 3/11/20 12:57 PM, Martin Sebor wrote: On 3/9/20 6:08 PM, Jason Merrill wrote: On 3/9/20 5:39 PM, Martin Sebor wrote: On 3/9/20 1:40 PM, Jason Merrill wrote: On 3/9/20 12:31 PM, Martin Sebor wrote: On

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/12/20 11:03 AM, Martin Sebor wrote: On 3/11/20 3:30 PM, Martin Sebor wrote: On 3/11/20 2:10 PM, Jason Merrill wrote: On 3/11/20 12:57 PM, Martin Sebor wrote: On 3/9/20 6:08 PM, Jason Merrill wrote: On 3/9/20 5:39 PM, Martin Sebor wrote: On 3/9/20 1:40 PM, Jason Merrill wrote: On

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/9/20 6:08 PM, Jason Merrill wrote: On 3/9/20 5:39 PM, Martin Sebor wrote: 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

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/11/20 2:10 PM, Jason Merrill wrote: On 3/11/20 12:57 PM, Martin Sebor wrote: On 3/9/20 6:08 PM, Jason Merrill wrote: On 3/9/20 5:39 PM, Martin Sebor wrote: 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

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On 4/7/20 3:36 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor wrote: On 4/7/20 1:50 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via Gcc-patches wrote: Among the numerous regressions introduced by the change committed to GCC

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On 4/9/20 1:03 PM, Jason Merrill wrote: On 4/8/20 1:23 PM, Martin Sebor wrote: On 4/7/20 3:36 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor wrote: On 4/7/20 1:50 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via Gcc-patches

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

Polacek wrote: On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via Gcc-patches wrote: Among the numerous regressions introduced by the change committed to GCC 9 to allow string literals as template arguments is a failure to recognize the C++ nullptr and GCC's __null constants as pointers

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On 4/8/20 12:43 PM, Jason Merrill wrote: On 4/7/20 2:50 PM, Martin Sebor wrote: Among the numerous regressions introduced by the change committed to GCC 9 to allow string literals as template arguments is a failure to recognize the C++ nullptr and GCC's __null constants as pointers. For one, I

Re: introduce target tmpnam and require it in tests relying on it

On 4/17/20 11:48 AM, Alexandre Oliva wrote: On Apr 9, 2020, Alexandre Oliva wrote: Some target C libraries that aren't recognized as freestanding don't have filesystem support, so calling tmpnam, fopen/open and remove/unlink fails to link. This patch introduces a tmpnam effective target

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

, Martin Sebor via Gcc-patches wrote: Among the numerous regressions introduced by the change committed to GCC 9 to allow string literals as template arguments is a failure to recognize the C++ nullptr and GCC's __null constants as pointers. For one, I didn't realize that nullptr, being a null

[PATCH] reject scalar array initialization with nullptr [PR94510]

Among the numerous regressions introduced by the change committed to GCC 9 to allow string literals as template arguments is a failure to recognize the C++ nullptr and GCC's __null constants as pointers. For one, I didn't realize that nullptr, being a null pointer constant, doesn't have a pointer

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On 4/7/20 1:50 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via Gcc-patches wrote: Among the numerous regressions introduced by the change committed to GCC 9 to allow string literals as template arguments is a failure to recognize the C++ nullptr and GCC's

[committed] update & correct -Wall and -Wrestrict documentation

-Wall was missing a couple of options and -Wrestrict mentioned its negative form as if was enabled by default (it's in -Wall). I just pushed the patch below to correct these minor mistakes: https://gcc.gnu.org/pipermail/gcc-cvs/2020-April/279540.html Martin

[PATCH] correct format of flexible array members in diagnostics (PR c/92326)

GCC 10 has changed the formatting of zero-length arrays in diagnostics to include their bound, but it also inadvertently added the zero bound to flexible array members which are confusingly represented differently between the C and C++ front ends. The attached patch corrects the problem so both

Re: [PATCH] correct format of flexible array members in diagnostics (PR c/92326)

On 4/13/20 1:25 PM, Jeff Law wrote: On Mon, 2020-04-13 at 12:39 -0600, Martin Sebor via Gcc-patches wrote: GCC 10 has changed the formatting of zero-length arrays in diagnostics to include their bound, but it also inadvertently added the zero bound to flexible array members which

[PATCH] correct strncpy range computation in restrict pass (PR 94647)

The restrict pass computes the wrong lower bound of the size of accesses to member arrays passed to strncpy as the source: it uses the third argument to the function even though the size of the read is limited by the length of the source when it is a string. This results in false positive

Re: introduce target tmpnam and require it in tests relying on it

On 4/21/20 3:50 AM, Bernhard Reutner-Fischer wrote: On 17 April 2020 21:21:41 CEST, Martin Sebor via Gcc-patches wrote: On 4/17/20 11:48 AM, Alexandre Oliva wrote: On Apr 9, 2020, Alexandre Oliva wrote: Some target C libraries that aren't recognized as freestanding don't have filesystem

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

07, 2020 at 02:46:52PM -0600, Martin Sebor wrote: On 4/7/20 1:50 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via Gcc-patches wrote: Among the numerous regressions introduced by the change committed to GCC 9 to allow string literals as template arguments

Re: [PATCH] avoid treating more incompatible redeclarations as builtin-ins [PR94040]

On 3/12/20 7:17 PM, Joseph Myers wrote: On Thu, 5 Mar 2020, Martin Sebor wrote: Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9? OK for GCC 10. Thank you. I committed it to trunk in r10-7162. Do you not want me to commit it to GCC 9 or are you leaving it up to me?

Re: [PATCH] avoid treating more incompatible redeclarations as builtin-ins [PR94040]

On 3/6/20 2:11 AM, Richard Biener wrote: On Fri, Mar 6, 2020 at 2:04 AM Martin Sebor wrote: 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

[committed] correct a built-in declaration in gcc.dg/torture/pr54261-1.c

Jeff's build-bot reported warnings in the test as a result of the recent tightening up of the -Wbuiltin-declaration-mismatch checking. The commit at the following link adjusts the test to avoid the warning: https://gcc.gnu.org/pipermail/gcc-cvs/2020-March/271705.html Tested on x86_64-linux

Re: [PATCH 1/2] c++: Replay errors during diagnosis of constraint satisfaction failures

On 3/11/20 4:18 PM, Patrick Palka via Gcc-patches wrote: ... Hmm, like this? This version introduces a new static member function diagnosing_failed_constraint::replay_errors_p that checks current_constraint_diagnosis_depth, and also sets max_depth_exceeded_p when appropriate. ... Just one

Re: [PATCH] avoid using TYPE_SIZE unless it's constant [PR94131]

On 3/25/20 9:40 AM, Jeff Law wrote: On Tue, 2020-03-17 at 19:35 -0600, Martin Sebor via Gcc-patches wrote: PR tree-optimization/94131 - ICE on printf with a VLA string and -fno-tree-ccp gcc/testsuite/ChangeLog: PR tree-optimization/94131 * gcc.dg/pr94131.c: New test. gcc

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/25/20 11:36 PM, Jason Merrill wrote: On 3/23/20 12:50 PM, Martin Sebor wrote: On 3/23/20 8:49 AM, Jason Merrill wrote: On 3/21/20 5:59 PM, Martin Sebor wrote: +  /* Diagnose class/struct/union mismatches.  IS_DECLARATION is false + for alias definition.  */ +  bool

Re: [PATCH] avoid modifying type in attribute access handler [PR94098]

On 3/25/20 3:56 PM, Jason Merrill wrote: On 3/16/20 4:41 PM, Martin Sebor wrote: The recent fix to avoid modifying in place the type argument in handle_access_attribute (PR 92721) was incomplete and didn't fully resolve the problem (an ICE in the C++ front-end).  The attached patch removes the

Re: [PATCH] avoid modifying type in attribute access handler [PR94098]

I have removed both calls to remove_attribute because with the changes to calls.c they are no longer needed. The revised patch is attached. I will plan to commit it tomorrow unless there's something else. In hindsight, I think changing the attribute from the human-readable form to the internal,

Re: [PATCH] avoid modifying type in attribute access handler [PR94098]

Thanks for the suggestion to use type_cache_hasher::equal. I'll revisit the idea of adding an assertion to decl_attribute in stage 1 and will look into using it there. Until then, unless you or anyone else has any concerns with the original patch I will plan to commit tomorrow:

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

Ping: Jason, is the latest patch acceptable or are there any other changes you want me to make? https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542538.html On 3/21/20 3:59 PM, Martin Sebor wrote: On 3/20/20 3:53 PM, Jason Merrill wrote: On 3/19/20 7:55 PM, Martin Sebor wrote: On

[PATCH] remove struct == POD coding convention [PR61339]

Last July we agreed to remove the convention that declarations of POD classes use the class-key struct (and others class). Attached is a patch to update the GCC Coding Conventions and the rationale to reflect the decision. I replaced it with a mild suggestion to use struct for C structs and

[PATCH] avoid passing expressions to decl_attributes [PR94346]

Attribute copy can be invoked with an expression argument to copy from the expression's type. However, it must avoid passing the expression as the last (optional) argument to decl_attributes because the function is only prepared to deal with DECLs and types. The attached patch passes null as

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/26/20 4:16 PM, Jason Merrill wrote: On 3/26/20 2:58 PM, Martin Sebor wrote: On 3/25/20 11:36 PM, Jason Merrill wrote: On 3/23/20 12:50 PM, Martin Sebor wrote: On 3/23/20 8:49 AM, Jason Merrill wrote: On 3/21/20 5:59 PM, Martin Sebor wrote: +  /* Diagnose class/struct/union

Re: [PATCH] avoid passing expressions to decl_attributes [PR94346]

On 3/27/20 3:55 AM, Jakub Jelinek wrote: On Thu, Mar 26, 2020 at 07:55:39PM -0600, Martin Sebor via Gcc-patches wrote: --- a/gcc/c-family/c-attribs.c +++ b/gcc/c-family/c-attribs.c @@ -2526,17 +2526,21 @@ handle_copy_attribute (tree *node, tree name, tree args

Re: [PATCH] avoid modifying type in attribute access handler [PR94098]

On 3/26/20 6:52 PM, Jason Merrill wrote: On 3/26/20 4:57 PM, Martin Sebor wrote: On 3/25/20 3:56 PM, Jason Merrill wrote: On 3/16/20 4:41 PM, Martin Sebor wrote: The recent fix to avoid modifying in place the type argument in handle_access_attribute (PR 92721) was incomplete and didn't fully

Re: [stage1][PATCH] Provide warning for missing jobserver.

On 3/26/20 3:40 AM, Martin Liška wrote: Hi. I'm suggesting to provide a warning when one uses -flto=jobserver but we can't detect job server for some reason. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed in next stage1? Thanks, Martin

Re: [PATCH, PR94774] tree-optimization: Fix use of uninitialized variable

On 4/27/20 10:58 AM, Stefan Schulze Frielinghaus wrote: Array retval is not necessarily initialized by function is_call_safe and may be used afterwards. Thus, initialize it explicitly. Ok for master? The change looks (even obviously) good to me but strictly speaking it needs the approval of

Re: [PATCH] [Stage1] Refactor tree-ssa-operands.c

On 4/22/20 12:39 PM, Giuliano Belinassi via Gcc-patches wrote: This patch refactors tree-ssa-operands.c by wrapping the global variables into a class, and also removes unused code. Just a few comments on this nice cleanup: It looks to me like class build_virtual_operands isn't safe to copy or

Re: [PATCH] correct strncpy range computation in restrict pass (PR 94647)

On 4/22/20 7:28 AM, Christophe Lyon wrote: On Tue, 21 Apr 2020 at 11:07, Richard Biener via Gcc-patches wrote: On Mon, Apr 20, 2020 at 11:29 PM Martin Sebor via Gcc-patches wrote: The restrict pass computes the wrong lower bound of the size of accesses to member arrays passed to strncpy

[PATCH] add missing -Wno-stack-usage etc. options [PR90983]

In addition to accepting argument values in excess of INT_MAX in options like -Walloca-larger-than=byte-size, GCC 9 has changed the behavior of such options with byte-size of zero. While in prior versions zero disables the warning for any size, in GCC 9 it enables it for all non-zero sizes.

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

: On 4/7/20 1:50 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via Gcc-patches wrote: Among the numerous regressions introduced by the change committed to GCC 9 to allow string literals as template arguments is a failure to recognize the C++ nullptr and GCC's

Re: introduce target tmpnam and require it in tests relying on it

On 4/22/20 2:03 AM, Bernhard Reutner-Fischer wrote: On Tue, 21 Apr 2020 at 16:59, Martin Sebor wrote: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543672.html I'm okay with the changes to the tests. The target-supports.exp changes look reasonable to me as well but I can't approve

Re: introduce target tmpnam and require it in tests relying on it

On 4/23/20 2:21 AM, Alexandre Oliva wrote: On Apr 21, 2020, Bernhard Reutner-Fischer wrote: On 17 April 2020 21:21:41 CEST, Martin Sebor via Gcc-patches wrote: On 4/17/20 11:48 AM, Alexandre Oliva wrote: On Apr 9, 2020, Alexandre Oliva wrote: Some target C libraries that aren't

Re: [PATCH] handle initialized flexible array members in __builtin_object_size [PR92815]

On 4/23/20 9:42 AM, Jeff Law wrote: On Wed, 2020-04-22 at 15:36 -0600, Martin Sebor via Gcc-patches wrote: When computing the size of an object with a flexible array member the object size pass doesn't consider that the initializer of such an object can result in its size being in excess

[PATCH] handle initialized flexible array members in __builtin_object_size [PR92815]

When computing the size of an object with a flexible array member the object size pass doesn't consider that the initializer of such an object can result in its size being in excess of the size of the enclosing type. As a result, stores into such objects by string functions causes false positive

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

1:23 PM, Martin Sebor wrote: On 4/7/20 3:36 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor wrote: On 4/7/20 1:50 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via Gcc-patches wrote: Among the numerous regressions introduced

Re: [PATCH] False-positive -Warray-bounds for char[1] on a non-zero offset in a referenced buffer

On 5/6/20 4:35 PM, Joey Liu via Gcc-patches wrote: Hi all, I think the assumption in builtin_memref::set_base_and_offset (gimple-ssa-warn-restrict.c) is not correct. It seems multiple levels of indirection may confuse gcc. When it loses the reference to the original buffer (e.g.the buffer is

Re: New mklog script

On 5/15/20 2:59 AM, Martin Liška wrote: Hi. Since we moved to git world and we're in the preparation for ChangeLog messages being in git commit messages, I think it's the right time to also simplify mklog script. I'm sending a new version (which should eventually replace contrib/mklog and

[PATCH] warn on uninitialized accesses by function calls (PR 10138)

Besides better buffer overflow checking, the new GCC 10 attribute access also provides an opportunity to detect other kinds of bugs, including uninitialized accesses by user-defined functions. The attached patch implements this enhancement. In addition, the closely related PR 10138 requests that

Re:

On 5/15/20 8:08 AM, Richard Sandiford wrote: We've moved more and more to stronly-typed data structures so I'd not like to see 'auto' everywhere - it should be still obvious what kind of objects we're working with where they matter. IMHO they do not matter for example for iterators. I don't

Re: [PATCH] Implement no_stack_protect attribute.

On 5/18/20 4:37 AM, Martin Liška wrote: Hi. The patch adds new no_stack_protect attribute. The change is requested from kernel folks and is direct equivalent of Clang's no_stack_protector. Unlike Clang, I chose to name it no_stack_protect because we already have stack_protect attribute (used

Re: [PATCH] Describe coding conventions surrounding "auto"

On 5/16/20 4:43 AM, Richard Sandiford wrote: Sorry for the empty subject line earlier... Jason Merrill writes: On Fri, May 15, 2020 at 9:47 PM Martin Sebor wrote: On 5/15/20 8:08 AM, Richard Sandiford wrote: Those are all good examples. Mind putting that into a patch for the coding

Re: [PATCH] Describe coding conventions surrounding "auto"

On 5/18/20 12:02 PM, Richard Sandiford wrote: Martin Sebor writes: On 5/16/20 4:43 AM, Richard Sandiford wrote: Sorry for the empty subject line earlier... Jason Merrill writes: On Fri, May 15, 2020 at 9:47 PM Martin Sebor wrote: On 5/15/20 8:08 AM, Richard Sandiford wrote: Those are

Re: [PATCH] tree-optimization/33315 - common stores during sinking

On 5/13/20 2:20 AM, Richard Biener wrote: This implements commoning of stores to a common successor in a simple ad-hoc way. I've decided to put it into the code sinking pass since, well, it sinks stores. It's still separate since it does not really sink code into less executed places. It's

[PATCH] handle std::byte in -Wclass-memaccess (PR 94923)

-Wclass-memaccess is suppressed for write accesses to trivially copyable but otherwise nontrivial class types by character types but the suppression neglects to consider the equivalent accesses by std::byte. The attached patch extends the same privilege also to it. I couldn't find a utility

Re: [PATCH] drop weakref attribute on function definitions (PR 92799)

On 3/12/20 2:10 PM, Jeff Law wrote: On Mon, 2020-03-09 at 14:33 -0600, Martin Sebor wrote: 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

Re: [PATCH] avoid modifying type in attribute access handler [PR94098]

On 3/16/20 3:10 PM, Jason Merrill wrote: On 3/16/20 4:41 PM, Martin Sebor wrote: The recent fix to avoid modifying in place the type argument in handle_access_attribute (PR 92721) was incomplete and didn't fully resolve the problem (an ICE in the C++ front-end).  The attached patch removes the

Re: [PATCH] avoid treating more incompatible redeclarations as builtin-ins [PR94040]

On 3/18/20 8:30 AM, Jeff Law wrote: On Wed, 2020-03-18 at 14:25 +, Szabolcs Nagy wrote: The 03/13/2020 10:45, Martin Sebor via Gcc-patches wrote: On 3/12/20 7:17 PM, Joseph Myers wrote: On Thu, 5 Mar 2020, Martin Sebor wrote: Tested on x86_64-linux. Is this acceptable for GCC 10? How

Re: [PATCH] avoid treating more incompatible redeclarations as builtin-ins [PR94040]

On 3/18/20 1:04 PM, Jakub Jelinek wrote: On Wed, Mar 18, 2020 at 12:57:18PM -0600, Martin Sebor via Gcc-patches wrote: I noticed this last night: https://sourceware.org/pipermail/glibc-cvs/2020q1/069150.html Presumably that's the fix. Or maybe for REAL_TYPE just care here about TYPE_MODE

[PING][PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541962.html On 3/12/20 4:38 PM, Martin Sebor wrote: On 3/12/20 11:03 AM, Martin Sebor wrote: On 3/11/20 3:30 PM, Martin Sebor wrote: On 3/11/20 2:10 PM, Jason Merrill wrote: On 3/11/20 12:57 PM, Martin Sebor wrote: On 3/9/20 6:08

Re: [stage1][PATCH] Add gcc_assert that _options are not dirty modified.

On 3/19/20 9:32 AM, Martin Liška wrote: On 3/19/20 10:09 AM, Jakub Jelinek wrote: I mean, optimize for the !flag_checking case... Sure, I transformed both situations into heap memory allocation. In gcc/c-family/c-attribs.c I faced maybe uninitialized warning when I only assigned (and checked)

Re: [PATCH] c++: Fix spelling of non-static

On 3/19/20 9:48 AM, Marek Polacek via Gcc-patches wrote: I was looking at DR 296 and noticed that we say "nonstatic" instead of "non-static", which is the version the standard uses. So this patch fixes the spelling throughout the front end. Did not check e.g. non-dependent or any other.

Re: [PATCH] strlen: Punt on UB reads past end of string literal [PR94187]

On 3/17/20 2:39 AM, Jakub Jelinek wrote: Hi! The gcc.dg/pr68785.c test which contains: int foo (void) { return *(int *) ""; } has UB in the program if it is ever called, but causes UB in the compiler as well as at least in theory non-reproduceable code generation. The problem is that nbytes

[PATCH] avoid using TYPE_SIZE unless it's constant [PR94131]

get_range_strlen() returns non-constant type sizes for VLAs that the new get_range_strlen_dynamic() function isn't prepared to deal with and ICEs. Extending the functions to deal with VLAs (and other dynamically allocated objects) is on my list of things to do for GCC 11. For GCC 10, the

Re: [stage1][PATCH] optgen: make more sanity checks for enums.

On 3/17/20 9:46 AM, Martin Liška wrote: Hi. The patch is about better sanity check in option generation script. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed in stage1? @@ -72,6 +72,19 @@ function opt_args(name, flags) return flags }

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/18/20 9:07 PM, Jason Merrill wrote: On 3/12/20 6:38 PM, Martin Sebor wrote: ... After a lot more trial and error I discovered most_specialized_partial_spec in pt.c with whose help I have been able to get templates to work the way I think they should (at least the cases I've tested do).

Re: [PATCH] driver: Improve the generated help text for alias options with arguments

On 3/17/20 5:52 AM, Richard Sandiford wrote: Lewis Hyatt writes: On Mon, Mar 16, 2020 at 06:11:08PM +, Richard Sandiford wrote: Lewis Hyatt via Gcc-patches writes: ... FWIW there are three other options currently affected by this change (-Wimplicit-fallthrough, -fcf-protection, and

Re: [PATCH] driver: Improve the generated help text for alias options with arguments

On 3/20/20 11:46 AM, Richard Sandiford wrote: Martin Sebor writes: On 3/17/20 5:52 AM, Richard Sandiford wrote: Lewis Hyatt writes: On Mon, Mar 16, 2020 at 06:11:08PM +, Richard Sandiford wrote: Lewis Hyatt via Gcc-patches writes: ... FWIW there are three other options currently

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/20/20 3:53 PM, Jason Merrill wrote: On 3/19/20 7:55 PM, Martin Sebor wrote: On 3/18/20 9:07 PM, Jason Merrill wrote: On 3/12/20 6:38 PM, Martin Sebor wrote: ... + declarations of a class from its uses doesn't work for type aliases + (as in using T = class C;).  */ Good point. 

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/23/20 8:49 AM, Jason Merrill wrote: On 3/21/20 5:59 PM, Martin Sebor wrote: +  /* Diagnose class/struct/union mismatches.  IS_DECLARATION is false + for alias definition.  */ +  bool decl_class = (is_declaration + && cp_parser_declares_only_class_p (parser));   

[PING 2][PATCH] issue -Walloca even when alloca is a system header macro [PR94004]

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542113.html On 3/16/20 6:00 PM, Martin Sebor wrote: On 3/16/20 3:41 PM, Jeff Law wrote: On Mon, 2020-03-16 at 11:39 -0600, Martin Sebor via Gcc-patches wrote: Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541521.html I

Re: [PATCH] issue -Walloca even when alloca is a system header macro [PR94004]

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541521.html On 3/4/20 2:06 PM, Martin Sebor wrote: 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

[PATCH] avoid modifying type in attribute access handler [PR94098]

The recent fix to avoid modifying in place the type argument in handle_access_attribute (PR 92721) was incomplete and didn't fully resolve the problem (an ICE in the C++ front-end). The attached patch removes the remaining modification that causes the ICE. In addition, the change adjusts

Re: [PATCH] issue -Walloca even when alloca is a system header macro [PR94004]

On 3/16/20 3:41 PM, Jeff Law wrote: On Mon, 2020-03-16 at 11:39 -0600, Martin Sebor via Gcc-patches wrote: Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541521.html I think Jakub indicated the test was incorrect. Please resolve that issue and repost. I think the core patch is OK

Re: [PATCH] c++: Fix spelling of non-static

On 5/7/20 11:24 AM, Marek Polacek wrote: On Thu, Mar 19, 2020 at 12:51:42PM -0400, Marek Polacek via Gcc-patches wrote: On Thu, Mar 19, 2020 at 10:45:01AM -0600, Martin Sebor via Gcc-patches wrote: On 3/19/20 9:48 AM, Marek Polacek via Gcc-patches wrote: I was looking at DR 296 and noticed

Re: [PATCH] c++: Fix spelling of non-static

On 5/7/20 12:44 PM, Marek Polacek wrote: On Thu, May 07, 2020 at 12:34:44PM -0600, Martin Sebor wrote: On 5/7/20 11:24 AM, Marek Polacek wrote: On Thu, Mar 19, 2020 at 12:51:42PM -0400, Marek Polacek via Gcc-patches wrote: On Thu, Mar 19, 2020 at 10:45:01AM -0600, Martin Sebor via Gcc-patches

Re: PING[STAGE 1][PATCH][x86][1/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

On 5/4/20 10:51 AM, Qing Zhao via Gcc-patches wrote: Hi, This is a PING for this patch for gcc11 stage 1. https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html Please take a look on it. Just a couple of minor

Re: [C++ Patch] PR 90915 [9/10 Regression] ICE in has_attribute, at c-family/c-attribs.c:4221

On 5/7/20 5:03 PM, Marek Polacek via Gcc-patches wrote: On Wed, Jan 29, 2020 at 10:06:51PM +0100, Paolo Carlini wrote: Hi, On 29/01/20 19:00, Jason Merrill wrote: On 1/29/20 4:31 AM, Paolo Carlini wrote: Hi, in this regression we issue a diagnostic about an incomplete type (only a warning

[PATCH] avoid -Warray-bounds when indexing into array members of union (PR 94940)

The improved detection of accesses to interior zero-length arrays fails to consider the case when the array is a member of a union. Such accesses are documented as supported so warning for them is not expected. The attached patch adjusts the component_ref_size function to return the size of the

Re: [PATCH] handle std::byte in -Wclass-memaccess (PR 94923)

On 5/18/20 3:04 PM, Jason Merrill wrote: On 5/8/20 2:16 PM, Martin Sebor wrote: -Wclass-memaccess is suppressed for write accesses to trivially copyable but otherwise nontrivial class types by character types but the suppression neglects to consider the equivalent accesses by std::byte.  The

Re: [PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

On 9/1/20 1:22 PM, Jason Merrill wrote: On 8/11/20 12:19 PM, Martin Sebor via Gcc-patches wrote: -Wplacement-new handles array indices and pointer offsets the same: by adjusting them by the size of the element.  That's correct for the latter but wrong for the former, causing false positives

Re: [PATCH] separate reading past the end from -Wstringop-overflow

On 9/1/20 4:22 PM, Jeff Law wrote: On Tue, 2020-09-01 at 16:13 -0600, Martin Sebor wrote: On 9/1/20 2:09 AM, Christophe Lyon wrote: On Mon, 31 Aug 2020 at 23:50, Martin Sebor wrote: On 8/31/20 4:51 AM, Christophe Lyon wrote: Hi, ... I pushed a small aarch64 patch as obvious:

Re: [PATCH] separate reading past the end from -Wstringop-overflow

On 8/31/20 4:51 AM, Christophe Lyon wrote: Hi, ... I pushed a small aarch64 patch as obvious: 2020-08-31 Christophe Lyon gcc/testsuite/ * gcc.target/aarch64/strcmpopt_6.c: Suppress -Wstringop-overread. (same as you added for i386) Thank you! On arm, there is a

Re: [PATCH] separate reading past the end from -Wstringop-overflow

On 8/31/20 3:50 PM, Martin Sebor wrote: On 8/31/20 4:51 AM, Christophe Lyon wrote: Hi, ... I pushed a small aarch64 patch as obvious: 2020-08-31  Christophe Lyon  gcc/testsuite/ * gcc.target/aarch64/strcmpopt_6.c: Suppress -Wstringop-overread. (same as you added

[PING 2][PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

12:44 PM, Martin Sebor wrote: Joseph, do you have any more comments on the rest of the most recent revision of the patch? https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html Martin On 8/19/20 6:09 PM, Joseph Myers wrote: On Wed, 19 Aug 2020, Martin Sebor via Gcc-patches wrote: I

[PING][PATCH] improve validation of attribute arguments (PR c/78666)

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552500.html Aldy provided a bunch of comments on this patch but I'm still looking for a formal approval. Martin On 8/24/20 10:45 AM, Martin Sebor wrote: On 8/24/20 4:59 AM, Aldy Hernandez wrote: On 8/21/20 1:37 AM, Martin Sebor

[PING][PATCH] use get_size_range to get allocated size (PR 92942)

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552903.html On 8/28/20 11:12 AM, Martin Sebor wrote: The gimple_call_alloc_size() function that determines the range of sizes of allocated objects and constrains the bounds in calls to functions like memcpy calls get_range() instead of

[PATCH] correct offset range adjustment in compute_objsize (PR 96903)

In a recent change I added an incorrect adjustment to the conversion of an offset range with inverted bounds (i.e., upper less than lower) that caused a regression I overlooked in testing. Attached is a fix for this tested on x86_64-linux, and with a more comprehensive test. I plan to commit

Re: [RFC Patch] mklog.py: Parse first 10 lines for PR/DR number

On 9/8/20 3:47 AM, Tobias Burnus wrote: Hi Martin, hi all, currently, mklog searches for "PR" (and "DR") only in the first line of a new 'testsuite' file. I think in many cases, the PR is listed a bit later than the first line – although, it is usually in the first few lines; in my example, it

[PATCH] document -Wuninitialized for allocated objects

The attached patch updates the manual to mention that Wuninitialized and -Wmaybe-uninitialized are issued for both auto and allocated objects, as well as for passing pointers to uninitialized objects to const-qualified parameters. Both of these features are GCC 11 enhancements. Martin Document

[PATCH] warn for integer overflow in allocation calls (PR 96838)

Overflowing the size of a dynamic allocation (e.g., malloc or VLA) can lead to a subsequent buffer overflow corrupting the heap or stack. The attached patch diagnoses a subset of these cases where the overflow/wraparound is still detectable. Besides regtesting GCC on x86_64-linux I also

[PATCH] work harder to avoid -Wuninitialized for empty structs (PR 96295)

The -Wuninitialized/-Wmaybe-uninitialized enhancement to warn when a pointer or reference to an uninitialized object is passed to a const-qualified function argument tries to avoid triggering for objects of empty types. However, the suppression is incomplete and lets the warning trigger in some

Re: [PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

On 9/4/20 11:14 AM, Jason Merrill wrote: On 9/3/20 2:44 PM, Martin Sebor wrote: On 9/1/20 1:22 PM, Jason Merrill wrote: On 8/11/20 12:19 PM, Martin Sebor via Gcc-patches wrote: -Wplacement-new handles array indices and pointer offsets the same: by adjusting them by the size of the element

[PING][PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

:09 PM, Joseph Myers wrote: On Wed, 19 Aug 2020, Martin Sebor via Gcc-patches wrote: I think you need a while loop there, not just an if, to account for the case of multiple consecutive cdk_attrs.  At least the GNU attribute syntax direct-declarator: [...]    ( gnu-attributes[opt

[committed] improve handling of offset wraparound in -Wstringop-overread

ILP32 failures in a test added for the new -Wstringop-overread option exposed an unnecessarily restrictive handling of offsets in ranges with an upper bound that's apparently less than the lower bound. I have relaxed the handling of this case to avoid these failures and improve the efficacy of

Re: [PATCH] separate reading past the end from -Wstringop-overflow

On 9/1/20 2:09 AM, Christophe Lyon wrote: On Mon, 31 Aug 2020 at 23:50, Martin Sebor wrote: On 8/31/20 4:51 AM, Christophe Lyon wrote: Hi, ... I pushed a small aarch64 patch as obvious: 2020-08-31 Christophe Lyon gcc/testsuite/ *

Re: [PING][PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

expect the rebase to require any substantive modifications.) Martin On 9/14/20 4:01 PM, Martin Sebor wrote: On 9/4/20 11:14 AM, Jason Merrill wrote: On 9/3/20 2:44 PM, Martin Sebor wrote: On 9/1/20 1:22 PM, Jason Merrill wrote: On 8/11/20 12:19 PM, Martin Sebor via Gcc-patches wrote: -Wplacement

Re: [PING][PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

, Martin Sebor wrote: On 9/4/20 11:14 AM, Jason Merrill wrote: On 9/3/20 2:44 PM, Martin Sebor wrote: On 9/1/20 1:22 PM, Jason Merrill wrote: On 8/11/20 12:19 PM, Martin Sebor via Gcc-patches wrote: -Wplacement-new handles array indices and pointer offsets the same: by adjusting them

Re: [PING][PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

On 10/7/20 3:01 PM, Jason Merrill wrote: On 10/7/20 4:11 PM, Martin Sebor wrote: ... For the various member functions, please include the comments with the definition as well as the in-class declaration. Only one access_ref member function is defined out-of-line: offset_bounded().  I've

Re: [PATCH] issue -Wstring-compare in more case (PR 95673)

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555225.html On 9/30/20 6:14 PM, Martin Sebor wrote: -Wstring-compare triggers under the same strict conditions as the strcmp/strncmp call is folded into a constant: only when all the uses of the result are [in]equality expressions

Re: [PING][PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

, Jason Merrill wrote: On 8/11/20 12:19 PM, Martin Sebor via Gcc-patches wrote: -Wplacement-new handles array indices and pointer offsets the same: by adjusting them by the size of the element.  That's correct for the latter but wrong for the former, causing false positives when the element size

[PATCH] peel off one less layer of array types (PR 97391)

The new gimple_parm_array_size() function computes the size of an array function parameter implied by its upper bound. The code that does this strips one too many layers of array types from the parameter, returning a smaller size than implied by the second most significant bound. (I must have

  1   2   3   4   5   6   7   8   9   10   >