Robert Dubner <rdub...@symas.com> writes: > Anybody who might have gotten interested should stand down.
Glad I could be of help ;) You had it sorted before I even got to see the first email. > > As usual, that analysis got me thinking. > > I got focused on where var_decl_return_code was being used. (I was wrong. > I made the mistake because I had just eliminated two sets of errors caused > by the optimization actually optimizing away things I need, so I had that > in the front of my brain.) Richard told me of something odd at the point > where var_decl_return was being established. I finally decided to look at > that. > > Turned out, ultimately, to be a SHORT / USHORT mismatch on the variables > being given to a MODIFY_EXPR. Apparently the optimization algorithms can > be extremely cranky about value types. > > In any event, with that straightened out, everything is working without > the flag_strict_aliasing modification. > > Thanks for asking, and thanks for listening. > >> -----Original Message----- >> From: Robert Dubner <rdub...@symas.com> >> Sent: Friday, April 4, 2025 16:02 >> To: Sam James <s...@gentoo.org> >> Cc: GCC Patches <gcc-patches@gcc.gnu.org> >> Subject: RE: [committed] cobol: Eliminate cobolworx UAT errors when >> compiling with -Os >> >> > -----Original Message----- >> > From: Sam James <mailto:s...@gentoo.org> >> > Sent: Friday, April 4, 2025 14:28 >> > To: Robert Dubner <mailto:rdub...@symas.com> >> > Cc: 'GCC Patches' <mailto:gcc-patches@gcc.gnu.org> >> > Subject: Re: [committed] cobol: Eliminate cobolworx UAT errors when >> > compiling with -Os >> > >> > Robert Dubner <mailto:rdub...@symas.com> writes: >> > >> > > From e70fe5ed46ab129a8b1da961c47d3fb75b11b988 Mon Sep 17 00:00:00 > 2001 >> > > From: Bob Dubner mailto:rdub...@symas.com >> > > Date: Fri, 4 Apr 2025 13:48:58 -0400 >> > > Subject: [PATCH] cobol: Eliminate cobolworx UAT errors when > compiling >> > with >> > > -Os >> > > >> > > Testcases compiled with -Os were failing because static functions > and >> > > static >> > > variables were being optimized away, because of improper data type >> > casts, >> > > and >> > > because strict aliasing (whatever that is) was resulting in some > loss >> > > of >> > >> > Are you unfamiliar with that from C and C++? See >> > https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8 (we > all >> > have our favourite documents to explain it) but I don't know if COBOL > is >> > amenable to the concept of TBAA. >> > >> > > data. >> > > These changes eliminate those known problems. >> > >> > I'd suggest that this should be accompanied by some question, > otherwise >> > it's going to live there forever and it's not necessarily right > (though >> > see above - if COBOL is incompatible with the idea, it might need >> > something along those lines, though not sure this is the right way of >> > doing that). >> > >> > That is, while you're free to approve your own COBOL patches, you're >> > also free to CC others and ask them for advice even if not explicit >> > approval before pushing them if something doesn't seem to be correct > or >> > is a hack. >> >> I am not any kind of compiler expert, except, possibly in one way: I > don't >> trust them. I have never trusted them. I don't trust them, and I don't >> trust the computers they run on. I regard compilers the same way a >> lion-tamer regards the big cats they work with every day. I treat them >> with firm respect; I expect them to behave the way they've been trained
