Check for non-zero denorm in __adddf3. Need to check both the upper and
lower 32-bit chunks of a 64-bit float for a non-zero value when
checking to see if the value is -0.
Fix __addsf3 when the sum exponent is exactly 0xff to ensure that
produces infinity and not nan.
Handle converting NaN/inf
The default C library is normally computed based on the target
triplet. However, for embedded systems, it can be useful to leave the
triplet alone while changing which C library is used by default. Other
C libraries may still be available on the system so the compiler and
can be used by specifying
This option allows targets to insert an OS library after the C library
in the LIB_PATH spec file fragment. This library maps a few POSIX APIs
used by picolibc to underlying system capabilities.
For example, picolibc provides 'libsemihost' on various targets which
maps these APIs to semihosting
Picolibc is a C library for embedded systems based on code from newlib
and avr libc. To connect some system-dependent picolibc functions
(like stdio) to an underlying platform, the platform may provide an OS
library.
This OS library must follow the C library in the link command line. In
current
Signed-off-by: Keith Packard
---
gcc/config.gcc | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 0679a76bebb..84bca8df615 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -661,7 +661,7 @@ case ${target} in
esac
# Common
I submitted the referenced patch to extend the 'getenv' .specs function
back in August and didn't see any response, so I wanted to provide a bit
more context to see if that would help people understand why I wrote
this.
Here's a link to that message:
The default C library is normally computed based on the target
triplet. However, for embedded systems, it can be useful to leave the
triplet alone while changing which C library is used by default. Other
C libraries may still be available on the system so the compiler and
can be used by specifying
This option allows targets to insert an OS library after the C library
in the LIB_PATH spec file fragment. This library maps a few POSIX APIs
used by picolibc to underlying system capabilities.
For example, picolibc provides 'libsemihost' on various targets which
maps these APIs to semihosting
Picolibc is a C library for embedded systems based on code from newlib
and avr libc. To connect some system-dependent picolibc functions
(like stdio) to an underlying platform, the platform may provide an OS
library.
This OS library must follow the C library in the link command line. In
current
Don't set the DEFAULT_LIBC variable for newlib configurations as that
is how it currently works for systems using newlib as the default.
Signed-off-by: Keith Packard
---
gcc/config.gcc | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/gcc/config.gcc
Richard Sandiford writes:
Thanks much for reviewing this series. I really appreciate it.
> should there be a default case that raises an error for unrecognised
> libcs? Command-line checking for configure isn't very tight, but we
> do raise similar errors for things like invalid
Right now, a missing environment variable provided to the 'getenv'
function in a .specs file causes a fatal error. That makes writing a
spec file that uses the GCC_EXEC_PREFIX value difficult as that
variable is only set when the driver has been relocated, but not when
run from the defined
Kito Cheng writes:
> I am thinking that maybe we should add
> -mlibc=[newlib|newlib-nano|picolibc|unknown] option to bare-matel
> toolchain, one reason is having an unify interface to select libc
> implementation between clang/LLVM, spec file is a GCC specific stuff,
> that cause very bad
Andrew Pinski writes:
(removing gcc@ as not appropriate for patch discussions)
Thanks for reviewing my patches; I appreciate the time you have taken to
think about this.
> Why do you need to change the specs to support picolibc? Why not have
> the library supply the specs file instead, like
Picolibc is a C library for embedded systems based on code from newlib
and avr libc. To connect some system-dependent picolibc functions
(like stdio) to an underlying platform, the platform may provide an OS
library.
This OS library must follow the C library in the link command line. In
current
This option allows targets to insert an OS library after the C library
in the LIB_PATH spec file fragment. This library maps a few POSIX APIs
used by picolibc to underlying system capabilities.
For example, picolibc provides 'libsemihost' on various targets which
maps these APIs to semihosting
The default C library is normally computed based on the target
triplet. However, for embedded systems, it can be useful to leave the
triplet alone while changing which C library is used by default. Other
C libraries may still be available on the system so the compiler and
can be used by specifying
Signed-off-by: Keith Packard
---
gcc/config.gcc | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index f8b6da4f4e7..0aa4bd6c3dd 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -639,7 +639,7 @@ case ${target} in
esac
# Common C
Martin Sebor writes:
> Can this option be used in attribute optimize? If yes, what's
> the advantage of also providing an atttribute?
Compatibility with the clang attribute.
> It seems to me that as a matter of QOI, GCC should be able to
> disable the expansion of built-ins to calls to
This attribute controls optimizations which make assumptions about the
semantics of builtin functions. Typical cases here are code which
match memcpy, calloc, sincos, or which call builtins like free.
This extends on things like the -ftree-loop-distribute-patterns
flag. That flag only covers
Richard Biener writes:
> I don't think it reliably works the way you implement it. It's also having
> more side-effects than what you document, in particular
Yeah, I made a 'minimal' patch that had the effect I needed, but it's
clearly in the wrong place as it disables the matching of builtins
This option (enabled by default) controls optimizations which convert
a sequence of operations into an equivalent sequence that includes
calls to builtin functions. Typical cases here are code which matches
memcpy, calloc, sincos.
The -ftree-loop-distribute-patterns flag only covers converting
Jonathan Wakely writes:
> I'll do a bit more testing and push it next week.
That's awesome news. Thanks so much for you help; I'm looking forward to
having real C++ support for my embedded customers!
--
-keith
signature.asc
Description: PGP signature
This option directs the library to only use simple stdio APIs instead
of using fileno to get the file descriptor for use with POSIX APIs.
Aided-by: Jonathan Wakely
Signed-off-by: Keith Packard
-
v2:
Switch from --enable-libstdcxx-pure-stdio to
--enable-stdio=stdio_pure
These are the changes to autoconf files for the stdio_pure patch
Signed-off-by: Keith Packard
---
libstdc++-v3/config.h.in | 3 +++
libstdc++-v3/configure | 17 -
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/libstdc++-v3/config.h.in
The current libstdc++ basic_file_stdio.cc code assumes a POSIX API
underneath the stdio implementation provided by the host libc. This
means that the host must provide a fairly broad POSIX file API,
including read, write, open, close, lseek and ioctl.
This patch changes basic_file_stdio.cc to
Jonathan Wakely writes:
> OK. In principle, changes to avoid using the POSIX APIs are definitely
> fine. I would like to combine your new configure switch with the
> existing --enable-cstdio one though.
>
> How about the attached change for acinclude.m4 which would allow you
> to do
Jonathan Wakely writes:
> GCC changelog files are autogenerated now, so patches should not touch
> them. Just include the ChangeLog entry in the Git commit log (which
> will usually end up being quoted in the patch and/or the email body of
> the mail to gcc-patches).
Awesome.
> I think the
28 matches
Mail list logo
