Clang and FPE trapping

[Robin Williams]

Hi --

I was just reminded of the problem with floating point trapping in Clang

  http://llvm.org/bugs/show_bug.cgi?id=18673

I think we gave up on this being addressed, you'll see that the bug is still open.

However... it looks like it may have actually been fixed between versions 3.6 and 3.7 of Clang -- see https://godbolt.org/z/aEodGnnxz if you'd like to explore.

I may have missed discussion on this, but in cpu.cpp on the gitlab master branch it still says

// do not enable trapping FPEs for Clang compiler since it is not supported in v3.4 and later

# elif defined(__GNUC__) && ( defined(__i386) || defined(__amd64) ) && !defined(__clang__)

It may be worth seeing what happens using a current compiler if the final logic test here is removed.  If this works, some version number discrimination may be required if compilers before v3.7 which are still in the wild are a concern.

Best wishes

  Robin

[Robin Williams]

OK, I downloaded the latest version, and removed that element in the preprocessor code.

The smoke test runs through fine (with clang 10.0.0), and the crash commands work as expected, but pn_paris fails FPEs at an apparently innocuous line of code

Program received signal SIGFPE, Arithmetic exception.

0x000000000069ac58 in RT_line_fine_opacity (t=..., DopplerWidth=<optimised out>) at ../rt_line_one.cpp:360
360 xprofile[i] = i*dcell;
(gdb) print dcell
$1 = 0.530216932
(gdb) print i
$2 = 0

I'll investigate further when I have time.

  Robin

[Gary J. Ferland]

thanks - if you could please send a patch file I will try it on the Mac 

--
--
http://groups.google.com/group/cloudy-dev
---
You received this message because you are subscribed to the Google Groups "cloudy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloudy-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cloudy-dev/CAJBtPxe_NL7gAz4S77ybRpLBZ%2BFwOsGucCYLoQNd11RyjxQrNg%40mail.gmail.com.

--

Gary J. Ferland
Physics, Univ of Kentucky
Lexington KY 40506 USA
Tel: 859 257-8795
https://pa.as.uky.edu/users/gary

[Robin Williams]

It's pretty minimal, but I guess for the avoidance of doubt...  Robin

To view this discussion on the web visit https://groups.google.com/d/msgid/cloudy-dev/CAOxTjFSEfd_Hk0TKZbOxYGvmtLA6M3rR0LUFpyGZV6MaOjP%3DPA%40mail.gmail.com.

[Gary J. Ferland]

smoke test on current Mac llvm

 DISASTER - A floating point exception occurred. Bailing out...

PRNG seed: 0x4ebffcd495e1a484

Backtrace follows:

1   cloudy.exe                          0x0000000100072cff t_cpu_i::signal_handler(int, __siginfo*, void*) + 79 -- cpu.cpp:543
2   libsystem_platform.dylib            0x00007fff20458d7d _sigtramp + 29
3   cloudy.exe                          0x00000001001181f2 iso_suprathermal(long, long) + 338 -- iso_collide.cpp:117
4   cloudy.exe                          0x000000010011a0b8 iso_collide(long, long) + 7608 -- iso_collide.cpp:379
5   cloudy.exe                          0x00000001001329d5 iso_update_rates() + 229 -- iso_solve.cpp:61
6   cloudy.exe                          0x000000010005ad23 ConvBase(long) + 3955 -- conv_base.cpp:463
7   cloudy.exe                          0x0000000100063a18 ConvIoniz() + 72 -- conv_ioniz.cpp:25
8   cloudy.exe                          0x0000000100061d85 EdenError(double) + 85 -- conv_eden_ioniz.cpp:286
9   cloudy.exe                          0x000000010006183f ConvEdenIoniz() + 4495 -- conv_eden_ioniz.cpp:0
10  cloudy.exe                          0x0000000100065778 ConvTempEdenIoniz() + 360 -- conv_temp_eden_ioniz.cpp:78
11  cloudy.exe                          0x00000001000632ae ConvInitSolution() + 910 -- conv_init_solution.cpp:565
12  cloudy.exe                          0x0000000100048957 cloudy() + 263 -- cloudy.cpp:157
13  cloudy.exe                          0x0000000100042d39 cdDrive() + 393 -- cddrive.cpp:153
14  cloudy.exe                          0x0000000100002ee1 cdMain(int, char const**) + 3697 -- maincl.cpp:493
15  cloudy.exe                          0x0000000100001674 main + 1828 -- maincl.cpp:0
16  libdyld.dylib                       0x00007fff2042ef3d start + 1

To view this discussion on the web visit https://groups.google.com/d/msgid/cloudy-dev/CAJBtPxdwWBgsje1St1gU_TbWKqm-Sk_er7FQpaWM5r0g3fZwCg%40mail.gmail.com.

[Robin Williams]

What version does the compiler say it is?  It looks like the version numbers of Apple's clang don't relate in any obvious way to the upstream compiler

  https://gist.github.com/yamaya/2924292#gistcomment-2289472

I think the relevant line of iso_collide.cpp is

   sp->trans(i,0).Coll().rate_lu_nontherm_set() = secondaries.x12tot *
    (sp->trans(i,0).Emis().gf()/
    sp->trans(i,0).EnergyWN()) /
    (iso_sp[ipH_LIKE][ipHYDROGEN].trans(ipH2p,0).Emis().gf()/
    iso_sp[ipH_LIKE][ipHYDROGEN].trans(ipH2p,0).EnergyWN()) *
    iso_ctrl.lgColl_excite[ipISO];;

-- the extra ';' is a bit untidy, and you could save quite a few flops by pulling invariant content out of the loop, but it's difficult to see what's causing an FPE here on a specific compiler.

  Robin

To view this discussion on the web visit https://groups.google.com/d/msgid/cloudy-dev/CAOxTjFSP-fT%3DH-T_MoXZGkW_ZA00256kR4Exa7QXQm2Af_ARRw%40mail.gmail.com.

[Gary J. Ferland]

we have long stumbled over this problem.  Here is clang++ on a fully patched system (current command line tools)

gary@Pro19 auto % clang++ -v
Apple clang version 13.0.0 (clang-1300.0.29.3)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

To view this discussion on the web visit https://groups.google.com/d/msgid/cloudy-dev/CAJBtPxdNQyv-66TEEsWxr47vCzQTV%2BerBdXpaTVSouL%3D%3DN0Qkg%40mail.gmail.com.

[Robin Williams]

OK, the most I can figure out about Xcode 13 clang seems to be that it's somewhere after the clang 9.0.0 equivalent which came with Xcode 11.

However, I installed clang++ 12 on my machine (in addition to the default clang++ 10).  The smoke test fails in the same place as Gary found, so I can reproduce the problem.

Looking at the objdump around the various failures I found, the code was all vectorized, so I tried adding the flag "-fno-slp-vectorize" to the compile.  With this set, the smoke test runs through in clang++ 12, and does pn_paris works with either compiler.

So my guess is that Clang vectorizes the code without worrying about FPE-causing junk getting into parts of the vector beyond the real data.  I'm not sure it makes sense to hobble the code by switching off vectorization for the benefit of FPE trapping, but it's interesting to know how near to working it is.

Thanks

  Robin

To view this discussion on the web visit https://groups.google.com/d/msgid/cloudy-dev/CAOxTjFQTyEErfjeENvNPCJgJOqJJWiuBmApM2CcENSDB7MkrUQ%40mail.gmail.com.

[Gary J. Ferland]

Hi Robin,

thanks for looking into this, and the update.  It sounds like the upshot is, for now, do nothing?  It is good to have these posts in our history for future reference.

best,

Gary

To view this discussion on the web visit https://groups.google.com/d/msgid/cloudy-dev/CAJBtPxexQ3mQ77m30qZXBUwsLadk64vCaFzrc%3DZaA_E-Vk3i1Q%40mail.gmail.com.

[Robin Williams]

Yes.  It's possible that the FPE trapping + no vectorization option may be worth bearing in mind for a developer on a stock iOS machine with no GCC, but that's quite a niche use case.  Given that FPEs are probably rarer beasts in Cloudy than they once were, I think the default setup for Clang still makes sense with the present state of the compiler.

  Robin

To view this discussion on the web visit https://groups.google.com/d/msgid/cloudy-dev/CAOxTjFSQEh-5CmHFr8Nk9Bt4R6Vj2xP8Z%3DcDbMjM3KJLJU6w4w%40mail.gmail.com.

[Gary J. Ferland]

Yes, it is unusual for convergence failures, and very usual for exceptions, to occur today.  That represents a lot of work by you, Peter, & Ryan.

Gary

To view this discussion on the web visit https://groups.google.com/d/msgid/cloudy-dev/CAJBtPxeXOnZ4bSr24ABhRzhA5iio_7PKRAZd1ZA2%3DHRu20NvrA%40mail.gmail.com.