Thanks! Applied.

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

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

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 :)

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]

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:

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

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.

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]

---
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]