https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
--- Comment #8 from Steve Kargl ---
On Wed, Feb 22, 2023 at 08:48:07AM +, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
>
> --- Comment #6 from Richard Biener ---
> For the specific testcase I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
--- Comment #7 from Richard Biener ---
Btw, it _might_ be possible to special case such functions in VN as well,
but to be not too intrusive it would happen at elimination time where we
also remove redundant stores so secondary effects of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
--- Comment #6 from Richard Biener ---
For the specific testcase I also wonder if the Fortran frontend optimization
pass can somehow unify these?
But yes, to be able to optimize these kind of library functions we need an
internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
--- Comment #4 from Steve Kargl ---
On Tue, Feb 21, 2023 at 09:49:38PM +, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
>
> --- Comment #2 from Andrew Pinski ---
> So the right way of fixing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> So the right way of fixing this is to have a builtin versions of "frexp"
> which return a complex type and that is pure for -fno-math-errno and such.
> And gets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
--- Comment #2 from Andrew Pinski ---
So the right way of fixing this is to have a builtin versions of "frexp" which
return a complex type and that is pure for -fno-math-errno and such. And gets
expanded to frexp correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
Andrew Pinski changed:
What|Removed |Added
Component|fortran |middle-end
Severity|normal
