This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/46244] gfc_compare_derived_types is buggy


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))?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]