Andre Vehreschild <ve...@gmx.de> writes:

> Hi all,
>
> please note, that I don't know this bisecting very well, so this may very well
> be a wrong blame. During latest regression testing of the Fortran suite I got
> typebound_operator_7.f03 failing with:
>
> typebound_operator_7.f03:94:25:
>
>    94 |   u = (u*2.0*4.0) + u*4.0
>       |                         1
> internal compiler error: tree check: expected function_decl, have indirect_ref
>    in DECL_FUNCTION_CODE, at tree.h:4329 0x3642f3e internal_error(char const*,
>    ...) /mnt/work_store/gcc/gcc.test/gcc/diagnostic-global-context.cc:517
> 0x1c0a703 tree_check_failed(tree_node const*, char const*, int, char const*,
>    ...) /mnt/work_store/gcc/gcc.test/gcc/tree.cc:9003
> 0xeb9150 tree_check(tree_node const*, char const*, int, char const*, 
> tree_code)
>       /mnt/work_store/gcc/gcc.test/gcc/tree.h:3921
> 0xf5725b DECL_FUNCTION_CODE(tree_node const*)
>       /mnt/work_store/gcc/gcc.test/gcc/tree.h:4329
> 0xf383d6 update_builtin_function
>       /mnt/work_store/gcc/gcc.test/gcc/fortran/trans-expr.cc:4405
> 0xf468b9 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
>    gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
>    /mnt/work_store/gcc/gcc.test/gcc/fortran/trans-expr.cc:8236 0xf48b0f
>    gfc_conv_function_expr
>    /mnt/work_store/gcc/gcc.test/gcc/fortran/trans-expr.cc:8815 0xf4ceda
>    gfc_conv_expr(gfc_se*, gfc_expr*)
>    /mnt/work_store/gcc/gcc.test/gcc/fortran/trans-expr.cc:9982 0xf40777
>    gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
>    gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
>    /mnt/work_store/gcc/gcc.test/gcc/fortran/trans-expr.cc:6816 0xf48b0f
>    gfc_conv_function_expr
>    /mnt/work_store/gcc/gcc.test/gcc/fortran/trans-expr.cc:8815 0xf4ceda
>    gfc_conv_expr(gfc_se*, gfc_expr*)
>    /mnt/work_store/gcc/gcc.test/gcc/fortran/trans-expr.cc:9982 0xf40777
>    gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
>    gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
>    /mnt/work_store/gcc/gcc.test/gcc/fortran/trans-expr.cc:6816 0xfb580a
>    gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
>    /mnt/work_store/gcc/gcc.test/gcc/fortran/trans-stmt.cc:425 0xed9363
>    trans_code /mnt/work_store/gcc/gcc.test/gcc/fortran/trans.cc:2434 0xed97d5
>    gfc_trans_code(gfc_code*)
>    /mnt/work_store/gcc/gcc.test/gcc/fortran/trans.cc:2713 0xf26342
>    gfc_generate_function_code(gfc_namespace*)
>    /mnt/work_store/gcc/gcc.test/gcc/fortran/trans-decl.cc:7958 0xed9819
>    gfc_generate_code(gfc_namespace*)
>    /mnt/work_store/gcc/gcc.test/gcc/fortran/trans.cc:2730 0xe544ee
>    translate_all_program_units
>    /mnt/work_store/gcc/gcc.test/gcc/fortran/parse.cc:7156 0xe54e23
>    gfc_parse_file() /mnt/work_store/gcc/gcc.test/gcc/fortran/parse.cc:7473
>    0xebf7ce gfc_be_parse_file
>    /mnt/work_store/gcc/gcc.test/gcc/fortran/f95-lang.cc:241
>
> Checking with git bisect this lead me to:
>
> d8ef4471cb9c9f86784b62424a215ea42173bfe1 being the last commit the test passed
>
> and
>
> 03623fa91ff36ecb9faa3b55f7842a39b759594e libstdc++: Use std::move for iterator
> in ranges::fill [PR117094]
>
> failing the test to pass. Can anyone confirm?
>
> I might be doing something wrong here, so please be patient and explain, what 
> I
> miss.

You can confirm this by reverting the commit to see if it starts to pass
again.

Also, if manually bisecting, it can be worth doing each commit twice if
unfamiliar with it (or use `git bisect run` instead).

Now, according to gcc-regression
(https://inbox.sourceware.org/gcc-regression/20241013105730.f2e0614a0...@shgcc06.sh.intel.com/T/#u),
it started between r15-4295 and r15-4298, although it didn't bisect (it
does sometimes but this isn't one of those emails):

$ git shortlog $(contrib/git-undescr.sh r15-4295)~1..$(contrib/git-undescr.sh 
r15-4298)
GCC Administrator (1):
      Daily bump.

Jivan Hakobyan (1):
      [RISC-V] Avoid unnecessary extensions when value is already extended

Thomas Koenig (1):
      Unsigned constants for ISO_FORTRAN_ENV and ISO_C_BINDING.

Tobias Burnus (1):
      Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' 
__builtin_is_initial_device

Those 2 Fortran candidates seem more likely, but not that I know
anything about Fortran.

>
> Regards,
>       Andre

thanks,
sam

Reply via email to