public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* 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).