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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46209
tbp tbptbp at gmail dot com changed:
What|Removed |Added
Severity|normal |enhancement
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46198
--- Comment #2 from tbp tbptbp at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45983
--- Comment #14 from tbp tbptbp at gmail dot com 2010-10-15 21:48:44 UTC ---
(In reply to comment #13)
Author: jason
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165521
Richard, Jason, many thanks, that did it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45984
--- Comment #2 from tbp tbptbp at gmail dot com 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=gccview=revrev=165443
Thanks!
Am i
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45983
--- Comment #3 from tbp tbptbp at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45983
--- Comment #4 from tbp tbptbp at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45983
--- Comment #6 from tbp tbptbp at gmail dot com 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
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 #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=21767action=view)
large fugly testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
gnu dot org
ReportedBy: tbptbp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
--- 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
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
ReportedBy: tbptbp at gmail dot com
GCC
--- 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=21568action=view)
one of the offender
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45409
--- 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 #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 begin
--- 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's off
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
--- 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
(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 dot com
http://gcc.gnu.org
--- 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
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 dot com
http
--- 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 nothing but ldexp
--- 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 #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 (all
--- 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).
Right now i'm out
)
--
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: tbptbp at gmail dot com
--- 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 ldexpf
--- 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(?), at least
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 #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=14936action=view)
preprocessed offender
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34774
--- 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 to this bug
--- 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 also see
--- 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 |Added
--- 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-23 18:31
--- 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 the
whole section
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-06-11 03:02 ---
s/gcc-4.3-20070105/gcc-4.3-20070608/
--
tbptbp at gmail dot com changed:
What|Removed |Added
--- 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 least got the case
--- 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
ReportedBy: tbptbp at gmail dot com
GCC host triplet: x86*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30627
--- 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=12975action=view)
fat testcase
--
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 part,
gcc badly
: 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 #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=12164action=view)
test case source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
--- 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=12165action=view)
test case preprocessed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
--- 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_bug.cgi
--- 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 causes the bigger
--- 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 problem
--- 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 org 2006-08
at gmail dot com
GCC host triplet: x86*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28691
--- 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.org/bugzilla
--- 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 structures in rt::packet
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: x86, x86-64
http://gcc.gnu.org/bugzilla
--- 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=11024action=view)
testcase #1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26650
--- 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=11025action=view)
testcase #2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26650
--- 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 #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 #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, but with a fresh svn
--- 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 ;)
Anyway, it's
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
--- 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=10737action=view)
Preprocessed offender
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25983
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: 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
--- 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
for ia32 to convince
--- 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 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-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 attrubite. Just
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=21408
--- 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 __m128
--- 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 noise
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
--- 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: 8b 42 28
--- 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 so fond
--- 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 eliminated(int):
401080
--- 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
the whole
--- 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 small win
--- 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 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,%xmm0
--- 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 and it really doesn't help
--- 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 f[4
--- 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: 8d 41 30
--- 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(%esp
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=19714
--
What|Removed |Added
Keywords||missed-optimization, ssemmx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19714
: 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
--- 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=8095action=view)
Various address generation snippets
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
--- 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
-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
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
--- 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
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=19274
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-bugs at gcc dot
--- 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=7870action=view)
All hell broke lose
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19252
: 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-bugs at gcc dot gnu dot org
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
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
1 - 100 of 101 matches
Mail list logo
