On character constants

Just a curiosity...

This code:

program test_chr
   implicit none
   character(len=*), parameter :: NAME(0:2) = (/&
          'abcd efg ',&
          'ABC',&
          'ABcd'/)
   write(*,*) NAME
end program test_chr

builds with GCC-4.3.4, but fails using GCC-4.4.4, with the following errors:

test_chr.f90:4.21:

          'abcd efg ',&
                      1
Error: Different CHARACTER lengths (9/3) in array constructor at (1)
test_chr.f90:7.17:

   write(*,*) NAME
                  1
Error: Symbol 'name' at (1) has no IMPLICIT type

It seems that it wants all initializations of the same length, i.e.

character(len=*), parameter :: NAME(0:2) = (/&
          'abcd efg ',&

[Patch, Fortran] PR42650 - F90: DT function with in-line DT definition and RESULT is rejected

Another kind of obvious patch.

Build & regtested on x86-64-linux.
OK for the trunk?

Tobias

PS: Paul, thanks for your review! I have added the variable declaration
and assignment for the other patch before committal.

2010-02-02  Tobias Burnus  <burnus <at> net-b.de>

	PR fortran/42650
	* parse.c (decode_specification_statement): Use sym->result not sym.

2010-02-02  Tobias Burnus  <burnus <at> net-b.de>

	PR fortran/42650
	* gfortran.dg/func_result_5.f90: New test.

Index: gcc/fortran/parse.c
===================================================================
--- gcc/fortran/parse.c	(Revision 156433)
+++ gcc/fortran/parse.c	(Arbeitskopie)
@@ -111,7 +111,7 @@ decode_specification_statement (void)
   match ("import", gfc_match_import, ST_IMPORT);
   match ("use", gfc_match_use, ST_USE);

-  if (gfc_current_block ()->ts.type != BT_DERIVED)

Re: On character constants

Ciao Angelo,

Angelo Graziosi ha scritto.
>   character(len=*), parameter :: NAME(0:2) = (/&
>          'abcd efg ',&
>          'ABC',&
>          'ABcd'/)
>   write(*,*) NAME
> end program test_chr
>
>          'abcd efg ',&
>                      1
> Error: Different CHARACTER lengths (9/3) in array constructor at (1)

The Fortran standard mandates that all strings in a constructor have the
same length; I think this is a constraint, i.e. something a compiler has
to diagnose - thus a check was added. I recall that we considered
(continuing) to allow it as extension, but it was unclear how the proper
length should be determined; one can construct corner cases where one
really does not know which value would be "correct" - thus we simply
follow the standard and let gfortran always reject it.

However, you can use:
   (/ character(len=9) :: 'A', 'ABC', ... /)
as this removed the ambiguity regarding the length and is 100%
standard-conform Fortran 2003/2008.

Tobias

Re: On character constants

2010/2/2 Tobias Burnus <burnus <at> net-b.de>:
> The Fortran standard mandates that all strings in a constructor have the
> same length; I think this is a constraint, i.e. something a compiler has
> to diagnose - thus a check was added. I recall that we considered
> (continuing) to allow it as extension, but it was unclear how the proper
> length should be determined; one can construct corner cases where one
> really does not know which value would be "correct" - thus we simply
> follow the standard and let gfortran always reject it.
>

Hi Tobias,

just out of curiosity, can you give an example of such a corner case?

Regards,

Arjen

Re: On character constants

Il 02/02/2010 8.48, Tobias Burnus ha scritto:
> Ciao Angelo,
 > [...]
> However, you can use:
>     (/ character(len=9) :: 'A', 'ABC', ... /)
> as this removed the ambiguity regarding the length and is 100%
> standard-conform Fortran 2003/2008.

Tobias,
thanks a lot for suggestions,

Angelo.

Re: On character constants

On 02/02/2010 09:09 AM, Arjen Markus wrote:
> just out of curiosity, can you give an example of such a corner case?
>   

Not ad hoc, but I can quote from a comp.lang.fortran's post of Richard
Maine:

"It turns out that there are more complications to the question than I
had imagined. The complications arise in cases where it is non-trivial
for the compiler to tell up front to tell what the character lengths
are. Yes, that can happen. It usually involves things like function
calls where the function returns a string of computed length. Implied DO
loops that can possibly be zero-trip ones make things worse. Trust me 
that it can get really, really messy - messier than I'd have ever
believed. Henry Zongaro had an incredible ability to find the obscure
cases that broke every rule that anyone proposed to "fix" things. The
messy cases mostly weren't things that "sane" users would actually do,
but they were a big deal for compiler writers who are supposed to make
the compiler work even for the "insane" users if the standard says it is
supposed to work."

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/336e596975ea5aec/

Tobias

Re: On character constants

On 02/02/2010 09:47 AM, Tobias Burnus wrote:
> On 02/02/2010 09:09 AM, Arjen Markus wrote:
>> just out of curiosity, can you give an example of such a corner case?
>>   
>
> Not ad hoc,

Not really a corner case, but what length should a compiler assume as
length in a constructor? The largest, the one of the first argument? the
one of the first constant length?

If one thinks of how to implement it, it becomes also quite difficult:
Currently, as soon as one knows one length, one can reserve
<length>*<#of elements> memory and put all the results together. If one
takes the largest one, one needs to iterate through all elements,
potentially creating lots of temporary variables just to find out the
length from the last function call. -- In case of initialization
expressions, it is easier. If you try with GCC 4.3 or ifort and
string-lengths which are only know at run time, the result can be
unexpected.

Try the following and tell beforehand what it should print. Try it with
your favourite compiler and tell me whether it is what you expected -
and what one should expect.

call test("A")
call test("Abcdef")
contains
subroutine test(a)
character(len=*) :: a

Re: [Patch, Fortran] PR42650 - F90: DT function with in-line DT definition and RESULT is rejected

Tobias,

Dang it!  I did not see it, although I looked.  Yes it is obvious and
is good for trunk and 4.4.

Well done and thanks

Paul

On Tue, Feb 2, 2010 at 8:37 AM, Tobias Burnus <burnus <at> net-b.de> wrote:
> Another kind of obvious patch.
>
> Build & regtested on x86-64-linux.
> OK for the trunk?
>
> Tobias
>
> PS: Paul, thanks for your review! I have added the variable declaration
> and assignment for the other patch before committal.
>

--

-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

[RFC] Interoperability C <-> Fortran for struct and COMMON (PR 41664 and PR 41227)

Hello all,

I have some interoperability question - mostly related to the things not
covered by the standard, including common vendor extensions and stuff
which "simply worked".

Most of the issues come about due to LTO where the middle end needs to
know whether to types are identical or not. Thus, for the following
items one need to decide which should fail, should be fixed for LTO or
for the Fortran front end. The issues relate mostly to C-Fortran
interoperability, but also (different-sized COMMON blocks) to
Fortran-Fortran compatibility.

Quotes from the standard are relative to Fortran 2003 (
http://www.j3-fortran.org/doc/year/04/04-007.pdf ). Note BIND(C) is new
since Fortran 2003 thus one need to think about pre-F2003 legacy support.

a) Derived TYPE

15.2.3: "A Fortran derived type is interoperable with a C struct type if
the derived-type definition of the Fortran type specifies BIND(C) [....]"

Legacy: A SEQUENCE type  ("TYPE name; sequence; integer :: i" ...)
should presumably also just work. Note: If one explicitly uses
__attribute__ ((packed)) the interoperability is gone.

As far as I can see, pr40725_0.f03 + pr40725_1.f03
(testsuite/gfortran.dg/lto) is valid according to the standard and
should work. (It is currently failing, see PR 41664 - and seems to be an
LTO bug.)

Re: [RFC] Interoperability C <-> Fortran for struct and COMMON (PR 41664 and PR 41227)

Can I have a pointer to the sources?  Just information on where to look
would do.  Thanks.

Most of these comments aren't very helpful, I am afraid.  This is a can
of worms.

> b) COMMON
> 
> F2003, 15.3: "A C variable with external linkage interoperates with a
> common block that has been specified in a BIND statement
> (1) if the C variable is of a struct type and the variables that are
> members of the common block are interoperable with corresponding
> components of the struct type, or
> (2) if the common block contains a single variable, and the variable is
> interoperable with the C variable."
> 
> First interpretation question: Does a common block with a single
> variable interoperate with a struct and a non-struct variable or only
> with the latter? (I think only with the latter.)

I think both, actually.  And I think that's a mistake - quite a serious
one.  I was going to offer to raise it in a Fortran standards context
but, upon checking, it seems that the root cause is a very serious
deficiency in the C standard.

4#2 says:
    Undefined behavior is otherwise indicated in this International
    Standard by the words ``undefined behavior'' or by the omission of
    any explicit definition of behavior.  There is no difference in
    emphasis among these three; they all describe ``behavior that is