On Wed, Mar 19, 2025 at 11:08:58PM +0100, Harald Anlauf wrote:
>
> the attached patch addresses an actually very long-standing issue
> with bogus bounds checks for components of nested derived types in
> assignments when an intermediate level has the POINTER attribute
> instead of the ALLOCATABLE
An associate construct causes the alloc error "pointer being freed was
not allocated" when the selector is a structure constructor for a
derived type with an allocatable component and a procedure pointer
component. This same error occurs if a function returning the same
type replaces the structure
Am 19.03.25 um 23:25 schrieb Steve Kargl:
On Wed, Mar 19, 2025 at 11:08:58PM +0100, Harald Anlauf wrote:
the attached patch addresses an actually very long-standing issue
with bogus bounds checks for components of nested derived types in
assignments when an intermediate level has the POINTER at
Dear all,
the attached patch addresses an actually very long-standing issue
with bogus bounds checks for components of nested derived types in
assignments when an intermediate level has the POINTER attribute
instead of the ALLOCATABLE attribute. It turned out that the
check for a reallocatable l
Hi Andre,
Do not worry about the change team construct. Getting out my notes and
restarting is likely to take a few months yet. Besides which, the PDT fixes
have to come first.
Cheers
Paul
On Wed, 19 Mar 2025 at 13:59, Andre Vehreschild wrote:
> Hi Harald and Paul,
>
> thanks for the reviews
Hi Andre,
Thanks for the review - I'll act on the points that you raised.
The Linaro people reported a failure in reduce_1.f90 execution, which I
believe is due to incorrect casting of 'dim' and a wrong specification of
its kind. I am waiting to hear back from them as to whether or not I have
fix
On 3/17/25 10:40 PM, Damian Rouson wrote:
With gfortran 12.4.0, 13.3.0, and 14.2.0, the program below prints
"T". With gfortran 15, the program crashes with an error message
that indicates that a pointer is being freed that was not allocated.
% cat all.f90
implicit none
type string_t
Hello GCC Community,
My name is Yuao, and I’m excited to express my interest in the “Fortran –
2018/202x” project for Google Summer of Code. I am majoring in Cyber Science
and Engineering, with a solid background in computer science that I believe
will help me contribute effectively to this pro
Hi Harald and Paul,
thanks for the reviews. Committed as gcc-15-8297-g9a13dc48a3a.
Paul, I am working on the change team construct at the moment. It has an
association list embedded. I will finish that work hopefully soon. After that
it will be safe for you to "get out your notes and restart" w/o
Hi Paul,
I took a look at your patch and think I found some improvements needed. In
+bool
+gfc_check_reduce (gfc_expr *array, gfc_expr *operation, gfc_expr *dim,
+ gfc_expr *mask, gfc_expr *identity, gfc_expr *ordered)
+{
...
+ if (formal->sym->attr.allocatable || formal->sym->
Hi Andre and Harald,
It looks good to me too.
Indeed, the associate construct is a strange one since TKR guessing is done
at a very early stage so that the associate block can be parsed. About a
year ago, I started looking at tackling this by delaying parsing the blocks
until the containing block
Hi Harald,
thanks for the comments.
> your solution looks basically correct to me, but I wonder why to
> return early w/o error. Would the following logic be wrong?
>
> @@ -7349,7 +7357,8 @@ resolve_compcall (gfc_expr* e, const char **name)
> gfc_symtree* target;
>
> /* Check that's real
12 matches
Mail list logo
