https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Robert Dubner from comment #14) > It has taken me a ridiculously long time to figure out that you are creating > trees for numeric values, and then doing arithmetic on those trees at > compile time. That is how e.g. C++ constexpr evaluation or folding of C constant expressions works, or what is used heavily during optimizations later on. > And what I am seeing here is a rampant enthusiasm bordering on glee for > improving the front end. And I simply have to get past the idea that *I* > have to fix everything. I'm not sure you'll have that many volunteers later on, the current state is that many people are looking at the new code and offering fixes for what they see, or efforts trying to get the FE in better shape, so that one can cross-compile COBOL etc. How many people will keep contributing after this initial phase is to be seen (apart from e.g. making global changes to GCC and adjusting all the FEs affected by the change, that will surely happen and is an advantage for in-tree FEs (in addition to people enabling cobol in their bootstraps/regtests and if they see a regression, they might have a look). > So: I am basically asking: "What can I do?" I think it would be useful if you could review Richi's patch from the POV of the FE co-author whether it is something you are ok with. Primarily start with the https://gcc.gnu.org/pipermail/gcc-patches/2025-March/678261.html patch, that one looks reasonable to me but wanted to hear from you/James first whether you're ok with that. > I offer up as an answer: "Bob, we need more test cases." And sure, that will be useful too. You can now use *> { dg-output-file "expected-test-output.txt" } too in there (but I'd suggest to use that primarily for larger outputs and where you are certain there is nothing architecture etc. specific in the output; e.g. if there are some runtime _Float128 computations especially when using most libm functions the ulp errors might depend on the exact C library).
