From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18001 invoked by alias); 3 Sep 2009 21:50:26 -0000 Received: (qmail 17992 invoked by uid 22791); 3 Sep 2009 21:50:25 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Sep 2009 21:50:20 +0000 Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id n83LoGfk005630 for ; Thu, 3 Sep 2009 22:50:17 +0100 Received: from ywh7 (ywh7.prod.google.com [10.192.8.7]) by wpaz9.hot.corp.google.com with ESMTP id n83LoEAI026301 for ; Thu, 3 Sep 2009 14:50:14 -0700 Received: by ywh7 with SMTP id 7so625707ywh.21 for ; Thu, 03 Sep 2009 14:50:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.88.14 with SMTP id l14mr10545321ybb.346.1252014613973; Thu, 03 Sep 2009 14:50:13 -0700 (PDT) Date: Thu, 03 Sep 2009 21:50:00 -0000 Message-ID: Subject: store.exp failure on i686-linux with newer gcc's From: Doug Evans To: gdb Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00058.txt.bz2 Hi. Anyone working on this failure? FAIL: gdb.base/store.exp: var longest l; print new l, expecting -1 [should read "expecting 4", fixed in separate patch] FAIL: gdb.base/store.exp: var longest l; print incremented l, expecting 2 FAIL: gdb.base/store.exp: upvar longest l; print new l, expecting 4 FAIL: gdb.base/store.exp: var struct 4 u; print new u, expecting {s = \{1, 2, 3, 4}} FAIL: gdb.base/store.exp: up struct 4 u; print new u, expecting {s = \{1, 2, 3, 4}} Newer gcc's can store a 64 bit int in non-contiguous registers and use DW_OP_piece to mark each piece. value->lval is set to not_lval and value_assign doesn't like that so gdb refuses to set the variable with "Left operand of assignment is not an lvalue." It seems like we need to not mark the value as not_lval and teach the relevant pieces how to handle such values. Anyone thought about how they want this done?