r150960 changed ltmain.sh and broke the build

[NightStrike]

Dave,

You checked in r150960 here:
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00642.html

This change affected ltmain.sh:
http://gcc.gnu.org/viewcvs/trunk/ltmain.sh?r1=150960&r2=150959&pathrev=150960

All of those changes to sed now make sed fail miserably on any mingw
host during the build:

libtool: link: 
/c/buildbot/vista64-mingw32/mingw-x86-x86/build/build/root/i686-w64-mingw32/bin/ar
rc .libs/libssp.a  ssp.o gets-chk.o memcpy-chk.o memmove-chk.o
mempcpy-chk.o memset-chk.o snprintf-chk.o sprintf-chk.o stpcpy-chk.o
strcat-chk.o strcpy-chk.o strncat-chk.o strncpy-chk.o vsnprintf-chk.o
vsprintf-chk.o
libtool: link: 
/c/buildbot/vista64-mingw32/mingw-x86-x86/build/build/root/i686-w64-mingw32/bin/ranlib
.libs/libssp.a
/bin/sed: -e expression #2, char 22: Invalid content of \{\}

Re: r150960 changed ltmain.sh and broke the build

[Dave Korn]

NightStrike wrote:
> Dave,
> 
> You checked in r150960 here:
> http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00642.html
> 
> This change affected ltmain.sh:
> http://gcc.gnu.org/viewcvs/trunk/ltmain.sh?r1=150960&r2=150959&pathrev=150960
> 
> All of those changes to sed now make sed fail miserably on any mingw
> host during the build:
> 
> libtool: link: 
> /c/buildbot/vista64-mingw32/mingw-x86-x86/build/build/root/i686-w64-mingw32/bin/ar
> rc .libs/libssp.a  ssp.o gets-chk.o memcpy-chk.o memmove-chk.o
> mempcpy-chk.o memset-chk.o snprintf-chk.o sprintf-chk.o stpcpy-chk.o
> strcat-chk.o strcpy-chk.o strncat-chk.o strncpy-chk.o vsnprintf-chk.o
> vsprintf-chk.o
> libtool: link: 
> /c/buildbot/vista64-mingw32/mingw-x86-x86/build/build/root/i686-w64-mingw32/bin/ranlib
> .libs/libssp.a
> /bin/sed: -e expression #2, char 22: Invalid content of \{\}

  Argh.  Very sorry for the breakage, I'll get straight onto it.  What
versions of the mingw+msys tools are you using?  Can you please send me a copy
of the generated libtool script, and the output you get when re-running the
failing libtool command manually after adding the "--debug" (non-modal) option?

cheers,
  DaveK

Re: r150960 changed ltmain.sh and broke the build

[Paolo Bonzini]

   Argh.  Very sorry for the breakage, I'll get straight onto it.  What
versions of the mingw+msys tools are you using?  Can you please send me a copy
of the generated libtool script, and the output you get when re-running the
failing libtool command manually after adding the "--debug" (non-modal) option?


This is the problem:

 removedotparts="s,/\(\./\)\{1\,\},/,g;s,/\.$,/,"

\, should be , (there is another occurrence).

Also please single-quote the commands.

Paolo

Re: r150960 changed ltmain.sh and broke the build

[Dave Korn]

Paolo Bonzini wrote:
>>Argh.  Very sorry for the breakage, I'll get straight onto it.  What
>> versions of the mingw+msys tools are you using?  Can you please send
>> me a copy
>> of the generated libtool script, and the output you get when
>> re-running the
>> failing libtool command manually after adding the "--debug"
>> (non-modal) option?
> 
> This is the problem:
> 
>  removedotparts="s,/\(\./\)\{1\,\},/,g;s,/\.$,/,"
> 
> \, should be , (there is another occurrence).

  Oops.  Looks like there are different versions of SED that have different
requirements, because on cygwin SED 4.1.5, you *have* to quote the comma in
the curly-braces {min,max} repetitions specifier or it is interpreted as a
separator.

> $ sed -e 's,/\(\./\)\{1\,\},/,g;s,/\.$,/,'
> ./foo/bar/./baz
> ./foo/bar/baz
> 
> $ sed -e 's,/\(\./\)\{1,\},/,g;s,/\.$,/,'
> sed: -e expression #1, char 18: unknown option to `s'
> 
> $

  Maybe the best thing would be to change it to use a different separator?
Ralf, have we discovered a new item for the autoconf man page "portable shell"
chapter?

> Also please single-quote the commands.

  Ok, why?

cheers,
  DaveK

Re: r150960 changed ltmain.sh and broke the build

[Paolo Bonzini]

On 08/26/2009 12:38 PM, Dave Korn wrote:

   Oops.  Looks like there are different versions of SED that have different
requirements, because on cygwin SED 4.1.5, you*have*  to quote the comma in
the curly-braces {min,max} repetitions specifier or it is interpreted as a
separator.


Right.  I also got bitten by this recently (and I should have known 
better, given my sed maintainer hat).  You should use another separator 
to be portable.


Paolo

Re: r150960 changed ltmain.sh and broke the build

[Dave Korn]

Dave Korn wrote:

>> Also please single-quote the commands.
> 
>   Ok, why?

  BTW should I do that for all four of the patterns?  And what about $dirname
and $basename, and the couple of dozen other locations in ltmain.sh that use
quoted sed scripts?  (You didn't answer my question about "why" yet so I can't
infer anything.)

cheers,
  DaveK

Re: r150960 changed ltmain.sh and broke the build

[Paolo Bonzini]

On 08/26/2009 12:48 PM, Dave Korn wrote:

Dave Korn wrote:


Also please single-quote the commands.


   Ok, why?


   BTW should I do that for all four of the patterns?  And what about $dirname
and $basename, and the couple of dozen other locations in ltmain.sh that use
quoted sed scripts?  (You didn't answer my question about "why" yet so I can't
infer anything.)


I don't like very much backslash sequences in double-quoted variables. 
It's portable, but somewhat unintuitive.  But this is upstream code 
after all, so it's better to leave it alone.  Sorry for the false alarm.


Paolo

Re: r150960 changed ltmain.sh and broke the build

[Dave Korn]

Paolo Bonzini wrote:
> On 08/26/2009 12:48 PM, Dave Korn wrote:
>> Dave Korn wrote:
>>
 Also please single-quote the commands.
>>>
>>>Ok, why?
>>
>>BTW should I do that for all four of the patterns?  And what about
>> $dirname
>> and $basename, and the couple of dozen other locations in ltmain.sh
>> that use
>> quoted sed scripts?  (You didn't answer my question about "why" yet so
>> I can't
>> infer anything.)
> 
> I don't like very much backslash sequences in double-quoted variables.
> It's portable, but somewhat unintuitive.  But this is upstream code
> after all, so it's better to leave it alone.  Sorry for the false alarm.

  No problem, thanks for worrying about it.  Are there any particular
recommendations about/against problematic separator characters in the 's'
command?  I was going to use an '@'.

cheers,
  DaveK

Re: Trying to backport alias fix to 4.2

[Ned Gill]

FWIW, I'm still looking at this on and off.  I beleive the pure function  
was a red herring, as this example also does the wrong thing:


extern int z;

int foo(int *y)
{
z = 1;
*y = 0;
return z;  // returns 1, even though y could point to z :(
}

Not much joy tracking it down as yet.  I've attached the alias information  
tree dump in case anyone fancies a look.  It looks ok to me, but I don't  
really understand it fully.


As a reminder: this bug is fixed from r119502 on trunk. I'd like to fix it  
on 4.2.x.



Ned.


--


bbb.c.030t.alias1
Description: Binary data

Re: Trying to backport alias fix to 4.2

[Richard Guenther]

On Wed, Aug 26, 2009 at 12:50 PM, Ned Gill wrote:
>
> FWIW, I'm still looking at this on and off.  I beleive the pure function was
> a red herring, as this example also does the wrong thing:
>
> extern int z;
>
> int foo(int *y)
> {
>    z = 1;
>    *y = 0;
>    return z;  // returns 1, even though y could point to z :(
> }
>
> Not much joy tracking it down as yet.  I've attached the alias information
> tree dump in case anyone fancies a look.  It looks ok to me, but I don't
> really understand it fully.
>
> As a reminder: this bug is fixed from r119502 on trunk. I'd like to fix it
> on 4.2.x.

Sorry, you are hitting some major latent problems there.  The
affected piece got a complete rewrite for 4.3, an isolated fix is likely
not easily possible.  The above problem is that NONLOCAL is
broken - it should have used the SMT for anything instead.

The code in 4.4 is somewhat sane, still corner cases are incorrect
there, hopefully fixed on trunk.

Richard.

>
> Ned.
>
>
> --
>

Why no strings in error messages?

[Bradley Lucier]

I've never seen the answer to the following question:  Why do some  
versions of gcc that I build not have string substitutions in error  
messages?


I get things like this:

[luc...@lambda-head lib]$ /pkgs/gcc-mainline/bin/gcc -mcpu=970 -m64 - 
fschedule-insns -Wno-unused -O1 -fno-math-errno -fschedule-insns2 - 
fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer - 
fPIC -fno-common -I"../include" -c _thread-test.i -save-temps

_thread.c: In function â:
_thread.c:10035:146: error: â undeclared (first use in this function)
_thread.c:10035:146: error: (Each undeclared identifier is reported  
only once

_thread.c:10035:146: error: for each function it appears in.)

It makes cutting down a test case for a bug report a bit of guess and  
hack.


And an unrelated question:  I've found on some tests on x86-64 that - 
fschedule-insns added to -O1 speeds up some of my codes impressively,  
but on x86-64-linux and powerpc64-linux I've had problems finding  
spill registers and I've also been getting stuff like


/pkgs/gcc-mainline/bin/gcc -mcpu=970 -m64 -fschedule-insns -save- 
temps -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping- 
math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno- 
common   -I"../include" -c -o "_thread.o" -I. -DHAVE_CONFIG_H - 
D___GAMBCDIR="\"/usr/local/Gambit-C\"" -D___SYS_TYPE_CPU="\"powerpc64 
\"" -D___SYS_TYPE_VENDOR="\"unknown\"" -D___SYS_TYPE_OS="\"linux-gnu 
\"" -D___CONFIGURE_COMMAND="\"./configure CC=/pkgs/gcc-mainline/bin/ 
gcc -mcpu=970 -m64 -fschedule-insns\"" -D___OBJ_EXTENSION="\".o\"" - 
D___EXE_EXTENSION="\"\"" -D___PRIMAL _thread.c -D___LIBRARY

_thread.c: In function â:
_thread.c:15556:1: error: insn does not satisfy its constraints:
(insn 614 220 216 26 _thread.c:15462 (set (reg:DF 20 20)
(mem:DF (plus:DI (reg:DI 23 23 [orig:199 D.20368 ] [199])
(const_int 23 [0x17])) [0 S8 A64])) 357  
{*movdf_hardfloat64} (nil))
_thread.c:15556:1: internal compiler error: in  
reload_cse_simplify_operands, at postreload.c:396


Actually, I haven't been able to get Gambit to build on any  
architecture I've tried with -fschedule-insns on the command line.


So, is -fschedule-insns an option to be avoided?

Brad

Re: Why no strings in error messages?

[Ian Lance Taylor]

Bradley Lucier  writes:

> I've never seen the answer to the following question:  Why do some
> versions of gcc that I build not have string substitutions in error
> messages?

Perhaps you configured with --disable-intl?


> So, is -fschedule-insns an option to be avoided?

-fschedule-insns should be avoided on Intel architectures.  In general
-fschedule-insns tends to increase register lifespan, and because of the
small number of available registers this can sometimes befuddle the
register allocator, especially when asm instructions as used.

On PPC -fschedule-insns is normally beneficial, and it is turned on by
-O2.

Ian

Re: Why no strings in error messages?

[Richard Earnshaw]

On Wed, 2009-08-26 at 09:00 -0400, Bradley Lucier wrote:
> I've never seen the answer to the following question:  Why do some  
> versions of gcc that I build not have string substitutions in error  
> messages?
> 
> I get things like this:
> 
> [luc...@lambda-head lib]$ /pkgs/gcc-mainline/bin/gcc -mcpu=970 -m64 - 
> fschedule-insns -Wno-unused -O1 -fno-math-errno -fschedule-insns2 - 
> fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer - 
> fPIC -fno-common -I"../include" -c _thread-test.i -save-temps
> _thread.c: In function â:
> _thread.c:10035:146: error: â undeclared (first use in this function)
> _thread.c:10035:146: error: (Each undeclared identifier is reported  
> only once
> _thread.c:10035:146: error: for each function it appears in.)

Your locale is set up to generate something your terminal can't display
properly (I've seen this myself).

Either fix your terminal to display the extended char-set properly, or
run your compiler with a simpler locale, eg:

export LANG=c
gcc ...

should do the trick.

If you want to prove to yourself that the variables are there pass the
output through 'od -c'

R.

GNU MPFR 2.4.2 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 2.4.2 ("andouillette sauce moutarde"
patch level 2) is imminent. Please help to make this release
as good as possible by downloading and testing this release
candidate:

http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc1.tar.xz
http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc1.tar.bz2
http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc1.tar.gz
http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc1.zip

The MD5's:
e60d4aa71db3822e5ef92aa0720a05b8  mpfr-2.4.2-rc1.tar.xz
43b040a2203174824b7833eeb5a47a8a  mpfr-2.4.2-rc1.tar.bz2
abae0b7776520332d9df36b5ffcee664  mpfr-2.4.2-rc1.tar.gz
544083466e8a2f2c615e015fb3044334  mpfr-2.4.2-rc1.zip

The signatures:
http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc1.tar.xz.asc
http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc1.tar.bz2.asc
http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc1.tar.gz.asc
http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc1.zip.asc

Changes from version 2.4.1 to version 2.4.2:
- Security fix in formatted output functions (buffer overflow).
- Formatted output functions: 6 is now the default value for
  empty precision field with %Rf.
- Better portability of configure script.
- Detection of intmax_t and uintmax_t types.
- Improved documentation: mpfr_get_z_exp, mpfr_strtofr, mpfr_get_str and
  formatted output functions.
- Improved message in case of assertion failure.
- Test coverage: 97.0% lines of code.
- Updated tcmp_ld test to really test the long double.
- Some documentation files are installed in $docdir.
- Bug fixes.

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 2.4.2 should be released
around 2009-09-09.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Why no strings in error messages?

[Michael Meissner]

On Wed, Aug 26, 2009 at 06:30:44AM -0700, Ian Lance Taylor wrote:
> Bradley Lucier  writes:
> 
> > I've never seen the answer to the following question:  Why do some
> > versions of gcc that I build not have string substitutions in error
> > messages?
> 
> Perhaps you configured with --disable-intl?
> 
> 
> > So, is -fschedule-insns an option to be avoided?
> 
> -fschedule-insns should be avoided on Intel architectures.  In general
> -fschedule-insns tends to increase register lifespan, and because of the
> small number of available registers this can sometimes befuddle the
> register allocator, especially when asm instructions as used.

When I worked at AMD, I was starting to suspect that it may be more beneficial
to re-enable the first schedule insns pass if you were compiling in 64-bit
mode, since you have more registers available, and the new registers do not
have hard wired uses, which in the past always meant a lot of spills (also, the
default floating point unit is SSE instead of the x87 stack).  I never got
around to testing this before AMD and I parted company.

> On PPC -fschedule-insns is normally beneficial, and it is turned on by
> -O2.
> 
> Ian

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meiss...@linux.vnet.ibm.com

Re: GNU MPFR 2.4.2 Release Candidate

[Vincent Lefevre]

On 2009-08-26 18:10:24 +0200, Vincent Lefevre wrote:
> The release of GNU MPFR 2.4.2 ("andouillette sauce moutarde"
> patch level 2) is imminent. Please help to make this release
> as good as possible by downloading and testing this release
> candidate:
[...]

Note: I've just got a report saying that the build may fail on
some platforms because of a

//exit (1);

in tests/tsprintf.c; it is sufficient to remove the "//"
(I forgot to do that before a commit). Sorry.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: [gnat] reuse of ASTs already constructed

[Oliver Kellogg]

I've been making progress on the Ada side, the basic usage pattern for
gnat1 and gnatmake is working.

There are two problems right now:

1) Mixing of Ada.Text_IO and Text_IO as described at
   http://gcc.gnu.org/ml/gcc-help/2009-08/msg00113.html

2) The 'X' lines in the ALI files are not what they should be.
This is due to the fact that Lib.Xref.Generate_(Definition|Reference) is
called during semantic analysis. However, when I discover that a
tree was already built for a main unit by a previous compilation,
Sem is not redone for that tree. Depending on whether
Lib.Xref.Initialize is called per-job or per-file, this leads to either
too much or too little cross ref info.

Ideas?

Thanks,

 Oliver


On Thu, 2009-07-02 at 00:23 +0200, Oliver Kellogg wrote:
> I am approaching the point where the basic multi-source mechanism
> in the gnat1/gnatmake Ada code is working but I am getting
> lots of crashes in the gigi/gnat_to_gnu triggered core gcc code.
> I will have to learn much more about the GCC internals than
> I know right now so progress will inevitably be slow.
> 
> For your information I am appending the current patch that
> I am using, as well as a log of a valgrind session that shows
> some of the current problems.
> 
> On Wed, 2009-04-22 at 18:22 -0400, Robert Dewar wrote:
> > Oliver Kellogg wrote:
> > > [...]
> > > One more thing, procedure Initialize crashes with a libc report of
> > > double free() when invoked more than once. (Found this while
> > > working on the gnat1 multi-source compile feature, see
> > > http://gcc.gnu.org/ml/gcc/2009-04/msg00380.html)
> > > FYI I'm attaching the patch that works for me.
> > 
> > gnat1 does not have the capability of compiling more than one
> > source file without being loaded, yes there is some preparation
> > for this, but it would require major work to get this working,
> > there are many known problems.
> 
> For interest, what are the known problems?
> 
> Thanks,
> 
> Oliver
> 

Re: r150960 changed ltmain.sh and broke the build

[Ralf Wildenhues]

* Dave Korn wrote on Wed, Aug 26, 2009 at 12:38:50PM CEST:
> Paolo Bonzini wrote:
> > $ sed -e 's,/\(\./\)\{1\,\},/,g;s,/\.$,/,'
> > ./foo/bar/./baz
> > ./foo/bar/baz
> > 
> > $ sed -e 's,/\(\./\)\{1,\},/,g;s,/\.$,/,'
> > sed: -e expression #1, char 18: unknown option to `s'
> > 
> > $
> 
>   Maybe the best thing would be to change it to use a different separator?
> Ralf, have we discovered a new item for the autoconf man page "portable shell"
> chapter?

Not really:

 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{}'.

Sorry for not catching this.

Cheers,
Ralf

Re: r150960 changed ltmain.sh and broke the build

[Dave Korn]

Ralf Wildenhues wrote:
> * Dave Korn wrote on Wed, Aug 26, 2009 at 12:38:50PM CEST:

>> Ralf, have we discovered a new item for the autoconf man page "portable 
>> shell"
>> chapter?
> 
> Not really:
> 
>  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.  Since
the second condition essentially says that you must only ever escape a special
character to make it non-meaningful or a normal character to make it special,
maybe the first condition say something a bit more like ...

>   Patterns should not include the separator (not even escaped, unless
>   you fancy having to use a semantically significant metacharacter for
>   your separator), even as part of a ...

... shouldn't it?

> Sorry for not catching this.

  NP, all fixed now :)

cheers,
  DaveK

Re: r150960 changed ltmain.sh and broke the build

[Ralf Wildenhues]

[ 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.  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.

?

Cheers,
Ralf

Re: r150960 changed ltmain.sh and broke the build

[Paolo Bonzini]

  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.  Since
the second condition essentially says that you must only ever escape a special
character to make it non-meaningful or a normal character to make it special,
maybe the first condition say something a bit more like ...


   Patterns should not include the separator (not even escaped, unless
   you fancy having to use a semantically significant metacharacter for
   your separator), even as part of a ...


No.  The problem is exactly when you use a semantically significant 
metacharacter for your separator.


\*   => unportable, a\* may become either a* or a\*
\>   => unportable, a\> may become either a> or a\>
\$   => unportable, a\$ may become either a$ or a\$
\,   => unportable, part of \{a,b\}
\|   => unportable, a\|b may become either a|b or a\|b and the latter
may be parsed as alternation
\/   => in theory unportable in practice it would be insane to introduce
a special sequence \/
\@ \: etc. => in theory unportable, in practice they should be fine.

All of these are forbidden by the wording in Autoconf manual.

One could add / to the list in the second paragraph, and saying 
something like "only / should be used as a separator if you wish to 
escape it, to avoid inadvertent introduction or escaping of regular 
expression operators".


Or even better, it should be left as is.

Paolo

Re: Why no strings in error messages?

[Paolo Bonzini]

When I worked at AMD, I was starting to suspect that it may be more beneficial
to re-enable the first schedule insns pass if you were compiling in 64-bit
mode, since you have more registers available, and the new registers do not
have hard wired uses, which in the past always meant a lot of spills (also, the
default floating point unit is SSE instead of the x87 stack).  I never got
around to testing this before AMD and I parted company.


Unfortunately, hardwired use of %ecx for shifts is still enough to kill 
-fschedule-insns on AMD64.


Paolo

Re: r150960 changed ltmain.sh and broke the build

[Dave Korn]

Paolo Bonzini wrote:

>>>Patterns should not include the separator (not even escaped, unless
>>>you fancy having to use a semantically significant metacharacter for
>>>your separator), even as part of a ...
> 
> No.  The problem is exactly when you use a semantically significant
> metacharacter for your separator.

  The wording "not even escaped, unless you fancy having to ..." was
rhetorical understatement; the idea is that "having to use ..." is not
something that anyone would fancy doing.  I wasn't suggesting a literal
wording, which is why I wrote "something a bit more like".  Sorry for the
confusing linguistics!

cheers,
  DaveK

Re: Why no strings in error messages?

[Bradley Lucier]

On Wed, 2009-08-26 at 20:38 +0200, Paolo Bonzini wrote:
> 
> > When I worked at AMD, I was starting to suspect that it may be more 
> > beneficial
> > to re-enable the first schedule insns pass if you were compiling in 64-bit
> > mode, since you have more registers available, and the new registers do not
> > have hard wired uses, which in the past always meant a lot of spills (also, 
> > the
> > default floating point unit is SSE instead of the x87 stack).  I never got
> > around to testing this before AMD and I parted company.
> 
> Unfortunately, hardwired use of %ecx for shifts is still enough to kill 
> -fschedule-insns on AMD64.

The AMD64 Architecture manual I found said that various combinations of
the RSI, RDI, and RCX registers are used implicitly by ten instructions
or prefixes, and RBX is used by XLAT, XLATB.  So it appears that there
are 12 general-purpose registers available for allocation.

Are 12 registers not enough, in principle, to do scheduling before
register allocation?  I was getting a 15% speedup on some numerical
codes, as pre-scheduling spaced out the vector loads among the
floating-point computations.

Brad

Re: i370 port

[Henrik Sorensen]

On Sunday 23 August 2009 04.27:11 Paul Edwards wrote:
>
> Jujitsu are pleased to announce the release of the
> following software:
>
> GCC 3.2.3 MVS 7.5 - GCC C compiler for z/OS, MVS/380, MVS/370.
> GCC 3.2.3 CMS 7.5 - GCC C compiler for z/VM, VM/380, VM/370.
> PDPCLIB 2.00 - C (C90-compliant) runtime library for MVS
> Hercules/380 3.06 v6.0 - Used to run MVS/380. It now does

Hi Paul

Congrats !!

good to see you are making progress, and also getting feedback on the 
gcc-list.
> BFN.  Paul.
Henrik

Re: [gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx

[Jason Merrill]

On 08/03/2009 04:09 PM, Pedro Lamarão wrote:

Current trunk (revision 150381) fails to bootstrap with the following
configuration:



.../../trunk/libcpp/../include/libiberty.h:106: error: new declaration
‘char* basename(const char*)’
/usr/include/string.h:601: error: ambiguates old declaration ‘const
char* basename(const char*)’


The problem is that AC_CHECK_DECLS gets confused by overloaded 
functions, and glibc 2.10 has overloaded declarations of basename and 
some other string functions for const-correctness.


Jason

Re: IRA undoing scheduling decisions

[Peter Bergner]

On Mon, 2009-08-24 at 23:56 +, Charles J. Tabony wrote:
> I am seeing a performance regression on the port I maintain, and I would 
> appreciate some pointers.
> 
> When I compile the following code
> 
> void f(int *x, int *y){
>   *x = 7;
>   *y = 4;
> }
> 
> with GCC 4.3.2, I get the desired sequence of instructions.  I'll call it 
> sequence A:
> 
> r0 = 7
> r1 = 4
> [x] = r0
> [y] = r1
> 
> When I compile the same code with GCC 4.4.0, I get a sequence that is lower 
> performance for my target machine.  I'll call it sequence B:
> 
> r0 = 7
> [x] = r0
> r0 = 4
> [y] = r0

This is caused by update_equiv_regs() which IRA inherited from local-alloc.c.
Although with gcc 4.3 and earlier, you don't see the problem, it is still there,
because if you look at the 4.3 dumps, you will see that update_equiv_regs()
unordered them for us.  What is saving us is that sched2 reschedules them
again for us in the order we want.  With 4.4, IRA happens to reuse the same
register for both pseudos, so sched2 is hand tied and cannot schedule them
back again for us.

Looking at update_equiv_regs(), if I disable the replacement for regs
that are local to one basic block (patch below) like it existed before
John Wehle's patch way back in Oct 2000:

  http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00782.html

then we get the ordering we want.  Does anyone know why John removed
that part of the test in his patch?  Thoughts anyone?


Peter


Index: ira.c
===
--- ira.c   (revision 15)
+++ ira.c   (working copy)
@@ -2510,6 +2510,7 @@ update_equiv_regs (void)
 calls.  */
 
  if (REG_N_REFS (regno) == 2
+ && REG_BASIC_BLOCK (regno) < NUM_FIXED_BLOCKS
  && (rtx_equal_p (x, src)
  || ! equiv_init_varies_p (src))
  && NONJUMP_INSN_P (insn)

Include statement in your gnu free fortran 77 compiler

[gjalkanen]

To whom it may be concerned:

I have a quick question on the useage of your gnu free
fortran compiler.  I have written fortran code for 
microsoft fortran compiler version 5.1 and use an include
statement in my code.  In this compiler, the include
statement starts with a $ letter.  I think they call these
commands metacommands.  Is this the same in your gnu free
fortran compiler, or is the include statement just
include "filename.ext" with filename.ext the include file
to be inserted into the code at this location.

Thanks

Gerald "Jerry" Jalkanen


Discover Pasty.net - http://www.pasty.net

Re: IRA undoing scheduling decisions

[Richard Guenther]

On Wed, Aug 26, 2009 at 10:47 PM, Peter Bergner wrote:
> On Mon, 2009-08-24 at 23:56 +, Charles J. Tabony wrote:
>> I am seeing a performance regression on the port I maintain, and I would 
>> appreciate some pointers.
>>
>> When I compile the following code
>>
>> void f(int *x, int *y){
>>   *x = 7;
>>   *y = 4;
>> }
>>
>> with GCC 4.3.2, I get the desired sequence of instructions.  I'll call it 
>> sequence A:
>>
>> r0 = 7
>> r1 = 4
>> [x] = r0
>> [y] = r1
>>
>> When I compile the same code with GCC 4.4.0, I get a sequence that is lower 
>> performance for my target machine.  I'll call it sequence B:
>>
>> r0 = 7
>> [x] = r0
>> r0 = 4
>> [y] = r0
>
> This is caused by update_equiv_regs() which IRA inherited from local-alloc.c.
> Although with gcc 4.3 and earlier, you don't see the problem, it is still 
> there,
> because if you look at the 4.3 dumps, you will see that update_equiv_regs()
> unordered them for us.  What is saving us is that sched2 reschedules them
> again for us in the order we want.  With 4.4, IRA happens to reuse the same
> register for both pseudos, so sched2 is hand tied and cannot schedule them
> back again for us.
>
> Looking at update_equiv_regs(), if I disable the replacement for regs
> that are local to one basic block (patch below) like it existed before
> John Wehle's patch way back in Oct 2000:
>
>  http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00782.html
>
> then we get the ordering we want.  Does anyone know why John removed
> that part of the test in his patch?  Thoughts anyone?

Hmm.  I suppose if you conditionalize it on flag_schedule_insns it might be
an overall win.  Care to SPEC test that change?

Thanks,
Richard.

>
> Peter
>
>
> Index: ira.c
> ===
> --- ira.c       (revision 15)
> +++ ira.c       (working copy)
> @@ -2510,6 +2510,7 @@ update_equiv_regs (void)
>                     calls.  */
>
>                  if (REG_N_REFS (regno) == 2
> +                     && REG_BASIC_BLOCK (regno) < NUM_FIXED_BLOCKS
>                      && (rtx_equal_p (x, src)
>                          || ! equiv_init_varies_p (src))
>                      && NONJUMP_INSN_P (insn)
>
>
>
>

Re: [gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx

[Ralf Wildenhues]

* Jason Merrill wrote on Wed, Aug 26, 2009 at 10:32:05PM CEST:
> On 08/03/2009 04:09 PM, Pedro Lamarão wrote:
> >Current trunk (revision 150381) fails to bootstrap with the following
> >configuration:
> 
> >.../../trunk/libcpp/../include/libiberty.h:106: error: new declaration
> >‘char* basename(const char*)’
> >/usr/include/string.h:601: error: ambiguates old declaration ‘const
> >char* basename(const char*)’
> 
> The problem is that AC_CHECK_DECLS gets confused by overloaded
> functions, and glibc 2.10 has overloaded declarations of basename
> and some other string functions for const-correctness.

Could you show the config.log snippet that shows the failed test?
Is this a new error due to the autotools upgrade, or new due to
glibc 2.10?

Thanks,
Ralf

Re: IRA undoing scheduling decisions

[Peter Bergner]

On Wed, 2009-08-26 at 23:30 +0200, Richard Guenther wrote:
> On Wed, Aug 26, 2009 at 10:47 PM, Peter Bergner wrote:
> > Looking at update_equiv_regs(), if I disable the replacement for regs
> > that are local to one basic block (patch below) like it existed before
> > John Wehle's patch way back in Oct 2000:
> >
> >  http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00782.html
> >
> > then we get the ordering we want.  Does anyone know why John removed
> > that part of the test in his patch?  Thoughts anyone?
> 
> Hmm.  I suppose if you conditionalize it on flag_schedule_insns it might be
> an overall win.  Care to SPEC test that change?

I assume you mean like the change below?  Yeah, I can SPEC test that.

Peter


Index: ira.c
===
--- ira.c   (revision 15)
+++ ira.c   (working copy)
@@ -2510,6 +2510,8 @@ update_equiv_regs (void)
 calls.  */
 
  if (REG_N_REFS (regno) == 2
+ && (!flag_schedule_insns
+ || REG_BASIC_BLOCK (regno) < NUM_FIXED_BLOCKS)
  && (rtx_equal_p (x, src)
  || ! equiv_init_varies_p (src))
  && NONJUMP_INSN_P (insn)

Re: [gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx

[Pedro Lamarão]

2009/8/26 Ralf Wildenhues :

>> >.../../trunk/libcpp/../include/libiberty.h:106: error: new declaration
>> >‘char* basename(const char*)’
>> >/usr/include/string.h:601: error: ambiguates old declaration ‘const
>> >char* basename(const char*)’
>>
>> The problem is that AC_CHECK_DECLS gets confused by overloaded
>> functions, and glibc 2.10 has overloaded declarations of basename
>> and some other string functions for const-correctness.
>
> Could you show the config.log snippet that shows the failed test?
> Is this a new error due to the autotools upgrade, or new due to
> glibc 2.10?

I think this is new in glibc 2.10, for the reasons given by Jason Merrill above.
I've discussed this problem with Jerry Quinn before, and he had a
tentative patch that worked for me.
As I understand things, this patch is on hold waiting for a solution
to the bootstrap comparison problem being discussed in another thread.

I am waiting for a solution to these problems to continue work on the
std::sort gcc-in-cxx subproject; keeping all these patches up to date
with trunk is too difficult for me right now.
Currently, I have a patch to an old revision of the trunk.

--
 P.

Re: Why no strings in error messages?

[Ian Lance Taylor]

Bradley Lucier  writes:

> Are 12 registers not enough, in principle, to do scheduling before
> register allocation?  I was getting a 15% speedup on some numerical
> codes, as pre-scheduling spaced out the vector loads among the
> floating-point computations.

If you are getting that kind of speedup (which I personally did not
expect) then this is clearly worth pursuing.  It should be possible to
make it work at least in 64-bit mode.  I recommend that you file a bug
report or two for cases which fail when using -fschedule-insns.

Ian

Re: Include statement in your gnu free fortran 77 compiler

[Ian Lance Taylor]

 writes:

> I have a quick question on the useage of your gnu free
> fortran compiler.  I have written fortran code for 
> microsoft fortran compiler version 5.1 and use an include
> statement in my code.  In this compiler, the include
> statement starts with a $ letter.  I think they call these
> commands metacommands.  Is this the same in your gnu free
> fortran compiler, or is the include statement just
> include "filename.ext" with filename.ext the include file
> to be inserted into the code at this location.

This question is not appropriate for the gcc@gcc.gnu.org mailing list.
Please take any followups to gcc-h...@gcc.gnu.org or
fort...@gcc.gnu.org.  Thanks.

I believe that GNU fortran does not use a $ prefix.

Ian

Re: Anyone else run ACATS on ARM?

[Geert Bosch]

On Aug 12, 2009, at 10:32, Joel Sherrill wrote:


Hi,

GNAT doesn't build for arm-rtems on 4.4.x or
SVN (PR40775).  I went back to 4.3.x since I
remembered it building.
I have run the ACATS on an ep7312 target and
get a number of generic test failures that
don't look RTEMS specific.  Has anyone run
ACATS on arm?


Yes, we ported it to ARM/Nucleus OS, and we required some fixes to
prologue generation. The patches we submitted for that to the
mailinglist and then pinged, were ignored. I'm sure this is in
the archives somewhere.

  -Geert

Re: Compiling the GNU ada compiler on a very old platform

[Geert Bosch]

On Aug 21, 2009, at 18:40, Paul Smedley wrote:


Hi All,

I'm wanting to update the GNU ADA compiler for OS/2... I'm currently
building GCC 4.3.x and 4.4.x on OS/2 (C/C++/fortran) but for ADA
configure complains about not finding gnat.  The problem is that the
only gnat compiled for OS/2 was years ago using a different toolchain
so it's not suitable.


I used to maintain the OS/2 port for AdaCore, but that was many years  
ago.

IBM released its last version of OS/2 in 2001. Currently it is almost
impossible to run OS/2 in either real modern hardware or on a  
virtualized

system.

AFAIK, GNAT 3.15p is the last GNAT version with OS/2 support. As the  
OS/2
version was a full implementation of Ada 95, including all annexes,  
passing

all ACATS tests, this version should still be very useful today, if you
have a system running OS/2, that is. If you're interested in developing
Ada applications on OS/2, your best bet is to use GNAT 3.15p.
You'll get a mature well-tested and very fast compiler.

This version might still be able to bootstrap GNAT.

  -Geert

Re: Why no strings in error messages?

[Bradley Lucier]

On Wed, 2009-08-26 at 17:12 -0700, Ian Lance Taylor wrote:

> If you are getting that kind of speedup (which I personally did not
> expect) then this is clearly worth pursuing.  It should be possible to
> make it work at least in 64-bit mode.  I recommend that you file a bug
> report or two for cases which fail when using -fschedule-insns.

Thanks, I've added some details of the speedup (with code differences)
to the end of PR33928 and I've reported the two different failures (for
x86-64 and ppc64) in PR41164 and PR41176.

Brad

[GSoC] Status of Automatic parallelization in Graphite.

[Li Feng]

Hi all,

Working with great Graphite developers, I have finished this summer's
GSoC project.
So I think it's time to summarize this summer's work and plan next.

For details about autopar in Graphite, you could refer to this page:
http://gcc.gnu.org/wiki/Graphite/Parallelization
and this page:
http://gcc.gnu.org/wiki/AutoparRelated
I blog here for this project:
http://summergraphite.blogspot.com/

Here is a short summary.

* Current status:

First step of autopar in Graphite has been done. You can trigger it by 2 flags
-floop-parallelize-all -ftree-parallelize-loops=4. Both of them are
needed, the first flag will
trigger Graphite pass to mark loops that can be parallel and the
second flag will trigger
the code generation part.

Now Autopar in Graphite can handle loops:

1. Common loops without dependency (Checking dependency under
polyhedral model).
2. Loops with if statement.
3. Some of the triangle loops.

* Limitations (To be enhanced)

1. Code generation only works for the innermost.
2. We can not handle all the triangle loops.
3. Missing reduction support.

* Open projects

1. Heuristics for automatic parallelization.
2. Parallelize non innermost loops.
3. Handle reductions in graphite
4. Advanced automatic parallelization.
(For details about these open projects, you could refer to this page:
http://gcc.gnu.org/wiki/Graphite/Parallelization )

* Plan next

This project is only the first step of my contribution to GCC
communicy, so I will continue
my working with Graphite developers for later works. It's really fun
to work together, and
discuss together, so if you also interested in Graphite development,
just leave us a post
in our maillist.

To Graphite developers, I would say it's really great to work with you
guys, and thanks
for your great help. Let's keep our good working goes on. :)

Cheers,
Li

Re: GNU MPFR 2.4.2 Release Candidate

[Jack Howarth]

The mpfr 2.4.2-rc1 release builds fine on x86_64-apple-darwin10
and passes all of its testsuite. I do see a few warnings though...

/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 
-DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1 
-DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1 
-DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 
-DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 
-DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ATTRIBUTE_MODE=1 
-DHAVE_ALLOCA_H=1 -I.   -I/sw/include  -Wall -Wmissing-prototypes 
-Wpointer-arith -O2 -pedantic -m64 -mtune=core2 -MT vasprintf.lo -MD -MP -MF 
.deps/vasprintf.Tpo -c -o vasprintf.lo vasprintf.c
libtool: compile:  gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
-DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 
-DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1 -DHAVE_SETLOCALE=1 
-DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1 
-DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 
-DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 
-DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ATTRIBUTE_MODE=1 
-DHAVE_ALLOCA_H=1 -I. -I/sw/include -Wall -Wmissing-prototypes -Wpointer-arith 
-O2 -pedantic -m64 -mtune=core2 -MT vasprintf.lo -MD -MP -MF 
.deps/vasprintf.Tpo -c vasprintf.c  -fno-common -DPIC -o .libs/vasprintf.o
vasprintf.c:547:76: warning: use of C99 long long integer constant
vasprintf.c:548:39: warning: use of C99 long long integer constant
vasprintf.c:583:43: warning: use of C99 long long integer constant
vasprintf.c:618:50: warning: use of C99 long long integer constant
vasprintf.c: In function '__gmpfr_vasprintf':
vasprintf.c:2015: warning: ISO C90 does not support 'long long'
vasprintf.c:2015: warning: ISO C90 does not support 'long long'
vasprintf.c:2142: warning: ISO C90 does not support 'long long'

/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 
-DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1 
-DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1 
-DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 
-DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 
-DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ATTRIBUTE_MODE=1 
-DHAVE_ALLOCA_H=1 -I.   -I/sw/include  -Wall -Wmissing-prototypes 
-Wpointer-arith -O2 -pedantic -m64 -mtune=core2 -MT fits_intmax.lo -MD -MP -MF 
.deps/fits_intmax.Tpo -c -o fits_intmax.lo fits_intmax.c
libtool: compile:  gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
-DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 
-DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1 -DHAVE_SETLOCALE=1 
-DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1 
-DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 
-DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 
-DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ATTRIBUTE_MODE=1 
-DHAVE_ALLOCA_H=1 -I. -I/sw/include -Wall -Wmissing-prototypes -Wpointer-arith 
-O2 -pedantic -m64 -mtune=core2 -MT fits_intmax.lo -MD -MP -MF 
.deps/fits_intmax.Tpo -c fits_intmax.c  -fno-common -DPIC -o .libs/fits_intmax.o
fits_intmax.c:76:15: warning: use of C99 long long integer constant
fits_intmax.c:76:28: warning: use of C99 long long integer constant
fits_intmax.c:96:25: warning: use of C99 long long integer constant
fits_intmax.c:96:38: warning: use of C99 long long integer constant

/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 
-DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1 
-DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1 
-DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 
-DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 
-DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ATTRIBUTE_MODE=1 
-DHAVE_ALLOCA_H=1 -I.   -I/sw/include  -Wall -Wmissing-prototypes 
-Wpointer-arith -O2 -pedantic -m64 -mtune=core2 -MT get_sj.lo -MD -MP -MF 
.deps/get_sj.Tpo -c -o get_sj.lo get_sj.c
libtool: compile:  gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
-DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 
-DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1 -DHAVE_SETLOCALE=1 
-DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1 
-DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 
-DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 
-DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ATTRIBUTE_MODE=1 
-DHAVE_ALLOCA_H=1 -I. -I/sw/include -Wall -Wmissing-prototypes -Wpointer-arith 
-O2 -pedantic -m64 -mtune=core2 -MT get_sj.lo -MD -MP -M

Re: GNU MPFR 2.4.2 Release Candidate

[Vincent Lefevre]

On 2009-08-26 22:54:05 -0400, Jack Howarth wrote:
> The mpfr 2.4.2-rc1 release builds fine on x86_64-apple-darwin10
> and passes all of its testsuite. I do see a few warnings though...

Thanks. The warnings should not be a problem, because the "configure"
script detected that the non-C90 features were working.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: enable-build-with-cxx bootstrap compare broken by r149964

[Jason Merrill]

On 08/15/2009 10:12 AM, Jerry Quinn wrote:

Building with --enable-build-with-cxx fails to bootstrap as follows:

Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_alloc.o differs

>...

Do you know why r149964 makes a difference?  The only objects that are 
listed as differing here are from libstdc++, and changing 
needs_fake_anon to abort rather than return true doesn't cause any 
problems building libstdc++.  We used anonymous namespaces in the 
library before this...


I tried doing the bootstrap myself, but build-with-cxx doesn't currently 
work with glibc 2.10.  I guess I could try on a box with an older 
install, but haven't yet.


Jason