https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
John David Anglin changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #6 from John David Anglin ---
Created attachment 57360
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57360=edit
Patch
As far as I can tell, the attached patch does not cause any regressions
on x86-64. See:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #5 from Jonathan Wakely ---
https://gcc.gnu.org/pipermail/gcc-patches/2016-January/439448.html described
the reason for the current approach.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #4 from Jonathan Wakely ---
And we have the same pattern in include/c_global/cmath and
include/bits/std_abs.h so I'm also very reluctant to change just one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #3 from Jonathan Wakely ---
(In reply to John David Anglin from comment #0)
> stdlib.h is fixed on this target. The #include_next pulled stdlib.h
> from /usr/include instead of ./prev-gcc/include-fixed/stdlib.h.
Why did that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #2 from dave.anglin at bell dot net ---
On 2024-02-07 2:43 a.m., redi at gcc dot gnu.org wrote:
> Using #include definitely won't work, that would just create a cycle between
> the libstdc++ versions of stdlib.h and cstdlib, at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #1 from Jonathan Wakely ---
Using #include definitely won't work, that would just create a cycle between
the libstdc++ versions of stdlib.h and cstdlib, at least for all targets that
don't have stdlib.h in include-fixed.
