fix argument mismatch error in gcc10 #1
Conversation
|
A simpler fix would be to call with TOLDEF instead with RCOND, because the call in line 514 is merely for computing the necessary workspace, so the value of TOL plays no role in this call. |
|
Yes I tried that. Somehow the compiler then complains with a mismatch between REAL(8) and REAL(4) for later use of TOLDEF. So I opted to create a new variable RCOND. |
|
All variables are DOUBLE PRECISION, so I cannot understand what is the issue. In the call in line 514 TOL should be simply a dummy double precion variable to be transfered by reference and not changed during the call. |
|
That's what I would think, too. Yet here is the compiler error: |
|
The new gcc probably expects And the parent discussion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 |
|
Just looked around a bit more and it seems like almost every major project with Fortran parts hit by this. From the gcc10 release notes
As can be seen from the third item, indeed the only options we have are either adding the flag or fixing all mismatched types |
|
Are you sure the mismatch is due to TOLDEF, because this seams to be a nonsese: in all calls the same argument is passed. |
If it is not, then the error message from gfortran is wrong. There is an assignment to TOLDEF in between. But even when I move the This is the only compiler error of this kind in SLICOT. All other routines compile fine. (There is python-control/Slycot#111, and newer LAPACK implementations have removed DLATZM, ZLATZM, DGEGS. See the branch slicot-changes.) |
|
Vasile Sima corrected the basic issue regarding the elimination of the call with an array instead of a variable. We decided for this solution, to remain independent of any particular compiler. I hope you will manage to compile this routine using suitable options. Many thanks for sharing this aspect with us. I am closing this PR, because the correction has been already performed. |
|
Indeed, I can now build the SLICOT part of Slycot with the fix in 7b96b64. I also found out, why my attempt to replace TOL with TOLDEF in #1 (comment) did not succeed: I did essentially the same as in 7b96b64 except that the changed line exceeds the FORTRAN77 line length limit. That seems to trigger the gfortran error message. I have to admit, in a very obsure way. I guess I am too young for this. 😉 Thank you for correcting it! And many thanks for providing this library to the community! |
|
It was a refreshing experience for me. Last time I wrote Fortran programs
was about 10 years ago (some mex interfaces to MATLAB based on SLICOT).
I was curious to learn a little bit about your SLYCOT project. Very
interesting indeed. Especially, I like the CI feature on so many machines.
This led me to an idea, which I would like to share with you.
We decided a few months ago to make SLICOT free (I pushed very strongly
this decison) and finally we agreed upon to make it free and use Github as
platform for the SLICOT repository.We uploaded the main sources for
routines, test programs and data, so, in principle, the library can be
used. However, just to perform the provided minimalistic tests,there is a
long way and requires to bind LAPACK and BLAS. As I was able to understand,
you automated this process for the purpose of integrating SLICOT in SLYCOT
(or I am wrong?). We would like to benefit of your expertise in this area,
at least by advising us how to provide more support for potential users of
SLICOT. I list here two aspects which could be of potential interest:
1. It would be great if we could provide a testing facility for SLICOT for
the purpose of CI. Such facility exists also for LAPACK, but we lack
experience in this area.
2. I see one of the main usages for SLICOT as a computational kernel for
control related computations in conjunction with environments like Matlab,
Python, Julia, Octave. Bulding interfaces to these tools (wrappers,
mex-files, etc.) involves (probably) the generation of appropriate shared
libraries for different architectures and compilers. It would be usefull
for many potential users to have this process largely automated.
Some information of possible interest to you and your colleagues.
SLICOT is accompanied also by a collection of mex-functions to interface
with Matlab. Many served for testing purposes and some tools have unique
functionality, which is not present in any other control tools. For
example, we implemented for my recent book on fault detection, a collection
of mex-files to serve for the implementation of some advanced control
related computations based on descriptor systems. We are thinking to make
these interfaces freely available too (at least those implemented by me
will certainly be). And I intend to make some wrappers to Julia too. The
descriptor systems tools for Matlab are freely available (presently on
Bitbucket) and served for several graduate courses on model based fault
diagnosis (the next 21 hours online course starts on March 8, 2021; I know
this is an advertising, but possibly of interest since the main application
domain is fault diagnosis in flight control).
We would appreciate if you could advise us in addressing the above two
aspects. Any other help would be also very welcome.
We look forward to hear your opinion on these issues.
Andreas and Vasile
Am Mo., 8. Feb. 2021 um 21:18 Uhr schrieb Ben Greiner <
[email protected]>:
… Indeed, I can now build the SLICOT part of Slycot with the fix in 7b96b64
<7b96b64>
.
I also found out, why my attempt to replace TOL with TOLDEF in #1
(comment)
<#1 (comment)>
did not succeed: I did essentially the same as in 7b96b64
<7b96b64>
*except* that the changed line exceeds the FORTRAN77 line length limit.
That seems to trigger the gfortran error message. I have to admit, in a
very obsure way. I guess I am too young for this. 😉
Thank you for correcting it! And many thanks for providing this library to
the community!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALJDHECIHCD2JUBX72C2NPDS6BBHRANCNFSM4XH3ZYKQ>
.
|
|
Well I, for one, am very happy to see you moved to GitHub so welcome on board and also I am grateful that you changed to a more permissive license. I have been waiting for this for a long time and over the years we had many discussions around SLICOT here and there. I think @pmli would remember who actually broke the news for me. Not to mention that I've been reading your articles and other materials for a very long time too. I am not involved with the Slycot project mostly because it was GPL-licensed but interested in control libraries in Python in general. I have witnessed the same evolution with LAPACK devs too who were also a bit outside the GitHub workflows. But now an active community surrounds the codebase. I am positive that the same will happen as it becomes more visible. I and surely many others would be willing to help setting up basic machinery if you could guide us with how the tests are structured or even if they exist in the first place.
Just to give a very basic introduction to the CI tools. Currently a few major vendors provide free CI/CD tools to open source codebases. GitHub itself, Azure Pipelines, CircleCI and AppVeyor are the most common ones. TravisCI was the most prominent player but lately they removed their free support so in case you saw their name that's why. The main workflow is the Issue reports and Pull Requests and this is the annoying part that any change to be made should better be first committed as a pull request. The reason for this is that CI tools and GitHub are integrated each other hence when a new pull request is opened, CI tools receives a webhook signal and starts incorporating the changes to the build and run all the existing tests. This is very helpful to catch the initial tirivial problems should there be any and to see any existing behavior is broken. Once every test passes the CI check then codebase owners, in this case you both, can decide whether a piece of code should go in or not and click the merge button. Obviously, the more tests there are the better it is. Hence all kinds of trivial input tests wrong strings, wrong options, wrong calls etc. can be tested and get out of the way. Another advantage of these CI tools is the possibility of running builds against different machine architectures Linux, Win, OSX are very typical choices and some other esoteric options such as ARM and Raspbian etc. are also available.
Yes indeed one of the nice byproducts of these CI/CD tools is that you can save the so-called artifacts, the resulting files after the build and use them as releasing a new version. This is a bit trickier so I'll skip the details for now. |
|
This is great. I opened a new Github issue [#2] for further discussion, so that it is more visible. Closed PRs are not easily found behind the "closed" link on the PR page. |
|
I thank you very much for these ample explanations. One aspect you mentioned is the constraint to use CI/CD triggered by commit and PR. I am using myself CI in my Julia projects based on Github actions, where the triggering of tests occurs at every push action, avoiding thus PRs. Could you imagine this to be feasible also for maintaining/developing the SLICOT repository? |
|
That is in fact the first immediate thing we all thought about. However when there are conflicting changes in different git branches it becomes very difficult to arrange what goes in first or how the commit history would look like in case you would be searching for a change that broke something 6 months ago. Not to mention the typical "Oh I forgot to include such and such" commits too. It does feel like extra work and I think we all agree but the pitfalls it prevents justify the use of PRs greatly in my opinion. However this is just a suggestion and not really a rule. So if you feel like SLICOT doesn't need then so be it. After all, you would be the deciding body. |
|
Thanks for your comments. I would like to express some personal opinions
regarding the future of SLICOT. We expect no significant development
activities before us. However, we will try to correct all errors.
Therefore, we would prefer using "issues" instead PRs, and all
modifications of source code will be only performed by a single person,
i.e. by Vasile Sima. Of course, we will wellcome any PR, if this will save
maintainance efforts, but we are convinced that the other way is also
viable.
Ilhan Polat <[email protected]> schrieb am Mi., 10. Feb. 2021, 19:56:
… That is in fact the first immediate thing we all thought about. However
when there are conflicting changes in different git branches it becomes
very difficult to arrange what goes in first or how the commit history
would look like in case you would be searching for a change that broke
something 6 months ago. Not to mention the typical "Oh I forgot to include
such and such" commits too.
It does feel like extra work and I think we all agree but the pitfalls it
prevents justify the use of PRs greatly in my opinion. However this is just
a suggestion and not really a rule. So if you feel like SLICOT doesn't need
then so be it. After all, you would be the deciding body.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALJDHEFOYYEAETVV3V3AUOTS6LJGHANCNFSM4XH3ZYKQ>
.
|
|
Understood. Thank you for the clarification |
Hello,
over at Slycot we have been maintaining a fork of the SLICOT 5.0 GPL sources. Over time, we implemented some small fixes to build SLICOT with updated versions of gcc and the various BLAS/LAPACK implementations.
The individual fixes would have to be submitted to this BSD licensed repository by the respective authors, because Slycot is currently stuck on GPL, but I can start with my own contribution:
gfortran10 started to throw errors because of a rank mismatch when calling MB03OD (see also https://gcc.gnu.org/gcc-10/porting_to.html):
This PR fixes the issue.