The following program is an extension to the one in PR 41539. It finally requires to many features that ifort 11.1 does not like it - nor the dated NAG f95 5.1 (current is 5.2). And while gfortran should have everything needed, it still does not work.
I have no idea whether the code is correct - probably not - but an ICE is definitely wrong. (For other issues see PR 41539.)
$ gfortran sort.f90
f951: internal compiler error: in gfc_match_varspec, at fortran/primary.c:1815
Please submit a full bug report

STATUS:
With the commit for PR 41539, there is no longer an ICE.
However, while the example of comment 2 (attachment 18978[details]) compiles, it fails to link with: undefined reference to `assign_'
Given that NAG 5.2 compiles it and as "assign" is only called via "assignment(=)", there must be some issue with the assignment resolution.

(In reply to comment #6)
> However, while the example of comment 2 (attachment 18978[details]) compiles,
> it fails to link with: undefined reference to `assign_'
The problem is in "subroutine bsort(a,tmp)": The line
tmp = a(i)
should call tmp->_vtr->assign. However, it calls a simple external "assign" procedure. If one uses:
call tmp%assign(a(i))
one finds the correct dump, namely:
tmp->_vptr->assign ((struct __class_m_sort_Sort_t *) tmp, &class.2);
The "assign" is found when resolve_ordinary_assign calls gfc_extend_assign, which runs:
3452 sym = gfc_search_interface (ns->op[INTRINSIC_ASSIGN], 1, &actual);
That returns the INTERFACE instead of the type bound procedure:
(gdb) p sym->name
$9 = 0x2aaaacde8fd0 "assign"
(gdb) p sym->attr.external
$11 = 1
If one changes the interface to an abstract one, one gets
ERROR: ABSTRACT INTERFACE 'assign' must not be referenced
Using "assign" instead of the type-bound "assign" is definitely a bug as no "INTERFACE ASSIGNMENT(=)" exists - there is only the type-based "generic :: assignment(=) => assign".

(In reply to comment #6)
> Given that NAG 5.2 compiles it and as "assign" is only called via
> "assignment(=)", there must be some issue with the assignment resolution.
Actually, I wonder whether the code is valid. One has:
type, abstract :: sort_t
contains
generic :: assignment(=) => assign
...
interface assignment(=)
procedure assign
end interface
Thus, one defines twice a generic name with the same (= identical) interface, once as TBP and once as external procedure. Thus, when one encounters:
tmp = a(i)
the compiler has the choice between "assign_" and "tmp->_vtab->assign".
I failed to nail it in the standard, but I am sure that "12.4.3.4.5 Restrictions on generic declarations" somehow must apply.

(In reply to comment #11)
> Here is a reduced version of comment 2, which is invalid according to comment
> 10:
Here is a non-abstract version of the test case in comment #11, which should be equally invalid (however, in this case it is not a problem of having two ambiguous procedures, but adding the same procedure twice to the same generic assignment operator):
module m_sort
implicit none
type :: sort_t
contains
generic :: assignment(=) => assign
procedure :: assign
end type
interface assignment(=)
module procedure :: assign
end interface
contains
subroutine assign (lhs, rhs)
class(sort_t), intent(out) :: lhs
class(sort_t), intent(in) :: rhs
end subroutine
end module

(In reply to comment #14)
> Comment 12 is fixed with r189022, but comment 11 is still accepted without
> error.
Note that previous commit also excluded PRIVATE type-bound operators, cf. http://gcc.gnu.org/ml/fortran/2012-06/msg00149.html.
Whatever a private type-bound operators/assignments are, given that they automatically become available when use-associating the type. (As they have to have a pass argument, they won't interfere with other operator declarations.)

(In reply to comment #16)
> One way to reject the abstract case in comment 11, would be to just do the
> checking, but not add the procedure to the operator list:
The only problem with the patch in comment 16 is that the error message it gives on comment 11 ...
generic :: assignment(=) => assign
1
Error: Entity 'assign_it' at (1) is already present in the interface
... is technically not correct. 'assign_it' is not added twice, but in one case is just the interface of the deferred type-boud procedure 'assign'. Instead, it might be better to complain about 'Ambiguous interfaces' (since any non-abstract extension of the type 'sort_t' will have to override/implement the type-bound 'assign' with a procedure which is ambiguous to 'assign_it').
However, such an error about 'Ambiguous interfaces' is also missing for the following case (which is still accepted):
module m_sort
implicit none
type, abstract :: sort_t
contains
generic :: assignment(=) => assign
procedure(assign_ifc), deferred :: assign
end type
abstract interface
subroutine assign_ifc (lhs, rhs)
import
class(sort_t), intent(out) :: lhs
class(sort_t), intent(in) :: rhs
end subroutine
end interface
interface assignment(=)
subroutine assign_it (lhs, rhs)
import
class(sort_t), intent(out) :: lhs
class(sort_t), intent(in) :: rhs
end subroutine
end interface
end module