Message ID | 20211106084056.2506166-1-xuchenghua@loongson.cn |
---|---|
Headers | show |
Series | Add LoongArch support. | expand |
On Sat, 2021-11-06 at 16:40 +0800, Chenghua Xu wrote: > > This is a series of patch sets to support LoongArch. > > The LoongArch architecture (LoongArch) is an Instruction Set > Architecture (ISA) that has a Reduced Instruction Set Computer (RISC) > style. > The documents are on > https://loongson.github.io/LoongArch-Documentation/README-EN.html > > The ELF ABI Documents are on: > https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html > > The binutils has been merged into trunk: > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=560b3fe208255ae909b4b1c88ba9c28b09043307 Congratulations! > The ABI -mabi=name is still under discussion and may change in the > next version, > the rest can be reviewed. > > chenglulu (7): > LoongArch Port: gcc The [PATCH 1/1] does not arrive at gcc-patches successfully. I guess it's because of some mail size limit issue... According to https://gcc.gnu.org/contribute.html: > If the patch is too big or too mechanical, posting it gzipped or > bzip2ed and uuencoded or encoded as a base64 MIME part is acceptable, > as long as the ChangeLog is still posted as plain text.
This patch does not arrive at mail list. Send as an attachment in a compressed format.
On Mon, 2021-11-08 at 10:30 +0800, Chenghua Xu wrote: > This patch does not arrive at mail list. Send as an attachment in a > compressed format. I think .patch.gz is perferred instead of .tar.gz. And is it possible to seperate this into multiple commits? For example the whole "-march=native" support can be in a seperate commit. It will be easier to review those changes one-by-one. > --- /dev/null > +++ b/gcc/config/loongarch/linux.h /* snip */ > + /* Integer ABI */ > + #if DEFAULT_ABI_INT == ABI_LP64 > + #define INT_ABI_SUFFIX "lib64" > + #endif "INT_ABI_SUFFIX" should be renamed to INT_ABI_LIBDIR or something. "lib64" is not a "suffix". > --- /dev/null > +++ b/gcc/config/loongarch/loongarch-opts.c /* snip */ > + /* 5. Check integer ABI-ISA for conflicts. */ > + switch (*isa_int) > + { > + case ISA_LA64: > + if (*abi_int != ABI_LP64) goto error_int_abi; > + break; /* snip */ > + switch (*isa_float) > + { > + case ISA_SOFT_FLOAT: > + if (*abi_float != ABI_SOFT_FLOAT) goto error_float_abi; > + break; > + > + case ISA_SINGLE_FLOAT: > + if (*abi_float != ABI_SINGLE_FLOAT) goto error_float_abi; > + break; > + > + case ISA_DOUBLE_FLOAT: > + if (*abi_float != ABI_DOUBLE_FLOAT) goto error_float_abi; > + break; > The goto statements should be in a new line (coding style). > --- /dev/null > +++ b/gcc/config/loongarch/gnu-user.h /* snip */ > +#define GLIBC_DYNAMIC_LINKER_LP64 "/lib64/ld.so.1" It is "ld-linux-loongarch-lp64d.so.x" in the latest ELF psABI. "x" is now 0 but we have an ongoing discussion to make it 1. > +++ b/gcc/config/loongarch/sync.md /* snip */ > +(define_insn "atomic_cas_value_strong<mode>" > + [(set (match_operand:GPR 0 "register_operand" "=&r") > + (match_operand:GPR 1 "memory_operand" "+ZC")) > + (set (match_dup 1) > + (unspec_volatile:GPR [(match_operand:GPR 2 "reg_or_0_operand" "rJ") > + (match_operand:GPR 3 "reg_or_0_operand" "rJ") > + (match_operand:SI 4 "const_int_operand") ;; mod_s > + (match_operand:SI 5 "const_int_operand")] ;; mod_f > + UNSPEC_COMPARE_AND_SWAP)) > + (clobber (match_scratch:GPR 6 "=&r"))] > + "" > +{ > + static char buff[256] = {0}; > + buff[0] = '\0'; > + sprintf (buff + strlen (buff), "%%G5\\n\\t"); > + sprintf (buff + strlen (buff), "1:\\n\\t"); > + sprintf (buff + strlen (buff), "ll.<amo>\\t%%0,%%1\\n\\t"); > + sprintf (buff + strlen (buff), "bne\\t%%0,%%z2,2f\\n\\t"); > + sprintf (buff + strlen (buff), "or%%i3\\t%%6,$zero,%%3\\n\\t"); > + sprintf (buff + strlen (buff), "sc.<amo>\\t%%6,%%1\\n\\t"); > + sprintf (buff + strlen (buff), "beq\\t$zero,%%6,1b\\n\\t"); > + sprintf (buff + strlen (buff), "b\\t3f\\n\\t"); > + sprintf (buff + strlen (buff), "2:\\n\\t"); > + sprintf (buff + strlen (buff), "dbar\\t0x700\\n\\t"); > + sprintf (buff + strlen (buff), "3:\\n\\t"); > + > + return buff; > +} These "cascading" sprintf/strlen looks stupid. It can be simply: return "%G5\\n\\t" "1:\\n\\t" "ll.<amo>\\t%0,%1\\n\\t" ... "3:\\n\\t"; The compiler will concatenate the string literals so there will be no runtime overhead. And there should be some comment to explain this LL/SC loop and dbar workaround IMO. Likewise for other atomic LL/SC expansions.
You have: > +#define GLIBC_DYNAMIC_LINKER_LP64 "/lib64/ld.so.1" See my comments on the glibc patch series <https://sourceware.org/pipermail/libc-alpha/2021-August/130298.html>. Specifically, the point that all new glibc ports should have unique per-ABI dynamic linker names for each ABI supported by the port, preferably referencing the architecture name somewhere in the dynamic linker name. /lib64/ld.so.1 is a name that's already in use, so should not be used by any ABI of this new port. > + error ("%<-march=%s%> does not work on a cross compiler.", Error messages should not end with '.'. > + error ("%<-mtune=%s%> does not work on a cross compiler.", Likewise. I didn't see any additions to contrib/config-list.mk anywhere in the patch series. (See "Back End" in sourcebuild.texi for a list of places you may need to update as part of a GCC port, including config-list.mk.) Please make sure the back end builds cleanly with current GCC mainline. This can be tested either with a native bootstrap, or by building a cross compiler, using a native compiler of the same GCC mainline version for the build and configuring using --enable-werror-always (that configure option has the effect of enabling -Werror in the same way that later bootstrap stages in a native bootstrap do).
On Mon, 2021-11-08 at 23:14 +0000, Joseph Myers wrote: /* snip */ > Please make sure the back end builds cleanly with current GCC mainline. > This can be tested either with a native bootstrap, or by building a cross > compiler, using a native compiler of the same GCC mainline version for the > build and configuring using --enable-werror-always (that configure option > has the effect of enabling -Werror in the same way that later bootstrap > stages in a native bootstrap do). gcc trunk does not build with glibc-2.34+ and --enable-werror-always :( gcc -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wno-overlength-strings -pedan tic -Wno-long-long -Werror -DHAVE_CONFIG_H -I. -I../../../fixincludes -I../incl ude -I../../../fixincludes/../include ../../../fixincludes/fixincl.c ../../../fixincludes/fixincl.c: In function ‘process’: ../../../fixincludes/fixincl.c:1356:7: error: argument 1 is null but the corresp onding size argument 2 value is 4096 [-Werror=nonnull] 1356 | fprintf (stderr, "Cannot access %s from %s\n\terror %d (%s)\n", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1357 | pz_curr_file, getcwd ((char *) NULL, MAXPATHLEN), | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1358 | erno, xstrerror (erno)); | ~~~~~~~~~~~~~~~~~~~~~~~ In file included from ../../../fixincludes/system.h:192, from ../../../fixincludes/fixlib.h:29, from ../../../fixincludes/fixincl.c:24: /usr/include/unistd.h:531:14: note: in a call to function ‘getcwd’ declared with attribute ‘access (write_only, 1, 2)’ 531 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur | ^~~~~~ cc1: all warnings being treated as errors I've sent the fix as https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583820.html.
On Tue, 2021-11-09 at 21:53 +0800, Xi Ruoyao via Gcc-patches wrote: > On Mon, 2021-11-08 at 23:14 +0000, Joseph Myers wrote: > > /* snip */ > > > Please make sure the back end builds cleanly with current GCC mainline. > > This can be tested either with a native bootstrap, or by building a cross > > compiler, using a native compiler of the same GCC mainline version for the > > build and configuring using --enable-werror-always (that configure option > > has the effect of enabling -Werror in the same way that later bootstrap > > stages in a native bootstrap do). > > gcc trunk does not build with glibc-2.34+ and --enable-werror-always :( > > I've sent the fix as > https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583820.html. I applied the 7 patches and my fix onto c71cb26a9e. A native bootstrap with --enable-werror-always has succeeded.
On Tue, 2021-11-09 at 23:52 +0800, Xi Ruoyao via Gcc-patches wrote: > > gcc trunk does not build with glibc-2.34+ and --enable-werror-always > > :( > > > > I've sent the fix as > > https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583820.html. > > I applied the 7 patches and my fix onto c71cb26a9e. A native bootstrap > with --enable-werror-always has succeeded. A test summary is attached.