[Fortran, Patch] Proposed type-bound procedures patch, part 1

Hi,

attached is a proposed draft-patch for type-bound procedures; it is 
meant to parse and resolve (that is, check the binding, PASS/NOPASS and 
such is correct) specific bindings, that is ones of the form

PROCEDURE, attributes :: name => target

The found procedures are stored as symtrees in the derived-type's 
f2k_derived namespace; additional attributes specific to type-bound 
procedures are added as new pointer member to gfc_symtree.

Awaiting your comments on this way to store the information and the 
various XXX marks still in the patch...  However, the patch introduces 
no regressions on i686-pc-linux-gnu and all my own tests succeed.

I'd like to get this patch in the current scope (parsing and resolving) 
reviewed and checked-in (with a not-yet-implemented message to be added) 
as to keep patches small before continuing with actually calling those 
procedures.

Yours,
Daniel

--

-- 
Done:     Arc-Bar-Sam-Val-Wiz, Dwa-Elf-Gno-Hum-Orc, Law-Neu-Cha, Fem-Mal
Underway: Cav-Dwa-Law-Fem
To go:    Cav-Hea-Kni-Mon-Pri-Ran-Rog-Tou

Re: [Fortran, Patch] Proposed type-bound procedures patch, part 1

Hi Daniel,

some pre-remarks without reading your patch.

Daniel Kraft wrote:
> The found procedures are stored as symtrees in the derived-type's 
> f2k_derived namespace; additional attributes specific to type-bound 
> procedures are added as new pointer member to gfc_symtree.
I'm currently thinking about how to do this such that most of the 
machinery can be reused for procedure-pointer components:

type t
  procedure(interface), pointer, PASS(x) :: proc
end type t

There, one has
   procedure([intrinsic type|name_of_explicitly_knowninterface]), 
pointer [,nopass][,pass(...)] ::
which is quite similar (except that for nopass there might be no 
explicit interface). For procedure pointers, one probably would save  
"gfc_typebound_proc" as pointer in gfc_component (which has to be 
changed a lot to save all the attributes and formal arguments, which are 
currently unsaved) - and in gfc_symbol as a gfc_component is converted 
into a gfc_symbol.

Also the PASS-resolving could be combined; in both cases the type has to 
be passed as n-th argument to the procedure. I have not yet checked 
whether the current implementation easily allows for this.

Tobias

Re: [Fortran, Patch] Proposed type-bound procedures patch, part 1

Tobias Burnus wrote:
> Hi Daniel,
> 
> some pre-remarks without reading your patch.
> 
> Daniel Kraft wrote:
>> The found procedures are stored as symtrees in the derived-type's 
>> f2k_derived namespace; additional attributes specific to type-bound 
>> procedures are added as new pointer member to gfc_symtree.
> I'm currently thinking about how to do this such that most of the 
> machinery can be reused for procedure-pointer components:

The current PASS-resolving is not 100% extensible to procptr components, 
but it should be trivial to move the corresponding code to a new method 
that could be used for both purposes; I can do this, if you want, or 
leave it to be done when procptr components are actually implemented.

We could also consider moving the relevant data to a new struct and 
include that struct in gfc_typebound_proc; this should be trivial, too, 
and I'll do it if you want.

For what comes in the future, I've planned to put adding the "this" 
argument to the actual arglist into its own method so this can be reused 
for procptr components (would probaby rely on putting the common data 
into its own struct or extending gfc_typebound_proc with procptr 
components data).  And the part that might be the most tricky one (I 
don't know by now) could be parsing something like var%proc(a, b, c) as 
procedure in CALL and as function in the various places...  This can be 
shared between typebound-procedures and procptr components, too.  Maybe 
create new methods that given var as gfc_expr*, proc as gfc_symbol* (for 

Fortran dynamic linking

[Patch, Fortran] Use __builtin_expect in libgfortran

This patch replaces

  if (unlikely fulfilled condition)
    runtime_error (...);

by
  if (__builtin_expect (unlikely fulfilled condition, 0))
    runtime_error (...);

to speed up the library.

See: http://www.imodulo.com/gnu/gcc/Other-Builtins.html

"The use of __builtin_expect has now two uses:

 - on platforms where conditional jump instructions have prediction bits
   this information can be used to set them

 - on all architectures it should now be possible to use
	-freorder-blocks
   to use the information to put the basic blocks in an order which
   guarantees an optimal straight pass through the code for the
   normal case."
(quote from http://sources.redhat.com/ml/libc-hacker/2000-04/msg00129.html
 -freorder-blocks is enabled with -O2)

I hope that I have not missed any place or wrongly marked something as
likely/unlikely which is not.

Build and check-gfortraned on x86-64-linux

Re: [Patch, Fortran] Use __builtin_expect in libgfortran

Sent from my iPhone

On Aug 3, 2008, at 3:36, Tobias Burnus <tobias.burnus <at> physik.fu-berlin.de 
 > wrote:

> This patch replaces
>
>  if (unlikely fulfilled condition)
>    runtime_error (...);
>
> by
>  if (__builtin_expect (unlikely fulfilled condition, 0))
>    runtime_error (...);
>
> to speed up the library.

If rutime_error is marked as noreturn, gcc already does this internally.
-- Pinski

>
>
> See: http://www.imodulo.com/gnu/gcc/Other-Builtins.html
>
> "The use of __builtin_expect has now two uses:
>
> - on platforms where conditional jump instructions have prediction  
> bits
>   this information can be used to set them
>

Re: [Patch, Fortran] Use __builtin_expect in libgfortran

Andrew Thomas Pinski wrote:
> On Aug 3, 2008, at 3:36, Tobias Burnus 
> <tobias.burnus <at> physik.fu-berlin.de> wrote:
>>  if (unlikely fulfilled condition)
>> by
>>  if (__builtin_expect (unlikely fulfilled condition, 0))
> If rutime_error is marked as noreturn, gcc already does this internally.
Great! That reduces the patch size a lot (at least in terms of changed 
lines). Attached an updated version of the patch. Additional to removing 
the not needed __builtin_expected, I added __attribute__ ((format 
(printf...))) to two functions in libgfortran.h to improve compile-time 
error checking.

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

Tobias

2008-08-03  Tobias Burnus  <burnus <at> net-b.de>

	* libgfortran.h (__mingw_snprintf, runtime_warning_at):
	Add __attribute__ ((format (printf...))).
	* io/file_pos.c (st_backspace, st_endfile, st_rewind,
	export_proto): Use __builtin_expect.
	* io/open.c (edit_modes, new_unit, already_open,
	st_open): Ditto.
	* intrinsics/dtime.c (dtime_sub): Ditto.
	* intrinsics/pack_generic.c (pack_internal): Ditto.
	* intrinsics/etime.c (etime_sub): Ditto.
	* intrinsics/spread_generic.c (spread_internal): Ditto.

Re: [Patch, Fortran] Use __builtin_expect in libgfortran

Tobias Burnus wrote:
> Andrew Thomas Pinski wrote:
>> If rutime_error is marked as noreturn, gcc already does this internally.
> Great! That reduces the patch size a lot (at least in terms of changed 
> lines). Attached an updated version of the patch. Additional to 
> removing the not needed __builtin_expected, I added __attribute__ 
> ((format (printf...))) to two functions in libgfortran.h to improve 
> compile-time error checking.

I missed two places. Additionally, Andrew pointed out on IRC that
  a) ptr == NULL
  b) ptr1 == ptr2
comparisons are regarded to be unlikely (cf. predict.c -> "pointer 
heuristic"). I therefore removed some other __builtin_expects.

We should keep (a) in mind for the procedures, which take optional 
arguments; at least in some cases optional arguments are only rarely 
passed. In these cases one can use __built_expected(..., 1). [But one 
should be careful as one easily might get this wrong. For instance might 
be there programs which are relying on iostat= errors (e.g. file does 
not exist), which can be called much more frequently than the not 
failing calls.]

As follow-up work one could mark if-branches for zero-sized arrays as 
unlikely; I think I marked a few such, but there are presumably much more.

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

Tobias

[patch, libfortran] UTF-8 Support, part 1

Hi all,

This initial patch provides partial support for ENCODING="utf-8" I/O.

The three test cases provided are for testing only.  As I further develop this, 
I will refine these into test cases for the test suite.

Testing and evaluation of this patch by others is welcome.  There are a few 
places where there is duplicated code related to processing delimiters.  Its a 
toss up to make this a macro or otherwise to consolidate these.

Also, please let me know if you see anything I have omitted.

The following items remain to be implemented:

1. Support of internal unit I/O to KIND=4 character strings/arrays. I plan this 
as a separate patch. (Part 2)

2. Processing of T,TL, and TR format specifiers with UTF-8 encoded strings. 
This will require positioning across variable width characters in the format 
buffer. Another patch (Part 3)

I have regression tested this against current trunk on x86-64.  While waiting 
for review comments, I will proceed with Part 2.  I have a scheme already worked 
out for part 3.

OK to commit Part 1 after development of the test cases?

Regards,

Re: [patch, libfortran] UTF-8 Support, part 1

Jerry DeLisle wrote:
> This initial patch provides partial support for ENCODING="utf-8" I/O.
I did some tests. First results:

a) I have not tried without your patch, but the following gives an ICE:
  f951: internal compiler error: in gfc_interpret_character, at 
fortran/target-memory.c:402
I should try with an unmodified 4.4 compiler and fill a bug report.

  write(*,'(a)') transfer(int(z'bde4'),4_'a')
  end

b) If I run the following program, I expect as result:
 뷠 len= 1
However, I get 255 times "뷠" and len=255. If I use a "normal" ascii 
text (i.e. without option -fbackslash), I get that text, padded by "0" 
(I really mean the digit 0 not achar(0)). The written file looks fine 
thus this seems to be a reading problem.

character(len=255,kind=4) :: str
open(6,encoding="UTF-8")
open(66,file="test.txt",encoding="UTF-8",status="replace")
write(66,'(a)') 4_'\ubde0'
rewind(66)
read(66,'(a)') str
write(*,*) trim(str),' len=',len(trim(str))
end

c) Here, I'm not 100% sure what to expect, but I think the output should 
be "? 1" and not "뷠 3":