I just ran into a nasty problem with GFortran and G++ (C++). Probably
not a bug ??? I am using GCC 14.1.
I have a lot of code in C++ (over 100,000 lines). I have 750,000 lines
of code in GFortran. I have to extern "C" this code in C++ to make it callable by GFortran code.
I missed declaring a couple of C++ functions as extern "C" which means
that they kept their C++ mangled link names. But these C++ functions
were declared as integer*8 and external in the GFortran code (old F77
code).
So, the GCC linker did not report to me that it did not have a link for
the G++ functions. This may be a bug, I am not sure.
When I ran the program, the C++ functions were not called by the
GFortran code. Instead, the GFortran code treated the C++ functions as integer*8 scalar variables.
If needful, I can probably put together a small code sample that
exhibits the problem. Maybe. It could be that the size of my code
affects the GCC linker.
I just ran into a nasty problem with GFortran and G++ (C++). Probably
not a bug ??? I am using GCC 14.1.
I have a lot of code in C++ (over 100,000 lines). I have 750,000 lines
of code in GFortran. I have to extern "C" this code in C++ to make it callable by GFortran code.
I missed declaring a couple of C++ functions as extern "C" which means
that they kept their C++ mangled link names. But these C++ functions
were declared as integer*8 and external in the GFortran code (old F77
code).
So, the GCC linker did not report to me that it did not have a link for
the G++ functions. This may be a bug, I am not sure.
When I ran the program, the C++ functions were not called by the
GFortran code. Instead, the GFortran code treated the C++ functions as integer*8 scalar variables.
If needful, I can probably put together a small code sample that
exhibits the problem. Maybe. It could be that the size of my code
affects the GCC linker.
I removed the Gfortran code "external" keywords, extern "C" the C++ functions, added the C++ function to my module list, and got a working
link.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I just ran into a nasty problem with GFortran and G++ (C++). Probably
not a bug ??? I am using GCC 14.1.
I have a lot of code in C++ (over 100,000 lines). I have 750,000 lines
of code in GFortran. I have to extern "C" this code in C++ to make it
callable by GFortran code.
I missed declaring a couple of C++ functions as extern "C" which means
that they kept their C++ mangled link names. But these C++ functions
were declared as integer*8 and external in the GFortran code (old F77
code).
So, the GCC linker did not report to me that it did not have a link for
the G++ functions. This may be a bug, I am not sure.
Without having looked at the source code, I suspect
it is probably something that you are not describing.
You can look into the object files with any number of utilities,
for example "nm". Here's an example:
subroutine foo
external bar
integer *8 bar
print *,bar(1234)
end subroutine foo
Compiling to an object file and running nm on this will show you
U bar_
0000000000000000 T foo_
U _gfortran_st_write
U _gfortran_st_write_done
U _gfortran_transfer_integer_write
which means you have a symbol "foo_" defined, it is a global (hence uppercase) symbol in the text section (hence T). You also have
several undefined symbols, among them bar_, plus some gfortran
library routines, so all is fine.
If you do not find your undefined
When I ran the program, the C++ functions were not called by the
GFortran code. Instead, the GFortran code treated the C++ functions as
integer*8 scalar variables.
If needful, I can probably put together a small code sample that
exhibits the problem. Maybe. It could be that the size of my code
affects the GCC linker.
That I would consider highly unlikely.
On 1/7/2025 4:18 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I just ran into a nasty problem with GFortran and G++ (C++). Probably
not a bug ??? I am using GCC 14.1.
I have a lot of code in C++ (over 100,000 lines). I have 750,000 lines
of code in GFortran. I have to extern "C" this code in C++ to make it
callable by GFortran code.
I missed declaring a couple of C++ functions as extern "C" which means
that they kept their C++ mangled link names. But these C++ functions
were declared as integer*8 and external in the GFortran code (old F77
code).
So, the GCC linker did not report to me that it did not have a link for
the G++ functions. This may be a bug, I am not sure.
Without having looked at the source code, I suspect
it is probably something that you are not describing.
You can look into the object files with any number of utilities,
for example "nm". Here's an example:
subroutine foo
external bar
integer *8 bar
print *,bar(1234)
end subroutine foo
Compiling to an object file and running nm on this will show you
U bar_
0000000000000000 T foo_
U _gfortran_st_write
U _gfortran_st_write_done
U _gfortran_transfer_integer_write
which means you have a symbol "foo_" defined, it is a global (hence
uppercase) symbol in the text section (hence T). You also have
several undefined symbols, among them bar_, plus some gfortran
library routines, so all is fine.
If you do not find your undefined
When I ran the program, the C++ functions were not called by the
GFortran code. Instead, the GFortran code treated the C++ functions as
integer*8 scalar variables.
If needful, I can probably put together a small code sample that
exhibits the problem. Maybe. It could be that the size of my code
affects the GCC linker.
That I would consider highly unlikely.
I turn off the trailing underscores in the Fortran code. I build Win32
DLLs that are Excel VBA, C++, and Fortran callable.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 1/7/2025 4:18 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I just ran into a nasty problem with GFortran and G++ (C++). Probably >>>> not a bug ??? I am using GCC 14.1.
I have a lot of code in C++ (over 100,000 lines). I have 750,000 lines >>>> of code in GFortran. I have to extern "C" this code in C++ to make it >>>> callable by GFortran code.
I missed declaring a couple of C++ functions as extern "C" which means >>>> that they kept their C++ mangled link names. But these C++ functions
were declared as integer*8 and external in the GFortran code (old F77
code).
So, the GCC linker did not report to me that it did not have a link for >>>> the G++ functions. This may be a bug, I am not sure.
Without having looked at the source code, I suspect
it is probably something that you are not describing.
You can look into the object files with any number of utilities,
for example "nm". Here's an example:
subroutine foo
external bar
integer *8 bar
print *,bar(1234)
end subroutine foo
Compiling to an object file and running nm on this will show you
U bar_
0000000000000000 T foo_
U _gfortran_st_write
U _gfortran_st_write_done
U _gfortran_transfer_integer_write
which means you have a symbol "foo_" defined, it is a global (hence
uppercase) symbol in the text section (hence T). You also have
several undefined symbols, among them bar_, plus some gfortran
library routines, so all is fine.
If you do not find your undefined
When I ran the program, the C++ functions were not called by the
GFortran code. Instead, the GFortran code treated the C++ functions as >>>> integer*8 scalar variables.
If needful, I can probably put together a small code sample that
exhibits the problem. Maybe. It could be that the size of my code
affects the GCC linker.
That I would consider highly unlikely.
I turn off the trailing underscores in the Fortran code. I build Win32
DLLs that are Excel VBA, C++, and Fortran callable.
Just wondering... have you read the relevant gfortran documentation
regarding naming conventions and the attributes directive?
On 1/8/2025 3:37 AM, Thomas Koenig wrote:
Just wondering... have you read the relevant gfortran documentation
regarding naming conventions and the attributes directive?
About three times now. Still makes my head spin.
All of this F77 / C++ code was working with the Watcom F77 / C++ PCDOS / Win32 compilers for the last 32+ years and over 2,000 commercial users.
The port has been the worst port ever. But I blame that on the old
Fortran code dating back to 1965 (Fortran II !!!).
I have ported the
Fortran code to twelve different platforms over the years (mainframes, various Unix boxen, Vax VMS, Prime, PC DOS, Win32).
I was porting for the third attempt to the Intel Fortran / Visual C++ compilers and they obsoleted the Intel Fortran compiler on me about
three months ago.
I am not going to port to an obsolete compiler.
The
first two attempts in 2002 ? and 2010 ? to port to Intel Fortran ran
into compiler bugs (crashed the linker table at 300,000 entries, the
vector automatic zeroing code had a serious bug).
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I was porting for the third attempt to the Intel Fortran / Visual C++
compilers and they obsoleted the Intel Fortran compiler on me about
three months ago.
They obsoleted the non-LLVM version? I hadn't heard that.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I just ran into a nasty problem with GFortran and G++ (C++). Probably
not a bug ??? I am using GCC 14.1.
I have a lot of code in C++ (over 100,000 lines). I have 750,000 lines
of code in GFortran. I have to extern "C" this code in C++ to make it
callable by GFortran code.
I missed declaring a couple of C++ functions as extern "C" which means
that they kept their C++ mangled link names. But these C++ functions
were declared as integer*8 and external in the GFortran code (old F77
code).
So, the GCC linker did not report to me that it did not have a link for
the G++ functions. This may be a bug, I am not sure.
Without having looked at the source code, I suspect
it is probably something that you are not describing.
You can look into the object files with any number of utilities,
for example "nm". Here's an example:
subroutine foo
external bar
integer *8 bar
print *,bar(1234)
end subroutine foo
Compiling to an object file and running nm on this will show you
U bar_
0000000000000000 T foo_
U _gfortran_st_write
U _gfortran_st_write_done
U _gfortran_transfer_integer_write
which means you have a symbol "foo_" defined, it is a global (hence uppercase) symbol in the text section (hence T). You also have
several undefined symbols, among them bar_, plus some gfortran
library routines, so all is fine.
If you do not find your undefined
When I ran the program, the C++ functions were not called by the
GFortran code. Instead, the GFortran code treated the C++ functions as
integer*8 scalar variables.
If needful, I can probably put together a small code sample that
exhibits the problem. Maybe. It could be that the size of my code
affects the GCC linker.
That I would consider highly unlikely.
I cannot get a small code sample with or without a DLL to exhibit the problem. Like I said, I thought it was something related to size of my
DLL. And this is the small DLL, only 3 MB.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I cannot get a small code sample with or without a DLL to exhibit the
problem. Like I said, I thought it was something related to size of my
DLL. And this is the small DLL, only 3 MB.
Regarding DLLs, I'm out... I don't think I have ever done one.
Which toolchain are you using? Msys/mingw64 is probably the
preferred one. (Personally, I use cygwin for Windows stuff (with
the mingw64 cross compiler), but that is because I like the
UNIXy look and feel of cygwin.)
Did you look at the symbols that can be found in the respective
DLLs, do they match your expectations? (I presume you follow
https://stackoverflow.com/questions/48021991/creating-dll-with-gfortran-on-windows
).
On 1/10/2025 3:27 AM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I cannot get a small code sample with or without a DLL to exhibit the
problem. Like I said, I thought it was something related to size of my
DLL. And this is the small DLL, only 3 MB.
Regarding DLLs, I'm out... I don't think I have ever done one.
Which toolchain are you using? Msys/mingw64 is probably the
preferred one. (Personally, I use cygwin for Windows stuff (with
the mingw64 cross compiler), but that is because I like the
UNIXy look and feel of cygwin.)
Did you look at the symbols that can be found in the respective
DLLs, do they match your expectations? (I presume you follow
https://stackoverflow.com/questions/48021991/creating-dll-with-gfortran-on-windows
).
For compilers and IDE, I am using GCC 14.1 that is in Simply Fortran 3.38.
https://simplyfortran.com/
For Unix utilities on Windows, I use the old Thompson Toolkit from 1987
that had the grep written in assembly language for SPEED. Finding code
in 5,000+ subroutines across 60+ subdirectories requires SPEED.
http://www.tasoft.com/toolkit.html
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 1/10/2025 3:27 AM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I cannot get a small code sample with or without a DLL to exhibit the
problem. Like I said, I thought it was something related to size of my >>>> DLL. And this is the small DLL, only 3 MB.
Regarding DLLs, I'm out... I don't think I have ever done one.
Which toolchain are you using? Msys/mingw64 is probably the
preferred one. (Personally, I use cygwin for Windows stuff (with
the mingw64 cross compiler), but that is because I like the
UNIXy look and feel of cygwin.)
Did you look at the symbols that can be found in the respective
DLLs, do they match your expectations? (I presume you follow
https://stackoverflow.com/questions/48021991/creating-dll-with-gfortran-on-windows
).
For compilers and IDE, I am using GCC 14.1 that is in Simply Fortran 3.38. >> https://simplyfortran.com/
Hm, OK. I'm not familiar with how Simply Fortran operates; they do
not cooperate with the gfortran team (but rather make money off the
work of volunteers). If you have questions regarding teir toolbox,
this is best addressed to them.
For Unix utilities on Windows, I use the old Thompson Toolkit from 1987
that had the grep written in assembly language for SPEED. Finding code
in 5,000+ subroutines across 60+ subdirectories requires SPEED.
http://www.tasoft.com/toolkit.html
Do you have a working nm? If not, debugging this will be pretty
much impossible.
On 1/10/2025 5:01 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 1/10/2025 3:27 AM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I cannot get a small code sample with or without a DLL to exhibit the >>>>> problem. Like I said, I thought it was something related to size of my >>>>> DLL. And this is the small DLL, only 3 MB.
Regarding DLLs, I'm out... I don't think I have ever done one.
Which toolchain are you using? Msys/mingw64 is probably the
preferred one. (Personally, I use cygwin for Windows stuff (with
the mingw64 cross compiler), but that is because I like the
UNIXy look and feel of cygwin.)
Did you look at the symbols that can be found in the respective
DLLs, do they match your expectations? (I presume you follow
https://stackoverflow.com/questions/48021991/creating-dll-with-gfortran-on-windows
).
For compilers and IDE, I am using GCC 14.1 that is in Simply Fortran 3.38. >>> https://simplyfortran.com/
Hm, OK. I'm not familiar with how Simply Fortran operates; they do
not cooperate with the gfortran team (but rather make money off the
work of volunteers). If you have questions regarding teir toolbox,
this is best addressed to them.
For Unix utilities on Windows, I use the old Thompson Toolkit from 1987
that had the grep written in assembly language for SPEED. Finding code
in 5,000+ subroutines across 60+ subdirectories requires SPEED.
http://www.tasoft.com/toolkit.html
Do you have a working nm? If not, debugging this will be pretty
much impossible.
Yes, I do. I am looking at the results right now. 35,932 lines of
stuff. I have confirmed that I am not using stdcall which may be wrong,
I am not sure yet. The Watcom F77, C, and C++ compilers used stdcall so
I am familiar with it.
Hm, OK. I'm not familiar with how Simply Fortran operates; they do
not cooperate with the gfortran team (but rather make money off the
work of volunteers). If you have questions regarding teir toolbox,
this is best addressed to them.
On 1/10/2025 3:01 PM, Thomas Koenig wrote:
Hm, OK. I'm not familiar with how Simply Fortran operates; they do
not cooperate with the gfortran team (but rather make money off the
work of volunteers). If you have questions regarding teir toolbox,
this is best addressed to them.
It is not strictly true that the Simply Fortran folks make money off the work of volunteers. They do not charge for the use of gfortran. Anyone
can install their software for free, and that installation provides
gfortran (and friends) that can be accessed from the command line
without any license from Simply Fortran. What they do charge for is
their IDE.
On 1/10/2025 3:01 PM, Thomas Koenig wrote:
Hm, OK. I'm not familiar with how Simply Fortran operates; they do
not cooperate with the gfortran team (but rather make money off the
work of volunteers). If you have questions regarding teir toolbox,
this is best addressed to them.
It is not strictly true that the Simply Fortran folks make money off the work of volunteers. They do not charge for the use of gfortran. Anyone
can install their software for free, and that installation provides
gfortran (and friends) that can be accessed from the command line
without any license from Simply Fortran. What they do charge for is
their IDE.
On Sun, 12 Jan 2025 11:11:47 -0800, baf wrote:
On 1/10/2025 3:01 PM, Thomas Koenig wrote:
Hm, OK. I'm not familiar with how Simply Fortran operates; they do
not cooperate with the gfortran team (but rather make money off the
work of volunteers). If you have questions regarding teir toolbox,
this is best addressed to them.
It is not strictly true that the Simply Fortran folks make money off the
work of volunteers. They do not charge for the use of gfortran. Anyone
can install their software for free, and that installation provides
gfortran (and friends) that can be accessed from the command line
without any license from Simply Fortran. What they do charge for is
their IDE.
I suppose that is one way to look at the situation. OTOH,
Simply Fortran would not exist if gfortran did not exist.
SF's homepage does not even bother to acknowledge that the
Fortran compiler is in fact gfortran. One does find on the
'Features' page: "Simply Fortran has been designed from the
start with GNU Fortran integration as the primary goal."
Additionally, there is no easily found information concerning
the actual version of GCC that comes with SF.
I suspect that Thomas's point is that the SF developer(s)
have not sent bug reports, patches to fix bugs, engaged
with any of gfortran's main contributors, or even said
"Thank you". Sure, the GPL does not require such behavior,
but the current lack of interaction appears to be somewhat
discourteous.
I just ran into a nasty problem with GFortran and G++ (C++). Probably
not a bug ??? I am using GCC 14.1.
I have a lot of code in C++ (over 100,000 lines). I have 750,000 lines
of code in GFortran. I have to extern "C" this code in C++ to make it callable by GFortran code.
I missed declaring a couple of C++ functions as extern "C" which means
that they kept their C++ mangled link names. But these C++ functions
were declared as integer*8 and external in the GFortran code (old F77
code).
So, the GCC linker did not report to me that it did not have a link for
the G++ functions. This may be a bug, I am not sure.
When I ran the program, the C++ functions were not called by the
GFortran code. Instead, the GFortran code treated the C++ functions as integer*8 scalar variables.
If needful, I can probably put together a small code sample that
exhibits the problem. Maybe. It could be that the size of my code affects the GCC linker.
I removed the Gfortran code "external" keywords, extern "C" the C++ functions, added the C++ function to my module list, and got a working
link.
Thanks,
Lynn
I found and fixed the problem with my code along with one of my
programmers. I was not properly handling the size_t hidden argument
length value that GFortran adds to the character string arguments in my
C++ code. Things are going better now.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I found and fixed the problem with my code along with one of my
programmers. I was not properly handling the size_t hidden argument
length value that GFortran adds to the character string arguments in my
C++ code. Things are going better now.
Good to hear that.
Another thing that works well for gcc is to link everything with
the -flto option.
An example:
$ cat main.f90
program memain
character *1 c
call foo(c)
print *,c
end
$ cat foo.c
void foo_(char *c)
{
*c = 'A';
}
$ gfortran -flto main.f90 foo.c
main.f90:3:13: warning: type of 'foo' does not match original declaration [-Wlto-type-mismatch]
3 | call foo(c)
| ^
foo.c:1:6: note: type mismatch in parameter 2
1 | void foo_(char *c)
| ^
foo.c:1:6: note: type 'void' should match type 'long int'
foo.c:1:6: note: 'foo_' was previously declared here
On 1/14/2025 12:42 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I found and fixed the problem with my code along with one of my
programmers. I was not properly handling the size_t hidden argument
length value that GFortran adds to the character string arguments in my
C++ code. Things are going better now.
Good to hear that.
Another thing that works well for gcc is to link everything with
the -flto option.
An example:
$ cat main.f90
program memain
character *1 c
call foo(c)
print *,c
end
$ cat foo.c
void foo_(char *c)
{
*c = 'A';
}
$ gfortran -flto main.f90 foo.c
main.f90:3:13: warning: type of 'foo' does not match original declaration [-Wlto-type-mismatch]
3 | call foo(c)
| ^
foo.c:1:6: note: type mismatch in parameter 2
1 | void foo_(char *c)
| ^
foo.c:1:6: note: type 'void' should match type 'long int'
foo.c:1:6: note: 'foo_' was previously declared here
I will try it.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 146:15:08 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,935 |
| D/L today: |
21 files (1,090K bytes) |
| Messages: | 2,410,864 |