On Mon, Mar 15, 2010 at 5:24 AM, Jim Wilson wrote:
> On 03/10/2010 10:48 PM, fanqifei wrote:
>>
>> For below piece of code, the instruction "clr.w a15" obviously doesn't
>> belong to the inner loop.
>> 6: bd f4 clr.w a15; #clear to zero
>> 8: 80 af 00 std.w a10 0x0 a15;
On 03/17/2010 12:04 AM, H.J. Lu wrote:
> __SSE__/-msse enables i686 ISA. Does i686 ISA support
> atomic operations?
>
If you are willing to contribute to these issue, please add your
comments to the audit trail of libstdc++/34106 and figure out with
Johannes a good clean-up for 4.6.0 (including
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 reworked *completely* by its main
Snapshot gcc-4.4-20100316 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100316/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
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 reworked *completely* by its maintainers,m
we have another PR for this, and I don't want __S
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 for
> parallel-mode which re
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 for
parallel-mode which really is tailored by and large to modern 64-bit
machines. For fur
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 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.
Paolo.
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 __pentium4.
>>
> Ah, ok, this is
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 __pentium4.
>
Ah, ok, this is what I was missing! We have *more* than i686. Thus I can
che
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.
>>> Why should be __i686 special? i686
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.
>> Why should be __i686 special? i686 does have __i586 features too, should it
>> define also __i58
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 if the processor supports it.
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 been introduced.
>>> You could add a differe
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 been introduced.
>> You could add a different macro if you want.
>> Why should be __i686 special? i6
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 been introduced.
> You could add a different macro if you want.
> Why should be __i686 special? i686 does have __i586 features too, should it
> define also __i
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 if the processor supports it.
> >
> If I understand correctly the logic underlying the
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 if the processor supports it.
>
If I understand correctly the logic underlying the recent work in this
area, I think we certainly want your patch, because o
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,
>> PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_NO_SAHF},
>>
>>
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,
> PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_NO_SAHF},
>
> For -march=x86-64, __k8 is defined. However, real K8 supports:
On Tue, Mar 16, 2010 at 12:28 PM, David Miller wrote:
> From: Richard Henderson
> Date: Tue, 16 Mar 2010 11:31:44 -0700
>
>> On 03/12/2010 09:33 PM, David Miller wrote:
>>> I couldn't figure out immediately how to fix this as the
>>> way LTO does spec overriding and such looked non-trivial.
>>
>>
On Tue, Mar 16, 2010 at 12:32 PM, Paolo Carlini
wrote:
> Hi,
>
> I'm rather surprised that now, in the "sane default world", only __i386 is
> defined, whereas __i686 is not on x86_64 -m32, I need -march=i686 on the
> command line (together with -m32).
>
> I noticed that while analyzing libstdc++/4
From: Richard Henderson
Date: Tue, 16 Mar 2010 12:53:47 -0700
> On 03/16/2010 12:28 PM, David Miller wrote:
>> It's not the assemblers fault.
>>
>> We're using %hi() and expecting the assembler to emit a
>> PC relative relcation just because the symbol name happens
>> to be _GLOBAL_OFFSET_TABLE_
On 03/16/2010 12:28 PM, David Miller wrote:
> It's not the assemblers fault.
>
> We're using %hi() and expecting the assembler to emit a
> PC relative relcation just because the symbol name happens
> to be _GLOBAL_OFFSET_TABLE_ And it will do this, but only
> when -PIC. Changing that is pretty d
Hi,
I'm rather surprised that now, in the "sane default world", only __i386
is defined, whereas __i686 is not on x86_64 -m32, I need -march=i686 on
the command line (together with -m32).
I noticed that while analyzing libstdc++/43394, where I was surprised
that some preprocessor lines, legacy cod
From: Richard Henderson
Date: Tue, 16 Mar 2010 11:31:44 -0700
> On 03/12/2010 09:33 PM, David Miller wrote:
>> I couldn't figure out immediately how to fix this as the
>> way LTO does spec overriding and such looked non-trivial.
>
> It would not be a bad thing, IMO, if the sparc assembler
> were
On 03/12/2010 09:33 PM, David Miller wrote:
> I couldn't figure out immediately how to fix this as the
> way LTO does spec overriding and such looked non-trivial.
It would not be a bad thing, IMO, if the sparc assembler
were extended to be able to emit any reloc directly, without
needing a specifi
On Tue, Mar 16, 2010 at 10:04:04PM +0600, Alexey Salmin wrote:
> >> Wow. What for?
> >
> > Well, simply because it is not compiled with strict alignment. There might
> > also be some optimization in
> > memory operation that does unaligned accesses.
>
> I always thought that unaligned access is
Alexey Salmin wrote:
> I always thought that unaligned access is much slower than aligned one.
It is not *MUCH* slower, just slower (unless you cross cache line
boundary). Unaligned accesses are very useful for improving
performance of, among other things, certain hash functions (e.g. Paul
Hsieh'
On 03/17/2010 12:08 AM, Richard Guenther wrote:
On Tue, Mar 16, 2010 at 5:02 PM, Jie Zhang wrote:
Hi,
I'm looking at this FIXME in cp/typeck2.c.
/* FIXME: Ordered removal is O(1) so the whole function is
worst-case quadratic. This could be fixed using an aside
bitmap t
On Tue, Mar 16, 2010 at 5:02 PM, Jie Zhang wrote:
> Hi,
>
> I'm looking at this FIXME in cp/typeck2.c.
>
> /* FIXME: Ordered removal is O(1) so the whole function is
> worst-case quadratic. This could be fixed using an aside
> bitmap to record which elements must be removed an
On Tue, Mar 16, 2010 at 9:48 PM, Tristan Gingold wrote:
>
> On Mar 16, 2010, at 4:37 PM, Alexey Salmin wrote:
I am interested in an -mstrict-alignment option for x86.
>>>
>>> Not sure it will be useful. The libc still does unaligned accesses IIRC.
>>>
>>
>> Wow. What for?
>
> Well, simply be
Hi,
I'm looking at this FIXME in cp/typeck2.c.
/* FIXME: Ordered removal is O(1) so the whole function is
worst-case quadratic. This could be fixed using an aside
bitmap to record which elements must be removed and remove
them all at the same time. Or by merging
On Mar 16, 2010, at 4:37 PM, Alexey Salmin wrote:
>>> I am interested in an -mstrict-alignment option for x86.
>>
>> Not sure it will be useful. The libc still does unaligned accesses IIRC.
>>
>
> Wow. What for?
Well, simply because it is not compiled with strict alignment. There might
also
On Tue, Mar 16, 2010 at 9:05 PM, Tristan Gingold wrote:
>
> On Mar 16, 2010, at 3:50 PM, H.J. Lu wrote:
>
>> 2010/3/8 Paweł Sikora :
>>> hi,
>>>
>>> during development a cross platform appliacation on x86 workstation
>>> i've enabled an alignemnt checking [1] to catch possible erroneous
>>> code b
On Tue, Mar 16, 2010 at 4:11 PM, Dominique Dhumieres wrote:
> In the block "Handle constant exponents." in gcc/builtins.c, the condition
> !optimize_size has been replaced with optimize_insn_for_speed_p () between
> gcc 4.3 and 4.4, but I have not been able to find when and why.
> Does anybody rem
In the block "Handle constant exponents." in gcc/builtins.c, the condition
!optimize_size has been replaced with optimize_insn_for_speed_p () between
gcc 4.3 and 4.4, but I have not been able to find when and why.
Does anybody remembers the when and why?
This change make the optimization sensitive
On Mar 16, 2010, at 3:50 PM, H.J. Lu wrote:
> 2010/3/8 Paweł Sikora :
>> hi,
>>
>> during development a cross platform appliacation on x86 workstation
>> i've enabled an alignemnt checking [1] to catch possible erroneous
>> code before it appears on client's sparc/arm cpu with sigbus ;)
>>
>> i
2010/3/8 Paweł Sikora :
> hi,
>
> during development a cross platform appliacation on x86 workstation
> i've enabled an alignemnt checking [1] to catch possible erroneous
> code before it appears on client's sparc/arm cpu with sigbus ;)
>
> it works pretty fine and catches alignment violations but
The intent was to clear up some stuff in the README.
When I noticed that I had affected other files, I had tried to put
everything back. Obviously a glitch. I'll fix it when I get home
tonight.
On Mon, Mar 15, 2010 at 11:00 PM, David Miller wrote:
>
> Ever since your changes installed on March
On Mon, 15 Mar 2010, Richard Guenther wrote:
> 42509, arm-gnueabi doesn't bootstrap but is a primary target
The primary target is arm-eabi, which is a bare-metal target; the arm-eabi
and mipsisa64-elf references must be understood as referring to building
and testing a cross compiler from some
Richi, Steven,
>> To be fair the people of that company do not expose bugs proportional
>> to their headcount either.
>
> Neither do I, and yet I try to help ;-)
Now, now, you two :-)
Paul
On Tue, Mar 16, 2010 at 12:25 PM, Richard Guenther wrote:
> On Tue, 16 Mar 2010, Steven Bosscher wrote:
>
>> On Tue, Mar 16, 2010 at 11:12 AM, Richard Guenther wrote:
>> > On Mon, 15 Mar 2010, NightStrike wrote:
>> >
>> >> On Mon, Mar 15, 2010 at 12:18 PM, Richard Guenther
>> >> wrote:
>> >> >
On Tue, 16 Mar 2010, Steven Bosscher wrote:
> On Tue, Mar 16, 2010 at 11:12 AM, Richard Guenther wrote:
> > On Mon, 15 Mar 2010, NightStrike wrote:
> >
> >> On Mon, Mar 15, 2010 at 12:18 PM, Richard Guenther
> >> wrote:
> >> > As maintainers do not care for P1 bugs in their maintainance area
>
On Tue, Mar 16, 2010 at 11:12 AM, Richard Guenther wrote:
> On Mon, 15 Mar 2010, NightStrike wrote:
>
>> On Mon, Mar 15, 2010 at 12:18 PM, Richard Guenther wrote:
>> > As maintainers do not care for P1 bugs in their maintainance area
>> > so will the release managers not consider them P1.
>>
>> P
On Mon, 15 Mar 2010, NightStrike wrote:
> On Mon, Mar 15, 2010 at 12:18 PM, Richard Guenther wrote:
> > As maintainers do not care for P1 bugs in their maintainance area
> > so will the release managers not consider them P1.
>
> Probably not the best reason to downgrade a bug, eh?
Well - patche
> The problem is that it won't be as simple as that. You'll have to extend
> the C++ parser to accept those new RID_ values that it was previously never
> expecting to see in those contexts, I would think (but haven't verified
> against the source yet). The C++ parser is a hand-coded recursive-
> 42509, arm-gnueabi doesn't bootstrap but is a primary target
I haven't had the time in the past few weeks to work on this
effectively. I'll be able to find some time to work on this during this
week and will get back on this.
cheers
Ramana
> If you don't know anything about register class preferencing or reload as
> yet, then this is probably not going to make much sense to you, but it isn't
> anything important you need to worry about at this point. It is a very
> minor performance optimization.
>
It makes sense to me now, though I
50 matches
Mail list logo
