Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

2024-04-20 Thread Dennis Clarke via Bug reports and discussion for GNU make
On 4/19/24 15:15, Paul Smith wrote: On Fri, 2024-04-19 at 14:38 -0400, Dmitry Goncharov wrote: On Fri, Apr 19, 2024 at 1:42 PM Paul Smith wrote: The main advantages to alloca are twofold: 1) efficiency for small local buffers, which GNU Make uses a lot. 2) simplification of the code because

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

2024-04-19 Thread Dennis Clarke via Bug reports and discussion for GNU make
On 4/19/24 14:38, Dmitry Goncharov wrote: On Fri, Apr 19, 2024 at 1:42 PM Paul Smith wrote: The main advantages to alloca are twofold: 1) efficiency for small local buffers, which GNU Make uses a lot. 2) simplification of the code because you don't have to track this memory and ensure it's

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

2024-04-19 Thread Dennis Clarke via Bug reports and discussion for GNU make
On 4/19/24 10:27, Paul Smith wrote: On Fri, 2024-04-19 at 09:54 -0400, Dennis Clarke via Bug reports and discussion for GNU make wrote: Where does one even begin to discover where something ( everything? ) went so horribly wrong? The very first thing you should try is re-configuring GNU Make

TESTs fail features/output-sync and features/parallelism on Linux 4.4.194 armv7l

2024-02-27 Thread Dennis Clarke via Bug reports and discussion for GNU make
As the subject line says ... --- Running tests for GNU Make on linux GNU Make 4.4.1 ---

make-4.3 on Linux x86_64 fails features/output-sync test

2023-11-27 Thread Dennis Clarke via Bug reports and discussion for GNU make
This is highly unexpected on a plain jane Linux x86_64 type box : -- Running tests for GNU make on Linux esther 6.1.63-genunix x86_64 GNU Make 4.3

Re: GNU make 4.2.93 release candidate available

2020-01-11 Thread Dennis Clarke via Bug reports and discussion for GNU make
On 2020-01-11 13:22, Martin Dorey wrote: >> accept prerequisites and implement them as > the user expects, which violates POSIX ... and which never happened > before > > I fear implementing what the makefile author asked for instead of > what they got... could expose other latent issues in their