| Age | Commit message (Collapse) | Author |
|---|
|
On arm64, arm, and ppc it is possible that a large stack frame will
cause the stack protector slot to be reallocated at the wrong end of
the frame.
Noticed by tj@. ok patrick@.
|
|
ok hackroom@
|
|
ok visa@
|
|
LOAD_STACK_GUARD pseudo without consulting the value of useLoadStackGuardNode(),
and then tries to add the return from getSDagStackGuard() as a parameter without
consulting the return from getIRStackGuard() to see if it should do that. This
means that the GlobalISel IRTranslator's implementation for
Intrinsic::stackprotector is broken for platforms that implement
getIRStackGuard() like we do, and this causes a segfault later when the
incomplete LOAD_STACK_GUARD pseudo is lowered in the back end.
Since GlobalISel is disabled on aarch64 most of the time anyway, add a bit that
disables it for OpenBSD/aarch64 all the time.
Fixes a crash when building on aarch64 without retguard, with a stack protector
and without optimizations, which manifests when building cross-tools.
ok patrick@ deraadt@
|
|
ok hackroom@
|
|
- In the N64 mode, properly load the whole immediate value
in the destination register even if the lower 32 bits are zero.
- Ensure correct alignment of memory operands.
- Fix the endianess of memory operands.
|
|
From Edgar Pettijohn <edgar () pettijohn-web ! com>
|
|
Reminded by brynet@
|
|
frame pointer for better use and lets the compiler run a little faster.
The resulting compiler binary is a half bit smaller too.
Note that frame pointer elimination is not applicable everywhere.
mips64 has the tooling that allow its use in this case.
OK kettenis@
|
|
|
|
OK brynet@, bluhm@
|
|
the MIPS64 mul instruction on pre-MIPS64 subtargets.
|
|
This patch sets the section in perl manpages to "3p" instead of "3"
which should be less confusing as you do find them in section 3p
on OpenBSD.
Initial idea and OK espie@, makes sense to schwarze@
|
|
pieces of software that use the constraint if the compiler claims
to be compatible with GCC 4.2.1.
Note that the constraint was removed in GCC 4.4. The reason was that
'h' could generate code whose result is unpredictable. The underlying
reason is that the HI and LO registers are special, and the optimizer
has to be careful when choosing the order of HI/LO accesses. It looks
that LLVM has the needed logic.
|
|
"where is the kaboom?" deraadt@
|
|
ok hackroom@
|
|
for OpenBSD sparc64. The problem is that the integrated assembler is not
even able to compile the .S files in lib/csu or lib/libc so revert this
and use gas again. Fixes build issues with clang on sparc64.
Issue identified by jca@
OK deraadt@, patrick@, jca@
|
|
|
|
|
|
as a memory operand, the assembler generates incorrect relocations in
PIC mode. As a simple fix, expand the instruction into an address load
sequence, which works, that is followed by the actual memory
instruction.
Note that the generated sequence is not always optimal. If the symbol
has a small offset, the offset could be fused with the memory
instruction. The fix does not achieve that, however. A symbol offset
adds an extra instruction.
|
|
we don't need to do that again here.
From Brad
|
|
ok hackroom@
|
|
|
|
|
|
Prepared with help from jsg@ and mortimer@
Tested on amd64 by bcallah@, krw@, naddy@
Tested on arm64 by patrick@
Tested on macppc by kettenis@
Tested on octeon by visa@
Tested on sparc64 by claudio@
|
|
|
|
"where is the kaboom?" deraadt@
|
|
|
|
development effort on OpenBSD/arm64.
|
|
|
|
ok hackroom@
|
|
which tried to figure out whether mandoc supported UTF-8 output
(which it has been doing since 2011) and which passed the -T locale
option (which has been the default since 2014 and always will)
but which required the -V option to work (which was deleted half
a decade ago and will not come back).
Nowadays, it is safe to assume that mandoc just works with UTF-8
on both the input and output sides - in literally each and every
operating system providing a mandoc port or package, even those
that are seriously lagging behind.
This patch will also be pushed upstream.
OK tb@
|
|
|
|
|
|
it will be there.
problem found by naddy@, "heck yeah" kettenis@
|
|
enabled.
ok visa@
|
|
It turns out MachineFrameInfo.hasCalls() is unreliable, because it is
up to the backends to update this information whenever they add calls
to a function, and this does not always happen.
ok kettenis@
|
|
|
|
|
|
Minor bugfixes and documentation improvments. See perldelta for details.
https://metacpan.org/pod/release/SHAY/perl-5.28.2/pod/perldelta.pod
OK bluhm@
|
|
|
|
no functional change intended;
OK patrick@
|
|
no functional change intended;
OK millert@
|
|
It was only used in a very unsystematic way for a small minority
of Perl manual pages anyway, and using it consistently would entail
unsustainable maintenance workload.
Using input from afresh1@ espie@ and Grinnz#p5p;
OK afresh1@ espie@ jmc@.
|
|
Patch clang.rst such that "gmake -f Makefile.sphinx man" keeps working.
Using input from jsg@; OK patrick@; "no worries" deraadt@
|
|
Affects i386 and amd64 only.
ok deraadt@ kettenis@
|
|
variable and fall back to what stty(1) reports, and it does so with
nroff(1), but it didn't with mandoc(1) because it didn't know how
to pass the desired width to mandoc. Teach it to use "-O width=".
OK afresh1@.
I noticed the unimplemented feature when Andrew Daugherity asked
on tech@ what the point of a certain patch in FreeBSD is (which it
turns out we don't need).
|
|
output in UTF-8 encoding on OpenBSD. The consumer is always mandoc(1)
on OpenBSD, which can always handle UTF-8 input (no matter what LC_CTYPE
is) and which always produces useful output: UTF-8 for LC_CTYPE=*.UTF-8
or ASCII otherwise, in particular for LC_CTYPE=C.
Patch written after afresh1@ reported that "perldoc -oman" output
looked bad in both output modes.
OK afresh1@.
|
|
From Andrew Daugherity <andrew.daugherity () gmail ! com>
Corrections to fix and OK millert@, suggestions and OK schwarze@
|
|
|
