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]

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


-----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.

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]