From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5342 invoked by alias); 12 Mar 2007 22:21:02 -0000 Received: (qmail 5290 invoked by uid 48); 12 Mar 2007 22:20:51 -0000 Date: Mon, 12 Mar 2007 22:21:00 -0000 Message-ID: <20070312222051.5289.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dje at gcc dot gnu dot org" 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: 2007-03/txt/msg01128.txt.bz2 ------- Comment #4 from dje at gcc dot gnu dot org 2007-03-12 22:20 ------- I do not believe this is an endian issue. It is a coincidence that the output value looks like the original constant. GCC converts the __builtin_memcpy() into a VIEW_CONVERT_EXPR. The constant is equivalent to a NaN and GCC uses the value CONST_DOUBLE NaN, not the original bits. real.c converts the CONST_DOUBLE NaN into a ieee_double NaN, which happens to look like the value printed. On little endian targets, the words are swapped, which just happens to look like the original constant. If the VIEW_CONVERT_EXPR is valid, manipulating it like a NaN seems valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704