From owner-svn-ports-all@FreeBSD.ORG  Mon Dec  3 11:24:13 2012
Return-Path: <owner-svn-ports-all@FreeBSD.ORG>
Delivered-To: svn-ports-all@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 1033)
 id D43DBF3B; Mon,  3 Dec 2012 11:24:13 +0000 (UTC)
Date: Mon, 3 Dec 2012 11:24:13 +0000
From: Alexey Dokuchaev <danfe@FreeBSD.org>
To: Pietro Cerutti <gahr@FreeBSD.org>
Subject: Re: svn commit: r308132 - head/audio/amrcoder
Message-ID: <20121203112413.GA32882@FreeBSD.org>
References: <201212031034.qB3AYpkL004754@svn.freebsd.org>
 <20121203105040.GA30670@FreeBSD.org>
 <20121203105616.GA86596@gahrfit.gahr.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <20121203105616.GA86596@gahrfit.gahr.ch>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org,
 ports-committers@freebsd.org
X-BeenThere: svn-ports-all@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: SVN commit messages for the ports tree <svn-ports-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/svn-ports-all>,
 <mailto:svn-ports-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-ports-all>
List-Post: <mailto:svn-ports-all@freebsd.org>
List-Help: <mailto:svn-ports-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-ports-all>,
 <mailto:svn-ports-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Dec 2012 11:24:13 -0000

On Mon, Dec 03, 2012 at 11:56:16AM +0100, Pietro Cerutti wrote:
> On 2012-Dec-03, 10:50, Alexey Dokuchaev wrote:
> > I recall this is not the first similar fix.  Is there reason not to uphold
> > ${CFLAGS} here instead?
> 
> CFLAGS as set by the user are used:
> 
> cc -O2 -pipe -fno-strict-aliasing  -O3 -I/src -DVAD1 -std=gnu99
> -Qunused-arguments -fstack-protector  -c decoder.c

-O3 (at least) is clearly bogus in this line.

> I see no reason, however, not to let the author supersede them with more
> appropriate flags.

Not too much software are written with clear mind about selected CFLAGS,
are well-tested and indeed the best (let say, vendor certified).  These are
special cases that required cooperation between maintainer and the upstream
and had to dealt on per-port basis.  We're not talking about these here.

Most often, however, folks just thow in -O3 or even -09 'cause they want
arbitrarily "the best" optimization and do not really care or know if doing
it improves anything for their program of not.

We should uphold our CFLAGS (that is, replace any unbridled optimization
options, not add to it) we're traditionally offering as sane and safe
defaults.

./danfe