gfortran support

[szaghi]

The present gfortran latest version (4.9.x) does not still support deferred length string defined as member of a derived type: FLAP cannot be compiled with gfortran until this gfortran bug will be fixed :-(

[victorsndvg]

Hello Stephano,
yes, It seems that FLAP don't compile with gfortran4.9. I was reading something about this bug and, as far as I know, it seems that gfortran4.9 (partly) supports deferred length strings in derived types.

Please, could you specify the origin of the problem with more detail?
Do you know if this issue is reported to GCC-Bugzilla?

[victorsndvg]

Sorry, i'm really fast pressing enter ..

After this, the good news is that I managed to compile (with gfortran4.9) and test the executable commenting only a few lines

[szaghi]

Good to know.

Feel free to do a pull request if you find a work around. It is a very silly bug... it seems that is use "directly" the deferred allocatable strings gfortran blows up, but if you copy it into a temporary variables before using gfortran works... I have done some tests (very quickly indeed), but I have not find a "sane" workaround.

[victorsndvg]

Sorry, I've probably been too positive...
I don't find any work around... I only comment some lines removing some features. I haven't forked the project and I don't know any other way to do a pull request.
The diff is shown as below:
+++ b/src/Data_Type_Command_Line_Interface.f90
@@ -762,10 +762,10 @@ contains
- if (present(examples)) then
- allocate(character(len=len(examples(1))):: cli%examples(1:size(examples)))
- cli%examples = examples
- endif
+! if (present(examples)) then
+! allocate(character(len=len(examples(1))):: cli%examples(1:size(examples)))
+! cli%examples = examples !Don't works with gfortran4.9
+! endif
!---------------------------------------------------------------------------------------------------------------------------------
@@ -986,11 +986,11 @@ contains
- do aaa=a+1,a+nargs
+ do aaa=a+nargs,a+1,-1
call get_command_argument(aaa,val)
- cli%cla(aa)%val = cli%cla(aa)%val//args_sep//trim(adjustl(val))
+ cli%cla(aa)%val = trim(adjustl(val))//args_sep//trim(cli%cla(aa)%val) !It works after commenting line 993
enddo
- cli%cla(aa)%val = cli%cla(aa)%val(1+len(args_sep):)
+ !cli%cla(aa)%val = cli%cla(aa)%val(1+len(args_sep):) !Don't works with gfortran4.9
@@ -1055,9 +1055,9 @@ contains !-------------------------------------------------------------------------------------------------------------------------------
- do a=1,cli%Na
- call cli%cla(a)%add_signature(signature=cla_list_sign)
- enddo
+! do a=1,cli%Na
+! call cli%cla(a)%add_signature(signature=cla_list_sign) !Don't works with gfortran4.9
+! enddo

[szaghi]

Thank you Victor.

I see your patches. Why reversing the loop do aaa=...?

If I understand right, with your patch the examples and the automatic signature are removed, but other features remain, is it right?

I will try your patch with more attention to evaluate if this can lead to a sane workaround maintaining all the present features.

Thank you very much, your help is very appreciated!

P.S. how do you find that the above modifications get gfortran to compile? is it a trial-error analysis or have you used some tool/compiler flags highlighting the crucial statements?

[victorsndvg]

Hello again,

I see your patches. Why reversing the loop do aaa=...?

After commenting line 993, I need to build a correct cli%cla(aa)%val without the first 1+len(args_sep) characters. Inside the loop I concatenate the strings in a different order.

If I understand right, with your patch the examples and the automatic signature are removed, but other features remain, is it right?

Yes, it is.

P.S. how do you find that the above modifications get gfortran to compile? is it a trial-error analysis or have you used some tool/compiler flags highlighting the crucial statements?

It was a trial-error analysis. After commenting the line 993, the compiler did all the work.

Line 993: https://github.com/szaghi/FLAP/blob/master/src/Data_Type_Command_Line_Interface.f90#L993

Best regards,
Víctor.

[szaghi]

Thank you again, this is a great starting point...

[victorsndvg]

just for your information, we take the following link as a starting point to find the problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63494

[szaghi]

Interesting, I found similar (I have not the link under my hands) for 4.9.x.

[szaghi]

Dear Victor,

this is a non official spoiler... basing on your patch I have written a workaround that is enough sane and... save all features including nice signature and examples...

Tomorrow I will upload a new version working with also gfortran 4.9.2!

Many many thanks!

[victorsndvg]

Great news! it makes me happy :)

I'm sure that FLAP will be very useful for us.

Congratulations for your great work.

[szaghi]

Dear Victor, you are too kind.

I have just uploaded the new version (0.0.4) that is Gfortran enabled. This has allowed also to perform a coverage analysis (that I am uploading into the wiki).

Please, take a look at the fobos file. In order to correctly build FLAP with gfortran two things are necessary:

• pass the -DGNU preprocessing flag to the preprocessor: unfortunately to retain all the features I have to define examples member differently between Intel and Gnu version, thus a compiling preprocessing flag was necessary;
• GNU gfortran (at least the 4.9.2 version I am using) has many bugs regarding deferred length characters: in particular I have found that if optimizations are enabled (-Ox x>0) the print_usage method exit with a seg-fault; I suggest to compile FLAP as standalone alone library with -DGNU -cpp -c -frealloc-lhs -fcheck=all -O0 (yes it seems that without -fcheck=all other Gfortran bugs raise up) and link it into your project as an external library, thus allowing your codes to be compiled with all optimizations.

Again, thank you very much!

[victorsndvg]

Dear Stephano,

after looking around the backtrace for the error in print_usage:

Backtrace for this error:
...
0x40E9C4 in __data_type_command_line_interface_MOD_signature at Data_Type_Command_Line_Interface.f90:662
...

I have commented a few lines and then run FLAP with Valgrind. Valgrind output was something similar to:

Conditional jump or move depends on uninitialised value(s)

referencing the sig variable inside function signature(cla).

adding sig = '' in the following line:

FLAP/src/Data_Type_Command_Line_Interface.f90

Line 651 in f999c86

if (cla%act==action_store) then

seem to fix the bug. This change it's right?

Now i'm compiling with -O3 and it works

Best regards,
Víctor.

[szaghi]

You are absolutely right... there are some variables not correctly initialized and among them sig!!!

I have not yet found the time to deeply profile the code!

Thank you very much!

[szaghi]

Got it, I refactor the method: I previously changed it from a subroutine to a function and my "old" things are now not refactored. Now works with also optimizations.

Thank you again.