* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
@ 2014-12-29 11:14 ` anlauf at gmx dot de
2014-12-29 11:18 ` anlauf at gmx dot de
` (38 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2014-12-29 11:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
2014-12-29 11:14 ` [Bug fortran/64432] " anlauf at gmx dot de
@ 2014-12-29 11:18 ` anlauf at gmx dot de
2014-12-29 11:20 ` janus at gcc dot gnu.org
` (37 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2014-12-29 11:18 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
2014-12-29 11:14 ` [Bug fortran/64432] " anlauf at gmx dot de
2014-12-29 11:18 ` anlauf at gmx dot de
@ 2014-12-29 11:20 ` janus at gcc dot gnu.org
2014-12-29 11:21 ` janus at gcc dot gnu.org
` (36 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: janus at gcc dot gnu.org @ 2014-12-29 11:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (2 preceding siblings ...)
2014-12-29 11:20 ` janus at gcc dot gnu.org
@ 2014-12-29 11:21 ` janus at gcc dot gnu.org
2014-12-29 14:13 ` fxcoudert at gcc dot gnu.org
` (35 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: janus at gcc dot gnu.org @ 2014-12-29 11:21 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (3 preceding siblings ...)
2014-12-29 11:21 ` janus at gcc dot gnu.org
@ 2014-12-29 14:13 ` fxcoudert at gcc dot gnu.org
2014-12-29 15:04 ` anlauf at gmx dot de
` (34 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2014-12-29 14:13 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (4 preceding siblings ...)
2014-12-29 14:13 ` fxcoudert at gcc dot gnu.org
@ 2014-12-29 15:04 ` anlauf at gmx dot de
2014-12-29 15:23 ` anlauf at gmx dot de
` (33 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2014-12-29 15:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (5 preceding siblings ...)
2014-12-29 15:04 ` anlauf at gmx dot de
@ 2014-12-29 15:23 ` anlauf at gmx dot de
2014-12-30 9:48 ` Joost.VandeVondele at mat dot ethz.ch
` (32 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2014-12-29 15:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (6 preceding siblings ...)
2014-12-29 15:23 ` anlauf at gmx dot de
@ 2014-12-30 9:48 ` Joost.VandeVondele at mat dot ethz.ch
2014-12-30 10:05 ` Joost.VandeVondele at mat dot ethz.ch
` (31 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2014-12-30 9:48 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (7 preceding siblings ...)
2014-12-30 9:48 ` Joost.VandeVondele at mat dot ethz.ch
@ 2014-12-30 10:05 ` Joost.VandeVondele at mat dot ethz.ch
2015-01-04 21:47 ` anlauf at gmx dot de
` (30 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2014-12-30 10:05 UTC (permalink / raw)
To: gcc-bugs
[-- 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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (8 preceding siblings ...)
2014-12-30 10:05 ` Joost.VandeVondele at mat dot ethz.ch
@ 2015-01-04 21:47 ` anlauf at gmx dot de
2015-01-04 21:56 ` anlauf at gmx dot de
` (29 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2015-01-04 21:47 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (9 preceding siblings ...)
2015-01-04 21:47 ` anlauf at gmx dot de
@ 2015-01-04 21:56 ` anlauf at gmx dot de
2015-01-04 22:04 ` fxcoudert at gcc dot gnu.org
` (28 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2015-01-04 21:56 UTC (permalink / raw)
To: gcc-bugs
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
:-)
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (10 preceding siblings ...)
2015-01-04 21:56 ` anlauf at gmx dot de
@ 2015-01-04 22:04 ` fxcoudert at gcc dot gnu.org
2015-01-04 22:53 ` anlauf at gmx dot de
` (27 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2015-01-04 22:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (11 preceding siblings ...)
2015-01-04 22:04 ` fxcoudert at gcc dot gnu.org
@ 2015-01-04 22:53 ` anlauf at gmx dot de
2015-01-09 11:20 ` rguenth at gcc dot gnu.org
` (26 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2015-01-04 22:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (12 preceding siblings ...)
2015-01-04 22:53 ` anlauf at gmx dot de
@ 2015-01-09 11:20 ` rguenth at gcc dot gnu.org
2015-01-09 14:12 ` jakub at gcc dot gnu.org
` (25 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-01-09 11:20 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (13 preceding siblings ...)
2015-01-09 11:20 ` rguenth at gcc dot gnu.org
@ 2015-01-09 14:12 ` jakub at gcc dot gnu.org
2015-01-19 20:49 ` anlauf at gmx dot de
` (24 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-01-09 14:12 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (14 preceding siblings ...)
2015-01-09 14:12 ` jakub at gcc dot gnu.org
@ 2015-01-19 20:49 ` anlauf at gmx dot de
2015-02-11 21:20 ` jvdelisle at gcc dot gnu.org
` (23 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2015-01-19 20:49 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (15 preceding siblings ...)
2015-01-19 20:49 ` anlauf at gmx dot de
@ 2015-02-11 21:20 ` jvdelisle at gcc dot gnu.org
2015-02-13 22:31 ` anlauf at gmx dot de
` (22 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-02-11 21:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (16 preceding siblings ...)
2015-02-11 21:20 ` jvdelisle at gcc dot gnu.org
@ 2015-02-13 22:31 ` anlauf at gmx dot de
2015-02-15 4:59 ` jvdelisle at gcc dot gnu.org
` (21 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2015-02-13 22:31 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (17 preceding siblings ...)
2015-02-13 22:31 ` anlauf at gmx dot de
@ 2015-02-15 4:59 ` jvdelisle at gcc dot gnu.org
2015-02-16 3:14 ` jvdelisle at gcc dot gnu.org
` (20 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-02-15 4:59 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (18 preceding siblings ...)
2015-02-15 4:59 ` jvdelisle at gcc dot gnu.org
@ 2015-02-16 3:14 ` jvdelisle at gcc dot gnu.org
2015-02-16 12:04 ` anlauf at gmx dot de
` (19 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-02-16 3:14 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (19 preceding siblings ...)
2015-02-16 3:14 ` jvdelisle at gcc dot gnu.org
@ 2015-02-16 12:04 ` anlauf at gmx dot de
2015-02-16 20:04 ` jvdelisle at gcc dot gnu.org
` (18 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2015-02-16 12:04 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (20 preceding siblings ...)
2015-02-16 12:04 ` anlauf at gmx dot de
@ 2015-02-16 20:04 ` jvdelisle at gcc dot gnu.org
2015-02-18 4:21 ` jvdelisle at gcc dot gnu.org
` (17 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-02-16 20:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (21 preceding siblings ...)
2015-02-16 20:04 ` jvdelisle at gcc dot gnu.org
@ 2015-02-18 4:21 ` jvdelisle at gcc dot gnu.org
2015-02-18 20:04 ` anlauf at gmx dot de
` (16 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-02-18 4:21 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (22 preceding siblings ...)
2015-02-18 4:21 ` jvdelisle at gcc dot gnu.org
@ 2015-02-18 20:04 ` anlauf at gmx dot de
2015-02-18 20:12 ` anlauf at gmx dot de
` (15 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2015-02-18 20:04 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (23 preceding siblings ...)
2015-02-18 20:04 ` anlauf at gmx dot de
@ 2015-02-18 20:12 ` anlauf at gmx dot de
2015-02-19 16:32 ` jvdelisle at gcc dot gnu.org
` (14 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2015-02-18 20:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (24 preceding siblings ...)
2015-02-18 20:12 ` anlauf at gmx dot de
@ 2015-02-19 16:32 ` jvdelisle at gcc dot gnu.org
2015-02-20 17:11 ` jvdelisle at gcc dot gnu.org
` (13 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-02-19 16:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (25 preceding siblings ...)
2015-02-19 16:32 ` jvdelisle at gcc dot gnu.org
@ 2015-02-20 17:11 ` jvdelisle at gcc dot gnu.org
2015-02-20 22:14 ` anlauf at gmx dot de
` (12 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-02-20 17:11 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (26 preceding siblings ...)
2015-02-20 17:11 ` jvdelisle at gcc dot gnu.org
@ 2015-02-20 22:14 ` anlauf at gmx dot de
2015-02-22 12:06 ` dominiq at lps dot ens.fr
` (11 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2015-02-20 22:14 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (27 preceding siblings ...)
2015-02-20 22:14 ` anlauf at gmx dot de
@ 2015-02-22 12:06 ` dominiq at lps dot ens.fr
2015-02-22 12:56 ` dominiq at lps dot ens.fr
` (10 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-02-22 12:06 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (28 preceding siblings ...)
2015-02-22 12:06 ` dominiq at lps dot ens.fr
@ 2015-02-22 12:56 ` dominiq at lps dot ens.fr
2015-02-22 17:11 ` jvdelisle at gcc dot gnu.org
` (9 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-02-22 12:56 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (29 preceding siblings ...)
2015-02-22 12:56 ` dominiq at lps dot ens.fr
@ 2015-02-22 17:11 ` jvdelisle at gcc dot gnu.org
2015-02-26 17:44 ` jvdelisle at gcc dot gnu.org
` (8 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-02-22 17:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (30 preceding siblings ...)
2015-02-22 17:11 ` jvdelisle at gcc dot gnu.org
@ 2015-02-26 17:44 ` jvdelisle at gcc dot gnu.org
2015-03-15 21:29 ` anlauf at gmx dot de
` (7 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-02-26 17:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (31 preceding siblings ...)
2015-02-26 17:44 ` jvdelisle at gcc dot gnu.org
@ 2015-03-15 21:29 ` anlauf at gmx dot de
2015-03-17 1:02 ` jvdelisle at gcc dot gnu.org
` (6 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2015-03-15 21:29 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (32 preceding siblings ...)
2015-03-15 21:29 ` anlauf at gmx dot de
@ 2015-03-17 1:02 ` jvdelisle at gcc dot gnu.org
2015-03-17 1:05 ` jvdelisle at gcc dot gnu.org
` (5 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-03-17 1:02 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (33 preceding siblings ...)
2015-03-17 1:02 ` jvdelisle at gcc dot gnu.org
@ 2015-03-17 1:05 ` jvdelisle at gcc dot gnu.org
2015-03-17 1:22 ` jvdelisle at gcc dot gnu.org
` (4 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-03-17 1:05 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (34 preceding siblings ...)
2015-03-17 1:05 ` jvdelisle at gcc dot gnu.org
@ 2015-03-17 1:22 ` jvdelisle at gcc dot gnu.org
2015-03-17 21:16 ` anlauf at gmx dot de
` (3 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-03-17 1:22 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (35 preceding siblings ...)
2015-03-17 1:22 ` jvdelisle at gcc dot gnu.org
@ 2015-03-17 21:16 ` anlauf at gmx dot de
2015-03-17 22:33 ` jvdelisle at gcc dot gnu.org
` (2 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: anlauf at gmx dot de @ 2015-03-17 21:16 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (36 preceding siblings ...)
2015-03-17 21:16 ` anlauf at gmx dot de
@ 2015-03-17 22:33 ` jvdelisle at gcc dot gnu.org
2015-03-18 1:47 ` jvdelisle at gcc dot gnu.org
2015-03-20 7:38 ` jvdelisle at gcc dot gnu.org
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-03-17 22:33 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (37 preceding siblings ...)
2015-03-17 22:33 ` jvdelisle at gcc dot gnu.org
@ 2015-03-18 1:47 ` jvdelisle at gcc dot gnu.org
2015-03-20 7:38 ` jvdelisle at gcc dot gnu.org
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-03-18 1:47 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
2014-12-29 10:44 [Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate anlauf at gmx dot de
` (38 preceding siblings ...)
2015-03-18 1:47 ` jvdelisle at gcc dot gnu.org
@ 2015-03-20 7:38 ` jvdelisle at gcc dot gnu.org
39 siblings, 0 replies; 41+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2015-03-20 7:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread