On Thu, Jun 28, 2018 at 07:36:56PM -0700, Steve Kargl wrote:
> === gfortran Summary ===
>
> # of expected passes 47558
> # of unexpected failures 6
> # of expected failures 104
> # of unsupported tests 85
>
> FAIL: gfortran.dg/actual_pointer_function_1.f90 -O0 execution test
> FAIL: gfortran.dg/actual_pointer_function_1.f90 -O1 execution test
> FAIL: gfortran.dg/actual_pointer_function_1.f90 -O2 execution test
> FAIL: gfortran.dg/actual_pointer_function_1.f90 -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
> FAIL: gfortran.dg/actual_pointer_function_1.f90 -O3 -g execution test
> FAIL: gfortran.dg/actual_pointer_function_1.f90 -Os execution test
>
> Execution timeout is: 300
> spawn [open ...]
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory
> reference.
>
> Backtrace for this error:
> #0 0x7ffffffff1a2 in ???
> #1 0x400c09 in ???
> #2 0x400b91 in ???
> #3 0x400c51 in ???
> #4 0x400854 in _start
> at /usr/src/lib/csu/amd64/crt1.c:74
> #5 0x200627fff in ???
If you have a test that is broken by the TRUTH_ANDIF_EXPR -> TRUTH_AND_EXPR
change, then the test must be broken, because from the snippets that were
posted, Fortran does not require (unlike C/C++) that the second operand is
not evaluated if the first one evaluates to false for (and) or true (for
or), it just allows it.
So, the optimizing away of the function calls should be an optimization, and
as such should be done only when optimizing. So for -O0 at least always use
TRUTH_{AND,OR}_EXPR, so that people can actually make sure that their
programs are valid Fortran and can also step into those functions when
debugging. For -O1 and higher perhaps use temporarily the *IF_EXPR, or
better, as I said in another mail, let's add an attribute that will optimize
all the calls that can be optimized, not just one special case.
Jakub
