Should mention that it's defined in the Math unit.
I personally believe that as soon as a developer gets 'Error: Identifier not found "SetExceptionMask"' they'll start googling for the function and eventually find out that's in Math unit.
But i'm ok if anyone updates the wiki to explicitly mention that
Also, SetExceptionMask isn't mentioned in relation to OpenGL anywhere else in the wiki.
That's because gl.pp handles the issue for you. If you check "initialization" section you might find the code like this
{$if defined(cpui386) or defined(cpux86_64)}
uses
math;
{$endif}
...
{ according to bug 7570, this is necessary on all x86 platforms,
maybe we've to fix the sse control word as well }
{ Yes, at least for darwin/x86_64 (JM) }
{$if defined(cpui386) or defined(cpux86_64)}
SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide,exOverflow, exUnderflow, exPrecision]);
{$endif}
If you ask me, is using Math unit by any OpenGL units good or bad - I'll say, it is bad.
Because adding "Math" to a uses section also drags "SysUtils", that eventually adds up to 70Kb to the produced executable (fpc 2.6.4, later versions of fpc, probably adds even more).
Demoscene developers would NOT appreciate that
Also, a low-level api unit should not depend on high-level unit.
Back in the (i386 only) days Set8087CW() function was used (declared in System unit).
But it's not compatible (enough?) with x64, thus it was replaced with SetExceptionMask from Math unit.
The function was called by gl.pp as well.
Ultimately, only developers who would not rely on OpenGL RTL package would encounter the problem.
The reason not to use RTL package is simple (as it is right now to Vulkan) - the need of most up-to-date APIs.
One could easily verify the implementation of SetExceptionMask for either i386 as well as x86_64 and make the proper Math-independent solution.