Le 07/08/2014 15:40, Andre Vehreschild a écrit : > Hi, > > in the bugtracker for PR60255 janus proposed to fix the bug by removing > the error and additionally checking if the character array length > declaration is deferred, which leaves the the charlen to be 0 > (gcc/fortran/class.c (find_intrinsic_vtab) 2418-2420). > > My contribution to that patch is the testcase and to mark the vtab-entry more > clearly to stem from a deferred array init, because I did not like the array > size being 0. This may lead to confusions with a character array of length 0. > Therefore I changed the symbol name generation to enable easier identification > of problems. > > The symbol before my change was computed to be: > > symbolname_0_kind > > I would have used the colon (:) to indicate the deferred state, but that > is not allowed in the assembler, so I spelled it out and the symbol is now > marked by: > > symbolname_DEFERRED_kind > > This way the vtab entry can not be confused with an entry for an entry for a > zero length array and the word DEFERRED has as many characters as MAXINT > printed in the decimal system, i.e., if no check is needed, if MAXINT does fit > into the space reserved for the vtab symbol, then no check is needed for the 8 > character word, too. > > Changelog and extended patch proposal attached. > > Bootstrapped and regtested on x86_64-linux-gnu > > Please comment! >
Hello, the testcase should check that the code generated is actually working, not just that the ICE disappeared. Janus's comment in the PR about _size being 0 tells that probably the code generated won't work in some (corner?) cases, so I'm a bit reluctant to let it pass through (I prefer the ICE). Mikael PS: No need for two separate Changelog entries, just put the two authors in the same entry. See the other ChangeLog files for examples.