public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paul Hua <paul.hua.gm@gmail.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: Chenghua Xu <xuchenghua@loongson.cn>,
	yangyujie@loongson.cn, chenglulu@loongson.cn,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH v3 06/12] LoongArch Port: Builtin macros.
Date: Fri, 17 Dec 2021 15:45:41 +0800	[thread overview]
Message-ID: <CAKjxQHnXekxOACwPbNLH2d191Mme_zZyGR=BfRdsrDsmL5FGNA@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2112140011090.1504422@digraph.polyomino.org.uk>

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

  reply	other threads:[~2021-12-17  7:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-10  7:43 [PATCH v3 00/12] Add LoongArch support Chenghua Xu
2021-12-10  7:43 ` [PATCH v3 01/12] LoongArch Port: gcc build Chenghua Xu
2021-12-10  7:43 ` [PATCH v3 02/12] LoongArch Port: Regenerate gcc/configure Chenghua Xu
2021-12-10  7:43 ` [PATCH v3 03/12] LoongArch Port: Machine Decsription files Chenghua Xu
2021-12-20 12:34   ` Xi Ruoyao
2021-12-10  7:43 ` [PATCH v3 04/12] LoongArch Port: Machine description C files and .h files Chenghua Xu
2021-12-18 17:53   ` Xi Ruoyao
2021-12-10  7:43 ` [PATCH v3 05/12] LoongArch Port: Builtin functions Chenghua Xu
2021-12-10  7:43 ` [PATCH v3 06/12] LoongArch Port: Builtin macros Chenghua Xu
2021-12-14  0:13   ` Joseph Myers
2021-12-17  7:45     ` Paul Hua [this message]
2021-12-18  9:37       ` Xi Ruoyao
2021-12-19  1:31         ` Paul Hua
2021-12-20  7:35           ` Xi Ruoyao
2021-12-20 14:08             ` Xi Ruoyao
2021-12-10  7:43 ` [PATCH v3 07/12] LoongArch Port: libgcc Chenghua Xu
2021-12-10  7:43 ` [PATCH v3 08/12] LoongArch Port: Regenerate libgcc/configure Chenghua Xu
2021-12-10  7:43 ` [PATCH v3 09/12] LoongArch Port: libgomp Chenghua Xu
2021-12-10  7:43 ` [PATCH v3 10/12] LoongArch Port: gcc/testsuite Chenghua Xu
2021-12-10  7:43 ` [PATCH v3 11/12] LoongArch Port: Regenerate configure Chenghua Xu
2021-12-10  7:43 ` [PATCH v3 12/12] LoongArch Port: Add doc Chenghua Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKjxQHnXekxOACwPbNLH2d191Mme_zZyGR=BfRdsrDsmL5FGNA@mail.gmail.com' \
    --to=paul.hua.gm@gmail.com \
    --cc=chenglulu@loongson.cn \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=xuchenghua@loongson.cn \
    --cc=yangyujie@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).