This is the mail archive of the gcc@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: Unnecessary call to mark_temp_addr_taken in calls.c (related to pr25505)?

From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
To: stevenb dot gcc at gmail dot com
Cc: gcc at gcc dot gnu dot org, jconner at apple dot com
Date: Tue, 22 Aug 2006 14:57:05 EDT
Subject: Re: Unnecessary call to mark_temp_addr_taken in calls.c (related to pr25505)?
References: <44EA29D7.3090508@apple.com> <10608212253.AA25266@vlsi1.ultra.nyu.edu> <571f6b510608221141q3ad7ec64h39715b2388b1ff63@mail.gmail.com>

> And you did not add that test case, why?  Now there is a possible fix
> for a pretty ugly regression, and we can only *guess* why something is
> done the way it is???

As I said earlier, this came in as part of a merge of one tree to another
back in 1999, not as a separate patch, so you'd have to go back to the
archives of that tree to find the test case.

But if this is responsible for such a large regression in stack size, there's
clearly something else going on.  Why did this not matter in 3.4?  It wasn't
that this code was added and caused the regression since this was added well
before then.  Something *else* was added that caused the regression and we
need to understand what that was.

References:
- Unnecessary call to mark_temp_addr_taken in calls.c (related to pr25505)?
  - From: Josh Conner
- Re: Unnecessary call to mark_temp_addr_taken in calls.c (related to pr25505)?
  - From: Richard Kenner
- Re: Unnecessary call to mark_temp_addr_taken in calls.c (related to pr25505)?
  - From: Steven Bosscher

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