Question about adding a new GCC derived compiler

[lizalc]

I'm looking to add the Microchip XC32 compiler which is pretty much GCC with some PIC32 specific addons.

The compiler technically supports most (all?) of the options / etc the underlying GCC version provides. However the compiler user manual states:

The GCC compiler on which the MPLAB XC32 C Compiler is based provides many options in addition
to those discussed in this document. It is recommended that you avoid any option that has not been
documented here, especially those that control the generation or optimization of code.

When adding the compiler to Meson should I strictly follow the compiler manual? Or is there some leeway so some of the underlying GCC features can be used (warnings not listed in the compiler manual, C/C++ stds, etc)?

[dcbaker]

I would err to the side of "allow underlying GCC things", unless we find that they don't work, and then we can special case them away. in otherwords, I'd directly inherit the GnuCCompiler class and just override the name and special case the supported platforms etc.

[lizalc]

That's what I was thinking, just wanted to check. But it leads me to another question about the toolchain version. Inheriting from GnuCCompiler means using the GCC version rather than the XC32 version. Is this a problem? I'm thinking about how in a meson.build file someone might call meson.get_compiler() and get back a compiler object that uses the GCC version rather than the XC32 version. For my use case that isn't a problem but it might confuse someone later on.

For reference, the current XC32 version is 4.60 while the underlying GCC version is 8.3.1:

xc32-gcc --version output:

pic32m-gcc (Microchip XC32 Compiler v4.60) 8.3.1 Build date: Feb 19 2025
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[dcbaker]

Yeah... hmm. That's an interesting problem because the GCC class is going to need the gcc version number to do the right thing, but the XC32 class might need the XC32 number for other things, and as you point out the end user is going to expect to get the XC32 number for a version comparison not the GCC number.

That might require some additional work in the XC32 abstractions. I think the internal bits are solvable, but the user exposed part might require some more work. I can help with that when you get that far.

[lizalc]

What about adding a gcc_version field to the Gnu* classes to represent the GCC version? And then updating the GCC version checks to use that instead of version. For actual GCC gcc_version and version would be the same but for GCC-derived compilers they can set gcc_version to get the desired behavior from the Gnu* classes while version can be whatever and bubbled up to the end user correctly.

[dcbaker]

The concern I have is that our abstractions are based around the idea that compilers are either gnu-like or msvc-like, there are a lot of assumptions that center around the idea that Compiler.version is the version of the given compiler, and those are inherited by a lot abstractions for compilers that we may not be able to test. It might be possible, but I suspect it will be incredible invasive.

I haven't looked at the code recently to see what would be involved, but I suspect it's less work (and less invasive) to have XC32 have it's own version to track than have GnuLike compiler do it

[lizalc]

I just submitted #15169 for adding XC32.