Bug 258628 - lang/ratfor: build times out on armv7
Summary: lang/ratfor: build times out on armv7
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: arm Any
: --- Affects Only Me
Assignee: Mikael Urankar
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-20 12:31 UTC by Robert Clausecker
Modified: 2021-09-24 14:20 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (bofh)
fuz: maintainer-feedback?


Attachments
ratfor-1985.06_14 build log on armv7 FreeBSD 13 (51.74 KB, text/plain)
2021-09-20 12:31 UTC, Robert Clausecker
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Clausecker freebsd_committer freebsd_triage 2021-09-20 12:31:39 UTC
Created attachment 228050 [details]
ratfor-1985.06_14 build log on armv7 FreeBSD 13

lang/ratfor seems to consistently fail on armv7 with a timeout:

cc -o ratfor77 rat4.o lookup.o getopt.o
ln ratfor77 ratfor
Warning: Object directory not changed from original /wrkdirs/usr/ports/lang/ratfor/work/ratfor-1985.06_14
./ratfor -o test.f test.r
=>> Killing runaway build after 21600 seconds with no output
=>> Cleaning up wrkdir
===>  Cleaning for ratfor-1985.06_14
Killed
build of lang/ratfor | ratfor-1985.06_14 ended at Fri Sep 17 08:14:29 CEST 2021
build time: 06:38:31
!!! build failure encountered !!!

Please fix this issue or at least mark the port as broken on armv7 so it doesn't bog up Poudriere builds.
Comment 1 Mark Millard 2021-09-20 19:17:07 UTC
(In reply to Robert Clausecker from comment #0)

My recent bulk -a on a 16-COrtex-A72 Honeycomb aarch64 targeting
armv7 got: (I've set larger timeouts for poudriere than the
defaults.)

. . .
ln ratfor77 ratfor
--- test.f ---
--- testw.f ---./ratfor -o test.f test.r
--- testw.f ---
./ratfor -o testw.f testw.r
=>> Killing runaway build after 14400 seconds with no output
=>> Cleaning up wrkdir
===>  Cleaning for ratfor-1985.06_14
Killed
build of lang/ratfor | ratfor-1985.06_14 ended at Wed Sep 15 12:14:25 PDT 2021
build time: 04:25:09
!!! build failure encountered !!!

So, with larger timouts and such "./ratfor -o test.f test.r"
finished but it might take more for "./ratfor -o testw.f testw.r".


I will note that the bulk -a targeting aarch64 on aarch64 reported:

[00:14:07] Ignoring lang/ratfor | ratfor-1985.06_14: is marked as broken on aarch64: ./ratfor -o test.f test.r keeps creating huge output file

so a similar point may apply to aarch64. Broken "for the default
timeouts" might be true but "broken for all bounded timeouts and
bounded free disk space" might not.
Comment 2 Mark Millard 2021-09-20 20:12:59 UTC
(In reply to Robert Clausecker from comment #0)

The bug in the port is use of the wrong type on
platforms with char being implicitly unsigned
instead of signed:

From the internal Makefile after the port's patching
of it:

#       On sun4,                use S_CHAR="char"
#       On RS6000,              use S_CHAR="signed char"
#       On DEC3100,     maybe   use S_CHAR="signed char"
#       On CRAY,                use S_CHAR="char"
#       On GNU,                 use S_CHAR="char"
#

CFLAGS+=        -DF77 -DS_CHAR="char" -Wno-error=return-type
#CFLAGS+=       -DS_CHAR="char"

By always using S_CHAR="char", for powerpc64, powerpc, aarch64,
armv7, and armv6 the port will fail because the type is
supposed to be a signed form of char (and, so, "signed char" would
be required).
Comment 3 Mark Millard 2021-09-20 20:18:12 UTC
(In reply to Mark Millard from comment #1)

Given the lack of negative char values for armv7, armv6, aarch64,
powerpc64, powerpc, powerpcspe, and powerpc64le ignore comment 1.
Even if it finished for test.r or testw.r, the result would be wrong
(mishandled for what is encoded as a negative char value).
Comment 4 Mark Millard 2021-09-22 22:45:17 UTC
(In reply to Mark Millard from comment #2)

This is also a problem with:

/usr/ports/lang/ratfor/files/patch-rat4.c

which has:

-       while ((c=our_getopt(argc, argv, "Chn:o:6:")) != EOF)
+       while ((c=getopt(argc, argv, "Chl:n:o:6:")) != EOF)

FreeBSD has:

int getopt(int argc, char * const argv[], const char *optstring);

So: not a char return value. Thus the above code involves a
conversion from int to S_CHAR (trunaction) before the comparison
to to EOF that involves the promotion of the (unsigned in the
problem contexts) char and the (signed) int for use in the != test.

For FreeBSD EOF is in turn:

/usr/include/stdio.h:#define    EOF     (-1)

so a negative int value (as C requires).

The result is that when getopt(. . .) returns EOF the value is
not preserved for use in the != test and the loop does not exit.

As direct handling of the int return value with a later assignment
to c when the value is != EOF would likely be better and avoid the
need for a type ends up as a form of signed char char in this spot.
(I've not checked for other presumptions in the code.)
Comment 5 Mark Millard 2021-09-22 23:19:05 UTC
(In reply to Mark Millard from comment #4)

For now I'm going to use:

diff --git a/lang/ratfor/Makefile b/lang/ratfor/Makefile
index 5b5f37dafd00..687d491da6da 100644
--- a/lang/ratfor/Makefile
+++ b/lang/ratfor/Makefile
@@ -14,6 +14,16 @@ COMMENT=     Rational FORTRAN compiler
 LICENSE=       PD
 LICENSE_FILE=  ${WRKSRC}/README
 
+# NOTE: The following are because of the FreeBSD patched code's handling of char
+#       being unsigned for these palatforms and treating int return values as char,
+#       such as involved with EOF comparisons. The port does not deal with
+#       defining S_CHAR as "signed char" [as one hack for the issue, based on
+#       EOF being (-1) in FreeBSD and so fitting in signed char without a
+#       mathematical value change].
+BROKEN_armv7=          getopt int return is treated as char in patch and later compared to EOF (signed vs. unsigned and truncation then promotion problem)
+BROKEN_armv6=          getopt int return is treated as char in patch and later compared to EOF (signed vs. unsigned and truncation then promotion problem)
+# I did not change the desriptions of the pre-existing BROKEN_*'s but they all
+# have the above issue:
 BROKEN_aarch64=                ./ratfor -o test.f test.r keeps creating huge output file
 BROKEN_powerpc=                ./ratfor -o test.f test.r keeps creating huge output file
 BROKEN_powerpc64=      ./ratfor -o test.f test.r keeps creating huge output file

in order to avoid wasting time waiting for the timeouts while
a cpu is kept busy. (I do not use ratfor.)
Comment 6 commit-hook freebsd_committer freebsd_triage 2021-09-24 14:13:30 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=61f3f3bf5d64b1206d866701ace608a11f8e801e

commit 61f3f3bf5d64b1206d866701ace608a11f8e801e
Author:     Mikael Urankar <mikael@FreeBSD.org>
AuthorDate: 2021-09-24 12:35:50 +0000
Commit:     Mikael Urankar <mikael@FreeBSD.org>
CommitDate: 2021-09-24 14:13:04 +0000

    lang/ratfor: Mark as broken on arm.

    PR:             258628
    Reported by:    Robert Clausecker fuz@fuz.su
    Approved by:    portmgr (tier-2 blanket)

 lang/ratfor/Makefile | 2 ++
 1 file changed, 2 insertions(+)
Comment 7 Mikael Urankar freebsd_committer freebsd_triage 2021-09-24 14:20:45 UTC
Thanks.