POV-Ray : Newsgroups : povray.unix : G++13 : Re: G++13 Server Time
19 Jul 2024 23:13:34 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 

(*) - 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


#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.