Re: C++ PATCHes to run testsuite in C++14 mode
Jason Merrill writes:
> diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C
> b/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C
> index 5b5d15a..50df842 100644
> --- a/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C
> +++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C
> @@ -1,6 +1,7 @@
> // Origin: PR c++/51032
> // { dg-skip-if "No stabs" { aarch64*-*-* mmix-*-* *-*-aix* alpha*-*-*
> hppa*64*-*-* ia64-*-* *-*-vxworks* nios2-*-* } { "*" } { "" } }
> -// { dg-options "-std=c++11 -gstabs+" }
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-gstabs+" }
Order matters, by using dg-do after dg-skip the latter is effectively
ignored. Tested on ia64-suse-linux and installed as obvious.
Andreas.
* g++.dg/cpp0x/alias-decl-debug-0.C: Move dg-skip after dg-do.
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C
index 50df842..524216a 100644
--- a/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C
@@ -1,6 +1,6 @@
// Origin: PR c++/51032
-// { dg-skip-if "No stabs" { aarch64*-*-* mmix-*-* *-*-aix* alpha*-*-*
hppa*64*-*-* ia64-*-* *-*-vxworks* nios2-*-* } { "*" } { "" } }
// { dg-do compile { target c++11 } }
+// { dg-skip-if "No stabs" { aarch64*-*-* mmix-*-* *-*-aix* alpha*-*-*
hppa*64*-*-* ia64-*-* *-*-vxworks* nios2-*-* } { "*" } { "" } }
// { dg-options "-gstabs+" }
template
--
1.9.0
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: [Build] libcilkrts/Makefile.am: Install cilk.h
Il 09/03/2014 07:24, Tobias Burnus ha scritto: The attached patch installs cilk.h such that "#include " works. Bootstrapped on x86-64-gnu-linux. OK for the trunk? (If you wonder about the other changes in the generated-files diff: I think they are due to r205357, where configure.ac changed and configure was regenerated but Makefile.in and aclocal.m4 were not.) Tobias Ok. Paolo
[Build] libcilkrts/Makefile.am: Install cilk.h
The attached patch installs cilk.h such that "#include " works. Bootstrapped on x86-64-gnu-linux. OK for the trunk? (If you wonder about the other changes in the generated-files diff: I think they are due to r205357, where configure.ac changed and configure was regenerated but Makefile.in and aclocal.m4 were not.) Tobias 2014-03-09 Tobias Burnus * Makefile.am: Install cilk.h. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. diff --git a/libcilkrts/Makefile.am b/libcilkrts/Makefile.am index f2d13aa..e902f73 100644 --- a/libcilkrts/Makefile.am +++ b/libcilkrts/Makefile.am @@ -50,8 +50,11 @@ AM_LDFLAGS = -lpthread # May be used by toolexeclibdir. gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER) +cilkincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/cilk + # Target list. toolexeclib_LTLIBRARIES = libcilkrts.la +nodist_cilkinclude_HEADERS = include/cilk/cilk.h libcilkrts_la_SOURCES =\ runtime/config/$(config_dir)/cilk-abi-vla.c \ diff --git a/libcilkrts/Makefile.in b/libcilkrts/Makefile.in index 092e2f7..706a0da 100644 --- a/libcilkrts/Makefile.in +++ b/libcilkrts/Makefile.in @@ -122,10 +122,8 @@ DIST_COMMON = $(srcdir)/include/internal/rev.mk README ChangeLog \ @MAC_LINKER_SCRIPT_TRUE@am__append_2 = -Wl,-exported_symbols_list,$(srcdir)/runtime/mac-symbols.txt subdir = . ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 -am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \ - $(top_srcdir)/../config/depstand.m4 \ +am__aclocal_m4_deps = $(top_srcdir)/../config/depstand.m4 \ $(top_srcdir)/../config/lead-dot.m4 \ - $(top_srcdir)/../config/libstdc++-raw-cxx.m4 \ $(top_srcdir)/../config/multi.m4 \ $(top_srcdir)/../config/override.m4 \ $(top_srcdir)/../libtool.m4 $(top_srcdir)/../ltoptions.m4 \ @@ -160,7 +158,7 @@ am__base_list = \ sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \ sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g' am__installdirs = "$(DESTDIR)$(toolexeclibdir)" \ - "$(DESTDIR)$(cilkincludedir)" + "$(DESTDIR)$(cilkincludedir)" "$(DESTDIR)$(cilkincludedir)" LTLIBRARIES = $(toolexeclib_LTLIBRARIES) libcilkrts_la_LIBADD = am_libcilkrts_la_OBJECTS = cilk-abi-vla.lo os-unix-sysdep.lo bug.lo \ @@ -204,7 +202,7 @@ MULTIDIRS = MULTISUBDIR = MULTIDO = true MULTICLEAN = true -HEADERS = $(cilkinclude_HEADERS) +HEADERS = $(cilkinclude_HEADERS) $(nodist_cilkinclude_HEADERS) ETAGS = etags CTAGS = ctags ACLOCAL = @ACLOCAL@ @@ -245,8 +243,6 @@ LD = @LD@ LDFLAGS = @LDFLAGS@ LIBOBJS = @LIBOBJS@ LIBS = @LIBS@ -LIBSTDCXX_RAW_CXX_CXXFLAGS = @LIBSTDCXX_RAW_CXX_CXXFLAGS@ -LIBSTDCXX_RAW_CXX_LDFLAGS = @LIBSTDCXX_RAW_CXX_LDFLAGS@ LIBTOOL = @LIBTOOL@ LIPO = @LIPO@ LN_S = @LN_S@ @@ -328,7 +324,6 @@ sysconfdir = @sysconfdir@ target = @target@ target_alias = @target_alias@ target_cpu = @target_cpu@ -target_noncanonical = @target_noncanonical@ target_os = @target_os@ target_vendor = @target_vendor@ toolexecdir = @toolexecdir@ @@ -355,8 +350,13 @@ AM_LDFLAGS = -lpthread # May be used by toolexeclibdir. gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER) +# C/C++ header files for Cilk. +# cilkincludedir = $(includedir)/cilk +cilkincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include/cilk + # Target list. toolexeclib_LTLIBRARIES = libcilkrts.la +nodist_cilkinclude_HEADERS = include/cilk/cilk.h libcilkrts_la_SOURCES = \ runtime/config/$(config_dir)/cilk-abi-vla.c \ runtime/config/$(config_dir)/os-unix-sysdep.c \ @@ -399,10 +399,6 @@ CILK_REVISION = 3902 libcilkrts_la_LDFLAGS = -version-info 5:0:0 -lpthread \ @lt_cv_dlopen_libs@ $(am__append_1) $(am__append_2) \ -no-undefined - -# C/C++ header files for Cilk. -# cilkincludedir = $(includedir)/cilk -cilkincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include/cilk cilkinclude_HEADERS = \ include/cilk/cilk_api.h \ include/cilk/cilk_api_linux.h\ @@ -873,6 +869,26 @@ uninstall-cilkincludeHEADERS: test -n "$$files" || exit 0; \ echo " ( cd '$(DESTDIR)$(cilkincludedir)' && rm -f" $$files ")"; \ cd "$(DESTDIR)$(cilkincludedir)" && rm -f $$files +install-nodist_cilkincludeHEADERS: $(nodist_cilkinclude_HEADERS) + @$(NORMAL_INSTALL) + test -z "$(cilkincludedir)" || $(MKDIR_P) "$(DESTDIR)$(cilkincludedir)" + @list='$(nodist_cilkinclude_HEADERS)'; test -n "$(cilkincludedir)" || list=; \ + for p in $$list; do \ + if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ + echo "$$d$$p"; \ + done | $(am__base_list) | \ + while read files; do \ + echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(cilkincludedir)'"; \ + $(INSTALL_HEADER) $$files "$(DESTDIR)$(cilkincludedir)" || exit $$?; \ + done + +uninstall-nodist_cilkincludeHEADERS: + @$(NORMAL_UNINSTALL) + @list='$(nodist_cilkinclude_HEADERS)'; test -n "$(cilkincludedir)" || list=; \ + files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \ + test -n "$$files" || exit 0; \ + echo " ( cd '$(DESTDIR)$(cilkincludedir)' && rm -f" $$files ")"; \ + cd "$(DESTDIR)$(cilkincludedir)"
Re: PATCH to add -std=c++14
On Mar 7, 2014, at 8:22 AM, Jason Merrill wrote: > It's looking very likely that we will have a new C++ standard this year, so > I'm going to go ahead and add the -std=c++14 flag for 4.9; I just won't > advertise it yet. Are they any plans to change the default language for C++?
Re: [patch, libfortran] [4.7/4.8/4.9 Regression] PR38199 missed optimization: I/O performance
Am 08.03.2014 23:37, schrieb Manfred Schwarb: Am 08.03.2014 07:38, schrieb Jerry DeLisle: The attached patch addresses the problem identified in comment #22 of the PR. For character array internal unit reads, eat_spaces must call next_char to advance every single character until the end of the string is reached. In the case sited which is very contrived, this amounts to about 10 calls to next_char. For clarity, this test case: character buffer(1)*10 integer i,j j = 1234 write(buffer(1),'(i4)') j DO j=1, !write(*,*) buffer(1)(1:4) read(buffer,*) i !write(*,*) i ENDDO end Without the patch takes about 25 seconds to run. With the patch this takes about 2.8 seconds. This is great. However, this is still 10 times slower than the LEN_TRIM variant: character buffer(1)*10 integer i,j j = 1234 write(buffer(1),'(i4)') j DO j=1, !write(*,*) buffer(1)(1:4) read(buffer(1)(1:LEN_TRIM(buffer(1))),*) i !write(*,*) i ENDDO end and also 10 times slower than the scalar variant (which was fixed by Thomas): character buffer*10 integer i,j j = 1234 write(buffer,'(i4)') j DO j=1, !write(*,*) buffer(1:4) read(buffer,*) i !write(*,*) i ENDDO end which takes 0.23s on my box. So on the on hand the improvement is great, on the other hand it is really sad, because the user will still need to do manual LEN_TRIM's when reading larger strings to get optimal performance... Thanks, Manfred The speedup is accomplished by simply skipping over spaces without calling next_read, then backing up one character and letting the existing execution path proceed, preserving all the end of record code needed in next_char. I also remove some unneeded error checks. Regression tested on X86_64 gnu. No need for a new test case since no new functionality is added. OK for trunk? The PR is marked as a regression, so I think this could be the last piece and call it done. Regards, Jerry 2014-03-08 Jerry DeLisle PR libfortran/38199 * io/list_read.c (next_char): Delete unuseful error checks. (eat_spaces): For character array reading, skip ahead over spaces rather than call next_char multiple times.
Re: [Patch, libgfortran] Add a comment to libgfortran.h explaining what the (un)likely() macros do
On Sat, Mar 08, 2014 at 07:50:53PM +0100, Tobias Burnus wrote: > OK for the trunk? > > diff --git a/libgfortran/libgfortran.h b/libgfortran/libgfortran.h > index d7e15ad..2664e1f 100644 > --- a/libgfortran/libgfortran.h > +++ b/libgfortran/libgfortran.h > @@ -97,6 +97,16 @@ typedef off_t gfc_offset; > #define NULL (void *) 0 > #endif > > + > +/* The following macros can be used to annotate conditions which are likely > or > + unlikely to be true. Avoid using them when a condition is only slightly > + more likely/less unlikely than average to avoid the performance penalties > of > + branch misprediction. In addition, as __builtin_expect overrides the > compiler > + heuristic, do not use in conditions where one of the branches ends with a > + call to a function with __attributee__((noreturn)): the compiler internal s/__attributee/__attribute > + heuristic will mark this branch as much less likely as unlikely() would > + do. */ OK with the above change. -- Steve
Re: [patch, libfortran] [4.7/4.8/4.9 Regression] PR38199 missed optimization: I/O performance
Am 08.03.2014 07:38, schrieb Jerry DeLisle: The attached patch addresses the problem identified in comment #22 of the PR. For character array internal unit reads, eat_spaces must call next_char to advance every single character until the end of the string is reached. In the case sited which is very contrived, this amounts to about 10 calls to next_char. For clarity, this test case: character buffer(1)*10 integer i,j j = 1234 write(buffer(1),'(i4)') j DO j=1, !write(*,*) buffer(1)(1:4) read(buffer,*) i !write(*,*) i ENDDO end Without the patch takes about 25 seconds to run. With the patch this takes about 2.8 seconds. This is great. However, this is still 10 times slower than the LEN_TRIM variant: character buffer(1)*10 integer i,j j = 1234 write(buffer(1),'(i4)') j DO j=1, !write(*,*) buffer(1)(1:4) read(buffer(1)(1:LEN_TRIM(buffer(1))),*) i !write(*,*) i ENDDO end which takes 0.23s on my box. So on the on hand the improvement is great, on the other hand it is really sad, because the user will still need to do manual LEN_TRIM's when reading larger strings to get optimal performance... Thanks, Manfred The speedup is accomplished by simply skipping over spaces without calling next_read, then backing up one character and letting the existing execution path proceed, preserving all the end of record code needed in next_char. I also remove some unneeded error checks. Regression tested on X86_64 gnu. No need for a new test case since no new functionality is added. OK for trunk? The PR is marked as a regression, so I think this could be the last piece and call it done. Regards, Jerry 2014-03-08 Jerry DeLisle PR libfortran/38199 * io/list_read.c (next_char): Delete unuseful error checks. (eat_spaces): For character array reading, skip ahead over spaces rather than call next_char multiple times.
Re: [patch, libfortran] [4.7/4.8/4.9 Regression] PR38199 missed optimization: I/O performance
Jerry DeLisle wrote: Here is the revised patch leaving the error checks in place and using unlikely(). I have also added handling of kind=4 character arrays. Regression tested on x86-64. OK for trunk? OK. Minor nit: + if ( unlikely(length < 0)) The space shall be after unlikely not before. Tobias
Re: [PATCH] Update -flto docs wrt option handling
Thanks for the time and diligence writing this up, Richi!
On Thu, 6 Mar 2014, Richard Biener wrote:
> -files; if @option{-flto} is not passed to the linker, no
> -interprocedural optimizations are applied.
> +files; if @option{-fno-lto} is not passed to the linker, no
> +interprocedural optimizations are applied.
That looks like one "no" too much?
> Note that when
> +@option{-fno-fat-lto-objects} is enabled the compile-stage is faster
> +but you cannot perform a regular, non-LTO link, on them.
The comma past "link" appears too much.
> Additionally, the optimization flags used to compile individual files
> are not necessarily related to those used at link time. For instance,
That requires -ffat-lto-objects, though? The text above talks more
about -fno-fat-lto-objects, not the positive form.
> @smallexample
> -gcc -c -O0 -flto foo.c
> -gcc -c -O0 -flto bar.c
> -gcc -o myprog -flto -O3 foo.o bar.o
> +gcc -c -O0 -ffat-lto-objects -flto foo.c
> +gcc -c -O0 -ffat-lto-objects -flto bar.c
> +gcc -o myprog -O3 foo.o bar.o
> @end smallexample
>
> This produces individual object files with unoptimized assembler
> code, but the resulting binary @file{myprog} is optimized at
> -@option{-O3}. If, instead, the final binary is generated without
> -@option{-flto}, then @file{myprog} is not optimized.
> +@option{-O3}. If, instead, the final binary is generated with
> +@option{-fno-lto}, then @file{myprog} is not optimized.
Would it make sense to use -Os in the example? I assume in the
last case myprog would then by optimized with -Os?
I am suggesting this since I believe it's not optimization vs
no optimization but "optimization level provided during compilation"?
> +Currently, the following options and their setting are take from
> +the first object file that explicitely specified it:
> +@option{-fPIC}, @option{-fpic}, @option{-fpie}, @option{-fcommon},
> +@option{-fexceptions}, @option{-fnon-call-exceptions}, @option{-fgnu-tm}
> +and all the @option{-m} target flags.
No -O options in case none are provided during link time?
> +Certain ABI changing flags are required to match in all compilation-units
> +and trying to override this at link-time with a conflicting value
> +is ignored. This includes options such as @option{-freg-struct-return}
> +and @option{-fpcc-struct-return}.
If they are required to match, shouldn't a conflicting value during
link time trigger a diagnoses -- error or at least warning?
> +Other options such as @option{-ffp-contract}, @option{-fno-strict-overflow},
> +@option{-fwrapv}, @option{-fno-trapv} or @option{-fno-strict-aliasing}
> +are passed through to the link stage and merged conservatively for
> +conflicting translation units. You can override them at linke-time.
What does conservative merging imply? How does that work?
> +same link with the same options and also specify those options at
> +link-time.
"link time" (noun)
> -GCC will not work with an older/newer version of GCC@.
> +GCC will not work with an older/newer version of GCC.
What is a version here? Release series?
Will GCC 4.9.0 and 4.9.1 work, or not?
Gerald
Re: [PATCH] Add support for powerpc ISA 2.07 128-bit add/subtract builtins
On Wed, Mar 5, 2014 at 3:57 PM, Michael Meissner wrote: > This patch adds support for the PowerPC ISA 2.07 (power8) 128-bit add/subtract > instructions that use the Altivec (VMX) register set (vaddumq, etc.). > > Unfortunately at the moment, TImode (__int128_t) is not allowed to use the > VSX/VMX register set, unless you use the undocumented switch -mvsx-timode. > This was disabled because there were several bugs that showed up during the > original ISA 2.07 patches. I spent some time trying to work out all of the > problems with -mvsx-timode, but I was not able to do so at present. > > These patches add support for the builtins when the code is running in 64-bit > mode. If TImode is not allowed to go into the VMX registers, the code uses > V2DImode to do the operation. Simple minded tests show that the compiler can > do loads directly into the VMX registers, but after the operation, it does a > permute, 2 direct move instructions, and a store quad from the GPR register > set. Ideally, a future patch will fix -mvsx-timode so it can be default. > > In these patches, I updated test timode_off.c. This test would fail if > -mvsx-timode is enabled because in that mode, TImode addresses can only be a > single register, so that the address can be used either to load GPRs or VSX > registers without reloading. This causes the test code to be slightly bigger, > and the test then fails when the code size gets to be larger than 616 bytes. > > I have tested these patches on power7 and power8 machines with no regressions. > I have tested the executable test on both big endian and little endian power8 > systems, and it produces the correct values in both cases. Are the patches ok > to install? > > [gcc] > 2014-03-05 Michael Meissner > > * doc/extend.texi (PowerPC AltiVec/VSX Built-in Functions): > Document vec_vaddcuq, vec_vadduqm, vec_vaddecuq, vec_vaddeuqm, > vec_subecuq, vec_subeuqm, vec_vsubcuq, vec_vsubeqm builtins adding > 128-bit integer add/subtract to ISA 2.07. > > * config/rs6000/rs6000-protos.h (rs6000_move_128bit_ok_p): Add new > declaration. > (rs6000_split_128bit_ok_p): Likewise. > (rs6000_int128_builtin_fixup): Likewise. > > * gcc/config/rs6000/rs6000-builtin.def (BU_P8V_AV_3): Add new > macros to support adding ISA 2.07 3 argument builtins. > (BU_P8V_OVERLOAD_3): Likewise. > (VADDCUQ): Add ISA 2.07 builtins to support 128-bit integer > add/subtract instructions, both as a normal builtin, and as an > overloaded builtin. > (VADDUQM): Likewise. > (VSUBCUQ): Likewise. > (VSUBUQM): Likewise. > (VADDECUQ): Likewise. > (VADDECUQ): Likewise. > (VSUBECUQ): Likewise. > (VSUBEUQM): Likewise. > > * gcc/config/rs6000-c.c (altivec_overloaded_builtins): Add support > for ISA 2.07 overloaded builtins to do 128-bit add and subtract. > > * gcc/config/rs6000.c (rs6000_init_builtins): Initialize state > variables for using __int128_t and __uint128_t as arguments to > builtins. > (rs6000_move_128bit_ok_p): New function to validate TImode/PTImode > moves. > (rs6000_split_128bit_ok_p): New function to say when it is ok to > split TImode/PTImove moves. > (rs6000_int128_builtin_fixup): New function to convert int 128-bit > add/subtract from using TImode to using V2DImode to allow use of > the ISA 2.07 builtins when TImode is not allowed in VSX > registers. > > * gcc/config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add > support to allow __int128_t and __uint128_t types as builtin > arguments. > (intTI_type_internal_node): Likewise. > (uintTI_type_internal_node): Likewise. > > * gcc/config/rs6000/altivec.md (UNSPEC_VADDUQM): New unspec > literals to allow addition of the ISA 2.07 128-bit add/subtract > builtin functions. > (UNSPEC_VADDCUQ): Likewise. > (UNSPEC_VADDEUQM): Likewise. > (UNSPEC_VADDECUQ): Likewise. > (UNSPEC_VSUBUQM): Likewise. > (UNSPEC_VSUBCUQ): Likewise. > (UNSPEC_VSUBEUQM): Likewise. > (UNSPEC_VSUBECUQ): Likewise. > (VINT128): New iterator for 128-bit add/subtract builtins. > (altivec_vadduqm): New ISA 2.07 128-bit add/subtract builtins. > (altivec_vadduqm_): Likewise. > (altivec_vaddcuq): Likewise. > (altivec_vaddcuq_): Likewise. > (altivec_vaddeuqm): Likewise. > (altivec_vaddeuqm_): Likewise. > (altivec_vaddecuq): Likewise. > (altivec_vaddecuq_): Likewise. > (altivec_vsubuqm): Likewise. > (altivec_vsubuqm_): Likewise. > (altivec_vsubcuq): Likewise. > (altivec_vsubcuq_): Likewise. > (altivec_vsubeuqm): Likewise. > (altivec_vsubeuqm_): Likewise. > (altivec_vsubecuq): Likewise. >
Re: Backports to 4.8 branch
On Thu, 6 Mar 2014, Jakub Jelinek wrote: > I've backported a few bugfixes to 4.8 branch, bootstrapped/regtested > on x86_64-linux and i686-linux, committed to branch. This reminds my: what are your plans doing new release off that branch? The last one has been five months ago. What is the rough interval between releases you have in mind? And how about GCC 4.7.4? Any plans for that and closing the branch afterwards? Or do you plan to keep 4.7 alive for longer? Gerald
Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
> Everything except _Cilk_for should be supported. Imagine you're a new cilk user. For you it's totally obvious what "everything" is. But someone new to it they won't it know anything about "everything". So you have to tell them. -Andi
Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
Iyer, Balaji V wrote:
1.2 is 1.1 ABI with the language spec reformatted. No new features has
been added in between 1.1 and 1.2. So, you can say either one.
Or should we simply remove the ABI version completely? I have attached
such a patch
I would put the ABI version, since the Cilk users will ask for it.
Fine with me - but then it makes sense to put the latest version (ABI
1.2): Users not knowing Cilk well, then see that the latest is supported
while knowledge users know that 1.2 is just a cleanup.
I have now committed the attached patches.
Tobias
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.61
retrieving revision 1.62
diff -p -r1.61 -r1.62
*** changes.html 8 Mar 2014 18:09:45 - 1.61
--- changes.html 8 Mar 2014 20:39:20 - 1.62
***
*** 157,162
--- 157,169
loop-carried dependencies which would prevent concurrent execution of
consecutive iterations using SIMD (single instruction multiple data)
instructions.
+
+ Support for https://www.cilkplus.org/";;>Cilk Plus has been
+ added and can be enabled with the -fcilkplus option. Cilk Plus
+ is an extension to the C and C++ languages to support data and task
+ parallelism. The present implementation follows ABI version 1.2; all
+ features but _Cilk_for have been implemented.
+
C
2014-03-08 Tobias Burnus
* doc/invoke.texi (-fcilkplus): Update implementation
status.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (Revision 208431)
+++ gcc/doc/invoke.texi (Arbeitskopie)
@@ -1889,12 +1889,11 @@ are ignored.
Enable the usage of Cilk Plus language extension features for C/C++.
When the option @option{-fcilkplus} is specified, enable the usage of
the Cilk Plus Language extension features for C/C++. The present
-implementation follows ABI version 0.9. This is an experimental
+implementation follows ABI version 1.2. This is an experimental
feature that is only partially complete, and whose interface may
change in future versions of GCC as the official specification
-changes. Currently only the array notation feature of the language
-specification has been implemented. More features will be implemented
-in subsequent release cycles.
+changes. Currently, all features but @code{_Cilk_for} have been
+implemented.
@item -fgnu-tm
@opindex fgnu-tm
RE: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
> -Original Message- > From: Andi Kleen [mailto:a...@firstfloor.org] > Sent: Saturday, March 8, 2014 3:38 PM > To: Iyer, Balaji V > Cc: Andi Kleen; Tobias Burnus; Gerald Pfeifer; gcc-patches; Jakub Jelinek > Subject: Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes > > > _Cilk_spawn is the correct keyword. "cilk_spawn" can be used if the > > user includes which has the following 3 lines (and > > that's the whole file) > > > > #define cilk_spawn _Cilk_spawn > > #define cilk_sync _Cilk_sync > > #define cilk_for _Cilk_for > > > > > > In Cilk there are basically 3 keywords: _Cilk_spawn, _Cilk_sync and > _Cilk_for. _Cilk_for patch is still under review but _Cilk_spawn and > _Cilk_sync keywords are supported. > > Thanks for explaining. But that should be somewhere in the documentation. > I think you could just put that paragraph in there. > > How about all the pragmas, or do these only only exist on icc? They should be supported. > How about special functions? Yes. > > Basically should have a list of what cilkplus means here. > Everything except _Cilk_for should be supported. > -Andi > > -- > a...@linux.intel.com -- Speaking for myself only.
Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
> _Cilk_spawn is the correct keyword. "cilk_spawn" can be used if the user > includes which has the following 3 lines (and that's the whole > file) > > #define cilk_spawn _Cilk_spawn > #define cilk_sync _Cilk_sync > #define cilk_for _Cilk_for > > > In Cilk there are basically 3 keywords: _Cilk_spawn, _Cilk_sync and > _Cilk_for. _Cilk_for patch is still under review but _Cilk_spawn and > _Cilk_sync keywords are supported. Thanks for explaining. But that should be somewhere in the documentation. I think you could just put that paragraph in there. How about all the pragmas, or do these only only exist on icc? How about special functions? Basically should have a list of what cilkplus means here. -Andi -- a...@linux.intel.com -- Speaking for myself only.
RE: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
> -Original Message- > From: Tobias Burnus [mailto:bur...@net-b.de] > Sent: Saturday, March 8, 2014 3:32 PM > To: Andi Kleen; Iyer, Balaji V > Cc: Gerald Pfeifer; gcc-patches; Jakub Jelinek > Subject: Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes > > Am 08.03.2014 21:13, schrieb Andi Kleen: > > Also it would be good to specify exactly what parts of Cilk are > > supported currently. It's some what hard to figure out. > > My understanding is that everything but cilk_for is supported. Yes you are correct. > > > One trap I ran into (perhaps naively) is that I tried to use > > cilk_spawn (as documented in some tutorials) instead of _Cilk_spawn > > It should work with: >#include ^ should be cilk/cilk.h > I responded more details in my previous email.. > However, the following file is not installed: libcilkrts/include/cilk/cilk.h > I think > something like the following should work (untested). > > Tobias > > --- a/libcilkrts/Makefile.am > +++ b/libcilkrts/Makefile.am > @@ -53,4 +53,5 @@ gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER) > # Target list. > toolexeclib_LTLIBRARIES = libcilkrts.la > +nodist_libsubinclude_HEADERS = include/cilk/cilk.h > > libcilkrts_la_SOURCES =\
Re: Cilk with -lcilkrts (was: Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes)
On Sat, Mar 08, 2014 at 09:22:54PM +0100, Tobias Burnus wrote: > Andi Kleen wrote: > >It would be also good if the documentation mentioned that you have > >to specify -lcilkrts > > Wouldn't it make more sense to automatically add the option? For > instance like the following? Or do we need to do the same as for > libgomp and create a .spec file? Yes something like this would be the right way. I don't understand spec well enough to say if your patch is enough. (but have to document then that -fcilkplus is also needed on the link command) -Andi
Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
On Sat, 8 Mar 2014, Tobias Burnus wrote: > OK for the trunk / the webserver? Okay. Go for the previous version with the ABI reference based on what Iyer wrote. On Sat, 8 Mar 2014, Iyer, Balaji V wrote: > 1.2 is 1.1 ABI with the language spec reformatted. No new features > has been added in between 1.1 and 1.2. So, you can say either one. In that case we should use the higher one. :-) Gerald
Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
Am 08.03.2014 21:13, schrieb Andi Kleen: Also it would be good to specify exactly what parts of Cilk are supported currently. It's some what hard to figure out. My understanding is that everything but cilk_for is supported. One trap I ran into (perhaps naively) is that I tried to use cilk_spawn (as documented in some tutorials) instead of _Cilk_spawn It should work with: #include However, the following file is not installed: libcilkrts/include/cilk/cilk.h I think something like the following should work (untested). Tobias --- a/libcilkrts/Makefile.am +++ b/libcilkrts/Makefile.am @@ -53,4 +53,5 @@ gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER) # Target list. toolexeclib_LTLIBRARIES = libcilkrts.la +nodist_libsubinclude_HEADERS = include/cilk/cilk.h libcilkrts_la_SOURCES =\
RE: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
> -Original Message- > From: Tobias Burnus [mailto:bur...@net-b.de] > Sent: Saturday, March 8, 2014 3:06 PM > To: Iyer, Balaji V; Gerald Pfeifer > Cc: gcc-patches; Jakub Jelinek > Subject: Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes > > Tobias Burnus wrote: > > Iyer, Balaji V wrote: > >> Thank you for catching this. Yes, it should be ABI 1.1 > > Actually, shouldn't this ABI 1.2? On http://www.cilkplus.org/ - one finds the > statement: "The new specification (version 1.2) contains numerous > corrections and clarifications. No new features were added, but the existing > features are much more precisely described." - Hence, ABI 1.1 should also > match ABI version 1.2. 1.2 is 1.1 ABI with the language spec reformatted. No new features has been added in between 1.1 and 1.2. So, you can say either one. > > Or should we simply remove the ABI version completely? I have attached > such a patch? > I would put the ABI version, since the Cilk users will ask for it. > OK for the trunk / the webserver? > > Tobias >
RE: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
> -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Andi Kleen > Sent: Saturday, March 8, 2014 3:13 PM > To: Iyer, Balaji V > Cc: Tobias Burnus; Gerald Pfeifer; gcc-patches; Jakub Jelinek > Subject: Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes > > Andi Kleen writes: > > > "Iyer, Balaji V" writes: > >> > >> The sentence "Current only..." should be changed to something like this: > >> > >> Currently all the features except _Cilk_for has been implemented. > > > > It would be also good if the documentation mentioned that you have to > > specify -lcilkrts > > Also it would be good to specify exactly what parts of Cilk are supported > currently. It's some what hard to figure out. > > One trap I ran into (perhaps naively) is that I tried to use cilk_spawn (as > documented in some tutorials) instead of _Cilk_spawn _Cilk_spawn is the correct keyword. "cilk_spawn" can be used if the user includes which has the following 3 lines (and that's the whole file) #define cilk_spawn _Cilk_spawn #define cilk_sync _Cilk_sync #define cilk_for _Cilk_for In Cilk there are basically 3 keywords: _Cilk_spawn, _Cilk_sync and _Cilk_for. _Cilk_for patch is still under review but _Cilk_spawn and _Cilk_sync keywords are supported. > > -Andi
Cilk with -lcilkrts (was: Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes)
Andi Kleen wrote:
It would be also good if the documentation mentioned that you have to
specify -lcilkrts
Wouldn't it make more sense to automatically add the option? For
instance like the following? Or do we need to do the same as for libgomp
and create a .spec file?
Tobias
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -768,2 +768,3 @@ proper position among the other output files. */
%{fopenmp|ftree-parallelize-loops=*:%:include(libgomp.spec)%(link_gomp)}\
+%{fcilkplus:-lcilkrts}\
%{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
Re: [patch, libfortran] [4.7/4.8/4.9 Regression] PR38199 missed optimization: I/O performance
On 03/08/2014 04:58 AM, Steven Bosscher wrote:
> On Sat, Mar 8, 2014 at 7:38 AM, Jerry DeLisle wrote:
>> The speedup is accomplished by simply skipping over spaces without calling
>> next_read, then backing up one character and letting the existing execution
>> path
>> proceed, preserving all the end of record code needed in next_char.
>>
>> I also remove some unneeded error checks.
>
> Would it be enough to make them "unlikely" instead?
>
> - if (length < 0)
> + if (unlikely(length < 0))
>
Here is the revised patch leaving the error checks in place and using
unlikely().
I have also added handling of kind=4 character arrays.
Regression tested on x86-64.
OK for trunk?
Jerry
Index: list_read.c
===
--- list_read.c (revision 208303)
+++ list_read.c (working copy)
@@ -160,7 +160,7 @@ next_char (st_parameter_dt *dtp)
dtp->u.p.line_buffer_pos = 0;
dtp->u.p.line_buffer_enabled = 0;
-}
+}
/* Handle the end-of-record and end-of-file conditions for
internal array unit. */
@@ -208,16 +208,16 @@ next_char (st_parameter_dt *dtp)
c = cc;
}
- if (length < 0)
+ if ( unlikely(length < 0))
{
generate_error (&dtp->common, LIBERROR_OS, NULL);
return '\0';
}
-
+
if (is_array_io (dtp))
{
/* Check whether we hit EOF. */
- if (length == 0)
+ if (unlikely (length == 0))
{
generate_error (&dtp->common, LIBERROR_INTERNAL_UNIT, NULL);
return '\0';
@@ -264,6 +264,48 @@ eat_spaces (st_parameter_dt *dtp)
{
int c;
+ /* If internal character array IO, peak ahead and seek past spaces.
+ This is an optimazation to eliminate numerous calls to
+ next character unique to character arrays with large character
+ lengths (PR38199). */
+ if (is_array_io (dtp))
+{
+ gfc_offset offset = stell (dtp->u.p.current_unit->s);
+ gfc_offset limit = dtp->u.p.current_unit->bytes_left;
+
+ if (dtp->common.unit) /* kind=4 */
+ {
+ gfc_char4_t cc;
+ limit *= (sizeof (gfc_char4_t));
+ do
+ {
+ cc = dtp->internal_unit[offset];
+ offset += (sizeof (gfc_char4_t));
+ dtp->u.p.current_unit->bytes_left--;
+ }
+ while (offset < limit && (cc == (gfc_char4_t)' '
+ || cc == (gfc_char4_t)'\t'));
+ /* Back up, seek ahead, and fall through to complete the
+ process so that END conditions are handled correctly. */
+ dtp->u.p.current_unit->bytes_left++;
+ sseek (dtp->u.p.current_unit->s,
+ offset-(sizeof (gfc_char4_t)), SEEK_SET);
+ }
+ else
+ {
+ do
+ {
+ c = dtp->internal_unit[offset++];
+ dtp->u.p.current_unit->bytes_left--;
+ }
+ while (offset < limit && (c == ' ' || c == '\t'));
+ /* Back up, seek ahead, and fall through to complete the
+ process so that END conditions are handled correctly. */
+ dtp->u.p.current_unit->bytes_left++;
+ sseek (dtp->u.p.current_unit->s, offset-1, SEEK_SET);
+ }
+}
+ /* Now skip spaces, EOF and EOL are handled in next_char. */
do
c = next_char (dtp);
while (c != EOF && (c == ' ' || c == '\t'));
Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
Andi Kleen writes: > "Iyer, Balaji V" writes: >> >> The sentence "Current only..." should be changed to something like this: >> >> Currently all the features except _Cilk_for has been implemented. > > It would be also good if the documentation mentioned that you have to > specify -lcilkrts Also it would be good to specify exactly what parts of Cilk are supported currently. It's some what hard to figure out. One trap I ran into (perhaps naively) is that I tried to use cilk_spawn (as documented in some tutorials) instead of _Cilk_spawn -Andi
Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
Tobias Burnus wrote:
Iyer, Balaji V wrote:
Thank you for catching this. Yes, it should be ABI 1.1
Actually, shouldn't this ABI 1.2? On http://www.cilkplus.org/ - one
finds the statement: "The new specification (version 1.2) contains
numerous corrections and clarifications. No new features were added,
but the existing features are much more precisely described." - Hence,
ABI 1.1 should also match ABI version 1.2.
Or should we simply remove the ABI version completely? I have attached
such a patch?
OK for the trunk / the webserver?
Tobias
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.61
diff -p -r1.61 changes.html
*** changes.html 8 Mar 2014 18:09:45 - 1.61
--- changes.html 8 Mar 2014 20:03:32 -
***
*** 157,162
--- 157,169
loop-carried dependencies which would prevent concurrent execution of
consecutive iterations using SIMD (single instruction multiple data)
instructions.
+
+ Support for https://www.cilkplus.org/";>Cilk Plus has been
+ added and can be enabled with the -fcilkplus option. Cilk Plus
+ is an extension to the C and C++ languages to support data and task
+ parallelism. All features but _Cilk_for have been
+ implemented.
+
C
2014-03-08 Tobias Burnus
* doc/invoke.texi (-fcilkplus): Update implementation
status.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2ee091a..8cb551f 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1888,13 +1888,11 @@ are ignored.
@cindex Enable Cilk Plus
Enable the usage of Cilk Plus language extension features for C/C++.
When the option @option{-fcilkplus} is specified, enable the usage of
-the Cilk Plus Language extension features for C/C++. The present
-implementation follows ABI version 0.9. This is an experimental
-feature that is only partially complete, and whose interface may
-change in future versions of GCC as the official specification
-changes. Currently only the array notation feature of the language
-specification has been implemented. More features will be implemented
-in subsequent release cycles.
+the Cilk Plus Language extension features for C/C++. This is an
+experimental feature that is only partially complete, and whose
+interface may change in future versions of GCC as the official
+specification changes. Currently, all features but @code{_Cilk_for}
+have been implemented.
@item -fgnu-tm
@opindex fgnu-tm
Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
"Iyer, Balaji V" writes: > > The sentence "Current only..." should be changed to something like this: > > Currently all the features except _Cilk_for has been implemented. It would be also good if the documentation mentioned that you have to specify -lcilkrts -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
Iyer, Balaji V wrote:
Thank you for catching this. Yes, it should be ABI 1.1
...
The sentence "Current only..." should be changed to something like
this: Currently all the features except _Cilk_for has been implemented.
How about the following patch to changes.html - and to doc/invoke.texi?
Regarding _Cilk_for, I assume that the missing bits are in
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01283.html ? It is a bit
unfortunate that 4.9 will miss that bits :-/
Tobias
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.61
diff -p -r1.61 changes.html
*** changes.html 8 Mar 2014 18:09:45 - 1.61
--- changes.html 8 Mar 2014 19:45:08 -
***
*** 157,162
--- 157,169
loop-carried dependencies which would prevent concurrent execution of
consecutive iterations using SIMD (single instruction multiple data)
instructions.
+
+ Support for https://www.cilkplus.org/";>Cilk Plus has been
+ added and can be enabled with the -fcilkplus option. Cilk Plus
+ is an extension to the C and C++ languages to support data and task
+ parallelism. The present implementation follows ABI version 1.1; all
+ features but _Cilk_for have been implemented.
+
C
2014-03-08 Tobias Burnus
* doc/invoke.texi (-fcilkplus): Update implementation
status.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2ee091a..c6530ba 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1889,12 +1889,11 @@ are ignored.
Enable the usage of Cilk Plus language extension features for C/C++.
When the option @option{-fcilkplus} is specified, enable the usage of
the Cilk Plus Language extension features for C/C++. The present
-implementation follows ABI version 0.9. This is an experimental
+implementation follows ABI version 1.1. This is an experimental
feature that is only partially complete, and whose interface may
change in future versions of GCC as the official specification
-changes. Currently only the array notation feature of the language
-specification has been implemented. More features will be implemented
-in subsequent release cycles.
+changes. Currently, all features but @code{_Cilk_for} have been
+implemented.
@item -fgnu-tm
@opindex fgnu-tm
Re: [PATCH 2/4] [GOMP4] [Fortran] OpenACC 1.0+ support in fortran front-end
[Resend as it was initially HTML - sorry for those who are CCed.]
Ilmir Usmanov wrote:
OpenACC 1.0 fortran FE support -- matching and resolving.
+gfc_match_oacc_cache (void)
+{
...
+ if (gfc_current_state() != COMP_DO)
{
- gfc_free_omp_clauses (c);
+ gfc_error ("ACC CACHE directive must be inside of loop %C");
+ gfc_free_omp_clauses(c);
return MATCH_ERROR;
}
Shouldn't it also be supported in DO CONCURRENT? The following is
currently rejected:
real :: b
!$acc loop
outer: do concurrent(i=1:5)
!$acc cache(b)
end do outer
end
(Side question: Is !$acc permitted in DO ... WHILE? If so, you need to
also add EXEC_DO_WHILE.)
+static void
+resolve_oacc_positive_int_expr (gfc_expr *expr, const char *clause)
+{
+ resolve_oacc_scalar_int_expr (expr, clause);
+ if (expr->expr_type == EXPR_CONSTANT && expr->ts.type == BT_INTEGER
+ && expr->value.integer->_mp_size <= 0)
+gfc_warning ("INTEGER expression of %s clause at %L must be positive",
+clause, &expr->where);
You shouldn't access internal variables of mpz_t. Use mpz_sgn() instead:
https://gmplib.org/manual/Integer-Comparisons.html
+ if ((sym->ts.type == BT_ASSUMED && sym->attr.pointer)
+ || (sym->ts.type == BT_ASSUMED && CLASS_DATA (sym)
+ && CLASS_DATA (sym)->attr.pointer))
The second line should use BT_CLASS instead of BT_ASSUMED.
+gfc_error ("POINTER object '%s' of polymorphic type in %s clause at %L",
+ sym->name, name, &loc);
+ if ((sym->ts.type == BT_ASSUMED && sym->attr.cray_pointer)
+ || (sym->ts.type == BT_ASSUMED && CLASS_DATA (sym)
+ && CLASS_DATA (sym)->attr.cray_pointer))
Ditto.
+gfc_error ("Cray pointer object of polymorphic type '%s' in %s clause at
%L",
+ sym->name, name, &loc);
+ if ((sym->ts.type == BT_ASSUMED && sym->attr.cray_pointee)
+ || (sym->ts.type == BT_ASSUMED && CLASS_DATA (sym)
+ && CLASS_DATA (sym)->attr.cray_pointee))
+gfc_error ("Cray pointee object of polymorphic type '%s' in %s clause at
%L",
+ sym->name, name, &loc);
Ditto.
+static void
+check_array_not_assumed (gfc_symbol *sym, locus loc, const char *name)
+{
+ if (sym->as && sym->as->type == AS_ASSUMED_SIZE)
+gfc_error ("Assumed size array '%s' in %s clause at %L",
+ sym->name, name, &loc);
+ if (sym->as && sym->as->type == AS_ASSUMED_SHAPE)
+gfc_error ("Assumed shape array '%s' in %s clause at %L",
+ sym->name, name, &loc);
+ if (sym->as && sym->as->type == AS_ASSUMED_RANK)
+gfc_error ("Assumed rank array '%s' in %s clause at %L",
+ sym->name, name, &loc);
+}
Actually, I wonder whether one needs to reject assumed-shape: I don't
know what OpenACC says, but my impression is that the problem is that
those can be noncontiguous. However, if they are marked as contiguous
["attr.contiguous"] …
On the other hand, your code seems to permit deferred-shape arrays like:
real, pointer :: b(:)
!$acc data copyin(b)
end
The problem is that pointers to deferred-shape arrays can be
noncontiguous. But deferred-shape array are always contiguous when they
are either attr.allocatable or have the "attr.contiguous" attribute.
+ if ((sym->ts.type == BT_ASSUMED && sym->attr.allocatable)
+ || (sym->ts.type == BT_ASSUMED && CLASS_DATA (sym)
+ && CLASS_DATA (sym)->attr.allocatable))
As above: BT_CLASS in the second line.
+resolve_oacc_deviceptr_clause (gfc_symbol *sym, locus loc, const char *name)
+{
+ if (sym->ts.type == BT_DERIVED && sym->attr.allocatable)
+gfc_error ("ALLOCATABLE object '%s' of derived type in %s clause at %L",
+ sym->name, name, &loc);
+ if ((sym->ts.type == BT_ASSUMED && sym->attr.allocatable)
+ || (sym->ts.type == BT_ASSUMED && CLASS_DATA (sym)
+ && CLASS_DATA (sym)->attr.allocatable))
Ditto.
+gfc_error ("ALLOCATABLE object '%s' of polymorphic type "
+ "in %s clause at %L", sym->name, name, &loc);
+ if (sym->attr.pointer)
+gfc_error ("POINTER object '%s' in %s clause at %L",
+ sym->name, name, &loc);
Shouldn't you also add
|| (sym->ts.type == BT_CLASS && CLASS_DATA (sym) + && CLASS_DATA
(sym)->attr.class_pointer)
here?
+ case OMP_LIST_USE_DEVICE:
+ if (n->sym->attr.allocatable)
+ gfc_error ("ALLOCATABLE object '%s' in %s clause at %L",
+ n->sym->name, name, &code->loc);
+ if (n->sym->attr.pointer)
+ gfc_error ("POINTER object '%s' in %s clause at %L",
+ n->sym->name, name, &code->loc);
Do you also need to handle BT_CLASS here for allocatable/pointer?
Otherwise, it looks good to me.
Tobias
RE: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Tobias Burnus
> Sent: Saturday, March 8, 2014 2:24 PM
> To: Iyer, Balaji V; Gerald Pfeifer
> Cc: gcc-patches; Jakub Jelinek
> Subject: Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
>
> Iyer, Balaji V wrote:
> > Cilk Plus supports both task and data parallelism and Cilk Plus and
> > thus far all features except _Cilk_for is supported in 4.9. I am not
> > sure what ABI you are referring to but Cilk Plus follows Cilk ABI 1.1.
>
> Well, I am referring to the following in gcc/doc/invoke.texi. From your
> answer, it should be either updated to "ABI version 1.1" - or, probably
> better,
> the ABI version should be removed from invoke.texi. Here is the
> quote:
>
> @item -fcilkplus
> @opindex fcilkplus
> @cindex Enable Cilk Plus
> Enable the usage of Cilk Plus language extension features for C/C++.
> When the option @option{-fcilkplus} is specified, enable the usage of the Cilk
> Plus Language extension features for C/C++. The present implementation
> follows ABI version 0.9. This is an experimental feature that is only
> partially
Thank you for catching this. Yes, it should be ABI 1.1
> complete, and whose interface may change in future versions of GCC as the
> official specification changes. Currently only the array notation feature of
> the
> language specification has been implemented. More features will be
The sentence "Current only..." should be changed to something like this:
Currently all the features except _Cilk_for has been implemented.
Thanks,
Balaji V. Iyer.
Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
Iyer, Balaji V wrote:
Cilk Plus supports both task and data parallelism and Cilk Plus and
thus far all features except _Cilk_for is supported in 4.9. I am not
sure what ABI you are referring to but Cilk Plus follows Cilk ABI 1.1.
Well, I am referring to the following in gcc/doc/invoke.texi. From your
answer, it should be either updated to "ABI version 1.1" - or, probably
better, the ABI version should be removed from invoke.texi. Here is the
quote:
@item -fcilkplus
@opindex fcilkplus
@cindex Enable Cilk Plus
Enable the usage of Cilk Plus language extension features for C/C++.
When the option @option{-fcilkplus} is specified, enable the usage of
the Cilk Plus Language extension features for C/C++. The present
implementation follows ABI version 0.9. This is an experimental
feature that is only partially complete, and whose interface may
change in future versions of GCC as the official specification
changes. Currently only the array notation feature of the language
specification has been implemented. More features will be implemented
in subsequent release cycles.
Tobias
Re: [PATCH ARM]: Fix more -mapcs-frame failures
On Fri, Mar 7, 2014 at 10:24 AM, Christian Bruel wrote: > Hi Ramana, > > Thanks for your comments, > >> Please respin using plus_constant instead of gen_addsi3. > > Here is my feeling about this: > > I experimented on using plus_constant instead of gen_addsi3. But there > are cases when the emitted code is not equivalent for large frames > (!const_ok_for_op (val, PLUS)) and leads to complications. Ah, Yes you are right. I hadn't remembered that when I looked at it yesterday. > > We could fix this case with a call to arm_split_constant (PLUS, Pmode, > NULL, amount, stack_pointer_rtx, stack_pointer_rtx, 0), but I'm not > sure we gain in clarity here. Also for consistency, the same interface > change would preferably be needed in the other parts of the arm.c file > (that I didn't modify) sharing the same sequence. For instance > "arm_expand_epilogue" > Agreed, There's no need to do that given your explanation. Looks good to me - please give an RM 24 working hours i.e. till end of day on 11th March to comment before committing this. Please also remove mfloat-abi=hard from pr60264.c, this will just conflict when people test for Thumb1 or with other conflicting multilibs i.e. with soft-float. There are enough autotesters with the hardfloat abi these days that we'll find any regressions that might be there. regards Ramana >> Otherwise >> this looks good to me. >> >> Please repost updated patch and I will look at it again. > > For the reasons expressed above it'd prefer to consider this new change > as a separate development with a new patch. > > For the time being (considering only the original apcs issue) is it OK > to apply only the patch as it ? and validate a global > gen_addsi3/plus_constant interface review as a separate step ? > > Many thanks, > > Christian > >> >> Ramana >
RE: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
> -Original Message- > From: Gerald Pfeifer [mailto:ger...@pfeifer.com] > Sent: Saturday, March 8, 2014 1:29 PM > To: Tobias Burnus > Cc: gcc-patches; Iyer, Balaji V; Jakub Jelinek > Subject: Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes > > On Sat, 8 Mar 2014, Tobias Burnus wrote: > > the attached patch mentions the support of Cilk Plus in GCC 4.9 in the > > release notes, http://gcc.gnu.org/gcc-4.9/changes.html > > > > Is the patch OK? > > "Plus is an extension...", should this read "Cilk Plus is an extension?" > Yes Cilk Plus is a language extension. It is enabled with -fcilkplus flag. > If so, I suggest to switch the second and third sentences: first explain what > it > is, then go into specifics such as ABI. > Cilk Plus supports both task and data parallelism and Cilk Plus and thus far all features except _Cilk_for is supported in 4.9. I am not sure what ABI you are referring to but Cilk Plus follows Cilk ABI 1.1. > Looks good to me otherwise (modulo the ABI question I cannot answer :-). > > Gerald
[Patch, libgfortran] Add a comment to libgfortran.h explaining what the (un)likely() macros do
OK for the trunk? Tobias diff --git a/libgfortran/libgfortran.h b/libgfortran/libgfortran.h index d7e15ad..2664e1f 100644 --- a/libgfortran/libgfortran.h +++ b/libgfortran/libgfortran.h @@ -97,6 +97,16 @@ typedef off_t gfc_offset; #define NULL (void *) 0 #endif + +/* The following macros can be used to annotate conditions which are likely or + unlikely to be true. Avoid using them when a condition is only slightly + more likely/less unlikely than average to avoid the performance penalties of + branch misprediction. In addition, as __builtin_expect overrides the compiler + heuristic, do not use in conditions where one of the branches ends with a + call to a function with __attributee__((noreturn)): the compiler internal + heuristic will mark this branch as much less likely as unlikely() would + do. */ + #ifndef __GNUC__ #define __attribute__(x) #define likely(x) (x)
Re: [wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
On Sat, 8 Mar 2014, Tobias Burnus wrote: > the attached patch mentions the support of Cilk Plus in GCC 4.9 in the > release notes, http://gcc.gnu.org/gcc-4.9/changes.html > > Is the patch OK? "Plus is an extension...", should this read "Cilk Plus is an extension?" If so, I suggest to switch the second and third sentences: first explain what it is, then go into specifics such as ABI. Looks good to me otherwise (modulo the ABI question I cannot answer :-). Gerald
[wwwdocs] RFC - mention Cilk Plus in the GCC 4.9 release notes
Hi all, the attached patch mentions the support of Cilk Plus in GCC 4.9 in the release notes, http://gcc.gnu.org/gcc-4.9/changes.html Is the patch OK? Tobias PS: Is it correct that the current implementation only supports ABI 0.9 of Oct 2010 and not ABI 1.1 of Jul 2011? (Current is 1.2 of Sep 2013, cf. http://www.cilkplus.org/download#open-specification) The ABI version 0.9 is taken from gcc/doc/invoke.texi [The library has CILKLIB1.02.] Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v retrieving revision 1.61 diff -p -r1.61 changes.html *** changes.html 8 Mar 2014 18:09:45 - 1.61 --- changes.html 8 Mar 2014 18:15:06 - *** *** 157,162 --- 157,167 loop-carried dependencies which would prevent concurrent execution of consecutive iterations using SIMD (single instruction multiple data) instructions. + + Support for https://www.cilkplus.org/";>Cilk Plus has been + added and can be enabled with the -fcilkplus option. The + present implementation follows ABI version 0.9. Plus is an extension to the + C and C++ languages to support data and task parallelism. C
[wwwdocs, patch, submitted] gcc-4.9/changes.html: Update Fortran - add deferred-length char component support
I have committed the attached patch as obvious. Suggestions to the
wording are welcome - as are other suggestions to the release notes.
Tobias
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.60
diff -p -r1.60 changes.html
*** changes.html 7 Mar 2014 18:04:49 - 1.60
--- changes.html 8 Mar 2014 18:08:48 -
*** auto incr = [](auto x) { return x++; };
*** 385,390
--- 385,394
Finalization is now supported. Note that finalization is currently
only done for a subset of the situations in which it should occur.
+ Experimental support for scalar character components with
+ deferred length (i.e. allocatable string length) in derived types has
+ been added. (Deferred-length character variables are supported since
+ GCC 4.6.)
http://gcc.gnu.org/wiki/Fortran2008Status";>Fortran 2008:
Re: [Patch, Fortran] PR60447 - Stop generating *.s file with -E -cpp
On Sat, Mar 08, 2014 at 02:44:16PM +0100, Tobias Burnus wrote: > > gfortran currently tells the ME that it wants it - even if it is not > needed when only preprocessing a file (-E). This patch fixes this by > telling the ME that no_backend is required - and then by triggering an > early exit in lang_dependent_init (all in toplev.c). > > Build and currently regtesting. > OK for the trunk? > Yes. -- Steve
Re: [PATCH 4/4] [GOMP4] [Fortran] OpenACC 1.0+ support in fortran front-end
Ilmir Usmanov wrote: OpenACC 1.0 fortran FE support -- tests. I browsed through the patches and it looked good to me. Tobias gcc/testsuite/gfortran.dg/goacc/ * assumed.f95: New test * branch.f95: Likewise * coarray.f95: Likewise * continuation-free-form.f95: Likewise * cray.f95: Likewise * critical.f95: Likewise * data-clauses.f95: Likewise * data-tree.f95: Likewise * declare-1.f95: Likewise * enter-exit-data.f95: Likewise * goacc.exp: Likewise * host_data-tree.f95: Likewise * if.f95: Likewise * kernels-tree.f95: Likewise * list.f95: Likewise * literal.f95: Likewise * loop-1.f95: Likewise * loop-2.f95: Likewise * loop-3.f95: Likewise * omp.f95: Likewise * parallel-kernels-clauses.f95: Likewise * parallel-kernels-regions.f95: Likewise * parallel-tree.f95: Likewise * parameter.f95: Likewise * pure-elemental-procedures.f95: Likewise * reduction.f95: Likewise * sentinel-free-form.f95: Likewise * several-directives.f95: Likewise * sie.f95: Likewise
Re: [PATCH 3/4] [GOMP4] [Fortran] OpenACC 1.0+ support in fortran front-end
Ilmir Usmanov wrote: OpenACC 1.0 fortran FE support -- translation to GENERIC. This part of the patch set looks good to me. Thanks. Tobias gcc/fortran/ * trans-decl.c (gfc_generate_function_code): Insert OACC_DECLARE GENERIC node. * trans-openmp.c (gfc_convert_expr_to_tree): New helper function. (gfc_trans_omp_array_reduction): Support also OpenACC. Add parameter. (gfc_trans_omp_reduction_list): Update. (gfc_trans_oacc_construct): New transform function. (gfc_trans_omp_map_clause_list): Likewise. (gfc_trans_oacc_executable_directive): Likewise. (gfc_trans_oacc_combined_directive, gfc_trans_oacc_declare): Likewise. (gfc_trans_oacc_directive): Use them. (gfc_trans_oacc_loop): Stub. (gfc_trans_omp_clauses): Transform OpenACC clauses. * trans-stmt.h (gfc_trans_oacc_directive): New function prototype. (gfc_trans_oacc_declare): Likewise. * trans.c (trans_code): Transform also OpenACC directives.
[PATCH] SPARC: Mention global register 7 usage for TLS
Are the global registers 5 and 6 really available for the operating system or uses GCC or the linker them for a special purpose? Is it possible to document this somewhere in to standard documentation and not only in a header file? gcc/ChangeLog 2014-03-08 Sebastian Huber * config/sparc/sparc.h: Mention global register 7 usage for TLS. --- gcc/config/sparc/sparc.h | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/gcc/config/sparc/sparc.h b/gcc/config/sparc/sparc.h index dd2b5ad..23c79fc 100644 --- a/gcc/config/sparc/sparc.h +++ b/gcc/config/sparc/sparc.h @@ -637,16 +637,17 @@ extern enum cmodel sparc_cmodel; On non-v9 systems: g1 is free to use as temporary. - g2-g4 are reserved for applications. Gcc normally uses them as + g2-g4 are reserved for applications. GCC normally uses them as temporaries, but this can be disabled via the -mno-app-regs option. - g5 through g7 are reserved for the operating system. + g5 and g6 are reserved for the operating system. + g7 is used for thread-local storage (TLS) in the initial exec TLS model. On v9 systems: g1,g5 are free to use as temporaries, and are free to use between calls if the call is to an external function via the PLT. g4 is free to use as a temporary in the non-embedded case. g4 is reserved in the embedded case. - g2-g3 are reserved for applications. Gcc normally uses them as + g2-g3 are reserved for applications. GCC normally uses them as temporaries, but this can be disabled via the -mno-app-regs option. g6-g7 are reserved for the operating system (or application in embedded case). -- 1.8.1.4
Re: [patch, libfortran] [4.7/4.8/4.9 Regression] PR38199 missed optimization: I/O performance
On 03/08/2014 02:45 AM, Tobias Burnus wrote: --- snip --- > > I think that code is okay. > > I wonder whether it can happen that we read one character too far: i.e. > stell() > == end of string; offset++ -> one behind. As one then immediately steps back > (due to "offset < limit" plus offset--), the code should be handled just fine > - > except for the out of bounds read - which might be detected by, e.g., > -fsanitizer=address (if libgfortran and the program use it). However, I am not > sure whether eat_spaces would be called in that case or whether other > conditions > error out before. > The strings are internally NULL terminated, which helps. I will do some tests to see. >> I also remove some unneeded error checks. > > I have to admit that I do not really understand why the conditions are > unreachable. Is it because "dtp->u.p.current_unit->bytes_left == 0" is already > checked for "is_array_io (dtp)"? If so, can it happen for scalar internal > I/O? I > assume, it is obvious, but I don't quickly see it. The is_array_io (dtp) is checking for an array descriptor. For scalar internal I/O the descriptor is a NULL, so the new code is not executed in that case. I ran a test using a scalar string and the new code is not needed. The errors given are not normal error conditions. If we hit these errors there is a internal library bug and the program would fail out. Since we have had none reported ever I don't think we need it. As Steven suggested I can make them unlikely. Also I just realized I did not address the kind=4 case, so I will do that and resubmit. Thanks for review. Jerry
Re: Fwd: [RFC][gomp4] Offloading patches (2/3): Add tables generation
Hi Bernd,
Here is updated patch for libgomp. It assumes that there is a constructor with
a call to GOMP_offload_register in every target image, created by mkoffload
tool. How does this look?
---
libgomp/libgomp.map |1 +
libgomp/plugin-host.c | 58 -
libgomp/target.c | 170 +
3 files changed, 213 insertions(+), 16 deletions(-)
diff --git a/libgomp/libgomp.map b/libgomp/libgomp.map
index d8631a6..e43cb42 100644
--- a/libgomp/libgomp.map
+++ b/libgomp/libgomp.map
@@ -208,6 +208,7 @@ GOMP_3.0 {
GOMP_4.0 {
global:
+ GOMP_offload_register;
GOMP_barrier_cancel;
GOMP_cancel;
GOMP_cancellation_point;
diff --git a/libgomp/plugin-host.c b/libgomp/plugin-host.c
index 5354ebe..ec0c78c 100644
--- a/libgomp/plugin-host.c
+++ b/libgomp/plugin-host.c
@@ -33,14 +33,53 @@
#include
#include
-bool
-device_available (void)
+const int TARGET_TYPE_HOST = 0;
+
+int
+get_type (void)
{
#ifdef DEBUG
printf ("libgomp plugin: %s:%s\n", __FILE__, __FUNCTION__);
#endif
- return true;
+ return TARGET_TYPE_HOST;
+}
+
+int
+get_num_devices (void)
+{
+#ifdef DEBUG
+ printf ("libgomp plugin: %s:%s\n", __FILE__, __FUNCTION__);
+#endif
+
+ return 1;
+}
+
+void
+offload_register (void *host_table, void *target_data)
+{
+#ifdef DEBUG
+ printf ("libgomp plugin: %s:%s (%p, %p)\n", __FILE__, __FUNCTION__,
+ host_table, target_data);
+#endif
+}
+
+void
+device_init (void)
+{
+#ifdef DEBUG
+ printf ("libgomp plugin: %s:%s\n", __FILE__, __FUNCTION__);
+#endif
+}
+
+int
+device_get_table (void *table)
+{
+#ifdef DEBUG
+ printf ("libgomp plugin: %s:%s (%p)\n", __FILE__, __FUNCTION__, table);
+#endif
+
+ return 0;
}
void *
@@ -82,3 +121,16 @@ void *device_host2dev (void *dest, const void *src, size_t
n)
return memcpy (dest, src, n);
}
+
+void
+device_run (void *fn_ptr, void *vars)
+{
+#ifdef DEBUG
+ printf ("libgomp plugin: %s:%s (%p, %p)\n", __FILE__, __FUNCTION__, fn_ptr,
+ vars);
+#endif
+
+ void (*fn)(void *) = (void (*)(void *)) fn_ptr;
+
+ fn (vars);
+}
diff --git a/libgomp/target.c b/libgomp/target.c
index dbe6e28..8be9ea1 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -87,6 +87,26 @@ struct splay_tree_key_s {
bool copy_from;
};
+enum target_type {
+ TARGET_TYPE_HOST,
+ TARGET_TYPE_INTEL_MIC
+};
+
+/* This structure describes an offload image.
+ It contains type of the target, pointer to host table descriptor, and
pointer
+ to target data. */
+struct offload_image_descr {
+ int type;
+ void *host_table;
+ void *target_data;
+};
+
+/* Array of descriptors of offload images. */
+static struct offload_image_descr *offload_images;
+
+/* Total number of offload images. */
+static int num_offload_images;
+
/* Array of descriptors of all available devices. */
static struct gomp_device_descr *devices;
@@ -120,15 +140,26 @@ struct gomp_device_descr
TARGET construct. */
int id;
+ /* This is the TYPE of device. */
+ int type;
+
+ /* Set to true when device is initialized. */
+ bool is_initialized;
+
/* Plugin file handler. */
void *plugin_handle;
/* Function handlers. */
- bool (*device_available_func) (void);
+ int (*get_type_func) (void);
+ int (*get_num_devices_func) (void);
+ void (*offload_register_func) (void *, void *);
+ void (*device_init_func) (void);
+ int (*device_get_table_func) (void *);
void *(*device_alloc_func) (size_t);
void (*device_free_func) (void *);
- void *(*device_dev2host_func)(void *, const void *, size_t);
- void *(*device_host2dev_func)(void *, const void *, size_t);
+ void *(*device_dev2host_func) (void *, const void *, size_t);
+ void *(*device_host2dev_func) (void *, const void *, size_t);
+ void (*device_run_func) (void *, void *);
/* Splay tree containing information about mapped memory regions. */
struct splay_tree_s dev_splay_tree;
@@ -137,6 +168,13 @@ struct gomp_device_descr
gomp_mutex_t dev_env_lock;
};
+struct mapping_table {
+ uintptr_t host_start;
+ uintptr_t host_end;
+ uintptr_t tgt_start;
+ uintptr_t tgt_end;
+};
+
attribute_hidden int
gomp_get_num_devices (void)
{
@@ -474,6 +512,63 @@ gomp_update (struct gomp_device_descr *devicep, size_t
mapnum,
gomp_mutex_unlock (&devicep->dev_env_lock);
}
+/* This function should be called from every offload image. It gets the
+ descriptor of the host func and var tables HOST_TABLE, TYPE of the target,
+ and TARGET_DATA needed by target plugin (target tables, etc.) */
+void
+GOMP_offload_register (void *host_table, int type, void *target_data)
+{
+ offload_images = realloc (offload_images,
+ (num_offload_images + 1)
+ * sizeof (struct offload_image_descr));
+
+ if (offload_images == NULL)
+return;
+
+ offload_images[num_offload_images].type = type;
+ offload_images[num_offload_images].host_table = host_table;
+ offload_images[num_offl
[Patch, Fortran] PR60447 - Stop generating *.s file with -E -cpp
Hello,
gfortran currently tells the ME that it wants it - even if it is not
needed when only preprocessing a file (-E). This patch fixes this by
telling the ME that no_backend is required - and then by triggering an
early exit in lang_dependent_init (all in toplev.c).
Build and currently regtesting.
OK for the trunk?
Tobias
2014-03-08 Tobias Burnus
PR fortran/60447
* f95-lang.c (gfc_init): Return false when only
preprocessing.
* options.c (gfc_post_options): Ditto.
diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
index aa49ea0..e25e92a 100644
--- a/gcc/fortran/f95-lang.c
+++ b/gcc/fortran/f95-lang.c
@@ -223,6 +223,9 @@ gfc_init (void)
if (!gfc_new_file ())
fatal_error ("can't open input file: %s", gfc_source_file);
+ if (flag_preprocess_only)
+return false;
+
return true;
}
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index 895a7dc..a2b91ca 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -437,14 +437,7 @@ gfc_post_options (const char **pfilename)
gfc_cpp_post_options ();
-/* FIXME: return gfc_cpp_preprocess_only ();
-
- The return value of this function indicates whether the
- backend needs to be initialized. On -E, we don't need
- the backend. However, if we return 'true' here, an
- ICE occurs. Initializing the backend doesn't hurt much,
- hence, for now we can live with it as is. */
- return false;
+ return gfc_cpp_preprocess_only ();
}
Re: [patch, libfortran] [4.7/4.8/4.9 Regression] PR38199 missed optimization: I/O performance
On Sat, Mar 8, 2014 at 7:38 AM, Jerry DeLisle wrote: > The speedup is accomplished by simply skipping over spaces without calling > next_read, then backing up one character and letting the existing execution > path > proceed, preserving all the end of record code needed in next_char. > > I also remove some unneeded error checks. Would it be enough to make them "unlikely" instead? - if (length < 0) + if (unlikely(length < 0)) Ciao! Steven
Re: [patch] Remove two maintainers of avr port
On Sat, Mar 08, 2014 at 04:50:44PM +0400, Anatoly Sokolov wrote: > > Don't maintainers usually retain their write-after-approval status even > > if they step down from the maintainership? > > > Rainer > > > Please retain me write-after-approval status. I must return to active work > on the GCC. > > May I commit this? Sure. > 2014-03-07 Anatoly Sokolov > > * MAINTAINERS: Add myself. > > > Index: MAINTAINERS > === > --- MAINTAINERS (revision 208419) > +++ MAINTAINERS (working copy) > @@ -526,6 +526,7 @@ > Jan Sjodin jan.sjo...@amd.com > Edward Smith-Rowland 3dw...@verizon.net > Jayant Sonar rsonar.jay...@gmail.com > +Anatoly Sokolovae...@post.ru > Michael Sokolov > msoko...@ivan.harhan.org > Richard Stallman r...@gnu.org > Basile Starynkevitch bas...@starynkevitch.net > > Anatoly. Jakub
Re[2]: [patch] Remove two maintainers of avr port
Hello. > Denis Chertykov writes: >> 2014-03-07 Denis Chertykov >> >> * MAINTAINERS: Remove avr maintainers: Anatoly Sokolov and >> Eric Weddington > Don't maintainers usually retain their write-after-approval status even > if they step down from the maintainership? > Rainer Please retain me write-after-approval status. I must return to active work on the GCC. May I commit this? 2014-03-07 Anatoly Sokolov * MAINTAINERS: Add myself. Index: MAINTAINERS === --- MAINTAINERS (revision 208419) +++ MAINTAINERS (working copy) @@ -526,6 +526,7 @@ Jan Sjodin jan.sjo...@amd.com Edward Smith-Rowland 3dw...@verizon.net Jayant Sonar rsonar.jay...@gmail.com +Anatoly Sokolovae...@post.ru Michael Sokolovmsoko...@ivan.harhan.org Richard Stallman r...@gnu.org Basile Starynkevitch bas...@starynkevitch.net Anatoly.
Re: [PATCH] Use the LTO linker plugin by default
Richard Biener writes: > The following patch addresses the common (?) issue of people > omitting -flto from the linker command-line which gets more > severe with GCC 4.9 where slim LTO objects are emitted by > default. The patch simply _always_ arranges for the linker > plugin to be used, so if there are any (slim) LTO objects > on the link LTO will be done on them. Similarly the > non-linker-plugin path in collect2 is adjusted. > > You can still disable this by specifying -fno-lto on the > linker command-line. > > One side-effect of enabling the linker-plugin by default > (for HAVE_LTO_PLUGIN == 2) is that collect2 will then > use the configured plugin ld rather than the default ld. > Not sure if that is desired. > > Comments? This patch broke Solaris bootstrap with GNU ld: when linking stage1 libgcc, the lto plugin is used. It has been built with -shared and thus depends on libgcc_s.so.1. There's no instance of libgcc_s shipped with the system, thus when trying to link the stage1 libgcc_s, the lto plugin fails to load: chicken and egg ;-( The solution/workaround seems to be to link stage1 libgcc_s with -fno-lto (which works if done manually). Unfortunately, there's currently no way to pass in additional ldflags from the toplevel, depending on stage; not even toplevel LDFLAGS is used in SHLIB_LINK. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Fix bug 59586
Sorry, an error occurred somewhere. Below is an attachment with the patch and ChangeLog entry. > This patch fixes the following bug: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586. > The segfault is caused by NULL arguments passed to compute_deps by > loop_level_carries_dependences. > This causes an assignment of NULL values to the no_source parameters > of compute_deps. > They are passed to subtract_commutative_associative_deps and dereferenced. > > However, this NULL arguments are appropriate for the algorithm used > in loop_level_carries_dependences. It uses compute_deps > for finding RAW, WAR and WAW dependences of all basic blocks > in the body of the given loop. Subsequently, it tries to > determine presence of these dependences at the given level. > Therefore it maps the relation of the dependences to the relation > of the corresponding time-stamps and intersects the result with > the relation in which all the inputs before the DEPTH occur at the > same time as the output, and the input at the DEPTH occurs before output. > If the intersection is not empty, some dependences are carried > by the DEPTH we currently check and the loop is consequently not parallel. > > This patch tries to avoid the problem by addition to > subtract_commutative_associative_deps > of NULL checking of the no_source statements. > > Tested x86_64-unknown-linux-gnu, applying to 4.8.3 and trunk. patch Description: Binary data ChangeLog_entry Description: Binary data
Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc
On 07/03/14 09:03, Richard Biener wrote: Btw, can you check the attached as well? It makes sure all TUs have -fshort-double set consistently and it automatically enables it at link-time, not allowing to override the setting. If it works for you please check it in, too. (I can't really test it because -fshort-double brokeness on x86_64). I have tested it and everything looks fine. I have now committed all the code and testcase. Hopefully it's now sorted. Thanks for your help, Paulo Matos Thanks, Richard. -- PMatos
Re: [patch, libfortran] [4.7/4.8/4.9 Regression] PR38199 missed optimization: I/O performance
Jerry DeLisle wrote: The attached patch addresses the problem identified in comment #22 of the PR. For character array internal unit reads, eat_spaces must call next_char to advance every single character until the end of the string is reached. In the case sited which is very contrived, this amounts to about 10 calls to next_char. Without the patch takes about 25 seconds to run. With the patch this takes about 2.8 seconds. Nice! The speedup is accomplished by simply skipping over spaces without calling next_read, then backing up one character and letting the existing execution path proceed, preserving all the end of record code needed in next_char. I think that code is okay. I wonder whether it can happen that we read one character too far: i.e. stell() == end of string; offset++ -> one behind. As one then immediately steps back (due to "offset < limit" plus offset--), the code should be handled just fine - except for the out of bounds read - which might be detected by, e.g., -fsanitizer=address (if libgfortran and the program use it). However, I am not sure whether eat_spaces would be called in that case or whether other conditions error out before. I also remove some unneeded error checks. I have to admit that I do not really understand why the conditions are unreachable. Is it because "dtp->u.p.current_unit->bytes_left == 0" is already checked for "is_array_io (dtp)"? If so, can it happen for scalar internal I/O? I assume, it is obvious, but I don't quickly see it. Tobias 2014-03-08 Jerry DeLisle PR libfortran/38199 * io/list_read.c (next_char): Delete unuseful error checks. (eat_spaces): For character array reading, skip ahead over spaces rather than call next_char multiple times.
Ping^2 GCC trunk 4.9: documentation patch on plugins
Hello All,
I am pinging again this documentation patch
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00074.html
(pinged at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01002.html on febµ.17th
2014)
gcc/ChangeLog entry
2014-03-08 Basile Starynkevitch
* doc/plugins.texi (Plugin callbacks): Mention PLUGIN_INCLUDE_FILE.
Italicize plugin event names in description. Explain that
PLUGIN_PRAGMAS has no sense for lto1. Explain PLUGIN_INCLUDE_FILE.
Remind that no GCC functions should be called after PLUGIN_FINISH.
Explain what pragmas with expansion are.
the patch:
Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi(revision 207422)
+++ gcc/doc/plugins.texi(working copy)
@@ -209,6 +209,10 @@
PLUGIN_EARLY_GIMPLE_PASSES_END,
/* Called when a pass is first instantiated. */
PLUGIN_NEW_PASS,
+/* Called when a file is #include-d or given thru #line directive.
+ Could happen many times. The event data is the included file path,
+ as a const char* pointer. */
+ PLUGIN_INCLUDE_FILE,
PLUGIN_EVENT_FIRST_DYNAMIC/* Dummy event used for indexing callback
array. */
@@ -229,15 +233,27 @@
@item @code{void *user_data}: Pointer to plugin-specific data.
@end itemize
-For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, PLUGIN_REGISTER_GGC_ROOTS
-and PLUGIN_REGISTER_GGC_CACHES pseudo-events the @code{callback} should be
-null, and the @code{user_data} is specific.
+For the @i{PLUGIN_PASS_MANAGER_SETUP}, @i{PLUGIN_INFO},
+@i{PLUGIN_REGISTER_GGC_ROOTS} and @i{PLUGIN_REGISTER_GGC_CACHES}
+pseudo-events the @code{callback} should be null, and the
+@code{user_data} is specific.
-When the PLUGIN_PRAGMAS event is triggered (with a null
-pointer as data from GCC), plugins may register their own pragmas
-using functions like @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion}.
+When the @i{PLUGIN_PRAGMAS} event is triggered (with a null pointer as
+data from GCC), plugins may register their own pragmas. Notice that
+pragmas are not available from @file{lto1}, so plugins used with
+@code{-flto} option to GCC during link-time optimization cannot use
+pragmas and do not even see functions like @code{c_register_pragma} or
+@code{pragma_lex}.
+The @i{PLUGIN_INCLUDE_FILE} event, with a @code{const char*} file path as
+GCC data, is triggered for processing of @code{#include} or
+@code{#line} directives.
+
+The @i{PLUGIN_FINISH} event is the last time that plugins can call GCC
+functions, notably emit diagnostics with @code{warning}, @code{error}
+etc.
+
+
@node Plugins pass
@section Interacting with the pass manager
@@ -376,10 +392,13 @@
@end smallexample
-The @code{PLUGIN_PRAGMAS} callback is called during pragmas
-registration. Use the @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion} functions to register custom
-pragmas.
+The @i{PLUGIN_PRAGMAS} callback is called once during pragmas
+registration. Use the @code{c_register_pragma},
+@code{c_register_pragma_with_data},
+@code{c_register_pragma_with_expansion},
+@code{c_register_pragma_with_expansion_and_data} functions to register
+custom pragmas and their handlers (which often want to call
+@code{pragma_lex}) from @file{c-family/c-pragma.h}.
@smallexample
/* Plugin callback called during pragmas registration. Registered with
@@ -397,7 +416,15 @@
It is suggested to pass @code{"GCCPLUGIN"} (or a short name identifying
your plugin) as the ``space'' argument of your pragma.
+Pragmas registered with @code{c_register_pragma_with_expansion} or
+@code{c_register_pragma_with_expansion_and_data} are allowing
+preprocessor expansions, like e.g.
+@smallexample
+#define NUMBER 10
+#pragma GCCPLUGIN foothreshold (NUMBER)
+@end smallexample
+
@node Plugins recording
@section Recording information about pass execution
#
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
[PATCH] Fix bug 59586
This patch fixes the following bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586.
The segfault is caused by NULL arguments passed to compute_deps by
loop_level_carries_dependences.
This causes an assignment of NULL values to the no_source parameters
of compute_deps.
They are passed to subtract_commutative_associative_deps and dereferenced.
However, this NULL arguments are appropriate for the algorithm used
in loop_level_carries_dependences. It uses compute_deps
for finding RAW, WAR and WAW dependences of all basic blocks
in the body of the given loop. Subsequently, it tries to
determine presence of these dependences at the given level.
Therefore it maps the relation of the dependences to the relation
of the corresponding time-stamps and intersects the result with
the relation in which all the inputs before the DEPTH occur at the
same time as the output, and the input at the DEPTH occurs before output.
If the intersection is not empty, some dependences are carried
by the DEPTH we currently check and the loop is consequently not parallel.
This patch tries to avoid the problem by addition to
subtract_commutative_associative_deps
of NULL checking of the no_source statements.
Tested x86_64-unknown-linux-gnu, applying to 4.8.3 and trunk.
2014-03-07 Roman Gareev
gcc/
* graphite-dependences.c
(subtract_commutative_associative_deps):
Add NULL checking of the following variables:
must_raw_no_source, may_raw_no_source,
must_war_no_source, may_war_no_source,
must_waw_no_source, may_waw_no_source.
gcc/testsuite/gfortran.dg/graphite/graphite.exp: Run
corresponding
tests in new mode.
gcc/testsuite/gfortran.dg/graphite/parallelize-all-1.f: New testcase.
diff --git a/gcc/graphite-dependences.c b/gcc/graphite-dependences.c
index b0f8680..f382233 100644
--- a/gcc/graphite-dependences.c
+++ b/gcc/graphite-dependences.c
@@ -426,22 +426,48 @@ subtract_commutative_associative_deps (scop_p scop,
*must_raw = isl_union_map_subtract (*must_raw, x_must_raw);
*may_raw = isl_union_map_subtract (*may_raw, x_may_raw);
- *must_raw_no_source = isl_union_map_subtract (*must_raw_no_source,
- x_must_raw_no_source);
- *may_raw_no_source = isl_union_map_subtract (*may_raw_no_source,
- x_may_raw_no_source);
+
+ if (must_raw_no_source)
+ *must_raw_no_source = isl_union_map_subtract (*must_raw_no_source,
+ x_must_raw_no_source);
+ else
+ isl_union_map_free (x_must_raw_no_source);
+
+ if (may_raw_no_source)
+ *may_raw_no_source = isl_union_map_subtract (*may_raw_no_source,
+ x_may_raw_no_source);
+ else
+ isl_union_map_free (x_may_raw_no_source);
+
*must_war = isl_union_map_subtract (*must_war, x_must_war);
*may_war = isl_union_map_subtract (*may_war, x_may_war);
- *must_war_no_source = isl_union_map_subtract (*must_war_no_source,
- x_must_war_no_source);
- *may_war_no_source = isl_union_map_subtract (*may_war_no_source,
- x_may_war_no_source);
+
+ if (must_war_no_source)
+ *must_war_no_source = isl_union_map_subtract (*must_war_no_source,
+ x_must_war_no_source);
+ else
+ isl_union_map_free (x_must_war_no_source);
+
+ if (may_war_no_source)
+ *may_war_no_source = isl_union_map_subtract (*may_war_no_source,
+ x_may_war_no_source);
+ else
+ isl_union_map_free (x_may_war_no_source);
+
*must_waw = isl_union_map_subtract (*must_waw, x_must_waw);
*may_waw = isl_union_map_subtract (*may_waw, x_may_waw);
- *must_waw_no_source = isl_union_map_subtract (*must_waw_no_source,
- x_must_waw_no_source);
- *may_waw_no_source = isl_union_map_subtract (*may_waw_no_source,
- x_may_waw_no_source);
+
+ if (must_waw_no_source)
+ *must_waw_no_source = isl_union_map_subtract (*must_waw_no_source,
+ x_must_waw_no_source);
+ else
+ isl_union_map_free (x_must_waw_no_source);
+
+ if (may_waw_no_source)
+ *may_waw_no_source = isl_union_map_subtract (*may_waw_no_source,
+ x_may_waw_no_source);
+ else
+ isl_union_map_free (x_may_waw_no_source);
}
isl_union_map_free (original);
diff --git a/gcc/testsuite/gfortran.dg/graphite/graphite.exp
b/gcc/testsuite/gfortran.dg/graphite/graphite.exp
index c3aad13..3833e43 100644
--- a/gcc/testsuite/gfortran.dg/graphite/graphite.exp
+++ b/gcc/testsuite/gfortran.dg/graphite/graphite.exp
@@ -44,6 +44,7 @@ set interchange_files [lsort [glob -nocomplain
$srcdir/$subdir/interchange-*.\[f
set scop_files[lsort [glob -nocomplain
$srcdir/$subdir/scop-*.\[fF\]{,90,95,03,08} ] ]
set run_id_files [lsort [glob -nocomplain
$srcdir/$subdir/run-id-*.\[fF\]{,90,95,03,08} ] ]
set vect_files[lsort [glob -nocomplain
$srcdir/$subdir/vect-*.\[fF\]{,90,95,03,08} ] ]
+set parallelize_files [lsort [glob -nocomplain
$srcdir/$subdir/parallelize-all-*.\[fF\]{,90,95,03,08} ] ]
# Tests to be compiled.
set dg-do-what-default compile
@@ -51,6 +52,7 @@ gfortran-dg-runtest $scop_files"-O2
-fgraphite -fd
Re: [Patch, Fortran] Update gfortran.texi's 2003/2008 status
2014-03-08 8:38 GMT+01:00 Tobias Burnus : > An update the gfortran.texi's F2003/F2008 status. > > OK for the trunk? Sounds good. Ok! Cheers, Janus
[PATCH] SPARC: Clarify -mapp-regs option
gcc/ChangeLog
2014-03-08 Sebastian Huber
* doc/invoke.texi (mapp-regs): Clarify.
---
gcc/doc/invoke.texi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2ee091a..12b43fa 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -20818,7 +20818,8 @@ These @samp{-m} options are supported on the SPARC:
@opindex mapp-regs
Specify @option{-mapp-regs} to generate output using the global registers
2 through 4, which the SPARC SVR4 ABI reserves for applications. This
-is the default.
+is the default. Like the global register 1 the global registers 2 through 4
+are used as volatile registers (may be destroyed across a function call).
To be fully SVR4 ABI-compliant at the cost of some performance loss,
specify @option{-mno-app-regs}. You should compile libraries and system
--
1.8.1.4
[committed] PR 58271: Upgrade a warning to an error
PR 58271 shows a case where using -mips3 -mpaired-single will print:
warning: the 'mips3' architecture does not support paired-single instructions
[enabled by default]
and then ICE because the -mpaired-single support implicitly assumes
that MIPS IV features are available. The ICE in this case is a regression
from 4.7, although 4.7 would probably ICE in other situations.
This patch upgrades the warning to an error and disables -mips3d and
-mpaired-single when they are not available.
Tested on mips64-linux-gnu and applied.
Thanks,
Richard
gcc/
PR target/58271
* config/mips/mips.c (mips_option_override): Promote -mpaired-single
warning to an error. Disable TARGET_PAIRED_SINGLE and TARGET_MIPS3D
if they can't be used.
Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c 2014-02-02 16:10:04.116587339 +
+++ gcc/config/mips/mips.c 2014-03-05 20:44:40.651657638 +
@@ -17206,15 +17206,24 @@ mips_option_override (void)
/* Make sure that when TARGET_PAIRED_SINGLE_FLOAT is true, TARGET_FLOAT64
and TARGET_HARD_FLOAT_ABI are both true. */
if (TARGET_PAIRED_SINGLE_FLOAT && !(TARGET_FLOAT64 && TARGET_HARD_FLOAT_ABI))
-error ("%qs must be used with %qs",
- TARGET_MIPS3D ? "-mips3d" : "-mpaired-single",
- TARGET_HARD_FLOAT_ABI ? "-mfp64" : "-mhard-float");
+{
+ error ("%qs must be used with %qs",
+TARGET_MIPS3D ? "-mips3d" : "-mpaired-single",
+TARGET_HARD_FLOAT_ABI ? "-mfp64" : "-mhard-float");
+ target_flags &= ~MASK_PAIRED_SINGLE_FLOAT;
+ TARGET_MIPS3D = 0;
+}
- /* Make sure that the ISA supports TARGET_PAIRED_SINGLE_FLOAT when it is
- enabled. */
+ /* Make sure that -mpaired-single is only used on ISAs that support it.
+ We must disable it otherwise since it relies on other ISA properties
+ like ISA_HAS_8CC having their normal values. */
if (TARGET_PAIRED_SINGLE_FLOAT && !ISA_HAS_PAIRED_SINGLE)
-warning (0, "the %qs architecture does not support paired-single"
+{
+ error ("the %qs architecture does not support paired-single"
" instructions", mips_arch_info->name);
+ target_flags &= ~MASK_PAIRED_SINGLE_FLOAT;
+ TARGET_MIPS3D = 0;
+}
if (mips_r10k_cache_barrier != R10K_CACHE_BARRIER_NONE
&& !TARGET_CACHE_BUILTIN)
