http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #10 from dean at arctic dot org ---
On Thu, 4 Jul 2013, jakub at gcc dot gnu.org wrote:
> I'm not 100% sure about CLZ/CTZ in the patch, because it could return any
> value
> for argument of 0, but as we document i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17838
dean at arctic dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
--- Comment #7 from dean at arctic dot org 2009-09-17 11:06 ---
(In reply to comment #6)
> Without accounting for the push/pop in CFI you will not be able to accurately
> process asynchronous unwind events.
>
just to be sure i understand -- you're saying a %rsp mod
--- Comment #5 from dean at arctic dot org 2009-09-17 10:54 ---
(In reply to comment #4)
>0: b8 80 ff ff ff mov$0xff80,%eax
>5: 6a 80 pushq $0xff80
>7: 58 pop%rax
>
should be:
0
--- Comment #4 from dean at arctic dot org 2009-09-17 10:51 ---
(In reply to comment #3)
> For the push/pop you need to add 2 bytes to the CFI which makes it useless
> compared to mov $imm32,reg.
>
note that my push/pop example said -128..127 and "push $imm8"
--- Comment #2 from dean at arctic dot org 2009-09-17 10:28 ---
stop closing bugs you have no understanding of.
--
dean at arctic dot org changed:
What|Removed |Added
--- Comment #4 from dean at arctic dot org 2009-09-17 10:27 ---
(In reply to comment #2)
> 32bit moves and other instructions _SIGN_EXTEND_ results to 64bits on x86_64
wait i just reread your statement.
the amd64 ISA zero-extends 32-bit register writes out to 64-bits. please go
r
--- Comment #3 from dean at arctic dot org 2009-09-17 10:23 ---
(In reply to comment #2)
> (In reply to comment #1)
>
> > and in this case the "mov %rdx,%rax" could be "mov %edx,%eax" because of the
> > dominating movzbl.
>
> 32bit moves and
--- Comment #11 from dean at arctic dot org 2008-02-19 17:42 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] jump to
middle of loop on entry with using old version of an variable
On Mon, 19 Feb 2008, xinliangli at gmail dot com wrote:
> Note that assignment of s0 = s in the loop
--- Comment #1 from dean at arctic dot org 2008-01-03 19:27 ---
oops i should have used an "unsigned long" for the tag rather than unsigned
long long, not that it matters much.
here's an expanded example showing another unnecessary REX:
extern unsigned long table[];
un
: unassigned at gcc dot gnu dot org
ReportedBy: dean at arctic dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34653
--- Comment #1 from dean at arctic dot org 2007-11-28 01:43 ---
this appears to be a regression between gcc 4.1.x and 4.2.x. i had to switch
the intrinsic to _mm_cvtsi64_si64x but it otherwise generates the same code on
4.3.x...
ubuntu 4.1.2:
% objdump -dr movq.o
movq.o: file
64
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dean at arctic dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC ho
--- Comment #1 from dean at arctic dot org 2007-10-30 18:43 ---
apparently the approved intrinsics for the "movq xmm,m64" / "movq m64,xmm"
instructions are _mm_loadl_epi64 and _mm_storel_epi64. i've asked intel to add
these to the ISA documentation because they
mponent: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dean at arctic dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33944
nu dot org
ReportedBy: dean at arctic dot org
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32869
--
Summary: -Os: shorter load immediates for x86_64
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedB
--- Comment #3 from dean at arctic dot org 2007-04-10 09:38 ---
nice... that seems to do the trick on idiv-assert.c:
10: 89 df mov%ebx,%edi
12: 83 c3 01add$0x1,%ebx
15: c1 ff 02sar$0x2,%edi
18: e8 00 00 00 00
Priority: P3
Component: pending
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dean at arctic dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzill
omponent: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dean at arctic dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30829
org
ReportedBy: dean at arctic dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
t gnu dot org
ReportedBy: dean at arctic dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29775
gcc dot gnu dot org
ReportedBy: dean at arctic dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27986
2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: pending
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dean at arctic dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC targ
24 matches
Mail list logo
