[PATCH] Fix code size regression in Ada

Eric Botcazou ebotcazou@adacore.com
Tue Aug 8 16:12:00 GMT 2006


Hi,

The following tiny testcase exhibits an annoying regression in Ada.  For

package static_initializer is

  type Vector is array (1 .. 3) of Float;
  type Arr is array (Integer range 1 .. 3) of Vector;

  Pos : constant Arr := ((0.0, 1.0, 2.0),
                         (0.5, 1.5, 2.5),
                         (1.0, 2.0, 4.0));

end;

the 3.x compiler will emit a static initializer in the assembly file

p__pos:
	.long	0
	.long	1065353216
	.long	1073741824
	.long	1056964608
	.long	1069547520
	.long	1075838976
	.long	1065353216
	.long	1073741824
	.long	1082130432

while the mainline compimr will use a dynamic initialization

p___elabs:
.LFB2:
	pushl	%ebp
.LCFI6:
	movl	%esp, %ebp
.LCFI7:
	pushl	%edi
.LCFI8:
	pushl	%esi
.LCFI9:
	subl	$80, %esp
.LCFI10:
	leal	-80(%ebp), %edi
	cld
	movl	$0, %edx
	movl	$9, %eax
	movl	%eax, %ecx
	movl	%edx, %eax
	rep
	stosl
	movl	$0x00000000, %eax
	movl	%eax, -44(%ebp)
	movl	$0x3f800000, %eax
	movl	%eax, -40(%ebp)
	movl	$0x40000000, %eax
	movl	%eax, -36(%ebp)
	movl	-44(%ebp), %eax
	movl	%eax, -80(%ebp)
	movl	-40(%ebp), %eax
	movl	%eax, -76(%ebp)
	movl	-36(%ebp), %eax
	movl	%eax, -72(%ebp)
	movl	$0x3f000000, %eax
	movl	%eax, -32(%ebp)
	movl	$0x3fc00000, %eax
	movl	%eax, -28(%ebp)
	movl	$0x40200000, %eax
	movl	%eax, -24(%ebp)
	movl	-32(%ebp), %eax
	movl	%eax, -68(%ebp)
	movl	-28(%ebp), %eax
	movl	%eax, -64(%ebp)
	movl	-24(%ebp), %eax
	movl	%eax, -60(%ebp)
	movl	$0x3f800000, %eax
	movl	%eax, -20(%ebp)
	movl	$0x40000000, %eax
	movl	%eax, -16(%ebp)
	movl	$0x40800000, %eax
	movl	%eax, -12(%ebp)
	movl	-20(%ebp), %eax
	movl	%eax, -56(%ebp)
	movl	-16(%ebp), %eax
	movl	%eax, -52(%ebp)
	movl	-12(%ebp), %eax
	movl	%eax, -48(%ebp)
	movl	$p__pos, %edi
	leal	-80(%ebp), %esi
	cld
	movl	$9, %eax
	movl	%eax, %ecx
	rep
	movsl


The problem stems from a bad interaction between Ada semantics and the more 
stringent type system of the 4.x compiler: the front-end creates a subtype 
for each inner aggregate of the initializer, the latter being then casted to 
the base subtype before being wrapped up in the outer aggregate.  Gigi used 
to "swallow" the cast but it cannot anymore in 4.x for the aforementioned 
reason.  As a consequence, there is a VIEW_CONVERT_EXPR in the way of the
propagation of the TREE_CONSTANT flag to the outer aggregate, which later
causes initializer_constant_valid_p to reject it.

The proposed fix is to propagate TREE_CONSTANT through VIEW_CONVERT_EXPR, like 
is already the case for CONVERT_EXPR, NOP_EXPR and NON_LVALUE_EXPR.  This 
works because output_constant is prepared to deal with VIEW_CONVERT_EXPR:

  /* Eliminate any conversions since we'll be outputting the underlying
     constant.  */
  while (TREE_CODE (exp) == NOP_EXPR || TREE_CODE (exp) == CONVERT_EXPR
         || TREE_CODE (exp) == NON_LVALUE_EXPR
         || TREE_CODE (exp) == VIEW_CONVERT_EXPR)


Bootstrapped/regtested on i586-redhat-linux.  OK for mainline?


2006-08-08  Eric Botcazou  <ebotcazou@adacore.com>

	* tree.c (build1_stat): Also propagate the TREE_CONSTANT and
	TREE_INVARIANT flags for a VIEW_CONVERT_EXPR.


2006-08-08  Eric Botcazou  <ebotcazou@adacore.com>

	* gnat.dg/specs/static_initializer.ads: New test.


-- 
Eric Botcazou
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f805-001_fsf.diff
Type: text/x-diff
Size: 681 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20060808/8eef48d8/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: static_initializer.ads
Type: text/x-adasrc
Size: 331 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20060808/8eef48d8/attachment-0001.bin>


More information about the Gcc-patches mailing list