On Wed, 19 Mar 2025, James K. Lowden wrote: > 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.
I hope that I can explain (and comment in code) everything needed here. > 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. Sure! So let me explain the advantage I see in using 'tree' instead of _Float128 as representation. You have confirmed what I somehow reverse engineered from the bits I touched - there's cases where integral type constants are stored in the _Float128 and it's required they keep being that. With using 'tree' you can actually store those as integer typed nodes. Then there is host _Float128 computations, doing those with 'tree' (or REAL_VALUE_TYPE) makes sure they behave exactly the same as if they were performed on the CPU you code generate for. The code also currently transfers the host representation of floats and integers to target memory without caring for endianess or float format differences. I realize most of the issues will only exist when cross-compiling but that's what GCC supports. That said - the current patching experiment I'm doing is to simply translate _Float128 usage to tree (or mostly REAL_VALUE_TYPE), without addressing endianess or target float format encoding issues or even trying to store integers as integers. One of the main points of the exercise for me is to see how far that _Float128 usage extends and what relies on it (there's quite some string processing done, and correctly converting that might be a challenge). Richard. -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
