[Bug fortran/35765] return type of complex functions not C compatible
--- Comment #5 from Georg dot Baum at post dot rwth-aachen dot de 2008-03-31 19:41 --- Subject: Re: return type of complex functions not C compatible > --- Comment #4 from burnus at gcc dot gnu dot org 2008-03-30 21:18 --- > > Not all. I gave two counter examples: pvf and ifort. > > Well at least ifort 9.1, 10.0 and 10.1 on Linux do not use the f2c calling > convention. It does not use __, but apart from that it handles complex valued functions in the same way as f2c and g77. Try it out if you don't believe. In terms of gfortran command line options: If you want gfortran to behave like ifort, use gfortran -ff2c -fno-second-underscore I have to admit that I don't know how ifort handles real valued functions, so it is possible that the above command breaks compatibility with ifort for real valued functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35765
[Bug fortran/35765] return type of complex functions not C compatible
--- Comment #3 from Georg dot Baum at post dot rwth-aachen dot de 2008-03-30 20:48 --- Thanks for the quick reply. You where right, I mixed up the FF2C macro in the test case. Unfortunately this was not the real problem. The problem I had in my code was that calling BLAS zdotc from C++ did not work. In this case using your "proper" 2003 way is no option, since the BLAS interface is well defined for years and won't change. And it is no option either if you use a commercial Fortran lib where you don't have the source. After further digging I found out what went wrong, and I'll explain it here in case somebody else runs into the same problem: gcc makes a difference between built in types and structs with respect to function return values (depends on the platform and the -fpcc-struct-return/-freg-struct-return switches). Therefore the working code from comment 1 does not work anymore if you replace the C99 complex types with a struct (even if that struct has the correct memory layout). This is a pity because many existing C/Fortran interface layers use structs to exchanging complex data, and this works on many C++/Fortran compiler combos if you take care of the alignment. Unfortunately in C++ you can't use C99 complex (it might be possible to use std::complex, because this is sometimes identical to C99 complex depending on the compiler config). So if you want to call a Fortran function that returns a complex number from C++ you have to declare it in a gcc specific way: double _Complex foo(); (In reply to comment #2) > > -ff2c: the return value is returned in an additional argument as g77 and > > other > > fortran compilers do it > > I want to point out that all? modern compiler use the -fno-f2c scheme which is > compatible with the default gfortran output. Not all. I gave two counter examples: pvf and ifort. > The f2c syntax goes back to the f2c compiler (www.netlib.org/f2c) which was > created at a time when C compilers were available but no Fortran 77 compiler > for free. It translated the Fortran code into C code which had then to be > compiled. (This is better and more correctly described at > http://en.wikipedia.org/wiki/F2c) I know what f2c is. Exactly because I do not want to use the -f2c switch I ran into the return value problem after switching from g77 to gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35765
[Bug fortran/35765] New: return type of complex functions not C compatible
As I understand the gfortran docs, the -ff2c/-fno-f2c switches change how
functions returning complex numbers are implemented:
-ff2c: the return value is returned in an additional argument as g77 and other
fortran compilers do it (can be seen e. g. in
http://www.pgroup.com/doc/pvfug.pdf, chapter 11 and
http://www.intel.com/support/performancetools/libraries/mkl/sb/cs-017175.htm)
-fno-f2c (which is the default): the return value is returned in a C compatible
manner without an additional argument.
The latter does not work for me. To reproduce, compile the snippet
complex function fcomplex_func(i)
implicit none
integer i
fcomplex_func = cmplx(i, 2*i)
end
double complex function dcomplex_func(i)
implicit none
integer i
dcomplex_func = dcmplx(i, 2*i)
end
with gfortran and the snippet
#include
typedef struct { float r; float i; } fcomplex;
typedef struct { double r; double i; } dcomplex;
#ifdef FF2C
extern fcomplex fcomplex_func__(int const *);
extern dcomplex dcomplex_func__(int const *);
#else
extern void fcomplex_func_(fcomplex *, int const *);
extern void dcomplex_func_(dcomplex *, int const *);
#endif
int main(){
int const i = 12;
int const j = 13;
fcomplex fc = {7,8};
dcomplex dc = {9,10};
#ifdef FF2C
printf("c return %d %d\n", i, j);
fc = fcomplex_func__(&i);
dc = dcomplex_func__(&j);
#else
printf("nonc return %d %d\n", i, j);
fcomplex_func_(&fc, &i);
dcomplex_func_(&dc, &j);
#endif
printf("fcomplex_func: %d %g %g\n", i, fc.r, fc.i);
printf("dcomplex_func: %d %lg %lg\n", j, dc.r, dc.i);
return 0;
}
with gcc and link both together. The expected output of the program is
nonc return 12 13
fcomplex_func: 12 12 24
dcomplex_func: 13 13 26
but here it goes into an endless loop and prints
nonc return 12 13
fcomplex_func: 12 7 8
dcomplex_func: 13 13 26
repeatedly until manual abort. Note that the double complex result is correct,
but nevertheless the call of dcomplex_func does something bad (stack
corruption?). The endless loop persists if you comment out the call of
fcomplex_func.
If you use the -ff2c switch of gfortran, and define the FF2C preprocessor
variable for gcc everything works well, and the output is as expected
nonc return 12 13
fcomplex_func: 12 12 24
dcomplex_func: 13 13 26
. I tried 4.2.4 svn from today, and the debian packages 4.2.3-2 and 4.3.0-1,
and all versions show this problem.
--
Summary: return type of complex functions not C compatible
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Georg dot Baum at post dot rwth-aachen dot de
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35765
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
--- Comment #2 from Georg dot Baum at post dot rwth-aachen dot de 2006-05-16 15:04 --- Yes, I think that would be good. Then you know that you are not doing something wrong but that it is a tool chain limitation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
[Bug c++/27557] New: OpenMP threadprivate directive does not work with non-POD types
Compiling the fragment
struct A {
A() {}
};
extern A a;
#pragma omp threadprivate(a)
A a;
with svn from yesterday yields
LANG=C g++-4.2 -fopenmp -c x.cpp -o x.o
x.cpp:6: error: 'a' cannot be thread-local because it has non-POD type 'A'
x.cpp:6: error: 'a' is thread-local and so cannot be dynamically initialized
It works if I remove the definition of a (last line).
I could not find anything in the OpenMP spec (version 2.5) stating that non-POD
threadprivate variables are not allowed. If I change the above to
struct A {
A() {}
};
A a;
#pragma omp threadprivate(a)
I get
LANG=C g++-4.2 -fopenmp -c x.cpp -o x.o
x.cpp:5: error: 'a' declared 'threadprivate' after first use
I believe that both variants are allowed by the OpenMP spec (version 2.5) and
they compile fine with icc 8.1. The spec says something about non-POD
variaables with explicit initializers in section 2.8.2 on page 69, but that
does not apply here. Please correct me if I am wrong.
--
Summary: OpenMP threadprivate directive does not work with non-
POD types
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Georg dot Baum at post dot rwth-aachen dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
[Bug middle-end/27499] New: ICE with unsigned iteration variable and -fopenmp
Now that the really baad OpenMP bugs seem to be fixed (thanhsk for that!) I
have a hopefully easy one: I get an ICE (svn from today) for the following C
code (and the C++ equivalent as well):
void f()
{
unsigned int i;
int dummy;
#pragma omp parallel for
for (i = 0; i < 5; ++i)
dummy = i;
}
LANG=C gcc-4.2 -c -fopenmp -o gcc-bug-signed.o gcc-bug-signed.c
gcc-bug-signed.c: In function 'f':
gcc-bug-signed.c:6: warning: iteration variable 'i' is unsigned
gcc-bug-signed.c:6: internal compiler error: in gimplify_omp_for, at
gimplify.c:4753
FYI icc 8.1 flags the unsigned variable as error.
--
Summary: ICE with unsigned iteration variable and -fopenmp
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Georg dot Baum at post dot rwth-aachen dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27499
[Bug middle-end/27325] ICE with enabled exceptions and -fopenmp
--- Comment #2 from Georg dot Baum at post dot rwth-aachen dot de 2006-04-28 15:05 --- The patch at http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01084.html fixes the problem for me. Now my code compiles without optimization, but with -O1 or higher I get a different ICE without file location that is very difficult to reduce. I'll file a new report when I managed to reduce it to something reasonable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27325
[Bug middle-end/26913] ICE with -fopenmp and -O1
--- Comment #5 from Georg dot Baum at post dot rwth-aachen dot de 2006-04-26 14:39 --- The test case does indeed not trigger the ICE anymore, but I have a similar new one: PR27325. -- Georg dot Baum at post dot rwth-aachen dot de changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26913
[Bug middle-end/27325] New: ICE with enabled exceptions and -fopenmp
The code
struct A {
~A();
};
int f()
{
A a;
#pragma omp parallel firstprivate(a)
for (int i = 0; i < 5; ++i)
int x = 0;
return 0;
}
gives the following ICE with gcc version 4.2.0 20060426 (experimental):
LANG=C g++-4.2 -c -fopenmp -o gcc-bug.o gcc-bug.cpp
gcc-bug.cpp: In function 'int f()':
gcc-bug.cpp:5: internal compiler error: in find_outermost_region_in_block, at
tree-cfg.c:4758
This is reduced from the same code as PR26913 (thanks for the fix). The ICE
disappears with -fno-exceptions. I am not sure whether this is a duplicate of
PR26823, but the ICE appears in a different file, so maybe it is not.
In the process of reducing I got also two other ICEs:
gcc-bug.cpp:16: internal compiler error: in make_decl_rtl, at varasm.c:1009
and
gcc-bug.cpp:27: error: basic block 5 edge lists are corrupted
gcc-bug.cpp:27: internal compiler error: verify_flow_info failed
Since these appear in a rather large file I'll reduce them further and file
reports after this problem is fixed (if they still appear then).
--
Summary: ICE with enabled exceptions and -fopenmp
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Georg dot Baum at post dot rwth-aachen dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27325
[Bug c++/26913] New: ICE with -fopenmp and -O2
I get a ICE in g++ for the following code when compiled with -fopenmp and -O2:
#include
int foo()
{
int x1;
#pragma omp parallel
{
for (int i = 0; i < 5; ++i) {
std::string xxx;
}
}
return 0;
}
Note that this is not exactly bug 26823, since the function name where the ICE
occurs is not printed. I tried to replace std::string with something else, but
then the ICE disappears. This is with svn from yesterday: g++-4.2 (GCC) 4.2.0
20060328 (experimental)
--
Summary: ICE with -fopenmp and -O2
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Georg dot Baum at post dot rwth-aachen dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26913
