[patch, libfortran] PR33253 namelist: reading back a string with apostrophe

:ADDPATCH fortran:

Hi all,

After a lot of fussing, I think I have sorted this out.

The attached patch includes my original fix to this pr which checked for 
delimiters to decide whether to terminate reading.

In addition, this patch adjusts the conditions that allow extended reads of 
namelists.  This now requires -std=legacy.  The reason is that all these cases 
with non standard namelists such as extra data or no delimiters end up 
conflicting.  The mechanism for handling these is present, its a matter of 
choice when to allow what.

With this patch, non-delimited (no ' or ") strings work by default.  The test 
case namelist_24.f90 is modified to -std=legacy.  Two new test cases are 
provided. The test case namelist_39.f90 is derived from Toon Moene's case in 
pr33421.

I want to mention that according to the F95 standard, character strings in 
namelists are supposed to be delimited.  People should do that. (strong hint to 
anyone reading this :) ).

Regression tested on x86-64.

OK for trunk?

Regards,

Re: [patch, libfortran] PR33253 namelist: reading back a string with apostrophe

> In addition, this patch adjusts the conditions that allow extended  
> reads of namelists.  This now requires -std=legacy.  The reason is  
> that all these cases with non standard namelists such as extra data  
> or no delimiters end up conflicting.  The mechanism for handling  
> these is present, its a matter of choice when to allow what.

Short of a proper review, which I might do later this week, I want to  
note that as this requires users to turn change compiler options for  
their (broken) code, this should probably be noted in the release notes.

FX

Re: [Patch, fortran] PR33550 - ICE (segfault) when USEing ambiguous symbols

Thanks Jerry,

> OK, Obvious and simple rule.
>

Up to the "abiguous" that Tom Tromey pointed out.

Paul

--

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

Is this yet another bug with transfer

The following code

real(8)  :: x, ax(2)
real(16) :: y, z
equivalence (ax(1), z)
ax=transfer(1.0_16,x)
print *, ax
z = 1.0_16
print *, ax
end

gives

   1.00000000000000        1.00000000000000     
   1.00000000000000        0.00000000000000     

The second line is the answer I expect, do I misunderstand
something? or is the transfer not working properly here?

Note: yes I know that the use of the equivalence makes
the code non standard conforming.

Dominique

Re: Is this yet another bug with transfer

OK, I'm never too sure when it comes to transfer, but here is what I
think happens...

> real(8)  :: x, ax(2)
> real(16) :: y, z
> equivalence (ax(1), z)
> ax=transfer(1.0_16,x)

transfer(1.0_16,x) is a scalar real of kind value 8. Its value is the
first 32 bits of 1.0_16, and since you're using a big-endian, it so
happens that this corresponds to 1.0_8. The assignment is then:

  ax = 1.0_8

which is equivalent to ax(:) = 1.0_8, which sets both ax(1) and ax(2)
to 1.0_8, hence the result you're seeing. The result would be very
different on a little-endian platform; for example, on i686-mingw32, I
get (with real kinds 4 and 8):

$ cat a.f90
real(4)  :: x, ax(2)
real(8) :: y, z
equivalence (ax(1), z)
ax=transfer(1.0_8,x)
print *, ax
z = 1.0_8
print *, ax
end

$ gfortran a.f90 && ./a.exe

[Patch, fortran] PR33554 - [4.3 regression] Seg.fault: Default initialization of derived type uses uninitialized values

:ADDPATCH fortran:

This regression came about when I rejigged the handling of default
initialization of derived types with intent(out).  The block of code
doing the initilization was placed too early and so pre-empted the
calculation of dummy array offsets and lower bounds.  This triggered
the segfault.  The solution is to move this code to its own function
and to add the translated block to the top of the function body, just
before any deferred trickery is done to the function result.  The code
for deferred arrays is then added on top of that.  The testcase is the
reporter's with a bit of dejagnuification.

Regtested on cygwin_nt/PIV (will bootstrap and regtest tonight on
x86_ia64) - OK for trunk?

Paul

--

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

2007-10-01  Paul Thomas  <pault <at> gcc.gnu.org>

	PR fortran/33554
	* trans-decl.c
(init_intent_out_dt): New function.
	(gfc_trans_deferred_vars): Remove the code for
default
	initialization of INTENT(OUT) derived types and put it
	in the new function.  Call it earlier
than before, so
	that array offsets and lower bounds are available.

2007-10-01  Paul Thomas 
<pault <at> gcc.gnu.org>

	PR fortran/33554
	* gfortran.dg/intent_out_2.f90: New test.

Index: gcc/fortran/trans-decl.c
===================================================================

Re: Is this yet another bug with transfer

François-Xavier Coudert wrote:
> OK, I'm never too sure when it comes to transfer, but here is what I
> think happens...
> 
>> real(8)  :: x, ax(2)
>> real(16) :: y, z
>> equivalence (ax(1), z)
>> ax=transfer(1.0_16,x)
> 
> transfer(1.0_16,x) is a scalar real of kind value 8. Its value is the
> first 32 bits of 1.0_16, and since you're using a big-endian, it so
> happens that this corresponds to 1.0_8. The assignment is then:
> 
>   ax = 1.0_8
> 
> which is equivalent to ax(:) = 1.0_8, which sets both ax(1) and ax(2)
> to 1.0_8, hence the result you're seeing. The result would be very
> different on a little-endian platform
or even on a big-endian platform, with IEEE format for real(16).

[fortran,patch] Register entering/exiting source files, handling macro definitions debug info

Attached is my updated patch for PR33502: the first patch was reverted
after discovering that it screwed update -gstabs completely (thus
inducing bootstrap failures on targets that use stabs as default debug
format). The explanation in the original patch still stands
(http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01721.html), which was
rather detailed, still stands, so I copy-pasted bits of it for the
paragraphs below.

The Fortran front-end currently thinks the only preprocessor lines it
can be given are location lines (of the form: # linenum "filename").
This is not true for verbose debug (-g3): in that case, #define and
#undef preprocessor directives are included in the preprocessed file,
so that they debug info can be emitted for macros. The Fortran
front-end not only doesn't emit such debug information, but it even
chokes on the preprocessor lines. The first half of the patch fixes
that: We first encounter the #define and #undef lines when loading the
file; at that time, however, it's too early to emit debug info (the
compiler hasn't yet setup the output file), so we just have to ignore
them (that's the part in scanner.c:load_file). Later, when we actually
parse the source, we can actually handle them: in next_statement
[parse.c], we call about new function gfc_define_undef_line
[scanner.c], which calls debug_hooks->define and debug_hooks->undef.

However, doing so requires that we tell the middle-end (via the debug
target hooks) whenever we enter or exit a source file, ie whenever the
filename changes. I also discovered (serendipity!), while
investigating PR33408, that our current behaviour of not doing so
leads to bad memory references in the middle-end for stabs,
potentially triggering ICEs (at least one concrete example of this was
the initial report for PR33408, on powerpc-darwin).

Re: Is this yet another bug with transfer

My mistake had nothing to do with endianness, but was because
I did not read correctly the definition of TRANSFER():
transfer(1.0_16,x) is a scalar and I was expecting the result
of transfer(1.0_16,ax), i.e. an array of rank one and length two.

Thanks for the answer and sorry for the noise.

Dominique

Re: [patch, libfortran] PR33253 namelist: reading back a string with apostrophe

FX Coudert wrote:
>> In addition, this patch adjusts the conditions that allow extended 
>> reads of namelists.  This now requires -std=legacy.  The reason is 
>> that all these cases with non standard namelists such as extra data or 
>> no delimiters end up conflicting.  The mechanism for handling these is 
>> present, its a matter of choice when to allow what.
> 
> Short of a proper review, which I might do later this week, I want to 
> note that as this requires users to turn change compiler options for 
> their (broken) code, this should probably be noted in the release notes.
> 
> FX
> 
I agree.  Another thing that would be helpful is to see how other compilers 
handle the test cases given.  I only have ifort.

ifort fails on namelist_15.f90 but passes on namelist_24.f90 with no compiler 
options.

Any comment on the behavior we want would be appreciated.

Jerry