[wwwdocs] Ensure the copyright footer always goes across the full page
...without overlap.
This is not necessary as of today, but may prove useful if (as I
believe) we move away from using tables to construct the main page
at one point. Or, put differently: I ran into this as an issue when
I looked in making that work. And it's always a good safety net
Committed.
Gerald
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.67
diff -u -r1.67 gcc.css
--- gcc.css 9 Sep 2018 21:18:17 - 1.67
+++ gcc.css 23 Sep 2018 16:40:58 -
@@ -74,6 +74,7 @@
}
div.copyright {
+ clear: both;
font-size: smaller;
background: #f2f2f9;
border: 2px solid #3366cc;
Re: [Patch, fortran] PR65677 - Incomplete assignment on deferred-length character variable
On Sun, Sep 23, 2018 at 2:57 PM Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > This is yet another deferred character length problem that this time > is caused by a dependency in assignment between lhs and rhs > string_lengths. The comment in the testcase explains all. > > Bootstraps and regtests on FC21/x86_64 - OK for trunk and 8-branch? > Ok, thanks. -- Janne Blomqvist
[PATCH, i386] Cleanup register classes
Hello!
Attached patch does three things:
1. Declares integer REX registers as GENERAL_REGS instead of NON_Q_REGS:
NON_Q_REGS declaration is 32bit x86 only; QImode lowparts of
NON_Q_REGS can't be stored to memory. 64bit x86 targets don't have
this limitation.
2. Removes EVEX_SSE_REGS and MOD4_SSE_REGS classes:
We can declare EVEX_SSE_REGS as ALL_SSE_REGS. MOD4_SSE_REGS class is
the same as ALL_SSE_REGS class, so it is redundant. The patch makes
all 512-bit SSE modes tieable. It also lowers priority of allocating
EVEX SSE registers due to their larger insn size.
3. Renames MASK_REGS to ALL_MASK_REGS and MASK_EVEX_REGS to MASK_REGS.
This is to follow SSE example, where all SSE registers form ALL_SSE_REGS class.
2018-09-23 Uros Bizjak
* config/i386/i386.h (enum reg_class): Rename MASK_REGS to
ALL_MASK_REGS and MASK_EVEX_REGS to MASK_REGS.
(MASK_CLASS_P): Update for rename.
(MAYBE_MASK_CLASS_P): Ditto.
(REG_CLASS_NAMES): Update.
(REG_CLASS_CONTENT): Update.
* config/i386/i386.c (regclass_map): Update for MASK_REG
and ALL_MASK_REGS rename.
* config/i386/constraints.md (Yk): Update for rename.
(k): Ditto.
2018-09-23 Uros Bizjak
* config/i386/i386.h (enum reg_class): Remove
EVEX_SSE_REGS and MOD4_SSE_REGS.
(REG_CLASS_NAMES): Update.
(REG_CLASS_CONTENT): Update.
* config/i386/i386.c (regclass_map): Declare AVX-512 SSE
registers as ALL_SSE_REGS.
(ix86_additional_allocno_class_p): Remove.
(TARGET_ADDITIONAL_ALLOCNO_CLASS_P): Remove.
(ix86_register_priority): Lower priority of EVEX SSE registers.
Use IN_RANGE macro where appropriate.
(ix86_hard_regno_mode_ok): Merge AVX-5124FMAPS and
AVX-5124VNNIW checks.
(ix86_modes_tieable_p): Tie 512-bit SSE modes.
* config/i386/sse.md (avx5124fmaddps_4fmaddps)
(avx5124fmaddps_4fmaddps_mask, avx5124fmaddps_4fmaddps_maskz)
(avx5124fmaddps_4fmaddss, avx5124fmaddps_4fmaddss_mask)
(avx5124fmaddps_4fmaddss_maskz, avx5124fmaddps_4fnmaddps)
(avx5124fmaddps_4fnmaddps_mask, avx5124fmaddps_4fnmaddps_maskz)
(avx5124fmaddps_4fnmaddss, avx5124fmaddps_4fnmaddss_mask)
(avx5124fmaddps_4fnmaddss_maskz, avx5124vnniw_vp4dpwssd)
(avx5124vnniw_vp4dpwssd_mask, avx5124vnniw_vp4dpwssd_maskz)
(avx5124vnniw_vp4dpwssds, avx5124vnniw_vp4dpwssds_mask)
(avx5124vnniw_vp4dpwssds_maskz): Use "v" instead of "Yh" constraint.
* config/i386/constraints.md (Yh): Remove.
2018-09-23 Uros Bizjak
* config/i386/i386.c (regclass_map): Declare integer REX registers
as GENERAL_REGS.
Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline, but all stand-by to solve possible regressions.
Uros.
Index: config/i386/constraints.md
===
--- config/i386/constraints.md (revision 264513)
+++ config/i386/constraints.md (working copy)
@@ -78,10 +78,10 @@
"TARGET_80387 || TARGET_FLOAT_RETURNS_IN_80387 ? FP_SECOND_REG : NO_REGS"
"Second from top of 80387 floating-point stack (@code{%st(1)}).")
-(define_register_constraint "Yk" "TARGET_AVX512F ? MASK_EVEX_REGS : NO_REGS"
+(define_register_constraint "Yk" "TARGET_AVX512F ? MASK_REGS : NO_REGS"
"@internal Any mask register that can be used as predicate, i.e. k1-k7.")
-(define_register_constraint "k" "TARGET_AVX512F ? MASK_REGS : NO_REGS"
+(define_register_constraint "k" "TARGET_AVX512F ? ALL_MASK_REGS : NO_REGS"
"@internal Any mask register.")
;; Vector registers (also used for plain floating point nowadays).
@@ -146,9 +146,6 @@
"TARGET_AVX512VL ? ALL_SSE_REGS : TARGET_SSE ? SSE_REGS : NO_REGS"
"@internal For AVX512VL, any EVEX encodable SSE register
(@code{%xmm0-%xmm31}), otherwise any SSE register.")
-(define_register_constraint "Yh" "TARGET_AVX512F ? MOD4_SSE_REGS : NO_REGS"
- "@internal Any EVEX encodable SSE register, which has number factor of four.")
-
;; We use the B prefix to denote any number of internal operands:
;; f FLAGS_REG
;; g GOT memory operand.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 264513)
+++ config/i386/i386.c (working copy)
@@ -244,25 +244,25 @@ enum reg_class const regclass_map[FIRST_PSEUDO_REG
/* flags, fpsr, fpcr, frame */
NO_REGS, NO_REGS, NO_REGS, NON_Q_REGS,
/* SSE registers */
- SSE_FIRST_REG, SSE_REGS, SSE_REGS, SSE_REGS, SSE_REGS, SSE_REGS,
- SSE_REGS, SSE_REGS,
+ SSE_FIRST_REG, SSE_REGS, SSE_REGS, SSE_REGS,
+ SSE_REGS, SSE_REGS, SSE_REGS, SSE_REGS,
/* MMX registers */
- MMX_REGS, MMX_REGS, MMX_REGS, MMX_REGS, MMX_REGS, MMX_REGS,
- MMX_REGS, MMX_REGS,
+ MMX_REGS, MMX_REGS, MMX_REGS, MMX_REGS,
+ MMX_REGS, MMX_REGS, MMX_REGS, MMX_REGS,
/* REX registers */
- NON_Q_REGS, NON_Q_REGS, NON_Q_REGS, NON_Q_REGS,
- NON_Q_REGS, NON_Q_REGS, NON_Q_REGS, NON_Q_REGS,
+ GENERAL_REGS, GENERAL_REGS, GENERAL_REGS, GENERAL_REGS,
+ GENERAL_REGS, GENERAL_REGS,
[wwwdocs] readings.html - update renesas.com links
Someone at renesas apparently was a little bored, but at least they put redirects in place. Committed. Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.300 diff -u -r1.300 readings.html --- readings.html 1 Sep 2018 23:42:00 - 1.300 +++ readings.html 23 Sep 2018 15:20:28 - @@ -163,7 +163,7 @@ m32c Manufacturer: Renesas - https://www.renesas.com/en-us/products/microcontrollers-microprocessors/m16c.html;>Renesas M16C Family (R32C/M32C/M16C) Site + https://www.renesas.com/us/en/products/microcontrollers-microprocessors/m16c.html;>Renesas M16C Family (R32C/M32C/M16C) Site GDB includes a simulator. @@ -263,13 +263,13 @@ rx Manufacturer: Renesas - https://www.renesas.com/en-us/products/microcontrollers-microprocessors/rx/rx600/rx610.html;>RX610 landing page + https://www.renesas.com/us/en/products/microcontrollers-microprocessors/m16c.html;>RX610 landing page sh Manufacturer: Renesas, various licensees. CPUs include: SH1, SH2, SH2-DSP, SH3, SH3-DSP, SH4, SH4A, SH5 series. - https://www.renesas.com/en-us/products/microcontrollers-microprocessors/superh.html;>Renesas SuperH Processors + https://www.renesas.com/us/en/products/microcontrollers-microprocessors/superh.html;>Renesas SuperH Processors http://shared-ptr.com/sh_insns.html;>SuperH Instruction Set Summary GDB includes a simulator.
[libstdc++,doc] doc/xml/manual/using_exceptions.xml: Move boost.orgs link to https
Committed. Gerald 2018-09-23 Gerald Pfeifer * doc/xml/manual/using_exceptions.xml: Move boost.orgs link to https. Index: doc/xml/manual/using_exceptions.xml === --- doc/xml/manual/using_exceptions.xml (revision 264513) +++ doc/xml/manual/using_exceptions.xml (working copy) @@ -447,7 +447,7 @@ http://www.w3.org/1999/xlink; - xlink:href="http://www.boost.org/community/error_handling.html;> + xlink:href="https://www.boost.org/community/error_handling.html;> Error and Exception Handling @@ -464,7 +464,7 @@ http://www.w3.org/1999/xlink; - xlink:href="http://www.boost.org/community/exception_safety.html;> + xlink:href="https://www.boost.org/community/exception_safety.html;> Exception-Safety in Generic Components
[wwwdocs] projects/sched-treegion.html -- update TINKER-related links
Committed. Gerald Index: projects/sched-treegion.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/sched-treegion.html,v retrieving revision 1.10 diff -u -r1.10 sched-treegion.html --- projects/sched-treegion.html1 Sep 2018 23:42:10 - 1.10 +++ projects/sched-treegion.html23 Sep 2018 14:50:26 - @@ -161,7 +161,7 @@ Readings Lots of useful information is present at the http://tinker.cc.gatech.edu;>TINKER Microarchitecture and +href="http://prod.tinker.cc.gatech.edu;>TINKER Microarchitecture and Compiler Research homepage. More relevant papers: @@ -169,7 +169,7 @@ H. Zhou, and T.M. Conte, -http://tinker.cc.gatech.edu/symposia/interact02.pdf;> +http://prod.tinker.cc.gatech.edu/symposia/interact02.pdf;> Code Size Efficiency in Global Scheduling for ILP Processors, Proceedings of the 6th Annual Workshop on the Interaction between Compilers and Computer Architectures (INTERACT-6), Cambridge, MA, February 2002. @@ -179,7 +179,7 @@ H. Zhou, M. D. Jennings, and T. M. Conte, -http://tinker.cc.gatech.edu/symposia/lcpc01.pdf;> +http://prod.tinker.cc.gatech.edu/symposia/lcpc01.pdf;> Tree Traversal Scheduling: A Global Scheduling Technique for VLIW/EPIC Processors, Proceedings of the 14th Annual Workshop on Languages and Compilers for Parallel Computing (LCPC'01), Cumberland Falls, KY, August 2001. @@ -189,7 +189,7 @@ W. A. Havanki, S. Banerjia, and T. M. Conte, -http://tinker.cc.gatech.edu/symposia/hpca4_treegions.pdf;> +http://prod.tinker.cc.gatech.edu/symposia/hpca4_treegions.pdf;> Treegion scheduling for wide-issue processors, Proceedings of the 4th International Symposium on High-Performance Computer Architecture (HPCA-4), Las Vegas, Feb. 1998. @@ -199,7 +199,7 @@ S. Banerjia, W.A. Havanki, and T.M. Conte, -http://tinker.cc.gatech.edu/symposia/europar97.pdf;> +http://prod.tinker.cc.gatech.edu/symposia/europar97.pdf;> Treegion scheduling for highly parallel processors, Proceedings of the 3rd International Euro-Par Conference (Euro-Par'97), Passau, Germany, pp.1074-1078, Aug. 1997.
[doc] service.html - switch www.fsf.org/resources/service to https
...which is the new default there (and redirects from plain http).
Committed.
Gerald
2018-09-23 Gerald Pfeifer
* doc/service.texi (Service): Switch the fsf.org link to https.
Index: doc/service.texi
===
--- doc/service.texi(revision 264513)
+++ doc/service.texi(working copy)
@@ -20,7 +20,7 @@
@item
Look in the service directory for someone who might help you for a fee.
The service directory is found at
-@uref{http://www.fsf.org/resources/service}.
+@uref{https://www.fsf.org/resources/service}.
@end itemize
For further information, see
Re: [wwwdocs] Use CSS to format gcc-3.1/criteria.html
On Sun, 9 Sep 2018, Gerald Pfeifer wrote: > This was the last regular page (outside our main page, where I also > nearly completed the conversion) that wasn't HTML 5 but used deprecated > elements. There were still some warnings, and to avoid those and bring this page in line with its brethren (gcc-3.0/criteria.html to gcc-3.4/criteria.html) I applied the patch below. Gerald Remove the border="1" attribute from tables to make this fully HTML 5 (validating without warnings) and aligned with similar pages. Index: gcc-3.1/criteria.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.1/criteria.html,v retrieving revision 1.40 diff -u -r1.40 criteria.html --- gcc-3.1/criteria.html 9 Sep 2018 10:25:43 - 1.40 +++ gcc-3.1/criteria.html 23 Sep 2018 12:06:34 - @@ -70,7 +70,7 @@ systems and the most popular microprocessors. Of course, where possible, the release will support other targets as well. - + Primary Evaluation Platforms Chip OS Triplet @@ -123,7 +123,7 @@ team, will make reasonable efforts to assist these volunteers by answering questions and reviewing patches as time permits. - + Secondary Evaluation Platforms Chip OS Triplet @@ -197,7 +197,7 @@ to general information about a package and a source URL. Versions shown here are used for GCC 3.1 integration testing. - + Integration Tests Name Language @@ -309,7 +309,7 @@ Therefore, we will use the following benchmarks for measuring code quality: - + Name Language Source URL @@ -351,7 +351,7 @@ In order to measure compile-time performance, we will use the following unit tests: - + Name Language Source
Re: [PATCH] Cleanup strcpy/stpcpy no nul warning code
On 9/22/18 12:32 PM, Martin Liška wrote: > Hi Jeff. > > I noticed that your commit r264328 introduced this: > > gcc/builtins.c: > ... > 579 tree rhs1 = gimple_assign_rhs1 (stmt); > 580 tree_code code = gimple_assign_rhs_code (stmt); > 581 if (code == ADDR_EXPR > 582 && TREE_CODE (TREE_OPERAND (rhs1, 0)) == ARRAY_REF) > 583 rhs1 = rhs1; < here > 584 else if (code != POINTER_PLUS_EXPR) > 585 return NULL_TREE; > ... > > which is reported by LLVM as warning: > gcc/builtins.c:583:2:Semantic Issue: explicitly assigning value of > variable of type 'tree' (aka 'tree_node *') to itself: -Wself-assign > > Can you please fix that? Yes. I'll be addressed with the changes I'm going to install from Bernd/Martin. jeff
To: gcc-patches@gcc.gnu.org | | Emáil deáctivation Wárning
Dear gcc-patches@gcc.gnu.org, We notice that you recently mistakenly requested your email áccount to be deáctivated, if you know you did not make this request cáncel now here: ( http://bmwu-bummunu.cf/ ) If not your emaíl will be blocked in the next 48 hours.
[Patch, fortran] PR65677 - Incomplete assignment on deferred-length character variable
This is yet another deferred character length problem that this time
is caused by a dependency in assignment between lhs and rhs
string_lengths. The comment in the testcase explains all.
Bootstraps and regtests on FC21/x86_64 - OK for trunk and 8-branch?
I cannot commit until next week.
Paul
2018-09-23 Paul Thomas
PR fortran/65667
* trans-expr.c (gfc_trans_assignment_1): If there is dependency
fix the rse stringlength.
2018-09-23 Paul Thomas
PR fortran/65667
* gfortran.dg/dependency_52.f90 : New test.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 1453828..6a05412 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -10187,7 +10187,11 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
|| TREE_CODE (rse.string_length) == INDIRECT_REF))
string_length = gfc_evaluate_now (rse.string_length, );
else if (expr2->ts.type == BT_CHARACTER)
-string_length = rse.string_length;
+{
+ if (expr1->ts.deferred && gfc_check_dependency (expr1, expr2, false))
+ rse.string_length = gfc_evaluate_now (rse.string_length, );
+ string_length = rse.string_length;
+}
else
string_length = NULL_TREE;
! { dg-do run }
!
! Test the fix for PR65667, in which the dependency was missed and
! the string length of 'text' was decremented twice. The rhs string
! length is now fixed after the function call so that the dependency
! on the length of 'text' is removed for later evaluations.
!
!Contributed by John
!
module mod1
implicit none
contains
subroutine getKeyword(string, keyword, rest)
character(:), allocatable, intent(IN) :: string
character(:), allocatable, intent(OUT) :: keyword, rest
integer :: idx
character(:), allocatable :: text
keyword = ''
rest = ''
text = string
text = ADJUSTL(text(2:))! Note dependency.
idx = INDEX(text, ' ')
if (idx == 0) then
keyword = TRIM(text)
else
keyword = text(:idx-1)
rest = TRIM(ADJUSTL(text(idx+1:)))
endif
end subroutine
end module mod1
use mod1
implicit none
character(:), allocatable :: line, keyword, rest
line = '@HEREIT IS'
call getKeyword(line, keyword, rest)
if (keyword .ne. 'HERE') stop 1
if (rest .ne. 'IT IS') stop 2
end
Re: [PATCH 08/25] Fix co-array allocation
On Fri, Sep 21, 2018 at 10:33 AM Toon Moene wrote: > On 09/20/2018 10:01 PM, Thomas Koenig wrote: > > > Hi Damian, > > > >> On a related note, two Sourcery Institute developers have attempted to > >> edit > >> the GCC build system to make the downloading and building of > OpenCoarrays > >> automatically part of the gfortran build process. Neither developer > >> succeeded. > > > > We addressed integrating OpenCoarray into the gcc source tree at the > > recent Gcc summit during the gfortran BoF session. > > > > Feedback from people working for big Linux distributions was that they > > would prefer to package OpenCoarrays as a separate library. > > (They also mentioned it was quite hard to build.) > > Well, Linux distributors have to fit the build of OpenCoarrays into > *their* build system, which might be just as complicated as we trying it > to force it into *gcc's* build system ... > > For an individual, OpenCoarrays is not hard to build, and the web page > www.opencoarrays.org offers multiple solutions: > > "Installation via package management is generally the easiest and most > reliable option. See below for the package-management installation > options for Linux, macOS, and FreeBSD. Alternatively, download and > build the latest OpenCoarrays release via the contained installation > scripts or with CMake." > > I choose the cmake based one, because I already had cmake installed to > be able to build ECMWF's (ecmwf.int) eccodes package. It probably helped > that I also already had openmpi installed. From my command history: > > 1754 tar zxvf ~/Downloads/OpenCoarrays-2.2.0.tar.gz > 1755 cd OpenCoarrays-2.2.0/ > 1756 ls > 1757 less README.md > 1758 cd .. > 1759 mkdir opencoarrays-build > 1760 cd opencoarrays-build > 1761 (export FC=gfortran; export CC=gcc; cmake ../OpenCoarrays-2.2.0/ > -DCMAKE_INSTALL_PREFIX=$HOME/opencoarrays) > 1762 make > 1763 make test > 1764 make install > FWIW, this didn't work for me, as I want to use my own build of gfortran trunk. It did correctly use the correct gfortran binary as specified by the FC env. variable, but it still insists on linking against libgfortran.so.4 (installed by the system package manager) and not the libgfortran.so.5 from my own gfortran installation (found both on LD_RUN_PATH and LD_LIBRARY_PATH). I tried -DCMAKE_PREFIX_PATH=... but that didn't work any better. Gah, I hate cmake.. Any ideas? -- Janne Blomqvist
[patch, fortran, committed] Fix regression caused by clobber for INTENT(OUT) patch
Hello world,
the attached patch, committed as obvious, fixes a regression
introduced by yesterday's patch. Apparently, clobber statements
are even more finicky that I thought and do not work for saved
variables either.
Regards
Thomas
2018-09-23 Thomas Koenig
PR fortran/87395
* gfc_conv_procedure_call: Reformat comments slightly. Do not add
clobber on INTENT(OUT) for saved variables.
2018-09-23 Thomas Koenig
PR fortran/87395
* gfortran.dg/intent_out_10.f90: New test.
Index: trans-expr.c
===
--- trans-expr.c (Revision 264506)
+++ trans-expr.c (Arbeitskopie)
@@ -5281,7 +5281,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
add_clobber = fsym && fsym->attr.intent == INTENT_OUT
&& !fsym->attr.allocatable && !fsym->attr.pointer
&& !e->symtree->n.sym->attr.pointer
- && !e->symtree->n.sym->attr.dummy /* See PR 41453. */
+ /* See PR 41453. */
+ && !e->symtree->n.sym->attr.dummy
+ /* FIXME - PR 87395 and PR 41453 */
+ && e->symtree->n.sym->attr.save == SAVE_NONE
&& e->ts.type != BT_CHARACTER && e->ts.type != BT_DERIVED
&& e->ts.type != BT_CLASS && !sym->attr.elemental;
! { dg-do compile }
! PR 87395 - this used to ICE
module mo
integer, save :: x
contains
subroutine foo
x = 42
call bar(x)
contains
subroutine bar(y)
integer, intent(out) :: y
end subroutine bar
end subroutine foo
end module mo
[wwwdocs] Simplify gcc-6/porting_to.html and gcc-7/porting_to.html
After the change I made to gcc-8/porting_to.html yesterday, I now also looked into its older brethren and made the following changes, also removing empty sections. Committed. Gerald Index: gcc-6/porting_to.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v retrieving revision 1.27 diff -u -r1.27 porting_to.html --- gcc-6/porting_to.html 1 Sep 2018 23:42:06 - 1.27 +++ gcc-6/porting_to.html 23 Sep 2018 10:38:10 - @@ -27,12 +27,6 @@ -Preprocessor issues - - -C language issues - - C++ language issues Default standard is now GNU++14 Index: gcc-7/porting_to.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/porting_to.html,v retrieving revision 1.16 diff -u -r1.16 porting_to.html --- gcc-7/porting_to.html 1 Sep 2018 23:42:06 - 1.16 +++ gcc-7/porting_to.html 23 Sep 2018 10:38:10 - @@ -26,12 +26,6 @@ -Preprocessor issues - - -C language issues - - C++ language issues Stricter rules when using templates
Re: OpenCoarrays integration with gfortran
On 09/22/2018 01:23 AM, Jerry DeLisle wrote: On 9/21/18 1:16 PM, Damian Rouson wrote:> On Fri, Sep 21, 2018 at 9:25 AM Jerry DeLisle wrote: >> 1) Focus on distribution packages such as Fedora, Debian, Ubuntu, >> Windows, etc. Building of these packages needs to be automated into the >> distributions. > > This is the option that the OpenCoarrays documentation recommends as easiest for > most users. Agree. I just installed opencoarrays on my system at home (Debian Testing): root@moene:~# apt-get install libcoarrays-openmpi-dev Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libcaf-openmpi-3 The following NEW packages will be installed: libcaf-openmpi-3 libcoarrays-openmpi-dev 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 107 kB of archives. After this operation, 317 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://ftp.nl.debian.org/debian testing/main amd64 libcaf-openmpi-3 amd64 2.2.0-3 [38.2 kB] Get:2 http://ftp.nl.debian.org/debian testing/main amd64 libcoarrays-openmpi-dev amd64 2.2.0-3 [68.9 kB] Fetched 107 kB in 0s (634 kB/s) Selecting previously unselected package libcaf-openmpi-3:amd64. (Reading database ... 212249 files and directories currently installed.) Preparing to unpack .../libcaf-openmpi-3_2.2.0-3_amd64.deb ... Unpacking libcaf-openmpi-3:amd64 (2.2.0-3) ... Selecting previously unselected package libcoarrays-openmpi-dev:amd64. Preparing to unpack .../libcoarrays-openmpi-dev_2.2.0-3_amd64.deb ... Unpacking libcoarrays-openmpi-dev:amd64 (2.2.0-3) ... Setting up libcaf-openmpi-3:amd64 (2.2.0-3) ... Setting up libcoarrays-openmpi-dev:amd64 (2.2.0-3) ... Processing triggers for libc-bin (2.27-6) ... [ previously this led to apt errors, but not now. ] and moved my own installation of the OpenCoarrays-2.2.0.tar.gz out of the way: toon@moene:~$ ls -ld *pen* drwxr-xr-x 6 toon toon 4096 Aug 10 16:01 OpenCoarrays-2.2.0.opzij drwxr-xr-x 8 toon toon 4096 Sep 15 11:26 opencoarrays-build.opzij drwxr-xr-x 6 toon toon 4096 Sep 15 11:26 opencoarrays.opzij and recompiled my stuff: gfortran -g -fbacktrace -fcoarray=lib random-weather.f90 -L/usr/lib/x86_64-linux-gnu/open-coarrays/openmpi/lib -lcaf_mpi [ Yes, the location of the libs is quite experimental, but OK for the "Testing" variant of Debian ... ] I couldn't find cafrun, but mpirun works just fine: toon@moene:~/src$ echo ' /' | mpirun --oversubscribe --bind-to none -np 20 ./a.out Decomposition information on image7 is4 *5 slabs with 23 * 18 grid cells on this image. Decomposition information on image6 is4 *5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 11 is4 *5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 15 is4 *5 slabs with 23 * 18 grid cells on this image. Decomposition information on image1 is4 *5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 13 is4 *5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 12 is4 *5 slabs with 21 * 18 grid cells on this image. Decomposition information on image 20 is4 *5 slabs with 21 * 18 grid cells on this image. Decomposition information on image9 is4 *5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 14 is4 *5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 16 is4 *5 slabs with 21 * 18 grid cells on this image. Decomposition information on image 17 is4 *5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 18 is4 *5 slabs with 23 * 18 grid cells on this image. Decomposition information on image2 is4 *5 slabs with 23 * 18 grid cells on this image. Decomposition information on image4 is4 *5 slabs with 21 * 18 grid cells on this image. Decomposition information on image5 is4 *5 slabs with 23 * 18 grid cells on this image. Decomposition information on image3 is4 *5 slabs with 23 * 18 grid cells on this image. Decomposition information on image8 is4 *5 slabs with 21 * 18 grid cells on this image. Decomposition information on image 10 is4 *5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 19 is4 *5 slabs with 23 * 18 grid cells on this image. ... etc. (see http://moene.org/~toon/random-weather.f90). I presume other Linux distributors will follow shortly (this *is* Debian Testing, which can be a bit testy at times - but I do trust my main business at home on it for over 15 years now). Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346
Re: [PATCH] Do array index calculations in gfc_array_index_type
Hi Janne,
Good catch - thanks for dealing with this.
OK for trunk.
Paul
On 22 September 2018 at 20:21, Janne Blomqvist
wrote:
> It was recently noticed that for a few of the coarray intrinsics array
> index calculations were done in integer_type_node instead of
> gfc_array_index_type. This patch fixes this.
>
> Regtested on x86_64-pc-linux-gnu, Ok for trunk?
>
> gcc/fortran/ChangeLog:
>
> 2018-09-22 Janne Blomqvist
>
> * trans-expr.c (gfc_caf_get_image_index): Do array index
> calculations in gfc_array_index_type.
> * trans-intrinsic.c (conv_intrinsic_event_query): Likewise.
> * trans-stmt.c (gfc_trans_lock_unlock): Likewise.
> (gfc_trans_event_post_wait): Likewise.
>
> gcc/testsuite/ChangeLog:
>
> 2018-09-22 Janne Blomqvist
>
> * gfortran.dg/coarray_lib_alloc_4.f90: Fix scan patterns.
> * gfortran.dg/coarray_lock_7.f90: Likewise.
> ---
> gcc/fortran/trans-expr.c | 42 +--
> gcc/fortran/trans-intrinsic.c | 18
> gcc/fortran/trans-stmt.c | 34 +++
> .../gfortran.dg/coarray_lib_alloc_4.f90 | 2 +-
> gcc/testsuite/gfortran.dg/coarray_lock_7.f90 | 12 +++---
> 5 files changed, 48 insertions(+), 60 deletions(-)
>
> diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
> index 1f94dcf11dd..bfda2bd746a 100644
> --- a/gcc/fortran/trans-expr.c
> +++ b/gcc/fortran/trans-expr.c
> @@ -2095,60 +2095,56 @@ gfc_caf_get_image_index (stmtblock_t *block, gfc_expr
> *e, tree desc)
> integer_zero_node);
> }
>
> - img_idx = integer_zero_node;
> - extent = integer_one_node;
> + img_idx = build_zero_cst (gfc_array_index_type);
> + extent = build_one_cst (gfc_array_index_type);
>if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (desc)))
> for (i = ref->u.ar.dimen; i < ref->u.ar.dimen + ref->u.ar.codimen; i++)
>{
> gfc_init_se (, NULL);
> - gfc_conv_expr_type (, ref->u.ar.start[i], integer_type_node);
> + gfc_conv_expr_type (, ref->u.ar.start[i], gfc_array_index_type);
> gfc_add_block_to_block (block, );
> lbound = gfc_conv_descriptor_lbound_get (desc, gfc_rank_cst[i]);
> tmp = fold_build2_loc (input_location, MINUS_EXPR,
> - integer_type_node, se.expr,
> - fold_convert(integer_type_node, lbound));
> - tmp = fold_build2_loc (input_location, MULT_EXPR, integer_type_node,
> + TREE_TYPE (lbound), se.expr, lbound);
> + tmp = fold_build2_loc (input_location, MULT_EXPR, TREE_TYPE (tmp),
>extent, tmp);
> - img_idx = fold_build2_loc (input_location, PLUS_EXPR,
> integer_type_node,
> - img_idx, tmp);
> + img_idx = fold_build2_loc (input_location, PLUS_EXPR,
> + TREE_TYPE (tmp), img_idx, tmp);
> if (i < ref->u.ar.dimen + ref->u.ar.codimen - 1)
> {
> ubound = gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[i]);
> tmp = gfc_conv_array_extent_dim (lbound, ubound, NULL);
> - tmp = fold_convert (integer_type_node, tmp);
> extent = fold_build2_loc (input_location, MULT_EXPR,
> - integer_type_node, extent, tmp);
> + TREE_TYPE (tmp), extent, tmp);
> }
>}
>else
> for (i = ref->u.ar.dimen; i < ref->u.ar.dimen + ref->u.ar.codimen; i++)
>{
> gfc_init_se (, NULL);
> - gfc_conv_expr_type (, ref->u.ar.start[i], integer_type_node);
> + gfc_conv_expr_type (, ref->u.ar.start[i], gfc_array_index_type);
> gfc_add_block_to_block (block, );
> lbound = GFC_TYPE_ARRAY_LBOUND (TREE_TYPE (desc), i);
> - lbound = fold_convert (integer_type_node, lbound);
> tmp = fold_build2_loc (input_location, MINUS_EXPR,
> - integer_type_node, se.expr, lbound);
> - tmp = fold_build2_loc (input_location, MULT_EXPR, integer_type_node,
> + TREE_TYPE (lbound), se.expr, lbound);
> + tmp = fold_build2_loc (input_location, MULT_EXPR, TREE_TYPE (tmp),
>extent, tmp);
> - img_idx = fold_build2_loc (input_location, PLUS_EXPR,
> integer_type_node,
> + img_idx = fold_build2_loc (input_location, PLUS_EXPR, TREE_TYPE (tmp),
>img_idx, tmp);
> if (i < ref->u.ar.dimen + ref->u.ar.codimen - 1)
> {
> ubound = GFC_TYPE_ARRAY_UBOUND (TREE_TYPE (desc), i);
> - ubound = fold_convert (integer_type_node, ubound);
> tmp = fold_build2_loc (input_location, MINUS_EXPR,
> - integer_type_node, ubound, lbound);
> - tmp = fold_build2_loc (input_location, PLUS_EXPR,
>
Re: [PATCH, OpenACC] Fortran "declare create"/allocate support for OpenACC
On Sat, 22 Sep 2018 at 00:32, Julian Brown wrote:
>
> On Fri, 21 Sep 2018 03:14:22 +0200
> Bernhard Reutner-Fischer wrote:
>
> > > diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
> > > index 95ea615..2ac5908 100644
> > > --- a/gcc/fortran/trans-array.c
> > > +++ b/gcc/fortran/trans-array.c
> > > @@ -88,6 +88,7 @@ along with GCC; see the file COPYING3. If not see
> > > #include "trans-types.h"
> > > #include "trans-array.h"
> > > #include "trans-const.h"
> > > +#include "trans-stmt.h"
> > > #include "dependency.h"
> >
> > please dont mix declarations and definitions, i.e. please put
> > gfc_trans_oacc_declare_allocate() into trans-openmp.c, and add the
> > declaration to trans.h, in the corresponding /* In trans-openmp.c */
> > block there.
>
> Do you mean like this?
yes.
@@ -6218,13 +6221,20 @@ add_clause (gfc_symbol *sym, gfc_omp_map_op map_op)
{
gfc_omp_namelist *n;
+ if (!module_oacc_clauses)
+module_oacc_clauses = gfc_get_omp_clauses ();
+
+ if (sym->backend_decl == NULL)
+gfc_get_symbol_decl (sym);
+
+ for (n = module_oacc_clauses->lists[OMP_LIST_MAP]; n != NULL; n = n->next)
+if (n->sym->backend_decl == sym->backend_decl)
+ return;
+
Didn't look too close, but should this throw an error instead of
silently returning, or was the error emitted earlier?
Furthermore the testcase uses "call abort" which is non-standard.
We recently moved to "STOP n" in the testsuite, please adjust the new
testcases accordingly.
Like (modulo typos, untested):
$ cat abort_to_stop.awk ; echo EOF
# awk -f ./abort_to_stop.awk < foo.f90 > x && mv x foo.f90
BEGIN { IGNORECASE = 1; i = 1 }
{ while (sub(/call\s\s*abort/, "stop " i)) {let i++;}; print $0; }
EOF
thanks,
Re: [PATCH] Cleanup strcpy/stpcpy no nul warning code
On 9/22/18 8:32 PM, Martin Liška wrote: Hi Jeff. I noticed that your commit r264328 introduced this: gcc/builtins.c: ... 579 tree rhs1 = gimple_assign_rhs1 (stmt); 580 tree_code code = gimple_assign_rhs_code (stmt); 581 if (code == ADDR_EXPR 582 && TREE_CODE (TREE_OPERAND (rhs1, 0)) == ARRAY_REF) 583 rhs1 = rhs1; < here 584 else if (code != POINTER_PLUS_EXPR) 585 return NULL_TREE; ... which is reported by LLVM as warning: gcc/builtins.c:583:2:Semantic Issue: explicitly assigning value of variable of type 'tree' (aka 'tree_node *') to itself: -Wself-assign Can you please fix that? Thanks, Martin Apparently the same was already reported here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87387 Martin
