[Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

            Bug ID: 64432
           Summary: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong
                    result for integer(4)::rate
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: anlauf at gmx dot de

I just discovered that the 20141227 snapshot breaks SYSTEM_CLOCK when
the COUNT_RATE argument is a 32-bit integer:

% cat gfcbug128.f90
program gfcbug128
  integer(4) :: count_rate, count_max
  call system_clock (count_rate=count_rate)
  call system_clock (count_max=count_max)
  print *, count_rate, count_max
end

GNU Fortran (GCC) 5.0.0 20141227 (experimental)
produces:

% head -11 gfcbug128.f90.003t.original
gfcbug128 ()
{
  integer(kind=4) count_max;
  integer(kind=4) count_rate;

  {
    integer(kind=8) count_rate.0;

    _gfortran_system_clock_8 (0B, &count_rate.0, 0B);
    count_rate = (integer(kind=4)) count_rate.0;
    _gfortran_system_clock_4 (0B, 0B, &count_max);

whereas my 4.9 or other older installations give:

% head -7 gfcbug128.f90.003t.original-49 
gfcbug128 ()
{
  integer(kind=4) count_max;
  integer(kind=4) count_rate;

  _gfortran_system_clock_4 (0B, &count_rate, 0B);
  _gfortran_system_clock_4 (0B, 0B, &count_max);

On my Linux system, the _4 version has count_rate=1000,
the _8 version is 1000000.

:-(

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #1 from Harald Anlauf <anlauf at gmx dot de> ---
Modifying the test code as follows:

% cat gfcbug128b.f90
program gfcbug128b
  integer(4) :: count_rate, count_max
  call system_clock (count_rate=count_rate,count_max=count_max)
  call system_clock (count_rate=count_rate)
  call system_clock (count_max=count_max)
end

% head -12 gfcbug128b.f90.003t.original
gfcbug128b ()
{
  integer(kind=4) count_max;
  integer(kind=4) count_rate;

  {
    integer(kind=8) count_rate.0;

    _gfortran_system_clock_4 (0B, &count_rate, &count_max);
    _gfortran_system_clock_8 (0B, &count_rate.0, 0B);
    count_rate = (integer(kind=4)) count_rate.0;
    _gfortran_system_clock_4 (0B, 0B, &count_max);

shows that the logic in trans-intrinsic.c::conv_intrinsic_system_clock
does not cover the case of single arguments:


  gfc_expr *count = code->ext.actual->expr;
  gfc_expr *count_rate = code->ext.actual->next->expr;
  gfc_expr *count_max = code->ext.actual->next->next->expr;

  /* The INTEGER(8) version has higher precision, it is used if both COUNT
     and COUNT_MAX can hold 64-bit values, or are absent.  */
  if ((!count || count->ts.kind >= 8)
      && (!count_max || count_max->ts.kind >= 8))
    kind = 8;
  else
    kind = gfc_default_integer_kind;
  type = gfc_get_int_type (kind);

  /* Evaluate our arguments.  */


This probably needs to be amended.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

Harald Anlauf <anlauf at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu.org

--- Comment #2 from Harald Anlauf <anlauf at gmx dot de> ---
Introduced in r211686.
FX?

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Harald Anlauf from comment #0)
> I just discovered that the 20141227 snapshot breaks SYSTEM_CLOCK when
> the COUNT_RATE argument is a 32-bit integer:

Confirmed. Probably due to r211686.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-12-29
                 CC|                            |janus at gcc dot gnu.org
     Ever confirmed|0                           |1

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |fxcoudert at gcc dot gnu.org

--- Comment #4 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
I'm not sure this is a bug, but this was definitely by design (as the comment
indicates). I think this is allowed by the successive standards (which are, in
any case, very weakly worded).

The root of the problem is that we want to allow for SYSTEM_CLOCK to return
high-precision values for large integer kinds, and fall back to lower-precision
results that fit in fewer bytes for smaller integer kinds. Thus, one should
call SYSTEM_CLOCK once with all the necessary arguments, and not multiple times
with varying argument types.

The only other consistent option I can see would be to simply go for
high-resolution results in all cases, but that would mean that SYSTEM_CLOCK
with 32-bit integers would wrap around in less than an hour.

If you have another idea, please post a list of what you think should happen in
all various cases (all possible combinations of arguments have to be allowed).

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #5 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Francois-Xavier Coudert from comment #4)
> I'm not sure this is a bug, but this was definitely by design (as the
> comment indicates). I think this is allowed by the successive standards
> (which are, in any case, very weakly worded).

Well, let's see: the standard says:

  COUNT RATE (optional) shall be an integer or real scalar. It is an
    INTENT (OUT) argument. It is assigned a processor-dependent approximation
    to the number of processor clock counts per second, or zero if there is
    no clock.

You're right, it does not say anything about consistency.
Nevertheless, I would prefer if a program that always uses
e.g. default integer == integer(4), the low-resolution (msec)
version continues to be used consistently.  That's what other
compilers do and what gfortran <= 4.9 did.

Also, the presence of a second argument (see comment #1) should
not change the behavior.

OTOH, it is the responsibility of a user to consistently use
arguments of the same type and kind to get consistent behavior.
(I.e. not mixing integer and real or integer(4) and integer(8)).
I do take care of that.

> The root of the problem is that we want to allow for SYSTEM_CLOCK to return
> high-precision values for large integer kinds, and fall back to
> lower-precision results that fit in fewer bytes for smaller integer kinds.

How is this fallback done?  Do you truncate the resolution?
E.g. high res. -> low res.: divide count_rate and count by 1000?

> Thus, one should call SYSTEM_CLOCK once with all the necessary arguments,
> and not multiple times with varying argument types.

Note that I did *not* call SYSTEM_CLOCK with varying argument types.

You're probably not aware of existing (f95) code that deals with
the problem of wrapping, which is always present (count does not
necessarily start with 0 at start of the program), although not
very likely with integer(8)... ;-)

> The only other consistent option I can see would be to simply go for
> high-resolution results in all cases, but that would mean that SYSTEM_CLOCK
> with 32-bit integers would wrap around in less than an hour.

No, that doesn't make sense.

> If you have another idea, please post a list of what you think should happen
> in all various cases (all possible combinations of arguments have to be
> allowed).

Let's see:

- For any number of arguments present (1, 2 or 3)
  - always integer(4): msec resolution (as before)
  - always integer(>=8): usec resolution (or whatever is possible)
  - always real: I don't care, but I think it might be a good idea
    to use the same as for integer of a compatible kind.
  - different types and/or kinds: I don't care, since one should
    expect problems (wrapping or truncation) anyway.

But presence of non-presence should never make a difference
if consistent types and kinds are used.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #6 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Harald Anlauf from comment #5)
> Also, the presence of a second argument (see comment #1) should
> not change the behavior.

To make that explicit:

% cat gfcbug128c.f90
program gfcbug128c
  integer(4) :: count_rate, count_max
  call system_clock (count_rate=count_rate,count_max=count_max)
  print *, count_rate, count_max
  call system_clock (count_rate=count_rate)
  call system_clock (count_max=count_max)
  print *, count_rate, count_max
end

gfortran 5 gives:

        1000  2147483647
     1000000  2147483647

any other compiler:

        1000  2147483647
        1000  2147483647

I'd have a hard time to explain that to anybody.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Joost.VandeVondele at mat dot ethz
                   |                            |.ch

--- Comment #8 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
also in cp2k we use separate calls for getting the count_rate, count_max and
count.

I think as long as they are the same kind there should be no problem. *8
arguments resolve to the _8 version and *4 to the _4 version. Both versions
ideally have different resolution. 

I would argue that allowing a single call to system_clock to have integer
arguments of different kind is somewhat of a bug in the standard, possibly
worthy of a compiler warning. In that case, I would resolve return -HUGE,0,0
i.e. system_clock of this version not supported (also allowed by the standard).

Actually, the latter seems like a good idea for integer*1 and integer*2
system_clock calls as well, since the current version is non-conforming. 

> cat test.f90
INTEGER*1 :: count,count_max,count_rate
DO
  CALL SYSTEM_CLOCK(count,count_max,count_rate)
  write(6,*) count,count_max,count_rate
ENDDO

END
> ./a.out | head
  -14  -24   -1
  -13  -24   -1

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[Joost.VandeVondele at mat dot ethz.ch]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 2846 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #9 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
reading the standard, indeed it seems like count_rate can be real as well...
same rules here *4 -> _4 *8 -> _8.

As a side remark the following generates a slightly outdated error:

> cat test.f90
COMPLEX(KIND=4) :: count_rate
CALL SYSTEM_CLOCK(count_rate=count_rate)
END

> gfortran test.f90
test.f90:2:29:

 CALL SYSTEM_CLOCK(count_rate=count_rate)
                             1
Error: ‘count_rate’ argument of ‘system_clock’ intrinsic at (1) must be INTEGER

should be 'INTEGER or REAL'.

count and count_max are still integer.
>From gcc-bugs-return-471920-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 30 10:57:03 2014
Return-Path: <gcc-bugs-return-471920-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18453 invoked by alias); 30 Dec 2014 10:57:02 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18415 invoked by uid 48); 30 Dec 2014 10:56:57 -0000
From: "ysrumyan at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/64434] [5 Regression] Performance regression after operand canonicalization (r216728).
Date: Tue, 30 Dec 2014 10:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ysrumyan at gmail dot com
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-64434-4-1BJHO4akTh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64434-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64434-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg02927.txt.bz2
Content-length: 310

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd434

--- Comment #11 from Yuri Rumyantsev <ysrumyan at gmail dot com> ---
Created attachment 34363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id4363&actioníit
patch to fix issue

This patch fixed almost all issues related to operand canonicalization.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #10 from Harald Anlauf <anlauf at gmx dot de> ---
Created attachment 34374
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34374&action=edit
Partial patch to handle proposed behavior of system_clock

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #11 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Harald Anlauf from comment #10)
> Created attachment 34374 [details]
> Partial patch to handle proposed behavior of system_clock

The patch in comment #10 is a way to produce behavior similar
to Intel:

- every argument to SYSTEM_CLOCK is treated separately and independently
- tested with integer(4), integer(8) and also real(4/8) for count_rate

Note that:
- it is imcomplete, ugly
- inefficient (calls _gfortran_system_clock_ for each present argument)
- does not handle integer(1) and integer(2) properly
- needs cleanup

It works for me.  I.e., for

% cat gfcbug128d.f90
program gfcbug128d
  integer(4) :: count_rate_i4, count_max_i4
  integer(8) :: count_rate_i8, count_max_i8
  real(4)    :: count_rate_r4 = 0
  real(8)    :: count_rate_r8 = 0

  call system_clock (count_max=count_max_i4)
  call system_clock (count_rate=count_rate_i4)
  call system_clock (count_rate=count_rate_r4)
  print *, count_max_i4, count_rate_i4, count_rate_r4
  call system_clock (count_rate=count_rate_i4,count_max=count_max_i4)
  print *, count_max_i4, count_rate_i4
  call system_clock (count_rate=count_rate_r4,count_max=count_max_i4)
  print *, count_max_i4, count_rate_r4
  print *
  call system_clock (count_max=count_max_i8)
  call system_clock (count_rate=count_rate_i8)
  call system_clock (count_rate=count_rate_r8)
  print *, count_max_i8, count_rate_i8, count_rate_r8
  call system_clock (count_rate=count_rate_i8,count_max=count_max_i8)
  print *, count_max_i8, count_rate_i8
  call system_clock (count_rate=count_rate_r8,count_max=count_max_i8)
  print *, count_max_i8, count_rate_r8
  print *
  call system_clock (count_rate=count_rate_i4,count_max=count_max_i8)
  print *, count_max_i8, count_rate_i4
  call system_clock (count_rate=count_rate_r4,count_max=count_max_i8)
  print *, count_max_i8, count_rate_r4
  print *
  call system_clock (count_rate=count_rate_i8,count_max=count_max_i4)
  print *, count_max_i4, count_rate_i8
  call system_clock (count_rate=count_rate_r8,count_max=count_max_i4)
  print *, count_max_i4, count_rate_r8
end

it produces:
  2147483647        1000   1000.00000    
  2147483647        1000
  2147483647   1000.00000    

  9223372036854775807              1000000   1000000.0000000000     
  9223372036854775807              1000000
  9223372036854775807   1000000.0000000000     

  9223372036854775807        1000
  9223372036854775807   1000.00000    

  2147483647              1000000
  2147483647   1000000.0000000000     

:-)

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #12 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Harald Anlauf from comment #10)
> Partial patch to handle proposed behavior of system_clock

Thanks for the partial patch. Some quick critique:
  - it doesn't handle mixed argument kinds (you said you don't care, but others
might)
  - it creates multiple calls to the library (performance issue, especially on
a timing routine)
  - I disagree with the logic for COUNT_RATE: we don't care what kind it is,
because any "decent" kind (32-bit int, 64-bit int, or any real kind) is large
enough to store the value.

We've got to define an implementation that works for everyone, and for all
corner cases. Then we can implement it. I've indicated on comp.lang.fortran
what I think is the best strategy:

  a) if any integer kind is 1 or 2, we emit a warning at compile-time and
behave as if no clock is available
  b) for COUNT_RATE, we treat a real as a "wide" int (64-bit or more)
  c) if the kinds of present arguments don't match, issue a compile-time
warning
  d) if all present args are wide, go for high-res, otherwise go for low-res.

How does that sound?


I will have some time to deal with this in a week.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #13 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Francois-Xavier Coudert from comment #12)
> (In reply to Harald Anlauf from comment #10)
> > Partial patch to handle proposed behavior of system_clock
> 
> Thanks for the partial patch. Some quick critique:
>   - it doesn't handle mixed argument kinds (you said you don't care, but
> others might)

I originally said that I wouldn't care, but after playing with other
compilers I reconsidered (see comment #7).

Actually the patch does handle it in the most simple way: all arguments
are independent.  See the test case in comment #11.  (My tentative patch
did not remove code that compares the kinds of the arguments etc.)

>   - it creates multiple calls to the library (performance issue, especially
> on a timing routine)

True.  But as long as only COUNT is present, there's no performance
difference to the old behavior.  That's how I use SYSTEM_CLOCK.

Optimizations for multiple present arguments are possible but require
lengthy coding.  I haven't looked at the library code, but calls to
determine count_max and count_rate should be extremely cheap.

>   - I disagree with the logic for COUNT_RATE: we don't care what kind it is,
> because any "decent" kind (32-bit int, 64-bit int, or any real kind) is
> large enough to store the value.

Probably true for all present and future gfortran implementations.
(With crayftn I have seen COUNT_RATE = cpu clockspeed for integer(8),
and 2.6 GHz is too large for 32 bit...).

Nevertheless, I'd prefer the same COUNT_RATE for default integer(4)
and default real(4), and similarly for integer(>=8) and real(>=8).

> We've got to define an implementation that works for everyone, and for all
> corner cases. Then we can implement it. I've indicated on comp.lang.fortran
> what I think is the best strategy:
> 
>   a) if any integer kind is 1 or 2, we emit a warning at compile-time and
> behave as if no clock is available

OK.  This is better than a timer with ridiculously low count_rate/_max.

>   b) for COUNT_RATE, we treat a real as a "wide" int (64-bit or more)

I'd prefer real(4) ~ integer(4), see above reasoning.

>   c) if the kinds of present arguments don't match, issue a compile-time
> warning

OK.  (No other compiler I've met complains here, but it's good to warn
users to expect trouble).

>   d) if all present args are wide, go for high-res, otherwise go for low-res.

That's up to you.  But I'd prefer to stay consistent with what other
compilers do.  (I didn't post the crayftn behavior, but it is sort
of similar to what Intel does, except for somewhat odd count_rates.)

> How does that sound?
> 
> 
> I will have some time to deal with this in a week.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
                 CC|                            |jakub at gcc dot gnu.org

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #14 from Harald Anlauf <anlauf at gmx dot de> ---
Created attachment 34488
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34488&action=edit
Updated partial patch

This modified partial patch addresses the potential performance issue by
calling the _4 and/or _8 versions of the library functions when needed,
combining multiple arguments of the same kind as in the original code
version.

Still not done: handling of kind=1,2 arguments.  I need a hint how
to generate code to set these arguments to those explicit values
described by the standard.

Harald

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu.org

--- Comment #15 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I was looking at this one just the other day.  There are three PRs related to
SYSTEM_CLOCK that we should attempt to close. I will look some more tonight.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #16 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Jerry DeLisle from comment #15)
> I was looking at this one just the other day.  There are three PRs related
> to SYSTEM_CLOCK that we should attempt to close. I will look some more
> tonight.

What's missing:

- Support for integer(1/2).  The standard requires (13.7.167):

COUNT (...). It is assigned a processor-dependent value based on the
value of the processor clock, or −HUGE (COUNT) if there is no clock.

COUNT RATE (...) It is assigned a processor-dependent approximation to
the number of processor clock counts per second, or zero if there is
no clock.

COUNT MAX (...) It is assigned the maximum value that COUNT can have,
or zero if there is no clock.

  We might treat any integer(1/2) argument as there were no corresponding
  clock.  I just don't know how to create the corresponding code to
  set the result variable appropriately.

- The compile-time warning FX mentioned in comment #12.  We could
  split this one off as an enhancement.

- A consensus what shall happen for arguments of mixed kinds.
>From gcc-bugs-return-477234-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 13 22:35:56 2015
Return-Path: <gcc-bugs-return-477234-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31467 invoked by alias); 13 Feb 2015 22:35:56 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 31399 invoked by uid 48); 13 Feb 2015 22:35:53 -0000
From: "howarth at bromo dot med.uc.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/62132] [5 Regression] FAIL: c-c++-common/asan/misalign-[12].c after r213807 on x86_64-apple-darwin13 with -m32
Date: Fri, 13 Feb 2015 22:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: howarth at bromo dot med.uc.edu
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-62132-4-2ytWChmcjJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62132-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62132-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg01567.txt.bz2
Content-length: 1109

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62132

howarth at bromo dot med.uc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth at bromo dot med.uc.edu

--- Comment #22 from howarth at bromo dot med.uc.edu ---
(In reply to Francois-Xavier Coudert from comment #18)
> Author: fxcoudert
> Date: Wed Nov 19 14:32:09 2014
> New Revision: 217779
> 
> URL: https://gcc.gnu.org/viewcvs?rev=217779&root=gcc&view=rev
> Log:
> Fixing the mess I did with the two previous commits. Sorry!
> 
> 	PR sanitizer/62132
> 	* c-c++-common/asan/misalign-1.c: Pass -fno-omit-frame-pointer on
> 	darwin, adjust dg-output.
> 	* c-c++-common/asan/misalign-2.c: Likewise.
> 
> Modified:
>     trunk/gcc/testsuite/c-c++-common/asan/misalign-1.c
>     trunk/gcc/testsuite/c-c++-common/asan/misalign-2.c

Shouldn't this net change be backported to gcc-4_9-branch for 4.9.3? We seem to
need it there...

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01535.html
>From gcc-bugs-return-477235-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 13 22:59:38 2015
Return-Path: <gcc-bugs-return-477235-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5435 invoked by alias); 13 Feb 2015 22:59:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5410 invoked by uid 48); 13 Feb 2015 22:59:34 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/65060] New: [5 Regression] r220696 breaks bootstrap on Linux/x86-32
Date: Fri, 13 Feb 2015 22:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-65060-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg01568.txt.bz2
Content-length: 3008

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide060

            Bug ID: 65060
           Summary: [5 Regression] r220696 breaks bootstrap on
                    Linux/x86-32
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
                CC: law at redhat dot com

On Linux/x86-32, r220696 gave

make[6]: Leaving directory `/export/gnu/import/git/gcc-test-ia32corei7/bld'
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/gimple-fold.o differs
gcc/tree-ssa-pre.o differs
gcc/omp-low.o differs
gcc/i386.o differs
gcc/tree-ssa-sccvn.o differs
gcc/tree-ssa-threadupdate.o differs
gcc/tree-ssa-uninit.o differs
gcc/cfgexpand.o differs
gcc/objc/objc-act.o differs
gcc/tree-ssa-operands.o differs
gcc/sel-sched-ir.o differs
gcc/tree-into-ssa.o differs
gcc/java/expr.o differs
gcc/ree.o differs
gcc/sanopt.o differs
gcc/sese.o differs
gcc/cfgrtl.o differs
gcc/reg-stack.o differs
gcc/ira-emit.o differs
gcc/tree-ssa-loop-im.o differs
gcc/tree-emutls.o differs
gcc/tree-ssa-reassoc.o differs
gcc/c/c-parser.o differs
gcc/c/c-typeck.o differs
gcc/gimplify.o differs
gcc/tree-ssa-loop-ivopts.o differs
gcc/tree-if-conv.o differs
gcc/lto-cgraph.o differs
gcc/cfgloopanal.o differs
gcc/tree-cfgcleanup.o differs
gcc/tree-outof-ssa.o differs
gcc/ipa-cp.o differs
gcc/lower-subreg.o differs
gcc/tree-ssa-loop-unswitch.o differs
gcc/dojump.o differs
gcc/ipa-polymorphic-call.o differs
gcc/function.o differs
gcc/ubsan.o differs
gcc/cfganal.o differs
gcc/tree-ssa-live.o differs
gcc/fwprop.o differs
gcc/tree-complex.o differs
gcc/tree-vect-stmts.o differs
gcc/tree-ssa-structalias.o differs
gcc/build/genautomata.o differs
gcc/build/genpreds.o differs
gcc/build/genmatch.o differs
gcc/final.o differs
gcc/ipa-utils.o differs
gcc/tree-vect-slp.o differs
gcc/rtlanal.o differs
gcc/lto/lto-partition.o differs
gcc/c-family/array-notation-common.o differs
gcc/ipa-inline.o differs
gcc/tree-loop-distribution.o differs
gcc/tree-ssa-ccp.o differs
gcc/wide-int.o differs
gcc/bb-reorder.o differs
gcc/tree-object-size.o differs
gcc/tree-ssa-loop-niter.o differs
gcc/tree-predcom.o differs
gcc/tree-ssa-ter.o differs
gcc/cp/init.o differs
gcc/cp/decl.o differs
gcc/cp/pt.o differs
gcc/cp/class.o differs
gcc/cp/name-lookup.o differs
gcc/cp/error.o differs
gcc/cp/vtable-class-hierarchy.o differs
gcc/tree-ssa-loop-ch.o differs
gcc/tree-ssa-threadedge.o differs
gcc/ipa-icf.o differs
gcc/tree-inline.o differs
libcpp/macro.o differs
make[5]: *** [compare] Error 1

when configured with

--with-arch=corei7 --with-cpu=corei7 --prefix=/usr/5.0.0 --enable-clocale=gnu
--with-system-zlib --enable-shared --with-demangler-in-ld i686-linux
--with-fpmath=sse --enable-languages=c,c++,fortran,java,lto,objc

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #17 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Created attachment 34765
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34765&action=edit
Handle KIND=1 and KIND=2

This updated patch gives a proposed way to handle KIND=1 and KIND=2.  This is
done by adding a new KIND=2 function in the library that accepts a fourth
argument used to flag when a KIND=1 for any of the arguments.

For KIND=1 rate is set to 1, max is set to 127, count rolls over after 127 to
0.

For KIND=2 rate is set to 1000, max is 32767

THis is still in testing. I think we can handle the mixed integer and real
situations using this fourth argument with different values to designate real
KINDs that are encountered.  You may notice that if we mix KIND=2 count and
limit, with REAL(8) rate, the rate shows way too large.

I am working on the mixed integer/real part. I have attached so others can
review and comment.  I will keep going with the mixed real/integer cases if no
objections.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #18 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Created attachment 34771
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34771&action=edit
A test case

Current results with attached test case.

$ ./a.out 
KIND=1: 34  1  127
KIND=1: 34  1.00000000  127
 -----------------------------------------------------------
KIND=2: 17774  1000  32767
KIND=2: 17774  1000.00000  32767
 -----------------------------------------------------------
KIND=4: 22758766  1000  2147483647
KIND=4: 22758766  1000.00000  2147483647
 -----------------------------------------------------------
KIND=8: 22758766833088  1000000000  9223372036854775807
KIND=8: 22758766851741  1000000000.0000000  9223372036854775807
 -----------------------------------------------------------
KIND=10: 22758766876478  1000000000  9223372036854775807
KIND=10: 22758766894351  1000000000.00000000000  9223372036854775807
 -----------------------------------------------------------
KIND=16: 22758766919976  1000000000  9223372036854775807
KIND=16: 22758766933064  1000000000.00000000000000000000000000 
9223372036854775807

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #19 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Jerry DeLisle from comment #17)
> Created attachment 34765 [details]
> Handle KIND=1 and KIND=2

Jerry,

I applied your patch on top of rev. 220730.
Unfortunately it ICEs on the following simple code:

  integer(4) :: count_rate_i4
  call system_clock (count_rate=count_rate_i4)
end

gfcbug128x.f90:2:0:

   call system_clock (count_rate=count_rate_i4)
 1
internal compiler error: Segmentation fault
0x882b340 crash_signal
        ../../trunk/gcc/toplev.c:383
0x834b500 conv_intrinsic_system_clock
        ../../trunk/gcc/fortran/trans-intrinsic.c:9479
0x834b500 gfc_conv_intrinsic_subroutine(gfc_code*)
        ../../trunk/gcc/fortran/trans-intrinsic.c:9529
0x82ebeba trans_code
        ../../trunk/gcc/fortran/trans.c:1718
0x831c353 gfc_generate_function_code(gfc_namespace*)
        ../../trunk/gcc/fortran/trans-decl.c:5850
0x82a461b translate_all_program_units
        ../../trunk/gcc/fortran/parse.c:5341
0x82a461b gfc_parse_file()
        ../../trunk/gcc/fortran/parse.c:5538
0x82e6613 gfc_be_parse_file
        ../../trunk/gcc/fortran/f95-lang.c:228

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #20 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Harald Anlauf from comment #19)
> (In reply to Jerry DeLisle from comment #17)
> > Created attachment 34765 [details]
> > Handle KIND=1 and KIND=2
> 
> Jerry,
> 
> I applied your patch on top of rev. 220730.
> Unfortunately it ICEs on the following simple code:

Yes, that is an old version.  I have changed it quite a lot since that patch.

This has been evolving quickly since yesterday. I will not be able to continue
until possibly tonight or tomorrow.  I posted the results in Comment#18 so that
you can see the end result.  I will obsolete the patches.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #21 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Created attachment 34798
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34798&action=edit
Full Patch

This patch attempts to do it all. I have not tested the mingw/cygwin side of
it.

Any testing/comments welcome

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #22 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Jerry DeLisle from comment #21)
> Created attachment 34798 [details]
> Full Patch
> 
> This patch attempts to do it all. I have not tested the mingw/cygwin side of
> it.
> 
> Any testing/comments welcome

Jerry,

I did some simple test and found the following:

Cases with a single argument present:

% cat gfcbug128f.f90
program gfcbug128e
  integer(1) :: count_rate_i1, count_max_i1, count_i1
  integer(2) :: count_rate_i2, count_max_i2, count_i2
  integer(4) :: count_rate_i4, count_max_i4, count_i4
  integer(8) :: count_rate_i8, count_max_i8, count_i8
  real(4)    :: count_rate_r4 = 0
  real(8)    :: count_rate_r8 = 0

  print *, "KIND=1:"
  call system_clock (count=count_i1)
  print *, "count     =",count_i1
  call system_clock (count_max=count_max_i1)
  print *, "count_max =", count_max_i1
  call system_clock (count_rate=count_rate_i1)
  print *, "count_rate=", count_rate_i1
  print *
  print *, "KIND=2:"
  call system_clock (count=count_i2)
  print *, "count     =",count_i2
  call system_clock (count_max=count_max_i2)
  print *, "count_max =", count_max_i2
  call system_clock (count_rate=count_rate_i2)
  print *, "count_rate=", count_rate_i2
  print *
  print *, "KIND=4:"
  call system_clock (count=count_i4)
  print *, "count     =",count_i4
  call system_clock (count_max=count_max_i4)
  print *, "count_max =", count_max_i4
  call system_clock (count_rate=count_rate_i4)
  print *, "count_rate=", count_rate_i4
  call system_clock (count_rate=count_rate_r4)
  print *, "count_rate_real=", count_rate_r4
  print *
  print *, "KIND=8:"
  call system_clock (count=count_i8)
  print *, "count     =",count_i8
  call system_clock (count_max=count_max_i8)
  print *, "count_max =", count_max_i8
  call system_clock (count_rate=count_rate_i8)
  print *, "count_rate=", count_rate_i8
  call system_clock (count_rate=count_rate_r8)
  print *, "count_rate_real=", count_rate_r8
end

Test output:
 KIND=1:
 count     =  116
 count_max =  127
 count_rate=    1

 KIND=2:
 count     =  27083
 count_max =  32767
 count_rate=   1000

 KIND=4:
 count     =   507374028
 count_max =  2147483647
 count_rate=        1000
 count_rate_real=   1000.00000    

 KIND=8:
 count     =     1424289032652253
 count_max =  9223372036854775807
 count_rate=              1000000
 count_rate_real=   1000000.0000000000     

Looks reasonable so far, assuming it behaves as (to be) documented.

Further tests with two arguments:

% cat gfcbug128g.f90
program gfcbug128g
  integer(1) :: count_rate_i1, count_max_i1, count_i1
  integer(2) :: count_rate_i2, count_max_i2, count_i2
  integer(4) :: count_rate_i4, count_max_i4, count_i4
  integer(8) :: count_rate_i8, count_max_i8, count_i8
  real(4)    :: count_rate_r4 = 0
  real(8)    :: count_rate_r8 = 0

  call system_clock (count=count_i1,count_max=count_max_i2)
  print *, "count(1),count_max(2) =",count_i1, count_max_i2
  call system_clock (count=count_i2,count_max=count_max_i1)
  print *, "count(2),count_max(1) =",count_i2, count_max_i1
  call system_clock (count=count_i4,count_max=count_max_i2)
  print *, "count(4),count_max(2) =",count_i4, count_max_i2
  call system_clock (count=count_i2,count_max=count_max_i4)
  print *, "count(2),count_max(4) =",count_i2, count_max_i4
  call system_clock (count=count_i4,count_max=count_max_i8)
  print *, "count(4),count_max(8) =",count_i4, count_max_i8
  call system_clock (count=count_i8,count_max=count_max_i4)
  print *, "count(8),count_max(4) =",count_i8, count_max_i4
  call system_clock (count=count_i1,count_max=count_max_i8)
  print *, "count(1),count_max(8) =",count_i1, count_max_i8
  call system_clock (count=count_i8,count_max=count_max_i1)
  print *, "count(8),count_max(1) =",count_i8, count_max_i1

  call system_clock (count_rate=count_rate_i1,count_max=count_max_i2)
  print *, "count_rate(1),count_max(2) =",count_rate_i1, count_max_i2
  call system_clock (count_rate=count_rate_i2,count_max=count_max_i1)
  print *, "count_rate(2),count_max(1) =",count_rate_i2, count_max_i1
  call system_clock (count_rate=count_rate_i4,count_max=count_max_i2)
  print *, "count_rate(4),count_max(2) =",count_rate_i4, count_max_i2
  call system_clock (count_rate=count_rate_i2,count_max=count_max_i4)
  print *, "count_rate(2),count_max(4) =",count_rate_i2, count_max_i4
  call system_clock (count_rate=count_rate_i4,count_max=count_max_i8)
  print *, "count_rate(4),count_max(8) =",count_rate_i4, count_max_i8
  call system_clock (count_rate=count_rate_i8,count_max=count_max_i4)
  print *, "count_rate(8),count_max(4) =",count_rate_i8, count_max_i4
  call system_clock (count_rate=count_rate_i1,count_max=count_max_i8)
  print *, "count_rate(1),count_max(8) =",count_rate_i1, count_max_i8
  call system_clock (count_rate=count_rate_i8,count_max=count_max_i1)
  print *, "count_rate(8),count_max(1) =",count_rate_i8, count_max_i1
end

Test output:

 count(1),count_max(2) =   11    127
 count(2),count_max(1) =     11  127
 count(4),count_max(2) =        5991  32767
 count(2),count_max(4) =   5991       32767
 count(4),count_max(8) =   507909991           2147483647
 count(8),count_max(4) =            507909991  2147483647
 count(1),count_max(8) =   11                  127
 count(8),count_max(1) =                   11  127
 count_rate(1),count_max(2) =    1    127
 count_rate(2),count_max(1) =      1  127
 count_rate(4),count_max(2) =        1000  32767
 count_rate(2),count_max(4) =   1000       32767
 count_rate(4),count_max(8) =        1000           2147483647
 count_rate(8),count_max(4) =                 1000  2147483647
 count_rate(1),count_max(8) =    1                  127
 count_rate(8),count_max(1) =                    0  127

OK, but the last line looks strange: lacking documentation,
I'd expect the rate to be 1, not 0.  (Not that I'd use that
in real code...).

Cheers,
Harald

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #23 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Jerry DeLisle from comment #21)
> Created attachment 34798 [details]
> Full Patch
> 
> This patch attempts to do it all. I have not tested the mingw/cygwin side of
> it.
> 
> Any testing/comments welcome

Jerry,

I forgot to mention that the interface of _gfortran_system_clock_{4,8}
changed w.r.t. gcc 4.9 by adding the fourth argument.  One needs to make
sure that nobody links an object generated by the newer compiler against
a previous library.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #25 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Jerry DeLisle from comment #24)
> (In reply to Harald Anlauf from comment #22)
> >  count_rate(8),count_max(1) =                    0  127
> > 
> > OK, but the last line looks strange: lacking documentation,
> > I'd expect the rate to be 1, not 0.  (Not that I'd use that
> > in real code...).
> 
> Yes, tha last one is wrong. I will look into it.
> 

I found the problem and have it fixed.  I am traveling today so will not be
able to upload a patch until tomorrow or the next day.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #34798|0                           |1
        is obsolete|                            |

--- Comment #26 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Created attachment 34819
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34819&action=edit
Updated full patch.

Revised to fix error shown in Comment #22

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #27 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Jerry DeLisle from comment #26)
> Created attachment 34819 [details]
> Updated full patch.
> 
> Revised to fix error shown in Comment #22

The new patch does indeed fix the error in comment #22,
and it also works for me (e.g. for the original issue).

Thanks,
Harald

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #28 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Bootstrapping with the patch in comment 26 fails with

/opt/gcc/build_w/./prev-gcc/xg++ -B/opt/gcc/build_w/./prev-gcc/
-B/opt/gcc/gcc4.10w/x86_64-apple-darwin14.1.0/bin/ -nostdinc++
-B/opt/gcc/build_w/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/src/.libs
-B/opt/gcc/build_w/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/libsupc++/.libs 
-I/opt/gcc/build_w/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/include/x86_64-apple-darwin14.1.0
 -I/opt/gcc/build_w/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/include 
-I/opt/gcc/work/libstdc++-v3/libsupc++
-L/opt/gcc/build_w/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/src/.libs
-L/opt/gcc/build_w/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/libsupc++/.libs
-c  -DIN_GCC_FRONTEND -g -O2  -gtoggle -DIN_GCC    -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -I. -Ifortran -I../../work/gcc -I../../work/gcc/fortran
-I../../work/gcc/../include -I./../intl -I../../work/gcc/../libcpp/include
-I/opt/mp-new/include  -I../../work/gcc/../libdecnumber
-I../../work/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../work/gcc/../libbacktrace -I/opt/mp-new/include  -o
fortran/trans-intrinsic.o -MT fortran/trans-intrinsic.o -MMD -MP -MF
fortran/.deps/trans-intrinsic.TPo ../../work/gcc/fortran/trans-intrinsic.c
../../work/gcc/fortran/trans-intrinsic.c: In function 'tree_node*
conv_intrinsic_system_clock(gfc_code*)':
../../work/gcc/fortran/trans-intrinsic.c:2675:8: error: variable 'type' set but
not used [-Werror=unused-but-set-variable]
   tree type, tmp;
        ^
cc1plus: all warnings being treated as errors

../../work/gcc/fortran/trans-intrinsic.c: In function 'tree_node*
conv_intrinsic_system_clock(gfc_code*)':
../../work/gcc/fortran/trans-intrinsic.c:2676:7: error: variable 'kind' set but
not used [-Werror=unused-but-set-variable]
   int kind, least, most;
       ^
cc1plus: all warnings being treated as errors

The following patch (code commented) fixes bootstrap

--- ../_clean/gcc/fortran/trans-intrinsic.c    2015-01-17 21:48:17.000000000
+0100
+++ gcc/fortran/trans-intrinsic.c    2015-02-22 11:48:14.000000000 +0100
@@ -2670,9 +2670,10 @@ conv_intrinsic_system_clock (gfc_code *c
 {
   stmtblock_t block;
   gfc_se count_se, count_rate_se, count_max_se;
-  tree arg1 = NULL_TREE, arg2 = NULL_TREE, arg3 = NULL_TREE;
-  tree type, tmp;
-  int kind;
+  tree arg1 = NULL_TREE, arg2 = NULL_TREE, arg3 = NULL_TREE,
+          arg4 = NULL_TREE;
+  tree tmp;
+  int least, most;

   gfc_expr *count = code->ext.actual->expr;
   gfc_expr *count_rate = code->ext.actual->next->expr;
@@ -2680,12 +2681,12 @@ conv_intrinsic_system_clock (gfc_code *c

   /* The INTEGER(8) version has higher precision, it is used if both COUNT
      and COUNT_MAX can hold 64-bit values, or are absent.  */
-  if ((!count || count->ts.kind >= 8)
+  /* if ((!count || count->ts.kind >= 8)
       && (!count_max || count_max->ts.kind >= 8))
     kind = 8;
   else
-    kind = gfc_default_integer_kind;
-  type = gfc_get_int_type (kind);
+    kind = gfc_default_integer_kind; */
+  /* type = gfc_get_int_type (kind); */

   /* Evaluate our arguments.  */
   if (count)

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #29 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Clean patch to avoid the errors: variable '*' set but not used

--- ../_clean/gcc/fortran/trans-intrinsic.c    2015-01-17 21:48:17.000000000
+0100
+++ gcc/fortran/trans-intrinsic.c    2015-02-22 13:02:40.000000000 +0100
@@ -2670,23 +2670,15 @@ conv_intrinsic_system_clock (gfc_code *c
 {
   stmtblock_t block;
   gfc_se count_se, count_rate_se, count_max_se;
-  tree arg1 = NULL_TREE, arg2 = NULL_TREE, arg3 = NULL_TREE;
-  tree type, tmp;
-  int kind;
+  tree arg1 = NULL_TREE, arg2 = NULL_TREE, arg3 = NULL_TREE,
+          arg4 = NULL_TREE;
+  tree tmp;
+  int least, most;

   gfc_expr *count = code->ext.actual->expr;
   gfc_expr *count_rate = code->ext.actual->next->expr;
   gfc_expr *count_max = code->ext.actual->next->next->expr;

-  /* The INTEGER(8) version has higher precision, it is used if both COUNT
-     and COUNT_MAX can hold 64-bit values, or are absent.  */
-  if ((!count || count->ts.kind >= 8)
-      && (!count_max || count_max->ts.kind >= 8))
-    kind = 8;
-  else
-    kind = gfc_default_integer_kind;
-  type = gfc_get_int_type (kind);
-
   /* Evaluate our arguments.  */
   if (count)
     {

For the test don't forget that real(10) are not available on some platforms and
that real(16) may have different formats (I won't have access to my G5 until
the end of the coming week -> no testing on powerpc).

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #30 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #28 and #29)

Thanks for checking and I have the cleanup taken care of. I am making some
adjustments to avoid ABI issues as well.

Test case will be next.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #31 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I have generated a test case that includes all possible combinations and found
some issues with the patch related to Real (KIND 10).  I am working this now.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #32 from Harald Anlauf <anlauf at gmx dot de> ---
Jerry,

to give you some positive feedback: I'm now using your latest patch in

https://gcc.gnu.org/ml/fortran/2015-03/msg00067.html

It works for me.

Thanks,
Harald

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #33 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Tue Mar 17 01:01:54 2015
New Revision: 221471

URL: https://gcc.gnu.org/viewcvs?rev=221471&root=gcc&view=rev
Log:
2015-03-16  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR fortran/64432
    *trans-intrinisic.c (conv_intrinsic_system_clock): Check the
    smallest kind passed in user arguments and hardcode tesults for
    KIND=1 or KIND=2 to indicate no clock available.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-intrinsic.c

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #34 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Tue Mar 17 01:04:58 2015
New Revision: 221472

URL: https://gcc.gnu.org/viewcvs?rev=221472&root=gcc&view=rev
Log:
2015-03-16 Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR libgfortran/64432
    * intrinsics/system_clock.c (system_clock4, system_clock8):
    Cleanup some whitespace.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/intrinsics/system_clock.c

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #35 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Tue Mar 17 01:22:12 2015
New Revision: 221473

URL: https://gcc.gnu.org/viewcvs?rev=221473&root=gcc&view=rev
Log:
2015-03-16 Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR fortran/64432
    * gfortran.dg/system_clock_3.f08: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/system_clock_3.f08
Modified:
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #36 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Jerry DeLisle from comment #35)
> Author: jvdelisle
> Date: Tue Mar 17 01:22:12 2015
> New Revision: 221473
> 
> URL: https://gcc.gnu.org/viewcvs?rev=221473&root=gcc&view=rev
> Log:
> 2015-03-16 Jerry DeLisle  <jvdelisle@gcc.gnu.org>
> 
> 	PR fortran/64432
> 	* gfortran.dg/system_clock_3.f08: New test.
> 
> Added:
>     trunk/gcc/testsuite/gfortran.dg/system_clock_3.f08
> Modified:
>     trunk/gcc/testsuite/ChangeLog

Jerry,

are you sure that .and.ing the conditions in the testcase is correct,
or shouldn't they rather be .or.ed?
>From gcc-bugs-return-480579-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 17 21:27:55 2015
Return-Path: <gcc-bugs-return-480579-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 99662 invoked by alias); 17 Mar 2015 21:27:55 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 99629 invoked by uid 48); 17 Mar 2015 21:27:51 -0000
From: "jens.gustedt at inria dot fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/65455] New: typeof _Atomic fails
Date: Tue, 17 Mar 2015 21:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jens.gustedt at inria dot fr
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-65455-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg01723.txt.bz2
Content-length: 695

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide455

            Bug ID: 65455
           Summary: typeof _Atomic fails
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jens.gustedt at inria dot fr

The following declarations

_Atomic int a;
__typeof__(a) a;

result in compile errors:

> typeof_atomic.c:2:15: error: conflicting type qualifiers for 'a'
> __typeof__(a) a;
>               ^
> typeof_atomic.c:1:13: note: previous declaration of 'a' was here
> _Atomic int a;


This could be related to bug #65345.

Jens

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #37 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Harald Anlauf from comment #36)
--snip---> 
> are you sure that .and.ing the conditions in the testcase is correct,
> or shouldn't they rather be .or.ed?

Oh of course. Thanks Harald.  I will set it right

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #38 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Wed Mar 18 01:47:12 2015
New Revision: 221482

URL: https://gcc.gnu.org/viewcvs?rev=221482&root=gcc&view=rev
Log:
2015-03-17 Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR fortran/64432
    * gfortran.dg/system_clock_3.f08: Adjust test.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/system_clock_3.f08

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #39 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Fixed on trunk. Thanks all for testing and suggestions.