GNU bug report logs -
#75745
[PATCH] gnu: hugs: Ignore integer overflow.
Previous Next
To reply to this bug, email your comments to 75745 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
guix-patches <at> gnu.org
:
bug#75745
; Package
guix-patches
.
(Wed, 22 Jan 2025 05:52:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Homo <gay <at> disroot.org>
:
New bug report received and forwarded. Copy sent to
guix-patches <at> gnu.org
.
(Wed, 22 Jan 2025 05:52:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
This is required to bootstrap MicroHs.
* gnu/packages/patches/hugs-ignore-integer-overflow.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/hugs.scm (hugs)[source]: Use it.
Change-Id: Ie13085d356f98d4dbb0fd1108b7179ad5226720f
---
See https://github.com/augustss/MicroHs/tree/hugs
It's a strong requirement from Lennart to not remove usage of pattern guards in MicroHs's code, so need help from someone experienced with YACC to add pattern guards support to Hugs, a nice to have, but not required, cherry on top of that: adding bang patterns and "instance forall" support in Hugs.
gnu/local.mk | 1 +
gnu/packages/hugs.scm | 2 +-
.../hugs-ignore-integer-overflow.patch | 55 +++++++++++++++++++
3 files changed, 57 insertions(+), 1 deletion(-)
create mode 100644 gnu/packages/patches/hugs-ignore-integer-overflow.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index f118fe4442..ecea6ae9c7 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1569,6 +1569,7 @@ dist_patch_DATA = \
%D%/packages/patches/hubbub-sort-entities.patch \
%D%/packages/patches/hueplusplus-mbedtls.patch \
%D%/packages/patches/hugs-fix-build.patch \
+ %D%/packages/patches/hugs-ignore-integer-overflow.patch \
%D%/packages/patches/hurd-64bit.patch \
%D%/packages/patches/hurd-refcounts-assert.patch \
%D%/packages/patches/hurd-rumpdisk-no-hd.patch \
diff --git a/gnu/packages/hugs.scm b/gnu/packages/hugs.scm
index b6a97ea78c..ae7acbd511 100644
--- a/gnu/packages/hugs.scm
+++ b/gnu/packages/hugs.scm
@@ -37,7 +37,7 @@ (define-public hugs
(sha256
(base32
"1mdy4aq4campgmnpc2qwq7bsbfhaxfsqdghbyyz2wms4lnfcmyma"))
- (patches (search-patches "hugs-fix-build.patch"))))
+ (patches (search-patches "hugs-fix-build.patch" "hugs-ignore-integer-overflow.patch"))))
(build-system gnu-build-system)
(arguments
`(#:phases
diff --git a/gnu/packages/patches/hugs-ignore-integer-overflow.patch b/gnu/packages/patches/hugs-ignore-integer-overflow.patch
new file mode 100644
index 0000000000..ef0b7de824
--- /dev/null
+++ b/gnu/packages/patches/hugs-ignore-integer-overflow.patch
@@ -0,0 +1,55 @@
+From a87d3a15194e4d7724627e43a94ac1d12ab78f9c Mon Sep 17 00:00:00 2001
+From: Lennart Augustsson <lennart <at> augustsson.net>
+Date: Tue, 21 Jan 2025 12:26:15 -0700
+Subject: [PATCH] Ignore overflow in conversion from Integer to Int.
+
+---
+ src/bignums.c | 24 ++++++++++++++++++++----
+ 1 file changed, 20 insertions(+), 4 deletions(-)
+
+diff --git a/src/bignums.c b/src/bignums.c
+index 32ce528..38ec43f 100644
+--- a/src/bignums.c
++++ b/src/bignums.c
+@@ -196,10 +196,18 @@ Bignum n; {
+ while (nonNull(ds=tl(ds))) {
+ Int d = digitOf(hd(ds));
+ if (b > (Int)(MAXHUGSWORD/BIGBASE))
+- return NIL;
++#if 0
++ return NIL;
++#else
++ fprintf(stderr, "Warning: bigToInt overflow ignored\n");
++#endif
+ b *= BIGBASE;
+ if (d > (Int)((MAXHUGSWORD - m)/b))
+- return NIL;
++#if 0
++ return NIL;
++#else
++ fprintf(stderr, "Warning: bigToInt overflow ignored\n");
++#endif
+ m += b*d;
+ }
+ } else { /* fst(n)==NEGNUM */
+@@ -207,10 +215,18 @@ Bignum n; {
+ while (nonNull(ds=tl(ds))) {
+ Int d = - digitOf(hd(ds));
+ if (b > (MAXPOSINT/BIGBASE))
+- return NIL;
++#if 0
++ return NIL;
++#else
++ fprintf(stderr, "Warning: bigToInt overflow ignored\n");
++#endif
+ b *= BIGBASE;
+ if (d < (MINNEGINT - m)/b)
+- return NIL;
++#if 0
++ return NIL;
++#else
++ fprintf(stderr, "Warning: bigToInt overflow ignored\n");
++#endif
+ m += b*d;
+ }
+ }
--
2.47.1
Information forwarded
to
guix-patches <at> gnu.org
:
bug#75745
; Package
guix-patches
.
(Fri, 24 Jan 2025 14:01:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 75745 <at> debbugs.gnu.org (full text, mbox):
Hi,
> This is required to bootstrap MicroHs.
at first glance and without much background knowledge this looks like
a really bad idea(tm). Do you know why this patch is required (i.e. why
MicroHs relies on this specific overflow behavior)?
Lars
Information forwarded
to
guix-patches <at> gnu.org
:
bug#75745
; Package
guix-patches
.
(Fri, 24 Jan 2025 19:46:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 75745 <at> debbugs.gnu.org (full text, mbox):
Lars-Dominik Braun kirjoitti 2025-01-24 16:00:
> Hi,
>
>> This is required to bootstrap MicroHs.
>
> at first glance and without much background knowledge this looks like
> a really bad idea(tm). Do you know why this patch is required (i.e. why
> MicroHs relies on this specific overflow behavior)?
>
> Lars
Hi,
No idea, I tried grepping both large numbers and fromInteger usage, as
well as grep -i overflow, however not crashing in conversion from
Integer to Int is consistent behavior and might be assumed by a lot of
packages, like if you try:
ghci> fromInteger (9 ^ 100) :: Int
6627890308811632801
I remember several years ago seeing (unrelated to MicroHs) code that for
performance reasons uses integer overflow with division by some power of
2 (i++ / (1 << N)) for circular array (queue) to pass messages between
threads, so having it overflow or underflow is not always a bug.
This message is sent to 75745 <at> debbugs.gnu.org and so is visible to
public at https://issues.guix.gnu.org/75745 or if it doesn't work at
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75745
Information forwarded
to
guix-patches <at> gnu.org
:
bug#75745
; Package
guix-patches
.
(Fri, 24 Jan 2025 21:07:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 75745 <at> debbugs.gnu.org (full text, mbox):
> I remember several years ago seeing (unrelated to MicroHs) code that
> for performance reasons uses integer overflow with division by some
> power of 2 (i++ / (1 << N)) for circular array (queue) to pass messages
> between threads, so having it overflow or underflow is not always a
> bug.
Correction, it was: i++ & (1 << N)
But you get the idea.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#75745
; Package
guix-patches
.
(Sat, 25 Jan 2025 14:29:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 75745 <at> debbugs.gnu.org (full text, mbox):
Hi Lennart,
> If someone fixes all the warnings when compiling Hugs, then I bet this
> problem goes away. But I am not going to do that. In its current state Hugs
> can compile a fully functional MicroHs, and that's enough for me.
actually, I can build the MicroHs package from
https://issues.guix.gnu.org/75778 just fine with our default, unpatched
Hugs. It can also compile/run the example from
https://github.com/augustss/MicroHs?tab=readme-ov-file#example.
Can we therefore just drop this patch? It causes Hugs to die with a
SIGFPE while evaluating the example expression `fromInteger (9 ^ 100)
:: Int` from above, which is rather ugly behavior.
And on an unrelated note: Would it be possible to bootstrap (a possibly
very, very old version of) GHC with MicroHs? (As far as I see our GHC
7 is currently bootstrapped via binaries.)
Lars
Information forwarded
to
guix-patches <at> gnu.org
:
bug#75745
; Package
guix-patches
.
(Sat, 25 Jan 2025 17:09:04 GMT)
Full text and
rfc822 format available.
Message #20 received at 75745 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I actually checked carefully. MicroHs does not rely on any overflow
behaviour. There are no large Integers being used.
I believe this is a Hugs bug caused by Hugs assuming that Int is 32 bits,
but being compiled on a 64 bit platform.
Another example of such a bug is that it looks like the StablePtr
implementation casts 64 bit pointers to and from 32 bit int.
If someone fixes all the warnings when compiling Hugs, then I bet this
problem goes away. But I am not going to do that. In its current state Hugs
can compile a fully functional MicroHs, and that's enough for me.
Lennart
On Fri, Jan 24, 2025, 22:06 <gay <at> disroot.org> wrote:
> > I remember several years ago seeing (unrelated to MicroHs) code that
> > for performance reasons uses integer overflow with division by some
> > power of 2 (i++ / (1 << N)) for circular array (queue) to pass messages
> > between threads, so having it overflow or underflow is not always a
> > bug.
>
> Correction, it was: i++ & (1 << N)
>
> But you get the idea.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#75745
; Package
guix-patches
.
(Sat, 25 Jan 2025 17:09:05 GMT)
Full text and
rfc822 format available.
Message #23 received at 75745 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
So, it seems random if Hugs need the patch or not. Which suggests some
undefined behaviour.
But if it works for you without the patch, so much the better.
I have no idea what it would take to compile GHC with MicroHs. I've not
tried.
I think it might not be too far away. MicroHs will probably need to get
unboxed types (or at least fake them). GHC is written fairly
conservatively and is not using all the latest features.
If somebody wants to try, I'm willing to add needed features to MicroHs if
they are not too crazy.
On Sat, Jan 25, 2025 at 3:28 PM Lars-Dominik Braun <lars <at> 6xq.net> wrote:
> Hi Lennart,
>
> > If someone fixes all the warnings when compiling Hugs, then I bet this
> > problem goes away. But I am not going to do that. In its current state
> Hugs
> > can compile a fully functional MicroHs, and that's enough for me.
>
> actually, I can build the MicroHs package from
> https://issues.guix.gnu.org/75778 just fine with our default, unpatched
> Hugs. It can also compile/run the example from
> https://github.com/augustss/MicroHs?tab=readme-ov-file#example.
>
> Can we therefore just drop this patch? It causes Hugs to die with a
> SIGFPE while evaluating the example expression `fromInteger (9 ^ 100)
> :: Int` from above, which is rather ugly behavior.
>
> And on an unrelated note: Would it be possible to bootstrap (a possibly
> very, very old version of) GHC with MicroHs? (As far as I see our GHC
> 7 is currently bootstrapped via binaries.)
>
> Lars
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#75745
; Package
guix-patches
.
(Sat, 25 Jan 2025 19:46:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 75745 <at> debbugs.gnu.org (full text, mbox):
I wouldn't hurry to close this thread, as it seems to be
architecture-specific problem as today macOS runs on ARM, so Guix on
non-x86 architectures might also be affected.
By the way, I just tested that this code doesn't crash Hugs: fromInteger
(9^20) :: Int
Honestly I am extremely surprised by your willingness to help to
bootstrap GHC, as it's hard to find anyone interested in Haskell
community, and it might be impossible to convince GHC developers to
cooperate.
However I am content with what I already have as I only wanted minimal
bootstrappable Haskell compiler which I can flexibly change to port to
Plan 9 and all architectures it supports, and someone else already
ported Hugs there.
Having GHC on that minimal and portable system is just too much work and
once ported won't even be able to build 99% of packages on Stackage
because Plan 9 is anti-ISO and anti-POSIX, Plan 9 is research OS that
from the beginning opposes existing standards and so maintaining GHC
there would make it harder for me to experiment.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#75745
; Package
guix-patches
.
(Sun, 26 Jan 2025 00:29:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 75745 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I think bootstrapping GHC is a fun goal, but I'm only willing to put in
limited effort.
On Sat, Jan 25, 2025, 20:45 <gay <at> disroot.org> wrote:
> I wouldn't hurry to close this thread, as it seems to be
> architecture-specific problem as today macOS runs on ARM, so Guix on
> non-x86 architectures might also be affected.
>
> By the way, I just tested that this code doesn't crash Hugs: fromInteger
> (9^20) :: Int
>
> Honestly I am extremely surprised by your willingness to help to
> bootstrap GHC, as it's hard to find anyone interested in Haskell
> community, and it might be impossible to convince GHC developers to
> cooperate.
>
> However I am content with what I already have as I only wanted minimal
> bootstrappable Haskell compiler which I can flexibly change to port to
> Plan 9 and all architectures it supports, and someone else already
> ported Hugs there.
>
> Having GHC on that minimal and portable system is just too much work and
> once ported won't even be able to build 99% of packages on Stackage
> because Plan 9 is anti-ISO and anti-POSIX, Plan 9 is research OS that
> from the beginning opposes existing standards and so maintaining GHC
> there would make it harder for me to experiment.
>
[Message part 2 (text/html, inline)]
Added tag(s) moreinfo.
Request was from
Christopher Baines <mail <at> cbaines.net>
to
control <at> debbugs.gnu.org
.
(Sat, 01 Mar 2025 21:06:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 105 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.