This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR 28034: -fsection-anchors and coverage counters
Richard Sandiford wrote:
> I think it would be better to give the variable the type "T []" (with no
>> array bounds) at this point, and to leave DECL_SIZE set to NULL_TREE, as
>> we would with "extern int i[]". Then, set the type, and DECL_SIZE, when
>> the final size of the array is known.
> As discussed off-list, that was my first instinct too, but I was
> reluctant to do it because
>
> (a) It's a locally-defined object. I thought the optimisers might be
> surprised that a locally-defined object had no known size.
Thank you for trying this!
I'll reiterate my off-list thinking as well, so that we have a complete
record.
I think it's a possibility that the optimizers will choke -- though I
would argue they *should* be able to handle that case, especially given
that we have unit-at-a-time mode. They certainly can handle it for
TREE_PUBLIC objects, since C permits "extern int i[]; int i[10];", and
the fact that "static int i[]; static int i[10];" isn't valid C is
really just an artifact of C.
> (b) It almost seemed too obvious. I felt sure the original author
> must have rejected it for some reason (perhaps (a)).
I don't know what to say about that. :-)
> So, OK to install?
This still isn't quite what I had in mind. I'm sorry; I'm sure I was
unclear.
You've now made the initial type "T [0...?]", i.e., "array of T starting
at zero, upper bound unknown". That seems more likely to tickle a
problem than just "T []". In the latter case, the TYPE_DOMAIN of the
ARRAY_TYPE is just NULL_TREE. (Note that build_array_type explicitly
allows a NULL INDEX_TYPE.)
I think your version is in a way better -- it gives all the information
that is presently available, but since we don't do this for arrays in
C/C++ (which always have a lower bound of zero), I think it would be
best not to do it here either.
If removing the TYPE_DOMAIN works, then that patch is pre-approved. I
apologize for making you go around on this again.
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713