From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23307 invoked by alias); 10 Jun 2009 07:50:25 -0000 Received: (qmail 23293 invoked by uid 22791); 10 Jun 2009 07:50:24 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_91,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-qy0-f194.google.com (HELO mail-qy0-f194.google.com) (209.85.221.194) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Jun 2009 07:50:18 +0000 Received: by qyk32 with SMTP id 32so865373qyk.0 for ; Wed, 10 Jun 2009 00:50:16 -0700 (PDT) Received: by 10.224.32.96 with SMTP id b32mr1454340qad.24.1244620216730; Wed, 10 Jun 2009 00:50:16 -0700 (PDT) Received: from yakj.usersys.redhat.com (nat-pool-brq.redhat.com [62.40.79.66]) by mx.google.com with ESMTPS id 8sm587164qwj.44.2009.06.10.00.50.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 00:50:15 -0700 (PDT) Message-ID: <4A2F65A9.3040006@gmail.com> Date: Wed, 10 Jun 2009 07:50:00 -0000 From: Paolo Bonzini User-Agent: Thunderbird 2.0.0.17 (X11/20081009) MIME-Version: 1.0 To: Bernd Roesch CC: gcc@gcc.gnu.org Subject: Re: gcc 4.4.0 error at postreload.c:396 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-06/txt/msg00229.txt.bz2 Bernd Roesch wrote: > Hi, > > I search gcc ML and find this. > > http://gcc.gnu.org/ml/gcc/2009-05/msg00413.html > > but here i have source with no 64 bit CPU. > is the fix now in and should i test current gcc4.4 ? The fix is machine-dependent (the message you quoted referred to the poster's proprietary port), so likely not. Please create a bugzilla entry and CC me. You will need a preprocessed file but it is easy to create one: just add --save-temps to the command line and you'll find that GCC now generates a mpegvideo.i file with the preprocessed sources. > I also like to know if there is possible to build a gcc with better error > messages ? > It show as error place last bracket of the function. Yes, it is not optimal. For front-end errors, gcc 4.5.0 will have better positions. For this kind of back-end error it is difficult to find a position because anyway the error depends on all the optimizations done so far, and it is only remotely connected to the source code. Paolo