This is the mail archive of the 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]



this patch makes CONSTRUCTOR use internally a VEC to store the elements being
built, instead of using TREE_LIST. The patch survives a C-only bootstrap and
most of the testsuite (a few regressions left). I decided to post it to gather
some feedback since it's the first use of VEC in a tree, so people may object
to the general principle or to how the VEC is exposed to CONSTRUCTOR's users.

This is how the data structure looks like:

+ /* A single element of a CONSTRUCTOR. VALUE holds the actual value of the
+    element. INDEX can optionally design the position of VALUE: in arrays,
+    it is the index where VALUE has to be placed; in structures, it is the
+    FIELD_DECL of the member.  */
+ typedef struct constructor_elt_d GTY(())
+ {
+   tree index;
+   tree value;
+ } constructor_elt;
+ DEF_VEC_O(constructor_elt);
+ DEF_VEC_ALLOC_O(constructor_elt,gc);
+ struct tree_constructor GTY(())
+ {
+   struct tree_common common;
+   VEC(constructor_elt,gc) *elts;
+ };

As you can see, I made CONSTRUCTOR not to be an EXPR anymore, but I am not sure
it is a good idea. Surely it saves a little memory in the structure, but
probably it is not worth going through the regressions chasing out all the
occurrences of IS_EXPR_CODE_CLASS / EXPR_P that need to be relaxed to handle
CONSTRUCTOR. But after all, it would be an EXPR without operands, so it just
did not look right.

I appreciate any kind of feedback before I finish going through the regressions
and changing all languages.

Giovanni Bajo

Attachment: patch-constr.txt
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]