||2022-11-25
Resolution|FIXED |---
CC||rearnsha at gcc dot gnu.org
Status|RESOLVED|REOPENED
--- Comment #6 from Richard Earnshaw ---
Sorry, I think this is wrong. You cannot
https://sourceware.org/bugzilla/show_bug.cgi?id=22589
--- Comment #10 from Richard Earnshaw ---
(In reply to Szabolcs Nagy from comment #9)
> i ran into this again and i think the linker could relax 'adrp xN, weaksym'
> into 'mov xN, 0' if weaksym is undefined.
Static linker or dynamic? The dyn
https://sourceware.org/bugzilla/show_bug.cgi?id=29519
--- Comment #7 from Richard Earnshaw ---
Fixed for arm with
https://sourceware.org/pipermail/binutils/2022-August/122587.html, but need
something similar for aarch64.
--
You are receiving this mail because:
You are on the CC list for the bug
https://sourceware.org/bugzilla/show_bug.cgi?id=29519
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #6 from Richard Ea
https://sourceware.org/bugzilla/show_bug.cgi?id=29519
--- Comment #3 from Richard Earnshaw ---
The slightly strange thing is that the front-end parser passes the entire
buffer to a directive statement, unlike md_assemble which is just passed a
single statement. It's not at all clear why that is.
https://sourceware.org/bugzilla/show_bug.cgi?id=29519
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=28848
--- Comment #7 from Richard Earnshaw ---
(In reply to Nick Clifton from comment #6)
> Fair enough. The thing that worries me is that the problematic file -
> crti.o - comes from glibc and is going to affect the building of a lot of
> project
https://sourceware.org/bugzilla/show_bug.cgi?id=28848
--- Comment #5 from Richard Earnshaw ---
(In reply to Nick Clifton from comment #3)
> Created attachment 13968 [details]
> Proposed Patch
>
> Hi Richard,
>
> How about this patch ?
>
> I was unsure what should be done with the other pot
https://sourceware.org/bugzilla/show_bug.cgi?id=28848
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=28078
--- Comment #6 from Richard Earnshaw ---
For completeness, GCC has now been fixed on master and all maintained releases
(back to gcc-9).
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=28254
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=28078
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=28078
Richard Earnshaw changed:
What|Removed |Added
Target||arm
--
You are receiving this mai
https://sourceware.org/bugzilla/show_bug.cgi?id=28078
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=28031
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://sourceware.org/bugzilla/show_bug.cgi?id=28031
Richard Earnshaw changed:
What|Removed |Added
Version|2.36|2.34
--
You are receiving this ma
https://sourceware.org/bugzilla/show_bug.cgi?id=28031
--- Comment #3 from Richard Earnshaw ---
Fixed on master so far. Affects releases back to 2.34.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=28031
Richard Earnshaw changed:
What|Removed |Added
Target||arm
--
You are receiving this mai
https://sourceware.org/bugzilla/show_bug.cgi?id=28031
--- Comment #1 from Richard Earnshaw ---
Commenting out the .fpu directive allows the test to assemble.
Although iwmmxt2 is implemented in the co-processor space (and does conflict
with the now deprecated FPA co-processor) it is not considere
Assignee: unassigned at sourceware dot org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Created attachment 13518
--> https://sourceware.org/bugzilla/attachment.cgi?id=13518&action=edit
testcase.
The attached assembly output (generated by gcc) no-longer as
https://sourceware.org/bugzilla/show_bug.cgi?id=25406
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24596
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=22589
Richard Earnshaw changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=22589
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=17505
--- Comment #7 from Richard Earnshaw ---
> What is surprising is that the linker correctly patches the BL/BLX instru
ctions, itś just the address that is wrong. I´m wondering if this
can be fixed in the linker machinery to handle interwork
https://sourceware.org/bugzilla/show_bug.cgi?id=17505
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
||rearnsha at gcc dot gnu.org
Resolution||FIXED
--- Comment #1 from Richard Earnshaw 2011-05-11
17:11:59 UTC ---
This appears to be fixed now:
.syntax unified
.thumb
.cpu cortex-m3
movs r1, r2
mov
http://sourceware.org/bugzilla/show_bug.cgi?id=12198
Summary: SVC in thumb assembler forces M-profile attribute
Product: binutils
Version: 2.21 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gas
Assigned
28 matches
Mail list logo