Re: [Patch, Fortran, OOP] PR 58185: [4.8/4.9 Regression] ICE when selector in SELECT TYPE is non-polymorphic
>>> 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? >> >> It does regtest cleanly. Ok for trunk and 4.8? >> > Yes. Thanks, committed to trunk as r201919. Will backport to 4.8 soon. Cheers, Janus
Re: [Patch, Fortran, OOP] PR 58185: [4.8/4.9 Regression] ICE when selector in SELECT TYPE is non-polymorphic
Le 22/08/2013 12:49, Janus Weil a écrit : > Hi, > >>> 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? > > It does regtest cleanly. Ok for trunk and 4.8? > Yes.
Re: [Patch, Fortran, OOP] PR 58185: [4.8/4.9 Regression] ICE when selector in SELECT TYPE is non-polymorphic
Hi, >> 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? It does regtest cleanly. Ok for trunk and 4.8? Cheers, Janus
Re: [Patch, Fortran, OOP] PR 58185: [4.8/4.9 Regression] ICE when selector in SELECT TYPE is non-polymorphic
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 pr58185_v3.diff Description: Binary data
Re: [Patch, Fortran, OOP] PR 58185: [4.8/4.9 Regression] ICE when selector in SELECT TYPE is non-polymorphic
Le 19/08/2013 13:38, Janus Weil a écrit : > Hi all, > > here is a small patch which does some cleanup to avoid an ICE on > invalid SELECT TYPE statements. > > The first three hunks are just cosmetics, and the fourth one also > contains minor refactoring, where I pull some common code out of the > two branches of an if statement. The important part, however, is that > I prevent gfc_build_class_symbol from being called if no type symbol > is available. > > Regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.8? > > + 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? 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). Thanks. Mikael
[Patch, Fortran, OOP] PR 58185: [4.8/4.9 Regression] ICE when selector in SELECT TYPE is non-polymorphic
Hi all, here is a small patch which does some cleanup to avoid an ICE on invalid SELECT TYPE statements. The first three hunks are just cosmetics, and the fourth one also contains minor refactoring, where I pull some common code out of the two branches of an if statement. The important part, however, is that I prevent gfc_build_class_symbol from being called if no type symbol is available. Regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.8? Cheers, Janus 2013-08-19 Janus Weil PR fortran/58185 * match.c (copy_ts_from_selector_to_associate): Don't build class symbol if type is not available. Some cleanup. 2013-08-19 Janus Weil PR fortran/58185 * gfortran.dg/select_type_34.f90: New. pr58185.diff Description: Binary data select_type_34.f90 Description: Binary data
