On Thu, 20 Mar 2025 10:06:20 +0100 (CET) Richard Biener <rguent...@suse.de> wrote:
> > 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. Right. I don't make any attempt in the parser when processing constant compile-time expressions to distinguish between integer and floating point. We do everything in _Float128 because it's integer-exact for any conceivable purpose, and COBOL-correct for precision. Be warned there are two parsers, and cdf.y is behind the curve. There we're still using, ahem, int64_t. Always leave room for improvement, that's my motto. By specification, the compile-time constant expressions in the CDF are subject to the same requirements as any other COBOL computation. In effect, though, the body of existing tests is thin, and in the real world the CDF computation we've seen is hardly ever much more than 0 or 1 for conditional compilation. So, it wasn't the place that needed my most urgent attention. Since that shortcoming doesn't affect portability, it might be easiest -- for you, not me -- to leave cdf.y as it is. When parse.y is ready, I can transfer the ideas myself, undoubtedly with your guidance. > 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. Thank you for taking the time to explain it to me, Richard. I know it takes time. I got no "work" done yesterday because I was typing English instead of C++. I was concerned that using tree was both complex and might make using integer constants more difficult if not impossible. No one else seems concerned, and everyone else understands the solution better than I do. My only rational option to to watch and learn. --jkl
