* PING *
2016-09-21 19:03 GMT+01:00 Alessandro Fanfarillo <fanfarillo....@gmail.com>:
> Thanks Andre.
>
> 2016-09-19 9:55 GMT-06:00 Andre Vehreschild <ve...@gmx.de>:
>> Hi Alessandro,
>
>> The if in resolve.c at 8837: resolve_failed_image (... is intentional? It is
>> doing nothing. So do you plan to add more code, or will there never be
>> anything. If the later I recommend to just put a comment there and remove the
>> empty if.
>
> I added the if statement during the development and I forgot to remove it.
>
>>
>> There still is no test when -fcoarray=single is used. This shouldn't be so
>> hard, should it?
>
> Done.
>
> Built and regtested on x86_64-pc-linux-gnu.
>
>>
>> Regards,
>> Andre
>>
>> On Mon, 19 Sep 2016 08:30:12 -0700
>> Alessandro Fanfarillo <fanfarillo....@gmail.com> wrote:
>>
>>> * PING *
>>>
>>> On Sep 7, 2016 3:01 PM, "Alessandro Fanfarillo" <fanfarillo....@gmail.com>
>>> wrote:
>>>
>>> > Dear all,
>>> > the attached patch supports failed images also when -fcoarray=single is
>>> > used.
>>> >
>>> > Built and regtested on x86_64-pc-linux-gnu.
>>> >
>>> > Cheers,
>>> > Alessandro
>>> >
>>> > 2016-08-09 5:22 GMT-06:00 Paul Richard Thomas <
>>> > paul.richard.tho...@gmail.com>:
>>> > > Hi Sandro,
>>> > >
>>> > > As far as I can see, this is OK barring a couple of minor wrinkles and
>>> > > a question:
>>> > >
>>> > > For coarray_failed_images_err.f90 and coarray_image_status_err.f90 you
>>> > > have used the option -fdump-tree-original without making use of the
>>> > > tree dump.
>>> > >
>>> > > Mikael asked you to provide an executable test with -fcoarray=single.
>>> > > Is this not possible for some reason?
>>> > >
>>> > > Otherwise, this is OK for trunk.
>>> > >
>>> > > Thanks for the patch.
>>> > >
>>> > > Paul
>>> > >
>>> > > On 4 August 2016 at 05:07, Alessandro Fanfarillo
>>> > > <fanfarillo....@gmail.com> wrote:
>>> > >> * PING *
>>> > >>
>>> > >> 2016-07-21 13:05 GMT-06:00 Alessandro Fanfarillo <
>>> > fanfarillo....@gmail.com>:
>>> > >>> Dear Mikael and all,
>>> > >>>
>>> > >>> in attachment the new patch, built and regtested on
>>> > x86_64-pc-linux-gnu.
>>> > >>>
>>> > >>> Cheers,
>>> > >>> Alessandro
>>> > >>>
>>> > >>> 2016-07-20 13:17 GMT-06:00 Mikael Morin <morin-mik...@orange.fr>:
>>> > >>>> Le 20/07/2016 à 11:39, Andre Vehreschild a écrit :
>>> > >>>>>
>>> > >>>>> Hi Mikael,
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>>> + if(st == ST_FAIL_IMAGE)
>>> > >>>>>>> + new_st.op = EXEC_FAIL_IMAGE;
>>> > >>>>>>> + else
>>> > >>>>>>> + gcc_unreachable();
>>> > >>>>>>
>>> > >>>>>> You can use
>>> > >>>>>> gcc_assert (st == ST_FAIL_IMAGE);
>>> > >>>>>> foo...;
>>> > >>>>>> instead of
>>> > >>>>>> if (st == ST_FAIL_IMAGE)
>>> > >>>>>> foo...;
>>> > >>>>>> else
>>> > >>>>>> gcc_unreachable ();
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> Be careful, this is not 100% identical in the general case. For
>>> > >>>>> older
>>> > >>>>> gcc version (gcc < 4008) gcc_assert() is mapped to nothing, esp. not
>>> > to
>>> > >>>>> an abort(), so the behavior can change. But in this case everything
>>> > is
>>> > >>>>> fine, because the patch is most likely not backported.
>>> > >>>>>
>>> > >>>> Didn't know about this. The difference seems to be very subtle.
>>> > >>>> I don't mind much anyway. The original version can stay if preferred,
>>> > this
>>> > >>>> was just a suggestion.
>>> > >>>>
>>> > >>>> By the way, if the function is inlined in its single caller, the
>>> > assert or
>>> > >>>> unreachable statement can be removed, which avoids choosing between
>>> > them.
>>> > >>>> That's another suggestion.
>>> > >>>>
>>> > >>>>
>>> > >>>>>>> +
>>> > >>>>>>> + return MATCH_YES;
>>> > >>>>>>> +
>>> > >>>>>>> + syntax:
>>> > >>>>>>> + gfc_syntax_error (st);
>>> > >>>>>>> +
>>> > >>>>>>> + return MATCH_ERROR;
>>> > >>>>>>> +}
>>> > >>>>>>> +
>>> > >>>>>>> +match
>>> > >>>>>>> +gfc_match_fail_image (void)
>>> > >>>>>>> +{
>>> > >>>>>>> + /* if (!gfc_notify_std (GFC_STD_F2008_TS, "FAIL IMAGE statement
>>> > >>>>>>> at %C")) */
>>> > >>>>>>> + /* return MATCH_ERROR; */
>>> > >>>>>>> +
>>> > >>>>>>
>>> > >>>>>> Can this be uncommented?
>>> > >>>>>>
>>> > >>>>>>> + return fail_image_statement (ST_FAIL_IMAGE);
>>> > >>>>>>> +}
>>> > >>>>>>>
>>> > >>>>>>> /* Match LOCK/UNLOCK statement. Syntax:
>>> > >>>>>>> LOCK ( lock-variable [ , lock-stat-list ] )
>>> > >>>>>>> diff --git a/gcc/fortran/trans-intrinsic.c
>>> > >>>>>>> b/gcc/fortran/trans-intrinsic.c index 1aaf4e2..b2f5596 100644
>>> > >>>>>>> --- a/gcc/fortran/trans-intrinsic.c
>>> > >>>>>>> +++ b/gcc/fortran/trans-intrinsic.c
>>> > >>>>>>> @@ -1647,6 +1647,24 @@ trans_this_image (gfc_se * se, gfc_expr
>>> > >>>>>>> *expr) m, lbound));
>>> > >>>>>>> }
>>> > >>>>>>>
>>> > >>>>>>> +static void
>>> > >>>>>>> +gfc_conv_intrinsic_image_status (gfc_se *se, gfc_expr *expr)
>>> > >>>>>>> +{
>>> > >>>>>>> + unsigned int num_args;
>>> > >>>>>>> + tree *args,tmp;
>>> > >>>>>>> +
>>> > >>>>>>> + num_args = gfc_intrinsic_argument_list_length (expr);
>>> > >>>>>>> + args = XALLOCAVEC (tree, num_args);
>>> > >>>>>>> +
>>> > >>>>>>> + gfc_conv_intrinsic_function_args (se, expr, args, num_args);
>>> > >>>>>>> +
>>> > >>>>>>> + if (flag_coarray == GFC_FCOARRAY_LIB)
>>> > >>>>>>> + {
>>> > >>>>>>
>>> > >>>>>> Can everything be put under the if?
>>> > >>>>>> Does it work with -fcoarray=single?
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> IMO coarray=single should not generate code here, therefore putting
>>> > >>>>> everything under the if should to fine.
>>> > >>>>>
>>> > >>>> My point was more avoiding generating code for the arguments if they
>>> > are not
>>> > >>>> used in the end.
>>> > >>>> Regarding the -fcoarray=single case, the function returns a result,
>>> > which
>>> > >>>> can be used in an expression, so I don't think it will work without
>>> > at least
>>> > >>>> hardcoding a fixed value as result in that case.
>>> > >>>> But even that wouldn't be enough, as the function wouldn't work
>>> > consistently
>>> > >>>> with the fail image statement.
>>> > >>>>
>>> > >>>>> Sorry for the comments ...
>>> > >>>>>
>>> > >>>> Comments are welcome here, as far as I know. ;-)
>>> > >>>>
>>> > >>>> Mikael
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > The difference between genius and stupidity is; genius has its limits.
>>> > >
>>> > > Albert Einstein
>>> >
>>
>>
>> --
>> Andre Vehreschild * Email: vehre ad gmx dot de
