| Age | Commit message (Collapse) | Author |
|
Elf2: start implementing input object loading
|
|
`std.Io.tty.Config.detect` may be an expensive check (e.g. involving
syscalls), and doing it every time we need to print isn't really
necessary; under normal usage, we can compute the value once and cache
it for the whole program's execution. Since anyone outputting to stderr
may reasonably want this information (in fact they are very likely to),
it makes sense to cache it and return it from `lockStderrWriter`. Call
sites who do not need it will experience no significant overhead, and
can just ignore the TTY config with a `const w, _` destructure.
|
|
|
|
|
|
|
|
only thing remaining is using libc dns resolution when linking libc
|
|
|
|
Per the illumos GCC fork.
|
|
|
|
|
|
current error
- Compilation: renameTmpIntoCache doesn't need to be pub after the `translateC` change
|
|
- Add std.zig.Server.allocErrorBundle, replace duplicates
|
|
bundles on stdout) via --zig-integration
- Revive some of the removed cache integration logic in `cmdTranslateC` now that `translate-c` can return error bundles
- Fixup inconsistent path separators (on Windows) when building the aro include path
- Move some error bundle logic from resinator into aro.Diagnostics
- Add `ErrorBundle.addRootErrorMessageWithNotes` (extracted from resinator)
|
|
This allows segments to be moved around in the output file without
needing to reapply relocations until virtual address space is exhaused.
|
|
This allows more bytes to be referenced by a smaller index range.
Closes #22867
Closes #25297
Closes #25339
|
|
Coff2: create a new linker from scratch
|
|
This is a little different from how C/C++ compilers do this, but I think it's
justified because it's what users actually *mean* when the use frame pointer
options.
This is another one of those LLVM "CPU" features that have nothing to do with
CPU at all and should really be a TargetMachine option or something. One day
we'll figure out a better way of dealing with these...
|
|
|
|
|
|
fuzzing: implement limited fuzzing
|
|
--debug-rt previously would make rt libs match the root module. Now they
are always debug when --debug-rt is passed. This includes compiler-rt,
fuzzer lib, and others.
|
|
|
|
|
|
|
|
solves several problems with this pattern
|
|
|
|
|
|
|
|
|
|
|
|
This iteration already has significantly better incremental support.
Closes #24110
|
|
std: add a Deque data structure
|
|
Oops, this was supposed to be only a temporary troubleshooting patch.
|
|
std.fmt.Formatter -> std.fmt.Alt
std.fmt.format -> std.Io.Writer.print
|
|
std.Io: delete GenericReader, AnyReader, FixedBufferStream; and related API breakage
|
|
Also, breaking API changes to:
* std.fs.Dir.readFileAlloc
* std.fs.Dir.readFileAllocOptions
|
|
|
|
Unfortunately, we cannot yet remove the special-casing for RISC-V CPU features,
so that code stays.
Closes #10411.
|
|
and delete deprecated alias std.io
|
|
perhaps these APIs have the defaults backwards, eh?
|
|
|
|
And delete DeprecatedLinearFifo from the source tree.
|
|
Co-authored-by: Alex Rønne Petersen <alex@alexrp.com>
|
|
It does nothing but generate a warning for these.
|
|
ubsan-rt: export symbols with hidden visibility
|
|
The big endian RISC-V effort is mostly driven by MIPS (the company) which is
pivoting to RISC-V, and presumably needs a big endian variant to fill the niche
that big endian MIPS (the ISA) did.
GCC already supports these targets, but LLVM support will only appear in 22;
this commit just adds the necessary target knowledge and checks on our end.
|
|
|
|
|
|
|
|
It doesn't really make sense for `target_util.canBuildLibCompilerRt`
(and its ubsan-rt friend) to take in `use_llvm`, because the caller
doesn't control that: they're just going to queue a sub-compilation for
the runtime. The only exception to that is the ZCU strategy, where we
effectively embed `_ = @import("compiler_rt")` into the Zig compilation:
there, the question does matter. Rather than trying to do multiple weird
calls to model this, just have `canBuildLibCompilerRt` return not just a
boolean, but also differentiate the self-hosted backend being capable of
building the library vs only LLVM being capable. Logic in `Compilation`
uses that difference to decide whether to use the ZCU strategy, and also
to disable the library if the compiler does not support LLVM and it is
required.
Also, remove a redundant check later on, when actually queuing jobs.
We've already checked that we can build `compiler_rt`, and
`compiler_rt_strat` is set accordingly. I'm guessing this was there to
work around a bug I saw in the old strategy assignment, where support
was ignored in some cases.
Resolves: #24623
|