In #94078, `write_to_stdout` had not been fully implemented. However,
now that it has been implemented, to conform with the C standard
(7.23.6.3. The printf function, specifically point 2), we use `stdout`.
This issue is tracked in #94685.
- Also prefer `static constexpr`
- Made it explicit that we are writing to `stdout`
Summary:
We use the storage class for `long double` in the printing
implementations. We don't fully support the PPC double double type,
which that maps to, but we can stub out just the support needed for the
print interface to works. This required using the internal interface for
storage type, but it should be good enough.
Fixes: https://github.com/llvm/llvm-project/issues/136596
There is a problem with such unsigned comparison pattern:
```
if(unsigned_a - unsigned_b > 0) { /* only NOT go here when unsigned_a==unsigned_b */ }
```
When `unsigned_a` < `unsigned_b`, the result will still be `>0` due to
underflow.
This patch fixes two of the occurrences I found.
Also remove two redundant `if` where its condition is guaranteed by
outer `if`.
Summary:
We have 'generic' implementations for some functions stdio functions.
The current logic mandates that all generic functions are implemented by
the target. This obviously isn't true and this caused the GPU builds to
fail once baremtal added some extra ones.
This patch changes the logic to always include the generic sources only
if they aren't already defined. This can probably be cleaned up and
formalized later, since this pattern is copied in many places, but for
now this fixes the failing GPU build bots.
This allows specializing the implementation for different targets
without including unnecessary logic and is similar to #111559 which did
the same for printf Writer interface.
Commit 598e882ee88a1e3 turned `Writer` into a template, and updated most
of the call sites that use it. But not all. The alternative FP printf
system in `float_dec_converter_limited.h` wasn't updated, and neither
was `baremetal/printf.cpp` or `baremetal/vprintf.cpp`.
This patch updates `float_dec_converter_limited.h` in the same way that
the previous commit updated `float_dec_converter.h`: propagate the
templatedness through everything in the header, so that anything using a
`Writer` at all has a `write_mode` template parameter to pass on to it.
`printf.cpp` and `vprintf.cpp` are updated in the same way that the
previous commit updated `printf_core/vfprintf_internal.h`: the
`WriteBuffer` has parameter `WriteMode::FLUSH_TO_STREAM`, and `Writer`
picks it up implicitly from that.
Summary:
Currently we dispatch the writing mode off of a runtime enum passed in
by the constructor. This causes very unfortunate codegen for the GPU
targets where we get worst-case codegen because of the unused function
pointer for `sprintf`. Instead, this patch moves all of this to a
template so it can be masked out. This results in no dynamic stack and
uses 60 VGPRs instead of 117. It also compiles about 5x as fast.
This reverts commit 1e6e845d49a336e9da7ca6c576ec45c0b419b5f6 because it
changed the 1st parameter of adjust() to be unsigned, but libc itself
calls adjust() with a negative argument in align_backward() in
op_generic.h.
Both fileno and fdopen require interfacing with the opaque FILE struct,
so they shouldn't be enabled in overlay mode. This patch moves both into
fullbuild only on all platforms.
Fixes#128643
A temporary fix based on discussions in #128079
Currently, baremetal targets are failing to build because the scanf
internals require FILE* (either from the system's libc or our libc).
Normally we'd just turn off the broken entrypoint, but since the scanf
internals are built separately that doesn't work. This patch adds extra
conditions to building those internals, which we can hopefully remove
once we have a proper way to build scanf for embedded.
Another followup fix to #121215
The new cmake wouldn't define the readerat all if the target wasn't GPU
or didn't have a definition of FILE. This patch rewrites the cmake to be
more general.
As a followup, I'd like to make `use_system_file` consistent between
/test and /src. Currently in /src it includes the `COMPILE_OPTIONS` and
in /test it does not.
In #121215 the reader was reorganized and the definitions of the
internal getc and ungetc functions were moved, but the includes that the
GPU builder depends on were not. This patch moves the includes to the
correct new place.
Resolves#115394
1. Move definitions of cross-platform `getc` `ungetc` to `reader.h`.
2. Remove function pointer members to define them once per platform in
`.h`
3. Built in overlay mode in macOS m1
4. Remove `reader.cpp` as it's empty now
Also, full build doesn't yet build on macos m1 AFAIK
These warnings all come up in code modified by one of my two recent
commits c06d0ff806b72b1 and b53da77c505a2d3, and all relate to implicit
integer type conversion. In a build of ours with strict compile options
two of them became errors. Even without that problem, it's worth fixing
them to reduce noise that might hide a more serious warning.
The existing options for bin→dec float conversion are all based on the
Ryū algorithm, which generates 9 output digits at a time using a table
lookup. For users who can't afford the space cost of the table, the
table-lookup subroutine is replaced with one that computes the needed
table entry on demand, but the algorithm is otherwise unmodified.
The performance problem with computing table entries on demand is that
now you need to calculate a power of 10 for each 9 digits you output.
But if you're calculating a custom power of 10 anyway, it's easier to
just compute one, and multiply the _whole_ mantissa by it.
This patch adds a header file alongside `float_dec_converter.h`, which
replaces the whole Ryū system instead of just the table-lookup routine,
implementing this alternative simpler algorithm. The result is accurate
enough to satisfy (minimally) the accuracy demands of IEEE 754-2019 even
in 128-bit long double. The new float128 test cases demonstrate this by
testing the cases closest to the 39-digit rounding boundary.
In my tests of generating 39 output digits (the maximum number supported
by this algorithm) this code is also both faster and smaller than the
USE_DYADIC_FLOAT version of the existing Ryū code.
The previous implementation of the ctype functions assumed ASCII.
This patch changes to a switch/case implementation that looks odd, but
actually is easier for the compiler to understand and optimize.
Summary:
Currently, the RPC interface uses a basic opcode to communicate with the
server. This currently is 16 bits. There's no reason for this to be 16
bits, because on the GPU a 32-bit write is the same as a 16-bit write
performance wise.
Additionally, I am now making all the `libc` based opcodes qualified
with the 'c' type, mimiciing how Linux handles `ioctls` all coming from
the same driver. This will make it easier to extend the interface when
it's exported directly.
I normally run my cmake with LIBC_CMAKE_VERBOSE_LOGGING set to ON so I
can debug build issues more easily. One of the effects of this is I see
which tests/entrypoints are skipped on my machine. This patch fixes up
the tests and entrypoints that were skipped, but easily fixed. These
were:
libc.src.pthread.pthread_spin_destroy
libc.src.pthread.pthread_spin_init
libc.src.pthread.pthread_spin_lock
libc.src.pthread.pthread_spin_trylock
libc.src.pthread.pthread_spin_unlock
(entrypoints were just missing)
libc.src.wchar.btowc
(I forgot to finish it)
libc.test.src.sys.statvfs.linux.statvfs_test
libc.test.src.sys.statvfs.linux.fstatvfs_test
(Incorrect includes for rmdir, needed some cleanup)
libc.test.integration.src.unistd.execve_test
(wrong dep for errno)
libc.test.src.math.smoke.fmaf_test
(add_fp_unittest doesn't support flags)
libc.test.src.stdio.scanf_core.converter_test
(needed to be moved away from string_reader, further cleanup needed)
Scanf parsing reads the longest possibly valid prefix for a given
conversion. Then, it performs the conversion on that string. In the case
of "0xZ" with a hex conversion (either "%x" or "%i") the longest
possibly valid prefix is "0x", which makes it the "input item" (per the
standard). The sequence "0x" is not a "matching sequence" for a hex
conversion, meaning it results in a matching failure, and parsing ends.
This is because to know that there's no valid digit after "0x" it reads
the 'Z', but it can only put back one character (the 'Z') leaving it
with consuming an invalid sequence.
(inspired by a thread on the libc-coord mailing list:
https://www.openwall.com/lists/libc-coord/2024/10/15/1, see 7.32.6.2 in
the standard for more details.)
Summary:
I'm going to attempt to move the `rpc.h` header to a separate folder
that we can install and include outside of `libc`. Before doing this I'm
going to try to trim up the file so there's not as many things I need to
copy to make it work. This dependency on `cpp::functional` is a low
hanging fruit. I only did it so that I could overload the argument of
the work function so that passing the id was optional in the lambda,
that's not a *huge* deal and it makes it more explicit I suppose.
Dyadic floats were an existing option for float to string conversion,
but it had become stale. This patch fixes it up as well as adding proper
config options and test support. Due to the test changes this is a
followup to #110759
This bug is caused by the BigInt implementation failing to initialize
from errno. Explanation below, but the fix is a static cast to int.
The bug only shows up on risc-v 32 because of a chain of type-oddities:
1) Errno is provided by a struct with an implicit cast to int.
2) The printf parser uses an int128 to store the value of a conversion
on systems with long double greater than double.
3) On systems without native int128 support we use our own BigInt
instead.
These combine such that if both long double and int128 exist (e.g. on
x86) there's no issue, errno is implicitly cast to int, which is
extended to int128. If long double is double (e.g. on arm32) then int64
is used in the printf parser, the implicit cast works, and there's no
issue. The only way this would come up is if the target has a proper
long double type, but not int128, which is the case for at least the
current risc-v 32 bot.
This patch adds the %m conversion to printf, which prints the
strerror(errno). Explanation of why is below, this patch also updates
the docs, tests, and build system to accomodate this.
The standard for syslog in posix specifies it uses the same format as
printf, but adds %m which prints the error message string for the
current value of errno. For ease of implementation, it's standard
practice for libc implementers to just add %m to printf instead of
creating a separate parser for syslog.
