From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5338 invoked by alias); 10 Dec 2009 14:42:04 -0000 Received: (qmail 5103 invoked by uid 48); 10 Dec 2009 14:41:46 -0000 Date: Thu, 10 Dec 2009 14:42:00 -0000 Message-ID: <20091210144146.5102.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/42324] Gcc doesn't follow x86-64 psABI on _Bool In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "hjl dot tools at gmail dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-12/txt/msg01028.txt.bz2 ------- Comment #10 from hjl dot tools at gmail dot com 2009-12-10 14:41 ------- This is what I got from Sun: Solaris x86-64 compiler does not support this x86-64 psABI requirement for _Bool : "When a value of type _Bool is passed in a register or on the stack, the upper 63 bits of the eightbyte shall be zero" Solaris x86-64 compiler processes it like char or byte. i.e. When a value of type _Bool is passed in a register or on the stack, the bits1-31 of the eightbyte shall be zero and upper 32bits should be left undefined. Thus current behavior of Sun compiler is that which described by option 2. i.e. following solution looks the best from the point of view of Solaris x86-64 compiler : "2. Remove that paragraph in the psABI and keep gcc ASIS. It will make _Bool consistent independent of if it is used for function parameters. Both gcc and icc always treat _Bool as char even if it is returned from a function. It may break compatibilities among x86-64 compilers. But we have such problems anyway for gcc 4.3 and 4.4. " -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324