https://sourceware.org/bugzilla/show_bug.cgi?id=29005
--- Comment #2 from Jan Beulich ---
With the function deliberately (albeit with a FIXME comment) parsing past line
ends, I'd rather leave the fixing of this to hppa maintainers. Not knowing
their assembly language (and having found a couple of
: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
The code doing the conversion sits inside a "case LEX_IS_LINE_COMMENT_START:"
code block and hence won'
https://sourceware.org/bugzilla/show_bug.cgi?id=29183
--- Comment #1 from Jan Beulich ---
I see only two choices: Make this an error (like MASM does), or accept it as we
do now (as e.g. TASM does). I'm strongly in favor of retaining current behavior
to avoid the anomaly of
mov al, 1[eax]
https://sourceware.org/bugzilla/show_bug.cgi?id=29451
--- Comment #8 from Jan Beulich ---
(In reply to Mark Wielaard from comment #7)
> > and the symbol size is also 0 in the table:
> > $ readelf -s crti.o
> >
> > Symbol table '.symtab' contains 11 entries:
> >Num:Value Size Type
https://sourceware.org/bugzilla/show_bug.cgi?id=29451
--- Comment #9 from Jan Beulich ---
The commit in question actually tries to avoid emitting zero-sized regions, so
the question is why
if (S_GET_SIZE (symp) == 0)
{
if (!IS_ELF || symbol_get_obj (symp)->siz
https://sourceware.org/bugzilla/show_bug.cgi?id=29451
--- Comment #12 from Jan Beulich ---
Yeah, I can certainly see my thinko. Making a patch ...
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29451
--- Comment #13 from Jan Beulich ---
See patch at https://sourceware.org/pipermail/binutils/2022-August/122322.html.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29451
Jan Beulich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://sourceware.org/bugzilla/show_bug.cgi?id=29517
--- Comment #1 from Jan Beulich ---
(In reply to Kevin Buettner from comment #0)
> Note that there's no DW_AT_type attribute (which would specify the return
> type) for the munmap subprogram. As I understand it, this causes the return
> type t
: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
AT&T syntax, at least in its GNU interpretation, has always been permitting
sizing suffixes to be omitted when register oper
: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
'd' is not a valid insn sizing suffix in AT&T mode; the proper one is 'l'.
Observe the anomalies when assembling
cmpsd
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
While generally insn suffixes are used for sizing in only very few cases for
Intel syntax, we've been accepting such forever. But
: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
Note the warnings on the first three insns but their absence on the latter ones
(sizing suffixes ought to be used to disambiguate):
neg (
https://sourceware.org/bugzilla/show_bug.cgi?id=29527
--- Comment #3 from Jan Beulich ---
(In reply to H.J. Lu from comment #2)
> (In reply to Jan Beulich from comment #0)
> > cvtsi2ss (%rax), %xmm0
> > vcvtsi2ss (%rax), %xmm0, %xmm0
> > vcvtusi2ss (%rax), %xmm0, %xmm0
> >
>
> They
https://sourceware.org/bugzilla/show_bug.cgi?id=29551
--- Comment #4 from Jan Beulich ---
If that also allows _GLOBAL_OFFSET_TABLE_-. to work as expected, perhaps that's
the way to go. It's been a long time, but I expect that form of expression was
what I had in mind when adding the check for BFD
https://sourceware.org/bugzilla/show_bug.cgi?id=29457
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=29457
--- Comment #8 from Jan Beulich ---
(In reply to Nick Clifton from comment #7)
> What do think would be better: using an environment variable to
> set the colours or having a configure time option which decides upon the
> default behaviour ?
https://sourceware.org/bugzilla/show_bug.cgi?id=29457
--- Comment #10 from Jan Beulich ---
Looks okay to me, with perhaps two remarks: "color" and "colour" are aliases of
"on" according to the code. Documentation may want to reflect this. And then,
with my observation of output potentially being
https://sourceware.org/bugzilla/show_bug.cgi?id=29525
Jan Beulich changed:
What|Removed |Added
Resolution|WONTFIX |---
Status|RESOLVED
https://sourceware.org/bugzilla/show_bug.cgi?id=29524
Jan Beulich changed:
What|Removed |Added
Resolution|WONTFIX |---
Status|RESOLVED
https://sourceware.org/bugzilla/show_bug.cgi?id=29525
Jan Beulich changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=29526
Jan Beulich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://sourceware.org/bugzilla/show_bug.cgi?id=29524
Jan Beulich changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=29940
--- Comment #5 from Jan Beulich ---
IOW it's not a relocation which is being emitted, but there are stray (and
unused) symbol table entries now (referencing register names).
--
You are receiving this mail because:
You are on the CC list for
https://sourceware.org/bugzilla/show_bug.cgi?id=29940
Jan Beulich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://sourceware.org/bugzilla/show_bug.cgi?id=30117
Jan Beulich changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=30117
Jan Beulich changed:
What|Removed |Added
Status|NEW |ASSIGNED
--
You are receiving this mai
https://sourceware.org/bugzilla/show_bug.cgi?id=30120
Jan Beulich changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Jan Beulic
https://sourceware.org/bugzilla/show_bug.cgi?id=30117
Jan Beulich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=27217
Jan Beulich changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://sourceware.org/bugzilla/show_bug.cgi?id=27217
--- Comment #26 from Jan Beulich ---
(In reply to Kinsey Moore from comment #25)
> The original test case should show it provided that you also attempt to link
> it as per Nick's comment:
> https://sourceware.org/bugzilla/show_bug.cgi?id=27217
https://sourceware.org/bugzilla/show_bug.cgi?id=27217
--- Comment #27 from Jan Beulich ---
Another question is: Can't we suppress emitting of relocations when the value
is absolute? (Of course really the relocation in the testcase should reference
"bar", but as we've seen arranging for that by si
https://sourceware.org/bugzilla/show_bug.cgi?id=27217
--- Comment #28 from Jan Beulich ---
(In reply to Jan Beulich from comment #26)
> Quoting from the description of r_info in the ELF spec: "If the index is
> STN_UNDEF, the undefined symbol index, the relocation uses 0 as the ``symbol
> value''
https://sourceware.org/bugzilla/show_bug.cgi?id=30248
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=30317
Jan Beulich changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://sourceware.org/bugzilla/show_bug.cgi?id=30248
Jan Beulich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://sourceware.org/bugzilla/show_bug.cgi?id=30292
Jan Beulich changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=30292
--- Comment #3 from Jan Beulich ---
Created attachment 14842
--> https://sourceware.org/bugzilla/attachment.cgi?id=14842&action=edit
tentative fix
I'm afraid this is a result of a misuse of .eqv, which previously went
un-diagnosed by mistak
https://sourceware.org/bugzilla/show_bug.cgi?id=30292
Jan Beulich changed:
What|Removed |Added
Last reconfirmed||2023-04-20
Ever confirmed|0
https://sourceware.org/bugzilla/show_bug.cgi?id=30292
Jan Beulich changed:
What|Removed |Added
Attachment #14842|0 |1
is obsolete|
https://sourceware.org/bugzilla/show_bug.cgi?id=30292
Jan Beulich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=30578
Jan Beulich changed:
What|Removed |Added
Last reconfirmed||2023-07-20
Ever confirmed|0
https://sourceware.org/bugzilla/show_bug.cgi?id=30688
Jan Beulich changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://sourceware.org/bugzilla/show_bug.cgi?id=30688
--- Comment #2 from Jan Beulich ---
Created attachment 15015
--> https://sourceware.org/bugzilla/attachment.cgi?id=15015&action=edit
tentative fix
(still pending testing results, especially for the testsuite additions)
--
You are receivin
onent: binutils
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
As was pointed out on the list, commit 8bb23cdbb498 raises the minimum makeinfo
version required, yet top-level configure.ac continues to be happy with 4.7,
https://sourceware.org/bugzilla/show_bug.cgi?id=30688
Jan Beulich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=28909
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=11601
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=30703
--- Comment #2 from Jan Beulich ---
(In reply to Nick Clifton from comment #1)
> What is the minimum version now required ?
I don't know. My vague recollection from the earlier mail thread is that the
author of that patch also didn't really k
: binutils
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
MASM-generated COFF objects are copied successfully by objcopy, but at least
.text and .data are zero-padded to the next 16-byte boundary. Imo section
contents and
https://sourceware.org/bugzilla/show_bug.cgi?id=28231
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=30703
--- Comment #4 from Jan Beulich ---
(In reply to Nick Clifton from comment #3)
> So the next question is - are you asking that commit 8bb23cdbb498 be
> reverted, so that the docs will build with older versions of texinfo,
> or that the t
https://sourceware.org/bugzilla/show_bug.cgi?id=28231
Jan Beulich changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=30856
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
Ever
https://sourceware.org/bugzilla/show_bug.cgi?id=30856
--- Comment #5 from Jan Beulich ---
(In reply to Antoni Boucher from comment #4)
> I attached the ATT version (produced by gcc) that still works.
Well, only partly: PUSHQ works, but PUSH (no suffix) doesn't according to my
testing.
--
You a
https://sourceware.org/bugzilla/show_bug.cgi?id=30856
--- Comment #7 from Jan Beulich ---
(In reply to Antoni Boucher from comment #6)
> Do you mean that gcc produces invalid asm when using the Intel syntax and
> should be using pushq?
No. "push offset ..." is the correct form in Intel syntax. W
https://sourceware.org/bugzilla/show_bug.cgi?id=30856
--- Comment #8 from Jan Beulich ---
https://sourceware.org/pipermail/binutils/2023-September/129587.html
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30856
Jan Beulich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=30722
--- Comment #13 from Jan Beulich ---
While I can't say it has become entirely clear to me, it looks as if our
testcase expectations, to some degree, depend on properties of the underlying
platform. Perhaps that's a mistake that wants addressin
https://sourceware.org/bugzilla/show_bug.cgi?id=30722
--- Comment #15 from Jan Beulich ---
(In reply to Nick Clifton from comment #14)
> Except that in such a scenario the linker will still have executed correctly.
> The fact that the v4 marker was found in a system object file rather than a
> te
https://sourceware.org/bugzilla/show_bug.cgi?id=31043
--- Comment #2 from Jan Beulich ---
Hmm, both in 2.41 and in master I'm seeing "operand size mismatch", not
"unsupported instruction". That's still not ideal, but imo quite a bit better.
Yet I'm at a loss to explain why I would see a different
https://sourceware.org/bugzilla/show_bug.cgi?id=31043
--- Comment #4 from Jan Beulich ---
(In reply to Sam James from comment #3)
> (In reply to Jan Beulich from comment #2)
> > Hmm, both in 2.41 and in master I'm seeing "operand size mismatch", not
> > "unsupported instruction". That's still not
at sourceware dot org |jbeulich at suse dot com
--- Comment #4 from Jan Beulich ---
I can see what I overlooked (the C attribute aliases StaticRounding); working
on a fix.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31178
--- Comment #5 from Jan Beulich ---
https://sourceware.org/pipermail/binutils/2024-January/131582.html
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31178
Jan Beulich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=31319
Jan Beulich changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://sourceware.org/bugzilla/show_bug.cgi?id=31319
--- Comment #4 from Jan Beulich ---
(In reply to Sergei Trofimovich from comment #3)
> Aha, adapting kexec-tools sounds fine as well.
>
> Does the `.code16` use look fine in the rest of the file?
They're all okay, as there's no other .arch d
https://sourceware.org/bugzilla/show_bug.cgi?id=31388
Jan Beulich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=31115
--- Comment #8 from Jan Beulich ---
(In reply to Nick Clifton from comment #5)
> > There's another thing I just discovered : I can reproduce GDB's bad
> > behavior on an ELF executable (produced by GCC from the .S file), but
> > not on a .o fi
https://sourceware.org/bugzilla/show_bug.cgi?id=31752
Jan Beulich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://sourceware.org/bugzilla/show_bug.cgi?id=31903
--- Comment #2 from Jan Beulich ---
https://sourceware.org/pipermail/binutils/2024-June/134878.html
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31903
Jan Beulich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=32003
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=32003
--- Comment #15 from Jan Beulich ---
(In reply to Benjamin Drung from comment #6)
> That linker testcase snippet is evaluated to:
>
> --package-metadata='{"foo":"bar"}'
>
> Passing that to a shell or makefile works, because the singe quotes
https://sourceware.org/bugzilla/show_bug.cgi?id=32003
--- Comment #16 from Jan Beulich ---
(In reply to H.J. Lu from comment #14)
> It should be %[quote]". Will adding support for "%[string]" to existing
> --package-metadata option break anything?
You won't know until someone reports a problem.
https://sourceware.org/bugzilla/show_bug.cgi?id=32022
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=32022
--- Comment #7 from Jan Beulich ---
(In reply to Sam James from comment #6)
> We would need a way to make it error out by default when invoked by GCC
> then, given it exposed an x86 backend issue.
I'm afraid I can't make the connection: These
https://sourceware.org/bugzilla/show_bug.cgi?id=32022
--- Comment #9 from Jan Beulich ---
By paying attention to the warning that I indicated would better be emitted
instead. If need be (and if nothing like that exists yet), I'm sure ld could be
taught to have behavior along the lines of the comp
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
Jan Beulich changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #5 from Jan Beulich ---
(In reply to Andreas Schwab from comment #4)
> $ cat svml_d_acos2_core-sse2.S
> #define JUMPTARGET(name) *name##@GOTPCREL(%rip)
>
> .macro WRAPPER_IMPL_SSE2 callee
> call JUMPTARGET(\callee)
> .endm
> .tex
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #8 from Jan Beulich ---
(In reply to Jan Beulich from comment #5)
> Yet then documentation is unclear on whether there may be whitespace between
> the \ and the parameter name. We could of course make macro expansion skip
> whitesp
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #10 from Jan Beulich ---
(In reply to Michael Matz from comment #9)
> I fear the only non-contentious answer to all such questions is: "act in the
> same
> way as currently" :-/ I.e. try it out and emulate the behaviour.
In which
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #13 from Jan Beulich ---
(In reply to Maciej W. Rozycki from comment #12)
> Where does the notion of using whitespace for argument separation in
> macro invocations (as opposed to definitions) come from?
I have no idea, and I neve
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #19 from Jan Beulich ---
(In reply to Michael Matz from comment #14)
> The scrubber removes whitespace between tokens of different classes, but
> retains
> whitespace between token of same class, which sometimes makes it so that
>
https://sourceware.org/bugzilla/show_bug.cgi?id=25012
--- Comment #3 from Jan Beulich ---
Hmm, yes - No_qSuf gets in the way here. Simply removing the attribute won't
work though, I'm afraid. I'll try to find time soon to look into this. (And I'm
surprised there's nothing in the testsuite that wo
https://sourceware.org/bugzilla/show_bug.cgi?id=24546
--- Comment #9 from Jan Beulich ---
The proposed added (AT&T mode) behavior is to allow lcall and ljmp to also have
q suffixes in 64-bit Intel mode, paralleling how other insns (including
branching ones) work. Similarly the assembler would the
: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
The tests proposed to be added by
https://sourceware.org/ml/binutils/2019-12/msg00354.html
demonstrate some inconsistencies
https://sourceware.org/bugzilla/show_bug.cgi?id=16083
--- Comment #4 from Jan Beulich ---
Isn't this effectively (despite being older) a duplicate of 16893, and hence
has been fixed along long ago, with that other report?
--
You are receiving this mail because:
You are on the CC list for the bu
https://sourceware.org/bugzilla/show_bug.cgi?id=25438
--- Comment #2 from Jan Beulich ---
(In reply to H.J. Lu from comment #1)
> movz* with incorrect operands should be rejected, not silently changed
> to something else:
>
> [hjl@gnu-snb-1 tmp]$ cat x.s
> movzbw%al, %ecx
> movzbw
https://sourceware.org/bugzilla/show_bug.cgi?id=25438
--- Comment #6 from Jan Beulich ---
(In reply to H.J. Lu from comment #5)
> Also
>
> [hjl@gnu-cfl-1 pr25438]$ cat y.s
> movzwl%ax, %rcx
> [hjl@gnu-cfl-1 pr25438]$ gcc -c y.s
> [hjl@gnu-cfl-1 pr25438]$ objdump -dw y.o
>
> y.o: fil
https://sourceware.org/bugzilla/show_bug.cgi?id=25445
--- Comment #3 from Jan Beulich ---
(In reply to H.J. Lu from comment #0)
>0: 66 63 08movslq (%rax),%cx
Looks correct to me.
(In reply to H.J. Lu from comment #1)
> Also
>
> 63 08 movslq (%rax),%ecx
This
https://sourceware.org/bugzilla/show_bug.cgi?id=25438
--- Comment #8 from Jan Beulich ---
(In reply to H.J. Lu from comment #7)
> It is OK to encode "movzwq %ax,%rcx" as "movzwl %ax,%ecx". But assembler
> shouldn't accept "movzwl %ax,%rcx".
But addressing this is part of the second patch refere
https://sourceware.org/bugzilla/show_bug.cgi?id=25438
--- Comment #10 from Jan Beulich ---
(In reply to H.J. Lu from comment #9)
> Please submit a single patch to fix this bug.
How is
https://sourceware.org/ml/binutils/2019-12/msg00346.html
not a single patch? From that series
- patches 1 and
https://sourceware.org/bugzilla/show_bug.cgi?id=25445
--- Comment #5 from Jan Beulich ---
(In reply to H.J. Lu from comment #4)
> (In reply to Jan Beulich from comment #3)
> > (In reply to H.J. Lu from comment #0)
> > >0: 66 63 08movslq (%rax),%cx
> >
> > Looks correct to
https://sourceware.org/bugzilla/show_bug.cgi?id=24546
--- Comment #10 from Jan Beulich ---
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=5990e377e5a339bce715fabfc3e45b24b459a7af
I don't see a mechanism in the web interface though how to change a bug's
status, so I'm lea
https://sourceware.org/bugzilla/show_bug.cgi?id=25550
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=25550
--- Comment #3 from Jan Beulich ---
(In reply to H.J. Lu from comment #2)
> (In reply to Jan Beulich from comment #1)
> > However, as pointed out in the mail discussion already, consistent behavior
> > should result (which currently isn't the
https://sourceware.org/bugzilla/show_bug.cgi?id=25550
--- Comment #5 from Jan Beulich ---
(In reply to H.J. Lu from comment #4)
> (In reply to Jan Beulich from comment #3)
> > (In reply to H.J. Lu from comment #2)
> > > Is SSE2 a prerequisite for AVX?
> >
> > This can be viewed either way, I gue
https://sourceware.org/bugzilla/show_bug.cgi?id=25550
--- Comment #9 from Jan Beulich ---
(In reply to H.J. Lu from comment #8)
> We can say something like
>
> In addition to the basic instruction set, the assembler can be told
> to accept various extension mnemonics. 4 separate vecto
https://sourceware.org/bugzilla/show_bug.cgi?id=25550
--- Comment #11 from Jan Beulich ---
(In reply to H.J. Lu from comment #10)
> We need a directive for SSE instructions without MMX registers.
> We can give it a different name, something like pure-SSE.
But what practical use would such an opt
1 - 100 of 169 matches
Mail list logo
