delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2005/06/11/10:57:14

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Sat, 11 Jun 2005 16:57:13 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin <cygwin AT cygwin DOT com>
Subject: gcc 3.4.4 optimization problem (was Re: Negative stats from rsync with 20050610 snapshot)
Message-ID: <20050611145713.GA11065@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin <cygwin AT cygwin DOT com>
References: <42AA611A DOT 2050605 AT acm DOT org>
Mime-Version: 1.0
In-Reply-To: <42AA611A.2050605@acm.org>
User-Agent: Mutt/1.4.2i

On Jun 10 20:57, David Rothenberger wrote:
> rsync has started reported negative statistics with the 20050610 
> snapshot and a DLL I built from CVS HEAD today using gcc 3.4.4 and the 
> latest gcc-mingw release. Interestingly (to me, at least), it works 
> correctly with CVS HEAD built today using gcc 3.3.3 and the previous 
> gcc-mingw release.
> 
> Here's a test case.
> 
> % mkdir /tmp/{a,b}
> % date > /tmp/a/x
> % rsync -v --stats /tmp/a/x /tmp/b
> x
> 
> Number of files: 1
> Number of files transferred: 1
> Total file size: -29 bytes
> Total transferred file size: -29 bytes
> Literal data: -29 bytes
> Matched data: -0 bytes
> File list size: 20
> Total bytes sent: -105
> Total bytes received: -40

I found this to be a problem in gcc 3.4.x's -funit-at-a-time optimization.
I've also the vague feeling we already discussed this problem when Gerrit
released the first 3.4 based gcc for testing.

I'm far from being a gcc expert, but I recall that we had similar problem
once internally and switching off -funit-at-a-time optimization solved the
problem for us.  This was with some 3.4 derived gcc, but I don't know the
exact version number.  Anyway, switching off -funit-at-a-time when building
newlib also solves the above rsync problem.

Gerrit, could you please follow up on this?  It seems the simplest way is
to just switch off -funit-at-a-time for the -O2 optimization.  This is the
patch we applied internally, if that's of any help for you:

Index: gcc/opts.c
===================================================================
RCS file: /cvs/cvsfiles/gcc/opts.c,v
retrieving revision 1.3
diff -c -3 -p -r1.3 opts.c
*** gcc/opts.c  16 Mar 2004 01:43:58 -0000      1.3
--- gcc/opts.c  23 Jul 2004 14:03:41 -0000
*************** decode_options (unsigned int argc, const
*** 564,570 ****
        flag_delete_null_pointer_checks = 1;
        flag_reorder_blocks = 1;
        flag_reorder_functions = 1;
-       flag_unit_at_a_time = 1;
      }

    if (optimize >= 3)
--- 564,569 ----

Otherwise, do you know by any chance, if there exists some fix for that
problem?  The above kludge is almost a year old, so there's a chance
that somebody already found the fix.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019