Dear all,
I've pushed the following minor improvement of an error message
as suggested by the reporter as obvious after regtesting in the
gfortran.dg/gomp subdirectory.
Thanks,
Harald
From 96f4ba4d19a765902af7b79aa77d52c62fa2f82c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 2
27;
This case also applies when z is a DT scalar and x is more than one
level deep.
I would rather not make the error message text vary too much to avoid
to run into issues with translation. Would it be fine with you to have
... dimension 1 of array 'z...%x' above array bound ...
o
r and x is more than one
level deep.
I would rather not make the error message text vary too much to avoid
to run into issues with translation. Would it be fine with you to have
... dimension 1 of array 'z...%x' above array bound ...
only?
OK, let's drop "component&
as well.
- when z is a DT array, and x some component further down, 'z...%x'
This case also applies when z is a DT scalar and x is more than one
level deep.
I would rather not make the error message text vary too much to avoid
to run into issues with translation. Would it be fine wi
eresting. To clarify the options:
- for ordinary array x it would stay 'x'
- when z is a DT scalar, and z%x is the array in question, use 'z%x'
(here z...%x would look strange to me)
- when z is a DT array, and x some component further down, 'z...%x'
I would rather
Le 10/03/2024 à 22:31, Harald Anlauf a écrit :
Dear all,
after playing for some time with NAG and Intel, and an off-list
discussion with Jerry, I am getting more and more convinced that
simpler runtime error messages (also simpler to parse by a human)
are superior to awkward solutions. This is
nsion 1 below lower bound of 1
From cdf3b197beed0ce1649661b2132643b54cbade8d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 10 Mar 2024 22:14:30 +0100
Subject: [PATCH] Fortran: use name of array component in runtime error message
[PR30802]
gcc/fortran/ChangeLog:
PR fortran/30802
Le 30/01/2024 à 11:38, Mikael Morin a écrit :
Another (easier) way to clarify the data reference would be rephrasing
the message so that the array part is separate from the scalar part,
like so (there are too many 'of', but I lack inspiration):
Index '0' of dimension 1 of component 'zz' of el
Le 29/01/2024 à 21:50, Harald Anlauf a écrit :
Am 29.01.24 um 18:25 schrieb Harald Anlauf:
I was talking about the generated format strings of runtime error
messages.
program p
implicit none
type t
real :: zzz(10) = 42
end type t
class(t), allocatable :: xx(:)
integer :: j
Am 29.01.24 um 18:25 schrieb Harald Anlauf:
I was talking about the generated format strings of runtime error
messages.
program p
implicit none
type t
real :: zzz(10) = 42
end type t
class(t), allocatable :: xx(:)
integer :: j
j = 0
allocate (t :: xx(1))
print *, xx
reference in derived-type components for the runtime error
message generated for the bounds-checking code. Without the proper
part ref, not only a user may get confused: I was, too...
The testcase is compile-only, as it is only important to check the
strings used in the error messages.
Regtested on
> > > this patch is actually only a followup fix to generate the proper name
>> > > of an array reference in derived-type components for the runtime error
>> > > message generated for the bounds-checking code. Without the proper
>> > > part ref, not o
per name
> > > of an array reference in derived-type components for the runtime error
> > > message generated for the bounds-checking code. Without the proper
> > > part ref, not only a user may get confused: I was, too...
> > >
> > > The testcase is compile
Hi Mikael,
Am 28.01.24 um 12:39 schrieb Mikael Morin:
Le 24/01/2024 à 22:39, Harald Anlauf a écrit :
Dear all,
this patch is actually only a followup fix to generate the proper name
of an array reference in derived-type components for the runtime error
message generated for the bounds
Le 24/01/2024 à 22:39, Harald Anlauf a écrit :
Dear all,
this patch is actually only a followup fix to generate the proper name
of an array reference in derived-type components for the runtime error
message generated for the bounds-checking code. Without the proper
part ref, not only a user
Dear all,
this patch is actually only a followup fix to generate the proper name
of an array reference in derived-type components for the runtime error
message generated for the bounds-checking code. Without the proper
part ref, not only a user may get confused: I was, too...
The testcase is
-Andrew
>
> On Monday, October 17, 2022 2:28:33 AM PDT Salvatore Filippone via Fortran
> wrote:
> > Dear all
> > I am getting the following error message, which I find quite confusing
> >
> >68 | use amg_prec_mod
> >
> > | 1
>
n Monday, October 17, 2022 2:28:33 AM PDT Salvatore Filippone via Fortran
wrote:
> Dear all
> I am getting the following error message, which I find quite confusing
>
>68 | use amg_prec_mod
>
> | 1
>
> Fatal E
Dear all
I am getting the following error message, which I find quite confusing
68 | use amg_prec_mod
| 1
Fatal Error: Mismatch in components of derived type
'__vtype_psb_c_par_mat_mod_Psb_c_par_mat_type' from 'psb_c_par_mat_mod' at
(1): expecting '
.
It is even worse: The error message states the wrong reason.
The attached patch introduces a new STAT value LIBERROR_NO_MEMORY
that is returned for insufficient virtual memory, and a corresponding
(simple and invariant) ERRMSG: "Insufficient virtual memory".
I think the message is fine
On 28.05.22 22:25, Harald Anlauf via Fortran wrote:
the PR rightfully complained that we did not differentiate errors on
ALLOCATE(...,stat=,errmsg=) for failures from allocation of already
allocated objects or insufficient virtual memory.
It is even worse: The error message states the wrong
I believe that won't be easy
to handle in a general way.)
Most compilers I tried (Intel/NAG/Crayftn) behave similarly, except
for Nvidia/Flang, which try to return the size of the allocation in
the error message.
I am not sure that this is worth the effort. First, ERRMSG is very
compiler-depen
8af266501795dd76d05faef498dbd3472a01b305
Author: Tobias Burnus
Date: Fri May 27 13:12:45 2022 +0200
Fortran: Fix OpenMP clause name in error message
gcc/fortran/ChangeLog:
* openmp.cc (gfc_check_omp_requires): Fix clause name in error.
gcc/testsuite/ChangeLog
in addition to 'kernels',
>> 'parallel'
> I have included the test cases for the "serial construct".
I've adapted the remaining relevant changes and pushed to master branch
commit c4f4c60457d1657cbd72015de3d818eb6462a0e9
'Re
t; >> Hi Manfred,
> >>
> >> Am 29.10.21 um 16:12 schrieb Manfred Schwarb via Fortran:
> >>> Hi,
> >>>
> >>> on 2019-07-23, support for SHORT and LONG intrinsics were removed be
> >>> Steve Kargl by
> >>> adding an
intrinsics were removed be Steve
Kargl by
adding an error message in check.c. However, the error message
Error: 'long' intrinsic subprogram at (1) has been deprecated
is misleading, as support has been disabled by this patch.
Adjust the error message. This error message does not app
Am 29.10.21 um 21:51 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:12 schrieb Manfred Schwarb via Fortran:
>> Hi,
>>
>> on 2019-07-23, support for SHORT and LONG intrinsics were removed be Steve
>> Kargl by
>> adding an error
Hi Manfred,
Am 29.10.21 um 16:12 schrieb Manfred Schwarb via Fortran:
Hi,
on 2019-07-23, support for SHORT and LONG intrinsics were removed be Steve
Kargl by
adding an error message in check.c. However, the error message
Error: 'long' intrinsic subprogram at (1) has been dep
Hi,
on 2019-07-23, support for SHORT and LONG intrinsics were removed be Steve
Kargl by
adding an error message in check.c. However, the error message
Error: 'long' intrinsic subprogram at (1) has been deprecated
is misleading, as support has been disabled by this patch.
Adjust
*PING*
Forwarded Message
Subject: [Patch, fortran] PR fortran/96870 - Class name on error message
Date: Mon, 31 Aug 2020 16:09:32 +
From: José Rui Faustino de Sousa
To: fortran@gcc.gnu.org, gcc-patc...@gcc.gnu.org
Hi all!
Proposed patch to PR96870 - Class name on error
30 matches
Mail list logo
