[1/5] Altera Nios II: GCC backend patches

On 13/4/26 4:29 AM, Joseph S. Myers wrote:
>> +/* Define built-in preprocessor macros.  */
>> +#define TARGET_CPU_CPP_BUILTINS()                   \
>> +  do                                                \
>> +    {                                               \
>> +      builtin_define_std ("NIOS2");                 \
>> +      builtin_define_std ("nios2");                 \
>> +      if (TARGET_BIG_ENDIAN)                        \
>> +        builtin_define_std ("nios2_big_endian");    \
>> +      else                                          \
>> +        builtin_define_std ("nios2_little_endian"); \
>> +    }                                               \
>> +  while (0)
> 
> Do you really need the macro variants in the user namespace, or could you 
> just use builtin_define with implementation-namespace variants only (like 
> newer ports tend to do, e.g. AArch64 defines __aarch64__, __AARCH64EB__, 
> __AARCH64EL__ as appropriate, but never any variants without the leading 
> __)?

This should be inherited from the older Altera sources. I do not
see any use of nios2/NIOS2 names without '__' acround, but if not a
pressing issue, I would like to leave it as is. The nios2 toolchain is
being upstreamed only now, but has been in use for several years, so
preserving this bit of old behavior may be prudent.

>> Index: gcc/config/nios2/linux.h
>> ===================================================================
>> --- gcc/config/nios2/linux.h	(revision 0)
>> +++ gcc/config/nios2/linux.h	(revision 409063)
> 
>> +#undef LIB_SPEC
>> +#define LIB_SPEC "-lc \
>> + %{pthread:-lpthread}"
> 
> What's wrong with using the GNU_USER_TARGET_LIB_SPEC value from 
> gnu-user.h?  (If the header ordering means another header has overridden 
> that definition by now, you can just redefine LIB_SPEC to 
> GNU_USER_TARGET_LIB_SPEC here.)
> 

Corrected, thanks.

>> +#undef SYSROOT_SUFFIX_SPEC
>> +#define SYSROOT_SUFFIX_SPEC \
>> +  "%{EB:/EB}"
> 
> Normally, if SYSROOT_SUFFIX_SPEC is desired it isn't hardcoded like this; 
> instead, ./sysroot-suffix.h is listed in tm_file and t-sysroot-suffix in 
> tmake_file is used to generate sysroot-suffix.h.

The big-endian support for nios2 is not fully complete (nor publicized?)
yet. So I'm removing this altogether. Sysroot suffix support with be
added in the proper manner in the future if needed.

>> +  if (mode == BLKmode)
>> +    {
>> +      param_size = int_size_in_bytes (type);
>> +      if (param_size < 0)
>> +        internal_error
>> +          ("Do not know how to handle large structs or variable length types");
> 
> This sounds like a case for sorry () rather than internal_error () to me - 
> as I understand it, it's a matter of a known valid source-code construct 
> not handled by the port, as opposed to a should-never-happen condition 
> that indicates a condition you didn't think any source code could 
> generate.
> 
> Note that diagnostics should start with a lowercase letter, here and 
> elsewhere.

This has been replaced with simply gcc_assert().

>> +## MULTILIB_OPTIONS
>> +## For some targets, invoking GCC in different ways produces objects that
>> +## can not be linked together.  For example, for some targets GCC produces
>> +## both big and little endian code.  For these targets, you must arrange
>> +## for multiple versions of libgcc.a to be compiled, one for each set of
>> +## incompatible options.  When GCC invokes the linker, it arranges to link
>> +## in the right version of libgcc.a, based on the command line options
>> +## used.
>> +## The MULTILIB_OPTIONS macro lists the set of options for which special
>> +## versions of libgcc.a must be built.  Write options that are mutually
>> +## incompatible side by side, separated by a slash.  Write options that may
>> +## be used together separated by a space.  The build procedure will build
>> +## all combinations of compatible options.
>> +##
>> +## For example, if you set MULTILIB_OPTIONS to m68000/m68020 msoft-float,
>> +## Makefile will build special versions of libgcc.a using the following
>> +## sets of options: -m68000, -m68020, -msoft-float, -m68000 -msoft-float,
>> +## and -m68020 -msoft-float.
> 
> Don't include such long comments that just repeat the standard definition 
> of some interface and say nothing Nios II-specific.
> 
>> +## The BUILD_BE_MULTILIB and BUILD_PG_MULTILIB variables allow the
>> +## makefile user to enable/disable the generation of the precompiled
>> +## big endian and profiling libraries. By default, the big endian 
>> +## libraries are not created on a windows build and the profiling
>> +## libraries are not created on a Solaris build. All other library 
>> +## combinations are created by default.
>> +
>> +# Uncomment to temporarily avoid building big endian and profiling libraries during a Windows build.
>> +#ifeq ($(DEV_HOST_OS), win32)
>> +#BUILD_BE_MULTILIB ?= 0
>> +#BUILD_PG_MULTILIB ?= 0
>> +#endif
> 
> I don't know where DEV_HOST_OS is supposed to come from, but this doesn't 
> appear to make much sense for FSF GCC anyway.  If you want options to have 
> various possible sets of multilibs, model them on e.g. SH 
> --with-multilib-list rather than having this Nios II-specific approach.

I have changed config/nios2/t-nios2 to a minimal file with a possible
set of multilib options, currently commented out. Such support is still
unclear, and even the Mentor toolchains don't support them ATM.

Other formatting, function comment, etc. issues have been dealt with.
Updated patches attached.

Thanks,
Chung-Lin

[1/5] Altera Nios II: GCC backend patches

Commit Message

Patch