HI Jerry,
The patch looks good to me. OK for mainline and for backporting. I never
quite know what to suggest for delaying backporting and so I will leave it
to your judgement.
Thanks for the patch.
Paul
On Tue, 6 May 2025 at 04:30, Jerry D wrote:
> Attached patch fixes this by checking for
Hi Harald,
It appears that something is not right and generates wrong code with
the check enabled. Can you have another look?
The problem was indeed that generating a formal from an actual
arglist is a bad idea when classes are involved. Fixed in the
attached patch. I think it still makes s
On Mon, May 05, 2025 at 08:30:09PM -0700, Jerry D wrote:
> Attached patch fixes this by checking for BT_VOID and EXPR_FUNCTION.
>
> Thank you for guidance from Steve in the PR and Vincent for
> identifying the problem.
>
> Two test case files added to the testsuite.
>
> Regression tested on x86_
Hi Jerry, all,
the new logic misses the following bad code:
print *, c_associated(c_loc(val), 42)
This now ICEs here.
I suggest to not 'return true' too early before all arguments
have been checked.
Cheers,
Harald
On 5/6/25 19:15, Jerry D wrote:
On 5/6/25 12:44 AM, Paul Richard Thomas wr
On Tue, May 06, 2025 at 07:43:41PM +0200, Harald Anlauf wrote:
>
> the new logic misses the following bad code:
>
> print *, c_associated(c_loc(val), 42)
>
> This now ICEs here.
>
> I suggest to not 'return true' too early before all arguments
> have been checked.
>
Good catch, Harald. We
On 5/6/25 12:44 AM, Paul Richard Thomas wrote:
HI Jerry,
The patch looks good to me. OK for mainline and for backporting. I never
quite know what to suggest for delaying backporting and so I will leave
it to your judgement.
Thanks for the patch.
Paul
Thanks Paul, committed as:
commit r16
On 5/6/25 9:51 AM, Steve Kargl wrote:
On Mon, May 05, 2025 at 08:30:09PM -0700, Jerry D wrote:
Attached patch fixes this by checking for BT_VOID and EXPR_FUNCTION.
Thank you for guidance from Steve in the PR and Vincent for
identifying the problem.
Two test case files added to the testsuite.
I am seeing this today. I do not think it is related to my patch.
Running /home/jerry/dev/trunk/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/specifics_1.f90 -O2 execution test
FAIL: gfortran.dg/specifics_1.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-
See https://gcc.gnu.org/PR120099.
On 5/6/25 19:25, Jerry D wrote:
I am seeing this today. I do not think it is related to my patch.
Running /home/jerry/dev/trunk/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/specifics_1.f90 -O2 execution test
FAIL: gfortran.dg/specifics_1.f90 -O3 -fomit-frame-pointer -funroll-
lo
Dear all,
here's another rather obvious case where a temporary is needed for
an inquiry reference of a complex array which is a component of a
derived type. In contrast to PR119986, the argument is handled
within the code for the intrinsic TRANSFER, so that the other
patch did not catch the pres
On 5/6/25 10:59 AM, Steve Kargl wrote:
On Tue, May 06, 2025 at 07:43:41PM +0200, Harald Anlauf wrote:
the new logic misses the following bad code:
print *, c_associated(c_loc(val), 42)
This now ICEs here.
I suggest to not 'return true' too early before all arguments
have been checked.
12 matches
Mail list logo
