* can DECL_RESULT be 0?
@ 2005-11-12 12:03 Rafael Ávila de Espíndola
2005-11-15 0:33 ` Jim Wilson
0 siblings, 1 reply; 8+ messages in thread
From: Rafael Ávila de Espíndola @ 2005-11-12 12:03 UTC (permalink / raw)
To: gcc
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
In tree.def:329 it is written that
DECL_RESULT holds a RESULT_DECL node for the value of a function,
or it is 0 for a function that returns no value.
(C functions returning void have zero here.)
but C functions returning void have void_type_node in DECL_RESULT. Also note
that allocate_struct_function calls aggregate_value_p on the DECL_RESULT and
aggregate_value_p assumes that its argument is not null.
Should DECL_RESULT be allowed to be null or should the comment be fixed? If
DECL_RESULT can be null, should aggregate_value_p return false if its
argument is null?
Thanks,
Rafael
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: can DECL_RESULT be 0?
2005-11-12 12:03 can DECL_RESULT be 0? Rafael Ávila de Espíndola
@ 2005-11-15 0:33 ` Jim Wilson
2005-11-15 2:17 ` Gabriel Dos Reis
2005-11-15 21:30 ` Rafael Ávila de Espíndola
0 siblings, 2 replies; 8+ messages in thread
From: Jim Wilson @ 2005-11-15 0:33 UTC (permalink / raw)
To: Rafael Ávila de Espíndola; +Cc: gcc
Rafael Ãvila de EspÃndola wrote:
> DECL_RESULT holds a RESULT_DECL node for the value of a function,
> or it is 0 for a function that returns no value.
> (C functions returning void have zero here.)
I looked at gcc-1.42, and even there, a DECL_RESULT always holds a
RESULT_DECL. It can never be zero. However, the DECL_RTL of this
RESULT_DECL is zero for a function that returns no value. I'm not sure
if this is a typo in the tree.def file, or whether perhaps an
implementation change was made a very long time ago. Either way, this
comment as written is wrong, and has been for a very long time. We
could perhaps drop the comment about 0 values, or maybe expand it to say
that the DECL_RTL of the RESULT_DECL is 0 for functions that return no
value. aggregate_value_p doesn't look at DECL_RTL (DECL_RESULT (...))
so there is no problem there.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: can DECL_RESULT be 0?
2005-11-15 0:33 ` Jim Wilson
@ 2005-11-15 2:17 ` Gabriel Dos Reis
2005-11-15 2:40 ` James E Wilson
2005-11-15 21:30 ` Rafael Ávila de Espíndola
1 sibling, 1 reply; 8+ messages in thread
From: Gabriel Dos Reis @ 2005-11-15 2:17 UTC (permalink / raw)
To: Jim Wilson; +Cc: Rafael Ávila de Espíndola, gcc
Jim Wilson <wilson@specifix.com> writes:
| Rafael Ávila de Espíndola wrote:
| > DECL_RESULT holds a RESULT_DECL node for the value of a function,
| > or it is 0 for a function that returns no value.
| > (C functions returning void have zero here.)
|
| I looked at gcc-1.42, and even there, a DECL_RESULT always holds a
| RESULT_DECL. It can never be zero. However, the DECL_RTL of this
| RESULT_DECL is zero for a function that returns no value. I'm not
| sure if this is a typo in the tree.def file, or whether perhaps an
| implementation change was made a very long time ago. Either way, this
| comment as written is wrong, and has been for a very long time. We
| could perhaps drop the comment about 0 values, or maybe expand it to
| say that the DECL_RTL of the RESULT_DECL is 0 for functions that
| return no value. aggregate_value_p doesn't look at DECL_RTL
| (DECL_RESULT (...)) so there is no problem there.
I was under the impression that the DECL_RESULT is nullified for a
function that passes the named return-value optimization.
-- Gaby
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: can DECL_RESULT be 0?
2005-11-15 2:17 ` Gabriel Dos Reis
@ 2005-11-15 2:40 ` James E Wilson
0 siblings, 0 replies; 8+ messages in thread
From: James E Wilson @ 2005-11-15 2:40 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: Rafael Ávila de Espíndola, gcc
On Mon, 2005-11-14 at 18:16, Gabriel Dos Reis wrote:
> I was under the impression that the DECL_RESULT is nullified for a
> function that passes the named return-value optimization.
Just using grep, I don't see any obvious evidence of that. I don't know
where to look for more info. I see a number of places in the front end
that clear DECL_RESULT, but it appears that they are all clearing it so
that it can be recomputed. Perhaps it is being nullified in some way
other than setting the field to zero.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: can DECL_RESULT be 0?
2005-11-15 0:33 ` Jim Wilson
2005-11-15 2:17 ` Gabriel Dos Reis
@ 2005-11-15 21:30 ` Rafael Ávila de Espíndola
2005-11-18 1:35 ` Jim Wilson
1 sibling, 1 reply; 8+ messages in thread
From: Rafael Ávila de Espíndola @ 2005-11-15 21:30 UTC (permalink / raw)
To: Jim Wilson; +Cc: gcc
[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]
On Monday 14 November 2005 22:33, Jim Wilson wrote:
> I looked at gcc-1.42, and even there, a DECL_RESULT always holds a
> RESULT_DECL. It can never be zero. However, the DECL_RTL of this
> RESULT_DECL is zero for a function that returns no value. I'm not sure
> if this is a typo in the tree.def file, or whether perhaps an
> implementation change was made a very long time ago.
> comment as written is wrong, and has been for a very long time. We
> could perhaps drop the comment about 0 values, or maybe expand it to say
> that the DECL_RTL of the RESULT_DECL is 0 for functions that return no
> value. doesn't look at DECL_RTL (DECL_RESULT (...))
> so there is no problem there.
I thought that there was a problem with aggregate_value_p when, after reading
that comment, I attempted to set DECL_RESULT to 0 in a toy front end that I
am working and the result was a segmentation fault inside aggregate_value_p.
Thank you very much for showing that the problem was in the comment.
Rafael
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: can DECL_RESULT be 0?
2005-11-15 21:30 ` Rafael Ávila de Espíndola
@ 2005-11-18 1:35 ` Jim Wilson
2005-11-20 19:58 ` Rafael Ávila de Espíndola
0 siblings, 1 reply; 8+ messages in thread
From: Jim Wilson @ 2005-11-18 1:35 UTC (permalink / raw)
To: Rafael Ávila de Espíndola; +Cc: gcc
Rafael Ãvila de EspÃndola wrote:
> Thank you very much for showing that the problem was in the comment.
I've checked in a patch to fix the comment typo.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: can DECL_RESULT be 0?
2005-11-18 1:35 ` Jim Wilson
@ 2005-11-20 19:58 ` Rafael Ávila de Espíndola
2005-11-21 21:19 ` James E Wilson
0 siblings, 1 reply; 8+ messages in thread
From: Rafael Ávila de Espíndola @ 2005-11-20 19:58 UTC (permalink / raw)
To: Jim Wilson; +Cc: gcc
[-- Attachment #1.1: Type: text/plain, Size: 217 bytes --]
On Thursday 17 November 2005 23:35, Jim Wilson wrote:
>
> I've checked in a patch to fix the comment typo.
Thanks,
What do you thing about adding an assert? Something similar to the attached
patch.
Rafael
[-- Attachment #1.2: gcc-decl-result.patch --]
[-- Type: text/x-diff, Size: 737 bytes --]
Index: gcc/function.c
===================================================================
--- gcc/function.c (revision 107249)
+++ gcc/function.c (working copy)
@@ -1711,8 +1711,11 @@ aggregate_value_p (tree exp, tree fntype
{
int i, regno, nregs;
rtx reg;
+ tree type;
- tree type = (TYPE_P (exp)) ? exp : TREE_TYPE (exp);
+ gcc_assert (exp != NULL_TREE);
+
+ type = (TYPE_P (exp)) ? exp : TREE_TYPE (exp);
if (fntype)
switch (TREE_CODE (fntype))
@@ -3805,6 +3808,7 @@ allocate_struct_function (tree fndecl)
cfun->decl = fndecl;
result = DECL_RESULT (fndecl);
+ gcc_assert (result != NULL_TREE);
if (aggregate_value_p (result, fndecl))
{
#ifdef PCC_STATIC_STRUCT_RETURN
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: can DECL_RESULT be 0?
2005-11-20 19:58 ` Rafael Ávila de Espíndola
@ 2005-11-21 21:19 ` James E Wilson
0 siblings, 0 replies; 8+ messages in thread
From: James E Wilson @ 2005-11-21 21:19 UTC (permalink / raw)
To: Rafael Ávila de Espíndola; +Cc: gcc
On Sun, 2005-11-20 at 12:01, Rafael Ãvila de EspÃndola wrote:
> What do you thing about adding an assert? Something similar to the attached
> patch.
I think there is no chance of a user seeing this problem. It can only
occur when working on a front end, in which case the problem would be
obvious to the developer, and would be fixed before end users ever saw
it. I don't really see a need for extra checks here.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2005-11-21 21:19 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-11-12 12:03 can DECL_RESULT be 0? Rafael Ávila de Espíndola
2005-11-15 0:33 ` Jim Wilson
2005-11-15 2:17 ` Gabriel Dos Reis
2005-11-15 2:40 ` James E Wilson
2005-11-15 21:30 ` Rafael Ávila de Espíndola
2005-11-18 1:35 ` Jim Wilson
2005-11-20 19:58 ` Rafael Ávila de Espíndola
2005-11-21 21:19 ` James E Wilson
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).