https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #21 from Rui Ueyama ---
I fixed several issues in mold related to POWER10 compatibility, and all its
unit tests pass on gcc120! I also confirmed that mold can now bootstrap itself
with `-mcpu=power10`. So I believe it's now usable on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #20 from Rui Ueyama ---
Last time I tried, mold-produced binaries crash on a real POWER10 machine, but
I couldn't debug it due to some issue (gdb's issue or something but I don't
remember exactly what that was.) Let me try again when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605
--- Comment #12 from Rui Ueyama ---
> Hmm, if you configure the cross target with --with-ld=ld.mold does that then
> work (when not specifying -fuse-ld=mold)?
Sorry, I don't know, but in either case, that wouldn't solve the user-facing
problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605
--- Comment #10 from Rui Ueyama ---
> This is only a problem when using a cross gcc, so why should mold proactively
> create symlinks for dozens of targets when mold is installed?
It's because there are too many and we don't have an exhaustive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605
--- Comment #8 from Rui Ueyama ---
Sure, I agree with that. But would there be any problem if gcc, after failing
to find `-mold` and `mold` in the embedded toolchain's directory, looks
for `ld.mold` in the $PATH?"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605
--- Comment #6 from Rui Ueyama ---
Since mold supports all targets by a single executable, it doesn't make much
sense to install one mold executable for each embedded toolchain. So if we want
to keep the current gcc's lookup mechanism for `ld` e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605
--- Comment #4 from Rui Ueyama ---
> More likely the scripts which build the full toolchains directories should be
> creating the symbolic links instead of mold itself.
So the package manager create a `-ld.mold` as a symlink to `mold` if
mold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605
--- Comment #2 from Rui Ueyama ---
I can make a change to the `make install` rule of the mold linker to install
bunch of symbolic links, but can we enumerate all possible triples? For
example, I wasn't aware that `arm-none-eabi` was a valid trip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605
Bug ID: 111605
Summary: Cross compilation doesn't work with `-fuse-ld=mold`
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #11 from Rui Ueyama ---
I'll try to add a POWER10 support to mold using Qemu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #9 from Rui Ueyama ---
I'm the maintainer of the mold linker. I didn't implement that POWER10 ABI
because I didn't have an access to a POWER10 machine and therefore couldn't
verify the correctness of my implementation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105305
--- Comment #3 from Rui Ueyama ---
By other ld's, what linkers did you have in your mind? If lld, mold and gold
don't hard code /usr and /usr/lib, then the only remaining linker is GNU ld.
It doesn't seem like POSIX says about the default libra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #6 from Rui Ueyama ---
If it silently produces a value that doesn't make sense, shouldn't we ban the
use of the variable or at least show a warning?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #3 from Rui Ueyama ---
Here is my gcc -S output:
$ gcc-12 -S -o- foo.c
.file "foo.c"
.text
.section.rodata
.LC0:
.string "%lx"
.text
.globl main
.type main, @funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
Bug ID: 106835
Summary: [i386] Taking an address of _GLOBAL_OFFSET_TABLE_
produces a wrong value
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #1 from Rui Ueyama ---
It was originally reported to the mold linker. For the record, here is the link
to the original issue: https://github.com/rui314/mold/issues/693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
Bug ID: 106834
Summary: GCC creates R_X86_64_GOTOFF64 for 4-bytes immediate
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625
--- Comment #5 from Rui Ueyama ---
Cool! We'll add a `.llvm_addrsig` support to binutils and get back to you guys.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625
--- Comment #3 from Rui Ueyama ---
I think we can implement the `.addrsig` support to the assembler, but I wonder
if GCC will support it once the GNU assembler gains the feature?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625
Bug ID: 105625
Summary: Support .llvm_addrsig section
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239
--- Comment #14 from Rui Ueyama ---
I see. I think I'm convinced.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239
--- Comment #12 from Rui Ueyama ---
I mean setting STV_HIDDEN visibility to a symbol prevents it to be visible from
any ELF binaries than itself, which may resolve your concern. I may be missing
something though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239
--- Comment #11 from Rui Ueyama ---
You can make it a global, hidden symbol, can't you?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239
--- Comment #9 from Rui Ueyama ---
Thanks Jukub for the description. I'll try to implement it to mold.
One question though. Why doesn't gcc create a weak symbol
wm4.stdio.h.24.5c1b97eef3c86b7a2549420f69f4f128 at the beginning of each
wm4.stdio.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239
--- Comment #7 from Rui Ueyama ---
Note that the latter should be easier to implement because finding a matching
section in a prevailing comdat group for a deduplicated section may not be
trivial.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239
Rui Ueyama changed:
What|Removed |Added
CC||rui314 at gmail dot com
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105305
Bug ID: 105305
Summary: ARM32: gcc does not pass all library directories to
linker
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105172
Rui Ueyama changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105172
Bug ID: 105172
Summary: RV64: gcc generates R_RISCV_ALIGN with a
non-power-of-two value
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104887
--- Comment #2 from Rui Ueyama ---
What kind of regression are you worry about?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104887
Bug ID: 104887
Summary: mold linker is not detected properly
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104708
--- Comment #1 from Rui Ueyama ---
Here is the link to the original bug report:
https://github.com/rui314/mold/issues/358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104708
Bug ID: 104708
Summary: RV64: gcc does not pass all library directories to
linker
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
P
33 matches
Mail list logo
