Comments (17)
The updates have now been pushed to master. I am also working toward getting GHDL running in the OSVVM scripting environment so I can run the full regression suite on it.
from osvvm.
AFAIK this error was found some days ago by another user, which reported in the Gitter chat: https://gitter.im/OSVVM/Lobby?at=5f5f0795df4af236f9070b10
A possible current solution is to use the Dev branch of OSVVM which includes a fix / workaround: https://github.com/OSVVM/OSVVM/commits/Dev
from osvvm.
I see. Just wanted to notify about this issue. Closing it, as already aware of.
from osvvm.
VHDL-2008 made code of this sort legal. If someone would like to make a bug report against GHDL, that would be appreciated
from osvvm.
from osvvm.
The call does not meet the call profile of the inner procedure since it has only one parameter.
OTOH, the call does meet the call profile of the outer procedure since the parameters are
initialized.
from osvvm.
from osvvm.
Their profiles do not lexicographically conform. So how can it hide it? It would only hide the calls that match its exact profile - calling with all parameters. If called with less, it should call the outer one. Right?
With respect to importance, this one is low as there is a simple work around. However, I have numerous ones wrt records with unconstrained arrays, ports, using subtype with such ports, ... that are much more important to me. I have not been able to submit a bug report as I am not good enough at GHDL yet. Also all my build scripts are currently TCL based - which is ok if you have an environment that allows you to run tclsh.
from osvvm.
from osvvm.
There seem to be some inconsistencies in this area.
The rules of visibility in12.3 seems to say it is hidden since the formal parameters have the same parameter profile.
A declaration is said to be hidden within (part of) an inner declarative region if the inner region contains a
homograph of this declaration; the outer declaration is then hidden within the immediate scope of the inner
homograph. Each of two declarations is said to be a homograph of the other if and only if both declarations
have the same designator, and they denote different named entities, and either overloading is allowed for at
most one of the two, or overloading is allowed for both declarations and they have the same parameter and
result type profile (see 4.5.1).
However, 4.5.1 the rule for ambiguity, it is clear that to call is unambiguous:
A call to an overloaded subprogram is ambiguous (and therefore is an error) if the name of the subprogram,
the number of parameter associations, the types and order of the actual parameters, the names of the formal
parameters (if named associations are used), and the result type (for functions) are not sufficient to identify
exactly one (overloaded) subprogram.
I think that rules of 12.3 are erroneous and should account for initialized parameters and needs to be updated. If 12.3 accounted for this, then the call would be unambiguous. Mentor and Aldec seem to agree with my interpretation.
from osvvm.
I have submitted issue: https://gitlab.com/IEEE-P1076/VHDL-Issues/-/issues/20 against the LRM in this area.
Any reason that we should not make the code legal?
from osvvm.
from osvvm.
from osvvm.
Why change the LRM? Does the current solution provide any safety benefit? If no, then does the current solution make these type of situations easier or harder for a programmer?
This sort of hiding is inconsistent with the way ambiguity is determined and eliminates more than required to make subprogram calls unambiguous in the context. The only hiding that is required is a call to the subprogram with all parameters specified.
There is a reason to not have default values on an inner layer like this when a wrapper layer, like the one in AlertLogPkg is created. If the job of the outer layer is to fill in the parameters and then call the inner layer, if the inner layer has defaults and as you are writing the outer layer, one forgets to map the defaults, it takes some time and simulation effort to find - first hand experience. So I removed the defaults from the inner layer.
from osvvm.
from osvvm.
Currently I have tested on 2 of the 4 commercial vendors and neither take issue with the code, only GHDL. Hopefully later this year I will be able to do testing with the other two.
from osvvm.
Obviously any change to the LRM makes it different than the previous versions. The current metric when changing the LRM is try to not break old code - if you break old code, it better be a really important feature (which obviously this is not).
from osvvm.
Related Issues (20)
- Alerts - Option to print entire path to alert name. HOT 6
- AlertLogPkg: ReportAlerts ignores ReportAll HOT 3
- Intelligent Coverage - Protected type restricted to use in different files HOT 8
- AlertLogPkg: Enabling and Disabling Passed/Affirmations Checked HOT 1
- Inconsistent line termination. HOT 4
- ScoreboardPkg is missing in OsvvmContext HOT 3
- Race conditions / buffer issues in console output HOT 4
- Missing wait for 0 ns in else-branch in WaitForLevel procedure HOT 2
- NewID Procedure with signal parameter and wait for 0 ns HOT 1
- NewID Procedure with signal parameter and wait for 0 ns
- Make the AlertLogName column width of log-output configurable HOT 2
- Traceability between expected errors/skipped tests and issue tracking software HOT 2
- CoveragePkg: AddCross with IgnoreBin Error HOT 5
- Common Log Interface HOT 6
- AlertLogPkg: AffirmIf with std_match (as implemented in the ScoreBoardPkg) HOT 3
- Add possibility to use falling clock edge as the active one. HOT 2
- RandInt : Provide simple overload or set defaults of min/max version to integer'low integer'high
- IDs - add _UNINITIALISED constant and add is_initialised functions for IDs
- ScoreboardGenericPkg: Make generic "match" function impure
- Provide a WARNING (user settable via options to ERROR) if any randomisation is attempted without first providing a seed HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from osvvm.