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] | |
...I agree.
My inclination would be to do the cosmetic and small fixes to this and go ahead and commit it and then work on the alternate-character-set hypotheticality and the derived-type spacing stuff in follow-up patches, since AFAIK this doesn't cause anything to break that worked previously. But that's not a strong inclination, and I'll let Paul and FX make the call on that. :)I have fixed derived types. Instead of assuming that the derived types are packed, I have used gfc_typenode_for_spec to produce a tree type and then use the offset values in the components. I believe that this is robust.
I think we should assert that we're not dealing with derived types, since otherwise we would leave the user with a potentially hard-to-find error. Apart from that, I agree with this course of action.
+ size_t
+ gfc_target_expr_size (gfc_expr *e)
+ {
...
+ case BT_DERIVED:
+ ctr = e->value.constructor;
+ for (;ctr; ctr = ctr->next)
+ {
+ gcc_assert (ctr->expr != NULL);
+ expr_size += gfc_target_expr_size (ctr->expr);
+ }
+ return expr_size;
+ default:
+ gfc_internal_error ("Invalid expression in gfc_target_expr_size.");
+ return 0;
+ }
+ }
Cheers, - Tobi
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |