On Thu, Jul 31, 2025 at 04:22:20PM -0400, James K. Lowden wrote: > I want to understand what our baseline is wrt %z in diagnostic > messages. The proximate cause is this change on July 11 for 32-bit > Darwin to gcc/cobol/parse.y: > > error_msg(loc, "FUNCTION %qs has " > - "inconsistent parameter type %zu (%qs)", > - keyword_str($1), p - args.data(), name_of(p->field) ); > + "inconsistent parameter type %ld (%qs)", > + keyword_str($1), (long)(p - args.data()), name_of(p->field) ); > > I'm writing because I want to put it back as it was, and I don't want > to work at cross purposes. > > This code had problems before the revision, which I'll describe > shortly. My objection is that this revision IMO takes the code > backwards. > > 1. It uses a C-style cast for C++ code in 2025. C++ invented new cast > operators for a reason, and cppcheck looks for them.
We have many thousands of C-style casts in the gcc C++ sources, they are fine. > 2. The diagnostic framework recognizes %z in gcc 15 (and some versions > prior). A bootstrap build should compile the above without the revision. If error_msg is gcc_tdiag format (i.e. uses gcc pretty-print.cc diagnostics rather than host *printf), then %zu and %td and %wu etc. are ok. If p - args.data() has ptrdiff_t type, then the right format specifier is %td, not %zu though. If the function instead used host *printf (various gcobol FE functions do), then %zu or %td or %wu are not ok, sadly not all supported host arches support those. So, for *printf family one needs to use macros like HOST_WIDE_INT_PRINT_DEC (for HOST_WIDE_INT argument), or HOST_SIZE_T_PRINT_UNSIGNED (for size_t, with casts to (fmt_size_t)). > I think someone is going to tell me that gcc should build on 32-bit Darwin > without error using the compiler that came with the system. But, > > https://www.gnu.org/software/gcc/gcc-16/criteria.html > > makes no such claim. > > I would answer: > > 3. The last 32-bit Apple machine was manufactured in 2006, before Taylor > Swift was famous, when we still knew where Jim Gray was. No idea why you're talking specifically about 32-bit Darwin, there are tons of supported 32-bit hosts, and even if you don't want to support 32-bit targets in COBOL (I don't know why, when the libgcobol library is C++ it isn't that hard to add a class that emulates 128-bit arithmetics, I've attached it to one of the PRs), GCC should support cross-compilation from any of the supported hosts to any of the supported targets. > 4. We do not expect any COBOL users on 32-platforms, at all, ever. > > 5. It is counterproductive to restrict new code in gcc to features of > ancient compilers on obsolete hardware. No, portability is one of the important GCC features. > 6. Until and unless we can show the FE works on a 32-bit target, > adapting the error messages to be correct is pointless. > > When I asked about this previously, I was told we distinguish between > libraries we control and libraries we don't. Anything relying on the C > standard library needs to be backwards compatible such that the > compiler and produced binary use it correctly. Anything that is part > of gcc, and thus under our control, we're free to use. From that I > concluded that diagnostic messages can use any formatting characters > supported by the in-tree version of the diagnostic framework. If that > is incorrect, I would like to know which version of the diagnostic > framework to use as a reference, today and in the future. > > IOW, what about %z? See above, z/t/w are ok in gcc diagnostics (and in fact one can't use there the HOST_* macros inside of the format strings, they are translated and need to be translatable), they are not ok for *printf because there the host C library is used, and while z/t are in C99, not all supported hosts support it (I think e.g. AIX doesn't). > An improved version of that function will take std::vector as a > parameter and return N, the index of the offending element in args. Generally, in GCC (compiler side) we try to avoid using std::vector and use <vec.h> APIs instead when a vector is needed. Jakub
