I have now committed (Rev. 202725) a test case for that patch. (I
confirmed that it fails before Rev. 202609 and works now.)
See attachment.
(While trying to create a test case, I found another bug with defined
assignment; see PR fortran/58469.)
Tobias
PS: I still have to do the backporting
Thomas Koenig wrote:
Build and regtested on x86-64-gnu-linux.
OK?
The patch is OK, also for 4.8. Please add a test case which also
checks for the ForTrilinos failure.
Thanks for the review. I have now committed the current patch as Rev.
202609.
I will later try to create a test case, which
Hi Tobias,
> As testing showed, it didn't fix the real-world code: ForTrilinos's
> ForTrilinos_ADT_3D_Burgers_6th_Pade did still fail as it has:
>
> *_F.DA65 = matrix_diff_x (&parm.621);
>_F.DA66 = ax->epetra_rowmatrix.universal; // Deref of "ax"!
>
> Build and regtested on x86
Yet another try to send this email - this time from a different
server. For completeness:
* The original email didn't made it, nor a repost. But the mail
server didn't bounce back.
* For another email, only the reply made it - but not the original
email: http://gcc.gnu.org/ml/fortran/2013-09/ms
Hi Tobias,
the patch is OK, also for 4.8. Thanks a lot for fixing this.
Just a couple of nits:
- You may want to remove the output from the test case.
- The two consecutive ifs in
>
> if (left != 0B)
> {
> if (_F.DA0 != 0B) goto L.2;
> _F.DA0 = (struct paren
Dear all,
in Fortran 2003, it can happen that for an intrinisic assignment of a
derived type, the component fits to a defined assignment; in that case,
the latter is invoked. gfortran implements this since GCC 4.8 (December).
However, it turned out that the current algorithm doesn't work if t
