https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
OK, so trying to understand if there is still an issue with trampolines ( as
noted before, AFAIU gfortran has been using trampolines for a very long time,
so one might expect to have seen fallout before ).
1. test conditions
- the test case gfortran-reproducer.f90 from comment #1
- Paul's patch from comment # 6 applied
- optimisations O0 and O1
2. platforms
- x86_64-darwin, x86_64-linux
3. output checked
- `-fdump-tree-optimized`
- checked that the built program runs without producing any error or output.
4. observations (on x86_64-linux, so folks can reproduce on the compile farm
etc)
- as Richi expected, when the optimisation level is >= O1 actually the whole
test is optimised away and we just get:
__attribute__((externally_visible))
integer(kind=4) main (integer(kind=4) argc, character(kind=1) * * argv)
{
static integer(kind=4) options.0[7] = {10308, 16383, 0, 1, 1, 0, 31};
<bb 2> [local count: 1073741824]:
_gfortran_set_args (argc_2(D), argv_3(D));
_gfortran_set_options (7, &options.0[0]);
return 0;
}
- however, for O0 we get a MAIN__ function which contains:
<bb 2> :
FRAME.3.FRAME_BASE.PARENT = 0B;
__builtin_init_trampoline (&FRAME.3.test, test, &FRAME.3);
_5 = __builtin_adjust_trampoline (&FRAME.3.test);
_6 = (logical(kind=4) (*<T6a3>) (void)) _5;
test.1_1 = _6;
test.2 = test.1_1;
test_description = new_test_description (&test.2);
test_description ={v} {CLOBBER(eos)};
return;
.. so is, indeed, using a trampoline to call via a pointer.
==========
However on both Linux and Darwin that I tested on, this works exactly as
expected (the stack is made executable by the trampoline machinery) and the
test case executes fine.
Please could folks who saw an issue;
1. repeat the tests with the same conditions as above
2. report their platform results
