aboutsummaryrefslogtreecommitdiff
path: root/newlib/libm/machine
AgeCommit message (Collapse)AuthorFilesLines
2023-12-04pru: libm: Fix incorrect function nameDimitar Dimitrov1-1/+1
Upstream GCC changed -Wimplicit-function-declaration warning into an error. The build break about missing fpclassifyf function prototype exposed a bug in the PRU port of libm. The fix is to use the fpclassify macro for both double and float types. Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
2023-08-17newlib: add Xtensa portAlexey Lapshin12-0/+503
2023-07-26RISC-V: Support Zfinx/Zdinx extension.Kito Cheng via Newlib38-46/+81
Zfinx/Zdinx are new extensions ratified in 2022, it similar to F/D extensions, support hard float operation for single/double precision, but the difference between Zfinx/Zdinx and F/D is Zfinx/Zdinx is operating under general purpose registers rather than dedicated floating-point registers. This patch improve the hard float support detection for RISC-V port, so that Zfinx/Zdinx can have better/right performance. Co-authored-by: Jesse Huang <jesse.huang@sifive.com>
2023-01-18amdgcn: Add vectorized math routinesKwok Cheung Yeung91-0/+8151
This implements a set of vectorized math routines to be used by the compiler auto-vectorizer. Versions for vectors with 2 lanes up to 64 lanes (in powers of 2) are provided. These routines are based on the scalar versions of the math routines in libm/common, libm/math and libm/mathfp. They make extensive use of the GCC C vector extensions and GCN-specific builtins in GCC.
2022-12-16Revert "amdgcn: Add vectorized math routines"Jeff Johnston90-6235/+0
This reverts commit 125e39bfea1a39341a60348c93a65cf4894e0f2a.
2022-12-16amdgcn: Add vectorized math routinesKwok Cheung Yeung90-0/+6235
This implements a set of vectorized math routines to be used by the compiler auto-vectorizer. Versions for vectors with 2 lanes up to 64 lanes (in powers of 2) are provided. These routines are based on the scalar versions of the math routines in libm/common, libm/math and libm/mathfp. They make extensive use of the GCC C vector extensions and GCN-specific builtins in GCC.
2022-02-17newlib: libm: merge build up a directoryMike Frysinger33-8355/+178
Convert all the libm/ subdir makes into the top-level Makefile. This allows us to build all of libm from the top Makefile without using any recursive make calls. This is faster and avoids the funky lib.a logic where we unpack subdir archives to repack into a single libm.a. The machine override logic is maintained though by way of Makefile include ordering, and source file accumulation in libm_a_SOURCES. One thing to note is that this will require GNU Make because of: libm_a_CFLAGS = ... $(libm_a_CFLAGS_$(subst /,_,$(@D))) This was the only way I could find to supporting per-dir compiler settings, and I couldn't find a POSIX compatible way of transforming the variable content. I don't think this is a big deal as other Makefiles in the tree are using GNU Make-specific syntax, but I call this out as it's the only one so far in the new automake code that I've been writing. Automake doesn't provide precise control over the output object names (by design). This is fine by default as we get consistent names in all the subdirs: libm_a-<source>.o. But this relies on using the same set of compiler flags for all objects. We currently compile libm/common/ with different optimizations than the rest. If we want to compile objects differently, we can create an intermediate archive with the subset of objects with unique flags, and then add those objects to the main archive. But Automake will use a different prefix for the objects, and thus we can't rely on ordering to override. But if we leverage $@, we can turn Automake's CFLAGS into a multiplex on a per-dir (and even per-file if we wanted) basis. Unfortunately, since $@ contains /, Automake complains it's an invalid name. While GNU Make supports this, it's a POSIX extension, so Automake flags it. Using $(subst) avoids the Automake warning to get a POSIX compliant name, albeit with a GNU Make extension.
2022-02-16newlib: fix mips fenv.o handlingMike Frysinger2-3/+3
Commit 8fa73a9f8414a4926365324c2fe32a237c2eb91d changed how fenv.c is compiled wrt mips16 targets used the wrong variable to add fenv.o to libm.a. Fix that thinko so it's included in the build again.
2022-02-15newlib/libgloss: drop unused $(CROSS_CFLAGS)Mike Frysinger22-52/+22
This is used in a bunch of places, but nowhere is it ever set, and nowhere can I find any documentation, nor can I find any other project using it. So delete the flags to simplify.
2022-02-10newlib: libm: move configure into top-levelMike Frysinger11-99/+275
This kills off the last configure script under libm/ and folds it into the top newlib configure script. The vast majority of logic was already in the top configure script, so move the little that is left into a libm/acinclude.m4 file.
2022-02-09newlib: drop support for $oextMike Frysinger11-11/+0
This was needed only to support libtool in case objects ended in .lo instead of .o, but we dropped libtool, so drop this too.
2022-02-09newlib: drop support for $aextMike Frysinger11-11/+0
This was needed only to support libtool in case the library ended in .la instead of .a, but we dropped libtool, so drop this too.
2022-02-09newlib: drop libtool supportMike Frysinger22-875/+183
This was only ever used for i?86-pc-linux-gnu targets, but that's been broken for years, and has since been dropped. So clean this up too. This also deletes the funky objectlist logic since it only existed for the libtool libraries. Since it was the only thing left in the small Makefile.shared file, we can punt that too.
2022-02-08newlib: switch to AM_PROG_ARMike Frysinger11-0/+11
Now that we require automake-1.15, we can use this macro rather than do the tool search ourselves.
2022-02-08newlib: switch to standard AC_PROG_CCMike Frysinger11-66/+11
Now that we use AC_NO_EXECUTABLES, and we require a recent version of autoconf, we don't need to define our own copies of these macros. So switch to the standard AC_PROG_CC.
2022-02-08newlib: simplify nds32 automake checksMike Frysinger2-20/+15
This code is a bit more convoluted than it needs to be. GPR_SOURCES is never set to anything, and the automake checks use negative logic to add the SP & DP source files to dedicated variables that are only expanded once. Get rid of the unused variable, use normal boolean logic, and collapse the source settings into a single variable.
2022-02-05newlib: drop shared documentation rulesMike Frysinger11-374/+11
Now that the top-level makefile handles these, don't need to copy these into every single subdir.
2022-02-01newlib: add AC_CACHE_CHECK sugar around preprocessor checksMike Frysinger1-6/+8
This isn't strictly necessary, but it makes for much clearer logs as to what the target is doing, and provides cache vars for anyone who wants to force the test a different way, and it lets the build cache its own results when rerunning config.status.
2022-01-29newlib: use abs_newlib_basedir for -I pathsMike Frysinger22-22/+22
When we had configure scripts in subdirs, the newlib_basedir value was computed relative to that, and it'd be the same when used in the Makefile in the same dir. With many subdir configure scripts removed, the top-level configure & Makefile can't use the same relative path. So switch the subdir Makefiles over to abs_newlib_basedir when they use -I to find source headers. Do this for all subdirs, even ones with configure scripts and where newlib_basedir works. This makes the code consistent, and avoids surprises if the configure script is ever removed in the future as part of merging to the higher level. Some of the subdirs were using -I$(newlib_basedir)/../newlib/ for some reason. Collapse those too since newlib_basedir points to the newlib source tree already.
2022-01-29newlib: export abs_newlib_basedir for all subdirsMike Frysinger11-0/+11
When using the top-level configure script but subdir Makefiles, the newlib_basedir value gets a bit out of sync: it's relative to where configure lives, not where the Makefile lives. Move the abs setting from the top-level configure script into acinclude.m4 so we can rely on it being available everywhere. Although this commit doesn't use it anywhere, just lays the groundwork.
2022-01-26newlib: libm: merge machine/ configure scripts up a levelMike Frysinger56-87093/+792
The machine configure scripts are all effectively stub scripts that pass the higher level options to its own makefile. The only one doing any custom tests was nds32. The rest were all effectively the same as the libm/ configure script. So instead of recursively running configure in all of these subdirs, generate their makefiles from the top-level configure. For nds32, deploy a pattern of including subdir logic via m4: m4_include([machine/nds32/acinclude.m4]) Even its set of checks are very small -- it does 2 preprocessor tests and sets up 2 makefile conditionals. Some of the generated machine makefiles have a bunch of extra stuff added to them, but that's because they were inconsistent in their configure libtool calls. The top-level has it, so it exports some new vars to the ones that weren't already.
2022-01-26newlib: libm: merge machine/ trampoline up a levelMike Frysinger5-16290/+0
The machine/{configure,Makefile} files exist only to fan out to the specific machine/$arch/ subdir. We already have all that same info in the libm/ dir itself, so by moving the recursive configure and make calls into it, we can cut off this logic entirely and save the overhead. For arches that don't have a machine subdir, it means they can skip the logic entirely.
2022-01-23newlib: update preprocessor configure checksMike Frysinger3-96/+192
The nds32 & spu dirs are using compile tests to look for some preprocessor defines, but we don't need to compile the code, just preprocess it. So switch to AC_PREPROC_IFELSE. The sh dir is using a preprocessor test via grep, but let's switch it to AC_PREPROC_IFELSE too to be consistent. This should allow us to drop the uncommon AC_NO_EXECUTABLES call.
2022-01-21newlib: stop clobbering LDFLAGS with non-standard $ldflagsMike Frysinger20-62/+10
It's unclear why this was added originally, but assuming it was needed 20 years ago, it shouldn't be explicitly required nowadays. Current versions of autotools already take care of exporting LDFLAGS to the Makefile as needed (things are actually getting linked). That's why the configure diffs show LDFLAGS still here, but shifted to a diff place in the output list. A few dirs stop exporting LDFLAGS, but that's because they don't do any linking, only compiling, so it's correct. As for the use of $ldflags instead of the standard $LDFLAGS, I can't really explain that at all. Just use the right name so users don't have to dig into why their setting isn't respected, and then use a non-standard name instead. Adjust the testsuite to match.
2022-01-21newlib: stop checking --enable-multilib in subdirsMike Frysinger12-162/+6
None of the subdirs actually use the multilib arg, so include the logic only in the top-level configure.
2022-01-18newlib: avoid duplicate awk checksMike Frysinger12-18/+6
Since AM_INIT_AUTOMAKE calls AC_PROG_AWK, and some configure.ac scripts call it too, we end up testing for awk multiple times. If we change NEWLIB_CONFIGURE to require the macro instead, then it makes sure it's always expanded, but only once. While we're here, do the same thing with AC_PROG_INSTALL since it is also called by AM_INIT_AUTOMAKE, although it doesn't currently result in duplicate configure checks.
2022-01-18newlib: merge old AC_LIBTOOL_WIN32_DLL macro into LT_INITMike Frysinger6-939/+927
The AC_LIBTOOL_WIN32_DLL macro has been deprecated for a while and code should call LT_INIT with win32-dll instead. Update the calls to match. The generated code is noisy not because of substantial differences, but because the order of some macros change (i.e. instead of calling AS and then CC, CC is called first and then AS).
2022-01-18newlib: update libtool macro nameMike Frysinger3-9/+9
Replace old AM_PROG_LIBTOOL name with LT_INIT. There's no change to the generated files since they're aliases internally.
2022-01-18newlib: delete (most) redundant lib_a_CCASFLAGS=$(AM_CCASFLAGS)Mike Frysinger20-38/+2
Since automake already sets per-library CCASFLAGS to $(AM_CCASFLAGS) by default, there's no need to explicitly set it here. Many of these dirs don't have .S files in the first place, so the rule doesn't even do anything. That can easily be seen when Makefile.in has no changes as a result. For the dirs with .S files, the custom rules are the same as the pattern .S.o rules, so this is a nice cleanup. The only dir that was adding extra flags (newlib/libc/machine/mn10300/) to the per-library setting can have it moved to the global AM_CCASFLAGS since the subdir only has one target. Although the setting just adds extra debugging flags, so maybe it should be deleted in general. There are a few dirs that we leave the redundant setting in place. This is to workaround an automake limitation in subdirs that support building with & w/out libtool: https://www.gnu.org/software/automake/manual/html_node/Objects-created-both-with-libtool-and-without.html
2022-01-14newlib: update to automake-1.15Mike Frysinger36-5212/+8585
This matches what the other GNU toolchain projects have done already. The generated diff in practice isn't terribly large. This will allow more use of subdir local.mk includes due to fixes & improvements that came after the 1.11 release series.
2022-01-14require autoconf-2.69 exactlyMike Frysinger60-315/+150
The newlib & libgloss dirs are already generated using autoconf-2.69. To avoid merging new code and/or accidental regeneration using diff versions, leverage config/override.m4 to pin to 2.69 exactly. This matches what gcc/binutils/gdb are already doing. The README file already says to use autoconf-2.69. To accomplish this, it's just as simple as adding -I flags to the top-level config/ dir when running aclocal. This is because the override.m4 file overrides AC_INIT to first require the specific autoconf version before calling the real AC_INIT.
2022-01-12libtool.m4: fix nm BSD flag detectionNick Alcock3-132/+135
Libtool needs to get BSD-format (or MS-format) output out of the system nm, so that it can scan generated object files for symbol names for -export-symbols-regex support. Some nms need specific flags to turn on BSD-formatted output, so libtool checks for this in its AC_PATH_NM. Unfortunately the code to do this has a pair of interlocking flaws: - it runs the test by doing an nm of /dev/null. Some platforms reasonably refuse to do an nm on a device file, but before now this has only been worked around by assuming that the error message has a specific textual form emitted by Tru64 nm, and that getting this error means this is Tru64 nm and that nm -B would work to produce BSD-format output, even though the test never actually got anything but an error message out of nm -B. This is fixable by nm'ing *nm itself* (since we necessarily have a path to it). - the test is entirely skipped if NM is set in the environment, on the grounds that the user has overridden the test: but the user cannot reasonably be expected to know that libtool wants not only nm but also flags forcing BSD-format output. Worse yet, one such "user" is the top-level Cygnus configure script, which neither tests for nor specifies any BSD-format flags. So platforms needing BSD-format flags always fail to set them when run in a Cygnus tree, breaking -export-symbols-regex on such platforms. Libtool also needs to augment $LD on some platforms, but this is done unconditionally, augmenting whatever the user specified: the nm check should do the same. One wrinkle: if the user has overridden $NM, a path might have been provided: so we use the user-specified path if there was one, and otherwise do the path search as usual. (If the nm specified doesn't work, this might lead to a few extra pointless path searches -- but the test is going to fail anyway, so that's not a problem.) (Tested with NM unset, and set to nm, /usr/bin/nm, my-nm where my-nm is a symlink to /usr/bin/nm on the PATH, and /not-on-the-path/my-nm where *that* is a symlink to /usr/bin/nm.) ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> PR libctf/27967 * libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided NM, if there is one. Run nm on itself, not on /dev/null, to avoid errors from nms that refuse to work on non-regular files. Remove other workarounds for this problem. Strip out blank lines from the nm output.
2022-01-12libtool.m4: augment symcode for Solaris 11Nick Alcock3-3/+3
This reports common symbols like GNU nm, via a type code of 'C'. ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> PR libctf/27967 * libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for Solaris 11.
2022-01-12Add support for the haiku operating system. These are the os support patches ↵Alexander von Gluck IV3-3/+3
we have been grooming and maintaining for quite a few years over on git.haiku-os.org. All of these architectures are working and most have been stable for quite some time.
2022-01-12GCC: Check if AR works with --plugin and rcH.J. Lu3-9/+33
AR from older binutils doesn't work with --plugin and rc: [hjl@gnu-cfl-2 bin]$ touch foo.c [hjl@gnu-cfl-2 bin]$ ar --plugin /usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c [hjl@gnu-cfl-2 bin]$ ./ar --plugin /usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c ./ar: no operation specified [hjl@gnu-cfl-2 bin]$ ./ar --version GNU ar (Linux/GNU Binutils) 2.29.51.0.1.20180112 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. [hjl@gnu-cfl-2 bin]$ Check if AR works with --plugin and rc before passing --plugin to AR and RANLIB. PR ld/27173 * configure: Regenerated. * libtool.m4 (_LT_CMD_OLD_ARCHIVE): Check if AR works with --plugin and rc before enabling --plugin. config/ PR ld/27173 * gcc-plugin.m4 (GCC_PLUGIN_OPTION): Check if AR works with --plugin and rc before enabling --plugin. libiberty/ PR ld/27173 * configure: Regenerated. zlib/ PR ld/27173 * configure: Regenerated.
2022-01-12GCC: Pass --plugin to AR and RANLIBH.J. Lu3-6/+75
Detect GCC LTO plugin. Pass --plugin to AR and RANLIB to support LTO build. * Makefile.tpl (AR): Add @AR_PLUGIN_OPTION@ (RANLIB): Add @RANLIB_PLUGIN_OPTION@. * configure.ac: Include config/gcc-plugin.m4. AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION. * libtool.m4 (_LT_CMD_OLD_ARCHIVE): Pass --plugin to AR and RANLIB if possible. * Makefile.in: Regenerated. * configure: Likewise. config/ * gcc-plugin.m4 (GCC_PLUGIN_OPTION): New. libiberty/ * Makefile.in (AR): Add @AR_PLUGIN_OPTION@ (RANLIB): Add @RANLIB_PLUGIN_OPTION@. (configure_deps): Depend on ../config/gcc-plugin.m4. * aclocal.m4: Include ../config/gcc-plugin.m4. * configure.ac: AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION. * configure: Regenerated. zlib/ * configure: Regenerated.
2022-01-12libtool.m4: update GNU/Hurd test from upstream. In upstream libtool, ↵Samuel Thibault3-39/+9
47a889a4ca20 ("Improve GNU/Hurd support.") fixed detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink. This backports it. . * libtool.m4: Match gnu* along other GNU systems. */ChangeLog: * configure: Re-generate.
2022-01-12newlib: regen aclocal.m4 after autoconf updateMike Frysinger12-24/+24
The configure scripts were regenerated with 2.69 for the newlib-4.2.0 release in 484d2ebf8d825b28af47b8ee88cd845f1d2c7c6e, but the aclocal files were not. Do that now to avoid confusion between the two as to which version of autoconf was used.
2022-01-05newlib: migrate from INCLUDES to AM_CPPFLAGSMike Frysinger22-24/+24
Since automake deprecated the INCLUDES name in favor of AM_CPPFLAGS, change all existing users over. The generated code is the same since the two variables have been used in the same exact places by design. There are other cleanups to be done, but lets focus on just renaming here so we can upgrade to a newer automake version w/out triggering new warnings.
2021-12-31Update newlib to 4.2.0newlib-snapshot-20211231Jeff Johnston12-1391/+1459
2021-12-29newlib: Regenerate autotools filesJon Turney12-66/+60
2021-12-29newlib: Remove automake option 'cygnus'Jon Turney6-12/+0
The 'cygnus' option was removed from automake 1.13 in 2012, so the presence of this option prevents that or a later version of automake being used. A check-list of the effects of '--cygnus' from the automake 1.12 documentation, and steps taken (where possible) to preserve those effects (See also this thread [1] for discussion on that): [1] https://lists.gnu.org/archive/html/bug-automake/2012-03/msg00048.html 1. The foreign strictness is implied. Already present in AM_INIT_AUTOMAKE in newlib/acinclude.m4 2. The options no-installinfo, no-dependencies and no-dist are implied. Already present in AM_INIT_AUTOMAKE in newlib/acinclude.m4 Future work: Remove no-dependencies and any explicit header dependencies, and use automatic dependency tracking instead. Are there explicit rules which are now redundant to removing no-installinfo and no-dist? 3. The macro AM_MAINTAINER_MODE is required. Already present in newlib/acinclude.m4 Note that maintainer-mode is still disabled by default. 4. Info files are always created in the build directory, and not in the source directory. This appears to be an error in the automake documentation describing '--cygnus' [2]. newlib's info files are generated in the source directory, and no special steps are needed to keep doing that. [2] https://lists.gnu.org/archive/html/bug-automake/2012-04/msg00028.html 5. texinfo.tex is not required if a Texinfo source file is specified. (The assumption is that the file will be supplied, but in a place that automake cannot find.) This effect is overriden by an explicit setting of the TEXINFO_TEX variable (the directory part of which is fed into texi2X via the TEXINPUTS environment variable). 6. Certain tools will be searched for in the build tree as well as in the user's PATH. These tools are runtest, expect, makeinfo and texi2dvi. For obscure automake reasons, this effect of '--cygnus' is not active for makeinfo in newlib's configury. However, there appears to be top-level configury which selects in-tree runtest, expect and makeinfo, if present. So, if that works as it appears, this effect is preserved. If not, this may cause problem if anyone is building those tools in-tree. This effect is not preserved for texi2dvi. This may cause problems if anyone is building texinfo in-tree. If needed, explicit checks for those tools looking in places relative to $(top_srcdir)/../ as well as in PATH could be added. 7. The check target doesn't depend on all. This effect is not preseved. The check target now depends on the all target. This concern seems somewhat academic given the current state of the testsuite. Also note that this doesn't touch libgloss.
2021-12-29newlib: Regenerate autotools filesJon Turney24-654/+450
2021-12-09newlib: Regenerate all autotools filesJon Turney36-765/+2274
Regenerate all aclocal.m4, configure and Makefile.in files.
2021-11-30Modifying patch from: marian.buschsieweke@ovgu.deJeff Johnston2-11/+24
The code accessing the floating point control/status register, namely #define __cfc1(__fcsr) __asm __volatile("cfc1 %0, $31" : "=r" (__fcsr) does not compile with mips16. This changed the makefile to pass -mno-mips16 to avoid the following compiler error: mips-mti-elf fails with "Error: unrecognized opcode `cfc1 $3,$31'"
2021-11-06libgloss/newlib: update configure.ac in Makefile.in filesMike Frysinger12-12/+12
The maintainer rules refer to configure.in directly, so update that after renaming all the configure.ac files.
2021-09-13libgloss/newlib: rename configure.in to configure.acMike Frysinger12-0/+0
The .in name has been deprecated for a long time in favor of .ac.
2021-09-03ldexp/ldexpf: avoid assembler warningCorinna Vinschen2-2/+2
libm/machine/i386/f_ldexp.S:30: Warning: no instruction mnemonic suffix given and no register operands; using default for `fild' libm/machine/i386/f_ldexpf.S:30: Warning: no instruction mnemonic suffix given and no register operands; using default for `fild' fix this by adding the l mnemonic suffix Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-04-21fix some Arm FP routines not checking if floating point is enabledTies Stuij6-6/+6
A lot of the Arm FP routines check for the availability of floating point by way of `(__ARM_FP & 0x4)`. However some do not. This patch remedies this.
2021-04-13Cygwin: don't export _feinitialise from newlibCorinna Vinschen1-6/+1
Use the more official fesetenv(FE_DFL_ENV) from _dll_crt0, thus allowing to drop the _feinitialise declaration from fenv.h. Provide a no-op _feinitialise in Cygwin as exportable symbol for really old applications when _feinitialise was called from mainCRTStartup in crt0.o. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
generated by cgit v1.1 at 2024-08-03 04:33:16 +0000