On Wed, Mar 10, 2021 at 8:39 PM mscfd via Fortran wrote:
>
> > which version of gfortran, and which operating system?
> I have seen this on two different Linux distros on x86 with a recently
> compiled version, but also some time ago with an older gfortran 10 version.
>
> Using helgrind on a simp
Dear Harald, dear all,
On 10.03.21 22:26, Harald Anlauf wrote:
[...] I found another testcase which lead to trouble during error
recovery due to a NULL pointer dereference.
I was a bit surprised that the crash only occurs in trans*.c;
however, the error 'non-constant initialization expression'
Hi Martin,
On 10.03.21 21:40, mscfd via Fortran wrote:
Using helgrind on a simple omp do loop with write to
a character variable, I get some possible data races
in libgfortran/io/unit.c.
[...]
Thanks for digging. I have filled https://gcc.gnu.org/PR99529
There global array newunits is
alloc
Dear Tobias, all,
> The reason that it is not permitted is the "automatic data object"
> (see *...* highlighted parts in the quote):
>
> C876 (R839) A *variable* whose *designator* appears as a
> *data-stmt-object* or a data-i-do-object hall not be a
> dummy argument, accessed by use or host ass
Sorry for the noise, but line breaks and subject
were somehow missing...
> which version of gfortran, and which operating system?
I have seen this on two different Linux distros on x86
with a recently compiled version, but also some
time ago with an older gfortran 10 version.
Using helgrind on a
Thanks for the report. I have now applied the attached patch.
Tobias
On 10.03.21 20:44, Russ Childers via Gcc wrote:
https://gcc.gnu.org/onlinedocs/gfortran/MIN.html
...says
"
The return value corresponds to the maximum value among the arguments, and
has the same type and kind as the first ar
Dear Harald,
On 10.03.21 20:43, Harald Anlauf wrote:
In the following variant of the program, the invalid
variable declaration of 'c' itself is avoided by using
a block:
integer :: ll
ll = 4
block
character(ll) :: c(2), cc(2)
character(ll) :: c2(2), cc2(2)
data c /'a', 'b'/
data
Dear Tobias,
thanks for your comments.
> > A variable that is a data statement object shall be a designator,
> > thus a character variable shall have a constant length.
>
> This comment is wrong: A designator does not imply this – nor is
> F2018:C875 violated, not even the substring starting/end
> which version of gfortran, and which operating system?
I have seen this on two different Linux distros on x86 with a recently compiled
version, but also some time ago with an older gfortran 10 version.
Using helgrind on a simple omp do loop with write to a character variable, I
get some possib
On 3/10/21 12:35 PM, Martin Stein via Fortran wrote:
> Hi,
>
> I am seeing rare but reproducible memory corruptions which I can trace back
> to lines like
>
> write(out,'(a,i8)') 'short string', k
>
> where out is a (sufficiently large) character(len=...) variable and k some
> small integer. T
If a variable appears in DATA, the following applies:
F2018: 8.6.7 DATA statement
"Except for variables in named common blocks, a named variable has the
SAVE attribute if any part of it is initialized in a DATA statement,
and this may be confirmed by explicit specification."
The attached test
The C/C++ FE sets for an 'omp declare target' ... 'omp end declare target'
the attribute 'omp declare target implicit'.
That's later processed (for C++) in decl.c - which remove that attribute
and either keeps and explicit 'omp declare target' or 'omp declare target link'
attribute.
Unfortunatel
Hi,
I am seeing rare but reproducible memory corruptions which I can trace back to
lines like
write(out,'(a,i8)') 'short string', k
where out is a (sufficiently large) character(len=...) variable and k some
small integer. The line itself occurs in a subroutine called from within an
openmp reg
> I think it is a bad idea to hard-code the real type.
> Does the following work for you? If so, I think that
> patch is obvious and you can go ahead and commit it.
>
> --- a/gcc/fortran/trans-intrinsic.c
> +++ b/gcc/fortran/trans-intrinsic.c
> @@ -407,7 +407,7 @@ build_round_expr (tree arg, tree
Belated follow-up to the patch from August ...
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552588.html
This patch handles CLASS variables in the FIRSTPRIVATE data-sharing
clause, including freeing the memory at the end.
Technically this patch fixes a regression as the ICE is new –
befo
Dear Harald, dear all,
On 09.03.21 20:45, Harald Anlauf via Fortran wrote:
character variables with undefined length are not allowed as
objects in DATA statements. We better reject them.
Regtested on x86_64-pc-linux-gnu. OK for master / backport?
PR fortran/99205 - Out of memory with undefin
Hi,
On 08.03.21 17:25, Eric Botcazou wrote:
AFAICS the code in build_round_expr implicitly assumes that __float128 exists,
which is *not* the common case among 64-bit architectures since "long double"
is generally already 128-bit for them.
Crossref: Introduced by the Patch for PR96711,
https:
17 matches
Mail list logo
