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: Bootstrap failures on ToT, changes with no ChangeLog entry?


On Thu, Jul 24, 2008 at 09:35:26AM -0700, Steve Ellcey wrote:
> 
> All of my bootstraps except x86 Linux failed last night.   Both 
> HP-UX builds and my IA64 Linux build.  This was with version 
> 138102.  I tried to find out when the failure started and ran
> into some odd things.  If I go back to version 138070 and
> then update my tree to 138076 I see a bunch of files in trunk/gcc
> that are changed but ChangeLog does get changed during this
> update.
> 
> I do get the failure with version 138076, I am still testing
> 138070.
> 
> Is anyone else seeing bootstrap failures with ToT?  Does anyone
> know what is going on with ChangeLog?
> 
> I also tried updating to 138077 at one point and that version number
> doesnt' seem to exist:
> 
> 	$ svn update -r138077
> 	svn: Target path does not exist
> 
> At least I think that is what this error means.
> 
> What is going on?
> 
> Steve Ellcey
> sje@cup.hp.com

I made two mistakes when I submitted the function specific patch (138075).  The
first mistake was I was trying to move the current tree to the branch, and
accidently deleted the trunk instead of the branch (138077), and fixed this by
copying 138076 back to the trunk and submitted it as 138078.  Then I discovered
that I had not submitted the ChangeLog as part of 138075, and submitted that
afterwards (the changelog entry was in the patch sent to gcc-patches).

I submitted another patch yesterday that fixed building objective C libraries.

I'm working on a fix for the IA-64 right now, and the IA-64 fix will likely
need to be replicated in the other ports that define OVERRIDE_OPTIONS
(basically a lot of ports do lots of stuff in OVERRIDE_OPTIONS, but the
hot/cold attribute stuff which now calls the optimzie attribute, which in turn
needs to call the parts of OVERRIDE_OPTIONS that are safe to do more than once
(adding a SECONDARY_OVERRIDE_OPTIONS).

Mea culpa.  I'm sorry for problems I've caused with the addition of function
specific optimizations.

-- 
Michael Meissner
email: gnu@the-meissners.org
http://www.the-meissners.org


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