[Bug gas/29005] ASAN error: in pa_chk_field_selector /home/marxin/buildworker/zen2-cross-binutils-sanitizers/build/gas/config/tc-hppa.c:2448
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 comments hinting at quirks there) the risk is just too high for me to introduce new issues. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29120] New: conversion to .linefile is dependent upon # being a line comment char
https://sourceware.org/bugzilla/show_bug.cgi?id=29120 Bug ID: 29120 Summary: conversion to .linefile is dependent upon # being a line comment char Product: binutils Version: 2.39 (HEAD) Status: NEW Severity: 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't be reached by targets where # doesn't make it there. It is, however, unclear whether correcting this is a good idea, as targets (primarily tic30, but also ns32k when SEQUENT_COMPATABILITY is defined) may not like these sequences suddenly obtaining a meaning. I notice that neither of the two mentioned targets is supported by gcc, which might explain why the issue so far has gone unnoticed. I did notice it only because I'm about to introduce a (generic) test for this conversion actually occurring (and not being ignored inside the "false" branches of conditionals). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29183] Inconsistent behaviors of Types with PTR operator
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] mov al, [1+eax] mov al, [eax+1] all meaning the same but then out of mov al, byte[eax] mov al, [byte+eax] mov al, [eax+byte] only the latter two being accepted. (Note that I do not see any room at all for making a difference of whether "byte" and "[" are separated by whitespace.) IOW the presence / absence of "ptr" really does have a meaning. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size
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 TypeBind Vis Ndx Name > > ... > > 9: 0 FUNCGLOBAL HIDDEN 5 _init > > So if the size really is zero than high_pc should be one larger than low_pc > (if expressed as addr in DWARF < 4) and 1 if expressed as unsigned constant > (for DWARF >=4) > > Having the addresses equal or high_pc zero does not express the zero sized > region. Doesn't high_pc being one larger than low_pc express a 1-byte region? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size
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)->size == NULL)
continue;
}
doesn't have the intended effect in the case at hand. With no .size directive I
don't see why / how ->size could be non-NULL.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size
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.
[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size
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.
[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size
https://sourceware.org/bugzilla/show_bug.cgi?id=29451 Jan Beulich changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #16 from Jan Beulich --- Should be taken care of then. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29517] DWARF subprograms output by gas-2.39 have a 'void' return type
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 to be void. In section 3.3.2 of the DWARF 5 doc, it says "Debugging > information entries for C void functions should not have an attribute for > the return type." > > However, a potential fix is suggested by section 5.2: "An unspecified > (implicit, unknown, ambiguous or nonexistent) type is represented by a > debugging information entry with the tag DW_TAG_unspecified_type." Well, that's the route to take then for Dwarf3 and newer, I guess. I don't currently see what we could do about it for Dwarf2, though. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29524] New: x86: move-with-sign-extend inconsistent with move-with-zero-extend
https://sourceware.org/bugzilla/show_bug.cgi?id=29524 Bug ID: 29524 Summary: x86: move-with-sign-extend inconsistent with move-with-zero-extend Product: binutils Version: unspecified Status: NEW Severity: 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 operands allow proper sizing of an insn. This principle is violated for move-with-sign-extend, as can be easily seen with movsb %al, %ax movsb %al, %eax movsb %al, %rax movsb (%rax), %ax movsb (%rax), %eax movsb (%rax), %rax movzb %al, %ax movzb %al, %eax movzb %al, %rax movzb (%rax), %ax movzb (%rax), %eax movzb (%rax), %rax movsw %ax, %eax movsw %ax, %rax movsw (%rax), %eax movsw (%rax), %rax movzw %ax, %eax movzw %ax, %rax movzw (%rax), %eax movzw (%rax), %rax movsl %eax, %rax movsl (%rax), %rax See the v1 posting of patches addressing this: https://sourceware.org/pipermail/binutils/2022-August/122458.html https://sourceware.org/pipermail/binutils/2022-August/122459.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29525] New: x86: CMPSD and MOVSD wrongly accepted in AT&T mode
https://sourceware.org/bugzilla/show_bug.cgi?id=29525 Bug ID: 29525 Summary: x86: CMPSD and MOVSD wrongly accepted in AT&T mode Product: binutils Version: unspecified Status: NEW Severity: normal Priority: 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 iretd lodsd movsd scasd stosd See the v1 posting of a patch addressing this: https://sourceware.org/pipermail/binutils/2022-August/122458.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29526] New: x86: inconsistent suffix recognition in Intel syntax mode
https://sourceware.org/bugzilla/show_bug.cgi?id=29526 Bug ID: 29526 Summary: x86: inconsistent suffix recognition in Intel syntax mode Product: binutils Version: unspecified Status: NEW Severity: normal 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 this then needs to be consistent - observe the anomaly for MOVD when assembling notw[rbx] notd[rbx] nopw[rbx] nopd[rbx] addw[rbx], 5 addd[rbx], 5 movw[rbx], 5 movd[rbx], 5 See the v1 posting of a patch addressing this: https://sourceware.org/pipermail/binutils/2022-August/122458.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29527] New: x86: ambiguous operands silently accepted in AT&T mode
https://sourceware.org/bugzilla/show_bug.cgi?id=29527 Bug ID: 29527 Summary: x86: ambiguous operands silently accepted in AT&T mode Product: binutils Version: unspecified Status: NEW Severity: normal Priority: 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 (%rax) not (%rax) nop (%rax) movsx (%rax), %ax movsx (%rax), %eax movsx (%rax), %rax movzx (%rax), %ax movzx (%rax), %eax movzx (%rax), %rax cvtsi2ss (%rax), %xmm0 vcvtsi2ss (%rax), %xmm0, %xmm0 vcvtusi2ss (%rax), %xmm0, %xmm0 For MOVSX / MOVZX the first case each is the only one where going silently is reasonable, as a 16-bit source is very unlikely to be meant (albeit possible to encode). Patches addressing these were posted previously, but rejected for questionable reasons. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29527] x86: ambiguous operands silently accepted in AT&T mode
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 default to 32 bits because when SSE was introduced, it was 32-bit only. How does "32-bit only" at introduction time matter for 64-bit? When 64-bit was introduced, disambiguation should have been required (and 32-bit code would have remained unaffected). In fact the lack thereof had allowed a gcc bug to go unnoticed for quite some time. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29551] Wrong relocations against _GLOBAL_OFFSET_TABLE_
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_RELOC_32_PCREL. What I'm unsure about is whether _GLOBAL_OFFSET_TABLE_@GOTPCREL is actually a legitimate construct. We're way to lax with (not) rejecting invalid @ constructs anyway, so us not currently rejecting this means about nothing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29457] Consider making --disassembler-color=color default if terminal
https://sourceware.org/bugzilla/show_bug.cgi?id=29457 Jan Beulich changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #6 from Jan Beulich --- (In reply to Martin Liska from comment #2) > Yes, thanks for it. I've just tested the patch and it looks nice! I'm afraid I disagree. It not only doesn't look nice, especially register names are close to unreadable on a terminal with a black background. Nick - I'd like to ask that this be reconsidered. When Andrew first introduced the feature, I specifically asked that coloring not be made the default. And now it suddenly is (the patch wasn't even sent to the list afaics, which is likely part of the reason why I didn't notice until now). I would have been kind of okay if the envvar override had been accepted, but now I need to always remember to add a pretty long option to objdump, just for its output to be at least readable? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29457] Consider making --disassembler-color=color default if terminal
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 ? Or both ? Having both would of course be most flexible. I recall though that you had (imo valid) concerns regarding the use of an envvar. For a possible configure option, I'd like to ask that even that default to off. At the very least until colored output is readable regardless of terminal settings. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29457] Consider making --disassembler-color=color default if terminal
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 (close to?) unreadable, I guess there may want to be a warning (for the time being) in this regard? I admit it's not really clear to me where such a warning would best go. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29525] x86: CMPSD and MOVSD wrongly accepted in AT&T mode
https://sourceware.org/bugzilla/show_bug.cgi?id=29525 Jan Beulich changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED|REOPENED --- Comment #2 from Jan Beulich --- Your response doesn't justify the "won't fix" at all. In fact we did discuss a compromise on the mailing list, and that's what I think we should follow: There are known uses of MOVSD (without operands) in otherwise AT&T code. Clang's integrated assembler also accepts this as an exception. So we want top keep that, but it looks more than reasonable to warn about such uses. Despite e.g. Clang's integrated assembler _not_ accepting CMPSD, we may want to retain support for its no-operands form as well (again with a warning). Nevertheless that's inconsistent with the other string insns (where we don't accept *SD), so doing so is strictly optional (and you saying "For other string instructions" is simply not stating the truth). There is no point in retaining _bogus_ support for the two-operand forms of MOVSD / CMPSD. As a general remark - please don't close bug reports lightly as "won't fix". Doing so needs to be based on objective reasons, not personal taste. This includes qualifying some issues as "minor" (and then using just that as a justification). It may be acceptable to not invest time in fixing such, but if a fix is available and isn't entirely unreasonable, it shouldn't be rejected. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29524] x86: move-with-sign-extend inconsistent with move-with-zero-extend
https://sourceware.org/bugzilla/show_bug.cgi?id=29524 Jan Beulich changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED|REOPENED --- Comment #2 from Jan Beulich --- (In reply to H.J. Lu from comment #1) > Since movsX is used as string instructions, this is expected. It may be expected by you, but that's not an objective reason to mark a report as "won't fix". Like just said in 29525, please don't close bug reports lightly as "won't fix". Doing so needs to be based on objective reasons, not personal taste. This includes qualifying some issues as "minor" (and then using just that as a justification). It may be acceptable to not invest time in fixing such, but if a fix is available and isn't entirely unreasonable, it shouldn't be rejected. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29525] x86: CMPSD and MOVSD wrongly accepted in AT&T mode
https://sourceware.org/bugzilla/show_bug.cgi?id=29525 Jan Beulich changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jan Beulich --- Fixed, with the (intentional) exception noted in #2. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29526] x86: inconsistent suffix recognition in Intel syntax mode
https://sourceware.org/bugzilla/show_bug.cgi?id=29526 Jan Beulich changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Jan Beulich --- Now done (hopefully there aren't further anomalies). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29524] x86: move-with-sign-extend inconsistent with move-with-zero-extend
https://sourceware.org/bugzilla/show_bug.cgi?id=29524 Jan Beulich changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jan Beulich --- Now things are in line with MOVZ*, so marking as resolved. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29940] fails to correctly assemble the JAL instruction on riscv64
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 the bug.
[Bug gas/29940] fails to correctly assemble the JAL instruction on riscv64
https://sourceware.org/bugzilla/show_bug.cgi?id=29940 Jan Beulich changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Jan Beulich --- Fixed on master as well as the branch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30117] internal error in parse_register at tc-i386.c:13060
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 --- Comment #1 from Jan Beulich --- I'll look into that. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30117] internal error in parse_register at tc-i386.c:13060
https://sourceware.org/bugzilla/show_bug.cgi?id=30117 Jan Beulich changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30120] x87: fucomp assembled as fucom
https://sourceware.org/bugzilla/show_bug.cgi?id=30120
Jan Beulich changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Jan Beulich ---
(In reply to Michael Matz from comment #2)
> Came in with bd7828084 "x86: use ModR/M for FPU insns with operands".
>
> The proper Reg field of ModRM for the popping variant of fucom is '5' not
> '4'.
> So this:
>
> --- a/opcodes/i386-opc.tbl
> +++ b/opcodes/i386-opc.tbl
> @@ -651,7 +651,7 @@ fcompp, 0xded9, FP, NoSuf, {}
> fucom, 0xdd/4, i387, Modrm|NoSuf, { FloatReg }
> // alias for fucom %st(1)
> fucom, 0xdde1, i387, NoSuf, {}
> -fucomp, 0xdd/4, i387, Modrm|NoSuf, { FloatReg }
> +fucomp, 0xdd/5, i387, Modrm|NoSuf, { FloatReg }
> // alias for fucomp %st(1)
> fucomp, 0xdde9, i387, NoSuf, {}
> fucompp, 0xdae9, i387, NoSuf, {}
Would you mind simply committing your change?
> (didn't check the other insns touched by the patch)
I've just gone through using a pattern I didn't use when composing the change,
and I didn't find any other similar issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/30117] internal error in parse_register at tc-i386.c:13060
https://sourceware.org/bugzilla/show_bug.cgi?id=30117 Jan Beulich changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jan Beulich --- Sorted. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
https://sourceware.org/bugzilla/show_bug.cgi?id=27217 Jan Beulich changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #24 from Jan Beulich --- (In reply to Kinsey Moore from comment #22) > To be clear, the "no symbol" error has returned. Since the testcase that was originally added doesn't cover this case (which is why it wasn't noticed), can you please supply an example code fragment where the bad behavior is observed? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
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#c4 Oh, I'm sorry for not paying attention. I can indeed observe the issue there. 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''." Which makes me think we're dealing with a linker issue here, as this is precisely the situation we're in. I'll see to find time to go hunt, but I'm far less familiar with ld than with gas. (If others agree this is a separate issue, I guess this would better be handled in a fresh bug report.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
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 simply avoiding to evaluate expressions produces other fallout. In the corresponding email conversation I did suggest yet another expression evaluation mode as a possible route. But that would look more like another hack than a solution, to me at least.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
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''." Which makes me think we're dealing with a linker issue here, as > this is precisely the situation we're in. I'll see to find time to go hunt, > but I'm far less familiar with ld than with gas. (If others agree this is a > separate issue, I guess this would better be handled in a fresh bug report.) See https://sourceware.org/pipermail/binutils/2023-March/126759.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30248] Internal error in i386_att_operand
https://sourceware.org/bugzilla/show_bug.cgi?id=30248 Jan Beulich changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #3 from Jan Beulich --- This needs dealing with differently; see https://sourceware.org/pipermail/binutils/2023-March/126908.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30317] .insn directive did not swap sources
https://sourceware.org/bugzilla/show_bug.cgi?id=30317 Jan Beulich changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jan Beulich --- (In reply to Haochen Jiang from comment #0) > For the current AMX and AMX-FP16 bad testcases, we got testcases like this: > > #tdpfp16ps %tmm5,%tmm4,%tmm3 set VEX.W = 1 (illegal value). > .insn VEX.128.F2.0F38.W1 0x5c, %tmm4, %tmm5, %tmm3 > .fill 0x05, 0x01, 0x90 > > #tdpfp16ps %tmm5,%tmm4,%tmm3 set VEX.L = 1 (illegal value). > .insn VEX.256.F2.0F38.W0 0x5c, %tmm4, %tmm5, %tmm3 > .fill 0x05, 0x01, 0x90 > > The operand order is reversed for operand 2 and 3. And intentionally so. > I did not fully root cause the reason but I guess the highest possibility is > the AMX instructions are using SwapSources which swaps operand 2 and 3. SwapSources can only sensibly be present / in use for real insn templates. .insn has to assume some specified ordering of operands, no matter what order they ought to be in for the real (properly mnemonic-ized) insn. Please read the documentation, which specifically states this aspect. Of course syntax of .insn could be extended to allow specifying such, but I'm afraid that would become unwieldy, because _all_ possible permutations would then need to be expressable. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30248] Internal error in i386_att_operand
https://sourceware.org/bugzilla/show_bug.cgi?id=30248 Jan Beulich changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jan Beulich --- Should be okay now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30292] Unbounded recursion/infinite loop in eqv expansion since 4faaa10f3fabb345aca006ed67a8be97dc924e9c
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 CC|jbeulich at suse dot com | Target Milestone|--- |2.41 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30292] Unbounded recursion/infinite loop in eqv expansion since 4faaa10f3fabb345aca006ed67a8be97dc924e9c
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 mistake. Both .eqv and .equiv are clearly documented to guard the resulting symbol against re-definition. While plain register names (i.e. ones target specific code may insert in the symbol table) are meant to be excluded from this, it was imo a mistake to also exclude equates of registers from this. The attached draft patch addresses this, but it hasn't been run against a wide set of targets yet, so there may end up being obstacles to going that route. Independent of that, however, .eqv also pretty clearly isn't meant here in the first place: You don't want forward reference equates, but normal ones. And indeed by properly switching to .equ all equates involved in the two macros rotate_Xs and ROTATE_ARGS, things work with both plain gas 2.40 as well as patched 2.40.50 (producing the same code 2.38 did generate). What I can't exclude is that this won't work with gas where .eqv / .equiv weren't known yet (but the code in question won't work there anyway for the lack of those directives), as along with introducing the secondary directives handling of .equ symbols was changed (to take into account the value at the time of use [for already defined symbols], rather than the eventual final value). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30292] Unbounded recursion/infinite loop in eqv expansion since 4faaa10f3fabb345aca006ed67a8be97dc924e9c
https://sourceware.org/bugzilla/show_bug.cgi?id=30292 Jan Beulich changed: What|Removed |Added Last reconfirmed||2023-04-20 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30292] Unbounded recursion/infinite loop in eqv expansion since 4faaa10f3fabb345aca006ed67a8be97dc924e9c
https://sourceware.org/bugzilla/show_bug.cgi?id=30292 Jan Beulich changed: What|Removed |Added Attachment #14842|0 |1 is obsolete|| --- Comment #4 from Jan Beulich --- Created attachment 14843 --> https://sourceware.org/bugzilla/attachment.cgi?id=14843&action=edit tentative fix (v2) Further adjustments were necessary, but not as intrusive as I feared. Then again testsuite coverage may not be sufficient to spot all possible fallout ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30292] Unbounded recursion/infinite loop in eqv expansion since 4faaa10f3fabb345aca006ed67a8be97dc924e9c
https://sourceware.org/bugzilla/show_bug.cgi?id=30292 Jan Beulich changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jan Beulich --- Fixed by commit d50c498a1ba7 in so far as gas won't crash anymore, but instead would reject the invalid equate re-definition. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30578] libavcodec/x86/mathops.h:125: Error: operand type mismatch for ` shr'
https://sourceware.org/bugzilla/show_bug.cgi?id=30578 Jan Beulich changed: What|Removed |Added Last reconfirmed||2023-07-20 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Jan Beulich --- See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941. The cast in (uint8_t)(-s) isn't honored by gcc when s can be determined to be a plain number, making it emit a negative value. Negative shift counts of course make no sense (on x86 at least). See the description of the referenced binutils patch as to the resulting misbehavior for RCL and RCR. For SHL/SHR etc the behavior would still be correct, but (dis)allowing negative shift counts there is a matter of consistency. I won't mark this "invalid" right away, to allow for discussion to happen here that should have happened on the patch submission (if need be). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30688] [2.41 regression] Warning: size (8) out of range, ignored
https://sourceware.org/bugzilla/show_bug.cgi?id=30688 Jan Beulich changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-07-27 CC||amodra at gmail dot com --- Comment #1 from Jan Beulich --- In commit a0ea3e1db8c4 uses of X_unsigned were added. Aiui absence of X_unsigned doesn't indicate though whether a value is negative; it merely indicates that the value is to be considered a signed number. (A similar use appears to exist in parse_align().) I'll make a patch amending those, but I'd appreciate input as I might easily be missing something. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30688] [2.41 regression] Warning: size (8) out of range, ignored
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 receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30703] New: bfd doc doesn't build anymore with makeinfo 4.12
https://sourceware.org/bugzilla/show_bug.cgi?id=30703 Bug ID: 30703 Summary: bfd doc doesn't build anymore with makeinfo 4.12 Product: binutils Version: 2.41 Status: NEW Severity: normal Priority: P2 Component: 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, thus causing the build to fail with (in my case) 4.12. While possible to work around by passing MAKEINFO=true on all make command lines, it would of course be nice if a fresh release built out of the box. (Note that Component: is wrong, for there not being "bfd" in the list. Afaict only bfd is affected at this point.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30688] [2.41 regression] Warning: size (8) out of range, ignored
https://sourceware.org/bugzilla/show_bug.cgi?id=30688 Jan Beulich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jan Beulich --- Thanks for confirming. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28909] 2.38 tarball (once again) requires makeinfo
https://sourceware.org/bugzilla/show_bug.cgi?id=28909 Jan Beulich changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #9 from Jan Beulich --- Sadly this breaks the build on Cygwin, for me at least: GEN doc/asconfig.texi cp: failed to preserve ownership for 'doc/asconfig.texi': Permission denied CC config/tc-aarch64.o make[4]: *** [Makefile:2233: doc/asconfig.texi] Error 1 make[4]: *** Waiting for unfinished jobs make[3]: *** [Makefile:1663: all-recursive] Error 1 make[2]: *** [Makefile:1009: all] Error 2 make[1]: *** [Makefile:5477: all-gas] Error 2 make: *** [Makefile:1009: all] Error 2 Which is even more unfortunate because with the use of "cp -p" we aren't really after preserving ownership here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/11601] Solaris assembler compatibility doesn't work
https://sourceware.org/bugzilla/show_bug.cgi?id=11601 Jan Beulich changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #6 from Jan Beulich --- Just to mention it: This regresses certain Arm code. Linux had switched to GNU syntax already a while ago [1], but older kernel builds would be affected. Xen, which inherited some of Linux'es code, has had a patch submitted only just now [2], and hence all published versions are affected. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=790756c7e0229dedc83bf058ac69633045b1000e [2] https://lists.xen.org/archives/html/xen-devel/2023-08/msg0.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30703] bfd doc doesn't build anymore with makeinfo 4.12
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 know the exact minimum. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30747] New: objcopy changes section sizes / contents for COFF
https://sourceware.org/bugzilla/show_bug.cgi?id=30747 Bug ID: 30747 Summary: objcopy changes section sizes / contents for COFF Product: binutils Version: 2.41 Status: NEW Severity: normal Priority: P2 Component: 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 sizes should remain unaltered. Otoh changing the order of symbol table entries (which can also be observed) is likely okay. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28231] relocation truncated to fit: R_X86_64_32S against `.text'
https://sourceware.org/bugzilla/show_bug.cgi?id=28231 Jan Beulich changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #2 from Jan Beulich --- Your testcase doesn't match anything in the referenced source; the closest I can see there is "leaq 1f(%%rip), %%rax" "\n\t" yet the difference (whether or not (%%rip) is appended to 1f) is what I would expect to make things work. In fact that code was changed in this very way almost three years ago. I'm inclined to conclude: Not an issue anymore with the code brought into proper shape. Please confirm. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30703] bfd doc doesn't build anymore with makeinfo 4.12
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 top level configure.ac be updated to check for at least > texinfo 6.8 ? Well, reverting is what I'm doing locally right now, but I don't view this as a good option. Whether to encode the higher version requirement in the top level configury I'm also not sure of - that largely depends if other sub-components' doc would also soon require newer versions. Plus of course wouldn't that require sync-ing with at least gcc? Would it be possible to limit this to bfd's doc for now? But of course all I really care about is that things build cleanly when configure claims to be happy. I'm not sure what the policy is - it would of course be nice for configure to not fail with too old makeinfo, but for it to instead simply disable doc building (with an appropriate warning). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28231] relocation truncated to fit: R_X86_64_32S against `.text'
https://sourceware.org/bugzilla/show_bug.cgi?id=28231 Jan Beulich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jan Beulich --- Thanks for confirming. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856 Jan Beulich changed: What|Removed |Added CC||jbeulich at suse dot com Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at sourceware dot org |jbeulich at suse dot com Last reconfirmed||2023-09-21 --- Comment #3 from Jan Beulich --- I'll look into why this happens, but: 1) I'm not sure we do ourselves (and our users) much good if we allow this again. The referenced symbol is severely constrained in where in the address space it may live. Nevertheless similar symbol uses (with e.g. MOV or ADD) still work, so it is likely necessary to fix this at least for consistency reasons, and for --x32. 2) I'm not convinced the compiler should actually emit such code. It can't know where the linker script (which may be a custom one) would put the executable. When put outside of the low 2G of address space and outside of the high 2G of address space, linking would fail from what I can tell. The emitted code looks to be legitimate only when -mcmodel=kernel is in effect, or in --x32 mode. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
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 are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
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. What I'm saying is that it is wrong to emit such code without -mcmodel=kernel, for there not being any guarantee that the resulting code will actually link. (At the same time an assembly programmer may write such code, knowing the target environment.) > I was under the impression that suffixes like q was ATT syntax, but I > couldn't find any reference of the intel syntax allowed in GNU as. It does > seem to allow pushq even for the Intel syntax, though. It does, but more by mistake than deliberately. > Other assemblers allow "push qword". That's a different form of push, with a memory operand (here we're talking about immediate / address operands). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
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.
[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856 Jan Beulich changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jan Beulich --- Sorted on master and 2.41. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30722] ld tests 'Build property 3', 'Build property 4', 'Build property 5' fail (glibc-2.38?)
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 addressing beyond just papering over the effects visible here? The purpose of the tests is undermined, after all, if platform properties can affect their outcome: What if, say, a v4 marker appeared for property-5 not because of the binutils side handling and inputs, but because of a platform property? Then the test might wrongly pass. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30722] ld tests 'Build property 3', 'Build property 4', 'Build property 5' fail (glibc-2.38?)
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 > test created object file is irrelevant. The test still shows that if a v4 > marker is found in one or more input files, then it will be present in the > output file. The only real failure mode is if the v4 marker is absent from > the output despite the fact that it is present in at least one of the input > files. Not exactly, no. What e.g. property-4 checks is that an object with baseline+v2 and an object with v2+v4 correctly combine to baseline+v2+v4. Them combining to baseline+v2+v3+v4 is something that should fail the test. And yes, such a test very likely should not involved system supplied objects and as a result likely shouldn't use the C compiler to drive the linking. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31043] Poor error message for wrong number of registers
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 error message than you do. Then again I'm also uncertain I properly understand your complaint: The title says "wrong number of registers" when from description and the gcc bug I'd rather infer "wrong register numbers". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31043] Poor error message for wrong register numbers
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 ideal, but imo quite a bit > > better. Yet I'm at a loss to explain why I would see a different error > > message than you do. > > Andrew got the same error message as me which is curious... Well, apologies, that was because of an embarrassing mistake of mine. Is https://sourceware.org/pipermail/binutils/2023-November/130465.html going to make this any better, do you think? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31178] [2.42 regression] Crash when building Valgrind tests (Internal error in build_vex_prefix in tc-i386.c:376)
https://sourceware.org/bugzilla/show_bug.cgi?id=31178 Jan Beulich changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned 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.
[Bug gas/31178] [2.42 regression] Crash when building Valgrind tests (Internal error in build_vex_prefix in tc-i386.c:376)
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.
[Bug gas/31178] [2.42 regression] Crash when building Valgrind tests (Internal error in build_vex_prefix in tc-i386.c:376)
https://sourceware.org/bugzilla/show_bug.cgi?id=31178 Jan Beulich changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jan Beulich --- And thus fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31319] [2.42 regression]: `.arch i386` is rejected by `x86_64` target: 4bit mode not supported on `i386'.
https://sourceware.org/bugzilla/show_bug.cgi?id=31319 Jan Beulich changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-01-31 Status|UNCONFIRMED |WAITING --- Comment #2 from Jan Beulich --- So this is precisely the case that the new behavior is intended to catch: It is meaningless to restrict ISA to i386 when trying to build 64-bit code. In the kexec example, the .code32 comes too late anyway (would have wanted to be at least before the label already before); wants moving ahead of the .arch. IOW for now I view this as neither a bug nor a regression; earlier gas simply was to lax. I'm open to be convinced otherwise ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31319] [2.42 regression]: `.arch i386` is rejected by `x86_64` target: 4bit mode not supported on `i386'.
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 directive. Ordering there would be a problem only if you had e.g. ".arch i286" ahead of ".code16". > SO far I made it build as: >[...] > Does it look about right? Yes. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31388] There is no documentation for -moperand-check
https://sourceware.org/bugzilla/show_bug.cgi?id=31388 Jan Beulich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jan Beulich --- And thus taken care of. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31115] [ARM] The minimalistic DWARF DIE for function has wrong address in Thumb mode
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 file produced directly by gas: > > Or one that is produced by using gcc to invoke just gas. ie compiling with > "-c". Doesn't this ... > > Both the executable and the .o file have the LSB bit set in main's > > DW_AT_low_pc: > > > So for some reason GDB is fine with an object file containing the wrong > > DW_AT_low_pc in main's DIE, but not when it's with a "full blown" > > executable. > > My guess - totally unproven - is that GDB has special code to mask thumb > addresses for object files, but for some reason this code is not applied > to linked executables. ... suggest there's an issue in the linking step? But I'm actually confused by the mention of the .o having the low bits set. If that was the case, the way gcc invokes as would provoke the odd behavior, and that ought to then be reproducible by invoking as directly, with whatever necessary options and/or directives in place. In my testing I cannot observe the low bits set in .o, no matter how they're created. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31752] gas: Support \+ in .rept/.irp/.irpc directives
https://sourceware.org/bugzilla/show_bug.cgi?id=31752 Jan Beulich changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Jan Beulich --- Should be all set now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31903] Asan heap-buffer-overflow in test gas/elf/dwarf-5-irp.s in cross-assember to aarch64-elf
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.
[Bug gas/31903] Asan heap-buffer-overflow in test gas/elf/dwarf-5-irp.s in cross-assember to aarch64-elf
https://sourceware.org/bugzilla/show_bug.cgi?id=31903 Jan Beulich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jan Beulich --- And thus (supposedly) all done. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32003] Specifying --package-metadata might not be possible and is too fragile
https://sourceware.org/bugzilla/show_bug.cgi?id=32003 Jan Beulich changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #4 from Jan Beulich --- (In reply to H.J. Lu from comment #3) > One possibility is to treat "\comma" as ','. Yet introducing another escape character would come with further complexity. It also looks to me as if the %-encoding of double-quotes dominated that of commas in the example provided. I'm inclined to suggest to extend the %-encoding scheme instead; that way what's going to be in 2.43 is not at risk of subtle breakage when support further escaping sequences is added. All that needs to be made sure is for existing escaping sequences to retain their original meaning. What the best scheme here would be is likely better determined by people who make active use of the feature (knowing what set of characters it is that frequently would need escaping one way or the other). I'd be inclined to borrow naming e.g. from HTML's Named Character References, and then use, say, "%[comma]" or "%comma;" to have proper delimiting on both ends. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32003] Specifying --package-metadata might not be possible and is too fragile
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 protect
> the JSON content inside. But this escaping protects this snippet from
> evaluating only once. The problem is that the linker flag can be passed
> around and evaluated multiple times. This will happen easily during Debian
> package build, where debian/rules is a Makefile that calls the project build
> system (that can use makefiles as well).
That, however, is a problem of the build system. Passing around potentially
quoted strings needs special care, to retain quotation. The issue isn't unique
to Debian; see e.g. the Linux kernel's "escsq" and its uses (and how it further
protects e.g. # and $$).
Imo it's just the commas which are the main problem here, as -Wl,... in the
compiler has - afaik - no way of escaping them.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/32003] Specifying --package-metadata might not be possible and is too fragile
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. We simply don't know what people might be using. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32022] Assembler shouldn't accept invalid TLS instructions
https://sourceware.org/bugzilla/show_bug.cgi?id=32022 Jan Beulich changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #5 from Jan Beulich --- (In reply to H.J. Lu from comment #0) > [hjl@gnu-tgl-3 tmp]$ ld y.o > ld: warning: cannot find entry symbol _start; defaulting to 00401000 > ld: y.o: TLS transition from R_X86_64_GOTTPOFF to R_X86_64_TPOFF32 against > `foo' at 0x3 in section `.text' failed > ld: final link failed: bad value And why exactly does linking need to fail is such a situation? The TLS transitions are optional, aren't they? Not being able to do carry one out may indeed deserve a warning (with a control to silence), but not more. (In reply to H.J. Lu from comment #1) > An assembler option should be provided to control the behavior. Having an option to control this is fine with me. Yet then, if enabled, it should really diagnose all suspicious constructs, not just a (random) subset. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32022] Assembler shouldn't accept invalid TLS instructions
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 are orthogonal aspects. Plus, assuming gcc has a suitable testcase in its testsuite, a warning ought to make that fail anyway, wouldn't it? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32022] Assembler shouldn't accept invalid TLS instructions
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 compiler's -Werror. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
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 Status|NEW |ASSIGNED --- Comment #2 from Jan Beulich --- While this use of macros may be in widespread use, that doesn't make it correct (and the gas/NEWS entry actually mentions a macro invocation of this same form). Macro arguments (and parameters) don't require commas as separators. Hence without relying on the internal workings of the gas scrubber, one can't assume that the provided example passes a single argument; instead (following admittedly not great documentation) it's rather 3 arguments which are being passed. Just that gas didn't handle this correctly in the past. Let me give a slightly more complex example: m 101 + (1) (15) (a) How many arguments? The change in question had been pending comments for a long time. Sadly, as is happening more often than not, comments actually surface only once a change was committed and suddenly issues with (broken) existing code show up. Parenthesizing or quoting the argument(s) helps. In case of macros with a single argument, using :vararg in the macro definition is also a way to approach things. At least transitionally we could also invent a mode where macro invocations with some comma separation assumes all arguments are comma separated, thus continuing to ignore whitespace elsewhere. That'll help everywhere, though. For macros with a single argument we could further effectively guess that :vararg is in effect, yet of course that's likely to break some test in the gas testsuite (at least I hope we have such a test there). Which of course in turn could be worked around by adding a new "using new gas behavior" command line option. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
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 > .text > WRAPPER_IMPL_SSE2 acos Which cpp expands to .macro WRAPPER_IMPL_SSE2 callee call *\ callee@GOTPCREL(%rip) .endm .text WRAPPER_IMPL_SSE2 acos Wow. Where's the blank coming from? I didn't know the pre-processor may insert random whitespace. And the pre-processed result is identical to that of the (imo) bogus call JUMPTARGET(\ callee) How's the consumer supposed to be telling apart which one it was originally? 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 whitespace when a valid parameter name follows. Yet I fear there could be other anomalies as a result. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
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 > whitespace when a valid parameter name follows. Yet I fear there could be > other anomalies as a result. I've looked into what the options are of fixing this particular issue. Dealing with the one question of "should blanks be skipped here" quickly turns into a series of such questions, perhaps one for every individual transformation that is done while expanding a macro: - Is \( a token, or can there be whitespace? - Are \@ and \+ tokens, or can there be whitespace? - There's also \& with a comment alluding to preprocessor variables. - Is & used for macro parameter references permitted to be followed by whitespace? If so, what about the optional trailing & ? - Same for @. My intuitive answers to these wouldn't all be the same. For example I'd be more inclined to not permit whitespace in @name@ references. Yet I don't even know the origin of that kind of construct, so how should I be able to tell? Plus of course there's then also the question of whether whitespace should survive when processing something that looks like a param ref, but really isn't (as can easily be the case in nested macros). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
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 case it would also be impossible to fix anomalies there. In turn meaning that hardly any bug in parsing of input can actually be fixed. Not a good state to be in. How would you respond to a bug report in such an area then? "We know it's broken, but it can't be fixed"? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
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 never really liked it. But I've seen it in actual use, not just once. My vague guess is that comma separation actually was introduced only later, to allow macro uses to look more like insns. > I can see it was you actually who documented this feature in the GAS > manual back in 2022 only. But if GAS does accept whitespace here, then > isn't it just a GAS regression that needs fixing instead? Regression? Afaict this (bad) mode of argument (and parameter) separation has been there forever. It just may not have been properly spelled out in the doc. > Is there any > substantial piece of software out there known to rely on this previously > undocumented feature (and why)? I know we've switched to (consistently) comma separation in the Xen hypervisor only a year or so ago. The origin of Xen is Linux; I didn't extensively check recent Linux, but at least on x86 there are such macro uses. And I can certainly easily spot macro definitions across various architectures where parameters are separated by just blanks. > How does the use of whitespace for > argument separation mix with default values anyway? Not very well, as you apparently inferred. Yet iirc defaults for macro arguments hadn't been there all the time. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
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 > whitespace in macro invocation does or does not separate arguments, the > difference visible in e.g.: > > invoke 1 2 > invoke 1 + 2 3 But that's the whole issue: This isn't how the scrubber works. It's not uniformly "different classes" (there's not really a proper concept of tokens either). Boundaries between what may be numbers or identifiers are different from boundaries between operators and alike. The original report that I started this effort from was (iirc) something like invoke (1) (2) where the (pretty obviously) two arguments become just one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25012] pushq/popq %gs/%fs in .code64 now unsupported
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 would have allowed me to notice this before even submitting the patch.) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/24546] x86-64 far jump/call encoding issues
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 then print q suffixes in Intel64 mode, rather than rex.W. A patch for this was already posted as part of a larger series: https://sourceware.org/ml/binutils/2019-12/msg00355.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25438] New: x86 MOVZ* anomalies for unusual/wrong operand combinations
https://sourceware.org/bugzilla/show_bug.cgi?id=25438
Bug ID: 25438
Summary: x86 MOVZ* anomalies for unusual/wrong operand
combinations
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: 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 which get addressed by the next patch of the
series:
https://sourceware.org/ml/binutils/2019-12/msg00346.html
The condensed differences from before the patch (and 2.33.1 behavior) and after
it can be seen in the following diff of the respective listing files:
--- movx.l
+++ movx.l
@@ -7,39 +7,43 @@
4 movsbw %al, %ecx
5 movsbl %al, %cx
6
- 7 660FB6C8 movzbw %al, %ecx
- 8 0FB6C8 movzbl %al, %cx
+ 7 0FB6C8 movzbw %al, %ecx
+ Warning: using `%cx' instead of `%ecx' due to `w' suffix
+ 8 660FB6C8 movzbl %al, %cx
+ Warning: using `%ecx' instead of `%cx' due to `l' suffix
9
10 .code32
11 code32:
12 movsbw %al, %ecx
13 movsbl %al, %cx
14
- 15 0FB6C8 movzbw %al, %ecx
- 16 660FB6C8 movzbl %al, %cx
+ 15 660FB6C8 movzbw %al, %ecx
+ Warning: using `%cx' instead of `%ecx' due to `w' suffix
+ 16 0FB6C8 movzbl %al, %cx
+ Warning: using `%ecx' instead of `%cx' due to `l' suffix
17
18 .code64
19 code64:
20 movsbw %al, %ecx
21 movsbw %al, %rcx
22
- 23 0FB6C8 movzbw %al, %ecx
- 24 480FB6C8 movzbw %al, %rcx
+ 23 movzbw %al, %ecx
+ 24 movzbw %al, %rcx
25
26 movsbl %al, %cx
27 movsbl %al, %rcx
28
- 29 660FB6C8 movzbl %al, %cx
- 30 480FB6C8 movzbl %al, %rcx
+ 29 movzbl %al, %cx
+ 30 movzbl %al, %rcx
31
32 movsbq %al, %cx
33 movsbq %al, %ecx
34
- 35 660FB6C8 movzbq %al, %cx
- 36 0FB6C8 movzbq %al, %ecx
+ 35 movzbq %al, %cx
+ 36 movzbq %al, %ecx
37
38 movswl %ax, %rcx
39 movswq %ax, %ecx
40
- 41 480FB7C8 movzwl %ax, %rcx
- 42 0FB7C8 movzwq %ax, %ecx
+ 41 movzwl %ax, %rcx
+ 42 movzwq %ax, %ecx
IOW,
- for 32- and 16-bit code generated code and emitted diagnostics get brought in
sync with that for other insns, i.e. suffix trumps register size,
- for 64-bit code emitted diagnostics get brought in sync with that for other
insns, i.e. mismatched suffix and register size are not allowed,
- for 64-bit code additionally MOVZ* behavior no longer differs from MOVS* one,
except for the precise wording of the error ("incorrect register ... used with
... suffix" vs "operand size mismatch").
Of course this example additionally demonstrates that MOVS* handling in 32- and
16-bit modes still won't be in line with all other insns, due to there not
being true suffixes in the insn templates. But that's a separate topic,
adjustment to which was previously attempted but rejected by the maintainer.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/16083] objdump provides wrong disassemble for MULSD instruction when used with an unusual combination of prefixes
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 bug.
[Bug gas/25438] x86 MOVZ* anomalies for unusual/wrong operand combinations
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%al, %rcx > movzbl%al, %cx > movzbl%al, %rcx > movzbq%al, %cx > movzbq%al, %ecx > [hjl@gnu-snb-1 tmp]$ gcc -c x.s > [hjl@gnu-snb-1 tmp]$ objdump -dw x.o > > x.o: file format elf64-x86-64 > > > Disassembly of section .text: > > <.text>: >0: 0f b6 c8movzbl %al,%ecx >3: 48 0f b6 c8 movzbq %al,%rcx >7: 66 0f b6 c8 movzbw %al,%cx >b: 48 0f b6 c8 movzbq %al,%rcx >f: 66 0f b6 c8 movzbw %al,%cx > 13: 0f b6 c8movzbl %al,%ecx > [hjl@gnu-snb-1 tmp]$ Indeed that's what the patch is doing, for 64-bit code. For 32-bit (and 16-bit) code though this isn't the way to go, as long as e.g. movl%al, %al movl%ax, %ax produce an error on the first line, but only two warnings on the second one. Behavior for MOVZ* simply gets brought in line with this by the proposed patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25438] x86 MOVZ* anomalies for unusual/wrong operand combinations
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: file format elf64-x86-64 > > > Disassembly of section .text: > > <.text>: >0: 48 0f b7 c8 movzwq %ax,%rcx And? How is this related here? This is an appropriate encoding for the insn. When optimzing, dropping the REX prefix would seem desirable. In fact this is already on my todo list. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25445] movsxd without REX_W prefix incorrectly disassembled
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 too looks correct to me. The only anomaly I can think of because of the vendor difference would be a memory operand in Intel syntax mode, which - if tagged by an operand size - might want to be WORD PTR for the 16-bit case in Intel64 mode and DWORD PTR in the AMD64 one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25438] x86 MOVZ* anomalies for unusual/wrong operand combinations
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 referenced by the original description here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25438] x86 MOVZ* anomalies for unusual/wrong operand combinations
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 2 have been committed - patch 3 demonstrates current (good as well as bad) behavior, to help show more clearly how ... - patch 4 fixes this issue (alongside other ones, but all by the same actual code changes). Would you _please_ take a _proper_ look at patches 3 and 4 of that series? It is telling enough that you moved from an initial "We can't change the encoding nor disallow it." response to "movzbw %al, %ecx movzbw %al, %rcx movzbl %al, %cx movzbl %al, %rcx movzbq %al, %cx movzbq %al, %ecx should be hard error. Clearly they are typos." -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25445] movsxd without REX_W prefix incorrectly disassembled
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 me. > > movslq is AT&T syntax for 32 bits -> 64 bits. It isn't accepted by > assembler. movsxd should be here. MOVSXD, like MOVSX and MOVZX, is Intel syntax, and hence has nothing to do in AT&T syntax disassembly. > > (In reply to H.J. Lu from comment #1) > > > Also > > > > > > 63 08 movslq (%rax),%ecx > > > > This too looks correct to me. > > movsxd should be here. Same here. > > The only anomaly I can think of because of the vendor difference would be a > > memory operand in Intel syntax mode, which - if tagged by an operand size - > > might want to be WORD PTR for the 16-bit case in Intel64 mode and DWORD PTR > > in the AMD64 one. > > Manual can be wrong. The current Intel manual says that MOVSXD is valid > for 32-bit. Can you double check MOVSXD on AMD processor to verify > > movsxd (%rax), %cx > > does load 4 bytes? I did already around the time I put together https://sourceware.org/ml/binutils/2019-12/msg00347.html Both manuals accurately describe actual hardware behavior. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/24546] x86-64 far jump/call encoding issues
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 leaving it at "NEW". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25550] Review .arch directives
https://sourceware.org/bugzilla/show_bug.cgi?id=25550 Jan Beulich changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #1 from Jan Beulich --- However, as pointed out in the mail discussion already, consistent behavior should result (which currently isn't the case): 1. Since .arch generally enables prereqs for the specified ISA extension (like AVX for AVX512F), disabling an extension also should disable everything that it is considered a prereq for. 2. Any ISA extension enabled should be enabled completely. The main anomaly looks to be SSE/SSE2 insns accessing MMX registers, where strictly speaking the MMX ISA extension isn't a prereq to the SSE* ones (it's only the registers that are used), which gas also handles this way. A patch was already proposed to address this: https://sourceware.org/ml/binutils/2020-02/msg00250.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25550] Review .arch directives
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 case): > > > > 1. Since .arch generally enables prereqs for the specified ISA extension > > (like AVX for AVX512F), disabling an extension also should disable > > everything that it is considered a prereq for. > > Is SSE2 a prerequisite for AVX? This can be viewed either way, I guess. The history of the ISA extensions suggests it is. But functionally nothing except the XMM registers have any overlap, I think. > > 2. Any ISA extension enabled should be enabled completely. The main anomaly > > looks to be SSE/SSE2 insns accessing MMX registers, where strictly speaking > > the MMX ISA extension isn't a prereq to the SSE* ones (it's only the > > registers that are used), which gas also handles this way. > > For view point of assembly codes, enable MMX register without MMX ISA > makes no sense. For example, emms is needed for proper MMX usage. Not necessarily, one can certainly get away without (using 4 FFREEP in a row). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25550] Review .arch directives
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 guess. The history of the ISA extensions > > suggests it is. But functionally nothing except the XMM registers have any > > overlap, I think. > > Why is AVX a prerequisite for AVX512? The correlation is largely the same as the one between SSE* and AVX. > > > For view point of assembly codes, enable MMX register without MMX ISA > > > makes no sense. For example, emms is needed for proper MMX usage. > > > > Not necessarily, one can certainly get away without (using 4 FFREEP in a > > row). > > What purpose does it serve? Well, I don't expect anyone would actively want to use it this way. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25550] Review .arch directives
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 vector ISA > extension families can be enabled or disabled independent of each > other: > > * 'MMX' - MMX instructions. > > * 'SSE' - SSE instructions without MMX registers. This is not a useful category. The only viable options I see are - the full set of insns valid with SSE* (including ones accessing MMX registers), - all insns not touching MMX _state_ (which would permit use of CVTPI2PD with a memory operand, but not use of a similar CVTPI2PS). In the latter case special care should be taken to at least warn about Intel syntax uses like "CVTPI2PD xmm0, mm0", as from simply looking at such an insn one wouldn't tell it uses a memory operand named "mm0". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25550] Review .arch directives
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 option be? You said yourself that anything that can engage MMX state in the CPU also is liable to want/need access to EMMS (or FEMMS), which won't be accessible with just SSE insns permitted. -- You are receiving this mail because: You are on the CC list for the bug.
