Re: Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]

Tobias Burnus wrote:
> Dave Korn wrote:
>> Dave Korn wrote:
>>> Dave Korn wrote:
>>>> Tobias Burnus wrote:
>>>>> I agree that for "main" the call to "__main()" should happend and thus
>>>>> expand_main_function should be called. I'm not sure in about the exact
>>>>> assumptions of the middle end. In principle, it would be OK if the
>>>>> MAIN__ function would show up as MAIN__ in gimple/-fdump-tree-original.
>>>>> The only potential inconvenience I see, is the mentioned reference to
>>>>> MAIN__ instead of <program name> in middle-end warnings, which can
>>>>> confuse users.
>>   Is it legitimate to have a space in an IDENTIFIER_NODE?  I have a cheeky idea:
> 
>> -  gfc_get_symbol (name, ns, &main_program);
>> +  identifier = gfc_get_string ("PROGRAM %s", name);
> 
>>   That should give reasonable warnings from the middle end, no?  I don't know
>> what it might do to debugging though.
> 
> Currently one can use "b MAIN__" and "b helloworld" in the debugger:
> 
> (gdb) b helloworld
> Breakpoint 1 at 0x400737: file test.f90, line 3.
> (gdb) b MAIN__
> Note: breakpoint 1 also set at pc 0x400737.
> Breakpoint 2 at 0x400737: file test.f90, line 3.
> (gdb) b main
> Breakpoint 3 at 0x4007b9: file test.f90, line 9.
> 

Re: gfortran vs ifort

On Fri, 29 May 2009, Tim Prince wrote:
> [...] although I think you are changing the subject frivolously.
> gfortran 4.1.2 is unacceptably out of date, and shouldn't be
> compared with a recent version [...]

Well, no.  I work on a Beowulf cluster that belongs to my institute.
All I can do is request an upgrade, which I did.  They have promised
to do that in another month (!).

On Fri, 29 May 2009, Tobias Burnus wrote:
> and general and really worth reading:
>
> David Goldberg, What Every Computer Scientist Should Know About
> Floating-Point Arithmetic
> David Monniaux, The pitfalls of verifying floating-point
> computations:

Thanks for this Tobias.

--

-- 
Girish Kulkarni - Allahabad, India - athene.org.in/girish

Re: [PATCH]: Integrate gfortran with MPC

On Thu, 28 May 2009, Steve Kargl wrote:

> I suspect that this is bug that has been immortalized in
> the testsuite.  It should probably be fixed to give the
> result that an equivalent C program would give.  Can you
> open a bug report and add me to cc?

Done, PR 40318.

Note the problem goes back to at least the 4.3 series.  While we can solve
it for gcc-4.5 using MPC, the older releases would need to have IEEE
special cases hand-entered into the fortran folding code (and possibly
into the middle-end.)

		--Kaveh

Re: Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]

Jerry DeLisle wrote:
> I tested the above on x86-64 Linux.  OK to commit.
Thanks for the review. Committed:

Sending        gcc/fortran/ChangeLog
Sending        gcc/fortran/trans-decl.c
Transmitting file data ..
Committed revision 148035.

Tobias

Cygwin, gfortran and C interop

I am trying to link a program that uses the C interoperability features 
of Fortran 2003 to call OpenGL routines. This works fine under Linux, 
but not under Cygwin. The problem is that the linker is looking for 
(e.g.) '_glBegin':
gl_module.o:gl_module.F90:(.text+0x293c): undefined reference to `_glBegin'
but the OpenGL library in /lib/w32api/libopengl32.a provides '_glBegin <at> 4':
  $ nm 'c:\cygwin\lib\w32api\libopengl32.a' | grep glBegin
00000000 I __imp__glBegin <at> 4
00000000 T _glBegin <at> 4

The Fortran code contains the following interface:
INTERFACE
SUBROUTINE glBegin(mode) BIND(C,NAME="glBegin")
IMPORT
INTEGER(GLenum), VALUE :: mode
END SUBROUTINE glBegin
END INTERFACE

Can I modify the interface to persuade gfortran to generate the right 
reference? The Nag compiler provides the possibility of modifying the 
interface to
INTERFACE
SUBROUTINE glBegin(mode) BIND(C,NAME="__stdcall glBegin")
IMPORT
INTEGER(GLenum), VALUE :: mode
END SUBROUTINE glBegin
END INTERFACE
and then it generates a reference to _glBegin <at> 4 as required.

gfortran doesn't accept this, but does it provide some other way round 

[trunk<-vta] Re: [vta, trunk?, fortran] fix -g/-g0 codegen diffs in fortran

On Nov 25, 2008, Alexandre Oliva <aoliva <at> redhat.com> wrote:

> This patch fixes 204 -fcompare-debug failures in GCC fortran
> (including libgomp) testsuites.

> It fixes two separate issues, that each cause divergence in decl uids,
> which in turn lead to optimization differences in compilations with
> and without -g.

> 1. we didn't generate range types for multidimensional arrays when not
>   generating debug info

> 2. we only generated base decls for array descriptors when emitting
>   debug info

> I acknowledge these changes are somewhat wasteful, especially the
> second part, that's most certainly too conservative, but I figured I'm
> not sufficiently familiar with this front-end to figure out a better
> way to do it.

> Suggestions?

Ok for trunk?

for  gcc/fortran/ChangeLog
from  Alexandre Oliva  <aoliva <at> redhat.com>

	* trans-decl.c (gfc_build_qualified_array): Don't skip generation

Re: [PATCH]: Integrate gfortran with MPC

2009/5/31 Dominique Dhumieres <dominiq <at> lps.ens.fr>:

> Any better ideas?

This might be somewhat closer to what the functional analysis guys
would expect (sorry if I'm lecturing):
Complex numbers have a well-defined concept of infinity, which I like
to visualise as the "infinite-diameter" ring around the finite complex
numbers, so its argument is, of course, not well-defined. This is
conceptually somewhat different from the two points +/-Inf on the real
line, and it is not signed.
Thus, I would humbly suggest to identify every number a+bi, where |a|
or |b| (or both!) are Inf with complex infinity (and likewise for NaN.
Cases like Inf + iNaN surely want to be NaN as well).
This definition of an "infinite side length" square is consistent with
my textbook's one (any takers?)
Using this definition, analogue rules as for real numbers hold for complex ones:
- z/(Complex Inf) = 0+0i, as long as z /= (Complex Inf) or (Complex
NaN), and (Complex NaN) otherwise,
- z/(0+0i) = (Complex Inf), as long as z /= 0+0i, (Complex Inf) or
(Complex NaN), and (Complex NaN) otherwise.

To me, this would be the least surprising approach.

Thoughts?

Cheers,
Dennis

Re: Cygwin, gfortran and C interop

Anthony Stone wrote:
> but the OpenGL library in /lib/w32api/libopengl32.a provides
> '_glBegin <at> 4':
> [...]
> SUBROUTINE glBegin(mode) BIND(C,NAME="glBegin")
> [...]
> Can I modify the interface to persuade gfortran to generate the right
> reference? The Nag compiler provides the possibility of modifying the
> interface to
> SUBROUTINE glBegin(mode) BIND(C,NAME="__stdcall glBegin")
No, currently STDCALL is not supported. There were plans to do so, but
so far there was no patch 

Using NAME="__stdcall ..." is an interesting idea; before I have only
seen Visual Fortran's
!DEC$, cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34112

The design does not look as clean as, e.g.
   BIND(C,convention="stdcall",name="glBegin")
but at least it fits better into the current C binding system as !DEC$.

Can you give a reference to name="__stdcall glBegin" ? I cannot find it
in the documentation of NAG; or is this a side effect of NAG f95
producing C code?

In any case, we should finally do something about it.

Tobias

Re: [Patch,Fortran] Update gfortran.texi for mixed-language programming

Hello Tobias,

* Tobias Burnus wrote on Sun, May 31, 2009 at 11:39:01PM CEST:
> PS: Please proof read. I did a couple of times, found
> several typos, but I think there are more language and
> maybe also content bugs hidden.

Style and language-proof only:

> 2009-05-31  Tobias Burnus  <burnus <at> net-b.de>
> 
> 	* gfortran.texi: Add mixed-language programming, mention
> 	varying string lengths, some clean up of introduction parts.
> 	* intrinsic.texi (instrinsic modules): Create @menu for
> 	subsections.
> 	(ISO_C_BINDING): Support ISOCBINDING_INT_FAST128_T.
> 	* libgfortran.h: Comment to rember to keep gfortran.texi
> 	in sync.
> 	* iso-c-binding.def: Support ISOCBINDING_INT_FAST128_T.

> --- gfortran.texi	(Revision 148016)
> +++ gfortran.texi	(Arbeitskopie)
> @@ -182,6 +182,7 @@
>  Part II: Language Reference
>  * Fortran 2003 and 2008 status::  Fortran 2003 and 2008 features supported by GNU Fortran.
>  * Compiler Characteristics::      KIND type parameters supported.
> +* Mixed-language programming::    Interoperability with C

I think it is common to uppercase like this in headings and node names:
  Mixed-Language Programming::     Interoperability with C

Re: [fortran] Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]

Tobias Burnus wrote:
> Jerry DeLisle wrote:
>> I tested the above on x86-64 Linux.  OK to commit.
> Thanks for the review. Committed:
> 
> Sending        gcc/fortran/ChangeLog
> Sending        gcc/fortran/trans-decl.c
> Transmitting file data ..
> Committed revision 148035.
> 
> Tobias

  Thank you both :)

    cheers,
      DaveK