Re: Dealing with compilers that pretend to be GCC

2012-01-20 Thread Dave Korn 
On 20/01/2012 11:19, Peter Rosin wrote:
 Dave Korn skrev 2012-01-20 01:15:
 
 *snip*
 
That could be tricky because I guess you won't be able to use
 libtool at configure time.
 
 *snip*
 
 It's possible to use libtool at configure time, but you need to invoke
 LT_OUTPUT before you do so.  Or is there a reason for that not to work
 in this case?

  Not as far as I know, I just wasn't aware that you could generate the output
script early.

cheers,
  DaveK

Re: r150960 changed ltmain.sh and broke the build

2009-08-26 Thread Dave Korn 
Ralf Wildenhues wrote:
 [ trimmed Cc:, added autoconf-patches; followups can remove gcc@ ]
 [ http://thread.gmane.org/gmane.comp.gcc.devel/108348 ]
 
 * Dave Korn wrote on Wed, Aug 26, 2009 at 08:16:11PM CEST:
 Ralf Wildenhues wrote:
  Patterns should not include the separator (unless escaped), even
  as part of a character class.  In conformance with Posix, the Cray
  `sed' rejects `s/[^/]*$//': use `s,[^/]*$,,'.
 [...]
  Portable `sed' regular expressions should use `\' only to escape
  characters in the string `$()*.0123456789[\^n{}'.
   Ah, I didn't read those two conditions as applying simultaneously.
 
 I don't think they apply simultaneously in the way you interpreted that.
 However, in the  s,x\{1\,\},y,  example, the comma is both a separator
 and another metacharacter.

  That seems strange to me, are you saying the comma is a metachar because it
is a component of the curly-brace number-of-repetitions modifier?

  Hmm, maybe those sentences don't really cover this case.
 
 How about
 
  Patterns should not include the separator (unless escaped), even
  as part of a character class.  In conformance with Posix, the Cray
  `sed' rejects `s/[^/]*$//': use `s,[^/]*$,,'.  Even escaped,
  patterns should not include separators that are also used as
  metacharacters.  For example, GNU sed 3.02 rejects `s,x\{1\,\},,',
  and is used on MinGW.

  Well, modulo my surprise that a comma is considered a metachar, that makes
sense.

cheers,
  DaveK

RE: changing configure to default to gcc -g -O2 -fwrapv ...

2006-12-30 Thread Dave Korn 
On 30 December 2006 11:49, Robert Dewar wrote:

 Paul Eggert wrote:
 Nor would I relish the prospect of keeping wrapv assumptions out of
 GCC as other developers make further contributions, as the wrapv
 assumption is so natural and pervasive.
 It's neither natural not pervasive to me!  I would never write code
 that way
 
 That's great, but GCC has had many other hands stirring the pot.
 I daresay a careful scan would come up with many other examples of
 undefined behavior due to signed integer overflow.  (No doubt
 you'll be appalled by them as well, but there they are.)
 
 Not so appalling really, given that relying on wrapping is as
 has been pointed out in this thread, the most natural and
 convenient way of testing for overflow. It is really *quite*
 difficult to test for overflow while avoiding overflow, and
 this is something that is probably not in the lexicon of
 many C programmers.

  Maybe the answer (as far as autoconf goes) is that autoconf tests should be
compiled at -O0.  They are trying to determine the underlying machine
behaviour; -O0 makes gcc more like the glorified-assembler model of a
compiler.  Which is probably what we want; the code to actually execute on the
target, not for the compiler to deduce what it would do if it did run and
maybe get it wrong.

  (Maybe they could be compiled at -O0 *and* at -O2, and the results compared,
to infer overflow behaviour and decide whether to add -fwrapv to the generated
CFLAGS?)

cheers,
  DaveK
-- 
Can't think of a witty .sigline today