From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5260 invoked by alias); 17 Jan 2005 14:49:53 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 4636 invoked by uid 48); 17 Jan 2005 14:48:11 -0000 Date: Mon, 17 Jan 2005 14:49:00 -0000 Message-ID: <20050117144811.4632.qmail@sourceware.org> From: "jakub at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20031222212004.13470.ro@techfak.uni-bielefeld.de> References: <20031222212004.13470.ro@techfak.uni-bielefeld.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug ada/13470] 64bits Ada bootstrap failure:xnmake etc. crash generating nmake.adb etc. X-Bugzilla-Reason: CC X-SW-Source: 2005-01/txt/msg02202.txt.bz2 List-Id: ------- Additional Comments From jakub at gcc dot gnu dot org 2005-01-17 14:48 ------- This seems to be related to RTX_UNCHANGING_P, but I'm not sure it is actually a bug in the compiler itself, or in the library code. I don't know Ada at all, but e.g. from the comment about it it sounds like it is doing something that is not kosher and is just being bitten by that. GCC marks the u argument as /u, so both return U.Reference; lines end up RTL like: (insn 23 190 24 3 a-stunau.adb:43 (set (reg:DI 68) (mem/s/u/j:DI (plus:DI (reg/v/u/f:DI 60 [ u ]) (const_int 32 [0x20])) [3 .reference+0 S8 A128])) -1 (nil) (nil)) (insn 24 23 25 3 a-stunau.adb:43 (set (reg:DI 69) (mem/s/u/j:DI (plus:DI (reg/v/u/f:DI 60 [ u ]) (const_int 40 [0x28])) [3 .reference+8 S8 A64])) -1 (nil) (nil)) (insn 25 24 26 3 a-stunau.adb:43 (set (reg:DI 58 [ ]) (reg:DI 68)) -1 (nil) (nil)) (insn 26 25 27 3 a-stunau.adb:43 (set (reg:DI 59 [ +8 ]) (reg:DI 69)) -1 (nil) while in the second case the code expects changes done through u_ptr pointer (set to (reg/v/u/f:DI 60 [ u ])), not done with /u, to propagate to the return value. But, as soon as the compiler starts optimizing a little bit more aggressively, although it will change the U.Reference value, it can very well return Old; instead, as it was promissed U.Reference is not going to change during the lifetime of the function. -- What |Removed |Added ---------------------------------------------------------------------------- CC| |laurent at guerby dot net, | |kenner at vlsi1 dot ultra | |dot nyu dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13470