This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: NM and AR not being used?

From: Jim Wilson <wilson at specifixinc dot com>
To: gcc-patches at gcc dot gnu dot org
Cc: Andreas Schwab <schwab at suse dot de>, Georg Schwarz <geos at epost dot de>
Date: Mon, 12 Jul 2004 19:27:25 -0700
Subject: Re: NM and AR not being used?
References: <E1Bidol-0000cS-D4@mikro.physik.TU-Berlin.DE> <1089523197.31944.17.camel@localhost> <jellhqna46.fsf@sykes.suse.de>

Andreas Schwab wrote:

Local makefile assignments always override values from the environment
(unless -e).  And since we null out MAKEOVERRIDES there are no implicit
command-line overrides passed down to recursive invocations.

Thanks for the explanation. I understand what is going on now.

I believe my suggested patch was the right approach given that explanation. I have tested it with an x86-linux bootstrap and make check. There was one libjava regression, but it appears to be a memory corruption problem with mainline. The testcase worked correctly when I ran it by hand.

Here is the one error I got: pr83.java:0: internal compiler error: virtual array basic_block_info[6]: element 2947526575 out of bounds in set_up_bb_rts_numbers, at global.c:2118 -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

References:
- Re: NM and AR not being used?
  - From: Jim Wilson
- Re: NM and AR not being used?
  - From: Andreas Schwab

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]