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: libgcc/config.host pattern question


Hi Joel,

>> I suppose this happened in the course of my libgcc move patches for
> gcc
>> 4.7.  Unfortunately, almost no one responded to my call for testers
> in
>> that timeframe, so it must have gone unnoticed since.
>
> We noticed but could never track it down. It initially manifested as
> _host_t not being defined. We were reworking the standard types
> infrastructure for rtems+Newlib around that time to be more BSD
> compatible and assumed we broke it.  And we focused on debugging
> that.
>
> I recently added cpuset.h for pthread affinity and now the errors
> also showed that file missing from the include path. Much better
> clue.
>
> So we knew it broke but never considered it was a GCC and not Newlib
> bug. :(

I see, several changes going on at the same time ;-)

>> It's almost impossible to tell in general without a detailed
> analysis of
>> each individual case.  Unless a specific problem is noticed, I'd
> leave
>> it alone for now, especially given how late in the 4.9 cycle we
> are.
>
> Unfortunately I have to agree on 4.9. No proof of an issue. It occurs
> because the OS specific but target cpu independent settings are
> overridden.
>
> What about for the head?

As I said, I hope to revisit and finish my libgcc work during the next
cycle, and it's probably easiest to include it then when I'm doing
large scale testing anyway.

>> > On a style inconsistency note, I see that some stanzas use
> $tmake_file
>> > while
>> > most use ${tmake_file}. Is there a rule? Personally I like having
> {} and
>> > most
>> > appear to have it.
>>
>> True, there are many inconsistencies like this, and many more.  I
> still
>> have this stuff on my agenda for when I hope to resume and finish
> my
>> libgcc move work.  For the moment, I'd go with what is used in the
>> vicinity of a change you're going to make.
>
> I will submit a small patch but would you like one to add {} broader
> as a follow up?

Same here: I'd like to avoid too much churn at different times since it
makes back porting more difficult.  As I said, it's on my list already.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


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