Add versions of __aeabi_memset and __aeabi_memclr which do not use mov
instructions between low registers, as this is unsupported on thumbv4t
and thumbv5.
errors as reported on macOS w/ Xcode 10.1, 10.2 and 11.0:
src/ir.cpp:23285:16: error: variable 'bits' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
} else if (float_type->id == ZigTypeIdFloat)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/ir.cpp:23288:13: note: uninitialized use occurs here
switch (bits) {
^~~~
src/ir.cpp:23285:12: note: remove the 'if' if its condition is always true
} else if (float_type->id == ZigTypeIdFloat)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/ir.cpp:23281:18: note: initialize the variable 'bits' to silence this warning
unsigned bits;
and expand @sqrt
This revealed that the accuracy of ln is not as good as the current algorithm in
musl and glibc, and should be ported again.
v2: actually include tests
v3: fix reversal of in and out arguments on f128M_sqrt()
add test for @sqrt on comptime_float
do not include @nearbyInt() until it works on all targets.
This removes the odd width and precision specifiers found and replacing
them with the more consistent api described in #1358.
Take the following example:
{1:5.9}
This refers to the first argument (0-indexed) in the argument list. It
will be printed with a minimum width of 5 and will have a precision of 9
(if applicable).
Not all types correctly use these parameters just yet. There are still
some missing gaps to fill in. Fill characters and alignment have yet to
be implemented.
f8f054b354 exposes the issue where
macho symbol `__mh_execute_header` is weak exported with an extra
underscore and stack traces fail due to invalid header magic.
related #2700
Not all of the softfloat library is being built....
Vector support is very buggy at the moment, but should work when the bugs are fixed.
(as I had the same code working with another vector function, that hasn't been merged yet).
This reverts commit aa60d2a688.
The copyright ownership of this 10 line patch is under dispute.
See #2701 for details. So I'll revert it and then fix it myself without
looking at this patch.
Previously, the symbol name parameter of `@export` would be ignored for
variables, and the variable name would be used for the symbol name.
Now it works as expected.
See #2679
previously `@export` for an array would panic with a TODO message.
now it will do the export. However, it uses the variable's name
rather than the name passed to `@export`. Issue #2679 remains open
for that problem.
