Re: [PATCH] PR63175 - [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1
On March 6, 2015 9:22:05 PM CET, Martin Sebor wrote: >On 03/06/2015 10:28 AM, Jeff Law wrote: >> On 03/02/15 09:28, Martin Sebor wrote: >>> On 03/02/2015 06:58 AM, Richard Biener wrote: On Fri, 27 Feb 2015, Martin Sebor wrote: >>> Given that Martin's fix to the testcase allowed it to succeed >without >>> Richi's fix for the underlying problem, is there a modification >to >>> the >>> testcase or a new testcase that would really test the >optimization? >> >> Let me work on it. > > Below is a patch with a couple of minor tweaks to the existing > test first to update the search string and second to better > exercise the vectorization not only when the source address > isn't aligned on the expected boundary but also when the > destination address isn't. This enhancement revealed > an outstanding aspect of the regression (not fixed by Richard's > already committed patch). > > Besides this change, the patch also adds a number of other > tests to better exercise the vectorization by verifying it > takes place for arrays of elements of other sizes besides > word: byte, half word, and double word. Those tests reveal > both another regression WRT 4.8 and further vectorization > opportunities not exploited even in 4.8. I marked the latter > XFAIL in the tests so that when the regression is fully > resolved, the tests should pass with no unexpected failures. I have a hard time applying the patch because of line-wrapping >issues or my patch tool not groking the git diffs. Can you please either commit the patch or extract the testcase that still regresses and paste it into PR63175? >>> >>> I pasted a couple of such test cases to the bug. The full patch >>> is also attached to this email in case there was a problem with >>> line wrapping. >> So for the unaligned case, is that really a regression when compared >to >> earlier compilers? If not, then it seems that we ought to at least >be >> at a point where the regression marker for that BZ can be removed, >> right? ie, Richi's patch fixed the actual code quality regression >and >> your patch fixes the testsuite aspects, right? > >My interpretation of the bug report is that it points out >two problems: > >1) a failure in the costmodel-bb-slp-9a.c test >2) a quality regression observed by inspecting the assembly >emitted for the test > >The two are unrelated in that (2) didn't cause (1). > >Since Richi's patch fixed (2) and my latest patch fixes (1) >I would be inclined to consider the bug resolved. > >While GCC 5 doesn't vectorize some code that 4.8 does with >the same options, it's apparently by accident (or due to >a bug in 4.8). Since 5.0 does vectorize the same code when >the right set of options is specified, I agree with others >that none of my additional tests has exposed any other >regressions than the one that's already been addressed. Yes. Once the test cases have been fixed we should close the bug as fixed. Richard. >Martin
Re: [PATCH, libgfortran] PR 65200 Handle EPERM as EACCES
Hi Janne, > the attached patch makes GFortran handle errno=EPERM in the same way > as EACCES (this affects only when no ACTION= specifier is used in the > OPEN statement and opening the file in read-write mode fails). Makes sense. > The patch also contains a doc snippet to explain how GFortran behaves > when no ACTION= is given when opening a file. Great. > This brings me to a > standards interpretation question: When no ACTION= is given, F2008 > 9.5.6.4 (ACCESS= specifier in OPEN statement) says: "If this specifier > is omitted, the default value is processor dependent." So does this > mean that the current GFortran behavior is allowed, or must the > behavior be exactly as with one of the possible ACTION= specifiers > (READ, WRITE, READWRITE)? I think we are standard-confirming: we open the file with one of the specifiers, determined in a processor-dependent fashion. Except our process-dependent value is not a constant, it depends on the file chosen (and its permissions). I believe that’s still within “processor dependent”. And it certainly makes more sense that the other possibilities. Thus, OK to commit. FX
Re: RFC: PATCHES: Properly handle reference to protected data on x86
On Fri, Mar 06, 2015 at 05:03:21PM -0800, H.J. Lu wrote: > I updated the testcase to Thanks, that's good to see. -- Alan Modra Australia Development Lab, IBM
Re: RFC: PATCHES: Properly handle reference to protected data on x86
On Sat, Mar 7, 2015 at 4:00 AM, Alan Modra wrote: > On Fri, Mar 06, 2015 at 05:03:21PM -0800, H.J. Lu wrote: >> I updated the testcase to > > Thanks, that's good to see. > Did you make it to work on PPC? -- H.J.
Re: [PATCH] Remove inefficient branchless conditional negate optimization
On Fri, Mar 6, 2015 at 8:36 AM, Jiong Wang wrote:
>
> Wilco Dijkstra writes:
>
>>> Jeff Law wrote:
>>> Can you move pr45685.c into gcc.target/i386?
>>>
>>> I know Richi said next stage1, but given this fixes a performance
>>> regression for ARM and it's reverting rather than adding new code, I
>>> think this is OK for the trunk with the testcase moved.
>>>
>>> So, OK with the testcase moved into gcc.target/i386/
>>
>> I've moved it and changed the compile condition:
>>
>> /* { dg-do compile { target { ! { ia32 } } } } */
>>
>> Jiong, can you commit this please?
>
> Done as 221246.
>
>>
>> Wilco
>>
>> 2015-03-06 Wilco Dijkstra
>>
>> * gcc/tree-ssa-phiopt.c (neg_replacement): Remove.
>> (tree_ssa_phiopt_worker): Remove negate optimization.
>> * gcc/testsuite/gcc.dg/tree-ssa/pr45685.c: Move to gcc.target/i386.
>> * gcc/testsuite/gcc.target/aarch64/csneg-1.c (test_csneg_cmp):
>> New test.
>> * gcc/gcc.target/i386/pr45685.c: Moved test, check for conditional
>> move on x64.
>
I checked in this as an obvious fix to make it pass on x32.
--
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 221254)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2015-03-07 H.J. Lu
+
+ * gcc.target/i386/pr45685.c (uint64_t): Replace long with long
+ long.
+ (int64_t): Likewise.
+
2015-03-07 Marek Polacek
Martin Uecker
Index: gcc.target/i386/pr45685.c
===
--- gcc.target/i386/pr45685.c (revision 221254)
+++ gcc.target/i386/pr45685.c (working copy)
@@ -1,8 +1,8 @@
/* { dg-do compile { target { ! { ia32 } } } } */
/* { dg-options "-O3" } */
-typedef unsigned long int uint64_t;
-typedef long int int64_t;
+typedef unsigned long long int uint64_t;
+typedef long long int int64_t;
int summation_helper_1(int64_t* products, uint64_t count)
{
int s = 0;
Data Recovery Services and Hardware Repair Services
We have made helping people our business. We only do data recovery, we do it all day, every day - we have become the very best in this field. We have seen all types of problems and solved nearly all of them! Why we are here? Data – Important assets of enterprises and individuals, is the key element of great success. Virus Attack, Back-up failure, Hard Disk Drive Crash, System Failure, Nature Disasters, Human Errors are one of the causes of Data Loss, which might potentially cause million and billions loss of profit. IntelliRecovery experts with their overwhelming experience, state-of-the-art tools and deep knowledge provide finest and innovative Data Recovery Solutions for all types of storage media and file systems in case of data loss. We are dedicated to provide you unmatchable, updated and quality data recovery services and we have enduring commitments to customer satisfaction. Nowadays, personal computer, mobile devices, networks, servers etc are so popular and they have become something we can’t miss in our daily life. This kind of digital platform can drive efficiency and convenience, unfortunately there is a huge risk behind – Data loss. Hence, IntelliRecovery team are here to recover and salvage lost data from disaster stricken hard drives, computer workstations, laptops, e-mails, smartphones, PDA's, iPods and portable storage media of every brand, manufacturer, model and capacity. What can we do? Hard disk data recovery RAID array data recovery Emergency data recovery USB flash drive data recovery Memory card data recovery Mobile phone data recovery Apple iPhone Passcode/PIN Removal Mobile Phone Spyware & Virus Detection NAS Data Recovery Data destruction Hard disk duplication Hard disk password removal We believe in doing business in an honest, friendly and professional way. We are always up front, honest and provide realistic time estimates, quotes and believe in providing the best service possible. No data recovery company can guarantee that they can recover your data (e.g if your disk platter is scratched or data is overwritten) but we promise not to give up until we recover your data or completely exhaust all possible options to help you! If your data cannot be recovered for any reason, we'll give you an honest explanation of the reason and assure you that we have done everything in our power to try to help you. In over 90% of cases, we can recover data from hard disks and other data storage devices. We look forward to helping you! We also provide Mobile Phone Repair services for Iphone, Ipad, and we specialize in repairing cell phones, smart phones, computers, laptops, game consoles, cameras, mp3 players, and most any other electronic gadget you can throw at us. We strive to create solutions where there weren’t any before. Best regards, Lance Email: drdatab...@tom.com
[SH][committed] Add test case for PR 65249
Hi,
This adds a test case for PR 65249.
Tested with
make -k check-c++ RUNTESTFLAGS="dg-torture.exp=pr65249.C
--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
Commited as r221256.
Cheers,
Oleg
gcc/testsuite/ChangeLog:
PR target/65249
* g++.dg/torture/pr65249.C: New.
Index: gcc/testsuite/g++.dg/torture/pr65249.C
===
--- gcc/testsuite/g++.dg/torture/pr65249.C (revision 0)
+++ gcc/testsuite/g++.dg/torture/pr65249.C (revision 0)
@@ -0,0 +1,54 @@
+// { dg-do compile }
+// { dg-additional-options "-fPIC -fstack-protector-strong" { target fpic } }
+// { dg-require-effective-target fstack_protector }
+
+struct struct0
+{
+ struct0 (void(*)());
+};
+
+int func5 (int* ptr);
+void func3 (int*, struct0*);
+
+inline void
+func4 (int* a, void (*b)())
+{
+ if (func5 (a) != 2)
+ {
+struct0 f (b);
+func3(a, &f);
+ }
+}
+
+struct struct1
+{
+ const void* val0;
+ const void* val1;
+};
+
+void* func3 (const void*);
+
+static const void* gvar1 = 0;
+static const void* gvar2 = 0;
+static int gvar0 = 0;
+
+void
+func0 (void)
+{
+ gvar2 = func3 (gvar1);
+}
+
+inline void
+func1 (void)
+{
+ func4 (&gvar0, &func0);
+}
+
+struct1 func2 (void)
+{
+ func1 ();
+ struct1 s;
+ s.val0 = gvar1;
+ s.val1 = gvar2;
+ return s;
+}
Re: [PATCH] PR63175 - [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1
On 03/07/15 01:34, Richard Biener wrote: On March 6, 2015 9:22:05 PM CET, Martin Sebor wrote: On 03/06/2015 10:28 AM, Jeff Law wrote: On 03/02/15 09:28, Martin Sebor wrote: On 03/02/2015 06:58 AM, Richard Biener wrote: On Fri, 27 Feb 2015, Martin Sebor wrote: Given that Martin's fix to the testcase allowed it to succeed without Richi's fix for the underlying problem, is there a modification to the testcase or a new testcase that would really test the optimization? Let me work on it. Below is a patch with a couple of minor tweaks to the existing test first to update the search string and second to better exercise the vectorization not only when the source address isn't aligned on the expected boundary but also when the destination address isn't. This enhancement revealed an outstanding aspect of the regression (not fixed by Richard's already committed patch). Besides this change, the patch also adds a number of other tests to better exercise the vectorization by verifying it takes place for arrays of elements of other sizes besides word: byte, half word, and double word. Those tests reveal both another regression WRT 4.8 and further vectorization opportunities not exploited even in 4.8. I marked the latter XFAIL in the tests so that when the regression is fully resolved, the tests should pass with no unexpected failures. I have a hard time applying the patch because of line-wrapping issues or my patch tool not groking the git diffs. Can you please either commit the patch or extract the testcase that still regresses and paste it into PR63175? I pasted a couple of such test cases to the bug. The full patch is also attached to this email in case there was a problem with line wrapping. So for the unaligned case, is that really a regression when compared to earlier compilers? If not, then it seems that we ought to at least be at a point where the regression marker for that BZ can be removed, right? ie, Richi's patch fixed the actual code quality regression and your patch fixes the testsuite aspects, right? My interpretation of the bug report is that it points out two problems: 1) a failure in the costmodel-bb-slp-9a.c test 2) a quality regression observed by inspecting the assembly emitted for the test The two are unrelated in that (2) didn't cause (1). Since Richi's patch fixed (2) and my latest patch fixes (1) I would be inclined to consider the bug resolved. While GCC 5 doesn't vectorize some code that 4.8 does with the same options, it's apparently by accident (or due to a bug in 4.8). Since 5.0 does vectorize the same code when the right set of options is specified, I agree with others that none of my additional tests has exposed any other regressions than the one that's already been addressed. Yes. Once the test cases have been fixed we should close the bug as fixed. Trunk regression marker removed. Not sure if it is worth backporting to 4.9, but I left the 4.9 regression marker and the BZ open just in case. jeff
Re: [PATCH, libgfortran] PR 65200 Handle EPERM as EACCES
On 03/06/2015 04:23 PM, Janne Blomqvist wrote: The patch as is causes gfortran.dg/open_errors.f90 to fail, due to changed error messages. I'm a bit unsure of to fix this, as now strerror* is used to generate part of the message, and thus the message can be different on different targets, and even dependent on the locale settings. Just checking for the fixed part of the error message doesn't seem that useful in this case; should the entire testcase just be removed? Generally the patch is OK as FX has stated. I am concerned about the strerror messages being less helpful to users than the ones we have. However, you can either keep the same error messages for those few or update the test case to use the error codes (iostat) if that makes more sense. Jerry
[SH][committed] Add test case for PR 65153
Hi,
This adds the test case for PR 65153.
Tested with
make -k check-gcc RUNTESTFLAGS="compile.exp=pr65153.c
--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
Committed as r221257.
Cheers,
Oleg
gcc/testsuite/ChangeLog:
PR target/65153
* gcc.c-torture/compile/pr65153.c: New.
Index: gcc/testsuite/gcc.c-torture/compile/pr65153.c
===
--- gcc/testsuite/gcc.c-torture/compile/pr65153.c (revision 0)
+++ gcc/testsuite/gcc.c-torture/compile/pr65153.c (revision 0)
@@ -0,0 +1,40 @@
+/* { dg-additional-options "-fPIC" { target fpic } } */
+
+typedef unsigned long word32;
+typedef unsigned char byte;
+typedef struct cast256_instance { word32 l_key[96];} cast256_key;
+word32 cast256_sbox[4][256] = {};
+void
+key (cast256_key *key, const word32 *in_key, const int key_len)
+{
+ word32 i, j, t, u, cm, cr, lk[8], tm[8], tr[8];
+ for (i = 0; i < 96; i += 8)
+{
+ for (j = 0; j < 8; ++j)
+ {
+ tm[j] = cm;
+ cm += 0x6ed9eba1;
+ tr[j] = cr;
+ cr += 17;
+ }
+ t = (((tm[0] + lk[7]) << ((word32)(tr[0] & 31)))
+ | ((tm[0] + lk[7]) >> (32 - (word32)(tr[0] & 31;
+ u = cast256_sbox[0][((byte)((t) >> (8 * 3)))];
+ u ^= cast256_sbox[1][((byte)((t) >> (8 * 2)))];
+ lk[7] ^= u;
+ for (j = 0; j < 8; ++j)
+ {
+ cm += 0x6ed9eba1;
+ tr[j] = cr;
+ cr += 17;
+ }
+ t = (((tm[0] + lk[7]) << ((word32)(tr[0] & 31)))
+ | ((tm[0] + lk[7]) >> (32 - (word32)(tr[0] & 31;
+ u = cast256_sbox[0][((byte)((t) >> (8 * 3)))];
+ u ^= cast256_sbox[1][((byte)((t) >> (8 * 2)))];
+ u -= cast256_sbox[2][((byte)((t) >> (8 * 1)))];
+ lk[2] ^= u;
+ lk[7] ^= u;
+ key->l_key[i + 1] = lk[2];
+}
+}
Do not free binfos linking vtables
Hi,
extra sanity checking I added while debugging PR 65316 noticed that the
type inheritance graph builder gets confused when one merges unit compiled
with -g -fno-devirtualize and unit compiled with -fdevirtualize.
In the first case there may be a base type lost.
Bootstrapped/regtested x86_64-linux, comitted.
PR ipa/65316
* tree.c (free_lang_data_in_type): Be sure to keep BINFO_VTABLE
when outputting debug.
Index: tree.c
===
--- tree.c (revision 221223)
+++ tree.c (working copy)
@@ -5081,9 +5081,15 @@ free_lang_data_in_type (tree type)
if (TYPE_BINFO (type))
{
free_lang_data_in_binfo (TYPE_BINFO (type));
+ /* We need to preserve link to bases and virtual table for all
+polymorphic types to make devirtualization machinery working.
+Debug output cares only about bases, but output also
+virtual table pointers so merging of -fdevirtualize and
+-fno-devirtualize units is easier. */
if ((!BINFO_VTABLE (TYPE_BINFO (type))
|| !flag_devirtualize)
- && (!BINFO_N_BASE_BINFOS (TYPE_BINFO (type))
+ && ((!BINFO_N_BASE_BINFOS (TYPE_BINFO (type))
+ && !BINFO_VTABLE (TYPE_BINFO (type)))
|| debug_info_level != DINFO_LEVEL_NONE))
TYPE_BINFO (type) = NULL;
}
Fix increase_alignment
Hi,
this patch makes vectorizer to increase alignments correctly in presence
of aliases. Currently increase happens at two places, first in
increase_alignment where we increase alignment of the DECL of alias as well
as alias target. This is not safe: it is possible that alias is static
and binds to current defintion, while target is not and may be interposed.
In this case we can not increase DECL_ALIGNMENT of target.
In the other place only alias DECL_ALIGN is bumped up. this however does not
make the definition (of alias target) to come out aligned and leads to segfault
in the testcase.
This patch moves the alignment decision to symbol table.
node->definition_alignment returns the desired alignment of the defintiion that
is maximal alignment needed by the declarations of symbol and its aliases.
I also moved logic deciding how to increase alignment into
node->can_increase_alignment_p predicate and node->increase_alignment that
increases alignment of all aliases that binds to current def.
I unforutnately spot another problem. With presence of section anchors we
can not increase alignment of symbol that was already placed into the section.
I think this is reason why we still have pass_increase_alignments that runs
only on target with anchors.
I added the following check:
+ /* If target is already placed in an anchor, we can not touch its
+ alignment. */
+ if (DECL_RTL_SET_P (target->decl)
+ && MEM_P (DECL_RTL (target->decl))
+ && SYMBOL_REF_HAS_BLOCK_INFO_P (XEXP (DECL_RTL (target->decl), 0)))
+return false;
but found it breaks several vectorization testcases with LTO. This is
becuase notice_global_symbol computes DECL_RTL even before
node->increase_alignment is run and we are stuck.
I decided to track this separately from this patch that snowballed quite a bit
already. I do not see how to solve it short of making notice_global_symbol to
not compute DECL_RTL. It was never quite clear to me why notice_global_symbol
is actually doing this at first place. Is it becuase of target mangling
happing only at RTL generation time?
Bootstrapped/regtested x86_64-linux, ppc64-linux, bootstrapped on AIX, will
commit it later today.
Honza
PR ipa/65334
* cgraph.h (symtab_node): Add definition_alignment,
can_increase_alignment_p and increase_alignment.
* symtab.c (symtab_node::can_increase_alignment_p,
increase_alignment_1, symtab_node::increase_alignment,
symtab_node::definition_alignment): New.
* tree-vect-data-refs.c (vect_can_force_dr_alignment_p): Use
can_increase_alignment_p.
* tree-vectorizer.c (increase_alignment): Use increase_alignment.
* tree-vect-stmts.c (ensure_base_align): Likewise.
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c (revision 221223)
+++ tree-vect-data-refs.c (working copy)
@@ -5703,58 +5703,10 @@ vect_can_force_dr_alignment_p (const_tre
if (TREE_CODE (decl) != VAR_DECL)
return false;
- /* With -fno-toplevel-reorder we may have already output the constant. */
- if (TREE_ASM_WRITTEN (decl))
+ if (decl_in_symtab_p (decl)
+ && !symtab_node::get (decl)->can_increase_alignment_p ())
return false;
- /* Constant pool entries may be shared and not properly merged by LTO. */
- if (DECL_IN_CONSTANT_POOL (decl))
-return false;
-
- if (TREE_PUBLIC (decl) || DECL_EXTERNAL (decl))
-{
- symtab_node *snode;
-
- /* We cannot change alignment of symbols that may bind to symbols
-in other translation unit that may contain a definition with lower
-alignment. */
- if (!decl_binds_to_current_def_p (decl))
- return false;
-
- /* When compiling partition, be sure the symbol is not output by other
-partition. */
- snode = symtab_node::get (decl);
- if (flag_ltrans
- && (snode->in_other_partition
- || snode->get_partitioning_class () == SYMBOL_DUPLICATE))
- return false;
-}
-
- /* Do not override the alignment as specified by the ABI when the used
- attribute is set. */
- if (DECL_PRESERVE_P (decl))
-return false;
-
- /* Do not override explicit alignment set by the user when an explicit
- section name is also used. This is a common idiom used by many
- software projects. */
- if (TREE_STATIC (decl)
- && DECL_SECTION_NAME (decl) != NULL
- && !symtab_node::get (decl)->implicit_section)
-return false;
-
- /* If symbol is an alias, we need to check that target is OK. */
- if (TREE_STATIC (decl))
-{
- tree target = symtab_node::get (decl)->ultimate_alias_target ()->decl;
- if (target != decl)
- {
- if (DECL_PRESERVE_P (target))
- return false;
- decl = target;
- }
-}
-
if (TREE_STATIC (decl))
return (alignment <= MAX_OFILE_ALIGNMENT);
else
Index: symtab.c
=
[patch, fortran] Bug 64432 - [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
The attached patch fixes this regression and implements KIND=1 and KIND=2
compatible calls. The smallest KIND found of the arguments given by the caller
is used to determine the results returned. New versions of the intrinsics with
the KIND argument are provided. The previous versions are retained and these
call the new with KIND= the respective call, 4 or 8.
The test case given here is provided for others to see the results and is not
yet dejagnu=ized. It provides all possible combinations of kinds and types to test.
I did performance test this with various combinations of the timeit.f08 program
to show the overhead is very very low. (also attached)
Regression tested on x86-64 and PowerPC. I am not set up to test on
Cygwin/Windows platforms. If someone can do this, please do.
OK for trunk?
Regards,
Jerry
2015-03-07 Jerry DeLisle
PR fortran/64432
* trans-decl (gfc_build_intrinsic_function_decls): Add a fourth
argument to system_clock declarations.
*trans-intrinisic.c (conv_intrinsic_system_clock): Build calls
to include the smallest kind used as the fourth argument to be
used by the runtime system_clock functions.
2015-03-07 Jerry DeLisle
PR libgfortran/64432
* gfortran.map: Add new section for new versions of
system_clock intrinsics.
* intrinsics/system_clock.c (system_clock4K, system_clock8K):
New/revised functions to include a KIND argument to handle
KIND=1 and KIND=2 cases. (system_clock4, system_clock8): Kept
for backward compatibility. These call the new versions above.
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c (revision 221248)
+++ gcc/fortran/trans-decl.c (working copy)
@@ -3122,15 +3122,16 @@ gfc_build_intrinsic_function_decls (void)
DECL_PURE_P (gfor_fndecl_sr_kind) = 1;
TREE_NOTHROW (gfor_fndecl_sr_kind) = 1;
+
gfor_fndecl_system_clock4 = gfc_build_library_function_decl (
- get_identifier (PREFIX("system_clock_4")),
- void_type_node, 3, gfc_pint4_type_node, gfc_pint4_type_node,
- gfc_pint4_type_node);
+ get_identifier (PREFIX("system_clock_4K")),
+ void_type_node, 4, gfc_pint4_type_node, gfc_pint4_type_node,
+ gfc_pint4_type_node, gfc_pint4_type_node);
gfor_fndecl_system_clock8 = gfc_build_library_function_decl (
- get_identifier (PREFIX("system_clock_8")),
+ get_identifier (PREFIX("system_clock_8K")),
void_type_node, 3, gfc_pint8_type_node, gfc_pint8_type_node,
- gfc_pint8_type_node);
+ gfc_pint8_type_node, gfc_pint4_type_node);
/* Power functions. */
{
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c (revision 221248)
+++ gcc/fortran/trans-intrinsic.c (working copy)
@@ -2670,23 +2670,15 @@ conv_intrinsic_system_clock (gfc_code *code)
{
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)
{
@@ -2706,37 +2698,84 @@ conv_intrinsic_system_clock (gfc_code *code)
gfc_conv_expr (&count_max_se, count_max);
}
+ /* Find the smallest kind found of the arguments. We will pass this to
+ the runtime library. */
+ least = 16;
+ least = (count && count->ts.kind < least) ? count->ts.kind : least;
+ least = (count_rate && count_rate->ts.kind < least) ? count_rate->ts.kind
+ : least;
+ least = (count_max && count_max->ts.kind < least) ? count_max->ts.kind
+ : least;
+ arg4 = build_int_cst (gfc_get_int_type (4), least);
+
+
+ /* Find the largest kind. This is used to decide which runtime call
+ to build. */
+ most = 1;
+ most = (count && count->ts.kind > most) ? count->ts.kind : most;
+ most = (count_rate && count_rate->ts.kind > most) ? count_rate->ts.kind
+ : most;
+ most = (count_max && count_max->ts.kind > most) ? count_max->ts.kind
+ : most;
+
/* Prepare temporary variables if we need them. */
- if (count && count->ts.kind != kind)
-arg1 = gfc_create_var (type, "count");
- else if (count)
-arg1 = count_se.expr;
- if (count_rate && (count_rate->ts.kind != kind
- || count_rate->ts.type != BT_INTEGER))
-a
