Done.
r279003.
- David
On Thu, Dec 5, 2019 at 9:33 AM Jakub Jelinek wrote:
>
> On Thu, Dec 05, 2019 at 09:25:40AM -0500, David Edelsohn wrote:
> > Sorry. I had to add tm_p.h because Jakub's earlier patch to add
> > output.h to cp-gimplify.c broke AIX.
> >
> > We certainly can add memmodel.h to
On Thu, Dec 05, 2019 at 09:25:40AM -0500, David Edelsohn wrote:
> Sorry. I had to add tm_p.h because Jakub's earlier patch to add
> output.h to cp-gimplify.c broke AIX.
>
> We certainly can add memmodel.h to cp-gimplify.c.
I'd say so. E.g. c-family/c-cppbuiltin.c which also includes output.h
inc
Sorry. I had to add tm_p.h because Jakub's earlier patch to add
output.h to cp-gimplify.c broke AIX.
We certainly can add memmodel.h to cp-gimplify.c.
Thanks, David
On Thu, Dec 5, 2019 at 8:32 AM Joseph Myers wrote:
>
> The change
>
> 2019-12-04 David Edelsohn
>
> * cp-gimplify.c: In
The change
2019-12-04 David Edelsohn
* cp-gimplify.c: Include tm_p.h.
appears to have broken the build for SPARC. I see
In file included from ./tm_p.h:4:0,
from
/scratch/jmyers/glibc-bot/src/gcc/gcc/cp/cp-gimplify.c:38:
/scratch/jmyers/glibc-bot/src/gcc/gcc/config/
From: David Miller
Date: Fri, 01 Jun 2012 13:50:48 -0400 (EDT)
> I hit the same problem, but solved it by removing the
> 'from' parameter entirely.
To move things forward I committed the following:
Restore Sparc build.
gcc/
* config/sparc/sparc.h (INITIAL_ELIMINAT
From: Rainer Orth
Date: Fri, 01 Jun 2012 18:01:45 +0200
> Steven Bosscher writes:
>
>> On Thu, May 31, 2012 at 11:15 PM, David Miller wrote:
>>>
>>> Removing output.h from reload1.c broke the sparc build because
>>> sparc's define of INITIAL_ELIMINATION_OFFSET (which is used in
>>> reload1.c)
Steven Bosscher writes:
> On Thu, May 31, 2012 at 11:15 PM, David Miller wrote:
>>
>> Removing output.h from reload1.c broke the sparc build because
>> sparc's define of INITIAL_ELIMINATION_OFFSET (which is used in
>> reload1.c) references current_function_is_leaf.
>
> I was afraid of some fall-
> I'm sure it works, but function calls are quite expensive on sparc.
I thought the whole business of the register windows was aimed at making them
quite cheap. :-) This one isn't performance critical anyway, so the fix is
fine I think (without the terminal 's' in "Implements" though).
--
Eri
From: Steven Bosscher
Date: Fri, 1 Jun 2012 01:00:37 +0200
> Besides, at least as far as I understand, it's sort-of a "design goal"
> for gcc to move from target macros to target hooks. So you're going to
> have to deal with some more calls anyway.
I understand, I'm just disappointed :-)
I'll t
On Fri, Jun 1, 2012 at 12:05 AM, David Miller wrote:
> From: Steven Bosscher
> Date: Thu, 31 May 2012 23:42:26 +0200
>
>> Could you please give the attached patch a try?
>> Sorry for the inconvenience!
>
> I'm sure it works, but function calls are quite expensive on
> sparc.
There are four elimi
From: Steven Bosscher
Date: Thu, 31 May 2012 23:42:26 +0200
> Could you please give the attached patch a try?
> Sorry for the inconvenience!
I'm sure it works, but function calls are quite expensive on
sparc.
On Thu, May 31, 2012 at 11:15 PM, David Miller wrote:
>
> Removing output.h from reload1.c broke the sparc build because
> sparc's define of INITIAL_ELIMINATION_OFFSET (which is used in
> reload1.c) references current_function_is_leaf.
I was afraid of some fall-out. This is why target macros must
Removing output.h from reload1.c broke the sparc build because
sparc's define of INITIAL_ELIMINATION_OFFSET (which is used in
reload1.c) references current_function_is_leaf.
13 matches
Mail list logo
