From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26160 invoked by alias); 26 Mar 2014 17:48:38 -0000 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 Received: (qmail 26110 invoked by uid 48); 26 Mar 2014 17:48:33 -0000 From: "ramana at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand Date: Wed, 26 Mar 2014 17:48:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: ramana at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ramana at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-03/txt/msg02442.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60655 --- Comment #7 from Ramana Radhakrishnan --- (In reply to Jakub Jelinek from comment #5) > As discussed yesterday with Ramana on IRC, my suggested fix for this for = 4.9 > is something like: > --- gcc/dwarf2out.c 2014-03-03 08:24:14.841895755 +0100 > +++ gcc/dwarf2out.c 2014-03-26 10:42:32.027508796 +0100 > @@ -11326,7 +11326,12 @@ const_ok_for_output_1 (rtx *rtlp, void * > } >=20=20 > if (GET_CODE (rtl) !=3D SYMBOL_REF) > - return 0; > + { > + /* NOT is not handled by output_addr_const. */ > + if (GET_CODE (rtl) =3D=3D NOT) > + return 1; > + return 0; > + } >=20=20 In addition looks like we need to handle=20 (minus (const_int) (sym_ref)) because with the reduced testcase with -g and removing the -fdata-sections I get an error with=20 const ( minus (323) (sym_ref)) and gas won't grok that because there is no relocation that will deal with this.=20 (note 220 219 221 5 (var_location r2 (plus:SI (plus:SI (reg:SI 3 r3 [orig:1= 92 ivtmp.37 ] [192]) (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])) (const:SI (minus:SI (const_int 323 [0x143]) (symbol_ref:SI ("*.LANCHOR0") [flags 0x182]))))) NOTE_INSN_VAR_LOCATION) Uggh this is proving to be more ugly. >>From gcc-bugs-return-447574-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 26 17:57:18 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 3683 invoked by alias); 26 Mar 2014 17:57:18 -0000 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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 3625 invoked by uid 55); 26 Mar 2014 17:57:12 -0000 From: "dave.anglin at bell dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor Date: Wed, 26 Mar 2014 17:57:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dave.anglin at bell dot net X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-03/txt/msg02443.txt.bz2 Content-length: 475 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #47 from dave.anglin at bell dot net --- On 3/26/2014 12:34 PM, dominiq at lps dot ens.fr wrote: > AFAICT on hppa*-*-hpux11* the E format does not round to nearest for tie. What > is the output of the following test > > #include "stdio.h" > int main() { > printf("%.1e %.1e\n", 9950.0, 9750.0); > return 0; > } > > ? On x86_64-apple-darwin13, I get '1.0e+04 9.8e+03'. You are correct: 9.9e+03 9.7e+03