http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #27 from Mikael Morin <mikael at gcc dot gnu.org> 2011-01-17 13:01:23 UTC --- (In reply to comment #25) > Maybe it would be better to set the "inherited" pointer and target > attributes much earlier, in gfc_variable_attr. With a bit of luck, > things would then work automatically. If you mean set the gfc_component.attr.target field, I don't think it's right. As gfc_component structs belong to the type's gfc_symbol, they are shared between non-pointer and pointer variants. (In reply to comment #26) > (In reply to comment #24) > > Or maybe drop restrict all together on the type for correctness. > > Indeed when we introduced the restrict handling to the Fortran frontend > we thought that the above case would not happen, thus that the testcase > in question would be not a valid Fortran program. At the moment > we probably even could generate a testcase that generates wrong-code > (when the ICE silences itself with release-checking). This means that > simply trying to make it not ICE is probably wrong and simply hides > the real issue (which the ICE shows). > > It is, btw, a sign of bad Fortran language design and makes the point > of the pointer/target attributes moot. I think it makes some sense: If there is more than one data path to a struct, there is more than one data path to all of its components. Thus the inherited target attribute. It's just it doesn't fit the C-minded middle-end well. :-( > > What we could do is drop restrict qualifications for all aggregate > types. At least such funny games do not seem possible with mere > toplevel arrays or scalars, right? Well, i think so. > > > By the way, does the middle-end support creating a variant of a type with a > > sub-component restrict (un)qualified ? > > No. For type variants all the fields are usually shared, you'd have to > create a deep copy. Which means they are not type-compatible anymore ? Which means casts everywhere ?
