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
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
https://sourceware.org/bugzilla/show_bug.cgi?id=25622
--- Comment #3 from Jan Beulich ---
Well, that's not a regression at all, but intended behavior. The requirement
you had put up was that gcc be fixed before the changes goes into gas. This did
happen. If new gas is to be used with old gcc,
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:
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
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
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
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=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
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 #13 from Jan Beulich ---
(In reply to H.J. Lu from comment #12)
> I want assembler to enforce assembly codes without any access to MMX state.
Well, that's what is described by my 2nd option, but it is (as explained)
specifically
https://sourceware.org/bugzilla/show_bug.cgi?id=25550
--- Comment #16 from Jan Beulich ---
(In reply to H.J. Lu from comment #14)
> (In reply to Jan Beulich from comment #13)
> > Well, that's what is described by my 2nd option, but it is (as explained)
> > specifically not sufficient to merely
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 #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
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
https://sourceware.org/bugzilla/show_bug.cgi?id=24546
--- Comment #9 from Jan Beulich ---
The proposed added (AT 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
: 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=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=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
https://sourceware.org/bugzilla/show_bug.cgi?id=26685
--- Comment #13 from Jan Beulich ---
(In reply to H.J. Lu from comment #12)
> (In reply to Jan Beulich from comment #11)
> > (In reply to H.J. Lu from comment #10)
> > > symbol(%rip) is similar to symbol and DISP. There is no real register
>
https://sourceware.org/bugzilla/show_bug.cgi?id=26685
--- Comment #5 from Jan Beulich ---
(In reply to H.J. Lu from comment #4)
> This specific case came from
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97257
>
> The address prefix changes the register operand in these instructions.
>
https://sourceware.org/bugzilla/show_bug.cgi?id=26685
--- Comment #11 from Jan Beulich ---
(In reply to H.J. Lu from comment #10)
> symbol(%rip) is similar to symbol and DISP. There is no real register
> in memory operand.
I disagree - the compiler ought to emit
movdir64b
https://sourceware.org/bugzilla/show_bug.cgi?id=26685
--- Comment #15 from Jan Beulich ---
(In reply to H.J. Lu from comment #14)
> (In reply to Jan Beulich from comment #13)
> > What is needed is some sort of flag to indicate that in this specific case
> > it needs to be foo(%eip).
>
> No, we
https://sourceware.org/bugzilla/show_bug.cgi?id=26685
--- Comment #7 from Jan Beulich ---
Of course, that's all fine. But it's still gcc emitting wrong code, which gas
legitimately diagnoses. You've introduced a bug into gas instead of fixing one.
--
You are receiving this mail because:
You
https://sourceware.org/bugzilla/show_bug.cgi?id=26685
--- Comment #9 from Jan Beulich ---
(In reply to H.J. Lu from comment #8)
> (In reply to Jan Beulich from comment #7)
> > Of course, that's all fine. But it's still gcc emitting wrong code, which
> > gas legitimately diagnoses. You've
https://sourceware.org/bugzilla/show_bug.cgi?id=26685
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=27753
Jan Beulich changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|NOTABUG
https://sourceware.org/bugzilla/show_bug.cgi?id=27753
--- Comment #7 from Jan Beulich ---
(In reply to Fangrui Song from comment #6)
> A dynamic loader needs PT_GNU_PROPERTY to know the ISA usage of a component.
> .note.gnu.property makes up PT_GNU_PROPERTY. Therefore, the section needs to
>
https://sourceware.org/bugzilla/show_bug.cgi?id=27753
--- Comment #9 from Jan Beulich ---
(In reply to H.J. Lu from comment #8)
> If you don't need NOTE sections, just discard them in the linker script.
As per above there's no linker script involved here, and for the simple
purposes here there
https://sourceware.org/bugzilla/show_bug.cgi?id=27626
Jan Beulich changed:
What|Removed |Added
Target||x86_64-*-*
--
You are receiving this
iority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
Working around a compiler issue by suppressing legitimate assembler warnings is
not a way to go. In fact the suppressed warnings hide a code generation bug
https://sourceware.org/bugzilla/show_bug.cgi?id=27419
--- Comment #1 from Jan Beulich ---
As of commit 829f3fe1f023 breakage is at least limited to x32 mode now.
--
You are receiving this mail because:
You are on the CC list for the bug.
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
In the Xen project, to test the internal insn emulator, we have a simple way of
generating binary blobs to hand to the emulator:
%.bin: %.c
$(CC) $(filter-out
https://sourceware.org/bugzilla/show_bug.cgi?id=27753
Jan Beulich changed:
What|Removed |Added
Target||x86
--
You are receiving this mail
https://sourceware.org/bugzilla/show_bug.cgi?id=27753
--- Comment #2 from Jan Beulich ---
(In reply to H.J. Lu from comment #1)
> It sounds like .note.gnu.property section is unused. Please pass
> -R .note.gnu.property to objcopy to remove it.
That's what I'm meaning to do as a workaround, but
https://sourceware.org/bugzilla/show_bug.cgi?id=27178
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
As a supposed fix (really at best: workaround, bug gas/26685) for a gcc
shortcoming, symbol(%rip) style operands got special
https://sourceware.org/bugzilla/show_bug.cgi?id=28230
--- Comment #1 from Jan Beulich ---
sysdeps/x86_64/fpu/s_log1pl.S otoh has
.align ALIGNARG(4)
/* The fyl2xp1 can only be used for values in
-1 + sqrt(2) / 2 <= x <= 1 - sqrt(2) / 2
0.29 is a safe
https://sourceware.org/bugzilla/show_bug.cgi?id=28381
Jan Beulich changed:
What|Removed |Added
CC||lili.cui at intel dot com
--- Comment
: gas
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
These two are expected to assemble to similar encodings with similar
relocations attached:
adrpx0, .
1: adrpx0, 1b
Yet presumably as of eac4eb8ecb26
https://sourceware.org/bugzilla/show_bug.cgi?id=2
--- Comment #1 from Jan Beulich ---
(In reply to Jan Beulich from comment #0)
> Nick then found that
>
> adrpx0, . - 8
>
> doesn't have this problem, so it's apparently only plain . which is affected
> (for whatever reason).
I
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
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
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
>
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
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.
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=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
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=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]
: 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
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
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
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
: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
AT syntax, at least in its GNU interpretation, has always been permitting
sizing suffixes to be omitted when register operands
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 mode; the proper one is 'l'.
Observe the anomalies when assembling
cmpsd
iretd
lodsd
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
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 #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=29451
Jan Beulich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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
--- 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
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
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=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=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=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=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
>
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
--- 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
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=30292
--- Comment #3 from Jan Beulich ---
Created attachment 14842
--> https://sourceware.org/bugzilla/attachment.cgi?id=14842=edit
tentative fix
I'm afraid this is a result of a misuse of .eqv, which previously went
un-diagnosed by mistake.
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
Assignee|unassigned at sourceware dot org |jbeulich at suse dot com
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=30248
Jan Beulich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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
https://sourceware.org/bugzilla/show_bug.cgi?id=30120
Jan Beulich changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Jan
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=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
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=edit
tentative fix
(still pending testing results, especially for the testsuite additions)
--
You are receiving this
https://sourceware.org/bugzilla/show_bug.cgi?id=30688
Jan Beulich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
: 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
: 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
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=30292
Jan Beulich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
1 - 100 of 109 matches
Mail list logo
