Fix array sizes created by Java FE (PR libgcj/57074)

I believe the real problem here is in place_block_symbol() and
output_object_block().  If DECL_INITIAL is given for an array, then
shouldn't we be taking the size from the initializer?

This patch fixes that problem, and ensures that we get an assembler
error if placement in the block changes.  I've bootstrapped with
Jakub's java change, and the libjava failures are gone.  However, the
checking code shows up failures in gcc.c-torture/execute/20010924-1.c
with "attempt to move .org backwards".  This isn't exactly a
regression as previously we generated bad code silently, but clearly
more work is needed to teach place_block_symbol() how to size
variables properly, or else something is going wrong elsewhere in the
compiler..

	PR libcgj/57074
	* varasm.c (place_block_symbol): Use DECL_INITIAL size for
	variables if available.
	(output_object_block): Likewise.  Use .org for each item in
	section anchor block rather than padding.

> I believe the real problem here is in place_block_symbol() and
> output_object_block().  If DECL_INITIAL is given for an array, then
> shouldn't we be taking the size from the initializer?

This means that the size of the array and the size of the initializer don't 
agree, right?  IMO this should be fixed instead since this could run afoul of 
various optimizations using array_ref_up_bound for example.

On Sat, May 04, 2013 at 10:34:52AM +0200, Eric Botcazou wrote:
> > I believe the real problem here is in place_block_symbol() and
> > output_object_block().  If DECL_INITIAL is given for an array, then
> > shouldn't we be taking the size from the initializer?
> 
> This means that the size of the array and the size of the initializer don't 
> agree, right?  IMO this should be fixed instead since this could run afoul of 
> various optimizations using array_ref_up_bound for example.

Good to hear.  I wasn't sure whether the sizes were even supposed to
agree.  Assuming Jakub's second patch fixes java for us (testing now),
that just leaves gcc.c-torture/execute/20010924-1.c which fails to
size a3 and a4 properly.  Both of these vars have DECL_SIZE_UNIT of 1.

struct {
  char a3c;
  char a3p[];
} a3 = {
  'o',
  "wx"
};

struct {
  char a4c;
  char a4p[];
} a4 = {
  '9',
  { 'e', 'b' }
};

> Good to hear.  I wasn't sure whether the sizes were even supposed to
> agree.  Assuming Jakub's second patch fixes java for us (testing now),
> that just leaves gcc.c-torture/execute/20010924-1.c which fails to
> size a3 and a4 properly.  Both of these vars have DECL_SIZE_UNIT of 1.
> 
> struct {
>   char a3c;
>   char a3p[];
> } a3 = {
>   'o',
>   "wx"
> };
> 
> struct {
>   char a4c;
>   char a4p[];
> } a4 = {
>   '9',
>   { 'e', 'b' }
> };

Flexible array members (or related GNU extensions) are a specific issue, 
reported under PR middle-end/28865.

On Sat, May 04, 2013 at 12:31:31PM +0200, Eric Botcazou wrote:
> > Good to hear.  I wasn't sure whether the sizes were even supposed to
> > agree.  Assuming Jakub's second patch fixes java for us (testing now),
> > that just leaves gcc.c-torture/execute/20010924-1.c which fails to
> > size a3 and a4 properly.  Both of these vars have DECL_SIZE_UNIT of 1.
> > 
> > struct {
> >   char a3c;
> >   char a3p[];
> > } a3 = {
> >   'o',
> >   "wx"
> > };
> > 
> > struct {
> >   char a4c;
> >   char a4p[];
> > } a4 = {
> >   '9',
> >   { 'e', 'b' }
> > };
> 
> Flexible array members (or related GNU extensions) are a specific issue, 
> reported under PR middle-end/28865.

Actually when I look more closely, it was me taking the size from
DECL_INITIAL that caused these to fail.  Interestingly, the var_decl
size is correct.  I was wrong to claim it wasn't.

	.org .LANCB1+0
	.type	a4, @object
	.size	a4, 1
a4:
	.byte	57
	.byte	101
	.byte	98
	.org .LANCB1+3
	.type	a3, @object
	.size	a3, 1
a3:
	.byte	111
	.string	"wx"
	.org .LANCB1+7

From that, I see the .size is wrong (assemble_variable_contents() uses
DECL_INITIAL), but the size gleaned from the .org differences
(effectively from var_decl DECL_SIZE_UNIT) is correct.