http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46209
tbp changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46209
Summary: pmovmskb, useless sign extension
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46198
--- Comment #2 from tbp 2010-10-27 18:10:21 UTC ---
(In reply to comment #1)
> The situation is thus totally under control ;)
I concede you may have a point :)
Yet, for size builds, it really can't possibly make sense, ever (and that's
what lead m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46198
Summary: movd xmm, r (xmm -> GPR) may hit the stack
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45983
--- Comment #14 from tbp 2010-10-15 21:48:44 UTC ---
(In reply to comment #13)
> Author: jason
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165521
Richard, Jason, many thanks, that did it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45984
--- Comment #2 from tbp 2010-10-14 01:03:50 UTC ---
(In reply to comment #1)
> Author: jason
> Date: Thu Oct 14 00:50:26 2010
> New Revision: 165443
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165443
Thanks!
Am i right to infer this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45983
--- Comment #6 from tbp 2010-10-12 13:56:50 UTC ---
(In reply to comment #5)
> canonical type error -> PR45984.
Ah. So, both the current error and your previous patch fixing it all were
nothing but side-effects.
Tuning into the other channel. And
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45983
--- Comment #4 from tbp 2010-10-12 13:31:07 UTC ---
(In reply to comment #1)
> you probably built GCC with release checking?
Oh. Worse,
$ /usr/local/gcc-4.6-20101012/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-4.6-20101012/bin/g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45983
--- Comment #3 from tbp 2010-10-12 13:27:24 UTC ---
(In reply to comment #2)
> Older GCC for some reason complain about
> src/core/sys_log.h:95:40: error: invalid use of ‘__builtin_va_arg_pack ()’
There's code to handle that, but that's not obviou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45983
Summary: ICE: tree code 'template_parm_index' is not supported
in gimple streams with -lto
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priorit
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45668
--- Comment #4 from tbptbp at gmail dot com 2010-09-10 18:00 ---
(In reply to comment #2)
> I think you need __attribute((aligned(16))) on the original forward declared
> class too.
As stated that does, indeed, fix it.
So, ok, let's say previous versions were too permissive
at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
--- Comment #1 from tbptbp at gmail dot com 2010-09-10 17:34 ---
Created an attachment (id=21767)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21767&action=view)
large & fugly testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
--- Comment #4 from tbptbp at gmail dot com 2010-08-26 03:52 ---
Subject: Re: ICE, g++ 4.4.x, -fschedule-insns, unable to find
a register to spill in class '*REG'
Case closed then.
Not that it matters much, i don't even remember why -fschedule-insns
got there to beg
--- Comment #2 from tbptbp at gmail dot com 2010-08-26 03:43 ---
Forgot to say g++ 4.5 and 4.6 are immune.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45409
--- Comment #1 from tbptbp at gmail dot com 2010-08-26 03:35 ---
Created an attachment (id=21568)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21568&action=view)
one of the offender
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45409
edule-insns, unable to find a
register to spill in class '*REG'
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
Reporte
--- Comment #10 from tbptbp at gmail dot com 2010-08-21 00:49 ---
Subject: Re: pextr{b,w,d}, (worse than) redundant extensions
A quick check vs trunk tells me that not only pextr* are now sane but
about 2% movs*/movz* disappeared altogether (in that particular
binary).
Hat'
--- Comment #6 from tbptbp at gmail dot com 2010-08-19 19:21 ---
Subject: Re: pextr{b,w,d}, (worse than) redundant extensions
Thank you very much for this neat patch, Jakub.
Alas, in this case, zero extension would be suboptimal and any sign
extension simply wrong: i ask for a 64bit
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45336
pextrw, redundant zero (or otherwise) extension
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail d
--- Comment #8 from tbptbp at gmail dot com 2010-04-28 13:43 ---
Allow me to extend to you my most profuse praises and blessing; may all the
woman in your vicinity fall pregnant and your male progeny be granted abounding
chest hair.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
e removal
issues
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail d
--- Comment #6 from tbptbp at gmail dot com 2008-02-14 10:30 ---
Well, this was my best attempt so far at cornering that issue. I'm gonna wave a
dead chicken and try another attack vector. Sigh.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34864
--- Comment #4 from tbptbp at gmail dot com 2008-02-14 10:02 ---
Hmm. If i correctly understand what you're saying, *cough*, ldexp should be
immune to this missed-folding-because-a-builtin-isn't-recognized-as-such; but
in the original code that lead to PR34774 there's no
--- Comment #21 from tbptbp at gmail dot com 2008-02-14 07:52 ---
I've already submitted PR34864 for the folding but apparently i've overdone the
reduction; it's actually slightly tricky to trigger the issue (i mean i've
obviously hit another problem in that PR).
--- Comment #18 from tbptbp at gmail dot com 2008-02-13 17:21 ---
Ah ah!
[svn pull... build...]
Sadly it makes no difference yet, most certainly because of all the kludges i
had to stuff in: out of the 2213 tests (from the ucb-corpus for +,-,*,/,sqrt)
there's still 3 of them
--- Comment #2 from tbptbp at gmail dot com 2008-01-19 17:56 ---
Gah. Seems that i've managed to hit another issue than what i was after with my
simplistic testcase then, because in the original code there's no array
anywhere - but static definitions - and i get calls to
n selected for clarity)
--
Summary: ldexp variants, folding
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: t
--- Comment #16 from tbptbp at gmail dot com 2008-01-16 13:04 ---
Much helpful, many thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34774
--- Comment #14 from tbptbp at gmail dot com 2008-01-15 20:07 ---
I keep bumping into this issue and i'd really appreciate a clue about how to
workaround for the time being.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34774
--- Comment #12 from tbptbp at gmail dot com 2008-01-14 12:47 ---
Subject: Re: [4.1/4.2/4.3 Regression] templates, enumerations, overflow, ice
On 14 Jan 2008 12:35:51 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> The testcase in comment #3 looks valid(?),
--- Comment #7 from tbptbp at gmail dot com 2008-01-13 21:20 ---
Subject: Re: [4.1/4.2/4.3 Regression] templates, enumerations, overflow, ice
On 13 Jan 2008 21:06:07 -, rguenther at suse dot de
<[EMAIL PROTECTED]> wrote:
> No idea, but I doubt so ;)
Fantastic.
Now i als
--- Comment #5 from tbptbp at gmail dot com 2008-01-13 19:47 ---
Thanks a lot for your investigations.
May i ask if the apparent 'quenching' of sign mismatch - and related - warnings
(that is if you pile enough templates, due warning are never emitted), is in
any way related t
--- Comment #1 from tbptbp at gmail dot com 2008-01-13 18:50 ---
Created an attachment (id=14936)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14936&action=view)
preprocessed offender
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34774
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34774
--- Comment #10 from tbptbp at gmail dot com 2007-08-23 19:42 ---
Subject: Re: vector float | vector float is accepted
On 23 Aug 2007 18:49:22 -, pinskia at gmail dot com
<[EMAIL PROTECTED]> wrote:
> Read the next line. That is where my quote is from. Please read th
--- Comment #8 from tbptbp at gmail dot com 2007-08-23 18:45 ---
Subject: Re: vector float | vector float is accepted
On 23 Aug 2007 18:31:25 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> --- Comment #7 from pinskia at gcc dot gnu dot org 2007-08
--- Comment #6 from tbptbp at gmail dot com 2007-08-23 11:01 ---
(In reply to comment #5)
> Fixed.
Please fix the extension documentation accordingly.
--
tbptbp at gmail dot com changed:
What|Removed |Ad
--- Comment #24 from tbptbp at gmail dot com 2007-06-11 05:58 ---
Yes, but there's some fuss at 0 when you pile up a NR round.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723
--- Comment #22 from tbptbp at gmail dot com 2007-06-11 03:32 ---
I'm a bit late to the debate but...
At some point icc did such transformations (for 1/x and sqrt) but, apparently,
they're now removed. It didn't bother to plug every holes (ie wrt infinities)
but at lea
--- Comment #1 from tbptbp at gmail dot com 2007-06-11 03:02 ---
s/gcc-4.3-20070105/gcc-4.3-20070608/
--
tbptbp at gmail dot com changed:
What|Removed |Added
3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
GCC host triplet: x86-64, linux, gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32280
--- Comment #1 from tbptbp at gmail dot com 2007-01-29 12:08 ---
Created an attachment (id=12975)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12975&action=view)
fat testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30627
cc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
GCC host triplet: x86*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30627
--- Comment #8 from tbptbp at gmail dot com 2006-09-18 05:52 ---
Subject: Re: IV selection is messed up
On 17 Sep 2006 22:48:12 -, rakdver at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> Regarding the "-fprefetch-loop-arrays's heuristic is way off the mark
--- Comment #5 from tbptbp at gmail dot com 2006-09-01 02:53 ---
(In reply to comment #4)
> Actually this is just a problem of IV selection, what is happening is the IV
> selection chooses the 1024+(const char *)&base[quad] as the IV instead of just
> &base[quad] which
--- Comment #3 from tbptbp at gmail dot com 2006-09-01 02:04 ---
Hmm, that description is a bit wrong. What i really mean is that gcc trades x
long encodings for 1 short instead of other way around.
Bear with me, it's rather late here :)
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #2 from tbptbp at gmail dot com 2006-09-01 01:56 ---
Created an attachment (id=12165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12165&action=view)
test case preprocessed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
--- Comment #1 from tbptbp at gmail dot com 2006-09-01 01:55 ---
Created an attachment (id=12164)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12164&action=view)
test case source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
ion: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
GCC host triplet: x86*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
--- Comment #4 from tbptbp at gmail dot com 2006-08-11 06:43 ---
Subject: Re: missed optimization, redundant scalar SSE comparisons
On 11 Aug 2006 06:25:09 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> --- Comment #3 from pinskia at gcc dot gnu dot
--- Comment #2 from tbptbp at gmail dot com 2006-08-11 06:07 ---
Subject: Re: missed optimization, redundant scalar SSE comparisons
On 11 Aug 2006 05:52:26 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> Using unsigned char and a temp variable removes the p
optimization, redundant scalar SSE comparisons
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail
--- Comment #7 from tbptbp at gmail dot com 2006-03-12 21:35 ---
For clarification i should say that rt::mono::ray_t which uses vec_t etc, isn't
a source of trouble, it's part of the single ray path where mostly scalar ops
are used.
There's a symmetrical set of structure
--- Comment #6 from tbptbp at gmail dot com 2006-03-12 21:03 ---
You're right, but that's a _mm_store_ss/movss asking for a 4 bytes alignment
(which is satisfied) and not a movaps with a 16 bytes constraint. The latter
are what are causing problems.
--
http://gcc.gnu.or
--- Comment #2 from tbptbp at gmail dot com 2006-03-12 06:21 ---
Created an attachment (id=11025)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11025&action=view)
testcase #2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26650
--- Comment #1 from tbptbp at gmail dot com 2006-03-12 06:21 ---
Created an attachment (id=11024)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11024&action=view)
testcase #1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26650
stack access, smashing
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
GCC target triplet:
--- Comment #9 from tbptbp at gmail dot com 2006-02-01 14:28 ---
And you can add PR 25983 on top of it :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25990
--- Comment #6 from tbptbp at gmail dot com 2006-01-27 18:12 ---
Subject: Re: [gomp] transient ICE, c++
On 27 Jan 2006 18:06:23 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> That is a dup of bug 25990, then.
Technically, it's the other way around ;)
--- Comment #4 from tbptbp at gmail dot com 2006-01-27 18:04 ---
I'm not sure it's a dupe & fixed, because it also triggered with exceptions
disabled.
I don't know if the patch for PR/25873 has been applied to the gomp branch or
not, if not please ignore the spam, b
--- Comment #2 from tbptbp at gmail dot com 2006-01-27 13:51 ---
Woops, that ICE wasn't in trunk but the gomp branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25983
--- Comment #1 from tbptbp at gmail dot com 2006-01-26 20:42 ---
Created an attachment (id=10737)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10737&action=view)
Preprocessed offender
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25983
Summary: [gomp] transient ICE in trunk, c++
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
GCC host triplet: x86-64, linux, gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25983
--- Additional Comments From tbptbp at gmail dot com 2005-05-09 22:20
---
Additional note, using -fno-gcse slightly reduce the cruft (this one is my new
pet peeve :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21463
--- Additional Comments From tbptbp at gmail dot com 2005-05-09 08:50
---
I forgot to say that using ternary operators or if/else while changing the
codegen slightly doesn't make much difference.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21463
--- Additional Comments From tbptbp at gmail dot com 2005-05-09 08:46
---
I'm going to ping this bugreport because there's still some very bad interaction
with gcse in current gcc.
Just compile the 'packet_intersection.cpp' testcase with ie g++-4.1-4120050501
nent: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: x86*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21463
gnedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: x86*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21408
--- Additional Comments From tbptbp at gmail dot com 2005-05-05 23:58
---
For future reference, i'm including my end-user offline answer to Uros regarding
always_inline usage.
Here we go:
> I was trying to take a quick look at your bugreport regarding
> always_inline attrub
--- Additional Comments From tbptbp at gmail dot com 2005-04-26 14:29
---
Subject: Re: SSE intrinsics not inlined, sometimes.
On 26 Apr 2005 13:25:20 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> That is PR 19639.
Oh! A patch.
Sorry for the additionnal n
--- Additional Comments From tbptbp at gmail dot com 2005-04-26 12:45
---
Let's have some more fun.
Take the silly testcase up there, add this:
struct foo_t {
bool dummy;
__attribute__ ((always_inline)) foo_t() {}
};
change finalblow into that:
bool finalblow(const __m
ed, sometimes.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: x86*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21195
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 23:42
---
d-19680-1 + d-19680-3 isn't as good, 14.9fps, as some silly stack movements are
induced; ie:
40265f: 0f 29 04 24 movaps %xmm0,(%esp)
402663: 0f 57 c0xorps %xmm0,
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 23:28
---
Wow! We got a winner. 15.8 fps with -fno-gcse, inlining and only d-19680-3.
402680: 66 0f 6f d1 movdqa %xmm1,%xmm2
..
402688: 66 0f db 50 30 pand 0x30(%eax),%xmm2
40268d
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 22:58
---
In previous test i've used a crufted string of compilation options; i've removed
all that crap for -O3 -march=k8 -mfpmath=sse -fno-gcse -fno-exceptions.
The second patch, hack sse simode inputs, is a sm
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 22:21
---
Oops, my bad. Thought pshufd mixed both operands à la shufps; i'm obviously not
familiar with the integer side of SSE.
And yes the combination is a lose, albeit a small one around 3%. But i'm timing
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 20:35
---
Hmm, there's something fishy with _mm_set1_epi32.
With your patches there's no stack copy anymore but, with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19714 testcase, i get:
00401080 :
401080:
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 20:18
---
-fno-gcse is a godsend, instant speedup and most of the sillyness when inlining
is gone.
Now i've applied both your patches, and while there's promising they also
triggers their own nastyness; gcc is
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 14:14
---
Yes, and i'm not asking for a GPR->SSE transfer. What i'm asking is why gcc
feels the urge to copy that memory reference to the stack before fooling around
with it.
The full sequence is:
401298:
--
What|Removed |Added
Keywords||missed-optimization, ssemmx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19714
site _mm_set1_epi32
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
CC: gcc-bugs at
--- Additional Comments From tbptbp at gmail dot com 2005-01-30 18:59
---
Ah! Seems that another temporary isn't eliminated, much like
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19274, this time with
_mm_set1_epi32.
40129b: 89 44 24 1c mov%eax,0x1c
--- Additional Comments From tbptbp at gmail dot com 2005-01-30 18:40
---
Yes that's not a win per se but even with those "unrolled" addr computations its
encodings end up generally tighter, ie:
gcc:
40114d: c1 e1 04shl$0x4,%ecx
401150:
--- Additional Comments From tbptbp at gmail dot com 2005-01-30 13:37
---
But i had to rewrite the hit_t structure in a way more closer to what's found in
the original source to avoid the same useless cloning i noted earlier with gcc.
Something like:
union float4_t {
float
--- Additional Comments From tbptbp at gmail dot com 2005-01-30 08:07
---
I'm sorry for providing such a poor testcase.
Here's the kind of *48 sequence i'm seeing, k8 codegen; that's happening at a
point where's there's quite some register pressure a
--- Additional Comments From tbptbp at gmail dot com 2005-01-29 03:15
---
Some recent discussion about related symptoms.
http://gcc.gnu.org/ml/gcc/2005-01/msg01667.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18463
--- Additional Comments From tbptbp at gmail dot com 2005-01-28 23:35
---
Created an attachment (id=8095)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8095&action=view)
Various address generation snippets
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19463
--- Additional Comments From tbptbp at gmail dot com 2005-01-14 03:51
---
While we're at it, in pmmintrin.h, the DAZ related macros are conditionnalized
on __SSE3__ definition and that's not quite right.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19418
--- Additional Comments From tbptbp at gmail dot com 2005-01-13 05:44
---
They are described in the SSE2 documentation chapter and defined in emmintrin.h
that way:
/*
* Support for casting between various SP, DP, INT vector types.
* Note that these do no conversion of values, they
ty: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19418
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19274
--- Additional Comments From tbptbp at gmail dot com 2005-01-04 12:39
---
Created an attachment (id=7870)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7870&action=view)
All hell broke lose
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19252
ons in SSE code
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
CC: gcc-
--- Additional Comments From tbptbp at gmail dot com 2005-01-03 13:14
---
Created an attachment (id=7863)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7863&action=view)
One place with described symptoms
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19240
vy
code, x86/SSE
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
1 - 100 of 102 matches
Mail list logo
