Re: [PATCH] fortran: Fix a pasto in gfc_check_dependency
On Fri, Aug 02, 2024 at 06:29:27PM +0200, Mikael Morin wrote: > I agree with all of that. Sure keeping the condition around would be the > safest. I'm just afraid of keeping code that would remain dead. > > > > > And the pasto fix would guess fix > > > > aliasing_dummy_5.f90 with > > > > arg(2:3) = arr(1:2) > > > > instead of > > > > arr(2:3) = arg(1:2) > > > > if the original testcase would actually fail. > > > > > > > Mmh, aren't they both actually the same? > They can alias, and they do alias. So in the end, writing either line is > equivalent, what do I miss? So, I had another look. Seems the reason why the testcase passes is that gfc_could_be_alias (called from gfc_conv_resolve_dependencies) returns true, so the assignment goes through a temporary array. gfc_check_dependency is then only called for if (lhs->rank > 0 && gfc_check_dependency (lhs, rhs, true) == 0) optimize_binop_array_assignment (c, &rhs, false); Guess the question is if one can construct a testcase where it would make a difference. Jakub
Re: [Patch, Fortran] PR104626 ICE in gfc_format_decoder, at fortran/error.cc:1071
Hi Jerry,
looks ok to me. Thanks for taking care.
- Andre
On Fri, 2 Aug 2024 10:44:58 -0700
Jerry D wrote:
> Hi all,
>
> Doing some catchup here. I plan to commit the following shortly. This is
> one of Steve's patches posted on bugzilla.
>
> I have created a new test case.
>
> Regression tested on linux x86-64.
>
> git show:
>
> commit 4d4549937b789afe4037c2f8f80dfc2285504a1e (HEAD -> master)
> Author: Steve Kargl
> Date: Thu Aug 1 21:50:49 2024 -0700
>
> Fortran: Fix ICE on invalid in gfc_format_decoder.
>
> PR fortran/104626
>
> gcc/fortran/ChangeLog:
>
> * symbol.cc (gfc_add_save): Add checks for SAVE attribute
> conflicts and duplicate SAVE attribute.
>
> gcc/testsuite/ChangeLog:
>
> * gfortran.dg/pr104626.f90: New test.
>
> diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
> index a8479b862e3..b5143d9f790 100644
> --- a/gcc/fortran/symbol.cc
> +++ b/gcc/fortran/symbol.cc
> @@ -1307,9 +1307,8 @@ gfc_add_save (symbol_attribute *attr, save_state
> s, const char *name,
>
> if (s == SAVE_EXPLICIT && gfc_pure (NULL))
> {
> - gfc_error
> - ("SAVE attribute at %L cannot be specified in a PURE procedure",
> -where);
> + gfc_error ("SAVE attribute at %L cannot be specified in a PURE "
> +"procedure", where);
> return false;
> }
>
> @@ -1319,10 +1318,15 @@ gfc_add_save (symbol_attribute *attr, save_state
> s, const char *name,
> if (s == SAVE_EXPLICIT && attr->save == SAVE_EXPLICIT
> && (flag_automatic || pedantic))
> {
> - if (!gfc_notify_std (GFC_STD_LEGACY,
> -"Duplicate SAVE attribute specified at %L",
> -where))
> + if (!where)
> + {
> + gfc_error ("Duplicate SAVE attribute specified near %C");
>return false;
> + }
> +
> + if (!gfc_notify_std (GFC_STD_LEGACY, "Duplicate SAVE attribute "
> + "specified at %L", where))
> + return false;
> }
>
> attr->save = s;
> diff --git a/gcc/testsuite/gfortran.dg/pr104626.f90
> b/gcc/testsuite/gfortran.dg/pr104626.f90
> new file mode 100644
> index 000..faff65a8c92
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/pr104626.f90
> @@ -0,0 +1,8 @@
> +! { dg-do compile }
> +program p
> + procedure(g), save :: f ! { dg-error "PROCEDURE attribute conflicts" }
> + procedure(g), save :: f ! { dg-error "Duplicate SAVE attribute" }
> +contains
> + subroutine g
> + end
> +end
--
Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
On Thu, Jul 25, 2024 at 4:47 PM FX Coudert wrote: > Can you post an updated version of the patch, following the first round of > review? > > FX Sorry for a delay, done. I dropped a change to the test file, since you have fixed it appropriately, and switched to Apple libm convention for flags, as you have suggested. Please let me know if I should do anything further to improve it and make it acceptable for a merge. Serge 0001-libgfortran-implement-fpu-macppc-for-Darwin-support-.patch Description: Binary data
Re: [PATCH] fortran: Fix a pasto in gfc_check_dependency
Le 05/08/2024 à 10:59, Jakub Jelinek a écrit : On Fri, Aug 02, 2024 at 06:29:27PM +0200, Mikael Morin wrote: I agree with all of that. Sure keeping the condition around would be the safest. I'm just afraid of keeping code that would remain dead. And the pasto fix would guess fix aliasing_dummy_5.f90 with arg(2:3) = arr(1:2) instead of arr(2:3) = arg(1:2) if the original testcase would actually fail. Mmh, aren't they both actually the same? They can alias, and they do alias. So in the end, writing either line is equivalent, what do I miss? So, I had another look. Seems the reason why the testcase passes is that gfc_could_be_alias (called from gfc_conv_resolve_dependencies) returns true, so the assignment goes through a temporary array. gfc_check_dependency is then only called for if (lhs->rank > 0 && gfc_check_dependency (lhs, rhs, true) == 0) optimize_binop_array_assignment (c, &rhs, false); gfc_check_dependency is also used for WHERE and FORALL. Guess the question is if one can construct a testcase where it would make a difference. The one I made up for PR116196 is a candidate, or can serve as base; I think it's valid, but a bit twisted.
Re: [PATCH 1/8] fortran: Add tests covering inline MINLOC/MAXLOC without DIM [PR90608]
Hi Mikael, I had only a quick glance at this patch, but am a little concerned about the tests involving nans. E.g.: + subroutine check_all_nans() +real, allocatable :: a(:,:,:) +real :: nan +integer, allocatable :: m(:) +nan = 0 +nan = nan / nan +allocate(a(3,3,3), source = nan) +m = maxloc(a) +if (size(m, dim=1) /= 3) stop 161 +if (any(m /= (/ 1, 1, 1 /))) stop 162 + end subroutineT Is there a reason you do not use the ieee intrinsic module way to get a quiet nan? Otherwise, how do you prevent exceptions to happen, possibly leading to a failing test? (The test cases need a workaround to run with NAG). Thanks, Harald
Re: [PATCH 1/8] fortran: Add tests covering inline MINLOC/MAXLOC without DIM [PR90608]
Hello, Le 05/08/2024 à 21:25, Harald Anlauf a écrit : Is there a reason you do not use the ieee intrinsic module way to get a quiet nan? Otherwise, how do you prevent exceptions to happen, possibly leading to a failing test? (The test cases need a workaround to run with NAG). indeed, I didn't think of signaling nans. I will change the test to use the intrinsic module as you suggest. Mikael
