COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is optimized away.

[Richard Biener]

On Fri, Apr 4, 2025 at 3:35 PM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Fri, Apr 4, 2025 at 3:06 PM Robert Dubner <rdubner@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.guenther@gmail.com>
> > > Sent: Friday, April 4, 2025 03:02
> > > To: Robert Dubner <rdubner@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 <rdubner@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!
> > > >