POV-Ray : Newsgroups : povray.unix : G++13 : Re: G++13 Server Time
27 Jul 2024 12:12:48 EDT (-0400)
  Re: G++13  
From: William F Pokorny
Date: 22 Jun 2024 01:35:38
Message: <667662aa$1@news.povray.org>
On 6/21/24 22:44, Ton wrote:
> This week I updated my kubuntu 22.04LTS to 24.04LTS, and as a result I had to
> reconfigure and recompile povray3.8 beta2.
> 
> To my amazement I got this error when running the new executable:
> Parse Error: Viewing angle has to be smaller than 180 degrees.
> 
> After some DuckDuckGoing I found this solution
> https://github.com/POV-Ray/povray/issues/460
> and after replacing all HUGE_VALs into HUGE_FINITY_VALs my povray was working
> again.

If the user posting in that issue was correct about g++13 turning on the 
-fno-finite-math-only along with -ffast-math by default and it being the 
cause of the problem, the safest thing to do is to configure with 
-fno-fast-math (*) or use -fno-finite-math-only as suggested. (I cannot 
reproduce the problem by turning finite-math-only on with my g++11.4 
compiler...)

(*) - Many official linux distribution packages of POV-Ray run without 
the fast-math flag, only O2 optimizations and some other stricter 
compiler flags too. They play it safer with distributed software packages.

---

The wrong thing to do is use the suggested patch posted to that github 
issue! It creates a new macro definition in source/core/configcore.h 
called HUGE_FINITE_VAL which replaces the lines:

#ifndef HUGE_VAL
	#define HUGE_VAL 1.0e+17
#endif

with

#define HUGE_FINITE_VAL 1.0e+17

But, HUGE_VAL is always defined - for 25 years or more - in math.h / 
cmath.h and not by that POV-Ray header file. In other words, we've not 
been using that 1e17 value for eons - and the suggested patch brings 
back that old value...

A real fix needs to look at and understand the cause and the code 
implications in detail, everywhere HUGE_VAL* is used today(**). I know 
we use +-inf, which are valid float/double values, to control code flow 
in more than the one reported problem case.

(**) - The POV-Ray source uses std::numeric_limits too in places - which 
has an inifinity() option. I bet those might be a problem too, if used. 
The right fix for the camera code with the hard parse time fail is 
likely to use std::numeric_limits<double>::max() over HUGE_VAL.

If finite-math-only is on in g++13 with fast-math by default (or due 
whatever), I have to think we have more problems than the one, hard, 
parse time camera error fail.

Aside: The linux distribution folks which opened the github issue have 
backed up to g++12 for their distribution package.

---

I'm supporting my own playpen yuqk fork - and others too, theirs.

There is no official support as far as I know.

Bill P.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.