This is the mail archive of the gcc-patches@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] |
Hi Mikael, thanks for the review! >> + else if (selector->ts.u.derived) > > Hum, accessing ts.u.derived is correct only if selector->ts.type is > BT_DERIVED or BT_CLASS, isn't it? yes. > Thus the condition should probably be > else if (selector->ts.type == BT_DERIVED) as the BT_CLASS was handled > before? OK with that change (if it works). Good point. And yes, it works. However, on second thought, I wonder why we need to treat the case "selector->ts.type == BT_DERIVED" at all, since the selector in a SELECT TYPE statement is required to be polymorphic (which is being checked later in resolve_select_type). I.e. we weill get an error on the BT_DERIVED case anyway, so I don't see why we need to build a class container at all here (the only reason I could imagine would be something like error recovery). The attached new version is what I'm regtesting right now (with the whole BT_DERIVED branch removed, since it should not be needed). Ok if it succeeds? Cheers, Janus
Attachment:
pr58185_v3.diff
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |