From Michael Forney to ~mcf/cproc

Thanks! Applied.

From Michael Forney to ~mpu/qbe

Drew DeVault <sir@cmpwn.com> wrote: > diff --git a/doc/il.txt b/doc/il.txt > index 308fe45..f2b92fa 100644 > --- a/doc/il.txt > +++ b/doc/il.txt > @@ -173,10 +173,11 @@ by zero-extension, or by sign-extension. > > `bnf > CONST := > - ['-'] NUMBER # Decimal integer > - | 's_' FP # Single-precision float > - | 'd_' FP # Double-precision float > - | $IDENT # Global symbol > + ['-'] NUMBER # Decimal integer

From Michael Forney to ~sircmpwn/hare-dev

I did some investigation of this issue and these are my findings: One of the math::complex tests checks that calike(math::complex::cosc128((math::NAN, 0f64)), (math::NAN, -0f64)) is true, which is failing on glibc. The definition of cosc128 returns (math::NAN, -0f64 * math::copysignf64(0f64, math::NAN)) for this input, so we are checking that the sign of -0f64 * math::copysignf64(0f64, math::NAN) is the same as the sign as -0f64. Simplifying further, we are essentially checking that the sign bit of math::NAN is unset. This ends up being true on musl, but not on

From Michael Forney to ~mcf/cproc

On 2022-05-22, NRK <nrk@disroot.org> wrote: > as long as `size_t`'s conversion rank is >= `int` this check would work > out fine. > > but in case size_t happens to be less than int (which I believe is valid > under the C standard) then comparison will take place in `signed int` > and the operand `-1` will not get implicitly converted to SIZE_MAX. > > explicitly cast it to size_t to avoid such issues. Thanks for the patch, applied. I'm not aware of any platforms where size_t is smaller than int, but it doesn't hurt to fix it anyway :)

From Michael Forney to ~mpu/qbe

The maximum immediate size for 1, 2, 4, and 8 byte loads/stores is 4095, 8190, 16380, and 32760 respectively[0][1][2]. [0] https://developer.arm.com/documentation/dui0802/a/A64-Data-Transfer-Instructions/LDRB--immediate- [1] https://developer.arm.com/documentation/dui0802/a/A64-Data-Transfer-Instructions/LDRH--immediate- [2] https://developer.arm.com/documentation/dui0802/a/A64-Data-Transfer-Instructions/LDR--immediate- --- arm64/emit.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arm64/emit.c b/arm64/emit.c index 47097b7..2506eea 100644 --- a/arm64/emit.c +++ b/arm64/emit.c [message trimmed]

From Michael Forney to ~sircmpwn/hare-dev

On 2022-05-04, Sudipto Mallick <smlckz@disroot.org> wrote: > Looking at the OpenBSD C standard library source code.. > http://bxr.su/OpenBSD/lib/libc/stdio/vfscanf.c#823 > > Why is it not checking for infinity and nan? > > According to C standard (C99 §7.19.6.2p12) it should have supported nan.. >> a,e,f,g Matches an optionally signed floating-point number, infinity, >> or NaN, whose format is the same as expected for the subject sequence of >> the strtod function. The corresponding argument shall be a pointer to >> floating. Going another level deeper, we have in C99 §7.20.1.3p3 for strtod:

From Michael Forney to ~mpu/qbe

On 2022-04-11, Roland Paterson-Jones <rolandpj@gmail.com> wrote: > I'm not sure if QBE allows 'b' and 'h' result types for general > arithmetic instructions? It does not. The only temporary types in QBE are the "base types", w (32-bit integer), l (64-bit integer), s (32-bit float), and d (64-bit float). Many arithmetic instructions don't care about the signedness of the operands (they work the same either way), but for those that do, like 'div', there is a corresponding instruction 'udiv' that interprets the operands as unsigned. > This leads into the question of exactly how much masking etc. a

From Michael Forney to ~mpu/qbe

On 2022-04-11, Roland Paterson-Jones <rolandpj@gmail.com> wrote: > The function decl/call allows this with ":"-typed params/args and > return, and I think(?) the expectation is to provide function > arguments as pointers, but specify them as ":"-style struct/union > types, and ditto with the return value. > > Is that right? That's correct. In QBE, aggregate types are only used to implement the C calling convention, so they only appear as the type of arguments/returns of a call instruction. Outside of function calls, you just treat them as pointers to data. You can use loads and stores to access the fields in the struct/union.

From Michael Forney to ~mpu/qbe

```
``````
Revisiting this, motivated by this recent blog post by Brian Callahan:
https://briancallahan.net/blog/20220330.html
Quentin Carbonneaux <quentin@c9x.me> wrote:
> I am not opposed to this optimization but I find the implementation
> a bit too hacky. An alternative approach I can suggest is to add a
> 'zero' instruction that just zeroes its return temporary. This
> instruction could easily work with both integer and sse registers.
> It could be 'xzero' as well if it is only used for amd64.
I'm not sure what you find hacky about this approach. The job of
isel() is to replace instructions that cannot be encoded in the
target ISA with an equivalent sequence of instructions that can.
In this case, we *do* have an amd64 instruction that copies zero
[message trimmed]
```

From Michael Forney to ~mpu/qbe

--- Whoops, forgot to increase the size of the name array. v2: increase size of Target.name to accommodate "amd64_sysv" all.h | 2 +- amd64/targ.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/all.h b/all.h index 3cfb60a..c8ec93c 100644 --- a/all.h +++ b/all.h @@ -40,7 +40,7 @@ enum { [message trimmed]