[Bug fortran/35765] return type of complex functions not C compatible

2008-03-31 Thread Georg dot Baum at post dot rwth-aachen dot de
--- 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

[Bug fortran/35765] return type of complex functions not C compatible

2008-03-30 Thread Georg dot Baum at post dot rwth-aachen dot de
--- 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

[Bug fortran/35765] New: return type of complex functions not C compatible

2008-03-30 Thread Georg dot Baum at post dot rwth-aachen dot de
t: 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

2006-05-16 Thread Georg dot Baum at post dot rwth-aachen dot de
--- 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

2006-05-11 Thread Georg dot Baum at post dot rwth-aachen dot de
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

2006-05-08 Thread Georg dot Baum at post dot rwth-aachen dot de
-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

2006-04-28 Thread Georg dot Baum at post dot rwth-aachen dot de
--- 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

[Bug middle-end/26913] ICE with -fopenmp and -O1

2006-04-26 Thread Georg dot Baum at post dot rwth-aachen dot de
--- 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

[Bug middle-end/27325] New: ICE with enabled exceptions and -fopenmp

2006-04-26 Thread Georg dot Baum at post dot rwth-aachen dot de
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

2006-03-29 Thread Georg dot Baum at post dot rwth-aachen dot de
-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: i