Bor Grošelj Simić <bor.groseljsimic@telemach.net> wrote:
> amd64 lacks instruction for this so it has to be implemented with
> float -> signed casts. The approach is borrowed from llvm.

A cproc user recently reported an issue[0] with double to unsigned
conversion. Here's a simple reproducer:

data $x = align 8 { d d_0xffffffff }
data $fmt = align 1 { b "%x\n\000" }

export
function w $main() {
@start
	%dx =d loadd $x
[message trimmed]

On 2023-04-22, Tim Kelly <gtkelly@dialectronics.com> wrote:
> You are conflating syntax with behavior.  QBE might emit gas syntax, but
> your position requires gas behavior.  My patch removes the requirement
> that QBE users use assemblers that reproduce gas behavior.  It is
> comparable to QBE compiling -std=c99 as opposed to incorporating
> gnu-extensions.

It is syntax, though. gas parses the line `xor t1, t1, 1` as syntactic
sugar for xori. On closer look, these aliases are indeed described in
the risc-v assembly manual [0], but rather than listing all the
aliases explicitly, it instructs you to look for the ALIAS lines in
opcodes/riscv-opc.c in binutils, which is what I linked earlier.

-std=c99 vs -std=gnu99 is not really the same thing. There is a

On 2023-04-22, Michael Forney <mforney@mforney.org> wrote:
> The risc-v assembly programmer's
> manual does *not* describe a complete assembly language. It doesn't
> say what comments look like, how to emit data, constant syntax,
> directives for section, alignment, symbol visibility, etc.

Just to correct myself here. It does look like that document does
describe a brief overview of these directives describing the gas
syntax. But it also says things like

> I think it's probably better to beef up the binutils documentation rather than duplicating it here.

implying that the document is describing the specifics of athe ssembly
language for use with GNU binutils.

On 2023-04-22, Tim Kelly <gtkelly@dialectronics.com> wrote:
> That really isn't relevant and distracts from the correctness of the
> emitted Assembly by QBE.

You talk about correctness of emitted assembly, as if assembly was a
well-defined standard language that all assemblers follow.
Unfortunately, this is not the case. The risc-v assembly programmer's
manual does *not* describe a complete assembly language. It doesn't
say what comments look like, how to emit data, constant syntax,
directives for section, alignment, symbol visibility, etc.

The flavor of assembly language syntax that QBE produces *is*
relevant. We have to pick some syntax to produce, and there are many
incompatible choices here (gas, nasm, msvc, plan9, etc). Currently,

On 2023-04-22, Tim Kelly <gtkelly@dialectronics.com> wrote:
> I don't pay attention to GNU.  They don't pay attention to independent
> standards and warps them the same as Microsoft does.  If I want to
> adhere to what GNU does, I'd just use gcc.

Just curious, which assembler do you plan to use with QBE?

> The RISC-V standard calls for add/sub/or/xor/sh* to have three registers
> and addi/subi/ori/xori/sh*i with two registers and the immediate for
> scalars < 4096.

I'm talking about the assembly language syntax, not the ISA. QBE
outputs gas syntax (GNU as), which parses xor with an immediate as an
alias for xori. It also supports several pseudo instructions like li,

On 2023-04-20, Tim Kelly <gtkelly@dialectronics.com> wrote:
> I would not count on an assembler making the correct assumption about
> whether the third value is a register or an immediate.  One of them will
> decide to do it a certain way, then others will do the same and
> eventually we have one and only choice.

GNU as treats xor with an immediate third operand as an alias for xori
(see [0]). QBE outputs gas assembly, so I don't see an issue with
using this alias if it simplifies the code. Are you aware of any
assemblers that claim to support gas syntax, but don't support this
alias?

[0] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=opcodes/riscv-opc.c;h=d9d69cda548bc577062e4923b00e2eb9d085c20c;hb=HEAD#l479

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