From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12400 invoked by alias); 16 Jan 2004 03:43:22 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12391 invoked from network); 16 Jan 2004 03:43:21 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 16 Jan 2004 03:43:21 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id TAA23136; Thu, 15 Jan 2004 19:43:08 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma023126; Thu, 15 Jan 04 19:42:38 -0800 Received: from claire.transmeta.com (claire.transmeta.com [10.10.25.31]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id i0G3gif12689; Thu, 15 Jan 2004 19:42:44 -0800 (PST) Received: (from dje@localhost) by claire.transmeta.com (8.11.6/8.11.6) id i0G3giL03304; Thu, 15 Jan 2004 19:42:44 -0800 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16391.23988.251985.754761@claire.transmeta.com> Date: Fri, 16 Jan 2004 03:43:00 -0000 To: Kazuhiro Inaoka Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: [PATCH] fix trap in parallel for m32r-sim In-Reply-To: <005301c3dbe1$6352c840$2569910a@tool.maec.co.jp> References: <005301c3dbe1$6352c840$2569910a@tool.maec.co.jp> X-SW-Source: 2004-01/txt/msg00404.txt.bz2 Kazuhiro Inaoka writes: > Hi Andrew, > > This is a patch for illegal trap operation in parallel. > > Please commit it. > > sim/m32r/ChangeLog > > 2004-01-16 Kazuhiro Inaoka < inaoka dot kazuhiro at renesas dot com > > > * mloopx.in (emit_parallel,emit_full_parallel,xextract-pbb): Fixed > trap operation in parallel. > * mloop2.in (emit_parallel,emit_full_parallel,xextract-pbb): Ditto. > > Regards, > > Kazuhiro Inaoka There's no documentation here that indicates why things are being done the way they are. If it were my call, I would require more comments. i.e. _why_ is "trap || insn" being treated as "insn -> trap". This seems like an erroneous thing to do at first glance, ergo the need for comments explaining why things are the way they are. Does h/w really work that way? Also, if things are indeed kosher, why the added FIXMEs? Also, nit: it's unfortunate that instructions are being specified as magic numbers, but that can be fixed later.