Bug 49636 - [F03] ASSOCIATE construct confused with slightly complicated case
[F03] ASSOCIATE construct confused with slightly complicated case
Status: NEW
Product: gcc
Classification: Unclassified
Component: fortran
4.6.0
: P3 normal
: ---
Assigned To: Paul Thomas
: wrong-code
Depends on: 37577
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-04 22:59 UTC by Fred Krogh
Modified: 2014-02-12 09:20 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2014-02-10 00:00:00


Attachments
Fails test, with minor change works (371 bytes, text/x-fortran)
2011-07-04 22:59 UTC, Fred Krogh
Details
A fix for this problem (1.70 KB, patch)
2014-02-10 22:14 UTC, Paul Thomas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Fred Krogh 2011-07-04 22:59:16 UTC
Created attachment 24684 [details]
Fails test, with minor change works

The attached 16 line fortran program shows the problem.  The Intel (11.1) compiler works on this example.
Comment 1 Fred Krogh 2011-07-04 23:21:21 UTC
Sorry failed to include the output of the program.  Here it is.

i_good=         1         3         5
 i_bad=         1   4197184         3
Comment 2 Tobias Burnus 2011-07-05 09:05:46 UTC
I think this is one of the bugs, which depend on a new array descriptor (cf. http://gcc.gnu.org/wiki/ArrayDescriptorUpdate).

The problem is that for
    associate (i=>t2%j%i)
the array
      i(1:3)
is not contiguous in memory. In the current array descriptor implementation, only arrays with strides which are multiples of the block are possible - that's fine grained enough if there is only "integer :: i" but no longer if there is also another element ("integer :: k"). In that case, one needs to have strides which are byte-based ("stride multiplier")

It is rather high on the to-do list of gfortran, but as the patch will be invasive and will have to be done at once as it breaks the ABI (i.e. the downward compatibility), it is still pending. The idea is that one will use a descriptor which is compatible with the upcomming TR 29113. (TR = Technical Report, small standard extension which will be also integrated in the next Fortran standard.)

Cf. http://gcc.gnu.org/wiki/ArrayDescriptorUpdate

Given some other larger on-going projects, the lack of time of some core developers and given that GCC 4.7 will probably already branched in September combined with the need for ABI breakage [which should happen only once], I fear it won't be fixed for 4.7 but only later. :-(
Comment 3 Dominique d'Humieres 2014-02-10 09:33:17 UTC
Confirmed on 4.7, 4.8, and trunk (4.9 r207643). At r207649, compiling the test gives the following ICE:

pr49636.f90:14:0: internal compiler error: in gfc_get_element_type, at fortran/trans-types.c:1183
     print '(" i_bad=", 3I10)', i(1:3)

It is caused by r207646

Author:	pault
Date:	Sun Feb 9 20:50:21 2014 UTC (12 hours, 41 minutes ago)
Changed paths:	5
Log Message:	
2014-02-09  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/57522
	* resolve.c (resolve_assoc_var): Set the subref_array_pointer
	attribute for the 'associate-name' if necessary.
	* trans-stmt.c (trans_associate_var): If the 'associate-name'
	is a subref_array_pointer, assign the element size of the
	associate variable to 'span'.

2014-02-09  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/57522
	* gfortran.dg/associated_target_5.f03 : New test
Comment 4 Paul Thomas 2014-02-10 22:14:30 UTC
Created attachment 32098 [details]
A fix for this problem

I am sure that this trick will fix pr57019 too.  This latter is claimed to be a regression but I am sure that it never worked :-)  Nonetheless, I will take advantage of the regression label!

I will work on it tomorrow night.

By the way, this patch regtests OK on trunk.  I have to make sure that substrings of character arrays work OK with ASSOCIATE.

Thanks for the heads-up Dominique!

Cheers

Paul
Comment 5 Dominique d'Humieres 2014-02-11 23:40:07 UTC
> Created attachment 32098 [details]
> A fix for this problem

AFAICT it fixes the problem for 64 bit mode only. In 32 bit mode the ICE is gone, but I get at run time

i_good=         1         3         5
 i_bad=         1**********         3

> I am sure that this trick will fix pr57019 too.  This latter is claimed 
> to be a regression but I am sure that it never worked :-)  Nonetheless, 
> I will take advantage of the regression label!
>
> I will work on it tomorrow night.
>
> By the way, this patch regtests OK on trunk.  I have to make sure 
> that substrings of character arrays work OK with ASSOCIATE.

Did you regtest with -m32? I see gfortran.dg/associated_target_5.f03 failing at execution time with -m32, as well as the first test in pr57522

           0           1           2           3
           0           4           1           5
Comment 6 paul.richard.thomas@gmail.com 2014-02-12 09:20:47 UTC
 Dear Dominique,

Thanks for the heads-up about -m32 - I thought that the code would be
immune to word length changes ***sigh***

Cheers

Paul

On 12 February 2014 00:40, dominiq at lps dot ens.fr
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49636
>
> --- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
>> Created attachment 32098 [details]
>> A fix for this problem
>
> AFAICT it fixes the problem for 64 bit mode only. In 32 bit mode the ICE is
> gone, but I get at run time
>
> i_good=         1         3         5
>  i_bad=         1**********         3
>
>> I am sure that this trick will fix pr57019 too.  This latter is claimed
>> to be a regression but I am sure that it never worked :-)  Nonetheless,
>> I will take advantage of the regression label!
>>
>> I will work on it tomorrow night.
>>
>> By the way, this patch regtests OK on trunk.  I have to make sure
>> that substrings of character arrays work OK with ASSOCIATE.
>
> Did you regtest with -m32? I see gfortran.dg/associated_target_5.f03 failing at
> execution time with -m32, as well as the first test in pr57522
>
>            0           1           2           3
>            0           4           1           5
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.