This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/46244] gfc_compare_derived_types is buggy
- From: "dominiq at lps dot ens.fr" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 20 Feb 2011 20:50:04 +0000
- Subject: [Bug fortran/46244] gfc_compare_derived_types is buggy
- Auto-submitted: auto-generated
- References: <bug-46244-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244
--- Comment #13 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-20 20:49:44 UTC ---
I have applied the patch in comment #12 on top of revision 170344.
> Patch, no regression modulo an error message change in null_1.f90
The error is changed from
Error: Different types in pointer assignment at (1); attempted assignment of
REAL(8) to REAL(4)
to
Error: Different kind type parameters in pointer assignment at (1)
Although I prefer the first form, if it is proven that it is too much work to
recover it, the second one requires only to adjust the tests. More annoying the
patch breaks the 'move_alloc()' calls, e.g., pr42274 comment #1 or pr42769
comment #1 (apparently this new feature is not tested in the test suite).
While looking at the code I have noticed something odd at lines 408 of
gcc/fortran/interface.c (patched file):
if (derived1 != NULL && derived2 != NULL
&& strcmp (derived1->name, derived2->name) == 0
&& derived1->module != NULL && derived2->module != NULL
&& strcmp (derived1->module, derived2->module) == 0)
return 1;
/* Compare type via the rules of the standard. Both types must have
the SEQUENCE attribute to be equal. */
if (strcmp (derived1->name, derived2->name))
return 0;
If the test 'derived1 != NULL && derived2 != NULL' is really required (i.e.,
derived1 or derived2 can be NULL when entering the proc), is not it also
required later in the code (e.g., strcmp (derived1->name, derived2->name))?