On 3/22/26 14:23, Collin Funk wrote:
Hi Dennis,
Dennis Clarke via Bug reports for the GNU m4 macro processor
<[email protected]> writes:
This is a bit of a strange failure message on a really strange machine.
Perhaps the word "strange" is wrong here. What I mean to say is that it
is very old and obscure in this modern world. I have managed to restore
a 1997 Digital DEC AlphaStation 600 to flawless working order. Which is
to say I tossed a lot of money and time at this thing and it works
perfectly in every measurable way.
It will never ever run Linux. This is because the Alpha 21164 EV5 was
dropped out of the Linux kernel.[1] Therefore the machine runs OpenBSD
and it seems to work great. Even the tape drive. However I must build
anything else I want from sources. C'est la Vie.
Just about everything builds cleanly and I even figured out how to get
really clean IEEE-754 floating point compliance from the monster.
GNU M4 has a single little personality issue here :
...
I changed the CC to [email protected] instead of [email protected] since
this test is imported into m4 from Gnulib.
Anyways, I think the test should be safe to ignore. Here is the alarm
snippet from the test:
#if HAVE_DECL_ALARM
/* In case a bug causes glibc to go into an infinite loop.
The tests should take less than 10 s on a reasonably modern CPU. */
int alarm_value = 1000;
signal (SIGALRM, SIG_DFL);
alarm (alarm_value);
#endif
I don't think your system has a "reasonably modern CPU", no offense. But
maybe Paul, who wrote this comment, has a different definition than
mine. :)
Thanks for the interesting report!
Yup ! I found that and made a small change !
000165 int
000166 main (void)
000167 {
000168 static struct re_pattern_buffer regex;
000169 unsigned char folded_chars[UCHAR_MAX + 1];
000170 const char *s;
000171 struct re_registers regs;
000172
000173 #if HAVE_DECL_ALARM
000174 /* In case a bug causes glibc to go into an infinite loop.
000175 The tests should take less than 10 s on a reasonably modern
CPU.
000176
000177 On an old 1997 DEC AlphaStation 600 with ye olde 21164 EV5 it
000178 may be reasonable to increase to 600 seconds. Seems fitting.
000179
000180 Here I change the 1000 to a 60000.
000181
000182 Dennis Clarke 22 Mar 2026
000183 */
000184 int alarm_value = 60000;
000185 signal (SIGALRM, SIG_DFL);
000186 alarm (alarm_value);
000187 #endif
000188
Well golly gee whiz eh?
============================================================================
Testsuite summary for GNU M4 1.4.21
============================================================================
# TOTAL: 382
# PASS: 334
# SKIP: 48
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
Can we jack that number up to 10 minutes? I also have ye olde Sun SPARC
big clunkers here also :)
--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
