Use of G95 compiler #2

Closed
bonanza opened this Issue Feb 17, 2011 · 12 comments

Projects

None yet

3 participants

@bonanza
Collaborator
bonanza commented Feb 17, 2011

The examples gtkhello2, cairo-basics, mandelbrot and mandelbrot_pixbuf work with G95 compiler (g95 gtk.f90 .f90 -o pkg-config --cflags --libs gtk+-2.0), version 0.93, configured with ../configure --enable-languages=c --disable-multilib, thread model: posix, gcc version 4.1.2, Linux 2.6.32-22-generic #36-Ubuntu SMP x86_64 GNU/Linux.

@vmagnin
Collaborator
vmagnin commented Feb 17, 2011

Thank you for these precisions. How long did the compilation take ?
I tried g95 under Ubuntu 10.10, it works but the compilation time is between 5 and 10 minutes...

@bonanza
Collaborator
bonanza commented Feb 17, 2011

Indeed, compilation with g95 takes long time in comparison with gfortran (gcc-Version 4.6.0 20110212):
gtkhello2: 3min 0s (g95), 0min 26s (gfortran)
cairo-basics: 4min 27s (g95), 0min 33s (gfortran)
mandelbrot: 4min 32s (g95), 0min 17s (gfortran)
mandelbrot_pixbuf: 4min 15s (g95), 0min 40s (gfortran)

@bonanza
Collaborator
bonanza commented Feb 18, 2011

To be fair, here are the compilation times using the latest g95 version (g95 0.93! Aug 17 2010):
gtkhello2: 2min 41s,
cairo-basics: 3min 43s,
mandelbrot: 3min 44s,
mandelbrot_pixbuf: 3min 46s.

@bonanza
Collaborator
bonanza commented Feb 25, 2011
g95 -time gtk.f90 mandelbrot.f90 -o mandelbrot `pkg-config --cflags --libs gtk+-2.0`

gives output:
# f951 8.35 0.57
# as 0.01 0.00
# f951 271.59 1.99
# as 0.01 0.00
# ld 0.09 0.07

@vmagnin
Collaborator
vmagnin commented Feb 26, 2011

Perhaps the differences between compilers could come from the "use iso_c_binding" statement. With "use iso_c_binding, only: ....":
gfortran -time -g ../src/gtk.f90 tests.f90 pkg-config --cflags --libs gtk+-2.0
f951 6.96 0.50

as 0.04 0.00

f951 56.48 4.83

as 0.00 0.01

collect2 0.18 0.06

If I delete all the ", only:" statements in gtk.f90:
gfortran -time -g ../src/gtk.f90 tests.f90 pkg-config --cflags --libs gtk+-2.0
f951 178.89 1.22

as 0.04 0.01

f951 53.56 4.99

as 0.01 0.00

collect2 0.16 0.08

@bonanza
Collaborator
bonanza commented Mar 14, 2011

In the current gtk-fortran version (jerryd-gtk-fortran-138bf02) I get some errors with G95:
In file gtk.f90:66

        & data0, NULL, 0)
                 1
Error: Type mismatch in parameter 'destroy_data' at (1).  Passing TYPE(c_ptr) to TYPE(c_funptr)
In file gtk.f90:69

        & NULL, NULL, 0)
                1
Error: Type mismatch in parameter 'destroy_data' at (1).  Passing TYPE(c_ptr) to TYPE(c_funptr)
@vmagnin
Collaborator
vmagnin commented Mar 14, 2011

Thanks. We will watch this problem when the "boolean problem" will be solved.

@jtappin
Collaborator
jtappin commented Mar 14, 2011

Odd! I'm sure I posted a potential fix here.

There is a "c_null_funptr" defined in the iso_c_binding module, so the solution (I think) is to add:
type(c_funptr), parameter :: FNULL=c_null_funptr
to the constants in gtk.f90, and then replace the offending NULLs with FNULL.

@vmagnin
Collaborator
vmagnin commented Mar 15, 2011

I included and comitted your fix in gtk.f90 (test branch only). It works with g95 and gfortran on my 32bits linux machine.

@jtappin
Collaborator
jtappin commented Mar 15, 2011

One area I think we are going to have problems, is that on 64-bit platforms there are 2 versions of g95 -- one with 32-bit integers and the other with 64-bit integers. As far as I can see, there is no standard way to specify the KIND of an enumerator, so any code that uses enumerators will give a type mismatch as GTK expects its enumerated types to be 32-bits.
e.g:
In file fgtk_h_widgets.f90:37

    win = gtk_window_new (GTK_WINDOW_TOPLEVEL)
                          1
Error: Type mismatch in parameter 'type' at (1).  Passing INTEGER(8) to INTEGER(4)

I'm not sure there's any way around that one (apart from requiring the 32-bit DI version).

@vmagnin
Collaborator
vmagnin commented Mar 15, 2011

One solution could be to use systematically something like:
win = gtk_window_new ( int(GTK_WINDOW_TOPLEVEL, 4) )
or
win = gtk_window_new ( int(GTK_WINDOW_TOPLEVEL, c_int) )

A more elegant solution would be to replace all enumerators by parameters declarations, by modifying my translate_enums procedure in cfwrapper.py. I will think about it when I have some time.
It seems that we will learn a lot of things by testing gtk-fortran with 32bits and 64bits machines. It will help us build a more portable code.

@jtappin
Collaborator
jtappin commented Mar 15, 2011

Another useful thing for portabilty would be if we could build on a
big-endian machine.

I did try with the g95 sparc snapshot but just got loads of errors
from the Sun assembler (I have sent Andy an e-mail to see if the
assembler on that system is just too old). The gcc-related libraries
on that machine are too old to build the gfortran snapshot.

I don't think my old g3 iBook would be quite up to the task even if I
could get X working again.

@vmagnin vmagnin closed this Apr 21, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment