headers
Jack Howarth | 1 Dec 2008 01:22
Picon

Re: -fdefault-integer-8 again!-(

On Sun, Nov 30, 2008 at 11:58:08PM +0100, Paul Richard Thomas wrote:
> > (-m32 and -m64). The most annoying problem I have seen so far is
> > an ICE for gfortran.dg/alloc_comp_constructor_1.f90 (pr34143,
> > just closed as fixed by Paul Thomas):
> 
> Why is that 'annoying'? This was a patch that was posted months ago;
> none of this was said <at> the time or since.
> As for the testcase you mention, it has nothing to do with pr34143.
> It's comment says:
> 
> ! Test constructors of derived type with allocatable components (PR 20541).
> 
> 
> It might be that I have caused a regression on powerpc-apple-darwin9.
> However, this platform is becoming so aberrant as to be unmaintainable
> for the likes of me. I do not have this machine nor do I see the
> problems that it has.
> 
> ...snip..
> 
> > Should I reopen pr34143 or open a new pr?
> 
> Do what you want - I wash my hands of it.  Revert my patch on
> allocatable components if you want and fix it yourself.
> 
> Paul

Paul,
   I think a more reasonable response would be to ask if this
same issue exists on powerpc64 linux. The problem doesn't show
(Continue reading)

Permalink | Reply | 12 comments |
headers
Paul Richard Thomas | 1 Dec 2008 07:30
Picon

Re: -fdefault-integer-8 again!-(

Dear Jack and Daniel,

>   I think a more reasonable response would be to ask if this
> same issue exists on powerpc64 linux. The problem doesn't show
> up in the stock testsuite runs on powerpc Darwin9 so it make
> be latent on powerpc64 linux as well.

I was not inclined to be reasonable, having spent a good part of my
weekend working on gfortran.

I guess that you are right about the language thing; Je sais bien ce
que pensait, Dominique:-)

Sorry, Dominique - *pault eats humble pie*

However, it does raise a serious point - we need support for power-pc
to understand why it seems to throw up problems not seen elsewhere.  I
will check whether changing the defaults does a job on x86_i64
tonight.

Cheers

Paul
Permalink | Reply | 3 comments |
headers
Janus Weil | 1 Dec 2008 14:06

[Patch, Fortran] PR 36704/38290

Hi all,

this patch fixes two PRs (at least partially):

* PR 36704 - Procedure pointer as function result: This I was planning
to implement in 4.5, but when having a look at it over the weekend, I
found that certain cases (i.e. those using a RESULT statement, see
proc_ptr_12.f90) are really easy to implement, so maybe this could
still go into 4.4 (since it's more of a bugfix than a 'feature')? The
harder cases (without RESULT statement) I will then take care of
later.

* PR 38290 - Procedure pointer assignment checking: This adds a few
additional checks for procedure pointer assignments and fixes comment
#2 from the PR, including an ICE, so it's even a 4.4 regression.

The patch passes the testsuite on i686-pc-linux-gnu without
regressions. Ok for trunk?

Cheers,
Janus

2008-12-01  Janus Weil  <janus <at> gcc.gnu.org>

	PR fortran/36704
	PR fortran/38290
	* decl.c (match_result): Result may be a standard variable or a
	procedure pointer.
	* expr.c (gfc_check_pointer_assign): Additional checks for procedure
	pointer assignments.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Daniel Kraft | 1 Dec 2008 14:38
Picon

Re: [Patch, Fortran] PR 36704/38290

Hi Janus,

Janus Weil wrote:
> this patch fixes two PRs (at least partially):
> 
> * PR 36704 - Procedure pointer as function result: This I was planning
> to implement in 4.5, but when having a look at it over the weekend, I
> found that certain cases (i.e. those using a RESULT statement, see
> proc_ptr_12.f90) are really easy to implement, so maybe this could
> still go into 4.4 (since it's more of a bugfix than a 'feature')? The
> harder cases (without RESULT statement) I will then take care of
> later.
> 
> * PR 38290 - Procedure pointer assignment checking: This adds a few
> additional checks for procedure pointer assignments and fixes comment
> #2 from the PR, including an ICE, so it's even a 4.4 regression.

 From my point of view, those should be both ok.

-  if (gfc_add_flavor (&r->attr, FL_VARIABLE, r->name, NULL) == FAILURE
-      || gfc_add_result (&r->attr, r->name, NULL) == FAILURE)
+  if (gfc_add_result (&r->attr, r->name, NULL) == FAILURE)
      return MATCH_ERROR;

Adding flavour FL_VARIABLE goes here without replacement (of course, it 
need to), but why was it needed in the first place?  Could this harm 
somehow?

-	  if (sym->attr.flavor == FL_UNKNOWN) sym->attr.flavor = FL_PROCEDURE;
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jack Howarth | 1 Dec 2008 14:43
Picon

Re: -fdefault-integer-8 again!-(

On Mon, Dec 01, 2008 at 07:30:38AM +0100, Paul Richard Thomas wrote:
> Dear Jack and Daniel,
> 
> 
> >   I think a more reasonable response would be to ask if this
> > same issue exists on powerpc64 linux. The problem doesn't show
> > up in the stock testsuite runs on powerpc Darwin9 so it make
> > be latent on powerpc64 linux as well.
> 
> I was not inclined to be reasonable, having spent a good part of my
> weekend working on gfortran.
> 
> I guess that you are right about the language thing; Je sais bien ce
> que pensait, Dominique:-)
> 
> Sorry, Dominique - *pault eats humble pie*
> 
> However, it does raise a serious point - we need support for power-pc
> to understand why it seems to throw up problems not seen elsewhere.  I
> will check whether changing the defaults does a job on x86_i64
> tonight.
> 
> Cheers
> 
> Paul

Paul,
   I am well aware of how annoying it will become to support PowerPC
going forward considering that the main hardware source, Apple, is no
longer creatin new hardware for that architecture. However I think it
(Continue reading)

Permalink | Reply | 0 comments |
headers
IainS | 1 Dec 2008 15:08
Picon

Re: -fdefault-integer-8 again!-(


On 1 Dec 2008, at 06:30, Paul Richard Thomas wrote:

> Dear Jack and Daniel,

<snip>

> However, it does raise a serious point - we need support for power-pc
> to understand why it seems to throw up problems not seen elsewhere.  I
> will check whether changing the defaults does a job on x86_i64
> tonight.

I'm not in a position to offer much support for bug-fixing (at the  
moment) ...

... However, as far as testing is concerned - I am working on  
establishing a regular run on a Darwin9 PPC machine.

The choice of "more often run" or "rotation of different config  
options" could be by consensus (from my point of view I'd like to do  
what's most useful across the community).

At the moment, I am shaking down some issues with repeatability of   
"make check" output  (with thanks to Dominique, Jack and Geoff).

cheers,
Iain
Permalink | Reply | 0 comments |
headers
Janus Weil | 1 Dec 2008 15:17

Re: [Patch, Fortran] PR 36704/38290

Hi Daniel,

>> this patch fixes two PRs (at least partially):
>>
>> * PR 36704 - Procedure pointer as function result: This I was planning
>> to implement in 4.5, but when having a look at it over the weekend, I
>> found that certain cases (i.e. those using a RESULT statement, see
>> proc_ptr_12.f90) are really easy to implement, so maybe this could
>> still go into 4.4 (since it's more of a bugfix than a 'feature')? The
>> harder cases (without RESULT statement) I will then take care of
>> later.
>>
>> * PR 38290 - Procedure pointer assignment checking: This adds a few
>> additional checks for procedure pointer assignments and fixes comment
>> #2 from the PR, including an ICE, so it's even a 4.4 regression.
>
> From my point of view, those should be both ok.

thanks for the review!

> -  if (gfc_add_flavor (&r->attr, FL_VARIABLE, r->name, NULL) == FAILURE
> -      || gfc_add_result (&r->attr, r->name, NULL) == FAILURE)
> +  if (gfc_add_result (&r->attr, r->name, NULL) == FAILURE)
>     return MATCH_ERROR;
>
> Adding flavour FL_VARIABLE goes here without replacement (of course, it need
> to), but why was it needed in the first place?

Well, in Fortran 95 one could be sure that the RESULT statement was a
'normal' variable, i.e. FL_VARIABLE.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Steve Kargl | 1 Dec 2008 15:44
Picon

Re: optimization removes a __builtin_memcpy?

On Sun, Nov 30, 2008 at 07:56:51PM +0100, Paul Richard Thomas wrote:
> Dear Richard,
> 
> >> The diff shows that the fails case correctly has dlen=30
> >> and in fact for any value less than slen=44 and -O[123]
> >> removes the __builtin_memcpy().  So what is missing or
> >> how to I inhibit this optimization?
> >
> > You cannot inhibit this optimization, instead the optimization should be
> > fixed to not generate invalid gimple ;)  (see builtins.c:fold_builtin_memory_op)
> >
> 
> Your comment is a bit opaque, to me at least:-)  I looked at
> builtins.c:fold_builtin_memory_op and figured out that if dest or src
> are not pointer types the call does not get inlined.  Does this
> matter?
> 
> Steve, does the code work?
> 

I have a working patch.  Unfortunately, I had to move my trip
to Washington DC up by a day, so was sitting on an airplane 
for 5 hours yesterday.  I'll submit a patch sometime this
week.

Richard's comment helped to the extent that I read through
trans.c with a bit more care.  In the end, telling someone
with my background to look at builtins.c:fold_builtin_memory_op
is tantamount to telling a blind person to look at a Picasso.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steve Kargl | 1 Dec 2008 15:48
Picon

Re: optimization removes a __builtin_memcpy?

On Sun, Nov 30, 2008 at 10:18:22PM +0100, Richard Guenther wrote:
> On Sun, Nov 30, 2008 at 5:28 AM, Steve Kargl
> <sgk <at> troutmask.apl.washington.edu> wrote:
> >
> >     ERRMSG.12 = &"Attempt to deallocate an unallocated object"[1]{lb: 1 sz: 1};
> > -    ERRMSG.12 = stat.11 != 0 ? (void) __builtin_memcpy ((void *) &err, (void *) ERRMSG.12, 30) : (void) 0;
> > +    ERRMSG.12 = stat.11 != 0 ? err = *(character(kind=1)[1:30] * {ref-all}) ERRMSG.12 : (void) 0;
> 
> Btw, you assign "void" to ERRMSG.12 - this is certainly invalid GENERIC and not
> what you want to do, right?
> 

I have a working patch.  Don't know if it's completely correct;
however, there are no regressions.  The key appeared to be that
I needed to build a pointer to err instead on passing err itself.

--

-- 
Steve
Permalink | Reply | 0 comments |
headers
Steve Kargl | 1 Dec 2008 15:59
Picon

Re: -fdefault-integer-8 again!-(

On Sun, Nov 30, 2008 at 07:22:21PM -0500, Jack Howarth wrote:
> On Sun, Nov 30, 2008 at 11:58:08PM +0100, Paul Richard Thomas wrote:
> > > (-m32 and -m64). The most annoying problem I have seen so far is
> > > an ICE for gfortran.dg/alloc_comp_constructor_1.f90 (pr34143,
> > > just closed as fixed by Paul Thomas):
> > 
> > Why is that 'annoying'? This was a patch that was posted months ago;
> > none of this was said <at> the time or since.
> > As for the testcase you mention, it has nothing to do with pr34143.
> > It's comment says:
> > 
> > ! Test constructors of derived type with allocatable components (PR 20541).
> > 
> > 
> > It might be that I have caused a regression on powerpc-apple-darwin9.
> > However, this platform is becoming so aberrant as to be unmaintainable
> > for the likes of me. I do not have this machine nor do I see the
> > problems that it has.
> > 
> > ...snip..
> > 
> > > Should I reopen pr34143 or open a new pr?
> > 
> > Do what you want - I wash my hands of it.  Revert my patch on
> > allocatable components if you want and fix it yourself.
> > 
> > Paul
> 
> Paul,
>    I think a more reasonable response would be to ask if this
(Continue reading)

Permalink | Reply | 7 comments |

Gmane