Re: Question about array types in the front-end

FX,

Sorry for the tardy reply.  I spent yesterday moving to Barcelona....
a disasterous day because the car blew its head gasket on the way.
*sigh*

>
>  So, Paul, anyone? Is it supposed to be that way? If I want
>  gfc_conv_array_parameter() to set GFC_ARRAY_TYPE_P on its results,
>  where should I do it and on what condition?

It might well need it.  I'll take a look today and I'll come back to you.

Cheers

Paul

>
>  Thanks,
>  FX, new to the array handling
>
>
>  Le 22 févr. 08 à 13:37, FX a écrit :
>
>  > Hi all,
>  >
>  > I dare ping that question... I'm really stuck with this fndecl issue
>  > and I think, even though it's probably not so huge a patch, it's
>  > important for 4.4 and it's also important to commit it early (because
>  > it's a quite intrusive change). So, if some of you have time to ponder

error on compilation for libgfortran from version 4.3 on

Dear GNU Fortran team,
when trying to compile the most recent versions of gcc and gfortran I 
encountered the error below. I was looking for some resolution of this in 
your mailing lists which is pointing to the issue of inlining functions and 
has something to do with the c99 standard. But there was nowhere a real 
solution what one should do in order to make the compilation work properly. 
I tested this on Linux Kernel 2.6.18.2-34-default i686 on Intel(R) Pentium(R) 
M processor 2.00GHz with SuSe Linux 10.2 as well as on
Linux Kernel 2.6.21.3-fr i686 on AMD Athlon(tm) 64 X2 Dual Core Processor 
4600+ with a Debian system. 
The error message is:
**********
libtool: 
compile:  /usr/local/packages/gcc-4.3-20080228/host-i686-pc-linux-gnu/gcc/xgcc
-B/usr/local/packages/gcc-4.3-20080228/host-i686-pc-linux-gnu/gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem
/usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I../.././libgfortran -I. -iquote../.././libgfortran/io
-I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config
-I../../host-i686-pc-linux-gnu/gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -g -O2 -MT 
transfer.lo -MD -MP -MF .deps/transfer.Tpo -c ../.././libgfortran/io/transfer.c -o 
transfer.o >/dev/null 2>&1
if /bin/sh ./libtool --tag=CC --mode=compile
/usr/local/packages/gcc-4.3-20080228/host-i686-pc-linux-gnu/gcc/xgcc
-B/usr/local/packages/gcc-4.3-20080228/host-i686-pc-linux-gnu/gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem
/usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I../.././libgfortran -I.  -iquote../.././libgfortran/io
-I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config

Re: Trying to find source of gfortran problems in Ubuntu

> 32/64 bit problem, why not. 

I haven't had a chance to further track down the NaNs, but I ran the same tests for ABINIT on my laptop as I did
for 64-bit desktop at work. Both have Ubuntu Gutsy Gibbon, but the laptop is just a 32-bit x86 system. I
could NOT reproduce the problem on my laptop.

      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Bootstrap failure building libobjc fixed

Hello all,

apologies for causing a bootstrap failure when building libobjc due to
my patch for PR 35063 (r132800).  As of r132802, I believe this issue
is now fixed. Big thanks to Jerry DeLisle for helping out with the
fix.

--

-- 
Janne Blomqvist

Re: Question about array types in the front-end

FX,

I needed to remind myself of which is which:)

From trans.h

/* An array without a descriptor.  */
#define GFC_ARRAY_TYPE_P(node) TYPE_LANG_FLAG_2(node)

Descriptor-less arrays are the types for which this flag should be
used.  It signals that the hidden descriptor in lang_type should be
used.

The only place where this flag is set is in gfc_get_nodesc_array_type,
as it should be.  I rather suspect that you need to be calling this
function for the dummies concerned.

Cheers

Paul

On Sat, Mar 1, 2008 at 9:10 AM, Paul Richard Thomas
<paul.richard.thomas <at> gmail.com> wrote:
> FX,
>
>  Sorry for the tardy reply.  I spent yesterday moving to Barcelona....
>  a disasterous day because the car blew its head gasket on the way.
>  *sigh*
>
>

Re: Question about array types in the front-end

> The only place where this flag is set is in gfc_get_nodesc_array_type,
> as it should be.  I rather suspect that you need to be calling this
> function for the dummies concerned.

Thanks for your explanation. Being stubborn, I decided to start  
playing nonetheless and I think the problem actually is that this  
flag should also be set in a few other places, like  
gfc_conv_descriptor_data_get() and gfc_conv_array_parameter(). When  
(if?) I get to submit a complete patch, I'll discuss the issue in  
more detail.

Anyway, I'm now down to 124 testsuite regressions, which is way  
better than my previous version of the patch! I'm not sure how hard  
it's going to be to fix the remaining issues, but I'll keep you updated.

                 === gfortran Summary ===

# of expected passes            23548
# of unexpected failures        124
# of expected failures          3
# of unresolved testcases       28
# of unsupported tests          18

--

-- 
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

STDCALL first patch

Hi all,

I'll try to be very quiet for a week in order to focus on my work,  
but before I go I have one last patch to send... I'm not submitting  
it formally for review, but I thought it might be useful to follow  
the "release early, release often" scheme...

This patch adds support for some of the popular !DEC$ ATTRIBUTES,  
namely dllimport, dllexport, stdcall, fastcall and cdecl. It scans,  
parses and matches these attributes against a list of know  
attributes, flags them in a new field of our attributes structure,  
symbol->attr.ext_attr and translates them into GCC attributes (for  
these 5, the GNU attribute name is the same, but it's coded in all  
generality and a generic 1-to-1 mapping can be provided in array  
ext_attr_list.

The patch is not complete yet: for example it doesn't yet write these  
new attributes to modules files or read them back. Apart from the  
module stuff, I believe it's fully functional though, so you can try  
it for yourself. I want to get your opinions, if any, on the first  
draft before going further.

Thanks,
FX

PS: I was amazed that it's quite a short patch, and it can easily be  
modified to add support for other directives, like !GNU$ ATTRIBUTES  
weak :: my_function, or stuff like that if we want (not that I'm  
saying we want to).

STDCALL first patch

Again, this time with the patch attached... and my apologies.

-----------------------------------------------
Hi all,

I'll try to be very quiet for a week in order to focus on my work,  
but before I go I have one last patch to send... I'm not submitting  
it formally for review, but I thought it might be useful to follow  
the "release early, release often" scheme...

This patch adds support for some of the popular !DEC$ ATTRIBUTES,  
namely dllimport, dllexport, stdcall, fastcall and cdecl. It scans,  
parses and matches these attributes against a list of know  
attributes, flags them in a new field of our attributes structure,  
symbol->attr.ext_attr and translates them into GCC attributes (for  
these 5, the GNU attribute name is the same, but it's coded in all  
generality and a generic 1-to-1 mapping can be provided in array  
ext_attr_list.

The patch is not complete yet: for example it doesn't yet write these  
new attributes to modules files or read them back. Apart from the  
module stuff, I believe it's fully functional though, so you can try  
it for yourself. I want to get your opinions, if any, on the first  
draft before going further.

Thanks,

openmp workshare

Hello,

I've been playing  with openmp and gfortran and am generally very
pleased (thank you!). However I haven't been able to get the workshare
directive to work. After reading this mailing list a while I found
this message:

http://gcc.gnu.org/ml/fortran/2008-02/msg00137.html

which suggests that openmp workshare is not implemented in gfortran. Is
this still the case? And if so are there any plans for it? I ask as it
is really a shame that one cannot parallelize array expressions with
openmp. We'll have to re-write with do-loops.

I know that this is a volunteer effort and I'm not offering to help (I
would if I could), but is there any hope this will be done?

Best regards,
John Travers

Re: [fortran,patch] Initial Fortran 2008 support

FX Coudert wrote:
> This patch opens the Fortran 2008 game.
>   -- documenting our Fortran 2008 support in the doc, referring to the 
> current draft and WG5 webpage; mentioning that, until the final 
> standard is published (or, at least voted), our F2008 support follows 
> the drafts and may be expected to change without warnings or 
> compatibility, if the committee changes their mind about something
It should not be too bad as we have now a Candiate Draft instead of only 
a Working Draft; I think it passed the J3 voting. It still needs to go 
through WG5 and then through SC22, but I do not expect major changes.

>   -- allowing empty CONTAINS in Fortran 2008 mode, not just as a GNU 
> extension
You could also update the following in fortran/decl.c:

3999:      /* Fortran 2008 draft allows BIND(C) for internal procedures.  */
4000-      if (gfc_current_state () == COMP_CONTAINS
4001-     && sym->ns->proc_name->attr.flavor != FL_MODULE
4002-     && gfc_notify_std (GFC_STD_GNU, "Extension: BIND(C) attribute 
at %L "
4003-                        "may not be specified for an internal 
procedure",
--
4733:      /* The following is allowed in the Fortran 2008 draft.  */
4734-      if (gfc_current_state () == COMP_CONTAINS
4735-     && sym->ns->proc_name->attr.flavor != FL_MODULE
4736-     && gfc_notify_std (GFC_STD_GNU, "Extension: BIND(C) attribute at "
4737-                        "%L may not be specified for an internal 
procedure",