https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082
Bug ID: 113082
Summary: builtin transforms do not honor errno
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
This was split out from PR56888.
gcc is changing a program that can rely on errno not being changed to one where
the C library can change it. (The current C library or any future library that
the resulting binary may be dynamically linked against.) The library is
allowed to alter errno when not documented otherwise by 7.5p3
Quoting from the PRs last comment:
(In reply to M Welinder from comment #48)
> It's your (1). gcc is changing a program that can rely on errno not being
> changed to one where the C library can change it. (The current C library or
> any future library that the resulting binary may be dynamically linked
> against.)
Ick. Standards continue to surprise me ;)
> Is there any real-world situation that benefits from introducing these
> calls? It has the feel of optimizing for a benchmark.
People are good in writing inefficient code and replacing say, an open
coded strlen by an actual call to strlen enables followup transforms
that rely on strlen appearing as strlen and not an open-coded variant
(I realize that technically one might find a way to implement that without
actually emitting a call in the end).
And yes, optimizing (repeated) calls of strlen or replacing open-coded
large memcpy by a library call to optimized functions can make a noticable
difference even for non-benchmarks.
We're currently generating calls to memcpy, memmove, memset and strlen.
We are also replacing memmove with memcpy, printf with puts or putc, all
of those transforms are then invalid because of (1) as well.
We are treating -fno-math-errno as applying to non-math functions and
we don't have any -fno-errno or way of analyzing/annotating whether a
program is interested in the state of errno (not only but mainly because
identifying accesses to errno is non-trivial).
