This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libgcc/config.host pattern question
- From: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- To: Joel Sherrill <Joel dot Sherrill at OARcorp dot com>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Thu, 20 Mar 2014 13:41:10 +0100
- Subject: Re: libgcc/config.host pattern question
- Authentication-results: sourceware.org; auth=none
- References: <84DFB03DEB1A9C49AC40B1F3F18E72B104BC6EAFFA5E at OARmail dot OARCORP dot com>
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