* 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
@ 2004-12-14 14:44 Richard Kenner
2004-12-15 21:16 ` Christian Joensson
2004-12-21 10:04 ` Eric Botcazou
0 siblings, 2 replies; 15+ messages in thread
From: Richard Kenner @ 2004-12-14 14:44 UTC (permalink / raw)
To: ebotcazou; +Cc: gcc
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!
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
2004-12-14 14:44 [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
@ 2004-12-15 21:16 ` Christian Joensson
2004-12-15 21:19 ` Eric Botcazou
2004-12-21 10:04 ` Eric Botcazou
1 sibling, 1 reply; 15+ messages in thread
From: Christian Joensson @ 2004-12-15 21:16 UTC (permalink / raw)
To: Richard Kenner; +Cc: ebotcazou, gcc
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
2004-12-14 14:44 [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
2004-12-15 21:16 ` Christian Joensson
@ 2004-12-21 10:04 ` Eric Botcazou
1 sibling, 0 replies; 15+ messages in thread
From: Eric Botcazou @ 2004-12-21 10:04 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
@ 2004-12-21 13:05 Richard Kenner
2004-12-21 16:56 ` Eric Botcazou
2004-12-21 22:42 ` Eric Botcazou
0 siblings, 2 replies; 15+ messages in thread
From: Richard Kenner @ 2004-12-21 13:05 UTC (permalink / raw)
To: ebotcazou; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
2004-12-21 13:05 Richard Kenner
@ 2004-12-21 16:56 ` Eric Botcazou
2004-12-21 22:42 ` Eric Botcazou
1 sibling, 0 replies; 15+ messages in thread
From: Eric Botcazou @ 2004-12-21 16:56 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
2004-12-21 13:05 Richard Kenner
2004-12-21 16:56 ` Eric Botcazou
@ 2004-12-21 22:42 ` Eric Botcazou
2004-12-22 4:06 ` James A. Morrison
1 sibling, 1 reply; 15+ messages in thread
From: Eric Botcazou @ 2004-12-21 22:42 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
2004-12-21 22:42 ` Eric Botcazou
@ 2004-12-22 4:06 ` James A. Morrison
0 siblings, 0 replies; 15+ messages in thread
From: James A. Morrison @ 2004-12-22 4:06 UTC (permalink / raw)
To: Eric Botcazou; +Cc: Richard Kenner, gcc
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
@ 2004-12-15 23:32 Richard Kenner
0 siblings, 0 replies; 15+ messages in thread
From: Richard Kenner @ 2004-12-15 23:32 UTC (permalink / raw)
To: christian; +Cc: gcc
> 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 ..
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
@ 2004-12-14 13:29 Richard Kenner
2004-12-14 14:34 ` Eric Botcazou
0 siblings, 1 reply; 15+ messages in thread
From: Richard Kenner @ 2004-12-14 13:29 UTC (permalink / raw)
To: ebotcazou; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
2004-12-14 13:29 Richard Kenner
@ 2004-12-14 14:34 ` Eric Botcazou
0 siblings, 0 replies; 15+ messages in thread
From: Eric Botcazou @ 2004-12-14 14:34 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
@ 2004-12-13 13:01 Richard Kenner
2004-12-14 7:28 ` Eric Botcazou
0 siblings, 1 reply; 15+ messages in thread
From: Richard Kenner @ 2004-12-13 13:01 UTC (permalink / raw)
To: ebotcazou; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
2004-12-13 13:01 Richard Kenner
@ 2004-12-14 7:28 ` Eric Botcazou
0 siblings, 0 replies; 15+ messages in thread
From: Eric Botcazou @ 2004-12-14 7:28 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [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
@ 2004-12-13 7:12 Christian Joensson
2004-12-13 8:20 ` Eric Botcazou
0 siblings, 1 reply; 15+ messages in thread
From: Christian Joensson @ 2004-12-13 7:12 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
2004-12-13 7:12 Christian Joensson
@ 2004-12-13 8:20 ` Eric Botcazou
0 siblings, 0 replies; 15+ messages in thread
From: Eric Botcazou @ 2004-12-13 8:20 UTC (permalink / raw)
To: Christian Joensson; +Cc: gcc
> +===========================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
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2004-12-22 3:48 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-12-14 14:44 [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
2004-12-15 21:16 ` Christian Joensson
2004-12-15 21:19 ` Eric Botcazou
2004-12-21 10:04 ` Eric Botcazou
-- strict thread matches above, loose matches on Subject: below --
2004-12-21 13:05 Richard Kenner
2004-12-21 16:56 ` Eric Botcazou
2004-12-21 22:42 ` Eric Botcazou
2004-12-22 4:06 ` James A. Morrison
2004-12-15 23:32 Richard Kenner
2004-12-14 13:29 Richard Kenner
2004-12-14 14:34 ` Eric Botcazou
2004-12-13 13:01 Richard Kenner
2004-12-14 7:28 ` Eric Botcazou
2004-12-13 7:12 Christian Joensson
2004-12-13 8:20 ` Eric Botcazou
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).