[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #8, bug #65537 (group make): OK, I've installed that patch into Gnulib and I assume GNU Make will pick it up in due course. ___ Reply to this item at:

Re: [bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

On Fri, Mar 29, 2024 at 2:15 PM Martin Dorey wrote: > > URL: > > > Summary: Werrors from intprops-internal.h with gcc 8.3.0 >Group: make >Submitter: mdorey >Submitted: Fri 29 Mar 2024

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #7, bug #65537 (group make): [comment #6 comment #6:] That change on top of t'other Paul's from [comment #3 #3] and without my maintMakefile change from [comment #1 #1] is sufficient to stop the remaining warning, thanks. [comment #5 comment #5:] > GCC 4.2 and earlier doesn't

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #6, bug #65537 (group make): [comment #4 comment #4:] > In file included from lib/intprops.h:21, > from src/arscan.c:379: > src/arscan.c: In function ‘parse_int’: > lib/intprops-internal.h:387:35: error: comparison of integer expressions of different signedness:

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #5, bug #65537 (group make): [comment #0 original submission:] > I don't understand the macro guard there. Why would Paul Eggert want to avoid using the pragma in the half-open region between gcc 4.4 and gcc 5, while using it for the half-open region from gcc 4.0 to gcc 4.4?

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #4, bug #65537 (group make): I made that change, then, not knowing how to activate it, just tried running bootstrap again. That failed the same way I saw, but didn't report, earlier today, somehow clobbering the gnulib that had been cloned before, causing a second run of

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #3, bug #65537 (group make): I see there's a new stable branch: either these are not getting announced or I missed it. Can you try applying this patch and switching to this stable branch and see if it is fixed: diff --git a/bootstrap.conf b/bootstrap.conf index

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #2, bug #65537 (group make): > Are you using the latest HEAD of the stable-202307 branch of gnulib? I'm using whatever Gnu Make cloned for me. > It should be SHA 2f47ff2e115712 I do indeed see that substring in: martind@stormy:~/download/make-2024-03-29/gnulib$ git log -n 1

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #1, bug #65537 (group make): This is an issue with gnulib, not GNU Make, where that macro is defined. Are you using the latest HEAD of the stable-202307 branch of gnulib? It should be SHA 2f47ff2e115712 If so then we need to discuss on the gnulib mailing list.

[bug #65536] make.texi:5449: node `Using Variables' lacks menu item for `Conditionalizing' despite being its Up target

Follow-up Comment #2, bug #65536 (group make): I'm seemingly using: martind@stormy:~/download/make-2024-03-29$ makeinfo --version texi2any (GNU texinfo) 6.5 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

URL: Summary: Werrors from intprops-internal.h with gcc 8.3.0 Group: make Submitter: mdorey Submitted: Fri 29 Mar 2024 11:14:56 AM PDT Severity: 3 - Normal Item

[bug #65536] make.texi:5449: node `Using Variables' lacks menu item for `Conditionalizing' despite being its Up target

Follow-up Comment #1, bug #65536 (group make): Hrm why don't I see this? Martin can you let me know what version of makeinfo you are using? ___ Reply to this item at:

[bug #65533] gmake-4.4.1 has a performance regression: at least the nwchem project now builds much slower

Follow-up Comment #4, bug #65533 (group make): I cloned the nwchem git repository and my suspicions were correct. I see many, many instances of recursive variable assignment using $(shell ...) syntax, such as: src/nwc_columbus/sifs/GNUmakefile 38:ALLF = $(filter-out ./sifs_stubs.F, $(shell find

[bug #65536] make.texi:5449: node `Using Variables' lacks menu item for `Conditionalizing' despite being its Up target

URL: Summary: make.texi:5449: node `Using Variables' lacks menu item for `Conditionalizing' despite being its Up target Group: make Submitter: mdorey Submitted: Fri 29 Mar 2024 10:33:17 AM

[bug #65533] gmake-4.4.1 has a performance regression: at least the nwchem project now builds much slower

Follow-up Comment #3, bug #65533 (group make): [comment #2 comment #2:] > the gmake process should consume close to 100% of CPU much of the time doing these variable expansions I like your thinking but that's that's not what Paul's theory predicts. Perhaps an example will help to explain why

[bug #65533] gmake-4.4.1 has a performance regression: at least the nwchem project now builds much slower

Follow-up Comment #2, bug #65533 (group make): Hi Paul, [comment #1 comment #1:] > Since I don't have any idea what the "nwchem" project is or how its makefiles work and you haven't provided any short examples, I can't say for sure. Thank you for your insight. For the record: NWChem is a

[bug #65533] gmake-4.4.1 has a performance regression: at least the nwchem project now builds much slower

Follow-up Comment #1, bug #65533 (group make): Since I don't have any idea what the "nwchem" project is or how its makefiles work and you haven't provided any short examples, I can't say for sure. However, it's almost 100% sure that the problem is that the project's makefiles use a lot of

[bug #65533] gmake-4.4.1 has a performance regression: at least the nwchem project now builds much slower

URL: Summary: gmake-4.4.1 has a performance regression: at least the nwchem project now builds much slower Group: make Submitter: yurivict Submitted: Fri 29 Mar 2024 06:50:10 AM UTC