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!
> > > >
