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

G++ OpenMP implementation uses TREE_COMPLEXITY?!?!


Hello rth,

Can you explain what went through your mind when you picked the 
tree_exp.complexity field for something implemented new...  :-(

You know (or so I assume) this was a very Very VERY BAD thing to do,
if we are ever going to get rid of TREE_COMPLEXITY, which is a major
memory hog.  We are all better off if we can remove TREE_COMPLEXITY.

I thought we were there with an Ada patch I've just crafted, and
with the effort of Tom Tromey to remove TREE_COMPLEXITY usage from
the java front end.

But my all-languages bootstrap failed, and guess what:

/* Used to store the operation code when OMP_ATOMIC_DEPENDENT_P is set.  */
#define OMP_ATOMIC_CODE(NODE) \
  (OMP_ATOMIC_CHECK (NODE)->exp.complexity)

We should _not_ be doing this.  *Especially* not through anything
else than the TREE_COMPLEXITY accessor macro to hide the issue...
or maybe that was done on purpose? ;-)

I don't know if there is another place where we can store this
value, but we definitely should.  It is hugely disappointing to see
that, just when we're there with all other front ends, you've just
introduced another user of the tree_exp.complexity field.

Can you please help me fix this ASAP?

Gr.
Steven


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