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

Re: PATCH: BPs & cleanups for ARRAY_SIZE


Greg McGary <greg@mcgary.org> writes:

> By the above argument, `s = a' is equivalent to `s = &a[0]' and a[0]
> is char, not char[100], so the only valid access is to s[0], with
> s[1]..s[99] being invalid.  That argument is clearly wrong in this
> context, and not what BPs do in this case.

OK.  Mystery solved.  Upon considering this further, I couldn't see
why BPs shouldn't do as you expect, and in fact they do behave
as you expect.  Consider this:

	int a[10][10];
	int *ip = (int *) a;

The bounds of `ip' extend for 100 ints.

Now, why did BPs choke in init_emit_once?

Here's the change:

-  ggc_add_rtx_root (&const_tiny_rtx[0][0], sizeof(const_tiny_rtx)/sizeof(rtx));
+
+  for (i = 0; i < ARRAY_SIZE (const_tiny_rtx); i++)
+    ggc_add_rtx_root (const_tiny_rtx[i], ARRAY_SIZE (const_tiny_rtx[i]));

The old code referred to `&const_tiny_rtx[0][0]', which is equivalent to
`const_tiny_rtx[0]', which is rtx[MAX_MACHINE_MODE].  This bug code could
also have been fixed without a loop like so:

   ggc_add_rtx_root ((rtx *) const_tiny_rtx, sizeof(const_tiny_rtx)/sizeof(rtx));

Jeff, do you prefer this new fix, or the original fix that avoids the
undefined (but well-trodden) behavior at miniscule expense of time &
space?  I haven't committed anything yet, so I can easily change it.

Greg

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