commits in Bugzilla attributed to others?

2020-03-13 Thread Martin Sebor via Gcc
It looks as though commits with bug fixes appear in Bugzilla comments made by others(*). Fox instance, commit r10-7151 for PR 92071 shows in comment #16 on the bug under Martin Liška's name. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071#c16 Similarly, commits r9-8372, r10-7152, and r8-10

Re: commits in Bugzilla attributed to others?

2020-03-13 Thread Martin Sebor via Gcc
On 3/13/20 9:50 AM, Marek Polacek wrote: On Fri, Mar 13, 2020 at 09:46:40AM -0600, Martin Sebor via Gcc wrote: It looks as though commits with bug fixes appear in Bugzilla comments made by others(*). Fox instance, commit r10-7151 for PR 92071 shows in comment #16 on the bug under Martin

access to Subversion links forbidden?

2020-03-18 Thread Martin Sebor via Gcc
I've been getting Error 403 (Forbidden - You don't have permission to access /viewcvs on this server) following the Subversion links in Bugzilla for some time now (they worked for me before the switch to Git, but I'm not sure if they also did before the recent hardware upgrade). For example:

Re: New mklog script

2020-05-15 Thread Martin Sebor via Gcc
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 c

C++ 11 errors building go on 10-branch?

2020-05-18 Thread Martin Sebor via Gcc
The Go front end fails to build for me on 10-branch with the error below (and many others that look like they're cause by it). Git log doesn't show any recent changes that might be responsible for it. It looks like the code is guarded by the conditional #if defined(HAVE_UNORDERED_MAP) and HAVE_U

ERR: file not changed in a patch:"gcc/cp/cp-tree.c"

2020-05-19 Thread Martin Sebor via Gcc
I'm having trouble with the commit hook that tries to enforce ChangeLog contents. It fails with an error that doesn't make sense to me: the file it complains isn't mentioned clearly is listed there and I can't tell what about how it's mentioned the hook is having a problem with. Thanks Martin $

Re: ERR: file not changed in a patch:"gcc/cp/cp-tree.c"

2020-05-19 Thread Martin Sebor via Gcc
On 5/19/20 1:03 PM, Martin Sebor wrote: I'm having trouble with the commit hook that tries to enforce ChangeLog contents.  It fails with an error that doesn't make sense to me: the file it complains isn't mentioned clearly is listed there and I can't tell what about how it's mentioned the hook is

Re: ERR: file not changed in a patch:"gcc/cp/cp-tree.c"

2020-05-19 Thread Martin Sebor via Gcc
On 5/19/20 1:11 PM, Marek Polacek wrote: On Tue, May 19, 2020 at 01:03:09PM -0600, Martin Sebor via Gcc wrote: I'm having trouble with the commit hook that tries to enforce ChangeLog contents. It fails with an error that doesn't make sense to me: the file it complains isn't me

Re: ERR: file not changed in a patch:"gcc/cp/cp-tree.c"

2020-05-19 Thread Martin Sebor via Gcc
On 5/19/20 1:26 PM, Martin Liška wrote: On 5/19/20 9:19 PM, Martin Sebor via Gcc wrote: Yep, that was it.  It's one of those things that you can stare at for minutes before you notice it. Thank you for the report, it's 1:0 for the hook ;) Next time, please CC me to a similar issu

Re: New mklog script

2020-05-22 Thread Martin Sebor via Gcc
On 5/21/20 2:16 AM, Martin Liška wrote: Hello Martin. Can you please compare the current mklog.py. Is there anything you miss compared to your current script? Nope, it matches the format I get with my script and even works better and runs faster. Very nice! I'll be happy to switch to using i

Re: New mklog script

2020-05-26 Thread Martin Sebor via Gcc
On 5/26/20 7:14 AM, Martin Liška wrote: On 5/26/20 3:11 PM, Richard Earnshaw wrote: On 26/05/2020 14:09, Martin Liška wrote: On 5/26/20 1:18 PM, Richard Earnshaw wrote: On 26/05/2020 12:14, Martin Liška wrote: On 5/26/20 12:23 PM, Richard Earnshaw wrote: I thought we had a convention that ali

sign_and_send_pubkey: signing failed: agent refused operation

2020-06-01 Thread Martin Sebor via Gcc
git pull from the GCC and Glibc repos is failing for me with the error below. It worked fine last week and I haven't made any changes to my ssh keys. Is this a transient glitch or has something changed recently that I need to make some adjustments for? sign_and_send_pubkey: signing failed: agen

Re: sign_and_send_pubkey: signing failed: agent refused operation

2020-06-01 Thread Martin Sebor via Gcc
On 6/1/20 12:10 PM, Frank Ch. Eigler wrote: Hi - git pull from the GCC and Glibc repos is failing for me with the error below. It worked fine last week and I haven't made any changes to my ssh keys. And are you logging in from the same workstation with access to the same set of ssh private k

Re: sign_and_send_pubkey: signing failed: agent refused operation

2020-06-01 Thread Martin Sebor via Gcc
On 6/1/20 1:25 PM, Jonathan Wakely wrote: On Mon, 1 Jun 2020 at 20:16, Martin Sebor via Gcc wrote: On 6/1/20 12:10 PM, Frank Ch. Eigler wrote: Hi - git pull from the GCC and Glibc repos is failing for me with the error below. It worked fine last week and I haven't made any changes

Re: sign_and_send_pubkey: signing failed: agent refused operation

2020-06-01 Thread Martin Sebor via Gcc
On 6/1/20 1:53 PM, Frank Ch. Eigler wrote: Hi - ~/.ssh/known_hosts exists and ~/.ssh is rwx only by the owner. Everything works fine if I add my key by running ssh-add. What's not so great is the errors I get when I forget to do that: "agent refused operation?" Yeah, there is something odd o

Re: sign_and_send_pubkey: signing failed: agent refused operation

2020-06-02 Thread Martin Sebor via Gcc
On 6/1/20 1:12 PM, Jonathan Wakely via Overseers wrote: On Mon, 1 Jun 2020 at 19:11, Frank Ch. Eigler via Gcc wrote: Hi - git pull from the GCC and Glibc repos is failing for me with the error below. It worked fine last week and I haven't made any changes to my ssh keys. And are you loggi

Re: sign_and_send_pubkey: signing failed: agent refused operation

2020-06-02 Thread Martin Sebor via Gcc
On 6/2/20 2:43 PM, Jonathan Wakely wrote: On Tue, 2 Jun 2020 at 21:26, Martin Sebor wrote: On 6/1/20 1:12 PM, Jonathan Wakely via Overseers wrote: On Mon, 1 Jun 2020 at 19:11, Frank Ch. Eigler via Gcc wrote: Hi - git pull from the GCC and Glibc repos is failing for me with the error belo

ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates

2020-07-13 Thread Martin Sebor via Gcc
Could someone explain what the following error means and how to avoid it? It's for a commit to the 10 branch with the usual commit message format and changes to only .c/.C files (same as in r11-1899). There's nothing more about the subject of the ERR at the link it points to than what it says.

Re: ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates

2020-07-13 Thread Martin Sebor via Gcc
On 7/13/20 8:21 AM, Martin Sebor wrote: Could someone explain what the following error means and how to avoid it?  It's for a commit to the 10 branch with the usual commit message format and changes to only .c/.C files (same as in r11-1899).  There's nothing more about the subject of the ERR at t

Re: GCC 10.2: Spurious(?) stringop-overflow warning (not strlen/strcpy/etc.)

2020-08-03 Thread Martin Sebor via Gcc
On 8/3/20 2:18 PM, Paul Smith wrote: I'm testing upgrading from GCC 9.3 to 10.2 and I'm seeing this new warning: $ g++ --version x86_64-unknown-linux-gnu-g++ (GCC) 10.2.0 ... $ g++ -Wall -Werror -O2 -c -o stringop.o stringop.cpp In member function 'void LeafNode::markUpdate(

Re: GCC 10.2: Spurious(?) stringop-overflow warning (not strlen/strcpy/etc.)

2020-08-06 Thread Martin Sebor via Gcc
On 8/3/20 10:58 PM, Paul Smith wrote: On Mon, 2020-08-03 at 17:02 -0600, Martin Sebor wrote: If the code is designed to treat Node sort of like a struct with a flexible array member I would suggest to make that explicit by adding a zero-element array member to Node and using it to access other m

Re: GCC 10.2: Spurious(?) stringop-overflow warning (not strlen/strcpy/etc.)

2020-08-06 Thread Martin Sebor via Gcc
On 8/6/20 2:14 PM, Martin Sebor wrote: On 8/3/20 10:58 PM, Paul Smith wrote: On Mon, 2020-08-03 at 17:02 -0600, Martin Sebor wrote: If the code is designed to treat Node sort of like a struct with a flexible array member I would suggest to make that explicit by adding a zero-element array membe

how to debug Ada front end

2020-08-14 Thread Martin Sebor via Gcc
Could someone either point me to directions or explain how to start the Ada front end in GDB? I've searched the GCC Wiki but couldn't find anything useful and no matter what I do I get errors, either: fatal error, run-time library not installed correctly cannot locate file system.ads compilation

Re: how to debug Ada front end

2020-08-14 Thread Martin Sebor via Gcc
I've got it. Just removing all the gnatmake cruft and options the GCC driver doesn't understand and invoking GCC as usual works. Phew. It would be useful to update the GNAT Wiki with this. I'll probably get most of it wrong but let me give it a try. On 8/14/20 3:53 PM, Martin Sebor wrote: Co

Re: about souce code location

2020-09-06 Thread Martin Sebor via Gcc
On 9/4/20 6:26 AM, 易会战 via Gcc wrote: how to check the location corresponding to a gimple statement? My instrument stmt include some memory access, I wish get right source code line. By context it is possible get wrong line. The gimple_location() function returns the location of the GIMPLE st

Re: irange best practices document

2020-09-09 Thread Martin Sebor via Gcc
On 9/3/20 1:14 AM, Aldy Hernandez via Gcc wrote: Below is a documented we have drafted to provide guidance on using irange's and converting passes to it.  This will future proof any such passes so that they will work with the ranger, or any other mechanism using multiple sub-ranges (as opposed

duplicate arm test results?

2020-09-22 Thread Martin Sebor via Gcc
Hi Christophe, While checking recent test results I noticed many posts with results for various flavors of arm that at high level seem like duplicates of one another. For example, the batch below all have the same title, but not all of the contents are the same. The details (such as test failur

Re: duplicate arm test results?

2020-09-22 Thread Martin Sebor via Gcc
On 9/22/20 9:15 AM, Christophe Lyon wrote: On Tue, 22 Sep 2020 at 17:02, Martin Sebor wrote: Hi Christophe, While checking recent test results I noticed many posts with results for various flavors of arm that at high level seem like duplicates of one another. For example, the batch below all

Re: duplicate arm test results?

2020-09-23 Thread Martin Sebor via Gcc
On 9/23/20 2:54 AM, Christophe Lyon wrote: On Wed, 23 Sep 2020 at 01:47, Martin Sebor wrote: On 9/22/20 9:15 AM, Christophe Lyon wrote: On Tue, 22 Sep 2020 at 17:02, Martin Sebor wrote: Hi Christophe, While checking recent test results I noticed many posts with results for various flavors

Re: VLA warning on recent git

2020-10-23 Thread Martin Sebor via Gcc
On 10/23/20 7:41 AM, Uecker, Martin wrote: I tested a recent GCC from git and noticed a couple of new warnings for VLA parameters. (Martin, I assume this is your work. First, let me say: thank you! I think this is really important.) Here is some feedback from running this on an existing code

Re: broken check: You should edit tm.texi.in rather than tm.texi

2020-11-23 Thread Martin Sebor via Gcc
On 11/20/20 6:23 AM, Martin Liška wrote: Hello. I hit the following issue: /bin/sh /home/marxin/Programming/gcc/gcc/../move-if-change tmp-tm.texi tm.texi You should edit /home/marxin/Programming/gcc/gcc/doc/tm.texi.in rather than /home/marxin/Programming/gcc/gcc/doc/tm.texi . Steps to reprod

Re: broken check: You should edit tm.texi.in rather than tm.texi

2020-11-23 Thread Martin Sebor via Gcc
On 11/23/20 12:45 PM, Joseph Myers wrote: On Mon, 23 Nov 2020, Martin Sebor via Gcc wrote: I never did understand what it was complaining about, or the point of making us jump through these hoops for updates to the internals manual when the (arguably far more impactful) changes to GCC source

Re: broken check: You should edit tm.texi.in rather than tm.texi

2020-11-23 Thread Martin Sebor via Gcc
On 11/23/20 1:25 PM, Joseph Myers wrote: On Mon, 23 Nov 2020, Martin Sebor via Gcc wrote: I'd expect the best way to ensure the two copies of the contributed text are in sync is to copy it automatically. If the only point of asking the author to do it by hand each time they change the fi

Re: PETITION TO REMOVE -fexec-charset in GCC. That is purely garbage and undefined behavior.

2020-11-25 Thread Martin Sebor via Gcc
On 11/25/20 8:15 AM, Zack Weinberg wrote: printf(“Hello World\n”); is UB under -fexec-charset= EBCDIC. WTF WTF!!! It's not undefined behavior. It does, however, appear to trip various bugs in GCC. $ cat test.c #include int main(void) { printf("hello world\n"); } $ gcc-9 --version | head -n1

how to get the library DECL for a built-in function

2020-12-04 Thread Martin Sebor via Gcc
I'm looking for a way to get the FUNCTION_DECL for the library (i.e., non-built-in) form of a function given the corresponding built-in DECL. Is there an API I can all with either the built -in DECL or its code to get it in the middle end? In C, what I'm looking for appears to be DECL_CHAIN(decl

Re: how to get the library DECL for a built-in function

2020-12-04 Thread Martin Sebor via Gcc
On 12/4/20 4:33 PM, Martin Sebor wrote: I'm looking for a way to get the FUNCTION_DECL for the library (i.e., non-built-in) form of a function given the corresponding built-in DECL.  Is there an API I can all with either the built -in DECL or its code to get it in the middle end? In C, what I'm

Re: cacheflush.2

2020-12-14 Thread Martin Sebor via Gcc
On 12/11/20 11:14 AM, Alejandro Colomar (man-pages) via Gcc wrote: It looks like GCC recently moved from 'char *' to 'void *'. This SO question[1] (4 years ago) quotes the GCC docs and they had 'char *'. __builtin___clear_cache in GCC has always been declared to take void*. The signature in th

Re: Ping: cacheflush.2

2020-12-18 Thread Martin Sebor via Gcc
On 12/18/20 3:42 AM, Alejandro Colomar (man-pages) wrote: Hi Martin, I sent you an email, but I received a "delivery failure". If you're reading this from a list, could you answer, please? Thanks, Alex On 12/14/20 11:34 PM, Alejandro Colomar (man-pages) wrote: Hello Martin, Thanks for the c

Re: More consistency for Git log messages?

2020-12-30 Thread Martin Sebor via Gcc
On 12/29/20 1:49 AM, Jonathan Wakely via Gcc wrote: On Mon, 28 Dec 2020, 23:55 Gerald Pfeifer, wrote: Having spent a bit more time with GCC sources (as opposed to wwwdocs) recently and looking for prior art to guide me, I noticed there's a lot of options to specific the ChangeLog file(s) to us

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

2021-01-07 Thread Martin Sebor via Gcc
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

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

2021-01-08 Thread Martin Sebor via Gcc
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 owns and mana

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

2021-01-10 Thread Martin Sebor via Gcc
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: Fw: Problems with compiling autogen with GCC8 or newer versions

2021-01-10 Thread Martin Sebor via Gcc
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 a character that we al

Re: Static analysis updates in GCC 11

2021-01-28 Thread Martin Sebor via Gcc
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: using undeclared function returning bool results in wrong return value

2021-02-17 Thread Martin Sebor via Gcc
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: using undeclared function returning bool results in wrong return value

2021-02-22 Thread Martin Sebor via Gcc
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: side-effect-free function

2021-03-09 Thread Martin Sebor via Gcc
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

help debug hash_map garbage collection issue

2021-04-20 Thread Martin Sebor via Gcc
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: help debug hash_map garbage collection issue

2021-04-20 Thread Martin Sebor via Gcc
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

Re: help debug hash_map garbage collection issue

2021-04-20 Thread Martin Sebor via Gcc
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

2021-04-20 Thread Martin Sebor via Gcc
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

2021-04-20 Thread Martin Sebor via Gcc
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

2021-04-21 Thread Martin Sebor via Gcc
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

TREE_NO_WARNING and internal variables

2021-04-29 Thread Martin Sebor via Gcc
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: TREE_NO_WARNING and internal variables

2021-04-29 Thread Martin Sebor via Gcc
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

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

2021-04-29 Thread Martin Sebor via Gcc
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: -flto and -Werror

2021-05-04 Thread Martin Sebor via Gcc
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

Detecting memory management bugs with GCC 11

2021-05-06 Thread Martin Sebor via Gcc
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: safety command-line options

2021-05-24 Thread Martin Sebor via Gcc
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

Re: GCC documentation: porting to Sphinx

2021-06-02 Thread Martin Sebor via Gcc
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: GCC documentation: porting to Sphinx

2021-06-04 Thread Martin Sebor via Gcc
On 6/3/21 4:56 AM, Martin Liška wrote: On 6/2/21 10:41 PM, Martin Sebor wrote: On 5/31/21 7:25 AM, Martin Liška wrote: Hello. I've made quite some progress with the porting of the documentation and I would like to present it to the community now: https://splichal.eu/scripts/sphinx/ Hello.

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

2021-06-10 Thread Martin Sebor via Gcc
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: git gcc-commit-mklog doesn't extract PR number to ChangeLog

2021-06-10 Thread Martin Sebor via Gcc
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 +010

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

2021-06-10 Thread Martin Sebor via Gcc
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 Wak

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

2021-06-10 Thread Martin Sebor via Gcc
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 c

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

2021-06-10 Thread Martin Sebor via Gcc
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 PR referen

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

2021-06-10 Thread Martin Sebor via Gcc
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 bug

Re: GCC documentation: porting to Sphinx

2021-06-10 Thread Martin Sebor via Gcc
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

2021-06-11 Thread Martin Sebor via Gcc
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 in the wrong

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

2021-06-11 Thread Martin Sebor via Gcc
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 change (or le

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

2021-06-15 Thread Martin Sebor via Gcc
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

2021-06-16 Thread Martin Sebor via Gcc
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: Build failure due to format-truncation

2021-06-16 Thread Martin Sebor via Gcc
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: docs: Unification of "enabled by default at -O{,1}

2021-06-16 Thread Martin Sebor via Gcc
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

2021-06-16 Thread Martin Sebor via Gcc
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 that's 25

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

2021-06-16 Thread Martin Sebor via Gcc
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: git gcc-commit-mklog doesn't extract PR number to ChangeLog

2021-06-16 Thread Martin Sebor via Gcc
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

2021-06-16 Thread Martin Sebor via Gcc
errill wrote: >> On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc     mailto:gcc@gcc.gnu.org> >> <mailto:gcc@gcc.gnu.org <mailto:gcc@gcc.gnu.org>>> wrote: >> >>     On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:      >

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

2021-06-17 Thread Martin Sebor via Gcc
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 unrelat

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

2021-06-17 Thread Martin Sebor via Gcc
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

2021-06-17 Thread Martin Sebor via Gcc
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: Build failure due to format-truncation

2021-06-17 Thread Martin Sebor via Gcc
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 breaks t

Re: Build failure due to format-truncation

2021-06-17 Thread Martin Sebor via Gcc
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 take so

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

2021-06-18 Thread Martin Sebor via Gcc
On 6/18/21 5:25 AM, Tobias Burnus wrote: On 18.06.21 13:10, Jonathan Wakely wrote: On Fri, 18 Jun 2021 at 12:05, Tobias Burnus wrote: PR c++/12394 - internal compiler error: in write_type, at cp/mangle.c:1517 PR fortran/100123 - -ftree-fre gives incorrect result in subroutine with array decla

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

2021-06-18 Thread Martin Sebor via Gcc
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: replacing the backwards threader and more

2021-06-25 Thread Martin Sebor via Gcc
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

Using source-level annotations to help GCC detect buffer overflows

2021-06-28 Thread Martin Sebor via Gcc
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

2021-06-28 Thread Martin Sebor via Gcc
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 like to address a han

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

2021-06-29 Thread Martin Sebor via Gcc
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

2021-06-29 Thread Martin Sebor via Gcc
On 6/28/21 6:32 PM, Aldy Hernandez wrote: I had changed my approach to passing -Wno-free-nonheap-object in the Makefile. Can you try disabling the Makefile bit and bootstrapping, cause that was still failing. I see. I just tested it and my patch does let the existing #pragma suppress the warn

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

2021-06-30 Thread Martin Sebor via Gcc
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

ubsan built-in function types

2021-07-02 Thread Martin Sebor via Gcc
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

where is PRnnnn required again?

2021-07-06 Thread Martin Sebor via Gcc
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 doesn't need to be repeated again in the ChangeLog entries. But my commit below was rejected last Friday with the s

Re: where is PRnnnn required again?

2021-07-06 Thread Martin Sebor via Gcc
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

Re: where is PRnnnn required again?

2021-07-07 Thread Martin Sebor via Gcc
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?

2021-07-07 Thread Martin Sebor via Gcc
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?

2021-07-07 Thread Martin Sebor via Gcc
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?

2021-07-07 Thread Martin Sebor via Gcc
; > On Tue, 6 Jul 2021, 22:45 Martin Sebor via Gcc, mailto:gcc@gcc.gnu.org> > <mailto:gcc@gcc.gnu.org <mailto:gcc@gcc.gnu.org>>> wrote: > >     On 7/6/21 3:36 PM, Marek Polacek wrote: >      > On Tue, Jul 06, 2021 at 0

Re: where is PRnnnn required again?

2021-07-07 Thread Martin Sebor via Gcc
On 7/7/21 4:24 PM, Jonathan Wakely wrote: On Wed, 7 Jul 2021, 23:18 Martin Sebor, > 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 for me and I've had no troubl

Re: where is PRnnnn required again?

2021-07-07 Thread Martin Sebor via Gcc
se...@gmail.com <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> >     <mailto:gcc@gcc

  1   2   >