tatus: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: m at rolle dot name
Target Milestone: ---
Related to bug 18770 (for gas). Same confusion as to allowed memory operand
address sizes.
If I assembl
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: m at rolle dot name
Target Milestone: ---
I did not indicate Critical only because gas does not produce incorrect code.
However, the bug is a serious one because
https://sourceware.org/bugzilla/show_bug.cgi?id=18739
Michael Rolle changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE
Severity: minor
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: m at rolle dot name
Target Milestone: ---
Same as bug 13571. I'm filing a new bug because the other one was for version
2.20 and has probably been forgot
https://sourceware.org/bugzilla/show_bug.cgi?id=13571
Michael Rolle changed:
What|Removed |Added
CC||m at rolle dot name
--- Comment #1
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: m at rolle dot name
Target Milestone: ---
objdump disassembles gather/scatter instructions showing the vector operand
size as the memory operand size. However, the Intel doc says it
https://sourceware.org/bugzilla/show_bug.cgi?id=18736
--- Comment #1 from Michael Rolle ---
Note the objdump problem should be forwarded to the binutils component.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-bi
https://sourceware.org/bugzilla/show_bug.cgi?id=18736
Michael Rolle changed:
What|Removed |Added
Component|binutils|gas
--
You are receiving this mail b
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: m at rolle dot name
Target Milestone: ---
gather/scatter instructions require a memory size to match the vector register
size. However, the memory size is actually the element size
: binutils
Assignee: unassigned at sourceware dot org
Reporter: m at rolle dot name
Target Milestone: ---
The vcvtsi2sd instruction has the {er} decorator associated with the last
operand. See Intel doc:
EVEX.NDS.LIG.F2.0F.W1 2A /r
VCVTSI2SD xmm1, xmm2, r/m64{er}
However
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: m at rolle dot name
Target Milestone: ---
gas complains about "invalid register operand" for an instruction using ymm16
.. ymm31, or same for xmm. Likewise if it uses ymm
https://sourceware.org/bugzilla/show_bug.cgi?id=18700
--- Comment #1 from Michael Rolle ---
First off, I might be misinterpreting the Intel doc (319433-022
OCTOBER 2014), in which case gas might be doing the right thing after all.
I wrote some EVEX instructions, both scalar and vector, and both
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: m at rolle dot name
Target Milestone: ---
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils
https://sourceware.org/bugzilla/show_bug.cgi?id=18638
--- Comment #4 from Michael Rolle ---
In the first case, I got the correct results when I assembled the .s file. The
file was gas/i386/x86-64-avx-scalar.s in the gas/testsuite directory. objdump
of the resulting .o file show the correct byt
https://sourceware.org/bugzilla/show_bug.cgi?id=18639
--- Comment #1 from Michael Rolle ---
Make that Bug 18638 above, not 18636.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@g
https://sourceware.org/bugzilla/show_bug.cgi?id=18638
--- Comment #3 from Michael Rolle ---
In the second case, it was my mistake. I was reading the reg field as the rm
field. The rm field is in fact 100b. So there's no bug.
--
You are receiving this mail because:
You are on the CC list for
: enhancement
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: m at rolle dot name
Target Milestone: ---
This is a big project I am suggesting, but I think it is very important.
I just filed bug 18636, in which incorrect code is
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: m at rolle dot name
Target Milestone: ---
Two issues here, both with the binary code generated by gas. These are seen in
the testsuite files.
(1) vmovq rcx, xmm4
Generates C4 E1 FD
https://sourceware.org/bugzilla/show_bug.cgi?id=17712
--- Comment #2 from Michael Rolle ---
Actually, a jump to an absolute 64-bit address using a 32-bit displacement
isn't possible anyway, no matter what the linker or loader tries to do.
So I think this instruction should be illegal in all case
https://sourceware.org/bugzilla/show_bug.cgi?id=17712
--- Comment #1 from Michael Rolle ---
Actually, it's worse than that. Look at the actual code bytes assembled.
Disassembly of section .text:
<.text>:
0: ff d0 call rax
2: ff d0
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: m at rolle dot name
This appears in the gas testsuite, for file
gas/testsuite/gas/i386/x86-64-branch.d.
The .s file contains four branches to absolute addressed, the first one being
call
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: m at rolle dot name
Created attachment 7805
--> https://sourceware.org/bugzilla/attachment.cgi?id=7805&action=edit
Correct and incorrect generated ./ld/Makefile
I am building b
https://sourceware.org/bugzilla/show_bug.cgi?id=17419
--- Comment #1 from Michael Rolle ---
I looked at the GNU release version 2.24, and its bfd.texinfo is identical to
the one I got from Cygwin (except for the Copyright line).
Anyone like to forward this bug report to GNU?
--
You are receivin
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: m at rolle dot name
Created attachment 7798
--> https://sourceware.org/bugzilla/attachment.cgi?id=7798&action=edit
Transcript of build failure
I am building binutils from source, on Cygwin. The
24 matches
Mail list logo
