A runtime error occurs when assigning a variable of `bitset_large`

[degawa]

A runtime error occurs when assigning a variable of `bitset_large`

[degawa]

Thank you, @PierUgit, for comment on argument aliasing. I asked for help in Fortran Discourse because the issue was beyond my knowledge and may provide important insights for other Fortran users.

[jvdp1]

Thank you.
I can reproduce the error on my Linux machine.
I will open a PR to replicate this issue and to test different compiler versions.

The error may be due to the deallocation of the component blocks of set2 caused by the intent(out) attribute for set1 >since set1 and set2 are the same variable.

It seems to be indeed the case.

Intel ifort compilers do not seem to have this issue (see #727 ). Therefore, is it a compiler issue or a code issue?

@milancurcic @awvwgk any idea?

Note: since the derived type bitset_large does not contain pointers, I would suggest to remove the user-defined assignment procedure in favor of the intrinsic assignment operation

[degawa]

Thank you for working on reproducing this issue on your Linux machine.

I don't know why the intel compiler does not reproduce the issue, but I suspect it is the compiler implementation.

The gfortran's behavior may be compiler-dependent, but the code does not seem to violate the Fortran standard, so I would like to fix the assignment procedure for bitset_large to solve the issue.

[PierUgit]

the code does not seem to violate the Fortran standard

I'm not sure... When assigning an object to itself, the routine assign_large is called with the same actual object in the two arguments. Argument aliasing is normally not authorized... unless there are some exceptions?

[FortranFan]

bitsetl(0) = bitsetl(0)

To make the program conform, my read is you can change the assignment to explicitly reference an expression on the right-hand side:

bitsetl(0) = ( bitsetl(0) )

And then file another report with GCC Bugzilla for that processor.

This might satisfy the principle of least change for stdlib while enhancing that one processor if the support request gets worked on promptly.

[degawa]

Thank you, @FortranFan, for the information from a different perspective from what we have been considering.

The modification you suggested would require changes in several places in the sorting procedures for fixing the issue occurring only with the bitset_large type. We will also need to investigate the impact of the changes on the already supported types.
As @jvdp1 and @PierUgit said, the bitset_large type has no pointer component, so removing the user-defined assignment operator for bitset_large type is the easiest way to fix the issue.

[jvdp1]

The modification you suggested would require changes in several places in the sorting procedures for fixing the issue occurring only with the bitset_large type. We will also need to investigate the impact of the changes on the already supported types.

As the sorting procedures are most likely used for sorting arrays of integers or reals, I am not in favour of such a solution, as it could impact the performances of these procedures. But it questions the versatility of the sorting procedures too.