On Wed, 19 Mar 2025 15:24:19 +0100 (CET) Richard Biener <rguent...@suse.de> wrote:
> The following removes HOWEVER_GCC_DEFINES_TREE and the alternate > definition of tree from symbols.h and instead ensures that both > coretypes.h and tree.h are included where required. This required > putting GCCs own 'NONE' in a scoped enum (see separate patch) and > renaming the cobol use of UNSIGNED, SIGNED and BLOCK which conflict > with enums from tree.h. IIUC, your intention is to pave the way for computations on tree types in the front end, in order to do away with _Float128. I'm not convinced this effort is either good or necessary. I'm a afraid of ending up with code no one including me understands, for the sake of portability to architectures no one will ever use. I think you're assuming I understand things I don't, and possibly assuming something to be necessary that isn't, in this context. More than one person has said something along the lines of "the host shouldn't use native computation" as though it's self-evident I'd really, really like to understand that better. If that's written down somewhere with a rationale, I'm happy to read it before making any fuss. As of today, I don't understand why that should be true. Even better would be that plus documentation for how to do it, since I already know how computation in C++ works (pretty well, anyway). Before we get too far into it, let me alert you to ramifications that come immediately to mind. In parse.y I'm sure you've already seen cce_expr, an arithmetic parser for "Constant Compile-time Expressions" as ISO has it, or "cce" among friends. As of now, any expression consisting of only numeric constants is reduced to a _Float128. That value may: 1. participate in boolean evaluation, including to strings. 2. participate later evaluation with another cce 3. participate in further runtime evaluation with runtime values 4. define the size of a "data item", COBOL for "variable", usually in Working-Storage Section. That includes the size of numeric type in digits, the size of an alphanumeric type in characters, and the size of an array (which COBOL calls a table. COBOL is like French: it has a different word for everything.) 5. be an initial value for a numeric type (display, integer, fixed- or floating-point). While the computation is floating point, the parser in its actions restricts some uses to integral types. Failure to do so is a bug. On one hand, in general I'm not sure _Float128 suffices to meet ISO COBOL's requirements. On the other hand, we'll never have a single variable with a size of 2^64, never mind a *size* with 31 digits of precision! So _Float128 has us covered for all practical purposes, especially regarding sizes. On the 3rd hand, it's very nice while debugging the parser to see these numbers as numbers, not as some abstract tree type. I just want to put all 3 hands on the table, and make sure we all understand why we're doing this, if we are, and what it will entail if we do. I'm sure you feel the same. --jkl
