From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25159 invoked by alias); 15 Nov 2005 02:17:55 -0000 Received: (qmail 25143 invoked by uid 22791); 15 Nov 2005 02:17:52 -0000 Received: from smtp-102-tuesday.nerim.net (HELO kraid.nerim.net) (62.4.16.102) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 15 Nov 2005 02:17:52 +0000 Received: from uniton.integrable-solutions.net (gdr.net1.nerim.net [62.212.99.186]) by kraid.nerim.net (Postfix) with ESMTP id 7A9A940E4D; Tue, 15 Nov 2005 03:17:48 +0100 (CET) Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAF2GIge027418; Tue, 15 Nov 2005 03:16:18 +0100 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.10/8.12.10/Submit) id jAF2GIKJ027417; Tue, 15 Nov 2005 03:16:18 +0100 To: Jim Wilson Cc: =?iso-8859-1?q?Rafael_=C1vila_de_Esp=EDndola?= , gcc@gcc.gnu.org Subject: Re: can DECL_RESULT be 0? References: <200511121006.08293.rafael.espindola@gmail.com> <43792CBC.5050604@specifix.com> From: Gabriel Dos Reis In-Reply-To: <43792CBC.5050604@specifix.com> Date: Tue, 15 Nov 2005 02:17:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2005-11/txt/msg00620.txt.bz2 Jim Wilson writes: | Rafael =C1vila de Esp=EDndola 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.) |=20 | 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