Hi,
This release has been delayed for several months. There are no
tarballs. Please get it directly from linux/release/2.22.51.0.1 branch
at
http://git.kernel.org/?p=linux/kernel/git/hjl/binutils.git;a=summary
H.J.
This is the beta release of binutils 2.22.51.0.1 for Linux, which is
based
improve SPEC CPU performance by another 5%
over the current x32 implementation. I am putting this on hjl/x32/addr32 branch
at
http://gcc.gnu.org/git/?p=gcc.git;a=summary
I also backported it to GCC 4.6 on hjl/x32/gcc-4_6-branch branch.
--
H.J.
Hi,
The Linux binutils source tar ball is available from:
http://www.kernel.org/pub/linux/devel/binutils/
again. I also uploaded tar balls for some older releases, dating back
to release 2.21.51.0.5.
H.J.
---
This is the beta release of binutils 2.22.52.0.1 for Linux, which is
based on
Hi,
I fixed 2 local IFUNC symbol bugs.
H.J.
---
This is the beta release of binutils 2.19.51.0.12 for Linux, which is
based on binutils 2009 0716 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
ry tar ball for RedHat
EL 4.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
07/21/2009
www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
07/22/2009
or the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
09/08/2009
een fixed in mainline.
--
H.J.
;err-log.txt
> $ tail err-log.txt
> configure: error: cannot compute sizeof (long long)See `config.log' for more
> details.
> make[2]: *** [configure-stage3-gcc] Error 77
> make[2]: *** Waiting for unfinished jobs
>
This may be:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
H.J.
ing back to revision 151853.
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
--
H.J.
so different for RTEMS.
>
It may be:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
--
H.J.
nstructions.
>
Does this fix:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34653
--
H.J.
gt;
I think you should check the required libelf features in configure script:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41336
FWTW, libelf in Fedora 11 works fine.
H.J.
source files with error report
> Note that list may not be accurate in some cases,
> so please double check that the problem can still
> be reproduced with the set of files listed.
> Consider also -gnatd.n switch (see debug.adb).
>
This should be fixed also.
--
H.J.
ites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
10/10/2009
> __attribute__((optimize())) is definitely only half-baked.
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
--
H.J.
ted a bit to reflect the fact that the baker
>> got hit by a bus or something?
>
> I would rather suggest to rip out the half-baked code again.
>
I agree. The idea is good. But the design and implementation
are incomplete.
--
H.J.
comments?
Thanks.
H.J.
--
2009-11-03 Roland McGrath
* configure.ac (--enable-gold): Accept --enable-gold=both to
add gold to configdirs without removing ld.
* configure: Regenerated.
gold/
2009-11-03 H.J. Lu
* Makefile.am (install-exec-local): Install as
On Tue, Nov 3, 2009 at 3:23 PM, Roland McGrath wrote:
> --with is wrong for this. It's not about the ambient system built against.
> It's a feature selection for how you build binutils, which means --enable.
>
Here is the updated patch.
--
H.J.
2009-11-03 Roland McGrat
On Mon, Nov 2, 2009 at 3:06 PM, H.J. Lu wrote:
> Hi,
>
> This patch adds --enable-gold=both --with-linker=[bfd|gold] so that we
> can build both ld and gold. This patch will
>
> 1. Install ld as ld.bfd
> 2. Install gold as ld.gold
> 3. Install one of them as ld, selected
On Tue, Nov 3, 2009 at 9:09 PM, Roland McGrath wrote:
> I can't really tell how that's different from the patch I posted.
> It looks fine to me.
>
The difference is you can set the default linker.
--
H.J.
.tar.bz2. IA-32 binary tar ball for RedHat
EL 4.
4. binutils-2.20.51.0.3.ia64.tar.bz2. IA-64 binary tar ball for RedHat
EL 4.
5. binutils-2.20.51.0.3.x86_64.tar.bz2. X64_64 binary tar ball for RedHat
EL 4.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/p
gitweb and easier to clone.
>
Most of vendor branches are wrong. For example, there are many branches
under branches/redhat. But I only see one redhat branch in git.
BTW, I can't pull new changes from the new master into my local git branches
which are based on the old master.
--
H.J.
On Wed, Nov 18, 2009 at 10:09 AM, Bernie Innocenti wrote:
> El Wed, 18-11-2009 a las 07:13 -0800, H.J. Lu escribió:
>> On Sun, Nov 15, 2009 at 4:32 PM, Bernie Innocenti wrote:
>> > I repacked our (un)official git mirror (http://gcc.gnu.org/git) with
>> >
>> &g
t;> Should we try to get this in now?
>
> I'm sure this makes sense, but a gcc test case would be even better.
> If this can be detected in the gcc test suite it'll be found and
> fixed long before y'all in kernel land get to see it. That's the
> only way to guaran
On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley wrote:
> H.J. Lu wrote:
>> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote:
>>> Steven Rostedt wrote:
>>>> Ingo, Thomas and Linus,
>>>>
>>>> I know Thomas did a patch to force the -mtune=gene
FWIW, I have been using git to maintain my patches. I created a branch
for each patch.
Update and merge are almost automatic. It works quite well for me.
H.J.
On Wed, Nov 25, 2009 at 3:51 PM, Lu, Hongjiu wrote:
> Sorry for that. I did send an email and though it was an obvious fix. I gu
is set to zero by xor'ing it with itself), before
> they are completely filled with the mov{l,h}ps instructions ?
>
I think it is used to avoid partial SSE register stall.
--
H.J.
that gcc never zeros the upper 63 bits in register nor
on stack, should we update x86-64 psABI to reflect what gcc
really does?
Thanks.
--
H.J.
On Tue, Dec 8, 2009 at 8:50 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 7 Dec 2009, H.J. Lu wrote:
>
>> ---
>> When a value of type _Bool is passed in a register or on the stack,
>> the upper 63 bits of the eightbyte shall be zero.
>> ---
>
> That was the
On Wed, Dec 9, 2009 at 2:04 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 8 Dec 2009, H.J. Lu wrote:
>
>> Both icc and gcc generate:
>>
>> [...@gnu-26 pr42324]$ cat b4.c
>> extern unsigned int bartmp;
>>
>> void foo(_Bool bar)
>> {
>> bart
On Wed, Dec 9, 2009 at 6:56 AM, Michael Matz wrote:
> Hi,
>
> On Wed, 9 Dec 2009, H.J. Lu wrote:
>
>> > ... because this part can only be guaranteed by the ABI. Without the
>> > above language a compiler would be free to implement any non-zero byte as
>>
;
>> > Right now they are specified in the psABI, you suggested to remove that
>> > specification.
>> >
>>
>> The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
>> (and higher bits as don't cares, the same way a char i
remove that
>>> specification.
>>>
>>
>> The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
>> (and higher bits as don't cares, the same way a char is passed), as
>> opposed to the current text which requires &l
On Wed, Dec 9, 2009 at 7:15 AM, H.J. Lu wrote:
> On Wed, Dec 9, 2009 at 7:10 AM, Michael Matz wrote:
>> Hi,
>>
>> On Wed, 9 Dec 2009, H. Peter Anvin wrote:
>>
>>> On 12/09/2009 06:56 AM, Michael Matz wrote:
>>> >>
>>> >
On Wed, Dec 9, 2009 at 7:51 AM, Andrew Haley wrote:
> H.J. Lu wrote:
>> On Wed, Dec 9, 2009 at 7:10 AM, Andrew Haley wrote:
>>> H. Peter Anvin wrote:
>>>> On 12/09/2009 06:56 AM, Michael Matz wrote:
>>>>>> Aren't bits in the _Bool byte of
On Wed, Dec 9, 2009 at 7:49 AM, Michael Matz wrote:
> Hi,
>
> On Wed, 9 Dec 2009, H.J. Lu wrote:
>
>> > Then fix the psABI.
>>
>> Don't we need to specify passing and returning char, short and int since
>> they are smaller than the integer class, whi
Hi,
When I visit:
http://gcc.gnu.org/ml/gcc-bugs/
http://gcc.gnu.org/ml/gcc-cvs/
at Wed Dec 9 10:41:43 PST 2009, I didn't see "December, 2009".
It was there yesterday. Has anyone else seen it? You may need to
clear browser cache first.
--
H.J.
On Wed, Dec 9, 2009 at 10:51 AM, David Daney wrote:
> H.J. Lu wrote:
>>
>> Hi,
>>
>> When I visit:
>>
>> http://gcc.gnu.org/ml/gcc-bugs/
>> http://gcc.gnu.org/ml/gcc-cvs/
>>
>> at Wed Dec 9 10:41:43 PST 2009, I didn't see "Decem
ry tar ball for RedHat
EL 4.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
12/14/2009
te the reason for this slowdown, I'd be
> glad to help, but I must admit that I'm no good at interpreting assembler.
>
> Any insight would be greatly appreciated.
>
You didn't what target you are using. Pentium D can run both 32bit
and 64bit. codes.
--
H.J.
gcc with sysroot, which points to your old glibc. If you want to
use the existing gcc, you need a special command line to link against
the old glibc.
--
H.J.
On Thu, Dec 17, 2009 at 10:48 AM, Douglas Gemignani
wrote:
> Hi,
>
> What command line? I found this -nostdinc and -I to include folders, -b also?
Here is a Makefile to link against the newly built glibc.
H.J.
> []s
> Douglas Gemignani
>
>
>
> On Thu, Dec 1
get dependent, something
like
/* Do not propagate loop invariant definitions inside the loop. */
if (targetm.foobar
&& DF_REF_BB (def)->loop_father != DF_REF_BB (use)->loop_father)
return;
--
H.J.
On Wed, Dec 23, 2009 at 10:06 AM, Paolo Bonzini wrote:
> On 12/23/2009 06:47 PM, H.J. Lu wrote:
>>
>> On Wed, Dec 23, 2009 at 8:41 AM, Paolo Bonzini wrote:
>>>
>>> On 12/23/2009 04:19 PM, Bingfeng Mei wrote:
>>>>
>>>> It seems th
onfigured my gcc with
-with-plugin-ld=ld.gold
If both linkers have the same name, it will be harder to
use ld by default and use gold only for plugin.
--
H.J.
On Tue, Jan 5, 2010 at 11:08 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> diff --git a/configure.ac b/configure.ac
>> index 407ab59..b349633 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -311,10 +311,11 @@ esac
>>
email about?
>
Many files in the top directories between gcc and src are out of sync.
You can do a diff on them to check it out.
--
H.J.
; badwarn.cpp: In function 'int foo()':
>> badwarn.cpp:12:1: warning: no return statement in function returning non-void
>>
>
> gcc 4.0.1, 4.2.1, and 4.3.4 don't warn about this. Looks like a regression.
>
> -- Ross Smith
>
>
It is caused by revision 138140:
http://gcc.gnu.org/ml/gcc-cvs/2008-07/msg00852.html
--
H.J.
On Tue, Jan 5, 2010 at 8:23 PM, H.J. Lu wrote:
> On Tue, Jan 5, 2010 at 11:08 AM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>
>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 407ab59..b349633 100644
>>> --- a/configure.a
r.bz2. IA-64 binary tar ball for RedHat
EL 4.
4. binutils-2.20.51.0.5.x86_64.tar.bz2. X64_64 binary tar ball for RedHat
EL 4.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
01/15/2010
;d like to release 4.4.3 next week.
>
I'd like to see ia64 backport for:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
in gcc 4.3/4.4.
Thanks.
--
H.J.
FC=no ;;
> *)
> - FC="$GFORTRAN" ;;
> + if test -x "$GFORTRAN"; then
> + FC="$GFORTRAN"
> + else
> + FC=no
> + fi ;;
> esac
> AC_PROG_FC(gfortran)
> FCFLAGS="$FCFLAGS -Wall"
>
> (untested)
>
> Paolo
>
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42872
--
H.J.
32bit or 64bit.
2. Which SSE extensions are available.
--
H.J.
ar.bz2. IA-64 binary tar ball for RedHat
EL 4.
4. binutils-2.20.51.0.6.x86_64.tar.bz2. X64_64 binary tar ball for RedHat
EL 4.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
02/07/2010
e performance cost of storing to / loading from memory at
> various points, as required to get the rounding on 387 (and there are
> still cases where excess precision means double rounding).
>
I think your C99 change caused a regression on ia32:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128#c10
--
H.J.
arget based
> on the host? Not too crazy, is it?
>
I agreed that gcc for x86 should choose a sensible default for 95% of
current x86 processors in use. People with those old processors can
use older gcc or -march=.
Default to SSE2 is a good first step.
--
H.J.
d first step.
>
> I think you vastly underestimate the number of older x86 processors in
> use.
>
There is nothing which stops them from using -march=i386. It just may not
be the default.
--
H.J.
On Sun, Feb 21, 2010 at 1:07 PM, Erik Trulsson wrote:
> On Sun, Feb 21, 2010 at 12:27:34PM -0800, H.J. Lu wrote:
>> On Sun, Feb 21, 2010 at 12:22 PM, Erik Trulsson
>> wrote:
>> >>
>> >> I agreed that gcc for x86 should choose a sensible default for 95%
On Sun, Feb 21, 2010 at 9:27 AM, H.J. Lu wrote:
> On Sun, Feb 21, 2010 at 9:15 AM, Geert Bosch wrote:
>
>>> As I understand it, whether -mfpmath=387 (with excess precision) or
>>> -mfpmath=sse is the default is also considered part of the platform API
>>> (like w
ection
It didn't work.
Thanks.
--
H.J.
On Tue, Feb 23, 2010 at 9:22 AM, Andreas Schwab wrote:
> "H.J. Lu" writes:
>
>> Is there a way to update my SSH authorized_keys on gcc.gnu.org?
>
> See <http://sourceware.org/ml/overseers/2008-q2/msg00112.html>.
>
It doesn't work for me:
# ssh so
gt; should do the deed.
>
Does it work for anyone? I got
# ssh sourceware.org updatekey < ~/.ssh/id_dsa.pub
Permission denied (publickey,gssapi-with-mic).
--
H.J.
On Tue, Feb 23, 2010 at 9:35 AM, Christopher Faylor
wrote:
> On Tue, Feb 23, 2010 at 09:27:35AM -0800, H.J. Lu wrote:
>>On Tue, Feb 23, 2010 at 9:22 AM, Andreas Schwab wrote:
>>> "H.J. Lu" writes:
>>>
>>>> Is there a way to update my SSH
I've just been trying to get people who might know why the status quo
> is the way it is to weigh in before I approve it.
>
> H.J., could you update your patch to support --with-arch/cpu=native as Uros
> requested?
>
Here it is:
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01095.html
--
H.J.
figure \
--enable-clocale=gnu --with-system-zlib --enable-shared --with-d
emangler-in-ld --with-fpmath=sse i686-linux
CC="gcc -m32" CXX="g++ -m32" is the key.
--
H.J.
as of 2010-02-28, gcc will default to i686 unless you configure
gcc with i[345]86-os.
--
H.J.
elf.h usability... no
checking libelf/libelf.h presence... no
checking for libelf/libelf.h... no
checking libelf/gelf.h usability... no
checking libelf/gelf.h presence... no
checking for libelf/gelf.h... no
checking for the correct version of libelf... yes
I am using elfutils-libelf 0.145.
--
H.J.
violates cpu alignment rules.
>
> so, is it possible to instruct gcc-x86 to always use suitable loads/stores
> like on sparc/arm?
>
> [1] "AC" bit - http://en.wikipedia.org/wiki/FLAGS_register_(computing)
>
I am interested in an -mstrict-alignment option for x86.
--
H.J.
8", PROCESSOR_K8, CPU_K8,
PTA_64BIT | PTA_MMX | PTA_3DNOW | PTA_3DNOW_A | PTA_SSE
| PTA_SSE2 | PTA_NO_SAHF},
It isn't an issue in i386.c since PROCESSOR_K8 isn't used to check
ISAs. But using __k8 to check ISAs is a problem.
--
H.J.
erous.
>
> But even if we got past that, we need to get the assembler options
> right in order to enable instruction classes. For example we have to
> get -Av9a there when using VIS instructions.
>
> Other platforms are going to hit things like this too.
>
> LTO really needs to evaluate the specs correctly.
>
Can you store assembler options in some LTO section?
--
H.J.
On Tue, Mar 16, 2010 at 1:13 PM, Paolo Carlini wrote:
> On 03/16/2010 08:53 PM, H.J. Lu wrote:
>> The question is what processor macros should "-march=x86-64" define. There
>> is
>>
>> {"x86-64", PROCESSOR_K8, CPU_K8,
>> P
arch=i386?!?
>
> Paolo.
>
Checking __iX86 is a good idea for ISAs since it's meaning isn't well defined
nor enforced. For libstdc++ purpose, can you check __SSE2__ in addition to
__i686?
--
H.J.
On Tue, Mar 16, 2010 at 2:06 PM, H.J. Lu wrote:
> On Tue, Mar 16, 2010 at 2:03 PM, Paolo Carlini
> wrote:
>> On 03/16/2010 09:58 PM, Jakub Jelinek wrote:
>>> I don't think it is a good idea to change the meaning of the macros years
>>> after they have b
On Tue, Mar 16, 2010 at 1:58 PM, Jakub Jelinek wrote:
> On Tue, Mar 16, 2010 at 09:53:30PM +0100, Paolo Carlini wrote:
>> On 03/16/2010 09:40 PM, H.J. Lu wrote:
>> > We never defined __i686 for -m32 by default on x86_64. Here is
>> > a patch to define __i686 for -m32 i
On Tue, Mar 16, 2010 at 1:14 PM, Paolo Carlini wrote:
> On 03/16/2010 10:08 PM, H.J. Lu wrote:
>> I don't think it is a good idea to change the meaning of the macros years
>>> after they have been introduced.
>>> You could add a different macro if you want.
>>
On Tue, Mar 16, 2010 at 1:30 PM, Paolo Carlini wrote:
> On 03/16/2010 10:20 PM, H.J. Lu wrote:
>> That is not true. The new -m32 default ISA on x86-64 is i686 + MMX + SSE +
>> SSE2.
>> It is Pentium 4, not i686. For historical reason, we define __k8
>> instead of __
On Tue, Mar 16, 2010 at 2:36 PM, Paolo Carlini wrote:
> On 03/16/2010 10:33 PM, H.J. Lu wrote:
>> Please check __SSE__ since __k8 won't be defined for -march=atom.
> I don't care about Atom.
>
Do you care about -march=core2?
--
H.J.
On Tue, Mar 16, 2010 at 2:32 PM, Paolo Carlini wrote:
> On 03/16/2010 11:27 PM, H.J. Lu wrote:
>> Do you care about -march=core2?
> Ok, thanks, let's check __core2 too, but really, I don't want to fiddle
> too much with these macros in the 4.5.0 timeframe. This is code
On Tue, Mar 16, 2010 at 3:39 PM, Paolo Carlini wrote:
> On 03/16/2010 11:36 PM, H.J. Lu wrote:
>> As I said, you should check __SSE__ and be done with it. Otherwise you
>> will need to keep adding more checks for no good reasons.
>>
> As I said, that file we'll be
6_64.tar.bz2. X64_64 binary tar ball for RedHat
EL 4.
The primary sites for the beta Linux binutils are:
1. http://www.kernel.org/pub/linux/devel/binutils/
Thanks.
H.J. Lu
hjl.to...@gmail.com
03/18/2010
Hi,
Many comments for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43560
are missing from gcc-bugs archive:
http://gcc.gnu.org/ml/gcc-bugs/2010-03/
Is there a problem with gcc-bugs archive?
--
H.J.
may trigger the assembler
bug.
--
H.J.
export/home/arth/gnu/gcc-0401/i386-pc-solaris2.10/amd64/libgcc':
> configure:3254: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
>
> My builds on a sparc-sun-solaris2.10 from yesterday worked fine - on
> this machine GCC does _not_ use the '--disable-multilib' configuration
> switch. This mornings build has just started.
>
> My thanks to everyone working on GCC.
>
> Art Haas
>
It may be related to
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01483.html
--
H.J.
.
>
> cpu_id returns this for the qemu32 cpu model (test fails)
>
> a=0x633 b=0x800 c=0x1 d=0x781abfd
>
> this for the 486 model (test works)
>
> a=0x0 b=0x0 c=0x0 d=0x0
>
> this for pentium (test works)
>
> a=0x543 b=0x800 c=0x0 d=0x8001bf
>
> and this for "coreduo" (test fails)
>
> a=0x6e8 b=0x800 c=0x9 d=0x789fbff
>
> Is qemu reporting that it supports SSE and not doing a good
> enough job to make gcc happen?
>
I think your qemu lied. It reports SSE in cpuid, but it doesn't
support it.
--
H.J.
binutils-2.20.51.0.8.i686.tar.bz2. IA-32 binary tar ball for RedHat
EL 5.
3. binutils-2.20.51.0.8.ia64.tar.bz2. IA-64 binary tar ball for RedHat
EL 5.
4. binutils-2.20.51.0.8.x86_64.tar.bz2. X64_64 binary tar ball for RedHat
EL 5.
The primary sites for the beta Linux binutils are:
1. http
/
gcc-4_3-branch/
gcc-4_4-branch/
under /branches/ix86. I think we should either mirror
or branches or don't mirror branches with more than
one `/' in branch name after /branches.
Thanks.
--
H.J.
On Linux/x86-64, "make check" gave me
make[6]: *** No rule to make target `check-lto', needed by `check'.
Where does it come from?
--
H.J.
operands[1], SImode, 0);
else
gcc_unreachable ();
})
Aren't
emit_insn
(gen_sse2_cvtdq2p (operands[3], operands[4]));
DONE;
missing at the end?
--
H.J.
OK if I commit it to ira-merge
> as well?
>
Please commit it to ira-merge if you haven't done so.
Thanks.
--
H.J.
7;
> /GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so:
> undefined reference to [EMAIL PROTECTED]'
>
> This is on solaris 2.10, using gnu ld (version 2.18..)
>
> Any ideas on how to get around this?
>
Please use g++ instead of gcc.
--
H.J.
ich has no "make check" nor SPEC
CPU 2K/2006 regressions on platforms available.
--
H.J.
avxintrin.h:
#ifndef _IMMINTRIN_H_INCLUDED
# error "Never use directly; include instead."
#else
AVX intrinsics
#endif /* _IMMINTRIN_H_INCLUDED */
Any comments?
Thanks.
--
H.J.
files in .
The patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00145.html
You can provide a patch against it to include AMD intrinsic header files.
--
H.J.
make any senses. I think
-mavx should turn off -msse5/-msse4a and vice versa.
Thanks.
--
H.J.
Hi,
I'd like to pointer that the new __optimize__ attribute doesn't work
correctly:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
Will it be fixed in 4.4?
H.J.
---
On Mon, Nov 17, 2008 at 2:15 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> Status
> ==
>
>
added -mfma in AVX patch. Currently it is a dummy.
>> Also I am not sure if "-mavx -msse5" or "-mavx -msse4a" make any
> senses. I
>> think
>> -mavx should turn off -msse5/-msse4a and vice versa.
>>
> Yes. We can have -mavx turn off -msse5/-msse
8192
That limits stack to 8MB. Please change it to 1GB.
> coredump(blocks) unlimited
> nofiles(descriptors) 256
> vmemory(kbytes) unlimited
>
> Do you have any suggestions to speed up my program?
>
--
H.J.
On Wed, Nov 19, 2008 at 7:18 PM, Nicholas Nethercote
<[EMAIL PROTECTED]> wrote:
> On Tue, 18 Nov 2008, H.J. Lu wrote:
>
>>> I used malloc to create my arrays instead of creating the in the stack.
>>> My program is working now but it is very slow.
>>>
>
this normal ?
>
See
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33966
--
H.J.
401 - 500 of 1206 matches
Mail list logo
