Ambiguous subprogram call ReportAlerts in AlertLogPkg.vhd OSVVM 2015.03.

[Olof Kraigher]

Trying to use OSVVM 2015.03 with GHDL there is a problem in AlertLogPkg.vhd:

Compiling /home/kraigher/repo/vunit/vhdl/osvvm/AlertLogPkg.vhd …

/home/kraigher/repo/vunit/vhdl/osvvm/AlertLogPkg.vhd:493:11: can’t resolve overload for procedure call

/home/kraigher/repo/vunit/vhdl/osvvm/AlertLogPkg.vhd:493:11: possible interpretations are:

/home/kraigher/repo/vunit/vhdl/osvvm/AlertLogPkg.vhd:284:15: procedure reportalerts [string, alertlogidtype, alertcounttype, boolean]

/home/kraigher/repo/vunit/vhdl/osvvm/AlertLogPkg.vhd:163:13: procedure reportalerts [string, alertlogidtype, alertcounttype]

ghdl: compilation error

The problem is that ReportAlerts is called with zero arguments but there are two overloaded versions of it that have default values for all of their arguments; one regular procedure and one procedure within the protected type. It seems this is a truly ambiguous case unless the LRM specifies some rule that gives either subprogram precedence then it is a GHDL bug. Still it might be good to be conservative with this coding style to work with more simulators. Modelsim gives no errors though I have not verified which subprogram it selected.

[Olof Kraigher]

Changing 493 to the following is enough to resolve the ambiguity: 

ReportAlerts(ReportAll => TRUE);

[Jim Lewis]

Hi Olof,
It appears that GHDL is getting confused trying to differentiate the procedure call in the outer package and the procedure call inside the protected type.  The call is from inside the protected type.  I think it should always resolved to calling the local function, but will have to check. 

Outside of the protected type, there are no issues as the procedure defined within the protected type is never directly visible (and hidden here because it is declared in the package body).

What version of GHDL are you using?  Are you on the most current release? This should have been caught when they ran the demo programs that are part of 2015.01 (these parts of 2015.01 and 2015.03 are identical). 
Best Regards,
Jim

[Olof Kraigher]

Jim: I am using the latest development branch of GHDL which I have built from source and OSVVM 2015.03. 

Like you say there is no problem outside of the protected type since the procedure is not visible to the outside as a stand-alone name without prefixing a protected type instance. The only problem is with line 493 which can be easily fixed with:

ReportAlerts(ReportAll => TRUE);

[Jim Lewis]

Hi Olof,

A more appropriate work around for GHDL is to change the offending call to:

AlertLogStructPType.ReportAlerts ;

Can you make this change and test it against your current version of GHDL?   If you verify that this works in GHDL, I will make the update permanent in the next revision.  I have already run regressions with it on the other tools I test with.

Thanks,

Jim

P.S.  I can send you a beta of 2015.05/2015.06 (not sure when it will be finalized) if you send me an email directly to jim at synthworks.com

[Olof Kraigher]

I changed the offending call as you specified. Unfortunately it produced an error:

/home/kraigher/repo/vunit/vhdl/osvvm/AlertLogPkg.vhd:493:11: type “alertlogstructptype” cannot be selected by name

ghdl: compilation error

If you know the LRM supports this syntax then maybe this is a valid bug report for GHDL.

They are generally quite responsive so if you file a ticket it might be fixed before their next official release. I can help you file a ticket if you like. 

I would be happy to test your beta releases of OSVMM and will send you an email.

[Author]

Posts