[ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Christian Joensson]

Aurora SPARC Linux release 1.92 (Tangerine FC2) UltraSparc IIi (Sabre) sun4u:

binutils-2.15.90.0.3-6
bison-1.875-7.1
dejagnu-1.4.2-11
expect-5.39.0-96.1
gcc-3.3.4-2
glibc-2.3.3-27
glibc-headers-2.3.3-27
glibc-kernheaders-2.6-16sparc
kernel-2.6.8-1.571sp1
tcl-8.4.5-7

LAST_UPDATED: Sun Dec 12 11:06:37 UTC 2004

+===========================GNAT BUG DETECTED==============================+
| 4.0.0 20041212 (experimental) (sparc-unknown-linux-gnu) GCC error:       |
| in expand_expr_addr_expr_1, at expr.c:6047                               |
| Error detected at g-awk.adb:1316:24                                      |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact gcc or gnatmake command that you entered.              |
| Also include sources listed below in gnatchop format                     |
| (concatenated together with no headers between files).                   |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.



raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:376
make[5]: *** [g-awk.o] Error 1
make[5]: Leaving directory `/usr/local/src/trunk/objdir32/gcc/ada/rts'
make[4]: *** [gnatlib] Error 2
make[4]: Leaving directory `/usr/local/src/trunk/objdir32/gcc/ada'
make[3]: *** [gnatlib-shared] Error 2
make[3]: Leaving directory `/usr/local/src/trunk/objdir32/gcc/ada'
make[2]: *** [gnatlib-shared] Error 2
make[2]: Leaving directory `/usr/local/src/trunk/objdir32/sparc-linux/libada'
make[1]: *** [all-target-libada] Error 2

Anyone?

Cheers,

/ChJ

Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Eric Botcazou]

> +===========================GNAT BUG
> DETECTED==============================+
>
> | 4.0.0 20041212 (experimental) (sparc-unknown-linux-gnu) GCC error:      
> | | in expand_expr_addr_expr_1, at expr.c:6047                             
> |  | Error detected at g-awk.adb:1316:24                                   
> |   | Please submit a bug report; see http://gcc.gnu.org/bugs.html.        
> |    | Include the entire contents of this bug box in the report.          
> |     | Include the exact gcc or gnatmake command that you entered.        
> |      | Also include sources listed below in gnatchop format              
> |       | (concatenated together with no headers between files).           
> |        |
>
> +==========================================================================
>+
>
> Please include these source files with error report
> Note that list may not be accurate in some cases,
> so please double check that the problem can still
> be reproduced with the set of files listed.
>
>
>
> raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:376

PR middle-end/17746.  There is even a patch that has been in my tree for 3 
months (linked to from comment #13) but was recently rejected.  Implementing 
the other solution is far more invasive (and I personally have no time to do 
it at the moment).

-- 
Eric Botcazou

Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[James A. Morrison]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

> > So I'm guessing that Ada is broken on STRICT_ALIGNMENT
> > machines on the head now because of this.
> 
> Here are the results as of today with RTH's patch and mine:
> 
>                 === acats tests ===
> FAIL:   c32001e
> FAIL:   c330001
> FAIL:   c380004
> FAIL:   c390003
> FAIL:   c391002
> FAIL:   c432002
> FAIL:   c432003
> FAIL:   c43214c
> FAIL:   c52011a
> FAIL:   c64105b
> FAIL:   c95086b
> FAIL:   c953003
> FAIL:   cc1221d
> FAIL:   cc50a01
> FAIL:   cc50a02
> FAIL:   cd10002
> FAIL:   cd2b11a
> FAIL:   cd2b11b
> 
>                 === acats Summary ===
> # of expected passes            2303
> # of unexpected failures        18
> Native configuration is sparc-sun-solaris2.8
> 
> c953002 hangs, like on other platforms.
> 
> -- 
> Eric Botcazou
> 

 This is a lot better than any time I've run acats, in the last while, on 
sparc-linux or powerpc-linux .

-- 
Thanks,
Jim

http://www.student.cs.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim

Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Eric Botcazou]

> So I'm guessing that Ada is broken on STRICT_ALIGNMENT
> machines on the head now because of this.

Here are the results as of today with RTH's patch and mine:

                === acats tests ===
FAIL:   c32001e
FAIL:   c330001
FAIL:   c380004
FAIL:   c390003
FAIL:   c391002
FAIL:   c432002
FAIL:   c432003
FAIL:   c43214c
FAIL:   c52011a
FAIL:   c64105b
FAIL:   c95086b
FAIL:   c953003
FAIL:   cc1221d
FAIL:   cc50a01
FAIL:   cc50a02
FAIL:   cd10002
FAIL:   cd2b11a
FAIL:   cd2b11b

                === acats Summary ===
# of expected passes            2303
# of unexpected failures        18
Native configuration is sparc-sun-solaris2.8

c953002 hangs, like on other platforms.

-- 
Eric Botcazou

Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Eric Botcazou]

> I know.  And I'm not at all sure that won't cause problems elsewhere,
> though I agree that it's far better for the gimplifier to make those
> temporaries (and even better if the front end can do it).  But that means
> the writing of code to detect when they have to be made, and no such code
> exists yet.

OK, that's more or less the conclusion I came to.

> So I'm guessing that Ada is broken on STRICT_ALIGNMENT machines on the head
> now because of this. 

Not that much according to the ACATS testsuite, the results on the SPARC were 
on par with those on x86 the last time I tried.  Of course ACATS is not 
exhaustive.

>     I think that, when expand_expr_addr_expr is invoked on an ADDR_EXPR
>     tree, it will make no difference whether the alignment gets explicitly
>     stepped up when a VIEW_CONVERT_EXPR is encountered or not, because the
>     final object the address of which will be returned will be the same.
>
>     What do you think?
>
> Given that nobody cares anymore, that's certainly true.

I can't believe that the chunk of code I quoted in my previous message was 
simply dropped.  Isn't there any substitute elsewhere?

> The other question is if we have to do the step-up in the _REF case.
> I think we still do there, so the disparity between handled_components_p
> and get_inner_reference needs to remain and should be documented.

Agreed.

-- 
Eric Botcazou

Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Richard Kenner]

    and neither expand_expr_addr_expr nor expand_expr_addr_expr_1 make
    temporaries, based on alignment conditions or not.  

I know.  And I'm not at all sure that won't cause problems elsewhere, 
though I agree that it's far better for the gimplifier to make those
temporaries (and even better if the front end can do it).  But that means
the writing of code to detect when they have to be made, and no such code
exists yet.  So I'm guessing that Ada is broken on STRICT_ALIGNMENT
machines on the head now because of this.  But it's *way* too early to
look for test cases.

    I think that, when expand_expr_addr_expr is invoked on an ADDR_EXPR
    tree, it will make no difference whether the alignment gets explicitly
    stepped up when a VIEW_CONVERT_EXPR is encountered or not, because the
    final object the address of which will be returned will be the same.

    What do you think?

Given that nobody cares anymore, that's certainly true.

The other question is if we have to do the step-up in the _REF case.
I think we still do there, so the disparity between handled_components_p
and get_inner_reference needs to remain and should be documented.

Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Eric Botcazou]

> OK, now I understand.  Unfortunately, *not* "accepting" it is also
> problematic since the gimplifier, if it doesn't accept that, will make a
> temporary for the result of the VIEW_CONVERT_EXPR, so the ADDR_EXPR would
> be returning the address of that temporary and not the operand of the
> V_C_E, which is exactly what you *don't* want to happen for TYPE_ALIGN_OK.

That's my understanding too.  handled_component_p should accept this kind of 
VIEW_CONVERT_EXPRs, otherwise we would need to add (|| ....) clauses to every 
single test mentioning handled_component_p at the tree level.  I think the 
TYPE_ALIGN_OK thing should stay at the RTL level.

> So this maybe indeed be the single exception to the correspondance between
> get_inner_refrence and handled_component_p.  I don't particularly care
> for that, but if there's no other way, we should at least document it
> *very* clearly ...

Agreed, I'm going to try and hopefully this will be sufficient to convince the 
other Richard. :-)


About stepping up the alignment in expand_expr_addr_expr_1: after thinking a 
little more, I'm now wondering if this is really necessary.  It was necessary 
to do so with the 3.4 code for every VIEW_CONVERT_EXPR because ADDR_EXPR 
trees were going through:

expand_expr:
    case ADDR_EXPR:
          [...]
	  /* If OP0 is not aligned as least as much as the type requires, we
	     need to make a temporary, copy OP0 to it, and take the address of
	     the temporary.  We want to use the alignment of the type, not of
	     the operand.  Note that this is incorrect for FUNCTION_TYPE, but
	     the test for BLKmode means that can't happen.  The test for
	     BLKmode is because we never make mis-aligned MEMs with
	     non-BLKmode.

	     We don't need to do this at all if the machine doesn't have
	     strict alignment.  */
	  if (STRICT_ALIGNMENT && GET_MODE (op0) == BLKmode
	      && (TYPE_ALIGN (TREE_TYPE (TREE_OPERAND (exp, 0)))
		  > MEM_ALIGN (op0))
	      && MEM_ALIGN (op0) < BIGGEST_ALIGNMENT)
	    {
	      tree inner_type = TREE_TYPE (TREE_OPERAND (exp, 0));
	      rtx new;

	      if (TYPE_ALIGN_OK (inner_type))
		abort ();

	      if (TREE_ADDRESSABLE (inner_type))
		{
		  /* We can't make a bitwise copy of this object, so fail.  */
		  error ("cannot take the address of an unaligned member");
		  return const0_rtx;
		}

	      new = assign_stack_temp_for_type
		(TYPE_MODE (inner_type),
		 MEM_SIZE (op0) ? INTVAL (MEM_SIZE (op0))
		 : int_size_in_bytes (inner_type),
		 1, build_qualified_type (inner_type,
					  (TYPE_QUALS (inner_type)
					   | TYPE_QUAL_CONST)));


With the 4.0 code, the ADDR_EXPR expander has been rewritten into:

    case ADDR_EXPR:
      return expand_expr_addr_expr (exp, target, tmode, modifier);

and neither expand_expr_addr_expr nor expand_expr_addr_expr_1 make 
temporaries, based on alignment conditions or not.  So my understanding is 
that the temporaries business for ADDR_EXPRs has been hoisted ouf of the 
expander and integrated in the gimplifier.

I think that, when expand_expr_addr_expr is invoked on an ADDR_EXPR tree, it 
will make no difference whether the alignment gets explicitly stepped up when 
a VIEW_CONVERT_EXPR is encountered or not, because the final object the 
address of which will be returned will be the same.

What do you think?

-- 
Eric Botcazou

Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Richard Kenner]

    > So this maybe indeed be the single exception to the correspondance
    > between get_inner_refrence and handled_component_p.  I don't
    > particularly care for that, but if there's no other way, we should at
    > least document it *very* clearly ...

    So, what's the suggestion then?

The above, unless anybody has a better idea ..

Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Eric Botcazou]

> So, what's the suggestion then?

I'll rework my patch and see what I need to borrow from the VIEW_CONVERT_EXPR 
expander.

-- 
Eric Botcazou

Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Christian Joensson]

On Tue, Dec 14, 2004 at 09:49:43AM -0500, Richard Kenner wrote:
>     The problematic expression reaches expand_expr_addr_expr_1 unmodified
>     because it was accepted at least once by handled_component_p at an
>     earlier stage (e.g. the gimplifier).
> 
> OK, now I understand.  Unfortunately, *not* "accepting" it is also
> problematic since the gimplifier, if it doesn't accept that, will make a
> temporary for the result of the VIEW_CONVERT_EXPR, so the ADDR_EXPR would be
> returning the address of that temporary and not the operand of the V_C_E,
> which is exactly what you *don't* want to happen for TYPE_ALIGN_OK.
> 
> So this maybe indeed be the single exception to the correspondance between
> get_inner_refrence and handled_component_p.  I don't particularly care
> for that, but if there's no 
other way, we should at least document it
> *very* clearly ...
> 
> This is tricky stuff!

So, what's the suggestion then?

/ChJ

Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Richard Kenner]

    The problematic expression reaches expand_expr_addr_expr_1 unmodified
    because it was accepted at least once by handled_component_p at an
    earlier stage (e.g. the gimplifier).

OK, now I understand.  Unfortunately, *not* "accepting" it is also
problematic since the gimplifier, if it doesn't accept that, will make a
temporary for the result of the VIEW_CONVERT_EXPR, so the ADDR_EXPR would be
returning the address of that temporary and not the operand of the V_C_E,
which is exactly what you *don't* want to happen for TYPE_ALIGN_OK.

So this maybe indeed be the single exception to the correspondance between
get_inner_refrence and handled_component_p.  I don't particularly care
for that, but if there's no other way, we should at least document it
*very* clearly ...

This is tricky stuff!

Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Eric Botcazou]

>     Yes, it is not called in expand_expr_addr_expr_1.  But I think the
>     idea would be that expand_expr_addr_expr_1 should never see an
>     expression that is rejected by handled_component_p.
>
> I'm sorry, I don't know what that means.

The problematic expression reaches expand_expr_addr_expr_1 unmodified because 
it was accepted at least once by handled_component_p at an earlier stage 
(e.g. the gimplifier).

>     IIRC the alignment gets stepped up in the VIEW_CONVERT_EXPR expander.
>
> It does, but as I understand your change, you bypass calling that.

You're right, the expander is bypassed.  This is indeed problematic.

-- 
Eric Botcazou

Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Richard Kenner]

    Yes, it is not called in expand_expr_addr_expr_1.  But I think the
    idea would be that expand_expr_addr_expr_1 should never see an
    expression that is rejected by handled_component_p.

I'm sorry, I don't know what that means.

    IIRC the alignment gets stepped up in the VIEW_CONVERT_EXPR expander.

It does, but as I understand your change, you bypass calling that.

Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Eric Botcazou]

> I reviewed this PR.  Although I agree with RTH that it's important to
> make handled_component_p and get_inner_reference_p agree, it's not
> relevant to this case because handled_component_p isn't called!

Yes, it is not called in expand_expr_addr_expr_1.  But I think the idea would 
be that expand_expr_addr_expr_1 should never see an expression that is 
rejected by handled_component_p.

> My feeling is that your patch is the right approach except that it
> *doesn't* "step up" the alignment and needs to.

IIRC the alignment gets stepped up in the VIEW_CONVERT_EXPR expander.

-- 
Eric Botcazou

Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Richard Kenner]

    PR middle-end/17746.  There is even a patch that has been in my tree
    for 3 months (linked to from comment #13) but was recently rejected.
    Implementing the other solution is far more invasive (and I personally
    have no time to do it at the moment).

I reviewed this PR.  Although I agree with RTH that it's important to
make handled_component_p and get_inner_reference_p agree, it's not
relevant to this case because handled_component_p isn't called!

My feeling is that your patch is the right approach except that it
*doesn't* "step up" the alignment and needs to.