# Odd gfortran result with atan

**URL:** <https://fortran-lang.discourse.group/t/odd-gfortran-result-with-atan/3590>\
**Category:** Uncategorized\
**Created:** [May 29, 2022, 3:20pm UTC](https://fortran-lang.discourse.group/t/odd-gfortran-result-with-atan/3590 "2022-05-29T15:20:03Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![mecej4](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mecej4/32/855_2.png) [@mecej4](https://fortran-lang.discourse.group/u/mecej4)\
**Post date:** [May 31, 2022, 3:09am UTC](https://fortran-lang.discourse.group/t/odd-gfortran-result-with-atan/3590/16 "2022-05-31T03:09:09Z")

</div>

Very true, and we had a recent demonstration of this in [a thread here](https://fortran-lang.discourse.group/t/a-bug-in-the-index-function-in-gfortran/3508). The compiler’s built-in intrinsic function **index** had a bug, but the Gfortran RTL intrinsic **index** worked correctly. Whether the bug was visible or not depended on the optimization level specified to the compiler. At low optimization levels, the compiler may choose the RTL routine, but at a higher optimization level it may do the evaluation of a constant expression at compile time using the built-in library routine.

---

_[View the full topic](https://fortran-lang.discourse.group/t/odd-gfortran-result-with-atan/3590)._