Re: [-Wstringop-overflow=] strncat(3)

On 12/14/22 16:14, Alejandro Colomar via Libc-alpha wrote: [CC += groff] Hi Andrew, On 12/14/22 23:57, Andrew Pinski wrote: On Wed, Dec 14, 2022 at 2:46 PM Alejandro Colomar via Libc-alpha wrote: Hi, I was rewriting the strncat(3) manual page, and when I tried to compile the example prog

Re: [RFC] Support for nonzero attribute

On 6/13/22 06:55, Miika via Gcc wrote: Thank you for the feedback! On Sunday, June 12th, 2022 at 7:25 AM, Prathamesh Kulkarni wrote: On Mon, 6 Jun 2022 at 01:39, Miika via Gcc gcc@gcc.gnu.org wrote: Based on Jakub's and Yair's comments I created a new attribute "inrange". Inrage takes three

Re: [PATCH v3] Document that the 'access' and 'nonnull' attributes are independent

On 3/25/22 12:45, David Malcolm wrote: On Wed, 2022-03-23 at 17:52 +0100, Sebastian Huber wrote: On 23/03/2022 17:31, Martin Sebor via Gcc-patches wrote: The concern is that the constraints implied by atttributes access and nonnull are independent of each other. I would suggest to document

Re: [PATCH v2] Document that the 'access' and 'nonnull' attributes are independent

On 3/23/22 07:01, David Malcolm wrote: On Mon, 2022-03-14 at 16:18 -0600, Martin Sebor wrote: On 3/9/22 14:57, David Malcolm via Gcc wrote: On Wed, 2022-03-09 at 13:30 -0800, Andrew Pinski wrote: On Wed, Mar 9, 2022 at 1:25 PM David Malcolm via Gcc wrote: We gained __attribute__ ((access

Re: [PATCH] Document that the 'access' and 'nonnull' attributes are independent

On 3/9/22 14:57, David Malcolm via Gcc wrote: On Wed, 2022-03-09 at 13:30 -0800, Andrew Pinski wrote: On Wed, Mar 9, 2022 at 1:25 PM David Malcolm via Gcc wrote: We gained __attribute__ ((access, ...)) in GCC 10: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html which id

Re: Accessing const parameter of GIMPLE_CALL

On 1/17/22 12:18, Shubham Narlawar via Gcc wrote: On Mon, Jan 17, 2022 at 1:55 PM Richard Biener wrote: On Mon, Jan 17, 2022 at 12:54 AM David Malcolm via Gcc wrote: On Sun, 2022-01-16 at 18:52 +0530, Shubham Narlawar via Gcc wrote: Hello, Hi; various notes inline below... My aim is t

Re: reordering of trapping operations and volatile

On 1/14/22 07:58, Paul Koning via Gcc wrote: On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc wrote: Hello, On Thu, 13 Jan 2022, Martin Uecker wrote: Handling all volatile accesses in the very same way would be possible but quite some work I don't see much value in. I see some value.

Re: getting branch conditions using ranger

On 12/15/21 12:23 PM, Andrew MacLeod wrote: On 12/14/21 18:55, Martin Sebor wrote: Thanks a lot for the feedback! I'll need some time to fully digest it. Just a few clarifying comments to explain what I'm after. Andrew, to improve the context of the late warnings I'm tryin

getting branch conditions using ranger

Andrew, to improve the context of the late warnings I'm trying to see how to get the execution path(s) leading from function entry up to a statement. For example, for the code below I'd like to "collect" and show the three conditionals in the context of the warning: extern char a[9]; void f (in

does TARGET_MEM_REF documentation need updating?

The manual says that the first argument of a TARGET_MEM_REF "is @code{TMR_SYMBOL} and must be a @code{VAR_DECL} of an object with a fixed address." The TARGET_MEM_REF below has as its first argument an ADDR_EXPR and not a VAR_DECL as the manual claims. The code I looked at seems to be prepa

Re: [PATCH] Add 'no_builtin' function attribute

On 11/2/21 3:14 PM, Keith Packard via Gcc-patches wrote: This attribute controls optimizations which make assumptions about the semantics of builtin functions. Typical cases here are code which match memcpy, calloc, sincos, or which call builtins like free. This extends on things like the -ftree

Re: assembler errors when bootstrapping with #pragma optimize "0"

On 10/21/21 6:10 PM, Tom Kacvinsky via Gcc wrote: On Thu, Oct 21, 2021 at 8:06 PM Martin Sebor via Gcc wrote: I put #pragma GCC optimize "0" at the top of gimplify.c to help me debug something in a bootstrapped compiler. The file failed to compile with many assembler errors like t

assembler errors when bootstrapping with #pragma optimize "0"

I put #pragma GCC optimize "0" at the top of gimplify.c to help me debug something in a bootstrapped compiler. The file failed to compile with many assembler errors like this: /tmp/ccL9zcXD.s: Assembler messages: /tmp/ccL9zcXD.s:9: Error: CFI instruction used without previous .cfi_startproc I

Re: TYPE_NEEDS_CONSTRUCTING zero for std::string?

On 10/1/21 11:44 AM, Florian Weimer wrote: * Martin Sebor via Gcc: I'd expect TYPE_NEEDS_CONSTRUCTING to be non-zero in the middle end for any C++ type with a user-defined ctor, but in some of my testing I see it's actually zero for std::string, at least in some instances (but n

TYPE_NEEDS_CONSTRUCTING zero for std::string?

I'd expect TYPE_NEEDS_CONSTRUCTING to be non-zero in the middle end for any C++ type with a user-defined ctor, but in some of my testing I see it's actually zero for std::string, at least in some instances (but nonzero for other types with ctors). Is there something special about std::string that

Re: nvtpx: error: array subscript -1 is below array bounds of 'short int [2][16]'

On 9/4/21 1:10 PM, Jan-Benedict Glaw wrote: Hi! Running automated tests again, I found that when building current (2fcfc03459a907c0237ea6e2c6e4ce4871034bed) GCC with a recent GCC, a build (make all-gcc) when ./configure'ed for -target=nvptx-none --enable-werror-always --enable-languages=all --di

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

On 9/17/21 3:12 AM, Jakub Jelinek via Gcc wrote: On Fri, Sep 17, 2021 at 10:08:34AM +0200, Florian Weimer via Gcc wrote: So the compiler would emit a call to __memcmpeq and at the same time emit a weak alias of __memcmpeq to memcmp so the program links when the libc version targeted does not pro

Re: [FYI] bugzilla cleanup

On 9/17/21 8:54 AM, Richard Earnshaw wrote: On 16/09/2021 16:44, Martin Sebor via Gcc wrote: On 9/14/21 2:10 AM, Andrew Pinski via Gcc wrote: Hi all,    I am doing some bugzilla cleanup.  This includes disabling some components and some versions for new bugs. So far I have disabled versions

Re: [FYI] bugzilla cleanup

On 9/14/21 2:10 AM, Andrew Pinski via Gcc wrote: Hi all, I am doing some bugzilla cleanup. This includes disabling some components and some versions for new bugs. So far I have disabled versions before GCC 4 because we have not had a report from someone for those versions in over 7 years. I

Re: Exact inform format escape sequence (GCC 10 or GCC 11)

On 9/14/21 3:43 AM, Basile Starynkevitch wrote: On 9/14/21 11:32 AM, Martin Liška wrote: On 9/10/21 15:05, Basile Starynkevitch wrote: Hello all, In the Bismon static source code analyzer on https://github.com/bstarynk/bismon/ commit ad8b6270691e (funded by http://decoder-project.eu/ )

Re: Fix 'hash_table::expand' to destruct stale Value objects

-16T14:10:00-0600, Martin Sebor wrote: On 8/16/21 6:44 AM, Thomas Schwinge wrote: On 2021-08-12T17:15:44-0600, Martin Sebor via Gcc wrote: On 8/6/21 10:57 AM, Thomas Schwinge wrote: So I'm trying to do some C++... ;-) Given: /* A map from SSA names or var decls to record f

Re: Problems in array access

On 8/31/21 2:39 AM, Utkarsh Singh via Gcc wrote: On 2021-08-31, 09:28 +0100, Jonathan Wakely wrote: On Tue, 31 Aug 2021 at 09:11, Utkarsh Singh wrote: Hello GCC mailing list, In one of my friend's C programming class, they asked him a question on the topic of array bounds based on the follw

Re: [RFC] Adding a new attribute to function param to mark it as constant

On 8/18/21 12:52 AM, Prathamesh Kulkarni wrote: On Fri, 13 Aug 2021 at 22:44, Martin Sebor wrote: On 8/12/21 2:32 AM, Prathamesh Kulkarni wrote: On Sat, 7 Aug 2021 at 02:09, Martin Sebor wrote: On 8/6/21 4:51 AM, Richard Earnshaw wrote: On 06/08/2021 01:06, Martin Sebor via Gcc wrote

Re: Expensive selftests

On 8/17/21 12:40 AM, Thomas Schwinge wrote: Hi! On 2021-08-16T14:10:00-0600, Martin Sebor wrote: On 8/16/21 6:44 AM, Thomas Schwinge wrote: [...], to document the current behavior, I propose to "Add more self-tests for 'hash_map' with Value type with non-trivial constructor/d

Re: 'hash_map>'

On 8/16/21 6:44 AM, Thomas Schwinge wrote: Hi! On 2021-08-12T17:15:44-0600, Martin Sebor via Gcc wrote: On 8/6/21 10:57 AM, Thomas Schwinge wrote: So I'm trying to do some C++... ;-) Given: /* A map from SSA names or var decls to record fields. */ typedef hash_map field_

Re: [RFC] Adding a new attribute to function param to mark it as constant

On 8/12/21 2:32 AM, Prathamesh Kulkarni wrote: On Sat, 7 Aug 2021 at 02:09, Martin Sebor wrote: On 8/6/21 4:51 AM, Richard Earnshaw wrote: On 06/08/2021 01:06, Martin Sebor via Gcc wrote: On 8/4/21 3:46 AM, Richard Earnshaw wrote: On 03/08/2021 18:44, Martin Sebor wrote: On 8/3/21 4

Re: 'hash_map>'

On 8/6/21 10:57 AM, Thomas Schwinge wrote: Hi! So I'm trying to do some C++... ;-) Given: /* A map from SSA names or var decls to record fields. */ typedef hash_map field_map_t; /* For each propagation record type, this is a map from SSA names or var decls to propaga

Re: [RFC] Adding a new attribute to function param to mark it as constant

On 8/6/21 4:51 AM, Richard Earnshaw wrote: On 06/08/2021 01:06, Martin Sebor via Gcc wrote: On 8/4/21 3:46 AM, Richard Earnshaw wrote: On 03/08/2021 18:44, Martin Sebor wrote: On 8/3/21 4:11 AM, Prathamesh Kulkarni via Gcc wrote: On Tue, 27 Jul 2021 at 13:49, Richard Biener wrote: On

Re: [RFC] Adding a new attribute to function param to mark it as constant

On 8/4/21 3:46 AM, Richard Earnshaw wrote: On 03/08/2021 18:44, Martin Sebor wrote: On 8/3/21 4:11 AM, Prathamesh Kulkarni via Gcc wrote: On Tue, 27 Jul 2021 at 13:49, Richard Biener wrote: On Mon, Jul 26, 2021 at 11:06 AM Prathamesh Kulkarni via Gcc wrote: On Fri, 23 Jul 2021 at 23:29

Re: Failures building glibc with mainline GCC

On 8/3/21 3:00 PM, Joseph Myers wrote: On Tue, 3 Aug 2021, Segher Boessenkool wrote: On Tue, Aug 03, 2021 at 10:20:49AM -0600, Martin Sebor via Gcc wrote: On 8/3/21 9:54 AM, Joseph Myers wrote: As discussed, this is a bug indicating that the code generating that warning fails to check

Re: Failures building glibc with mainline GCC

On 8/3/21 11:21 AM, Joseph Myers wrote: On Tue, 3 Aug 2021, Martin Sebor via Gcc wrote: Yes, we know about that one. What I'm asking for is the translation units with the other warnings you showed with the latest GCC (including the threader patches) on the other targets (including i68

Re: [RFC] Adding a new attribute to function param to mark it as constant

On 8/3/21 4:11 AM, Prathamesh Kulkarni via Gcc wrote: On Tue, 27 Jul 2021 at 13:49, Richard Biener wrote: On Mon, Jul 26, 2021 at 11:06 AM Prathamesh Kulkarni via Gcc wrote: On Fri, 23 Jul 2021 at 23:29, Andrew Pinski wrote: On Fri, Jul 23, 2021 at 3:55 AM Prathamesh Kulkarni via Gcc wr

Re: Failures building glibc with mainline GCC

On 8/3/21 9:54 AM, Joseph Myers wrote: On Mon, 2 Aug 2021, Martin Sebor via Gcc wrote: On 7/30/21 2:52 PM, Joseph Myers wrote: On Fri, 30 Jul 2021, Aldy Hernandez via Gcc wrote: There's a new jump threader in GCC which is much more aggressive, and may trigger latent problems with

Re: Failures building glibc with mainline GCC

On 7/30/21 2:52 PM, Joseph Myers wrote: On Fri, 30 Jul 2021, Aldy Hernandez via Gcc wrote: There's a new jump threader in GCC which is much more aggressive, and may trigger latent problems with other warning passes, especially -Warray-bounds, -Woverflow, and -Wuninitialized. Do your problems g

Re: Failures building glibc with mainline GCC

On 7/30/21 10:45 AM, Jeff Law via Gcc wrote: On 7/30/2021 10:19 AM, Aldy Hernandez via Libc-alpha wrote: There's a new jump threader in GCC which is much more aggressive, and may trigger latent problems with other warning passes, especially -Warray-bounds, -Woverflow, and -Wuninitialized. [ .

Re: Failures building glibc with mainline GCC

On 7/30/21 9:30 AM, Joseph Myers wrote: There are a lot of failures building glibc with mainline GCC right now (previously, there were ICEs building glibc on various architectures, so these might be hard to bisect): * x86_64

Re: Pushing XFAILed test cases

On 7/16/21 9:32 AM, Thomas Schwinge wrote: [Also including for guidance.] Hi! (I'm not involved in or familiar with Sandra's Fortran TS29113 work, just commenting generally here.) On 2021-07-16T09:52:28+0200, Thomas Koenig via Gcc-patches wrote: It is my understanding that it is not gcc

Re: [PATCH] Port GCC documentation to Sphinx

On 6/29/21 4:09 AM, Martin Liška wrote: On 6/28/21 5:33 PM, Joseph Myers wrote: Are formatted manuals (HTML, PDF, man, info) corresponding to this patch version also available for review? I've just uploaded them here: https://splichal.eu/gccsphinx-final/ Martin I think listing the -Wfoo an

Re: where is PRnnnn required again?

On 7/8/21 2:26 AM, Jonathan Wakely wrote: On Wed, 7 Jul 2021, 23:58 Martin Sebor, <mailto:mse...@gmail.com>> wrote: On 7/7/21 4:24 PM, Jonathan Wakely wrote: > > > On Wed, 7 Jul 2021, 23:18 Martin Sebor, mailto:mse...@gmail.com> > <mailto:m

Re: where is PRnnnn required again?

On 7/7/21 4:15 PM, Jonathan Wakely wrote: On Wed, 7 Jul 2021, 22:35 Martin Sebor, <mailto:mse...@gmail.com>> wrote: On 7/7/21 2:42 PM, Jonathan Wakely wrote: > > > On Wed, 7 Jul 2021, 17:39 Martin Sebor, mailto:mse...@gmail.com> > <mailto:m

Re: where is PRnnnn required again?

On 7/7/21 4:24 PM, Jonathan Wakely wrote: On Wed, 7 Jul 2021, 23:18 Martin Sebor, <mailto:mse...@gmail.com>> wrote: On 7/7/21 3:53 PM, Marek Polacek wrote: > I'm not sure why you keep hitting so many issues; git addlog takes care of > this stuff fo

Re: where is PRnnnn required again?

On 7/7/21 3:53 PM, Marek Polacek wrote: On Wed, Jul 07, 2021 at 03:35:35PM -0600, Martin Sebor wrote: On 7/7/21 2:42 PM, Jonathan Wakely wrote: On Wed, 7 Jul 2021, 17:39 Martin Sebor, mailto:mse...@gmail.com>> wrote: On 7/6/21 4:09 PM, Jonathan Wakely wrote: > >

Re: where is PRnnnn required again?

On 7/7/21 2:42 PM, Jonathan Wakely wrote: On Wed, 7 Jul 2021, 17:39 Martin Sebor, <mailto:mse...@gmail.com>> wrote: On 7/6/21 4:09 PM, Jonathan Wakely wrote: > > > On Tue, 6 Jul 2021, 22:45 Martin Sebor via Gcc, mailto:gcc@gcc.gnu.org> >

Re: where is PRnnnn required again?

On 7/7/21 11:51 AM, Jakub Jelinek wrote: On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via Gcc wrote: I came away from the recent discussion of ChangeLogs requirements with the impression that the PR bit should be in the subject (first) line and also above the ChangeLog part but

Re: where is PRnnnn required again?

On 7/6/21 4:09 PM, Jonathan Wakely wrote: On Tue, 6 Jul 2021, 22:45 Martin Sebor via Gcc, <mailto:gcc@gcc.gnu.org>> wrote: On 7/6/21 3:36 PM, Marek Polacek wrote: > On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via Gcc wrote: >> I came away from the

Re: where is PRnnnn required again?

On 7/6/21 3:36 PM, Marek Polacek wrote: On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via Gcc wrote: I came away from the recent discussion of ChangeLogs requirements with the impression that the PR bit should be in the subject (first) line and also above the ChangeLog part but

where is PRnnnn required again?

thing changed recently? Martin commit 8a6d08bb49c2b9585c2a2adbb3121f6d9347b780 (HEAD -> master) Author: Martin Sebor Date: Fri Jul 2 16:16:31 2021 -0600 Improve warning suppression for inlined functions [PR98512]. Resolves: PR middle-end/98871 - Cannot silence -Wmaybe-uninitia

ubsan built-in function types

Most sanitizer built-in argument types are all of pointer types. For example: BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS as BT_FN_VOID_PTR_PTR_PTR or BUILT_IN_UBSAN_HANDLE_VLA_BOUND_NOT_POSITIVE as BT_FN_VOID_PTR_PTR. But some calls to these functions are made with some arguments of int

Re: Using source-level annotations to help GCC detect buffer overflows

On 6/29/21 12:31 PM, David Brown wrote: On 29/06/2021 17:50, Martin Sebor wrote: On 6/29/21 6:27 AM, David Brown wrote: On 28/06/2021 21:06, Martin Sebor via Gcc wrote: I wrote an article for the Red Hat Developer blog about how to annotate code to get the most out of GCC's access che

Re: replacing the backwards threader and more

warning. I just pinged the core patch yesterday so once it and the rest of the series gets approved there will be no need for the Makefile workaround. Martin Thanks. Aldy On Tue, Jun 29, 2021, 00:29 Martin Sebor <mailto:mse...@gmail.com>> wrote: On 6/28/21 12:17 AM, Aldy Hernan

Re: Using source-level annotations to help GCC detect buffer overflows

On 6/29/21 6:27 AM, David Brown wrote: On 28/06/2021 21:06, Martin Sebor via Gcc wrote: I wrote an article for the Red Hat Developer blog about how to annotate code to get the most out of GCC's access checking warnings like -Warray-bounds, -Wformat-overflow, and -Wstringop-overflow.

Re: replacing the backwards threader and more

On 6/28/21 12:17 AM, Aldy Hernandez wrote: On 6/25/21 7:19 PM, Martin Sebor wrote: On 6/25/21 10:20 AM, Aldy Hernandez via Gcc wrote: Hi folks. I'm done with benchmarking, testing and cleanups, so I'd like to post my patchset for review.  However, before doing so, I'd lik

Using source-level annotations to help GCC detect buffer overflows

I wrote an article for the Red Hat Developer blog about how to annotate code to get the most out of GCC's access checking warnings like -Warray-bounds, -Wformat-overflow, and -Wstringop-overflow. The article published last week: https://developers.redhat.com/articles/2021/06/25/use-source-level-

Re: replacing the backwards threader and more

On 6/25/21 10:20 AM, Aldy Hernandez via Gcc wrote: Hi folks. I'm done with benchmarking, testing and cleanups, so I'd like to post my patchset for review.  However, before doing so, I'd like to address a handful of meta-issues that may affect how I post these patches. Trapping on differences

Re: [Patch] contrib/mklog.py: Improve PR handling

On 6/18/21 8:41 AM, Jason Merrill via Gcc wrote: On Fri, Jun 18, 2021 at 7:06 AM Tobias Burnus wrote: On 18.06.21 11:32, Richard Earnshaw via Gcc wrote: On 17/06/2021 18:21, Jakub Jelinek wrote: mklog as is doesn't fill in the details (descriptions of the changes to each function etc.), nor

Re: [Patch] contrib/mklog.py: Improve PR handling

them, then the lines added by -p would serve the same purpose, and we wouldn't need to repeat them So instead of requiring "^\tPR .*/\d+$" for the PR entry, require "^\t?PR ([^/]+)/\d+" I think we should require either ($|\s) after the PR number but otherwise, it works

Re: Build failure due to format-truncation

On 6/17/21 5:04 PM, José Rui Faustino de Sousa wrote: On 17/06/21 20:51, Martin Sebor wrote: What stage does this happens in, and if stage 1, what is the system compiler? > I am not sure if this happens also in the earlier stages, I would have to do a complete rebuild and that would t

Re: Build failure due to format-truncation

On 6/16/21 6:26 PM, José Rui Faustino de Sousa wrote: On 16/06/21 20:37, Martin Sebor wrote: I don't really think the warning is doing anything wrong I completely agree. I am not complaining about the warning, I am complaining that there is code in gcc which raises this warning and b

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/17/21 10:32 AM, Jonathan Wakely wrote: On Thu, 17 Jun 2021 at 16:33, Martin Sebor wrote: On 6/17/21 9:11 AM, Michael Matz wrote: Hello, On Thu, 17 Jun 2021, Martin Sebor via Gcc wrote: The original problem is that the PR wasn't _in the body_ of the commit But I see [PR100085]

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/17/21 9:11 AM, Michael Matz wrote: Hello, On Thu, 17 Jun 2021, Martin Sebor via Gcc wrote: The original problem is that the PR wasn't _in the body_ of the commit But I see [PR100085] right there at the end of the _summary line_: Emphasis mine. Let me make sure I understand: w

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/17/21 4:18 AM, Jonathan Wakely wrote: On Thu, 17 Jun 2021 at 02:01, Martin Sebor wrote: On 6/16/21 6:40 PM, Jason Merrill wrote: On 6/16/21 8:17 PM, Martin Sebor wrote: 3) adds the PR component/n to each ChangeLog This would be reverting the r12-771 change, which seems both

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/16/21 6:40 PM, Jason Merrill wrote: On 6/16/21 8:17 PM, Martin Sebor wrote: On 6/16/21 5:45 PM, Jason Merrill wrote: On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor <mailto:mse...@gmail.com>> wrote:     On 6/16/21 2:49 PM, Jason Merrill wrote: > On 6/15/21 11:42 PM, Jason M

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/16/21 5:45 PM, Jason Merrill wrote: On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor <mailto:mse...@gmail.com>> wrote: On 6/16/21 2:49 PM, Jason Merrill wrote: > On 6/15/21 11:42 PM, Jason Merrill wrote: >> On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/16/21 2:49 PM, Jason Merrill wrote: On 6/15/21 11:42 PM, Jason Merrill wrote: On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc <mailto:gcc@gcc.gnu.org>> wrote:     On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote: > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:

Re: Build failure due to format-truncation

On 6/16/21 11:21 AM, José Rui Faustino de Sousa wrote: On 16/06/21 16:53, Martin Sebor wrote: -fstrict-overflow isn't related to the warning or to sprintf (it controls whether signed integer overflow is considered undefined). The warning above tells you that if help points to a string t

Re: docs: Unification of "enabled by default at -O{,1}

On 6/11/21 6:53 AM, Martin Liška wrote: Hello. First, note that -O is equal to -O1 :) I noticed we don't use it consistently in documentation: $ git grep 'at.*-O1}' | cat gcc/ada/gnat_ugn.texi:pick it based on the optimization level: 1 for @code{-O1}, @code{-O2} or ... Is the later (and

Re: Build failure due to format-truncation

On 6/13/21 11:48 AM, José Rui Faustino de Sousa via Gcc wrote: Hi All! While building I started to get this error: ../../gcc-master/gcc/opts.c: In function ‘void print_filtered_help(unsigned int, unsigned int, unsigned int, unsigned int, gcc_options*, unsigned int)’: ../../gcc-master/gcc/opt

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/15/21 9:42 PM, Jason Merrill wrote: On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc <mailto:gcc@gcc.gnu.org>> wrote: On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote: > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote: > >> On 6/11/21 11:32 AM,

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote: On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote: On 6/11/21 11:32 AM, Jonathan Wakely wrote: On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote: My objection is to making our policies and tools more restrictive than they need to be. We shouldn&#

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/11/21 11:32 AM, Jonathan Wakely wrote: On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote: My objection is to making our policies and tools more restrictive than they need to be. We shouldn't expect everyone to study whole manuals just to figure out how to successfully commit a chang

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/11/21 3:13 AM, Jonathan Wakely wrote: On Thu, 10 Jun 2021 at 22:16, Martin Sebor wrote: I don't see why the script users should be subjected to this tedium when it can be done in the script itself with (presumably) only a little more effort. The proposed change is, IMO, a step i

Re: GCC documentation: porting to Sphinx

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

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/10/21 3:28 PM, Jakub Jelinek wrote: On Thu, Jun 10, 2021 at 03:16:43PM -0600, Martin Sebor wrote: Just look at the start of this thread. Some people put the [PRn] only in the first line of the commit. And that is what these changes want to diagnose, that is an error and results in

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/10/21 1:09 PM, Jakub Jelinek wrote: On Thu, Jun 10, 2021 at 12:55:43PM -0600, Martin Sebor wrote: Instead of rejecting commits that don't mention all the same PRs on the first line of the commit as in the ChangeLog entries it seems that the Git commit script could extract the P

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/10/21 11:30 AM, Jakub Jelinek wrote: On Thu, Jun 10, 2021 at 11:20:26AM -0600, Martin Sebor wrote: One other note: you mention policy above, which suggests a requirement. My understanding is that the format of a commit message is a convention put in place to take some of the tedium out of

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/10/21 11:06 AM, Martin Sebor wrote: On 6/10/21 9:56 AM, Jonathan Wakely wrote: On Thu, 10 Jun 2021 at 15:56, Martin Sebor wrote: On 6/10/21 4:40 AM, Jonathan Wakely via Gcc wrote: On Thu, 10 Jun 2021 at 11:08, Jakub Jelinek wrote: On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/10/21 9:56 AM, Jonathan Wakely wrote: On Thu, 10 Jun 2021 at 15:56, Martin Sebor wrote: On 6/10/21 4:40 AM, Jonathan Wakely via Gcc wrote: On Thu, 10 Jun 2021 at 11:08, Jakub Jelinek wrote: On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wakely via Gcc wrote: On 10/06/21 10:44

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/10/21 4:40 AM, Jonathan Wakely via Gcc wrote: On Thu, 10 Jun 2021 at 11:08, Jakub Jelinek wrote: On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wakely via Gcc wrote: On 10/06/21 10:44 +0100, Jonathan Wakely wrote: Quite interesting idea! Are you willing to prepare a patch for it?

Re: GCC documentation: porting to Sphinx

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/

Re: GCC documentation: porting to Sphinx

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

Re: safety command-line options

On 5/24/21 2:18 AM, Uecker, Martin wrote: I wonder if we could get a nice short command-line option for recommended safety/security related flags. We have -Ox for optimization and -Wall for a useful set of recommended warnings. I am thinking about options such as -ftrapv -fsanitize=undefined

Detecting memory management bugs with GCC 11

Back in February I wrote an article about GCC 11 features designed to help detect common dynamic memory management bugs. The article just published in two parts in the Red Hat Developer Blog: https://developers.redhat.com/blog/2021/04/30/detecting-memory-management-bugs-with-gcc-11-part-1-unders

Re: -flto and -Werror

On 5/4/21 6:39 AM, Matthias Klose wrote: Using -flto exposes some new warnings in code, as seen in the both build logs below, for upstream elfutils and systemd. I have seen others. These upstreams enable -Werror by default, but probably don't see these warnings turning to errors themself, becau

Re: RFC: attributes for marking security boundaries (system calls/ioctls, user vs kernel pointers etc)

On 4/29/21 11:18 AM, David Malcolm wrote: I've been going through old Linux kernel CVEs, trying to prototype some possible new warnings for -fanalyzer in GCC 12 (and, alas, finding places where the analyzer internals need work...) I think I want a way for the user to be able to mark security bou

Re: TREE_NO_WARNING and internal variables

On 4/29/21 11:32 AM, Jakub Jelinek wrote: On Thu, Apr 29, 2021 at 11:22:15AM -0600, Martin Sebor via Gcc wrote: The C front end (and perhaps others as well) creates internal variables in a few places, such as in convert_lvalue_to_rvalue like so: /* Remove the qualifiers for the rest of

TREE_NO_WARNING and internal variables

The C front end (and perhaps others as well) creates internal variables in a few places, such as in convert_lvalue_to_rvalue like so: /* Remove the qualifiers for the rest of the expressions and create the VAL temp variable to hold the RHS. */ nonatomic_type = build_qualifie

Re: help debug hash_map garbage collection issue

On 4/20/21 8:26 PM, Jason Merrill wrote: On Tue, Apr 20, 2021 at 8:31 PM Martin Sebor via Gcc wrote: On 4/20/21 5:03 PM, Martin Sebor wrote: On 4/20/21 4:15 PM, Martin Sebor wrote: On 4/20/21 2:36 PM, Martin Sebor wrote: On 4/20/21 2:13 PM, Marek Polacek wrote: On Tue, Apr 20, 2021 at 02

Re: help debug hash_map garbage collection issue

On 4/20/21 5:03 PM, Martin Sebor wrote: On 4/20/21 4:15 PM, Martin Sebor wrote: On 4/20/21 2:36 PM, Martin Sebor wrote: On 4/20/21 2:13 PM, Marek Polacek wrote: On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote: I have a static hash_map object that needs to persist across

Re: help debug hash_map garbage collection issue

On 4/20/21 4:15 PM, Martin Sebor wrote: On 4/20/21 2:36 PM, Martin Sebor wrote: On 4/20/21 2:13 PM, Marek Polacek wrote: On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote: I have a static hash_map object that needs to persist across passes:    static GTY(()) hash_map *map

Re: help debug hash_map garbage collection issue

On 4/20/21 2:36 PM, Martin Sebor wrote: On 4/20/21 2:13 PM, Marek Polacek wrote: On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote: I have a static hash_map object that needs to persist across passes:    static GTY(()) hash_map *map; I initialize the map like so:    map

Re: help debug hash_map garbage collection issue

On 4/20/21 2:13 PM, Marek Polacek wrote: On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote: I have a static hash_map object that needs to persist across passes: static GTY(()) hash_map *map; I initialize the map like so: map = hash_map::create_ggc (4); But I see

help debug hash_map garbage collection issue

I have a static hash_map object that needs to persist across passes: static GTY(()) hash_map *map; I initialize the map like so: map = hash_map::create_ggc (4); But I see crashes when accessing the map after adding and removing some number of entries in a few passes. The crashes are due t

Re: side-effect-free function

On 3/9/21 8:05 AM, Rasmus Villemoes via Gcc wrote: Hi, Consider some function now() which returns some kind of "current timestamp" as a simple scalar. It could be a wrapper for clock_gettime(CLOCK_MONOTONIC) which converts the timespec value to nanoseconds, or in the linux kernel one of the ktim

Re: using undeclared function returning bool results in wrong return value

On 2/20/21 8:46 AM, David Malcolm via Gcc wrote: On Sat, 2021-02-20 at 15:25 +0100, David Brown wrote: On 19/02/2021 12:18, Jonathan Wakely via Gcc wrote: On Fri, 19 Feb 2021 at 09:42, David Brown wrote: Just to be clear - I am not in any way suggesting that this situation is the fault of any

Re: using undeclared function returning bool results in wrong return value

On 2/17/21 2:05 PM, Thanos Makatos via Gcc wrote: I run into a problem that I'm not sure whether it's a bug in my program (most likely) or something wrong with GCC (highly unlikely, I know, hence why I haven't sent this to gcc-bugs). The problem is using a function that returns a bool, defined

Re: Static analysis updates in GCC 11

On 1/28/21 2:27 PM, David Malcolm via Gcc wrote: On Thu, 2021-01-28 at 22:06 +0100, David Brown wrote: On 28/01/2021 21:23, David Malcolm via Gcc wrote: I wrote a blog post covering what I've been working on in the analyzer in this release:   https://developers.redhat.com/blog/2021/01/28/stati

Re: Fw: Problems with compiling autogen with GCC8 or newer versions

On 1/10/21 12:28 PM, Bruce Korb wrote: Hi Martin, On 1/10/21 11:01 AM, Martin Sebor wrote: On 1/8/21 12:38 PM, Bruce Korb via Gcc wrote: This is the code that must be confusing to GCC. "def_str" points to the second character in the 520 byte buffer. "def_scan" points to

Re: Fw: Problems with compiling autogen with GCC8 or newer versions

On 1/8/21 12:38 PM, Bruce Korb via Gcc wrote:    $ bash cc.sh    + wrn+=' -Werror=format-overflow'    + gcc -DHAVE_CONFIG_H -I. -I.. -I../autoopts    -Wno-format-contains-nul -Wall -Werror -Wcast-align    -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes    -Wwrite-strings -

Re: [RFC] restricting aliasing by standard containers (PR 98465)

On 1/8/21 12:51 AM, Richard Biener wrote: On Thu, Jan 7, 2021 at 10:41 PM Martin Sebor wrote: The test case in PR 98465 brings to light a problem we've discussed before (e.g., PR 93971) where a standard container (std::string in this case but the problem applies to any class that own

[RFC] restricting aliasing by standard containers (PR 98465)

The test case in PR 98465 brings to light a problem we've discussed before (e.g., PR 93971) where a standard container (std::string in this case but the problem applies to any class that owns and manages allocated memory) might trigger warnings for unreachable code. The code is not eliminated due

  1   2   3   4   >