Hi Andre,
I forgot to answer your other question:
Am 11.07.23 um 18:23 schrieb Andre Vehreschild via Gcc-patches:
I tried to use a pdt within a derived type as a component. Is that not allowed
by the standard? I know, I could hunt in the standard for it, but when someone
knows out of his head,
Hi Andre,
this looks much better now!
This looks mostly good to me, except for a typo in the testcase:
+ if (p% ci% len /= 42) stop 4
There is no component "ci", only "c". The testsuite would fail.
Regarding the memleak: replacing
// TODO: Fix leaking expr tmp, when simplify is done
Hi Harald,
attached is a new version of the patch. This now also respects inquiry-LEN.
Btw, there is a potential memory leak in the simplify for inquiry functions. I
have added a note into the code.
I tried to use a pdt within a derived type as a component. Is that not allowed
by the standard? I
Hi Harald,
I do get why this happens. I still don't get why I have to do this
'optimization' manually. I mean, this rewriting of expressions is needed in
more than one location and most probably already present somewhere. So who
can point me in the right direction?
Regards,
Andre
Andre Vehresch
Hi Andre,
thanks for looking into this!
While it fixes the original PR, here is a minor extension of the
testcase that ICEs here with your patch:
program pr102003
type pdt(n)
integer, len :: n = 8
character(len=n) :: c
end type pdt
type(pdt(42)) :: p
integer, parameter ::
Hi all,
while browsing the pdt meta-bug I came across 102003 and thought to myself:
Well, that one is easy. How foolish of me...
Anyway, the solution attached prevents a pdt_len (or pdt_kind) expression in a
function call (e.g. len() or kind()) to mark the whole expression as a pdt one.
The secon
