bugGNU Octave - Bugs: bug #51961, integer argument size conflict in...

 
 

bug #51961: integer argument size conflict in ranlib when building with 64-bit Fortran support

Submitter:  Mike Miller <mtmiller>
Submitted:  Thu 07 Sep 2017 10:42:13 PM UTC
   
 
Category:  Libraries Severity:  4 - Important
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 09 Mar 2018 06:50:43 PM UTC, comment #7: 

I pushed the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/32671b14ed7b

In the end, I decided to go with declaring all integers in the ranlib functions to be INTEGER*4 since that's what we intended to happen with our compiler flag settings and because I'm not sure that the functions work properly if some internal values are 8 byte integers.

Closing as fixed.

John W. Eaton <jwe>
Group administrator
Thu 08 Mar 2018 10:03:23 PM UTC, comment #6: 

It seems best to me to use INTEGER*4 where needed in these functions.

John W. Eaton <jwe>
Group administrator
Mon 13 Nov 2017 09:56:26 PM UTC, comment #5: 

It's your bug (both submitted and solved).  If you feel okay closing it then go ahead and do so.

I'm always trying to prune the bug list so what remains are actual issues worth resolving.

Rik <rik5>
Group administrator
Mon 13 Nov 2017 08:00:24 PM UTC, comment #4: 

I don't remember now if the simple patch I posted here was enough for the test suite to run or if there were other problems at run time.

Mike Miller <mtmiller>
Group Member
Mon 13 Nov 2017 07:53:35 PM UTC, comment #3: 

I would be ok with closing this as won't fix for now.

The problem arises when the default FFLAGS is set to include "-fdefault-integer-8", so all Fortran is compiled with 64-bit INTEGERs. Or if one happens to have a Fortran compiler that works with 64-bit INTEGERs by default.

This problem does not occur when the default Fortran compilation environment builds 32-bit INTEGERs, but the F77_INTEGER_8_FLAG is set to "-fdefault-integer-8" (or other compiler-specific option) and only used to compile the Fortran files that have to do with BLAS and other external libraries.

All Fortran files under liboctave/external/ranlib must continue to be built with 32-bit INTEGERs always, while all other Fortran files under liboctave/external and liboctave/util must be built with the same INTEGER size that was used in the BLAS and other external numerical libraries.

Mike Miller <mtmiller>
Group Member
Fri 10 Nov 2017 05:52:37 AM UTC, comment #2: 

@Mike: Did you resolve this?  Your Fortran patch seems quite simple and jwe gave the go ahead to use the INTEGER*N syntax as necessary.

Rik <rik5>
Group administrator
Sat 09 Sep 2017 12:27:50 AM UTC, comment #1: 

I don't think the INTEGER*N syntax is part of any standard, but it has been a very common extension for more than 30 years.  I can't imagine a compiler that would not support it.

John W. Eaton <jwe>
Group administrator
Thu 07 Sep 2017 10:42:13 PM UTC, original submission:  

When building with 64-bit Fortran indexing, there is a conflict between some of the function arguments in liboctave/external/ranlib and the calling prototypes declared in C.

In C:


F77_RET_T F77_FUNC (getsd, GETSD) (F77_INT4&, F77_INT4&);
F77_RET_T F77_FUNC (setall, SETALL) (const F77_INT4&, const F77_INT4&);
F77_RET_T F77_FUNC (setcgn, SETCGN) (const F77_INT4&);
F77_RET_T F77_FUNC (setsd, SETSD) (const F77_INT4&, const F77_INT4&);


But in Fortran the arguments are declared as plain INTEGER types.

I've worked around this with the following patch


diff --git a/liboctave/external/ranlib/getcgn.f b/liboctave/external/ranlib/getcgn.f
--- a/liboctave/external/ranlib/getcgn.f
+++ b/liboctave/external/ranlib/getcgn.f
@@ -1,5 +1,5 @@
       SUBROUTINE getcgn(g)
-      INTEGER g
+      INTEGER*4 g
 C**********************************************************************
 C
 C      SUBROUTINE GETCGN(G)
diff --git a/liboctave/external/ranlib/getsd.f b/liboctave/external/ranlib/getsd.f
--- a/liboctave/external/ranlib/getsd.f
+++ b/liboctave/external/ranlib/getsd.f
@@ -30,7 +30,7 @@ C     .. Parameters ..
       PARAMETER (numg=32)
 C     ..
 C     .. Scalar Arguments ..
-      INTEGER iseed1,iseed2
+      INTEGER*4 iseed1,iseed2
 C     ..
 C     .. Scalars in Common ..
       INTEGER a1,a1vw,a1w,a2,a2vw,a2w,m1,m2
diff --git a/liboctave/external/ranlib/setall.f b/liboctave/external/ranlib/setall.f
--- a/liboctave/external/ranlib/setall.f
+++ b/liboctave/external/ranlib/setall.f
@@ -31,7 +31,7 @@ C     .. Parameters ..
       PARAMETER (numg=32)
 C     ..
 C     .. Scalar Arguments ..
-      INTEGER iseed1,iseed2
+      INTEGER*4 iseed1,iseed2
       LOGICAL qssd
 C     ..
 C     .. Scalars in Common ..
diff --git a/liboctave/external/ranlib/setsd.f b/liboctave/external/ranlib/setsd.f
--- a/liboctave/external/ranlib/setsd.f
+++ b/liboctave/external/ranlib/setsd.f
@@ -30,7 +30,7 @@ C     .. Parameters ..
       PARAMETER (numg=32)
 C     ..
 C     .. Scalar Arguments ..
-      INTEGER iseed1,iseed2
+      INTEGER*4 iseed1,iseed2
 C     ..
 C     .. Scalars in Common ..
       INTEGER a1,a1vw,a1w,a2,a2vw,a2w,m1,m2


I don't remember how portable the INTEGER*N syntax is, I don't know if we want to keep these source files pristine, or if there's a cleaner solution, like overriding the FFLAGS for just the libranlib source files.

Mike Miller <mtmiller>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-09 jwe StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2017-11-10 rik5 StatusNone Patch Submitted

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code