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:
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
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
> 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
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
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
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
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
> 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
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
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
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
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
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
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 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'
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
17 matches
Mail list logo
