This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch, fortran] Handling of .and. and .or. expressions
2018-06-29 9:28 GMT+02:00 Jakub Jelinek <jakub@redhat.com>:
> 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.
Exactly.
> 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.
Thanks for the comments, Jakub. I fully agree. This is pretty much the
sanest strategy I've heard so far in all of this monstrous thread and
I definitely support it.
Cheers,
Janus
- References:
- Re: [patch, fortran] Handling of .and. and .or. expressions
- Re: [patch, fortran] Handling of .and. and .or. expressions
- Re: [patch, fortran] Handling of .and. and .or. expressions
- Re: [patch, fortran] Handling of .and. and .or. expressions
- Re: [patch, fortran] Handling of .and. and .or. expressions
- Re: [patch, fortran] Handling of .and. and .or. expressions
- Re: [patch, fortran] Handling of .and. and .or. expressions
- Re: [patch, fortran] Handling of .and. and .or. expressions
- Re: [patch, fortran] Handling of .and. and .or. expressions
- Re: [patch, fortran] Handling of .and. and .or. expressions
- Re: [patch, fortran] Handling of .and. and .or. expressions