Thank you. I will implement that hook. And I'll see about that data
definition.
I could try to explain how RETURN-CODE became __gg___11_return_code6, and
why I defined it as unsigned char __gg__data_return_code[2] = {0,0}; But I
have a rule that I try to follow, which is that when I am starting to bore
myself, I stop talking.
Thank you very much for the information about the hook, and thanks for a
little bit of insight into how to see what the compiler is doing.
Bob D.
> -----Original Message-----
> From: Richard Biener <richard.guent...@gmail.com>
> Sent: Friday, April 4, 2025 09:50
> To: Robert Dubner <rdub...@symas.com>
> Cc: GCC Mailing List <gcc@gcc.gnu.org>
> Subject: Re: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is
> optimized away.
>
> On Fri, Apr 4, 2025 at 3:35 PM Richard Biener
> <richard.guent...@gmail.com> wrote:
> >
> > On Fri, Apr 4, 2025 at 3:06 PM Robert Dubner <rdub...@symas.com> wrote:
> > >
> > > This program exhibits the behavior when compiled with -O2, -O3 and -OS
> > >
> > > PROGRAM-ID. PROG.
> > > PROCEDURE DIVISION.
> > > MOVE 1 TO RETURN-CODE
> > > STOP RUN.
> >
> > Hmm, the call to exit() is still in the program.
> >
> > 0x000000000040114a <-358>: movswl 0x250f(%rip),%edi #
> > 0x403660 <__gg__data_return_code>
> > 0x0000000000401151 <-351>: mov %dx,(%rax)
> > => 0x0000000000401154 <-348>: call 0x4010b0 <exit@plt>
> >
> > $edi is 0 here. It looks like the store to __gg__data_return_code via
> > the move to (%rax)
> > and the load from it got interchanged due to aliasing issues possibly.
> >
> > It works when compiling with -O2 -fno-strict-aliasing, so apparently
> > your override
> > which you said was present does not work. I can't find it, after all.
> >
> > You want to implement the LANG_HOOKS_POST_OPTIONS hook and
> > do
> >
> > flag_strict_aliasing = 0;
> >
> > therein.
>
> Oh, and the actual problem is of course
>
> *(unsigned short *) (__gg___11_return_code6.data + (unsigned long)
> ((sizetype) D.260 * 1)) = D.259;
> ..pssr_retval = (signed int) __gg__data_return_code;
>
> where __gg__data_return_code is a global variable but
> __gg___11_return_code6 is something
> weird of type cblc_field_type_node and I nowhere see the .data field
> of it stored to (but it maybe is,
> via pointer arithmetic again - who knows - it's not mentioned anywhere
> else in the .original dump,
> so it's likely coming from libgcobol? So is __gg__data_return_code it
> seems.
>
> OK, so you are storing a short but reading from a unsigned char
> declaration. Since the
> declaration __gg__data_return_code is just 1 byte the 2-byte store
> cannot possibly alias it.
>
> Richard.
>
> > Richard.
> >
> > >
> > > > -----Original Message-----
> > > > From: Richard Biener <richard.guent...@gmail.com>
> > > > Sent: Friday, April 4, 2025 03:02
> > > > To: Robert Dubner <rdub...@symas.com>
> > > > Cc: GCC Mailing List <gcc@gcc.gnu.org>
> > > > Subject: Re: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT),
> is
> > > > optimized away.
> > > >
> > > > On Fri, Apr 4, 2025 at 12:17 AM Robert Dubner <rdub...@symas.com>
> wrote:
> > > > >
> > > > > The COBOL compiler has this routine:
> > > > >
> > > > > void
> > > > > gg_exit(tree exit_code)
> > > > > {
> > > > > tree the_call =
> > > > > build_call_expr_loc(location_from_lineno(),
> > > > > builtin_decl_explicit (BUILT_IN_EXIT),
> > > > > 1,
> > > > > exit_code);
> > > > > gg_append_statement(the_call);
> > > > > }
> > > > >
> > > > > I have found that when GCOBOL is used with -O2, -O3, or -Os, the
> call to
> > > > > gg_exit() is optimized away, and the intended exit value is lost,
> and I
> > > > > end up with zero.
> > > > >
> > > > > By changing the routine to
> > > > >
> > > > > void
> > > > > gg_exit(tree exit_code)
> > > > > {
> > > > > tree args[1] = {exit_code};
> > > > > tree function = gg_get_function_address(INT, "exit");
> > > > > tree the_call = build_call_array_loc (location_from_lineno(),
> > > > > VOID,
> > > > > function,
> > > > > 1,
> > > > > args);
> > > > > gg_append_statement(the_call);
> > > > > }
> > > > >
> > > > > the call is not optimized away, and the generated executable
> behaves as
> > > > > expected.
> > > > >
> > > > > How do I prevent the call to gg_exit() from being optimized away?
> > > >
> > > > I don't see anything wrong here, so the issue must be elsewhere.
> > > > Do you have a COBOL testcase that shows the exit() being optimized?
> > > >
> > > > >
> > > > > Thanks!
> > > > >
