Re: Supporting “crippled” MIPS implementations as cpu option
On Thu, Mar 6, 2025 at 7:14 AM mzpqnxow via Gcc wrote:
>
> Hello,
>
> Direct questions listed at the end for the impatient :)
>
> Hopefully my mail client wraps the text properly, if not, I apologize in
> advance. I haven’t used this client for mailing list posts before…
>
> I’m looking for information on GCC patch submission, hoping someone can
> provide some guidance. Specifically, the formal or informal guidelines used
> when determining if a specific submission is, in principle, something that
> is welcomed, assuming it meets technical guidelines. I do not want to send
> a patch if it won’t be considered as I don’t want to waste developers’ time
>
> What I’m talking about: I would like to understand how open the project is
> to accepting small patches that add support for a CPU (-mcpu targets) when
> they’re very slight variations within a supported architecture
>
> Why: I have the occasional need to have gcc emit MIPS1 instructions that do
> not contain a subset of loads and stores (lwl/swl/lwr/swl instructions)
The GCC patch to provide an option not emit lwl/lwr/swl/swr should be easily.
Something like:
```
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index e224ade2a1a..c40cae1a530 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1191,7 +1191,8 @@ struct mips_cpu_info {
&& (MODE) == V2SFmode)) \
&& !TARGET_MIPS16)
-#define ISA_HAS_LWL_LWR(mips_isa_rev <= 5 \
+#define ISA_HAS_LWL_LWR(mips_isa_rev <= 5
\
+&& TARGET_LEFT_RIGHT \
&& (!TARGET_MIPS16 || ISA_HAS_MIPS16E2))
#define ISA_HAS_IEEE_754_LEGACY(mips_isa_rev <= 5)
diff --git a/gcc/config/mips/mips.opt b/gcc/config/mips/mips.opt
index e24565469d9..e9414765b06 100644
--- a/gcc/config/mips/mips.opt
+++ b/gcc/config/mips/mips.opt
@@ -214,6 +214,10 @@ mfix4300
Target Var(TARGET_4300_MUL_FIX)
Work around an early 4300 hardware bug.
+mleftright
+Target Var(TARGET_LEFT_RIGHT) Init(1)
+Emit the load/store left/right instruction if possible
+
mfp-exceptions
Target Var(TARGET_FP_EXCEPTIONS) Init(1)
FP exceptions are enabled.
```
Adding a configure option should not be hard too but I am leaving that
up to you.
Note the MIPS port is not giving much support and I suspect patches
for this will be accepted as shown above it is minor.
As far as inline-asm/asm that uses load/stores left-right, you are
going need to audit each package that you.
You could also in theory error out in GNU binutils as which can help.
Accepting a patch to both I suspect will be acceptable upstream
communities since there is little to no development on the MIPS
backends and they are only now used for embedded/legacy developement.
Thanks,
Andrew Pinski
>
> Context/History: There are several patches floating around that do this,
> primarily from developers working on embedded networking development on a
> few Realtek SoCs in the rtl819x family. These CPUs do not support these
> instructions due to patent issues, and will SIGILL when encountering them.
> I’m not aware of any work to contribute these upstream after a few quick
> searches. There is extensive information available on OpenWRT [1]
>
> Some specific questions:
>
> 1. Are any gcc mips experts aware of a way to accomplish what I described
> above (no lwl/swl/lwr/swr instructions) *without* patching GCC? I have not
> yet tested -mno-struct-align/-mstrict-align though they sound promising. I
> plan to give them a try, it may render this all moot. I may be
> misunderstanding precisely what they do
> 2. Are these sorts of patches (mcpu target, unpopular architecture)
> generally considered currently?
> 3. If “it depends” - what are the primary considerations? Does the
> popularity of the target factor into it? I admit that this CPU is not
> popular and though it can still be found in embedded network devices, it is
> only getting less common
> 4. If such a patch produces code that is inherently incompatible with glibc
> (or some other core dependency of a common toolchain) is that considered a
> blocker? What I’m referring to here is a (theoretical) example where glibc
> uses the “bad” instructions in an asm block as part of some low-level
> component (iirc, sigsetjmp, some of the loader functionality, etc. uses
> hand-written asm)
>
> I understand this is a pretty niche thing, only benefitting a subset of GCC
> users, so I’m not expecting a lot of willingness to accept such a patch,
> despite its relatively simplicity. I’m appreciative of any advice, guidance
> or commentary the community has to offer, even if the answer is effectively
> “don’t bother” :)
>
> Thanks!
>
> 1. https://openwrt.org/docs/techref/hardware/soc/soc.realtek
Re: Supporting “crippled” MIPS implementations as cpu option
On 3/6/25 3:07 PM, mzpqnxow via Gcc wrote: Hello, Direct questions listed at the end for the impatient :) Hopefully my mail client wraps the text properly, if not, I apologize in advance. I haven’t used this client for mailing list posts before… I’m looking for information on GCC patch submission, hoping someone can provide some guidance. Specifically, the formal or informal guidelines used when determining if a specific submission is, in principle, something that is welcomed, assuming it meets technical guidelines. I do not want to send a patch if it won’t be considered as I don’t want to waste developers’ time What I’m talking about: I would like to understand how open the project is to accepting small patches that add support for a CPU (-mcpu targets) when they’re very slight variations within a supported architecture Why: I have the occasional need to have gcc emit MIPS1 instructions that do not contain a subset of loads and stores (lwl/swl/lwr/swl instructions) Context/History: There are several patches floating around that do this, primarily from developers working on embedded networking development on a few Realtek SoCs in the rtl819x family. These CPUs do not support these instructions due to patent issues, and will SIGILL when encountering them. I’m not aware of any work to contribute these upstream after a few quick searches. There is extensive information available on OpenWRT [1] Some specific questions: 1. Are any gcc mips experts aware of a way to accomplish what I described above (no lwl/swl/lwr/swr instructions) *without* patching GCC? I have not yet tested -mno-struct-align/-mstrict-align though they sound promising. I plan to give them a try, it may render this all moot. I may be misunderstanding precisely what they do 2. Are these sorts of patches (mcpu target, unpopular architecture) generally considered currently? 3. If “it depends” - what are the primary considerations? Does the popularity of the target factor into it? I admit that this CPU is not popular and though it can still be found in embedded network devices, it is only getting less common 4. If such a patch produces code that is inherently incompatible with glibc (or some other core dependency of a common toolchain) is that considered a blocker? What I’m referring to here is a (theoretical) example where glibc uses the “bad” instructions in an asm block as part of some low-level component (iirc, sigsetjmp, some of the loader functionality, etc. uses hand-written asm) I understand this is a pretty niche thing, only benefitting a subset of GCC users, so I’m not expecting a lot of willingness to accept such a patch, despite its relatively simplicity. I’m appreciative of any advice, guidance or commentary the community has to offer, even if the answer is effectively “don’t bother” :) Thanks! 1. https://openwrt.org/docs/techref/hardware/soc/soc.realtek I would generally expect/hope that such a patch would be relatively simple to accept, given that, unless I am gravely wrong about the meaning and functionality of the macro "ISA_HAS_LWL_LWR" in gcc/config/mips/mips.h, it seems like a patch should not actually involve much more than adjusting this macro (and adding some option for the corresponding CPUs, as you mentioned).
some Small questions of a new hand
Dear GCC Community, I have just joined the GCC community and am currently learning about the framework and essential knowledge related to the GCC compiler. I have cloned the GCC source code to my virtual machine, but I find the codebase to be quite large and am unsure where to start. Do you have any suggestions? Additionally, I have read the GCC community's development guide, and I would like to start by working on some simple bugs to gain practical experience. However, I am having trouble finding where these issues are discussed (it feels slightly different from the discussions on the GitHub platform). Is it only through the daily emails sent after subscribing that I can find these issues? Thank you! >From Gwen Fu
Re: some Small questions of a new hand
On Thu, 6 Mar 2025 at 15:09, Gwen Fu via Gcc wrote: > > Dear GCC Community, > > I have just joined the GCC community and am currently learning about the > framework and essential knowledge related to the GCC compiler. I have > cloned the GCC source code to my virtual machine, but I find the codebase > to be quite large and am unsure where to start. Do you have any suggestions? Have you seen https://gcc.gnu.org/wiki/GettingStarted ? > Additionally, I have read the GCC community's development guide, and I > would like to start by working on some simple bugs to gain practical > experience. However, I am having trouble finding where these issues are > discussed (it feels slightly different from the discussions on the GitHub > platform). Is it only through the daily emails sent after subscribing that > I can find these issues? No, they're in https://gcc.gnu.org/bugzilla - the emails are generated from there. The GettingStarted wiki page links to https://gcc.gnu.org/wiki/EasyHacks which tells you how find the bugs in https://gcc.gnu.org/bugzilla that are marked as EasyHack.
gcc-12-20250306 is now available
Snapshot gcc-12-20250306 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20250306/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision 6eec3f754319eeda377f1773e684ebc8792dc27a You'll find: gcc-12-20250306.tar.xz Complete GCC SHA256=5ebb60c63c1a42867d0eea2cdbdb5812447045c8bc338c666d6317f7af382b30 SHA1=0dcf923c5828f23f395562c0060d8a3f3be800c5 Diffs from 12-20250227 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
