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
