This is the beta release of binutils 2.17.50.0.6 for Linux, which is
based on binutils 2006 1020 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.6 release, the default output section LMA
(load memory address) has changed for allocatable sectio
On Tue, Oct 10, 2006 at 11:21:41AM -0500, Menezes, Evandro wrote:
> > H.J., do you have the i386 psABI in source form somewhere I could get
> > it, to make the corresponding changes?
>
> Actually, it's about an extension to the i386 psABI and it's an idea still in
> its infancy: http://sourcewar
On Sat, Nov 04, 2006 at 04:58:42PM -0800, Brooks Moses wrote:
> Daniel Jacobowitz wrote:
> >On Sat, Nov 04, 2006 at 10:57:14AM -0800, Brooks Moses wrote:
> >>I've been setting up a Debian box to do builds on, and make bootstrap on
> >>mainline is failing somewhere in the middle of Stage 1. The pr
Intel has published Core 2 Duo Optimization Reference Manual. I will
check in this patch to update wwwdocs.
H.J.
2006-11-10 H.J. Lu <[EMAIL PROTECTED]>
* readings.html: Update Intel64 and IA32 SDM website.
Index: readings.html
=
On Fri, Nov 10, 2006 at 09:36:59AM -0800, H. J. Lu wrote:
> Intel has published Core 2 Duo Optimization Reference Manual. I will
> check in this patch to update wwwdocs.
>
I checked it in. You can find Core 2 Duo Optimization Reference Manual
at
http://developer.intel.com/products/
On Fri, Nov 10, 2006 at 12:38:07PM -0800, Mike Stump wrote:
> How many hunks do we need, well, today I want 8 for 4.2 and 16 for
> mainline, each release, just 2x more. I'm assuming nice, equal sized
> hunks. For larger variations in hunk size, I'd need even more hunks.
>
> Or, so that is ju
On Sun, Nov 12, 2006 at 02:44:36PM -, Dave Korn wrote:
>
> I see this on linux but not on cygwin:
>
> make[3]: Leaving directory `/home/dk/gnu/obj'
> Comparing stages 2 and 3
> warning: ./cc1-checksum.o differs
> warning: ./cc1plus-checksum.o differs
> warning: ./cc1obj-checksum.o differs
>
Gcc 4.3 revision 118764 failed galgel in SPEC CPU 2000 with
-O2 -ffast-math on Linux/x86-64. I got
galgel_base.o2[30363]: segfault at 000b rip 000b rsp
007fb008 error 14
Gcc 4.3 revision 118723 passes SPEC CPU 2006 with -O2 -ffast-math on
Linux/x86-64. But it fail
On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
> > Steve Kargl writes:
>
> Steve> I have not seen this failure, but that may be expected
> Steve> since SPEC CPU 2000 isn't freely available.
>
> No failure should be expected. It is a bug and a regression and
> should be
On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
> On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
> > >>>>> Steve Kargl writes:
> >
> > Steve> I have not seen this failure, but that may be expected
> > Steve> since SPEC
On Tue, Nov 14, 2006 at 11:56:01AM -0800, Brooks Moses wrote:
> H. J. Lu wrote:
> >On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
> >>On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
> >>> No failure should be expected. It is a bug and a
On Tue, Nov 14, 2006 at 12:03:39PM -0800, H. J. Lu wrote:
> On Tue, Nov 14, 2006 at 11:56:01AM -0800, Brooks Moses wrote:
> > H. J. Lu wrote:
> > >On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
> > >>On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edel
This is the beta release of binutils 2.17.50.0.7 for Linux, which is
based on binutils 2006 1020 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.7 release, the default output section LMA
(load memory address) has changed for allocatable sections f
On Fri, Dec 01, 2006 at 03:36:59AM -0600, Ryan Hill wrote:
> Currently, the way the native CPU detection code in driver-i386.c
> is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
> Core 2 Duo*) processor will result in -m{arch,tune}=prescott. Is this
> the correct setting for this
On Fri, Dec 01, 2006 at 06:43:46AM -0800, H. J. Lu wrote:
> On Fri, Dec 01, 2006 at 03:36:59AM -0600, Ryan Hill wrote:
> > Currently, the way the native CPU detection code in driver-i386.c
> > is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
> > Core 2 Duo*)
FYI, I created an IA64 psABI discussion group:
http://groups-beta.google.com/group/ia64-abi
H.J.
This is the beta release of binutils 2.17.50.0.8 for Linux, which is
based on binutils 2006 1201 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.8 release, the default output section LMA
(load memory address) has changed for allocatable sections f
On Fri, Dec 01, 2006 at 03:37:22PM -0500, Andrew MacLeod wrote:
> On Fri, 2006-12-01 at 14:59 -0500, Daniel Berlin wrote:
> > On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > > On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
> > > > On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wr
On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and
LOCKREP_PREFIX isn't fixed. Currently, gas generates
LOCKREP_PREFIX ADDR_PREFIX DATA_PREFIX SEG_PREFIX
I will check in a patch:
http://sourceware.org/ml/binutils/2006-12/msg00054.html
tomorrow and change gas to generate
SEG_P
On Wed, Dec 06, 2006 at 08:43:17AM -0800, Randy Dunlap wrote:
> On Tue, 5 Dec 2006 23:00:14 -0800 H. J. Lu wrote:
>
> > On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and
> > LOCKREP_PREFIX isn't fixed. Currently, gas generates
> >
> > LOC
On Wed, Dec 06, 2006 at 06:52:39PM +0100, Mikael Pettersson wrote:
>
> If hardware x86 decoders (i.e., Intel or AMD processors)
> get measurably faster with the new order, that would be
> a good reason to change it.
I was told that AMD processors had no preferences and Intel processors
preferred
Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance
regressions on P4, Pentium M and Core Duo, comparing aganst
gcc 4.2 20060910. With -O2, the typical regressions look like
Gcc 4.2 Gcc 4.3
410.bwaves 9.899.14-7.58342%
41
On Fri, Dec 08, 2006 at 07:39:45PM +0100, Uros Bizjak wrote:
> H. J. Lu wrote:
>
> >Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance
> >regressions on P4, Pentium M and Core Duo, comparing aganst
> >gcc 4.2 20060910. With -O2, the typical regressions lo
On Mon, Dec 11, 2006 at 12:27:07AM -0500, Daniel Berlin wrote:
> Hey, by chance does the attached fix it?
>
Yes, it fixes 464.h264ref with the test input. I am running the real
input now.
Thanks.
H.J.
---
>
> On 12/10/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> &
On Sun, Dec 10, 2006 at 09:42:35PM -0800, H. J. Lu wrote:
> On Mon, Dec 11, 2006 at 12:27:07AM -0500, Daniel Berlin wrote:
> > Hey, by chance does the attached fix it?
> >
>
> Yes, it fixes 464.h264ref with the test input. I am running the real
> input now.
>
Do y
On Sun, Dec 10, 2006 at 09:42:35PM -0800, H. J. Lu wrote:
> On Mon, Dec 11, 2006 at 12:27:07AM -0500, Daniel Berlin wrote:
> > Hey, by chance does the attached fix it?
> >
>
> Yes, it fixes 464.h264ref with the test input. I am running the real
> input now.
>
It wor
On Fri, Dec 08, 2006 at 01:02:27PM -0600, Menezes, Evandro wrote:
> HJ,
>
> I'll run the three worst offenders below and get back to y'all.
>
> The full results will take longer.
Hi Evandro,
I also saw similar issues on x86-64 with -O2 -ffast-math:
gcc-4.2 rev 116820 gcc
On Mon, Dec 11, 2006 at 11:35:27AM -0600, Menezes, Evandro wrote:
> HJ,
>
> > > Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance
> > > regressions on P4, Pentium M and Core Duo, comparing aganst
> > > gcc 4.2 20060910. With -O2, the typical regressions look like
> > >
> > >
On Wed, Jan 03, 2007 at 10:18:36AM -0800, Seongbae Park wrote:
> >In fact, by default, gcc for the i386 targets will call _mcount. gcc
> >for i386 GNU/Linux targets was changed to call mcount instead of
> >_mcount with this patch:
> >
> >Thu Mar 30 06:20:36 1995 H.J. Lu ([EMAIL PROTECTED])
> >
This is the beta release of binutils 2.17.50.0.9 for Linux, which is
based on binutils 2007 0103 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections f
Here is one implementation of ELF sharable section proposal:
http://groups-beta.google.com/group/generic-abi/browse_thread/thread/bca08f6560f61b0d
Several people have expressed interests. I post it here for comments.
I used OS specific values. If we get consensus, I can change those
values to gen
On Fri, Jan 05, 2007 at 08:53:07AM +, Christoph Hellwig wrote:
> On Thu, Jan 04, 2007 at 03:31:46PM -0800, H. J. Lu wrote:
> > Here is one implementation of ELF sharable section proposal:
> >
> > http://groups-beta.google.com/group/generic-abi/browse_thread/th
On Fri, Jan 05, 2007 at 09:27:35PM +0100, Magnus Fromreide wrote:
> On fre, 2007-01-05 at 17:05 +, Andrew Haley wrote:
> > Magnus Fromreide writes:
> >
> > But it can't unless you use an architecture that has cmpxchgl.
> > cmpxchgl is a 486 instruction; if you compile for 386, we have to
> > g
On Sat, Jan 06, 2007 at 04:42:27PM +0100, Steven Bosscher wrote:
> Hi,
>
> We currently do not have an active maintainer for the i386 port. The
> only listed maintainer for the port is rth, and he hasn't been around
> to approve patches in a while. This situation is a bit strange for
> a port t
I am enclosing a patch to implement a new linker swicth,
--dynamic-list-data. It is -Bsymbolic for function symbols only.
I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64
and Linux/ia64. There are only a few regressions. The function calls
within the new resulting DSOs will bind
On Mon, Jan 08, 2007 at 08:09:59PM -0800, Andrew Pinski wrote:
> On Mon, 2007-01-08 at 18:25 -0800, H. J. Lu wrote:
> > I am enclosing a patch to implement a new linker swicth,
> > --dynamic-list-data. It is -Bsymbolic for function symbols only.
> > I tried it with C, C++
On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > I am enclosing a patch to implement a new linker swicth,
> > --dynamic-list-data. It is -Bsymbolic for function symbols only.
> > I tried it with C, C++, Java and Fortran on Linux/ia32,
On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote:
> > > H. J. Lu writes:
> > > > I am enclosing a patch to implement a new linker swicth,
> > > >
On Tue, Jan 09, 2007 at 02:01:53PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote:
> > > H. J. Lu writes:
> > > > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote:
> > > &
On Mon, Jan 08, 2007 at 08:23:39PM -0800, H. J. Lu wrote:
> On Mon, Jan 08, 2007 at 08:09:59PM -0800, Andrew Pinski wrote:
> > On Mon, 2007-01-08 at 18:25 -0800, H. J. Lu wrote:
> > > I am enclosing a patch to implement a new linker swicth,
> > > --dynamic-list-data. It
On Tue, Jan 09, 2007 at 04:42:41PM +0100, Paolo Bonzini wrote:
>
> >I am testing this patch now. It should fix the regresions when
> >libstdc++ is built with
> >
> >-Bsymbolic-functions --dynamic-list-cpp-new
I tested it on gcc 4.2 with C, C++, Java and Fortran on Linux/x86-64.
There is no regres
On Tue, Jan 09, 2007 at 06:18:19AM -0800, H. J. Lu wrote:
> On Tue, Jan 09, 2007 at 02:01:53PM +, Andrew Haley wrote:
> > H. J. Lu writes:
> > > On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote:
> > > > H. J. Lu writes:
> > > > > On
With LTO, an object file may contain sections with IL, which
can be discarded when building DSO and executable. Currently we can't
mark such sections with gABI. With GNU linker, we can use a
linker script to discard such sections. But it will be more generic
to make a section to be discarded for DS
On Tue, Jan 09, 2007 at 10:09:35AM -0800, Ian Lance Taylor wrote:
>
> That is not strictly required for LTO as I see it. With LTO, the lto
> program is going to read the .o files with the IL information. It
> will then generate a new .s file to pass to the assembler. The IL
> information will n
On Tue, Jan 09, 2007 at 09:42:40AM -0800, H. J. Lu wrote:
> On Tue, Jan 09, 2007 at 06:18:19AM -0800, H. J. Lu wrote:
> > On Tue, Jan 09, 2007 at 02:01:53PM +, Andrew Haley wrote:
> > > H. J. Lu writes:
> > > > On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Ha
Does gcc support "delete (nothrow)"? I ran into 2 problems:
1. I had to call destructor directly since
A *p = new (std::nothrow) A;
delete (std::nothrow) p;
won't cpmpile. I had to use
A *p = new (std::nothrow) A;
...
operator delete (bb, std::nothrow);
2.
A *bb = new (std::nothrow) A [10];
On Tue, Jan 09, 2007 at 01:55:44PM -0800, H. J. Lu wrote:
> Does gcc support "delete (nothrow)"? I ran into 2 problems:
>
> 1. I had to call destructor directly since
>
> A *p = new (std::nothrow) A;
> delete (std::nothrow) p;
>
> won't cpmpile. I had t
On Tue, Jan 09, 2007 at 07:52:42AM -0800, H. J. Lu wrote:
> >
> > What about just --dynamic-list-cpp that enables the new behavior and
> > implies --dynamic-list-cpp-typeinfo (I know that it is useless in this
> > particular case, since C++ typeinfo is data, but in gen
With the new linker switches, -Bsymbolic-functions and
--dynamic-list-cpp-new, we can improve shared library
performance in gcc. This change will build libstdc++.so with
-Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it
to other libraries.
H.J.
--
--- gcc/libstdc++-v3/acinclude.m4.
On Wed, Jan 10, 2007 at 07:19:17AM -0800, Ian Lance Taylor wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
>
> > With the new linker switches, -Bsymbolic-functions and
> > --dynamic-list-cpp-new, we can improve shared library
> > performance in gcc.
On Wed, Jan 10, 2007 at 06:26:09AM -0700, Tom Tromey wrote:
> >>>>> "H.J." == H J Lu <[EMAIL PROTECTED]> writes:
>
> H.J.> With the new linker switches, -Bsymbolic-functions and
> H.J.> --dynamic-list-cpp-new, we can improve shared library
&
Both AMD and Intel like to have BID as a configure time option
for DFP. Intel is planning to contribute a complete BID runtime
library, which can be used by executables generate by gcc.
As the first step, we'd like to contribute a BID<->DPD library so that
BID can be used with libdecnumber by exec
On Wed, Jan 10, 2007 at 02:10:58PM -0800, Janis Johnson wrote:
> On Wed, Jan 10, 2007 at 11:40:46AM -0800, H. J. Lu wrote:
> > Both AMD and Intel like to have BID as a configure time option
> > for DFP. Intel is planning to contribute a complete BID runtime
> > library,
On Thu, Jan 11, 2007 at 09:03:42AM +0100, Paolo Bonzini wrote:
> H. J. Lu wrote:
> >On Wed, Jan 10, 2007 at 06:26:09AM -0700, Tom Tromey wrote:
> >>>>>>>"H.J." == H J Lu <[EMAIL PROTECTED]> writes:
> >>H.J.> With the new linker switch
On Thu, Jan 11, 2007 at 07:33:21PM +0100, Paolo Bonzini wrote:
>
> >config/
> >
> >2007-01-10 H.J. Lu <[EMAIL PROTECTED]>
> >
> > * ld-symbolic.m4: New.
>
> Please name the macro AC_LIB_PROG_LD_GNU_SYMBOLIC, or
> ACX_PROG_LD_GNU_SYMBOLIC.
>
> >libgfortran/
> >
> >2007-01-10 H.J. Lu <[EM
On Fri, Jan 12, 2007 at 08:57:42AM +0100, Paolo Bonzini wrote:
>
> >libjava will use -Bsymbolic on Linux, which is more aggresive than
> >-Bsymbol-functions. It will bind global data references locally in
> >additon to global function references. My patch will keep -Bsymbolic
> >for libjava if it
On Fri, Jan 12, 2007 at 12:13:11PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > On Thu, Jan 11, 2007 at 07:33:21PM +0100, Paolo Bonzini wrote:
> > >
> > > >config/
> > > >
> > > >2007-01-10 H.J. Lu <[EMAIL P
On Thu, Jan 11, 2007 at 08:06:31PM -0500, Daniel Berlin wrote:
> On 1/11/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
> >Menezes, Evandro wrote:
> >> Though not as pronounced, definitely significant.
> >>
> >
> >Using binary search I've detected that 30% performance regression of
> >cpu2006/43
On Fri, Jan 12, 2007 at 09:30:27PM +0300, Grigory Zagorodnev wrote:
> Hi!
> GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and
> higher optimization level at x86_64-redhat-linux.
>
> reload1.c: In function 'reload':
> reload1.c:449: error: address taken, but ADDRESSABLE bit not
On Fri, Jan 12, 2007 at 06:38:56AM -0800, H. J. Lu wrote:
> On Fri, Jan 12, 2007 at 08:57:42AM +0100, Paolo Bonzini wrote:
> >
> > >libjava will use -Bsymbolic on Linux, which is more aggresive than
> > >-Bsymbol-functions. It will bind global data references locall
On Fri, Jan 12, 2007 at 02:06:48PM -0500, Daniel Berlin wrote:
> On 1/12/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> >On Thu, Jan 11, 2007 at 08:06:31PM -0500, Daniel Berlin wrote:
> >> On 1/11/07, Grigory Zagorodnev <[EMAIL PROTECTED]>
> >wrote:
> >> &
process_pending_assemble_externals will be called at the end,
which calls assemble_external_real on all external symbols.
Do we still need TARGET_ASM_EXTERNAL_LIBCALL? Why can't
assemble_external_real handle it?
H.J.
On Mon, Jan 15, 2007 at 09:47:34PM +0100, Toon Moene wrote:
> Grigory,
>
> Calculix is a combined C/Fortran program. Did you try to compile the
> Fortran parts with --param max-aliased-vops= default 50> ?
>
> Diego up'd the default from 10 to 50 because one (or more) of the
> (Fortran) Polyhed
On Mon, Jan 15, 2007 at 07:35:22PM -0800, Ian Lance Taylor wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
>
> > process_pending_assemble_externals will be called at the end,
> > which calls assemble_external_real on all external symbols.
> > Do we sti
On Mon, Jan 15, 2007 at 08:23:05PM -0800, Ian Lance Taylor wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
>
> > > Look at, e.g., mcore_external_libcall in mcore.c, and at
> > > ASM_OUTPUT_EXTERNAL_LIBCALL in i386/cygming.h. You need to handle
> >
On Mon, Jan 15, 2007 at 08:33:28PM -0800, H. J. Lu wrote:
> > > TARGET_ASM_EXTERNAL_LIBCALL when there is ASM_OUTPUT_EXTERNAL?
> >
> > In the larger scheme of things, we don't.
> >
> I will open a bug report for enhancement.
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30480
H.J.
On Tue, Jan 16, 2007 at 07:05:34PM +0300, Grigory Zagorodnev wrote:
> Toon Moene wrote:
> >Calculix is a combined C/Fortran program. Did you try to compile the
> >Fortran parts with --param max-aliased-vops= >default 50> ?
> Right, calculix is a combined program. Gprof says the regression is in
This is the beta release of binutils 2.17.50.0.10 for Linux, which is
based on binutils 2007 0122 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections
On Thu, Jan 25, 2007 at 11:18:34AM +0100, François-Xavier Coudert wrote:
> [sorry for breaking the thread; stupid gmail doesn't want to add
> custom References headers]
>
> >It may be that not too many people pick up 4.2.0. But, if 4.3 isn't
> >looking very stable, there will be a point when peop
On Thu, Jan 25, 2007 at 09:57:45AM -0500, Robert Dewar wrote:
> H. J. Lu wrote:
>
> >Gcc 4.2 has a serious FP performace issue:
> >
> >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html
> >
> >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it
On Thu, Jan 25, 2007 at 07:22:46PM -0800, George R Goffe wrote:
> Howdy,
>
> I got an email from Joe Buck who suggested that I fix a clock skew problem
> between 2
> of my systems. I did this but this did not change the "other" problem with
> this
> build effort. A diff of the 2 sets of error me
This is the beta release of binutils 2.17.50.0.11 for Linux, which is
based on binutils 2007 0125 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections
This is the beta release of binutils 2.17.50.0.12 for Linux, which is
based on binutils 2007 0128 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections
On Thu, Feb 01, 2007 at 08:03:36AM +0100, Basile STARYNKEVITCH wrote:
>
> Hello
>
> (I don't know if the good mailing list for this is gcc@ or gcc-patches@)
>
> Apparently trunk rev 121458 don't bootstrap on linux debian sid amd64 ie
> x86_64-unknown-linux-gnu
>
> I'm getting
>
> make[4]
On Fri, Feb 02, 2007 at 11:19:57AM -0800, Mike Stump wrote:
> I've been seeing:
>
> /Volumes/mrs5/net/gcc-darwin/./gcc/xgcc -shared-libgcc -B/
> Volumes/mrs5/net/gcc-darwin/./gcc -nostdinc++ -L/Volumes/mrs5/net/gcc-
> darwin/i686-apple-darwin9/libstdc++-v3/src -L/Volumes/mrs5/net/gcc-
>
On Wed, Feb 07, 2007 at 05:32:28PM +0300, Vladimir Sysoev wrote:
> Hi!
> I create test to reproduce issue with cpu2006/454.calculix
> See attached. File e_c3d.f contains cutted subroutine from calculix.
> tr535.f main entry point of the test. you can use go-script as a
> reference how i get these r
"make bootstrap" used to compare stage2 and stage3 after gcc was
bootstrapped. "make bootstrap" would abort if comparison was failed.
Now, compare stage2 and stage3 is not longer done for
"make bootstrap". Is that intentional? I think it is a very bad
idea.
H.J.
On Sun, Feb 11, 2007 at 01:00:41PM -0800, H. J. Lu wrote:
> "make bootstrap" used to compare stage2 and stage3 after gcc was
> bootstrapped. "make bootstrap" would abort if comparison was failed.
> Now, compare stage2 and stage3 is not longer done for
> "mak
On Sun, Feb 11, 2007 at 05:11:15PM +0100, Hanno Meyer-Thurow wrote:
> On 07 Feb 2007 15:36:14 -0800
> Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> > Can anybody else out there recreate this on their x86_64 system?
>
> Not that I could not recreate the segfault but I found a way to hide the
> s
On Sun, Feb 11, 2007 at 01:09:40PM -0800, H. J. Lu wrote:
> On Sun, Feb 11, 2007 at 05:11:15PM +0100, Hanno Meyer-Thurow wrote:
> > On 07 Feb 2007 15:36:14 -0800
> > Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> >
> > > Can anybody else out there recreate this
On Mon, Feb 12, 2007 at 09:53:00AM -0800, Joe Buck wrote:
> On Sun, Feb 11, 2007 at 01:04:05PM -0800, H. J. Lu wrote:
> > On Sun, Feb 11, 2007 at 01:00:41PM -0800, H. J. Lu wrote:
> > > "make bootstrap" used to compare stage2 and stage3 after gcc was
> > >
On Wed, Feb 14, 2007 at 02:34:24PM +0100, Paweł Sikora wrote:
> François-Xavier Coudert napisał(a):
>
> >$ gcc -march=pentium4 -O3 a.c && time ./a.out
> >064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00
> >./a.out 1.81s user 0.00s system 99% cpu 1.818 total
> >$ gcc-4.3 -march=pen
On Sat, Feb 17, 2007 at 01:35:28PM +0300, Vladimir Sysoev wrote:
> Hello, Daniel
>
> It looks like your changeset listed bellow makes performance
> regression ~40% on SPEC2006/leslie3d. I will try to create minimal
> test for this issue this week and update you in any case.
>
That is a known iss
On Mon, Feb 19, 2007 at 03:16:12PM -0800, Mark Mitchell wrote:
> Daniel Berlin wrote:
>
> >> > > > It looks like your changeset listed bellow makes performance
> >> > > > regression ~40% on SPEC2006/leslie3d. I will try to create minimal
> >> > > > test for this issue this week and update you in a
On Tue, Feb 20, 2007 at 03:53:55PM -0800, Mark Mitchell wrote:
> Richard Guenther wrote:
>
> >> This is 4.7% drop of SPECfp_base2006 ratio (geomean of individual FP
> >> ratios).
>
> Clearly, 4.7% is significant. Grigory, thanks for the measurements!
>
> >> Here is the full set of changes in cp
On Tue, Feb 27, 2007 at 12:30:16PM +0800, Zuxy Meng wrote:
> Hi,
>
> -march=native choose pentium4 instead of pentium-m for Pentium M processors
> (see config/i386/driver-i386.c)? Is this intentional or a typo?
>
It is because Pentium M implements Pentium instructions. You should
get:
bash-3.0
On Sat, Mar 03, 2007 at 11:01:40AM -0500, Diego Novillo wrote:
> Grigory Zagorodnev wrote on 03/03/07 02:27:
>
> > There are three checkins, candidates for the root of regression:
> > http://gcc.gnu.org/viewcvs?view=rev&revision=122487
> > http://gcc.gnu.org/viewcvs?view=rev&revision=12248
On Sat, Mar 03, 2007 at 02:00:30PM -0800, Andrew Pinski wrote:
> On 3/3/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> >> [1] 176.gcc and 253.perlbmk usually miscompare for me. Not sure why.
>
> >176.gcc=default=default=default:
> >CPORTABILITY = -Dalloca=_al
On Mon, Mar 12, 2007 at 05:27:21PM +0100, Richard Guenther wrote:
> Most of the problems are fixed, dealII remains with:
>
> /gcc/spec/sb-balakirew-head-64-2006/x86_64/install-hack/bin/g++ -c -o
> quadrature.o -DSPEC_CPU -DNDEBUG -Iinclude -DBOOST_DISABLE_THREADS
> -Ddeal_II_dimension=3 -O2 -D
This is the beta release of binutils 2.17.50.0.13 for Linux, which is
based on binutils 2007 0315 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
On Wed, Mar 21, 2007 at 09:19:44PM +0100, fafa wrote:
> Hi all,
>
> I noticed that G++ 4.1.2 (on a Pentium 4) generates different instructions
> for
> lea0x0(%esi),%esi
> or
> lea0x0(%edi),%edi
> with the same meaning but different encoding depending on the switch
> "-momit-leaf-fram
On Fri, Mar 23, 2007 at 09:29:05AM -0400, Doug Gregor wrote:
> On 3/23/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> >When I brought up the 16-bit option earlier, Jakub replied that x86 would
> >get hosed worse because it's 16-bit accesses are not as efficient as it's
> >8 or 32 bit ones.
> >
> >
This is the beta release of binutils 2.17.50.0.14 for Linux, which is
based on binutils 2007 0322 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
ACX_BUGURL has
[case "$withval" in
yes) AC_MSG_ERROR([bug URL not specified]) ;;
no) REPORT_BUGS_TO="";
REPORT_BUGS_TEXI=""
;;
*) REPORT_BUGS_TO="<$withval>"
REPORT_BUGS_TEXI="@uref{`echo $withval | sed 's/@/@@/g'`}"
;;
esac]
On Fri, Mar 23, 2007 at 04:57:03PM +, Joseph S. Myers wrote:
> On Fri, 23 Mar 2007, H. J. Lu wrote:
>
> > It assumes there is no @ in $1. Shouldn't be
> >
> > REPORT_BUGS_TEXI="@uref{`echo $1 | sed 's/@/@@/g'`}"
>
> Feel free
On Fri, Mar 23, 2007 at 06:55:38PM +0100, Andreas Schwab wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
>
> > REPORT_BUGS_TO="<$1>"
> > - REPORT_BUGS_TEXI="@uref{$1}"
> > + REPORT_BUGS_TEXI="@uref{`echo $1 |
On Fri, Mar 23, 2007 at 06:20:10PM -, Dave Korn wrote:
> On 23 March 2007 18:11, H. J. Lu wrote:
>
> > On Fri, Mar 23, 2007 at 06:55:38PM +0100, Andreas Schwab wrote:
> >> "H. J. Lu" <[EMAIL PROTECTED]> writes:
> >>
> >>> RE
On Mon, Mar 26, 2007 at 09:13:30AM +0200, Paolo Bonzini wrote:
> Please do this instead:
>
> [EMAIL PROTECTED] "$BUGURL" | sed 's/@/@@/g'`}
>
Will it work with spaces in $BUGURL?
H.J.
On Mon, Mar 26, 2007 at 01:57:52PM -0400, Michael Meissner wrote:
> On Sat, Mar 24, 2007 at 07:01:40PM +, Martin Michlmayr wrote:
> > The following change broke --disable-multilib:
> >
> > 2007-03-23 Michael Meissner <[EMAIL PROTECTED]>
> > H.J. Lu <[EMAIL PROTECTED]>
> >
> > .
On Tue, Mar 27, 2007 at 12:28:18PM +0200, François-Xavier Coudert wrote:
> >My nightly bootstrap of mainline on i386-linux failed tonight, on
> >revision 123192.
>
> This issue is still not fixed as of now. A diff was posted to PR31344
> with the mention "This isn't a real patch." Is a real patch
1 - 100 of 376 matches
Mail list logo
