Closed brad0 closed 7 months ago
This looks like a compiler issue. Given the error message, in triple.h try changing if(scale == 0.0)
to something like if(fabs(scale) < 1.0e-8)
Just to make sure.. you mean like so?
Index: triple.h
--- triple.h.orig
+++ triple.h
@@ -270,7 +270,7 @@ class triple : virtual public gc { (public)
friend triple unit(const triple& v)
{
double scale=v.length();
- if(scale == 0.0) return v;
+ if(fabs(scale) < 1.0e-8) return v;
scale=1.0/scale;
return triple(v.x*scale,v.y*scale,v.z*scale);
}
That did not help.
But I tried building with -O1 instead of the default -O2. No better. But building with -O0 and everything built Ok, the unit tests all pass.
Things didn't improve with 17.0.6.
Instead of building all of asymptote with -O0 another developer narrowed down disabling optimization to some of the functions.
https://github.com/openbsd/ports/blob/master/graphics/asymptote/patches/patch-path_cc https://github.com/openbsd/ports/blob/master/graphics/asymptote/patches/patch-triple_h
Good to know. It would be even more helpful to produce a minimal example that takes the same vector that causes the FPE (a cout statement in unit would be helpful) and then tries to compute a unit vector, guarding the division with an if statement. Such an example should help the compiler developers fix their optimization to respect guards against division by zero. At least it looks like that is what is going on here. I will close this for now but we can reopen it again later if needed.
With OpenBSD we updated from Clang 13 to Clang 16.0.6 and noticed asymptote fails to build like so. Trying with 17.0.6 also didn't improve anything.
The latest source does not appear to be any better off.
Arch is amd64.
Looks like FreeBSD is building with any Clang version up to 15, but obviously before 16 as a workaround as well. They updated to 16.0.6 about 5 months ago.
https://github.com/freebsd/freebsd-ports/commit/3b09134588a42a227abaf8ceed7cff5143dcf36b