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]

Re: Proposed solution for bug 44384, "builtin_object_size_ treatment of multidimensional arrays is unexpected"


On Mon, Mar 28, 2011 at 3:54 PM, Mark Eklund <meklund@cisco.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I am trying to get a solution for bug 44384, "builtin_object_size_
> treatment of multidimensional arrays is unexpected", and would like
> to know if my approach is right.
>
> First, a quick recap of the issue.
>
> The issue at hand is that __builtin_object_size(ptr, type) always treats
> multidimensional arrays as whole objects instead of treating each
> dimension as a sub-object which results in unexpected results from
> __builtin_object_size(ptr, type) when type & 1 does not equal zero.
>
> As this is of significant interest, I have started to work on a possible
> solution to this issue. ?Basically, the function, addr_objec_size(),
> appears to be the heart of the __builtin_object_size() function.
> However, after tracing the gcc source to see how the sizeof operator
> works as well as checking to see how gcc handles cases such as:
>
> void foo(char *)
> {
> ? ?//stuff
> }
>
> int main()
> {
> ? ?char c[10][20][30];
>
> ? ?foo(c);
> ? ?foo(c[2]);
> }
>
> I am of the opinion that addr_object_size() lacks the necessary
> information to correctly determine which dimension of c is really being
> looked at. ?Therefore, I am looking at ways to somehow append some of
> the original type data to the arguments passed in to addr_object_size()
> and then use that information where appropriate. ?One approach I am
> considering is to append the data to the end of the tree before
> fold_unary_loc() returns with the hopes that the appended data will be
> available to addr_object_size().
>
> However, I would like some feedback as to whether this is the proper
> approach to take, and if so, what the best function to attempt this in
> would be. ?I have already tried convert_for_assignment() (which seems to
> be too early). ?This leads me to believe that the function I am looking
> for might be one of the functions that handle the conversion of the
> generic tree to the gimple tree.
>
> Again any feedback that would help point me in the right direction would
> be appreciated.

What do you want to do with the information from __builtin_object_size?
Note that it was invented for a single special reason, it is probably not
suitable for anything else (and its somewhat fragile implementation shouldn't
be complicated by other usages).

Richard.

> Thanks,
>
> =mark
>
> - --
> Mark Eklund
> Software Engineer
> Product Development
> meklund@cisco.com
> Cisco Systems, Inc.
> 170 West Tasman Dr
> San Jose, CA 95134 USA
> United States
> Cisco.com - http://www.cisco.com
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk2QkvwACgkQQ0N2P/sOd5he+QCgltwvrRjSvOwSUgaDxLzLqasD
> husAoLZQ+FUNx5smq4VyCo9heJl+VT2a
> =myNY
> -----END PGP SIGNATURE-----
>


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