Skip to content

Conversation

sim642
Copy link
Contributor

@sim642 sim642 commented Sep 9, 2025

A front-end for the C programming language that facilitates program analysis and transformation

CHANGES:

CHANGES:

* Fix 32bit `Machdep` generation on 64bit host (goblint/cil#195).
@jmid
Copy link
Member

jmid commented Sep 10, 2025

Thanks!

CI failures are down to: 2 FreeBSD timeouts and a Windows failure ('.' is not recognized as an internal or external command, operable program or batch file) which looks OK to me 👍

Would you consider adding an x-maintenance-intent entry for goblint?
https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md

@sim642
Copy link
Contributor Author

sim642 commented Sep 22, 2025

Would you consider adding an x-maintenance-intent entry for goblint?
https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md

I will look into it. It would be nice to have this merged, I can open a separate PR to add the intent to goblint.

@jmid
Copy link
Member

jmid commented Sep 23, 2025

OK thanks 👍

In CI I see

  • conf-gmp.1 issues - this is a separate issue though mark conf-gmp.1 as avoid version #28540
  • run-test failures on arm64 (both with 4.14 and 5.3) . Is this expected? These could be silenced by guarding it by, e.g., arch = "x86_64"

@jmid jmid added the question label Sep 23, 2025
@sim642
Copy link
Contributor Author

sim642 commented Sep 23, 2025

  • run-test failures on arm64 (both with 4.14 and 5.3) . Is this expected? These could be silenced by guarding it by, e.g., arch = "x86_64"

Hmm, no. I was surprised to see this since this should be unchanged since #28433, where it did pass.

The actual problem is deep in the logs:

# /usr/include/aarch64-linux-gnu/bits/math-vector.h[156:9-22] : syntax error
# Parsing errorFatal error: exception GoblintCil__Frontc.ParseError("Parse error")

Looks like the Debian version update between the two PRs means that there are now new headers which contain funky builtin C types like __Float32x4_t.

I wouldn't want to exclude arch = "arm64" entirely though because this also excludes Apple silicon if I remember correctly. Perhaps x-ci-accept-failures for the Debian arm64 would make sense?

@jmid
Copy link
Member

jmid commented Sep 24, 2025

I wouldn't want to exclude arch = "arm64" entirely though because this also excludes Apple silicon if I remember correctly. Perhaps x-ci-accept-failures for the Debian arm64 would make sense?

Makes sense to me 👍
AFAICS, under x-ci-accept-failures we list operating systems from the first list here: https://github.com/ocurrent/opam-repo-ci/blob/master/doc/platforms.md
I don't know how if it is possibly to quantify that to debian-13 only on arm64 though... 🤔

@sim642
Copy link
Contributor Author

sim642 commented Sep 25, 2025

AFAICS, under x-ci-accept-failures we list operating systems from the first list here: https://github.com/ocurrent/opam-repo-ci/blob/master/doc/platforms.md
I don't know how if it is possibly to quantify that to debian-13 only on arm64 though... 🤔

Hmm, that seems to be the case indeed, looking at opam-repo-ci sources.

Oddly enough, I found some packages that have tried looking for other parts of the variant string though (and also has extra brackets!):

x-ci-accept-failures: [
["x86_32"]
["arm32"]
]

x-ci-accept-failures: [
"nnp" "nnpchecker"
"centos-7" # Too old version of make
]

And even one which uses a formula there:
x-ci-accept-failures: os-distribution = "freebsd" | os-family = "fedora"

I suspect that one accidentally even works because opam-repo-ci just greps the value on the shell.

@jmid
Copy link
Member

jmid commented Sep 25, 2025

Nice digging! Indeed greping for a distribution
https://github.com/ocurrent/opam-repo-ci/blob/master/opam-ci-check/lib/opam_build.ml#L66-L74
is not going to have much luck matching architectures (or nnp*), so I think the above are mistakes that have flown under the radar.

For Goblint we could of course cast a wider net with x-ci-accept-failures: ["debian-13"] at the risk of silencing later errors surfacing. However it seems like guarding run-test with, e.g., arch = "x86_64 || os != "linux" is the best option. 🤔

@sim642 sim642 force-pushed the release-goblint-cil-2.0.8 branch from b18d378 to 27bb43c Compare October 1, 2025 08:40
"-j"
jobs
"@install"
"@runtest" {with-test & (arch = "x86_64" | os != "linux")} # fails on arm64 debian-13
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"@runtest" {with-test & (arch = "x86_64" | os != "linux")} # fails on arm64 debian-13
"@runtest" {with-test & os != "freebsd" & (arch = "x86_64" | os != "linux")} # fails on arm64 debian-13

as I see installation working fine but the test suite now failing on FreeBSD.

Otherwise LGTM 👍
(Remaining CI failures are: Windows, opam-2.0, and the conf-gmp.1 issue triggering)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants