https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576
--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> --- So I did some historic digging and checking -ferrno-math for malloc() was introduced as a fix where before it we unconditionally assumed that malloc() does not alter global memory. That fix happened in r0-98297-ge3c70387dc0fdf (and was subsequently refined multiple times). The bug was first introduced by r0-97444-gc8b3e92f208415 where the mail introducing it says "I probably simply forgot this - noticed again when looking at some dumps from 436.cactusADM where it hinders copy and constant propagation from an array descriptor over the allocation of the array." so at least my memory got this right that this was mostly about Fortran and the fact that array descriptor optimization is very important (and that unfortunately contains quite some number of integers) and the frontend emits malloc () calls surprisingly often. I'll note that array descriptor accesses are very likely no longer an issue and are disambiguated by default_ref_may_alias_errno. Benchmarking SPEC CPU 2017 revealed no Fortran regression though, but surprisingly 500.perlbench_r shows a measurable (small) hit. I do think we need a solution for the Fortran frontend issue going with the fix. A correct solution would somehow mark all memory accesses generated by the frontend as not aliasing 'errno'. Alternatively the frontend could use its own allocator API and save/restore errno around malloc calls it eventually performs. I don't think ignoring possible 'errno' clobbering by malloc () called from fortran code is correct (but it would be pragmatic, possible by having a per-call flag that says 'does not read/write errno'). Having a glibc entry for malloc w/o errno handling would be useful here, of course. I will propose the attached patch on the mailing list.
