On Sat, Feb 18, 2006 at 09:23:36AM -0500, Joern Rennecke wrote:
> In http://gcc.gnu.org/ml/gcc/2006-02/msg00357.html, you wrote:
>
> > In fact the "gamer" benchmarks you are dissing are quite well reflecting the
> very kind
> > of coding excessively found in GCC itself. Some observations suggest
>
On Mon, Feb 20, 2006 at 10:51:13AM -0800, Dan Kegel wrote:
> Gerald wrote:
> >On Wed, 1 Feb 2006, H. J. Lu wrote:
> >> My memory hog patch for make has 2 typos. This patch fixes them.
> >Thanks, H. J. What's the upstream status of your patches?
>
> I think
On Mon, Feb 20, 2006 at 07:30:41PM +, Joern RENNECKE wrote:
> the bottleneck of a shared memory bus, but the operating system must
> allocate
> most memory locally to each CPU to avoid a bottleneck in the cross-connect
> of the processors.
>
Linux kernel 2.6.16-rc1 and above supports
percpu
On Mon, Feb 20, 2006 at 07:58:35PM +, Joern RENNECKE wrote:
> H. J. Lu wrote:
>
> >On Mon, Feb 20, 2006 at 07:30:41PM +, Joern RENNECKE wrote:
> >
> >
> >>the bottleneck of a shared memory bus, but the operating system must
> >>allocate
>
On Tue, Feb 21, 2006 at 02:09:43PM +0300, Grigory Zagorodnev wrote:
> Mark Mitchell wrote:
> >GCC 4.1.0 RC1 is here:
> >
> >ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.0-20060219
> >
> >Please download, build, and test. Please use these tarballs, rather
> >than the current SVN branch, so that we test
When I use -O2 -mtune=pentium4 -ffast-math on SPEC CPU 2K on Linux/x86
with gcc 4.2, I get
*** Miscompare of 200.s, see
/export/spec/src/2000/spec/benchspec/CINT2000/176.gcc/run/0004/200.s.mis
*** Miscompare of scilab.s, see
/export/spec/src/2000/spec/benchspec/CINT2000/176.gcc/run/0004/sc
On Thu, Feb 23, 2006 at 11:00:33AM -0800, Dale Johannesen wrote:
>
> On Feb 23, 2006, at 8:54 AM, H. J. Lu wrote:
>
> >When I use -O2 -mtune=pentium4 -ffast-math on SPEC CPU 2K on Linux/x86
> >with gcc 4.2, I get
> >
> >*** Miscompare of 200.s, see
> &
The current gcc only generates ELF type info for undefined symbol for
HPUX. This information is useful for linker to detect possible run-time
problems at link-time. Here is an example:
[EMAIL PROTECTED] mismatch]$ cat foo.c
#include
extern void bar (void);
int times;
int
main ()
{
printf ("t
On Tue, Feb 28, 2006 at 08:40:18PM -0500, Andrew Pinski wrote:
> With clean sources on x86_64-linux-gnu, I am getting almost all tests
> for running gij to fail. Does anyone know what is going on here?
I will bet it is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
H.J.
On Wed, Mar 01, 2006 at 11:48:39AM +, Andrew Haley wrote:
> Andrew Haley writes:
> > Andrew Pinski writes:
> > > With clean sources on x86_64-linux-gnu, I am getting almost all tests
> > > for running gij to fail. Does anyone know what is going on here?
> >
> > I'll have a try now.
>
On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > On Wed, Mar 01, 2006 at 11:48:39AM +, Andrew Haley wrote:
> > > Andrew Haley writes:
> > > > Andrew Pinski writes:
> > > > > With clean sources on x86_6
On Wed, Mar 01, 2006 at 03:19:18PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote:
> > > H. J. Lu writes:
> > > >
> > > > The fix was posted at
> > > >
> >
On Wed, Mar 01, 2006 at 08:24:18AM -0800, Mark Mitchell wrote:
>
> GCC 4.1.0 has been released.
>
It is great. Is 4.1 branch open now? I'd like to back port the x86
-mtune=generic patch:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01436.html
to 4.1.1.
Thanks.
H.J.
On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote:
> On Wednesday 01 March 2006 21:14, H. J. Lu wrote:
> > Is 4.1 branch open now? I'd like to back port the x86
> > -mtune=generic patch:
>
> Isn't that totally inappropriate for a release branch?
>
On Wed, Mar 01, 2006 at 09:42:19PM +0100, Richard Guenther wrote:
> On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote:
> > > On Wednesday 01 March 2006 21:14, H. J. Lu wrote:
> > > > Is 4.1 branch
On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote:
> On Wednesday 01 March 2006 21:49, H. J. Lu wrote:
> > It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc
> > 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2.
>
> Oh, r
On Wed, Mar 01, 2006 at 10:43:40PM +0100, Richard Guenther wrote:
> On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote:
> > > On Wednesday 01 March 2006 21:49, H. J. Lu wrote:
> > > > It is the iss
On Wed, Mar 01, 2006 at 02:19:47PM -0800, Mark Mitchell wrote:
> H. J. Lu wrote:
>
> > Here are diffs of SPEC CPU 2K between before and after with gcc 4.1
> > using "-O2 -ffast-math" on Nocona:
>
> Steven's right; this is clearly a new feature. HJ'
On Wed, Mar 01, 2006 at 03:06:46PM -0800, Mark Mitchell wrote:
> H. J. Lu wrote:
>
> > Here are diffs of "-O2 -mtune=nocona -ffast-math" vs
> > "-O2 -mtune=generic -ffast-math" on Nocona:
>
> A 1.5% performance improvement, while certainly significa
On Wed, Mar 01, 2006 at 04:05:16PM -0800, H. J. Lu wrote:
> On Wed, Mar 01, 2006 at 03:06:46PM -0800, Mark Mitchell wrote:
> > H. J. Lu wrote:
> >
> > > Here are diffs of "-O2 -mtune=nocona -ffast-math" vs
> > > "-O2 -mtune=generic -ffast-math&quo
With this patch:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01877.html
gcc no longer mixes SSE and x387 math by default. However glibc
still assumes gcc mixes SSE and x387 math. The x86-64 FP control
routines in glibc change both SSE and x387 units, which is no
longer necessary with the newer g
On Thu, Mar 02, 2006 at 04:08:54PM +0100, Richard Guenther wrote:
> On 3/2/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > With this patch:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01877.html
> >
> > gcc no longer mixes SSE and x387 math by defau
On Thu, Mar 02, 2006 at 04:34:09PM +0100, Richard Guenther wrote:
> On 3/2/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > On Thu, Mar 02, 2006 at 04:08:54PM +0100, Richard Guenther wrote:
> > > On 3/2/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > > > With this
On Thu, Mar 02, 2006 at 04:44:50PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 02, 2006 at 07:38:47AM -0800, H. J. Lu wrote:
> > Yes. That is for float and double functions in libm.
> >
> > > to touch x387
> > > flags for XFmode long long operations.
> >
>
On Thu, Mar 02, 2006 at 05:19:20PM +0100, Richard Guenther wrote:
> On 3/2/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > On Thu, Mar 02, 2006 at 04:44:50PM +0100, Jakub Jelinek wrote:
> > > On Thu, Mar 02, 2006 at 07:38:47AM -0800, H. J. Lu wrote:
> > > > Yes. Th
any ideas ?
regards
---
Matthew J Fletcher
Embedded Software
Serck Controls Ltd
---
**
Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK
Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437
Web: www.serck-controls.com Admin:
I think it is a glibc issue.
H.J.
-
On Tue, Mar 14, 2006 at 01:18:34PM -0800, Torsten Rohlfing wrote:
> Greetings.
>
> I am experiencing a major performance problem with the log() function on
> the x86_64 platform. It can be illustrated with the following little
> test program:
>
> te
FYI, today's gcc 4.2 generates many unaligned access on IA64:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
It may be related to
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01001.html
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01000.html
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00999.
On Fri, Mar 17, 2006 at 12:13:30AM +0100, Steven Bosscher wrote:
> Hi,
>
> So this Mandriva guy tells me gfortran can't compile Scilab, and
> he is right! Scilab is a pretty important piece of Fortran that
> many people use, so it is a shame that gfortran can't build it
> right now. But the reas
On Wed, Mar 15, 2006 at 08:10:41PM -0800, Alexey Starovoytov wrote:
> 1st choice (the best):
> - change the default for all sparc platforms
NetBSD/sparc still supports sun4c, so default cannot be changed there.
--
Aaron J. Grier | Frye Electronics, Tigard, OR | [EMAIL PROTECTED]
This is the beta release of binutils 2.16.91.0.7 for Linux, which is
based on binutils 2006 0317 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
On Wed, Mar 29, 2006 at 10:18:31PM +0900, SUGIOKA Toshinobu wrote:
> Hi,
>
> For sh4-unknown-linux target, libgcc_s.so is not symbolic link but linker
> script
> that is
>
> GROUP ( libgcc_s.so.1 libgcc.a )
>
> I hear this is because some functions are not included in libgcc_s.so.1 and
> they
On Fri, Apr 14, 2006 at 09:00:14PM +0100, Dave Murphy wrote:
> Ranjit Mathew wrote:
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA1
> >
> >Dave Murphy wrote:
> >
> >>I've been having some odd problems with relocation of 4.x toolchains -
> >>i.e. when a toolchain is configured, built and inst
On Sun, Apr 16, 2006 at 02:04:10PM -0700, Mark Mitchell wrote:
> I've now reviewed the open regressions against the GCC 4.1 branch.
> There are 101 "serious" (P3 or higher) regressions against GCC 4.1, the
> vast majority of which also apply to 4.2. Therefore, fixing these
> regressions provides a
On Wed, Apr 19, 2006 at 02:47:54PM -0700, Mark Mitchell wrote:
> On the regression front, we have 61 open serious (P3 or higher)
> regressions that are specific to 4.2. I have not triaged these, so
> there is a good chance than more than a few relate to Ada, Java,
> Fortran, or non-primary, non-se
On Wed, Apr 19, 2006 at 06:01:54PM -0400, Andrew Pinski wrote:
> > BTW, If anyone is interested in working on SEE for x86-64, please drop
> > me a line.
>
> Why not do the comunication in public?
Sure. Let me give a try.
If I understand it correctly, the current SEE implementation tries to
elim
On Thu, Apr 20, 2006 at 05:18:08PM +0200, Olivier Galibert wrote:
> I need to be able to do unaligned memory accesses to memory in
> big-endian or little-endian mode. For portability, I'd like to do it
> in pure C, but I'd like the compiler to generate optimal sequences for
> the operations. Most
On Sat, Apr 22, 2006 at 01:56:21AM +0200, Andi Kleen wrote:
> > Since they are assembly codes, it sounds like a gcc driver issue to me.
>
> Might be. The way the assembly is built is a bit funky because it's a
> shared library.
It is a gcc bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27253
This is the beta release of binutils 2.17.50.0.1 for Linux, which is
based on binutils 2006 0427 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
On Sat, Apr 29, 2006 at 03:49:42PM -0300, Alexandre Oliva wrote:
> On Apr 29, 2006, "H. J. Lu" <[EMAIL PROTECTED]> wrote:
>
> > On Sat, Apr 29, 2006 at 12:14:03AM -0600, R Hill wrote:
> >>
> >> Testcase is:
> >>
> >> .tfloat
On Sun, Apr 30, 2006 at 01:23:20PM +0200, Andreas Schwab wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
>
> > It looks like a gcc bug to me. Gcc 4.2 miscompiles:
> >
> > more_than_enough_bits_for_digits
> > = (number_of_digits_to_use * 3
n_extend (dest_extension_reg1))
ref: set (dest_extension_reg2) (sign_extend (dest_extension_reg1))
When def merge failed, def_se was deleted. Now use_se had a deleted
ref.
Basically, SEE doesn't handle
(set (reg/v:SI 70 [ j ])
(sign_extend:SI (subreg:HI (reg:SI 72 [ start ]) 0)))
(
On Thu, May 04, 2006 at 11:15:27AM -0400, David Edelsohn wrote:
> I thought that you or others at Intel were going to extend the SEE
> infrastructure to better support x86. The x86 port can turn off SEE in
> override_options or XFAIL the tests for x86 until that work is committed.
Some of
On Thu, May 04, 2006 at 08:39:58AM -0700, Andrew Pinski wrote:
>
> On May 4, 2006, at 8:37 AM, H. J. Lu wrote:
>
> >On Thu, May 04, 2006 at 11:15:27AM -0400, David Edelsohn wrote:
> >>I thought that you or others at Intel were going to extend the SEE
> >>inf
Before I open a bug report, I will ask it here:
[EMAIL PROTECTED] tmp]$ cat foo.c
typedef struct A A;
A *a;
typedef struct A
{
int x;
} A;
[EMAIL PROTECTED] tmp]$ gcc -c foo.c
foo.c:7: error: redefinition of typedef 'A'
foo.c:1: error: previous declaration of 'A' was here
[EMAIL PROTECTED] tmp]
e are at least 2 problems:
> >
> > 1. SEE uses NEXT_INSN/PREV_INSN to find adjacent insns. But with
> > -g, NEXT_INSN/PREV_INSN may point to a NOTE. So adjacent insns checks
> > with NEXT_INSN/PREV_INSN aren't sufficient.
> Only if we change the code to catch x86 patterns.
On Thu, May 04, 2006 at 02:53:38PM -0400, David Edelsohn wrote:
> >>>>> H J Lu writes:
>
> >> > This is case for all extensions for i386. For x86-64, only
> >> > zero_extendsidi2 won't clobber CC.
> >> Again, for x86.
>
> HJ&
On Fri, May 05, 2006 at 01:05:55PM +0200, Fran?ois-Xavier Coudert wrote:
> Hi all,
>
> The following regression appeared between 20060504 and 20060505 on
> i686-linux. It is filed as PR 27443,and appears to be a consequence of
> a new optimization pass introduced by revision 113518.
>
It is
htt
On Thu, May 04, 2006 at 01:18:37PM -0700, Mark Mitchell wrote:
> H. J. Lu wrote:
>
> > export BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2
> > -fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -
On Fri, May 05, 2006 at 05:28:14PM +0200, Steven Bosscher wrote:
> On 5/5/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> >
> >On May 5, 2006, at 7:26 AM, François-Xavier Coudert wrote:
> >
> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
> >>
> >> Humpf. Does that mean that the patch wasn't
On Tue, May 16, 2006 at 12:49:13PM -0400, Andrew MacLeod wrote:
> On Tue, 2006-05-16 at 11:50 -0400, Andrew MacLeod wrote:
> > I *just* checked out mainline, and it is failing to build like so:
> >
> > (x86 with checking enabled)
> >
> > libbackend.a(print-rtl.o): In function `print_decl_name':
>
On Tue, May 16, 2006 at 10:23:37AM -0700, Andrew Pinski wrote:
>
> On May 16, 2006, at 10:20 AM, H. J. Lu wrote:
>
> >On Tue, May 16, 2006 at 12:49:13PM -0400, Andrew MacLeod wrote:
> >>On Tue, 2006-05-16 at 11:50 -0400, Andrew MacLeod wrote:
> >>>I *just* che
On Tue, May 16, 2006 at 10:41:22AM -0700, Andrew Pinski wrote:
>
> On May 16, 2006, at 10:39 AM, H. J. Lu wrote:
>
> >
> >I assume that -fno-common is added by hand since I didn't see it
> >in my build logs on Linux/x86, Linux/x86-64 and Linux/ia64.
>
> N
On Tue, May 16, 2006 at 02:08:13PM -0400, Andrew Pinski wrote:
> >
> > >
> > > On Tue, May 16, 2006 at 10:41:22AM -0700, Andrew Pinski wrote:
> > > >
> > > > On May 16, 2006, at 10:39 AM, H. J. Lu wrote:
> > > >
> > > >
On Fri, May 19, 2006 at 06:00:09PM +0200, Rainer Emrich wrote:
> Bootstrap failure in gnattools for ia64-unknown-linux-gnu. Complaining on
> missing libunwind.so.7
>
It is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17464
H.J.
FYI, changes between revisions 112624 and 112694 introduced a C++
run-time regression for 447.dealII in SPEC CPU 2006 on x86-64, which
is in C++. I am trying to find a testcase.
H.J.
On Sat, May 20, 2006 at 07:23:28AM -0700, H. J. Lu wrote:
> FYI, changes between revisions 112624 and 112694 introduced a C++
> run-time regression for 447.dealII in SPEC CPU 2006 on x86-64, which
> is in C++. I am trying to find a testcase.
>
It is
http://gcc.gnu.org/bugzilla/sho
With the patch in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592
Gcc 4.2 revision 113936 now passes SPEC CPU 2006 on Linux/x86,
Linux/x86 and Linux/ia64. But I have to apply 3 patches to SPEC
sources.
H.J.
On Sun, May 21, 2006 at 11:43:41PM +0200, Steven Bosscher wrote:
> On 5/21/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> >With the patch in
> >
> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592
> >
> >Gcc 4.2 revision 113936 now passes SPEC CPU 2006 on Linux/
On Mon, May 22, 2006 at 09:39:33AM +0200, Rainer Emrich wrote:
> H. J. Lu schrieb:
> > On Fri, May 19, 2006 at 06:00:09PM +0200, Rainer Emrich wrote:
> >> Bootstrap failure in gnattools for ia64-unknown-linux-gnu. Complaining on
> >> missing libunwind.so.7
> &
With trunk revision 113999, I got
if [ x"-fpic" != x ]; then \
/export/build/gnu/gcc/build-ia64-linux/./prev-gcc/xgcc
-B/export/build/gnu/gcc/build-ia64-linux/./prev-gcc/
-B/usr/gcc-4.2/ia64-unknown-linux-gnu/bin/ -c -DHAVE_CONFIG_H -g -O2
-I. -I/net/gnu-13/export/gnu/src/gcc/gcc/libiberty
Has anyone seen
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2701
It looks like the result of merging of intl from gcc. It doesn't work
for me in gcc either:
make[2]: Leaving directory
`/export/build/gnu/gcc/build-i686-linux/intl'
Doing install-info in intl
make[2]: Entering directory
`/ex
This is the beta release of binutils 2.17.50.0.2 for Linux, which is
based on binutils 2006 0526 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
The x86 psABI is very old and doesn't cover XMM registers. I'd like to
update x86 Linux calling convention for XMM register usage. I am not
sure if I should update stack alignment requirement.
The x86 psABI only requires 4 byte aligned stack. But the current gcc
assumes that the satck of a functio
On Wed, Jun 07, 2006 at 06:43:50PM +0200, Sandro Tolaini wrote:
>
> On 07/giu/2006, at 18:22, H. J. Lu wrote:
>
> >The x86 psABI is very old and doesn't cover XMM registers. I'd like to
> >update x86 Linux calling convention for XMM register usage. I am not
&
On Wed, Jun 07, 2006 at 04:08:14PM -0500, Menezes, Evandro wrote:
> HJ,
>
> > We have several choices for stack alignment requirement
> >
> > 1. Leave it unchanged. Gcc can do
> > a. Nothing. Let the program crash.
> > b. Align stack to 16byte if XMM registers are used locally and
> >
On Wed, Jun 07, 2006 at 05:17:39PM -0500, Menezes, Evandro wrote:
> > > > We have several choices for stack alignment requirement
> > > >
> > > > 1. Leave it unchanged. Gcc can do
> > > > a. Nothing. Let the program crash.
> > > > b. Align stack to 16byte if XMM registers are used
On Wed, Jun 07, 2006 at 06:38:52PM -0500, Menezes, Evandro wrote:
> > > > > > We have several choices for stack alignment requirement
> > > > > >
> > > > > > 1. Leave it unchanged. Gcc can do
> > > > > > a. Nothing. Let the program crash.
> > > > > > b. Align stack to 16byte if XMM registe
On Thu, Jun 08, 2006 at 05:25:32PM -0500, Menezes, Evandro wrote:
> > > I see. Provided a local is passed in a register to a
> > non-vararg function, it is still OK to align the stack.
> >
> > Given that we don't support 4 byte aligned stack at all with XMM
> > regisrers, I would prefer to incre
Hi all,
I'd like to catch automatically over/underflows on floating point and
integer arithmetic. I thought -ftrapv would do the trick but I don't
really understand how it works. From the latest manual online:
-ftrapv
This option generates traps for signed overflow on addition,
subtraction, mu
On 19/06/06, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> By the way, -ftrapv only works on integral types.
When it works. Last time I took a look, it was easily wiped out by
optimization.
So, it is of no use then... :-(
--
Eric Botcazou
--
Paulo Jorge Matos - pocm at sat inesc-id pt
Web
On 23/06/06, Laurynas Biveinis <[EMAIL PROTECTED]> wrote:
I'm still waiting for the testsuite to complete (it's been running
just for about 24 hours so far). In the meanwhile I'd like to discuss
the first performance results, which I've put on the Wiki:
First number is GCC with Boehm's GC and th
On 25/06/06, Laurynas Biveinis <[EMAIL PROTECTED]> wrote:
2006/6/25, Paulo J. Matos <[EMAIL PROTECTED]>:
> > combine.c: top mem usage: 52180k (13915k). GC execution time 0.66
> > (0.61) 4% (4%). User running time: 0m16 (0m14).
> >
>
> How are you collecting t
There are
ix86_init_mmx_sse_builtins ()
{
..
/* The __float80 type. */
if (TYPE_MODE (long_double_type_node) == XFmode)
(*lang_hooks.types.register_builtin_type) (long_double_type_node,
"__float80");
else
{
/* The __float80 type
On Mon, Jun 26, 2006 at 09:24:57PM -0700, Ian Lance Taylor wrote:
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> > On Jun 26, 2006, at 2:09 PM, Ian Lance Taylor wrote:
> >
> > > As far as I can see, it doesn't.
> >
> > You missed:
> >if (TARGET_MMX)
> > ix86_init_mmx_sse_builtins ();
>
On Tue, Jun 27, 2006 at 11:18:13AM +, Joseph S. Myers wrote:
> On Mon, 26 Jun 2006, H. J. Lu wrote:
>
> > I have no strong opinion on the support for __float80. But the current
> > behavior seems odd to me. Also, we have incomplete support for
> > __float128. There i
This is the beta release of binutils 2.17.50.0.3 for Linux, which is
based on binutils 2006 0715 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
o
ld -shared -Bsymbolic will reduce number of dynamic relocations in
a shared library. Unfortunately, it won't work correctly with C++
exception and maybe other language features.
However, I think it is possible to make -shared -Bsymbolic to work
for C++ by providing a way to specify a list of symbo
On Thu, Jul 27, 2006 at 03:37:33PM -0700, Geoffrey Keating wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
>
> > ld -shared -Bsymbolic will reduce number of dynamic relocations in
> > a shared library. Unfortunately, it won't work correctly with C++
> >
When one checkin is used to fix multiple bugs, it isn't easy to back
out just the offending bug fix only if one of the bug fixes causes
regression. Can we limit one bug fix per checkin?
Thanks.
H.J.
On Mon, Aug 21, 2006 at 05:25:09PM -0400, Andrew Pinski wrote:
> >
> > On Aug 21, 2006, at 11:59 AM, Andreas Jaeger wrote:
> > > Trunk fails to build for me with:
> >
> > Maybe related (from http://gcc.gnu.org/regtest/HEAD/):
> >
> > 2006-08-16T23:25:59Z 2006-08-17T14:40:57Z pass native 116195
>
On Thu, Aug 24, 2006 at 09:28:11AM -0400, Jack Howarth wrote:
> I should add that I see the same problem if I execute...
>
> make -k check RUNTESTFLAGS='--target_board "unix{,-m32}"'
>
> ...from the toplevel of the linux_obj directory on gcc trunk
> built on a x86_64 Fedora Core 5 machine. Th
If an instruction has latency 3 and throughput 1, should I write it as
(define_insn_reservation "simple" 3
(eq_attr "memory" "none")
"p0")
or
(define_insn_reservation "simple" 3
(eq_attr "memory" "none")
"p0,nothing*2")
Are they equivalent? What happens when there are fewer reservation
fma3d in SPEC CPU 2K failed with revision 116385 on x86 and x86-64.
revision 116362 is OK. Has anyone else seen it?
H.J.
On Fri, Aug 25, 2006 at 01:51:26PM -0700, H. J. Lu wrote:
> fma3d in SPEC CPU 2K failed with revision 116385 on x86 and x86-64.
> revision 116362 is OK. Has anyone else seen it?
>
Never mind. I have an old library.
H.J.
On Sun, Jul 30, 2006 at 04:38:38PM -0700, H. J. Lu wrote:
> When one checkin is used to fix multiple bugs, it isn't easy to back
> out just the offending bug fix only if one of the bug fixes causes
> regression. Can we limit one bug fix per checkin?
>
> Thanks.
It happened
Has anyone tried SPEC CPU 2006 with gcc mainline and 4.1 branch?
Currently, there is at least one regression affecting SPEC CPU 2006:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
I was wondering if anyone had run into problems with gcc. I need 3
patches for SPEC CPU 2006 to support gcc on Li
I got failures like
compiler exited with status 1
output is:
In file
/net/gnu-13/export/gnu/src/gcc/gcc/libgomp/testsuite/libgomp.fortran/reduction3.f90:20^M
^M
!$ if (i .ne. -2147483648 .or. any (ia .ne. -2147483648)) v = .true.^M
1^M
Error: Integer too big for its kind a
On Thu, Sep 07, 2006 at 05:03:35PM -0400, Andrew Pinski wrote:
> >
> > I got failures like
> >
> > compiler exited with status 1
> > output is:
> > In file
> > /net/gnu-13/export/gnu/src/gcc/gcc/libgomp/testsuite/libgomp.fortran/reduction3.f90:20^M
> > ^M
> > !$ if (i .ne. -2147483648 .or. any (
On Thu, Sep 14, 2006 at 07:54:42AM -0700, Andrew Pinski wrote:
> On Thu, 2006-09-14 at 12:48 +0400, Grigory Zagorodnev wrote:
> > Hi!
> > Trunk failed to bootstrap with revision 116941. Does anybody see the same?
>
> Yes I see the same on i686-linux-gnu which is running FC5.
>
http://gcc.gnu.org
This is the beta release of binutils 2.17.50.0.4 for Linux, which is
based on binutils 2006 0924 in CVS on sources.redhat.com 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 sectio
This is the beta release of binutils 2.17.50.0.5 for Linux, which is
based on binutils 2006 0927 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.5 release, the default output section LMA
(load memory address) has changed for allocatable sectio
I created a Google group to discuss generic ABI:
http://groups.google.com/group/generic-abi
It is by membership only. Let me know if you are interested.
Thanks.
H.J.
On Thu, Sep 28, 2006 at 10:45:38AM +0100, Jan Beulich wrote:
>
> 2) Why does the linker silently resolve the (32-bit PC-relative)
> relocation targeting an undefined weak symbol, yielding at
> run-time a non-zero address? While I can see the point of
Do you have a testcase? I can't reproduce it.
On Thu, Sep 28, 2006 at 02:53:30PM +0100, Christoph Hellwig wrote:
> On Wed, Sep 27, 2006 at 03:32:45PM -0700, H. J. Lu wrote:
> > I created a Google group to discuss generic ABI:
> >
> > http://groups.google.com/group/generic-abi
> >
> > It is by member
On Thu, Sep 28, 2006 at 09:54:10AM -0700, Joe Buck wrote:
> On Thu, Sep 28, 2006 at 07:11:25AM -0700, H. J. Lu wrote:
> > On Thu, Sep 28, 2006 at 02:53:30PM +0100, Christoph Hellwig wrote:
> > > On Wed, Sep 27, 2006 at 03:32:45PM -0700, H. J. Lu wrote:
> > > > I cre
On Thu, Sep 28, 2006 at 01:34:31PM -0500, Menezes, Evandro wrote:
> HJ,
>
> I think that it's great that all the de facto changes adopted for i386 would
> be put in an extension or appendix to its psABI.
>
> However, I lean towards an open discussion list. If necessary, I'd be glad
> to inves
On Thu, Sep 28, 2006 at 03:33:05PM +0100, Keir Fraser wrote:
>
> > Compile and link the attached C program as follows. I used gcc-4.1.1 and
> > binutils-2.17, but gcc >= 4.0.0 and binutils >= 2.16 probably suffice.
> >
> > # gcc -fpic -o test.o -c test.c
> > # ld -Ttext 1 -o test test.o
On Wednesday, February 16, 2005, at 10:03 AM, Serguei Kouratov wrote:
@implementation MyClass; /// <<<--- Test.mm:13: internal compiler
error...
Is the ';' even supposed to be allowed there? Maybe the bug is that
the non-ObjC++ compiler accepts this.
-tim
HANDLE_PRAGMA_PACK_PUSH_POP defined, also the gcc4 documentation does not say
these #pragmas are target spesific.
regards
---
Matthew J Fletcher
Embedded Software
Serck Controls Ltd
---
**
Serck Controls Ltd, Rowley Drive, Coventry
601 - 700 of 820 matches
Mail list logo
