[v3,06/12] LoongArch Port: Builtin macros.
Commit Message
From: chenglulu <chenglulu@loongson.cn>
gcc/
*config/loongarch/loongarch-c.c
---
gcc/config/loongarch/loongarch-c.c | 136 +++++++++++++++++++++++++++++
1 file changed, 136 insertions(+)
create mode 100644 gcc/config/loongarch/loongarch-c.c
Comments
On Fri, 10 Dec 2021, Chenghua Xu wrote:
> + /* Macros dependent on the C dialect. */
> + if (preprocessing_asm_p ())
> + {
> + builtin_define_std ("LANGUAGE_ASSEMBLY");
> + builtin_define ("_LANGUAGE_ASSEMBLY");
> + }
> + else if (c_dialect_cxx ())
> + {
> + builtin_define ("_LANGUAGE_C_PLUS_PLUS");
> + builtin_define ("__LANGUAGE_C_PLUS_PLUS");
> + builtin_define ("__LANGUAGE_C_PLUS_PLUS__");
> + }
> + else
> + {
> + builtin_define_std ("LANGUAGE_C");
> + builtin_define ("_LANGUAGE_C");
> + }
> + if (c_dialect_objc ())
> + {
> + builtin_define ("_LANGUAGE_OBJECTIVE_C");
> + builtin_define ("__LANGUAGE_OBJECTIVE_C");
> + /* Bizarre, but retained for backwards compatibility. */
> + builtin_define_std ("LANGUAGE_C");
> + builtin_define ("_LANGUAGE_C");
> + }
> +}
I think all of this should be removed. It's a new architecture, there
should be no need for any such macros for things that are not
architecture-specific. In general, be careful to remove anything in the
port that is actually about the peculiarities of what was once done for
compatibility with existing software for an old architecture (MIPS?) that
you modelled the port on and that is not considered best practice for a
new architecture where you can make a fresh start.
Hi Joseph,
Thanks for your suggestion, Those macros can be removed, we will send
the v4 version soon.
Are there any problems in this series of patches?
In other words, What conditions are required for LoongArch back-end merged?
By the way, We are preparing the LoongArch machine to send to Cfarm for testing.
On Tue, Dec 14, 2021 at 8:13 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Fri, 10 Dec 2021, Chenghua Xu wrote:
>
> > + /* Macros dependent on the C dialect. */
> > + if (preprocessing_asm_p ())
> > + {
> > + builtin_define_std ("LANGUAGE_ASSEMBLY");
> > + builtin_define ("_LANGUAGE_ASSEMBLY");
> > + }
> > + else if (c_dialect_cxx ())
> > + {
> > + builtin_define ("_LANGUAGE_C_PLUS_PLUS");
> > + builtin_define ("__LANGUAGE_C_PLUS_PLUS");
> > + builtin_define ("__LANGUAGE_C_PLUS_PLUS__");
> > + }
> > + else
> > + {
> > + builtin_define_std ("LANGUAGE_C");
> > + builtin_define ("_LANGUAGE_C");
> > + }
> > + if (c_dialect_objc ())
> > + {
> > + builtin_define ("_LANGUAGE_OBJECTIVE_C");
> > + builtin_define ("__LANGUAGE_OBJECTIVE_C");
> > + /* Bizarre, but retained for backwards compatibility. */
> > + builtin_define_std ("LANGUAGE_C");
> > + builtin_define ("_LANGUAGE_C");
> > + }
> > +}
>
> I think all of this should be removed. It's a new architecture, there
> should be no need for any such macros for things that are not
> architecture-specific. In general, be careful to remove anything in the
> port that is actually about the peculiarities of what was once done for
> compatibility with existing software for an old architecture (MIPS?) that
> you modelled the port on and that is not considered best practice for a
> new architecture where you can make a fresh start.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
On Fri, 2021-12-17 at 15:45 +0800, Paul Hua via Gcc-patches wrote:
> Hi Joseph,
>
> Thanks for your suggestion, Those macros can be removed, we will send
> the v4 version soon.
>
> Are there any problems in this series of patches?
I'm not a compiler expert, but I'll bootstrap it once my 5th Linux From
Scratch build on LoongArch finishes and give a feedback.
> In other words, What conditions are required for LoongArch back-end
> merged?
GCC 12 development cycle is at stage 3 (general bugfixing) now. So a
new port have to wait until stage 1 of GCC 13 begins (in mid 2022, I
guess).
In the meantime you need to get someone applied by the SC as the
maintainer of the new port. Joseph is a SC member but I guess you'd
like to discuss this off-list.
> By the way, We are preparing the LoongArch machine to send to Cfarm
> for testing.
Hi Ruoyao,
Thank you for your attention.
> GCC 12 development cycle is at stage 3 (general bugfixing) now. So a
> new port have to wait until stage 1 of GCC 13 begins (in mid 2022, I
> guess).
I know it is stage3, but we are a new target, it's ok for GCC 12.
Hi,
I've bootstraped the patch with my GNU-stack fix
(https://github.com/loongson/gcc/pull/62) and --enable-werror-always.
Bootstrap succeeded, but with some warnings:
../../gcc/config/loongarch/loongarch.md:3205:1: warning: operand 0 missing mode?
../../gcc/config/loongarch/loongarch.md:3282:1: warning: operand 1 missing mode?
../../gcc/config/loongarch/loongarch.md:3329:1: warning: operand 1 missing mode?
../../gcc/config/loongarch/loongarch.md:3392:1: warning: operand 0 missing mode?
../../gcc/config/loongarch/loongarch.md:3470:1: warning: operand 1 missing mode?
../../gcc/config/loongarch/loongarch.md:3520:1: warning: operand 1 missing mode?
A similar issue exists for MIPS (PR101593) and I've not figured out how
to silence these warnings.
I'm trying to run GCC regression test on LoongArch, but all my previous
tries couldn't finish because a kernel panic was triggered. The kernel
was built from source pulled from
https://github.com/loongson/linux/tree/loongarch-next.
I'm not sure if this is a bug in Huacai's patches, or a bug in mainline
kernel, or even a hardware issue. If you have some idea about the panic
please inform me (this is off-topic though).
On Mon, 2021-12-20 at 15:35 +0800, Xi Ruoyao via Gcc-patches wrote:
> Hi,
>
> I've bootstraped the patch with my GNU-stack fix
> (https://github.com/loongson/gcc/pull/62) and --enable-werror-always.
> Bootstrap succeeded, but with some warnings:
>
> ../../gcc/config/loongarch/loongarch.md:3205:1: warning: operand 0 missing mode?
> ../../gcc/config/loongarch/loongarch.md:3282:1: warning: operand 1 missing mode?
> ../../gcc/config/loongarch/loongarch.md:3329:1: warning: operand 1 missing mode?
> ../../gcc/config/loongarch/loongarch.md:3392:1: warning: operand 0 missing mode?
> ../../gcc/config/loongarch/loongarch.md:3470:1: warning: operand 1 missing mode?
> ../../gcc/config/loongarch/loongarch.md:3520:1: warning: operand 1 missing mode?
>
> A similar issue exists for MIPS (PR101593) and I've not figured out how
> to silence these warnings.
>
> I'm trying to run GCC regression test on LoongArch, but all my previous
> tries couldn't finish because a kernel panic was triggered. The kernel
> was built from source pulled from
> https://github.com/loongson/linux/tree/loongarch-next.
>
> I'm not sure if this is a bug in Huacai's patches, or a bug in mainline
> kernel, or even a hardware issue. If you have some idea about the panic
> please inform me (this is off-topic though).
Well, I replaced the memory module and the system seems running stable...
Test summary is attached.
new file mode 100644
@@ -0,0 +1,136 @@
+/* LoongArch-specific code for C family languages.
+ Copyright (C) 2021 Free Software Foundation, Inc.
+ Contributed by Loongson Ltd.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+<http://www.gnu.org/licenses/>. */
+
+#define IN_TARGET_CODE 1
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "c-family/c-common.h"
+#include "cpplib.h"
+
+#define preprocessing_asm_p() (cpp_get_options (pfile)->lang == CLK_ASM)
+#define builtin_define(TXT) cpp_define (pfile, TXT)
+#define builtin_assert(TXT) cpp_assert (pfile, TXT)
+
+/* Define preprocessor macros for the -march and -mtune options.
+ PREFIX is either _LOONGARCH_ARCH or _LOONGARCH_TUNE, INFO is
+ the selected processor. If INFO's canonical name is "foo",
+ define PREFIX to be "foo", and define an additional macro
+ PREFIX_FOO. */
+#define LARCH_CPP_SET_PROCESSOR(PREFIX, CPU_TYPE) \
+ do \
+ { \
+ char *macro, *p; \
+ int cpu_type = (CPU_TYPE); \
+ \
+ macro = concat ((PREFIX), "_", \
+ loongarch_cpu_strings[cpu_type], NULL); \
+ for (p = macro; *p != 0; p++) \
+ *p = TOUPPER (*p); \
+ \
+ builtin_define (macro); \
+ builtin_define_with_value ((PREFIX), \
+ loongarch_cpu_strings[cpu_type], 1); \
+ free (macro); \
+ } \
+ while (0)
+
+/* TODO: what is the pfile technique ??? !!! */
+
+void
+loongarch_cpu_cpp_builtins (cpp_reader *pfile)
+{
+ builtin_assert ("machine=loongarch");
+ builtin_assert ("cpu=loongarch");
+ builtin_define ("__loongarch__");
+
+ LARCH_CPP_SET_PROCESSOR ("_LOONGARCH_ARCH", __ACTUAL_ARCH);
+ LARCH_CPP_SET_PROCESSOR ("_LOONGARCH_TUNE", __ACTUAL_TUNE);
+
+ /* Base architecture / ABI. */
+ if (TARGET_64BIT)
+ {
+ builtin_define ("__loongarch_grlen=64");
+ builtin_define ("__loongarch64");
+ }
+
+ if (TARGET_ABI_LP64)
+ {
+ builtin_define ("_ABILP64=3");
+ builtin_define ("_LOONGARCH_SIM=_ABILP64");
+ builtin_define ("__loongarch_lp64");
+ }
+
+ /* These defines reflect the ABI in use, not whether the
+ FPU is directly accessible. */
+ if (TARGET_DOUBLE_FLOAT_ABI)
+ builtin_define ("__loongarch_double_float=1");
+ else if (TARGET_SINGLE_FLOAT_ABI)
+ builtin_define ("__loongarch_single_float=1");
+
+ if (TARGET_DOUBLE_FLOAT_ABI || TARGET_SINGLE_FLOAT_ABI)
+ builtin_define ("__loongarch_hard_float=1");
+ else
+ builtin_define ("__loongarch_soft_float=1");
+
+
+ /* ISA Extensions. */
+ if (TARGET_DOUBLE_FLOAT)
+ builtin_define ("__loongarch_frlen=64");
+ else if (TARGET_SINGLE_FLOAT)
+ builtin_define ("__loongarch_frlen=32");
+ else
+ builtin_define ("__loongarch_frlen=0");
+
+ /* Native Data Sizes. */
+ builtin_define_with_int_value ("_LOONGARCH_SZINT", INT_TYPE_SIZE);
+ builtin_define_with_int_value ("_LOONGARCH_SZLONG", LONG_TYPE_SIZE);
+ builtin_define_with_int_value ("_LOONGARCH_SZPTR", POINTER_SIZE);
+ builtin_define_with_int_value ("_LOONGARCH_FPSET", 32 / MAX_FPRS_PER_FMT);
+ builtin_define_with_int_value ("_LOONGARCH_SPFPSET", 32);
+
+ /* Macros dependent on the C dialect. */
+ if (preprocessing_asm_p ())
+ {
+ builtin_define_std ("LANGUAGE_ASSEMBLY");
+ builtin_define ("_LANGUAGE_ASSEMBLY");
+ }
+ else if (c_dialect_cxx ())
+ {
+ builtin_define ("_LANGUAGE_C_PLUS_PLUS");
+ builtin_define ("__LANGUAGE_C_PLUS_PLUS");
+ builtin_define ("__LANGUAGE_C_PLUS_PLUS__");
+ }
+ else
+ {
+ builtin_define_std ("LANGUAGE_C");
+ builtin_define ("_LANGUAGE_C");
+ }
+ if (c_dialect_objc ())
+ {
+ builtin_define ("_LANGUAGE_OBJECTIVE_C");
+ builtin_define ("__LANGUAGE_OBJECTIVE_C");
+ /* Bizarre, but retained for backwards compatibility. */
+ builtin_define_std ("LANGUAGE_C");
+ builtin_define ("_LANGUAGE_C");
+ }
+}