This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
an indirect call through an access-to-protected-subprogram value is always considered an external call. This patch makes that happen (previously, the compiler was using internal calls in some cases). The following test should run to completion, silently. (Before the bug fix, it would hang, because the call "V_Acc.all;" was not reevaluating the barriers, so the call "PO.P;" would never proceed.) package External_Indirect_Calls is protected PO is procedure Init; entry P; procedure V; private B : Boolean := True; end PO; V_Acc : access protected procedure; end External_Indirect_Calls; package body External_Indirect_Calls is protected body PO is procedure Init is begin V_Acc := V'Access; end Init; entry P when not B is begin B := True; end P; procedure V is begin B := False; end V; end PO; end External_Indirect_Calls; procedure External_Indirect_Calls.Main is task T; task body T is begin PO.P; end T; begin PO.Init; delay 0.001; V_Acc.all; end External_Indirect_Calls.Main; Tested on x86_64-pc-linux-gnu, committed on trunk 2015-02-20 Bob Duff <duff@adacore.com> * exp_attr.adb (May_Be_External_Call): Remove this. There is no need for the compiler to guess whether the call is internal or external -- it is always external. (Expand_Access_To_Protected_Op): For P'Access, where P is a protected subprogram, always create a pointer to the External_Subprogram.
Attachment:
difs
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |