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:
libtoo
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
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)
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
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
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
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
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
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
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
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 -fsc
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
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
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.bz
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
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 th
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
* 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
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 char
[ 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
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 s
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 spil
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
> metac
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
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) run
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 ‘c
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
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 cal
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){
>> *
* 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(co
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
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 b
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 speedu
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
>
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 r
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 year
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 cas
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
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 -DHAV
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 w
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
41 matches
Mail list logo
