Re: [PATCH] libsanitizer: Use pre-computed size of struct ustat for Linux
On 24.05.2018 21:59, Jakub Jelinek wrote: > On Thu, May 24, 2018 at 12:56:23PM -0700, H.J. Lu wrote: This patch uses pre-computed size of struct ustat for Linux. PR sanitizer/85835 * sanitizer_common/sanitizer_platform_limits_posix.cc: Don't include for Linux. (SIZEOF_STRUCT_USTAT): New. (struct_ustat_sz): Use SIZEOF_STRUCT_USTAT for Linux. >>> >>> Ok, thanks. >>> >> >> OK to backport to released branches? > > Yes. Backported to the gcc-6-branch as well. Matthias
Re: [PATCH 08/25] Fix co-array allocation
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 After that, it was a breeze to test my mock weather program (moene.org/~toon/random-weather.f90), that I had built until then only with -fcoarray=single. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: C++ PATCH for c++/87372, __func__ constexpr evaluation
On Thu, Sep 20, 2018 at 11:56:37PM -0400, Marek Polacek wrote:
> The patch for P0595R1 - is_constant_evaluated had this hunk:
>
> @@ -5279,7 +5315,9 @@ maybe_constant_init_1 (tree t, tree decl, bool
> allow_non_constant)
>else if (CONSTANT_CLASS_P (t) && allow_non_constant)
> /* No evaluation needed. */;
>else
> -t = cxx_eval_outermost_constant_expr (t, allow_non_constant, false,
> decl);
> +t = cxx_eval_outermost_constant_expr (t, allow_non_constant,
> + !allow_non_constant,
> + pretend_const_required, decl);
>if (TREE_CODE (t) == TARGET_EXPR)
> {
>tree init = TARGET_EXPR_INITIAL (t);
>
> the false -> !allow_non_constant change means that when calling
> cxx_constant_init strict will be true because cxx_constant_init does not allow
> non constants. That means that for VAR_DECLs such as __func__ we'll call
> decl_really_constant_value instead of decl_constant_value. But only the
> latter
> can evaluate __func__ to "foo()".
>
> Jakub, was there a specific reason for this change? Changing it back still
> regtests cleanly and the attached test compiles again.
It just didn't feel right that cxx_constant_init which looks like a function
that requires strict conformance still passes false as strict.
If there is a reason to pass false, I think we need a comment that explains
it.
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-09-20 Marek Polacek
>
> PR c++/87372 - __func__ constexpr evaluation.
> * constexpr.c (maybe_constant_init_1): Pass false for strict down to
> cxx_eval_outermost_constant_expr.
>
> * g++.dg/cpp1y/func_constexpr2.C: New test.
>
> diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
> index fdea769faa9..6436b2f832d 100644
> --- gcc/cp/constexpr.c
> +++ gcc/cp/constexpr.c
> @@ -5361,7 +5361,7 @@ maybe_constant_init_1 (tree t, tree decl, bool
> allow_non_constant,
> /* No evaluation needed. */;
>else
> t = cxx_eval_outermost_constant_expr (t, allow_non_constant,
> - !allow_non_constant,
> + /*strict*/false,
> pretend_const_required, decl);
>if (TREE_CODE (t) == TARGET_EXPR)
> {
Jakub
Re: [PATCH 3/3] [LLVM] [sanitizer] add conditionals for libc
On Wed, 23 Apr 2014 at 10:58, Konstantin Serebryany wrote: > > Thanks. Let's move the discussion there. 4-early ping.. Thanks to Yuri for his remark there. Just asking if any of you folks had more comments? thanks, > > On Wed, Apr 23, 2014 at 12:46 PM, Bernhard Reutner-Fischer > wrote: > > On 17 April 2014 19:01, Konstantin Serebryany > > wrote: > >> On Thu, Apr 17, 2014 at 8:45 PM, Bernhard Reutner-Fischer > >> wrote: > >>> On 17 April 2014 16:51:23 Konstantin Serebryany > >>> wrote: > >>> > On Thu, Apr 17, 2014 at 6:27 PM, Bernhard Reutner-Fischer > wrote: > > On 17 April 2014 16:07, Konstantin Serebryany > > wrote: > >> Hi, > >> > >> If you are trying to modify the libsanitizer files, please read here: > >> https://code.google.com/p/address-sanitizer/wiki/HowToContribute > > > > I read that, thanks. Patch 3/3 is for current compiler-rt git repo, > > please install it there, i do not have write access to the LLVM nor > > compiler-rt trees. > > I can commit your patch to llvm tree only after you follow the process > described on that page. > Sorry, this is a hard rule. > >>> > >>> > >>> What part of the process do you think I did not follow? > >>> > >>> I made a patch for compiler-rt, sent it to llvm-comm...@cs.uiuc.edu then > >>> provided the corresponding GCC parts, along a backport of the new bits > >>> that > >>> I expect to be overwritten once you do a new merge, leaving just the GCC > >>> configuy bits. This is how I read the wiki page you cite. > >>> > >>> Please tell me what you expect me to do differently? > >> > >> First, I did not notice that you've sent it to llvm-commits because it > >> was also sent to the gcc list (unusual thing to happen) > >> and got filtered into the gcc part of my mail. Sorry. > >> But second, the patch is far from trivial and you should not expect us > >> to commit it w/o a careful review, > >> so here comes another part of the wiki: "For non-trivial patches > >> please use Phabricator -- this will help us reply faster." > > > > http://reviews.llvm.org/D3464 > > > > thanks,
Re: [PATCH] Remove arc profile histogram in non-LTO mode.
On 9/21/18 6:05 AM, Bin.Cheng wrote: > On Thu, Sep 20, 2018 at 6:43 PM Jan Hubicka wrote: >> >>> On Thu, Sep 20, 2018 at 5:26 PM Jan Hubicka wrote: > On Thu, Sep 20, 2018 at 2:11 AM Martin Liška wrote: >> >> Hello. >> >> I've been working for some time on a patch that simplifies how we set >> the hotness threshold of basic blocks. Currently, we calculate so called >> arc profile histograms that should identify edges that cover 99.9% of all >> branching. These edges are then identified as hot. Disadvantage of the >> approach >> is that it comes with significant overhead in run-time and GCC related >> code >> is also not trivial. Moreover, anytime a histogram is merged after an >> instrumented >> run, the resulting histogram is misleading. >> >> That said, I decided to simplify it again, remove usage of the histogram >> and return >> to what we have before (--param hot-bb-count-fraction). That basically >> says that >> we consider hot each edge that has execution count bigger than sum_max / >> 10.000. >> >> Note that LTO+PGO remains untouched as it still uses histogram that is >> dynamically >> calculated by read arc counts. > Hi, > Does this affect AutoFDO stuff? AutoFDO is broken and I am fixing it > now, on the basis of current code. This is indpendent of Auto-FDO. There we probably can define cutoffs for hot-cold partitions in the tool translating global data into per-file data read by GCC. It is great you will take a deper look at autoFDO. it indeed needs work! The patch is OK, thank for working on it! Histograms was added by google as bit of experiment, but I do not think they turned out to be useful. The data >>> I did some experiments showing it is somehow useful, for autoFDO. To >>> which extend it is useful remains a question I need to investigate >>> later. >> >> Indeed auto-FDO has better idea about whole program behaviour. We could >> revive >> the patch for streaming histograms and reading them to compiler if that turns >> out to be a good idea. I can see that auto-FDO profile data tells you pretty >> clearly where the hot spots are and it is not as easy to recover this >> information >> from profile annotated CFG becuase of all the transforms we do. >> Lets fix and benchmark auto-FDO first and then we could decide what is best >> option. >> Putting the stream-in code back should not be hard if it turns out to be >> useful. >> >> Main problem with current historams with normal FDO is the fact that you need >> to merge them between runs which is technically impossible job to do, so they >> work for programs run once, but not for programs run many times in train runs >> like gcc itself. It seems to me that for those relaly interested in >> performance it is good idea to switch to LTO and that makes it possible to >> calculate histograms during the linking stage. > > honza, thanks very much for detailed explanation. Thanks Honza for review. Bin: Do not hesitate and ask me about what you'll need. As Honza mentioned I don't see any problem with propagating hotness information from AutoFDO into *.gcda files. Format can be discussed. Martin > > Thanks, > bin >> >> Honza >>> >>> Thanks, >>> bin produced by them was not very related to what the IPA profile generation produces and thus it did not seem to match reality very well. Honza > > Thanks, > bin >> >> Note the statistics of the patch: >> 19 files changed, 101 insertions(+), 1216 deletions(-) >> >> I'm attaching file sizes of SPEC2006 int benchmark. >> >> Patch survives testing on x86_64-linux-gnu machine. >> Ready to be installed? >> >> Martin >> >> gcc/ChangeLog: >> >> 2018-09-19 Martin Liska >> >> * auto-profile.c (autofdo_source_profile::read): Do not >> set sum_all. >> (read_profile): Do not add working sets. >> (read_autofdo_file): Remove sum_all. >> (afdo_callsite_hot_enough_for_early_inline): Remove const >> qualifier. >> * coverage.c (struct counts_entry): Remove gcov_summary. >> (read_counts_file): Read new GCOV_TAG_OBJECT_SUMMARY, >> do not support GCOV_TAG_PROGRAM_SUMMARY. >> (get_coverage_counts): Remove summary and expected >> arguments. >> * coverage.h (get_coverage_counts): Likewise. >> * doc/gcov-dump.texi: Remove -w option. >> * gcov-dump.c (dump_working_sets): Remove. >> (main): Do not support '-w' option. >> (print_usage): Likewise. >> (tag_summary): Likewise. >> * gcov-io.c (gcov_write_summary): Do not dump >> histogram. >> (gcov_read_summary): Likewise. >> (gcov_histo_index): Remove
Re: [PATCH] Use vectored writes when reporting errors and warnings.
PING On Wed, Sep 12, 2018 at 10:17 PM Janne Blomqvist wrote: > When producing error and warning messages, libgfortran writes a > message by using many system calls. By using vectored writes (the > POSIX writev function) when available and feasible to use without > major surgery, we reduce the chance that output gets intermingled with > other output to stderr. > > In practice, this is done by introducing a new function estr_writev in > addition to the existing estr_write. In order to use this, the old > st_vprintf is removed, replaced by direct calls of vsnprintf, allowing > more message batching. > > Regtested on x86_64-pc-linux-gnu, Ok for trunk? > > libgfortran/ChangeLog: > > 2018-09-12 Janne Blomqvist > > * config.h.in: Regenerated. > * configure: Regenerated. > * configure.ac: Check for writev and sys/uio.h. > * libgfortran.h: Include sys/uio.h. > (st_vprintf): Remove prototype. > (struct iovec): Define if not available. > (estr_writev): New prototype. > * runtime/backtrace.c (error_callback): Use estr_writev. > * runtime/error.c (ST_VPRINTF_SIZE): Remove. > (estr_writev): New function. > (st_vprintf): Remove. > (gf_vsnprintf): New function. > (ST_ERRBUF_SIZE): New macro. > (st_printf): Use vsnprintf. > (os_error): Use estr_writev. > (runtime_error): Use vsnprintf and estr_writev. > (runtime_error_at): Likewise. > (runtime_warning_at): Likewise. > (internal_error): Use estr_writev. > (generate_error_common): Likewise. > (generate_warning): Likewise. > (notify_std): Likewise. > * runtime/pause.c (pause_string): Likewise. > * runtime/stop.c (report_exception): Likewise. > (stop_string): Likewise. > (error_stop_string): Likewise. > --- > libgfortran/config.h.in | 6 + > libgfortran/configure | 10 +- > libgfortran/configure.ac| 4 +- > libgfortran/libgfortran.h | 15 ++- > libgfortran/runtime/backtrace.c | 27 +++-- > libgfortran/runtime/error.c | 188 +++- > libgfortran/runtime/pause.c | 14 ++- > libgfortran/runtime/stop.c | 71 +--- > 8 files changed, 250 insertions(+), 85 deletions(-) > > diff --git a/libgfortran/config.h.in b/libgfortran/config.h.in > index 65fd27c6b11..c7f47146030 100644 > --- a/libgfortran/config.h.in > +++ b/libgfortran/config.h.in > @@ -762,6 +762,9 @@ > /* Define to 1 if you have the header file. */ > #undef HAVE_SYS_TYPES_H > > +/* Define to 1 if you have the header file. */ > +#undef HAVE_SYS_UIO_H > + > /* Define to 1 if you have the header file. */ > #undef HAVE_SYS_WAIT_H > > @@ -828,6 +831,9 @@ > /* Define if target has a reliable stat. */ > #undef HAVE_WORKING_STAT > > +/* Define to 1 if you have the `writev' function. */ > +#undef HAVE_WRITEV > + > /* Define to 1 if you have the header file. */ > #undef HAVE_XLOCALE_H > > diff --git a/libgfortran/configure b/libgfortran/configure > index a583b676a3e..1c93683acd2 100755 > --- a/libgfortran/configure > +++ b/libgfortran/configure > @@ -2553,6 +2553,7 @@ as_fn_append ac_header_list " sys/times.h" > as_fn_append ac_header_list " sys/resource.h" > as_fn_append ac_header_list " sys/types.h" > as_fn_append ac_header_list " sys/stat.h" > +as_fn_append ac_header_list " sys/uio.h" > as_fn_append ac_header_list " sys/wait.h" > as_fn_append ac_header_list " floatingpoint.h" > as_fn_append ac_header_list " ieeefp.h" > @@ -2584,6 +2585,7 @@ as_fn_append ac_func_list " access" > as_fn_append ac_func_list " fork" > as_fn_append ac_func_list " setmode" > as_fn_append ac_func_list " fcntl" > +as_fn_append ac_func_list " writev" > as_fn_append ac_func_list " gettimeofday" > as_fn_append ac_func_list " stat" > as_fn_append ac_func_list " fstat" > @@ -12514,7 +12516,7 @@ else >lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 >lt_status=$lt_dlunknown >cat > conftest.$ac_ext <<_LT_EOF > -#line 12517 "configure" > +#line 12519 "configure" > #include "confdefs.h" > > #if HAVE_DLFCN_H > @@ -12620,7 +12622,7 @@ else >lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 >lt_status=$lt_dlunknown >cat > conftest.$ac_ext <<_LT_EOF > -#line 12623 "configure" > +#line 12625 "configure" > #include "confdefs.h" > > #if HAVE_DLFCN_H > @@ -16168,6 +16170,8 @@ done > > > > + > + > > > > @@ -16763,6 +16767,8 @@ done > > > > + > + > > > > diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac > index 05952aa0d40..64f7b9a39d5 100644 > --- a/libgfortran/configure.ac > +++ b/libgfortran/configure.ac > @@ -276,7 +276,7 @@ AC_CHECK_TYPES([ptrdiff_t]) > > # check header files (we assume C89 is available, so don't check for that) > AC_CHECK_HEADERS_ONCE(unistd.h sys/random.h sys/time.h sys/times.h \ > -sys/resource.h sys/types.h sys/stat.h sys/wait.h \ > +sys/resource.h sys/types.h sys/stat.h sys/ui
Re: [PATCH] Properly mark lambdas in GCOV (PR gcov-profile/86109).
PING^1 On 9/12/18 2:39 PM, Martin Liška wrote: > Hi. > > This is follow-up of: > https://gcc.gnu.org/ml/gcc/2018-08/msg7.html > > I've chosen to implement that with new DECL_CXX_LAMBDA_FUNCTION that > uses an empty bit in tree_function_decl. > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > Ready for trunk? > > gcc/ChangeLog: > > 2018-09-12 Martin Liska > > PR gcov-profile/86109 > * coverage.c (coverage_begin_function): Do not > mark lambdas as artificial. > * tree-core.h (struct GTY): Remove tm_clone_flag > and introduce new lambda_function. > * tree.h (DECL_CXX_LAMBDA_FUNCTION): New macro. > > gcc/cp/ChangeLog: > > 2018-09-12 Martin Liska > > PR gcov-profile/86109 > * parser.c (cp_parser_lambda_declarator_opt): > Set DECL_CXX_LAMBDA_FUNCTION for lambdas. > > gcc/testsuite/ChangeLog: > > 2018-09-12 Martin Liska > > PR gcov-profile/86109 > * g++.dg/gcov/pr86109.C: New test. > --- > gcc/coverage.c | 3 ++- > gcc/cp/parser.c | 1 + > gcc/testsuite/g++.dg/gcov/pr86109.C | 16 > gcc/tree-core.h | 2 +- > gcc/tree.h | 4 > 5 files changed, 24 insertions(+), 2 deletions(-) > create mode 100644 gcc/testsuite/g++.dg/gcov/pr86109.C > >
Re: [PATCH] Improve location information of -Wcoverage-mismatch.
PING^1 On 9/12/18 2:37 PM, Martin Liška wrote: > Hi. > > The patch improves locations of the warning in following way: > > sample.c: In function ‘main’: > sample.c:16:1: error: source locations for function ‘main’ have changed, the > profile data may be out of date [-Werror=coverage-mismatch] > 16 | } >| ^ > sample.c:16:1: error: source locations for function ‘main’ have changed, the > profile data may be out of date [-Werror=coverage-mismatch] > cc1: some warnings being treated as errors > > into: > > sample.c: In function ‘main’: > sample.c:10:5: error: source locations for function ‘main’ have changed, the > profile data may be out of date [-Werror=coverage-mismatch] > 10 | int main() >| ^~~~ > sample.c:10:5: error: source locations for function ‘main’ have changed, the > profile data may be out of date [-Werror=coverage-mismatch] > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > Thanks, > Martin > > gcc/ChangeLog: > > 2018-09-12 Martin Liska > > * coverage.c (get_coverage_counts): Use warning_at > with current_function_decl location. Use %qD in warning > message. > --- > gcc/coverage.c | 18 ++ > 1 file changed, 10 insertions(+), 8 deletions(-) > > >
[PATCH] Remove Pascal-related entries in code and comments.
Hi.
This is removal of some Pascal-related comments.
Patch survives regression tests on x86_64-linux-gnu.
Ready for trunk?
Martin
gcc/ChangeLog:
2018-09-19 Martin Liska
* config/powerpcspe/powerpcspe.c (rs6000_output_function_epilogue):
Do not handle "GNU Pascal".
* config/rs6000/rs6000.c (rs6000_output_function_epilogue):
Likewise.
* config/sparc/sparc.c (sparc_pass_by_reference): Remove Pascal
from documentation. Likewise.
* dbxout.c (dbxout_range_type): Likewise.
* doc/cpp.texi: Likewise.
* doc/extend.texi: Likewise.
* doc/frontends.texi: Likewise.
* doc/invoke.texi: Remove Pascal entry.
* doc/rtl.texi: Likewise.
* tree.def (CLEANUP_POINT_EXPR): Likewise.
gcc/c-family/ChangeLog:
2018-09-19 Martin Liska
* c-common.c (c_common_truthvalue_conversion):
Remove Pascal from documentation.
---
gcc/c-family/c-common.c| 2 +-
gcc/config/powerpcspe/powerpcspe.c | 4 +---
gcc/config/rs6000/rs6000.c | 4 +---
gcc/config/sparc/sparc.c | 5 ++---
gcc/dbxout.c | 2 +-
gcc/doc/cpp.texi | 2 +-
gcc/doc/extend.texi| 2 +-
gcc/doc/frontends.texi | 3 +--
gcc/doc/invoke.texi| 3 ---
gcc/doc/rtl.texi | 2 +-
gcc/tree.def | 17 ++---
11 files changed, 16 insertions(+), 30 deletions(-)
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 4bfb14585e2..10a8bc29bfa 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -3289,7 +3289,7 @@ c_common_truthvalue_conversion (location_t location, tree expr)
tree inner = TREE_OPERAND (expr, 0);
if (decl_with_nonnull_addr_p (inner))
{
- /* Common Ada/Pascal programmer's mistake. */
+ /* Common Ada programmer's mistake. */
warning_at (location,
OPT_Waddress,
"the address of %qD will always evaluate as %",
diff --git a/gcc/config/powerpcspe/powerpcspe.c b/gcc/config/powerpcspe/powerpcspe.c
index dea1eab1188..325b6ad5223 100644
--- a/gcc/config/powerpcspe/powerpcspe.c
+++ b/gcc/config/powerpcspe/powerpcspe.c
@@ -32024,7 +32024,7 @@ rs6000_output_function_epilogue (FILE *file)
/* Language type. Unfortunately, there does not seem to be any
official way to discover the language being compiled, so we
use language_string.
- C is 0. Fortran is 1. Pascal is 2. Ada is 3. C++ is 9.
+ C is 0. Fortran is 1. Ada is 3. C++ is 9.
Java is 13. Objective-C is 14. Objective-C++ isn't assigned
a number, so for now use 9. LTO, Go and JIT aren't assigned numbers
either, so for now use 0. */
@@ -32036,8 +32036,6 @@ rs6000_output_function_epilogue (FILE *file)
else if (! strcmp (language_string, "GNU F77")
|| lang_GNU_Fortran ())
i = 1;
- else if (! strcmp (language_string, "GNU Pascal"))
- i = 2;
else if (! strcmp (language_string, "GNU Ada"))
i = 3;
else if (lang_GNU_CXX ()
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index a36e6140ecb..2aea649aa6b 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -28403,7 +28403,7 @@ rs6000_output_function_epilogue (FILE *file)
/* Language type. Unfortunately, there does not seem to be any
official way to discover the language being compiled, so we
use language_string.
- C is 0. Fortran is 1. Pascal is 2. Ada is 3. C++ is 9.
+ C is 0. Fortran is 1. Ada is 3. C++ is 9.
Java is 13. Objective-C is 14. Objective-C++ isn't assigned
a number, so for now use 9. LTO, Go and JIT aren't assigned numbers
either, so for now use 0. */
@@ -28415,8 +28415,6 @@ rs6000_output_function_epilogue (FILE *file)
else if (! strcmp (language_string, "GNU F77")
|| lang_GNU_Fortran ())
i = 1;
- else if (! strcmp (language_string, "GNU Pascal"))
- i = 2;
else if (! strcmp (language_string, "GNU Ada"))
i = 3;
else if (lang_GNU_CXX ()
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 2481fbf3b0a..42acabb5d78 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -7516,9 +7516,8 @@ sparc_pass_by_reference (cumulative_args_t cum ATTRIBUTE_UNUSED,
{
if (TARGET_ARCH32)
/* Original SPARC 32-bit ABI says that structures and unions,
- and quad-precision floats are passed by reference. For Pascal,
- also pass arrays by reference. All other base types are passed
- in registers.
+ and quad-precision floats are passed by reference.
+ All base types are passed in registers.
Extended ABI (as implemented by the Sun compiler) says that all
complex floats are passed by reference. Pass complex integers
diff --git a/gcc/dbxout.c b/gcc/dbxout.c
index 459b7c2806f..bf41b17a263 100644
--- a/gcc/dbxout.c
+++ b/gcc/dbxout.c
@@ -1715,7 +1715,7 @@ dbxout_range_type (tre
[PATCH] Guard memory block allocation.
Hi. Following patch marks releases memory blocks as not accesible for valgrind. That can help us in the future in order to catch memory corruptions. Ready for trunk? Martin gcc/ChangeLog: 2018-09-21 Martin Liska * memory-block.h (memory_block_pool::release): Annotate with valgrind that the memory is not accessible. --- gcc/memory-block.h | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/memory-block.h b/gcc/memory-block.h index 5440428240d..c045d2e95ab 100644 --- a/gcc/memory-block.h +++ b/gcc/memory-block.h @@ -68,6 +68,11 @@ memory_block_pool::release (void *uncast_block) block_list *block = new (uncast_block) block_list; block->m_next = instance.m_blocks; instance.m_blocks = block; + + VALGRIND_DISCARD (VALGRIND_MAKE_MEM_NOACCESS ((char *)uncast_block + + sizeof (block_list), + block_size + - sizeof (block_list))); } extern void *mempool_obstack_chunk_alloc (size_t) ATTRIBUTE_MALLOC;
[c-family] Issue a warning on packed record layout with -fdump-ada-spec
The packed record layout is not really supported for the time being.
Tested on x86-64/Linux, applied on the mainline.
2018-09-21 Eric Botcazou
* c-ada-spec.c: Include diagnostic.h.
(dump_ada_declaration) : Issue a warning on packed layout.
2018-09-21 Eric Botcazou
* c-c++-common/dump-ada-spec-14.c: New test.
--
Eric BotcazouIndex: c-ada-spec.c
===
--- c-ada-spec.c (revision 264342)
+++ c-ada-spec.c (working copy)
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3.
#include "c-ada-spec.h"
#include "fold-const.h"
#include "c-pragma.h"
+#include "diagnostic.h"
#include "stringpool.h"
#include "attribs.h"
@@ -2700,6 +2701,16 @@ dump_ada_declaration (pretty_printer *bu
return 1;
}
+ /* ??? Packed record layout is not supported. */
+ if (TYPE_PACKED (TREE_TYPE (t)))
+ {
+ warning_at (DECL_SOURCE_LOCATION (t), 0,
+ "unsupported record layout");
+ pp_string (buffer, "pragma Compile_Time_Warning (True, ");
+ pp_string (buffer, "\"probably incorrect record layout\");");
+ newline_and_indent (buffer, spc);
+ }
+
if (orig && TYPE_NAME (orig))
pp_string (buffer, "subtype ");
else
/* { dg-do compile } */
/* { dg-options "-fdump-ada-spec" } */
struct __attribute__((packed)) S /* { dg-warning "unsupported record layout" } */
{
char c;
int t;
};
/* { dg-final { cleanup-ada-spec } } */
Re: [PATCH] PR libstdc++/78179 run long double tests separately
On 21/09/18 01:52, Hans-Peter Nilsson wrote:
>> Date: Thu, 20 Sep 2018 15:22:23 +0100
>> From: Jonathan Wakely
>
>> On 20/09/18 15:36 +0200, Christophe Lyon wrote:
>>> On Wed, 19 Sep 2018 at 23:13, Rainer Orth
>>> wrote:
Hi Christophe,
> I have noticed failures on hypot-long-double.cc on arm, so I suggest we
> add:
>
> diff --git
> a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
> b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
> index 8a05473..4c2e33b 100644
> ---
> a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
> +++
> b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
> @@ -17,7 +17,7 @@
>
> // { dg-options "-std=gnu++17" }
> // { dg-do run { target c++17 } }
> -// { dg-xfail-run-if "PR 78179" { powerpc-ibm-aix* hppa-*-linux*
> nios2-*-* } }
> +// { dg-xfail-run-if "PR 78179" { powerpc-ibm-aix* hppa-*-linux*
> nios2-*-* arm*-*-* } }
>
> // Run the long double tests from hypot.cc separately, because they fail
> on a
> // number of targets. See PR libstdc++/78179 for details.
>
> OK?
just a nit (and not a review): I'd prefer the target list to be sorted
alphabetically, not completely random.
>>>
>>> Sure, I can sort the whole list, if OK on principle.
>>
>> Yes, please go ahead and commit it with the sorted list.
>
> "Me too". Can I please, rather than piling on to a target list,
> replace the whole xfail-list with the equivalent of "target { !
> large_long_double }" (an already-existing "effective target")?
>
> I'll leave the thought of running the test only for
> large_long_double targets (qualifying the dg-do run) instead of
> an xfail-clause for maintainers.
>
> brgds, H-P
>
Xfailing sounds wrong to me anyway. An xfailed test ought to run, but
some critical component other than the bug/regression in the test
prevents it happening. In this case the test can never be made to work
because the target environment simply doesn't support it. So better to
just skip it. If we want a separate compile-only test, then that's a
different issue and should be in a separate test.
So +1 for using large_long_double.
R.
Re: [PATCH] PR libstdc++/78179 run long double tests separately
On 21/09/18 02:52 +0200, Hans-Peter Nilsson wrote:
Date: Thu, 20 Sep 2018 15:22:23 +0100
From: Jonathan Wakely
On 20/09/18 15:36 +0200, Christophe Lyon wrote:
>On Wed, 19 Sep 2018 at 23:13, Rainer Orth
wrote:
>>
>> Hi Christophe,
>>
>> > I have noticed failures on hypot-long-double.cc on arm, so I suggest we
add:
>> >
>> > diff --git
>> > a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
>> > b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
>> > index 8a05473..4c2e33b 100644
>> > --- a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
>> > +++ b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
>> > @@ -17,7 +17,7 @@
>> >
>> > // { dg-options "-std=gnu++17" }
>> > // { dg-do run { target c++17 } }
>> > -// { dg-xfail-run-if "PR 78179" { powerpc-ibm-aix* hppa-*-linux*
nios2-*-* } }
>> > +// { dg-xfail-run-if "PR 78179" { powerpc-ibm-aix* hppa-*-linux*
>> > nios2-*-* arm*-*-* } }
>> >
>> > // Run the long double tests from hypot.cc separately, because they fail
on a
>> > // number of targets. See PR libstdc++/78179 for details.
>> >
>> > OK?
>>
>> just a nit (and not a review): I'd prefer the target list to be sorted
>> alphabetically, not completely random.
>>
>
>Sure, I can sort the whole list, if OK on principle.
Yes, please go ahead and commit it with the sorted list.
"Me too". Can I please, rather than piling on to a target list,
replace the whole xfail-list with the equivalent of "target { !
large_long_double }" (an already-existing "effective target")?
That looks like exactly what we want here, thanks.
Re: [PATCH] PR libstdc++/78179 run long double tests separately
On 21/09/18 11:24 +0100, Richard Earnshaw (lists) wrote:
On 21/09/18 01:52, Hans-Peter Nilsson wrote:
Date: Thu, 20 Sep 2018 15:22:23 +0100
From: Jonathan Wakely
On 20/09/18 15:36 +0200, Christophe Lyon wrote:
On Wed, 19 Sep 2018 at 23:13, Rainer Orth wrote:
Hi Christophe,
I have noticed failures on hypot-long-double.cc on arm, so I suggest we add:
diff --git
a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
index 8a05473..4c2e33b 100644
--- a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
+++ b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
@@ -17,7 +17,7 @@
// { dg-options "-std=gnu++17" }
// { dg-do run { target c++17 } }
-// { dg-xfail-run-if "PR 78179" { powerpc-ibm-aix* hppa-*-linux* nios2-*-* } }
+// { dg-xfail-run-if "PR 78179" { powerpc-ibm-aix* hppa-*-linux*
nios2-*-* arm*-*-* } }
// Run the long double tests from hypot.cc separately, because they fail on a
// number of targets. See PR libstdc++/78179 for details.
OK?
just a nit (and not a review): I'd prefer the target list to be sorted
alphabetically, not completely random.
Sure, I can sort the whole list, if OK on principle.
Yes, please go ahead and commit it with the sorted list.
"Me too". Can I please, rather than piling on to a target list,
replace the whole xfail-list with the equivalent of "target { !
large_long_double }" (an already-existing "effective target")?
I'll leave the thought of running the test only for
large_long_double targets (qualifying the dg-do run) instead of
an xfail-clause for maintainers.
brgds, H-P
Xfailing sounds wrong to me anyway. An xfailed test ought to run, but
some critical component other than the bug/regression in the test
prevents it happening. In this case the test can never be made to work
because the target environment simply doesn't support it.
That's not true, the test would work fine with different tolerances
for the expected results. If we used the same tolerances as for
double, then the targets where double and long double are the same
would pass.
So better to
just skip it. If we want a separate compile-only test, then that's a
different issue and should be in a separate test.
I was going to say that the advantage of dg-xfail-run-if is that we
still compile it, we just know it fails to produce the expected
results. There's definitely a benefit to checking it compiles OK even
when sizeof(long double) == sizeof(double).
So +1 for using large_long_double.
Or we could un-split the test and do this instead:
diff --git a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
deleted file mode 100644
index bcc1fec635b..000
--- a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
+++ /dev/null
@@ -1,25 +0,0 @@
-// Copyright (C) 2016-2018 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 3, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING3. If not see
-//
Re: [PATCH] PR libstdc++/78179 run long double tests separately
On 21/09/18 11:34, Jonathan Wakely wrote:
> On 21/09/18 11:24 +0100, Richard Earnshaw (lists) wrote:
>> On 21/09/18 01:52, Hans-Peter Nilsson wrote:
Date: Thu, 20 Sep 2018 15:22:23 +0100
From: Jonathan Wakely
>>>
On 20/09/18 15:36 +0200, Christophe Lyon wrote:
> On Wed, 19 Sep 2018 at 23:13, Rainer Orth
> wrote:
>>
>> Hi Christophe,
>>
>>> I have noticed failures on hypot-long-double.cc on arm, so I
>>> suggest we add:
>>>
>>> diff --git
>>> a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
>>>
>>> b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
>>>
>>> index 8a05473..4c2e33b 100644
>>> ---
>>> a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
>>>
>>> +++
>>> b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
>>>
>>> @@ -17,7 +17,7 @@
>>>
>>> // { dg-options "-std=gnu++17" }
>>> // { dg-do run { target c++17 } }
>>> -// { dg-xfail-run-if "PR 78179" { powerpc-ibm-aix* hppa-*-linux*
>>> nios2-*-* } }
>>> +// { dg-xfail-run-if "PR 78179" { powerpc-ibm-aix* hppa-*-linux*
>>> nios2-*-* arm*-*-* } }
>>>
>>> // Run the long double tests from hypot.cc separately, because
>>> they fail on a
>>> // number of targets. See PR libstdc++/78179 for details.
>>>
>>> OK?
>>
>> just a nit (and not a review): I'd prefer the target list to be
>> sorted
>> alphabetically, not completely random.
>>
>
> Sure, I can sort the whole list, if OK on principle.
Yes, please go ahead and commit it with the sorted list.
>>>
>>> "Me too". Can I please, rather than piling on to a target list,
>>> replace the whole xfail-list with the equivalent of "target { !
>>> large_long_double }" (an already-existing "effective target")?
>>>
>>> I'll leave the thought of running the test only for
>>> large_long_double targets (qualifying the dg-do run) instead of
>>> an xfail-clause for maintainers.
>>>
>>> brgds, H-P
>>>
>>
>> Xfailing sounds wrong to me anyway. An xfailed test ought to run, but
>> some critical component other than the bug/regression in the test
>> prevents it happening. In this case the test can never be made to work
>> because the target environment simply doesn't support it.
>
> That's not true, the test would work fine with different tolerances
> for the expected results. If we used the same tolerances as for
> double, then the targets where double and long double are the same
> would pass.
>
>> So better to
>> just skip it. If we want a separate compile-only test, then that's a
>> different issue and should be in a separate test.
>
> I was going to say that the advantage of dg-xfail-run-if is that we
> still compile it, we just know it fails to produce the expected
> results. There's definitely a benefit to checking it compiles OK even
> when sizeof(long double) == sizeof(double).
>
>> So +1 for using large_long_double.
>
> Or we could un-split the test and do this instead:
>
>
>
> patch.txt
>
>
> diff --git
> a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
> b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
> deleted file mode 100644
> index bcc1fec635b..000
> --- a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -// Copyright (C) 2016-2018 Free Software Foundation, Inc.
> -//
> -// This file is part of the GNU ISO C++ Library. This library is free
> -// software; you can redistribute it and/or modify it under the
> -// terms of the GNU General Public License as published by the
> -// Free Software Foundation; either version 3, or (at your option)
> -// any later version.
> -
> -// This library is distributed in the hope that it will be useful,
> -// but WITHOUT ANY WARRANTY; without even the implied warranty of
> -// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> -// GNU General Public License for more details.
> -
> -// You should have received a copy of the GNU General Public License along
> -// with this library; see the file COPYING3. If not see
> -//
Re: [PATCH v2] S/390: Fix conditional returns on z196+
Ilya Leoshkevich wrote:
> 2018-09-19 Ilya Leoshkevich
>
> PR target/80080
> * config/s390/s390.md: Do not use PARALLEL RETURN+USE when
> returning via %r14.
This makes sense to me. I'm just wondering if it wouldn't be
simpler to do the check for r14 right in s390_emit_epilogue
and then just call gen_return instead of gen_return_use
directly there?
> +++ b/gcc/config/s390/s390.md
> @@ -10831,6 +10831,13 @@
> (use (match_operand 0 "register_operand" "a"))])]
>""
> {
> + if (REGNO (operands[0]) == RETURN_REGNUM && s390_can_use_return_insn ())
This probably cannot happen in practice in this specific case,
but in general a register_operand may also be e.g. a SUBREG,
so you shouldn't use REGNO without first verifying that this
is a REG. (If you move the check to s390_emit_epilogue as above,
this point is moot; you don't even need to generate a REG RTX
if it's for r14 then.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
[PATCH] middle-end/81035: Mention that noreturn suppresses tail call optimization
2018-09-21 Florian Weimer
PR middle-end/81035
* doc/extend.texi (Common Function Attributes): Mention that
noreturn suppresses tail call optimization.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index e3312aa8b42..909e7a17357 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3157,6 +3157,9 @@ The @code{noreturn} keyword does not affect the
exceptional path when that
applies: a @code{noreturn}-marked function may still return to the caller
by throwing an exception or calling @code{longjmp}.
+In order to preserve backtraces, GCC will never turn calls to
+@code{noreturn} functions into tail calls.
+
Do not assume that registers saved by the calling function are
restored before calling the @code{noreturn} function.
Re: [PATCH v2] S/390: Fix conditional returns on z196+
> Am 21.09.2018 um 12:50 schrieb Ulrich Weigand :
>
> Ilya Leoshkevich wrote:
>
>> 2018-09-19 Ilya Leoshkevich
>>
>> PR target/80080
>> * config/s390/s390.md: Do not use PARALLEL RETURN+USE when
>> returning via %r14.
>
> This makes sense to me. I'm just wondering if it wouldn't be
> simpler to do the check for r14 right in s390_emit_epilogue
> and then just call gen_return instead of gen_return_use
> directly there?
My reasoning was that even though right now gen_return_use is called
only from one place, if we ever add a second one, then we would most
likely have to duplicate the return_reg check.
>
>> +++ b/gcc/config/s390/s390.md
>> @@ -10831,6 +10831,13 @@
>> (use (match_operand 0 "register_operand" "a"))])]
>> ""
>> {
>> + if (REGNO (operands[0]) == RETURN_REGNUM && s390_can_use_return_insn ())
>
> This probably cannot happen in practice in this specific case,
> but in general a register_operand may also be e.g. a SUBREG,
> so you shouldn't use REGNO without first verifying that this
> is a REG. (If you move the check to s390_emit_epilogue as above,
> this point is moot; you don't even need to generate a REG RTX
> if it's for r14 then.)
>
Thanks, I didn’t know that. I’ll add REG_P here.
Re: [PATCH] PR libstdc++/78179 run long double tests separately
On 21/09/18 11:39 +0100, Richard Earnshaw (lists) wrote:
On 21/09/18 11:34, Jonathan Wakely wrote:
On 21/09/18 11:24 +0100, Richard Earnshaw (lists) wrote:
On 21/09/18 01:52, Hans-Peter Nilsson wrote:
Date: Thu, 20 Sep 2018 15:22:23 +0100
From: Jonathan Wakely
On 20/09/18 15:36 +0200, Christophe Lyon wrote:
On Wed, 19 Sep 2018 at 23:13, Rainer Orth
wrote:
Hi Christophe,
I have noticed failures on hypot-long-double.cc on arm, so I
suggest we add:
diff --git
a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
index 8a05473..4c2e33b 100644
---
a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
+++
b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
@@ -17,7 +17,7 @@
// { dg-options "-std=gnu++17" }
// { dg-do run { target c++17 } }
-// { dg-xfail-run-if "PR 78179" { powerpc-ibm-aix* hppa-*-linux*
nios2-*-* } }
+// { dg-xfail-run-if "PR 78179" { powerpc-ibm-aix* hppa-*-linux*
nios2-*-* arm*-*-* } }
// Run the long double tests from hypot.cc separately, because
they fail on a
// number of targets. See PR libstdc++/78179 for details.
OK?
just a nit (and not a review): I'd prefer the target list to be
sorted
alphabetically, not completely random.
Sure, I can sort the whole list, if OK on principle.
Yes, please go ahead and commit it with the sorted list.
"Me too". Can I please, rather than piling on to a target list,
replace the whole xfail-list with the equivalent of "target { !
large_long_double }" (an already-existing "effective target")?
I'll leave the thought of running the test only for
large_long_double targets (qualifying the dg-do run) instead of
an xfail-clause for maintainers.
brgds, H-P
Xfailing sounds wrong to me anyway. An xfailed test ought to run, but
some critical component other than the bug/regression in the test
prevents it happening. In this case the test can never be made to work
because the target environment simply doesn't support it.
That's not true, the test would work fine with different tolerances
for the expected results. If we used the same tolerances as for
double, then the targets where double and long double are the same
would pass.
So better to
just skip it. If we want a separate compile-only test, then that's a
different issue and should be in a separate test.
I was going to say that the advantage of dg-xfail-run-if is that we
still compile it, we just know it fails to produce the expected
results. There's definitely a benefit to checking it compiles OK even
when sizeof(long double) == sizeof(double).
So +1 for using large_long_double.
Or we could un-split the test and do this instead:
patch.txt
diff --git
a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
b/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
deleted file mode 100644
index bcc1fec635b..000
--- a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc
+++ /dev/null
@@ -1,25 +0,0 @@
-// Copyright (C) 2016-2018 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 3, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING3. If not see
-//
Re: [PATCHv2] Handle not explicitly zero terminated strings in merge sections
Hi Jakub, are your concerns addressed with this answer, or do you have objections to this patch? Thanks Bernd. On 09/14/18 21:06, Bernd Edlinger wrote: > On 09/14/18 21:01, Jakub Jelinek wrote: >> On Fri, Sep 14, 2018 at 06:39:38PM +, Bernd Edlinger wrote: >>> Hi, >>> >>> this is an upate of the string-merge section, it is based on the >>> V2-STRING_CST >>> semantic patch series, which was finally installed yesterday. >>> It merges single-byte string constants with or without terminating NUL. >>> The patch has the same Ada and C test cases that were already in the V1 >>> patch. >>> >>> Thus there are no pre-requisite patches necessary at this time. >>> >>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu. >>> Is it OK for trunk? >> >> I believe SHF_MERGE | SHF_STRINGS sections should only ever contain >> zero-terminated strings. >> See e.g. SCO ELF documentation: >> "The size of each element is specified in the section header's sh_entsize >> field. If the SHF_STRINGS flag is also set, the data elements consist of >> null-terminated character strings." >> http://www.sco.com/developers/gabi/2003-12-17/ch4.sheader.html >> https://docs.oracle.com/cd/E23824_01/html/819-0690/ggdlu.html >> >> So, please never put non-zero terminated strings into MS sections. >> > > Yes, that is of course clear. > > The idea is, if the string itself is not zero-terminated > another zero is added, that is only done in at the assembly level. > > Strings with embedded zero bytes are not put in the merge section. > > > Bernd.
Re: [PATCHv2] Handle not explicitly zero terminated strings in merge sections
On Fri, Sep 21, 2018 at 11:36:53AM +, Bernd Edlinger wrote: > are your concerns addressed with this answer, or do you have objections > to this patch? No objections, but no time to review your patch either right now. Jakub
[patch] factorize the handling of vxworks-dummy.h in config.gcc
Hello, The inclusion of vxworks-dummy.h in tm_file by config.gcc is spread in various places without a clear rationale. The attached patch just factorizes this out, at the end of the tm_file construction steps to account for sections totally redefining the variable contents, and with a head comment to explain what the file is about. Tested by verifying that a couple of gcc-8 based compilers we build in house remain functional after the change, and that vxworks-dummy.h is in the generated tm.h. Also sanity-checked that mainline still bootstraps and regression tests fine on x86_64-linux. Regards, Olivier 2018-09-21 Olivier Hainque * config.gcc: Factorize and comment inclusion of vxworks-dummy.h. 0001-config.gcc-factorize-and-comment-inclusion-of-vxwork.patch Description: Binary data
Re: [PATCH v4] [aarch64] Add HiSilicon tsv110 CPU support
Hi Shaokun, On 20/09/18 15:54, Zhangshaokun wrote: Hi James, On 2018/9/20 22:22, James Greenhalgh wrote: On Wed, Sep 19, 2018 at 04:53:52AM -0500, Shaokun Zhang wrote: This patch adds HiSilicon's an mcpu: tsv110, which supports v8_4A. It has been tested on aarch64 and no regressions from this patch. This patch is OK for Trunk. Do you need someone to commit it on your behalf? Sure, it is great. I've committed this on your behalf with revision 264470. Thank you for your patience and persistence. Kyrill Thanks in advance, Shaokun Thanks, James --- gcc/ChangeLog| 9 +++ gcc/config/aarch64/aarch64-cores.def | 3 + gcc/config/aarch64/aarch64-cost-tables.h | 104 +++ gcc/config/aarch64/aarch64-tune.md | 2 +- gcc/config/aarch64/aarch64.c | 82 gcc/doc/invoke.texi | 2 +- 6 files changed, 200 insertions(+), 2 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 69e2e14..a040daa 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,12 @@ +2018-09-19 Shaokun Zhang +Bo Zhou + + * config/aarch64/aarch64-cores.def (tsv110): New CPU. + * config/aarch64/aarch64-tune.md: Regenerated. + * doc/invoke.texi (AArch64 Options/-mtune): Add "tsv110". + * config/aarch64/aarch64.c (tsv110_tunings): New tuning table. + * config/aarch64/aarch64-cost-tables.h: Add "tsv110" extra costs. + 2018-09-18 Marek Polacek P1064R0 - Allowing Virtual Function Calls in Constant Expressions .
Re: [PATCH] PR libstdc++/78179 run long double tests separately
> Date: Fri, 21 Sep 2018 12:21:31 +0100 > From: Jonathan Wakely > Here's the corrected patch, any objections to this? Quite the contrary; LGTM. brgds, H-P
Re: [PATCH v2] S/390: Fix conditional returns on z196+
On Fri, Sep 21, 2018 at 12:50:40PM +0200, Ulrich Weigand wrote:
> Ilya Leoshkevich wrote:
>
> > 2018-09-19 Ilya Leoshkevich
> >
> > PR target/80080
> > * config/s390/s390.md: Do not use PARALLEL RETURN+USE when
> > returning via %r14.
>
> This makes sense to me. I'm just wondering if it wouldn't be
> simpler to do the check for r14 right in s390_emit_epilogue
> and then just call gen_return instead of gen_return_use
> directly there?
I had the same thought :-)
> > +++ b/gcc/config/s390/s390.md
> > @@ -10831,6 +10831,13 @@
> > (use (match_operand 0 "register_operand" "a"))])]
> >""
> > {
> > + if (REGNO (operands[0]) == RETURN_REGNUM && s390_can_use_return_insn ())
>
> This probably cannot happen in practice in this specific case,
> but in general a register_operand may also be e.g. a SUBREG,
> so you shouldn't use REGNO without first verifying that this
> is a REG. (If you move the check to s390_emit_epilogue as above,
> this point is moot; you don't even need to generate a REG RTX
> if it's for r14 then.)
There is reg_or_subregno exactly for this.
Segher
Re: [PATCH] dumpfile.c: fix stray dump_loc output (PR tree-optimization/87309)
On Wed, 2018-09-19 at 15:51 +0200, Richard Biener wrote:
> On Wed, Sep 19, 2018 at 12:42 PM David Malcolm
> wrote:
> >
> > In r262891 I reimplemented this call:
> > dump_printf_loc (MSG_NOTE, loc, "=== %s ===\n", name);
> > in dump_begin_scope to use direct calls to dump_loc:
> > if (dump_file)
> > {
> > dump_loc (MSG_NOTE, dump_file, loc.get_location_t ());
> > fprintf (dump_file, "=== %s ===\n", name);
> > }
> >
> > if (alt_dump_file)
> >{
> > dump_loc (MSG_NOTE, alt_dump_file, loc.get_location_t ());
> > fprintf (alt_dump_file, "=== %s ===\n", name);
> >}
> >
> > However ::dump_loc doesn't filter with pflags and alt_flags.
> >
> > This caused stray output of the form:
> > test.cpp:1:6: note: test.cpp:1:11: note:
> > when using -fopt-info with "optimized" or "missed".
> >
> > This patch adds this missing filtering, eliminating the stray
> > partial
> > note output.
> >
> > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> >
> > OK for trunk?
>
> OK
Thanks.
Ilya [CCed] spotted (in bugzilla) that I missed the case of
m_test_pp_flags. This is only used by selftests, but it seemed
appropriate to get it right, so I fixed that, and added selftest
coverage for it.
For reference, here's what I committed (r264481), self-approving the
slight tweak described above under the "obvious" rule.
Dave
gcc/ChangeLog:
PR tree-optimization/87309
* dumpfile.c (dump_context::begin_scope): Filter the dump_loc
calls with pflags and alt_flags.
(selftest::test_capture_of_dump_calls): Add test of interaction of
MSG_OPTIMIZED_LOCATIONS with AUTO_DUMP_SCOPE.
gcc/testsuite/ChangeLog:
PR tree-optimization/87309
* gcc.dg/pr87309.c: New test.
---
gcc/dumpfile.c | 29 ++---
gcc/testsuite/gcc.dg/pr87309.c | 4
2 files changed, 30 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr87309.c
diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c
index a81ab3e..5655e46 100644
--- a/gcc/dumpfile.c
+++ b/gcc/dumpfile.c
@@ -1048,14 +1048,14 @@ dump_context::get_scope_depth () const
void
dump_context::begin_scope (const char *name, const dump_location_t &loc)
{
- if (dump_file)
+ if (dump_file && (MSG_NOTE & pflags))
::dump_loc (MSG_NOTE, dump_file, loc.get_location_t ());
- if (alt_dump_file)
+ if (alt_dump_file && (MSG_NOTE & alt_flags))
::dump_loc (MSG_NOTE, alt_dump_file, loc.get_location_t ());
/* Support for temp_dump_context in selftests. */
- if (m_test_pp)
+ if (m_test_pp && (MSG_NOTE & m_test_pp_flags))
::dump_loc (MSG_NOTE, m_test_pp, loc.get_location_t ());
pretty_printer pp;
@@ -2304,6 +2304,29 @@ test_capture_of_dump_calls (const line_table_case &case_)
OPTINFO_KIND_FAILURE);
}
}
+
+ /* Verify that MSG_* affect AUTO_DUMP_SCOPE and the dump calls. */
+ {
+temp_dump_context tmp (false, MSG_OPTIMIZED_LOCATIONS);
+dump_printf_loc (MSG_NOTE, stmt, "msg 1\n");
+{
+ AUTO_DUMP_SCOPE ("outer scope", stmt);
+ dump_printf_loc (MSG_NOTE, stmt, "msg 2\n");
+ {
+ AUTO_DUMP_SCOPE ("middle scope", stmt);
+ dump_printf_loc (MSG_NOTE, stmt, "msg 3\n");
+ {
+ AUTO_DUMP_SCOPE ("inner scope", stmt);
+ dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, stmt, "msg 4\n");
+ }
+ dump_printf_loc (MSG_NOTE, stmt, "msg 5\n");
+ }
+ dump_printf_loc (MSG_NOTE, stmt, "msg 6\n");
+}
+dump_printf_loc (MSG_NOTE, stmt, "msg 7\n");
+
+ASSERT_DUMPED_TEXT_EQ (tmp, "test.txt:5:10: note:msg 4\n");
+ }
}
/* Run all of the selftests within this file. */
diff --git a/gcc/testsuite/gcc.dg/pr87309.c b/gcc/testsuite/gcc.dg/pr87309.c
new file mode 100644
index 000..8bd5a44
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr87309.c
@@ -0,0 +1,4 @@
+/* { dg-do compile } */
+/* { dg-options "-fopt-info-vec-optimized -O3" } */
+
+void a() {} /* { dg-bogus "note" } */
--
1.8.5.3
Re: [PATCH, rs6000] Update vec_splat references in testcases for validity.
Hi Will, On Thu, Sep 20, 2018 at 01:52:55PM -0500, Will Schmidt wrote: > This updates those powerpc testsuite tests that are using the > vec_splat() builtin with an invalid arg1. Per discussions during the > review of gimple-folding for vec_splat(), it was clarified > that arg1 for vec_splat() should be a valid index into the > referenced vector (no modulo). > 2018-11-20 Will Schmidt > > * gcc.target/powerpc/fold-vec-splat-char.c: Remove invalid > vec_splat calls from recently added tests. Update instruction counts. (Two spaces after dot.) > * gcc.target/powerpc/fold-vec-splat-floatdouble.c: Same. > * gcc.target/powerpc/fold-vec-splat-int.c: Same. > * gcc.target/powerpc/fold-vec-splat-pixel.c: Same. > * gcc.target/powerpc/fold-vec-splat-short.c: Same. > * g++.dg/ext/altivec-6.C: Updated vec_splat() calls. "Update". Other than those trivialities this looks fine to me. Okay for trunk. Thank you! Segher
Re: [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561)
On 09/20/2018 03:06 AM, Richard Biener wrote: On Wed, Sep 19, 2018 at 4:19 PM Martin Sebor wrote: On 09/18/2018 10:23 PM, Jeff Law wrote: On 9/18/18 1:46 PM, Martin Sebor wrote: On 09/18/2018 12:58 PM, Jeff Law wrote: On 9/18/18 11:12 AM, Martin Sebor wrote: My bad. Sigh. CCP doesn't track copies, just constants, so there's not going to be any data structure you can exploit. And I don't think there's a value number you can use to determine the two objects are the same. Hmm, let's back up a bit, what is does the relevant part of the IL look like before CCP? Is the real problem here that we have unpropagated copies lying around in the IL? Hmm, more likely the IL looksl ike: _8 = &pb_3(D)->a; _9 = _8; _1 = _9; strncpy (MEM_REF (&pb_3(D)->a), ...); MEM[(struct S *)_1].a[n_7] = 0; Yes, that is what the folder sees while the strncpy call is being transformed/folded by ccp. The MEM_REF is folded just after the strncpy call and that's when it's transformed into MEM[(struct S *)_8].a[n_7] = 0; (The assignments to _1 and _9 don't get removed until after the dom walk finishes). If we were to propagate the copies out we'd at best have: _8 = &pb_3(D)->a; strncpy (MEM_REF (&pb_3(D)->a), ...); MEM[(struct S *)_8].a[n_7] = 0; Is that in a form you can handle? Or would we also need to forward propagate the address computation into the use of _8? The above works as long as we look at the def_stmt of _8 in the MEM_REF (we currently don't). That's also what the last iteration of the loop does. In this case (with _8) it would be discovered in the first iteration, so the loop could be replaced by a simple if statement. But I'm not sure I understand the concern with the loop. Is it that we are looping at all, i.e., the cost? Or that ccp is doing something wrong or suboptimal? (Should have propagated the value of _8 earlier?) I suspect it's more a concern that things like copies are typically propagated away. So their existence in the IL (and consequently your need to handle them) raises the question "has something else failed to do its job earlier". During which of the CCP passes is this happening? Can we pull the warning out of the folder (even if that means having a distinct warning pass over the IL?) It happens during the third run of the pass. The only way to do what you suggest that I could think of is to defer the strncpy to memcpy transformation until after the warning pass. That was also my earlier suggestion: defer both it and the warning until the tree-ssa-strlen pass (where the warning is implemented to begin with -- the folder calls into it). If it's happening that late (CCP3) in general, then ISTM we ought to be able to get the warning out of the folder. We just have to pick the right spot. warn_restrict runs before fold_all_builtins, but after dom/vrp so we should have the IL in pretty good shape. That seems like about the right time. I wonder if we could generalize warn_restrict to be a more generic warning pass over the IL and place it right before fold_builtins. The restrict pass doesn't know about string lengths so it can't handle all the warnings about string built-ins (the strlen pass now calls into it to issue some). The strlen pass does so it could handle most if not all of them (the folder also calls into it to issue some warnings). It would work even better if it were also integrated with the object size pass. We're already working on merging strlen with sprintf. It seems to me that the strlen pass would benefit not only from that but also from integrating with object size and warn-restrict. With that, -Wstringop-overflow could be moved from builtins.c into it as well (and also benefit not only from accurate string lengths but also from the more accurate object size info). What do you think about that? I think integrating the various "passes" (objectsize is also as much a facility as a pass) generally makes sense given it might end up improving all of them and reduce code duplication. Okay. If Jeff agrees I'll see if I can make it happen for GCC 10. Until then, does either of you have any suggestions for a different approach in this patch or is it acceptable with the loop as is? Martin Richard. Martin PS I don't think I could do more than merger strlen and sprintf before stage 1 ends (if even that much) so this would be a longer term goal.
Re: [PATCH, rs6000] Fix PR86592 (p8-vec-xl-xst-v2.c)
On Tue, Sep 18, 2018 at 03:34:25PM -0500, Will Schmidt wrote:
> The expected codegen for this testcase with target {le} and
> option -mcpu=power8 is lxvd2x and stxvd2x. It was initially
> committed with contents as seen on builds for P7, which was
> incorrect. Update as is appropriate.
> 2018-09-18 Will Schmidt
>
> PR testsuite/86592
> * p8-vec-xl-xst-v2.c: Add and update expected codegen.
gcc.target/powerpc/...
> -/* { dg-final { scan-assembler-times "lvx" 4 } } */
> -/* { dg-final { scan-assembler-times "stvx" 4 } } */
> -/* { dg-final { scan-assembler-times "xxpermdi" 0 } } */
> +/* { dg-final { scan-assembler-times {\mlxvd2x\M} 4 } } */
> +/* { dg-final { scan-assembler-times {\mstxvd2x\M} 4 } } */
Should it not check for xxpermdi? Okay for trunk with whichever way
you decide. Thanks!
Segher
Re: C++ PATCH for c++/87372, __func__ constexpr evaluation
On Fri, Sep 21, 2018 at 09:37:53AM +0200, Jakub Jelinek wrote:
> On Thu, Sep 20, 2018 at 11:56:37PM -0400, Marek Polacek wrote:
> > The patch for P0595R1 - is_constant_evaluated had this hunk:
> >
> > @@ -5279,7 +5315,9 @@ maybe_constant_init_1 (tree t, tree decl, bool
> > allow_non_constant)
> >else if (CONSTANT_CLASS_P (t) && allow_non_constant)
> > /* No evaluation needed. */;
> >else
> > -t = cxx_eval_outermost_constant_expr (t, allow_non_constant, false,
> > decl);
> > +t = cxx_eval_outermost_constant_expr (t, allow_non_constant,
> > + !allow_non_constant,
> > + pretend_const_required, decl);
> >if (TREE_CODE (t) == TARGET_EXPR)
> > {
> >tree init = TARGET_EXPR_INITIAL (t);
> >
> > the false -> !allow_non_constant change means that when calling
> > cxx_constant_init strict will be true because cxx_constant_init does not
> > allow
> > non constants. That means that for VAR_DECLs such as __func__ we'll call
> > decl_really_constant_value instead of decl_constant_value. But only the
> > latter
> > can evaluate __func__ to "foo()".
> >
> > Jakub, was there a specific reason for this change? Changing it back still
> > regtests cleanly and the attached test compiles again.
>
> It just didn't feel right that cxx_constant_init which looks like a function
> that requires strict conformance still passes false as strict.
> If there is a reason to pass false, I think we need a comment that explains
> it.
I think we use strict = true for *_constant_value, but *_constant_init should
get strict = false.
Marek
[PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions
Hi, this is the 4th version of the patch. mainly address Martin’s comments on some spelling issues. I have tested the patch on both x86 and aarch64, no issue. Okay for commit? thanks. Qing. gcc/ChangeLog +2018-09-20 Qing Zhao + + * cif-code.def (FUNCTION_EXTERN): New CIFCODE. + * common.opt (-finline-only-static): New option. + * doc/invoke.texi: Document -finline-only-static. + * ipa-inline.c (can_inline_edge_p): Control inlining based on + function's linkage. gcc/testsuite/ChangeLog +2018-09-20 Qing Zhao + + * gcc.dg/inline_only_static.c: New test. + New-inline-only-static.patch Description: Binary data
Re: C++ PATCH for c++/87372, __func__ constexpr evaluation
On Fri, Sep 21, 2018 at 11:04 AM, Marek Polacek wrote:
> On Fri, Sep 21, 2018 at 09:37:53AM +0200, Jakub Jelinek wrote:
>> On Thu, Sep 20, 2018 at 11:56:37PM -0400, Marek Polacek wrote:
>> > The patch for P0595R1 - is_constant_evaluated had this hunk:
>> >
>> > @@ -5279,7 +5315,9 @@ maybe_constant_init_1 (tree t, tree decl, bool
>> > allow_non_constant)
>> >else if (CONSTANT_CLASS_P (t) && allow_non_constant)
>> > /* No evaluation needed. */;
>> >else
>> > -t = cxx_eval_outermost_constant_expr (t, allow_non_constant, false,
>> > decl);
>> > +t = cxx_eval_outermost_constant_expr (t, allow_non_constant,
>> > + !allow_non_constant,
>> > + pretend_const_required, decl);
>> >if (TREE_CODE (t) == TARGET_EXPR)
>> > {
>> >tree init = TARGET_EXPR_INITIAL (t);
>> >
>> > the false -> !allow_non_constant change means that when calling
>> > cxx_constant_init strict will be true because cxx_constant_init does not
>> > allow
>> > non constants. That means that for VAR_DECLs such as __func__ we'll call
>> > decl_really_constant_value instead of decl_constant_value. But only the
>> > latter
>> > can evaluate __func__ to "foo()".
>> >
>> > Jakub, was there a specific reason for this change? Changing it back still
>> > regtests cleanly and the attached test compiles again.
>>
>> It just didn't feel right that cxx_constant_init which looks like a function
>> that requires strict conformance still passes false as strict.
>> If there is a reason to pass false, I think we need a comment that explains
>> it.
>
> I think we use strict = true for *_constant_value, but *_constant_init should
> get strict = false.
Right. In _init we try to get constant values for more than just C++
constant expressions.
Jason
Re: [ARM/FDPIC v2 01/21] [ARM] FDPIC: Add -mfdpic option support
On Fri, 31 Aug 2018 at 16:09, Christophe Lyon wrote: > > On Wed, 29 Aug 2018 at 12:46, Kyrill Tkachov > wrote: > > > > Hi Christophe, > > > > On 13/07/18 17:10, christophe.l...@st.com wrote: > > > From: Christophe Lyon > > > > > > 2018-XX-XX Christophe Lyon > > > Mickaël Guêné > > > > > > gcc/ > > > * config/arm/arm.opt: Add -mfdpic option. > > > > > > Change-Id: Ie5c4ed7434488933de6133186da09cd3ea1291a7 > > > > > > diff --git a/gcc/config/arm/arm.opt b/gcc/config/arm/arm.opt > > > index a1286a4..231c1cb 100644 > > > --- a/gcc/config/arm/arm.opt > > > +++ b/gcc/config/arm/arm.opt > > > @@ -302,3 +302,7 @@ When linking for big-endian targets, generate a > > > legacy BE32 format image. > > > mbranch-cost= > > > Target RejectNegative Joined UInteger Var(arm_branch_cost) Init(-1) > > > Cost to assume for a branch insn. > > > + > > > +mfdpic > > > +Target Report Mask(FDPIC) > > > +Enable Function Descriptor PIC mode. > > > > So since this is an ABI, why isn't it just adding a new -mabi value? > > I think it's just an oversight, because we always talk about "FDPIC > mode". I can change it, it's meant to be mostly hidden and toggled by > the target name. > Actually, the other targets with FDPIC support use -mfdpic (bfin, frv, sh), so I'm not sure what's the best option? Using -mfdpic has the advantage of consistency across targets. > > In any case, command-line option changes need documentation in invoke.texi. > I keep forgetting this, sorry. > > > Thanks, > > Kyrill > > > > > > > -- > > > 2.6.3 > > > > >
Re: [PATCH] PR libstdc++/78179 run long double tests separately
On 21/09/18 15:48 +0200, Hans-Peter Nilsson wrote: Date: Fri, 21 Sep 2018 12:21:31 +0100 From: Jonathan Wakely Here's the corrected patch, any objections to this? Quite the contrary; LGTM. Committed to trunk.
Re: [PATCH] PR libstdc++/87135 Rehash only when necessary (LWG2156)
Here is the patch complement.
load_factor.cc failure revealed a bug in load factor management. Now
computation of _M_next_resize is consistent throughout the different
places where it is set.
The 2 other tests only have to be adapted.
PR libstdc++/87135
* src/c++11/hashtable_c++0x.cc (_Prime_rehash_policy::_M_next_bkt):
Use __builtin_floor to compute _M_next_resize.
* testsuite/23_containers/unordered_set/hash_policy/71181.cc: Adapt.
* testsuite/23_containers/unordered_set/hash_policy/prime_rehash.cc:
Adapt.
Now fully tested under x86_64.
Ok to commit ?
François
On 09/19/2018 01:07 PM, Jonathan Wakely wrote:
On 18/09/18 22:39 +0200, François Dumont wrote:
On 09/18/2018 10:41 AM, Jonathan Wakely wrote:
On 13/09/18 07:49 +0200, François Dumont wrote:
All changes limited to hashtable_c++0x.cc file.
_Prime_rehash_policy::_M_next_bkt now really does what its comment
was declaring that is to say:
// Return a prime no smaller than n.
_Prime_rehash_policy::_M_need_rehash rehash only when _M_next_size
is exceeded, not only when it is reach.
PR libstdc++/87135
* src/c++11/hashtable_c++0x.cc:
(_Prime_rehash_policy::_M_next_bkt): Return a prime no smaller
than
requested size, but not necessarily greater.
(_Prime_rehash_policy::_M_need_rehash): Rehash only if target
size is
strictly greater than next resize threshold.
* testsuite/23_containers/unordered_map/modifiers/reserve.cc:
Adapt test
to validate that there is no rehash as long as number of
insertion is
lower or equal to the reserved number of elements.
unordered_map tests successful, ok to commit once all other tests
completed ?
François
diff --git a/libstdc++-v3/src/c++11/hashtable_c++0x.cc
b/libstdc++-v3/src/c++11/hashtable_c++0x.cc
index a776a8506fe..ec6031b3f5b 100644
--- a/libstdc++-v3/src/c++11/hashtable_c++0x.cc
+++ b/libstdc++-v3/src/c++11/hashtable_c++0x.cc
@@ -46,10 +46,10 @@ namespace __detail
{
// Optimize lookups involving the first elements of __prime_list.
// (useful to speed-up, eg, constructors)
- static const unsigned char __fast_bkt[13]
- = { 2, 2, 3, 5, 5, 7, 7, 11, 11, 11, 11, 13, 13 };
+ static const unsigned char __fast_bkt[]
+ = { 2, 2, 2, 3, 5, 5, 7, 7, 11, 11, 11, 11, 13, 13 };
- if (__n <= 12)
+ if (__n < sizeof(__fast_bkt) / sizeof(unsigned char))
sizeof(unsigned char) is defined to be 1, always.
I also though it was overkill but there are so many platforms that I
prefer to be caution. Good to know that it can't be otherwise.
I think this should be just sizeof(__fast_bkt), or if you're trying to
guard against the type of __fast_bkt changing, then use
sizeof(__fast_bkt) / sizeof(__fast_bkt[0]))
I committed with simply sizeof(__fast_bkt)
This caused some testsuite regressions:
FAIL: 23_containers/unordered_set/hash_policy/71181.cc execution test
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/71181.cc:42:
void test(int) [with _USet = std::unordered_set]: Assertion
'us.bucket_count() == bkts' failed.
FAIL: 23_containers/unordered_set/hash_policy/load_factor.cc execution
test
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/load_factor.cc:50:
void test() [with _USet = std::unordered_set]: Assertion
'us.load_factor() <= us.max_load_factor()' failed.
FAIL: 23_containers/unordered_set/hash_policy/prime_rehash.cc
execution test
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/prime_rehash.cc:37:
void test01(): Assertion 'nxt == policy._M_next_bkt(mx)' failed.
diff --git a/libstdc++-v3/src/c++11/hashtable_c++0x.cc b/libstdc++-v3/src/c++11/hashtable_c++0x.cc
index 462767612f0..b9b11ff4385 100644
--- a/libstdc++-v3/src/c++11/hashtable_c++0x.cc
+++ b/libstdc++-v3/src/c++11/hashtable_c++0x.cc
@@ -52,7 +52,7 @@ namespace __detail
if (__n < sizeof(__fast_bkt))
{
_M_next_resize =
- __builtin_ceil(__fast_bkt[__n] * (long double)_M_max_load_factor);
+ __builtin_floor(__fast_bkt[__n] * (long double)_M_max_load_factor);
return __fast_bkt[__n];
}
@@ -75,7 +75,7 @@ namespace __detail
_M_next_resize = std::size_t(-1);
else
_M_next_resize =
- __builtin_ceil(*__next_bkt * (long double)_M_max_load_factor);
+ __builtin_floor(*__next_bkt * (long double)_M_max_load_factor);
return *__next_bkt;
}
diff --git a/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/71181.cc b/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/71181.cc
index 0270ea52b9c..ba783d26847 100644
--- a/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/71181.cc
+++ b/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/71181.cc
@@ -30,7 +30,7 @@ template
auto bkts = us.bucket_count();
for (int i = 0; i != threshold; ++i)
{
- if (i == nb_reserved)
+ if (i >= nb_reserved)
{
nb_reserved = b
Re: [PATCH,rs6000] Add builtins for accessing the FPSCR
Hi Carl,
Sorry for the late review.
On Mon, Sep 17, 2018 at 03:03:28PM -0700, Carl Love wrote:
> * config/rs6000.c (rs6000_expand_mtfsb0_mtfsb1_builtin): Add.
config/rs6000/rs6000.c
> +RS6000_BUILTIN_X (RS6000_BUILTIN_MTFSB0, "__builtin_mtfsb0",
> + RS6000_BTM_ALWAYS,
> + RS6000_BTC_MISC | RS6000_BTC_UNARY,
> + CODE_FOR_rs6000_mtfsb0)
I think you need RS6000_BTC_VOID on most of these calls?
> static rtx
> +rs6000_expand_mtfsb_builtin (enum insn_code icode, tree exp)
The changelog has the function name wrong?
> + pat = GEN_FCN (icode) (op0);
> + if (! pat)
No space after ! (or any other prefix operator that doesn't have letters
in its name, i.e. casts, sizeof, etc.)
> +static rtx
> +rs6000_expand_set_fpscr_rn_builtin (enum insn_code icode, tree exp)
> + /* If the argument is a constant, check the range. Argument can only be a
> + 2-bit value. Unfortunately, can't check the range of the value at
> + compile time if the argument is a variable. */
So what do we do for variable args? Mask off the bits?
> +static rtx
> +rs6000_expand_set_fpscr_drn_builtin (enum insn_code icode, tree exp)
> + /* If the argument is a constant, check the range. Agrument can only be a
> + 3-bit value. Unfortunately, can't check the range of the value at
> + compile time if the argument is a variable.
> + */
Don't put */ on a separate line please.
> + if (GET_CODE (op0) == CONST_INT && !const_0_to_7_operand(op0, VOIDmode ))
Stray space after VOIDmode.
> +(define_insn "rs6000_mtfsb0"
> + [(unspec_volatile [(match_operand:SI 0 "u5bit_cint_operand" "n")]
> + UNSPECV_MTFSB0)]
> + "TARGET_HARD_FLOAT"
> + "mtfsb0 %0"
> + [(set_attr "type" "fp")])
Hrm... Does all of this work with -msoft-float? Does it not ICE at least?
> +(define_expand "rs6000_set_fpscr_rn"
> + [(match_operand:DI 0 "gpc_reg_operand")]
(Two spaces.)
You could handle immediate operands separately: you need only two mtfsbN
instructions for that, which is smaller and faster than the "variable"
sequence. Well, for non-P9 anyway.
> +(define_expand "rs6000_mffsl"
> + [(set (match_operand:DF 0 "gpc_reg_operand")
> + (unspec_volatile:DF [(const_int 0)] UNSPECV_MFFSL))]
> + "TARGET_HARD_FLOAT"
> +{
> + /* If the low latency mffsl instruction (ISA 3.0) is available use it,
> + otherwise fall back to the older mffs instruction to emulate the mffsl
> + instruction. */
> +
> + if (TARGET_P9_MISC)
> + emit_insn (gen_rs6000_mffsl_hw (operands[0]));
The indent is incorrect. But you could just not do anything if
TARGET_P9_MISC: the RTL pattern above already is exactly what you need.
So "if (!TARGET_P9_MISC)" and then that block with the DONE moved in there,
and the TARGET_P9_MISC case can just fall through.
> + emit_insn (gen_anddi3 (tmp_di, tmp_di, GEN_INT (0x70007F0FFLL)));
Write numbers in lower case please (for readability). 0x70007f0ffLL
> +(define_insn "rs6000_mtfsf_hi"
> + [(unspec_volatile [(match_operand:SI 0 "const_int_operand" "i")
const_int_operand is "n": an actual number, not e.g. a constant address
(like "i" allows). It doesn't make a real difference in some cases, but
it's best to get it right.
> +the most significant word on 32-bit environments. The @code{__builtin_mffs}
> +return the value of the FPSCR register. Note, ISA 3.0 supports the
> +@code{__builtin_mffsl()} which is a lower latency version of this builtin.
> The
mffsl does not return the whole fpscr, just the more useful (and cheaper
to access!) fields: rn and drn, the exception enables, the non-sticky
exception flags.
> +++ b/gcc/testsuite/gcc.target/powerpc/test_fpscr_drn_builtin.c
> @@ -0,0 +1,116 @@
> +/* { dg-do run { target { powerpc*-*-linux* && lp64 } } } */
Why only linux?
Okay for trunk with the nits fixed; the things that are more like
extensions can happen later (if at all). Thanks!
Segher
OpenCoarrays integration with gfortran
My apologies for kidnapping this thread: On 9/20/18 1: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.) I would like to put in my humble 2 cents worth here. OpenCoarrays was/is intended for a very broad audience, various large systems such as Cray, etc. I think this influenced heavily the path of its development, which is certainly OK. It was/is intended to interface libraries such as OpenMPI or MPICH to gfortran as well as other Fortran compilers. The actual library source code is contained mostly in one source file. After all the attempts to integrate into the GNU build systems without much success my thinking has shifted. Keep in mind that the OpenCoarrays implementation is quite dependent on gfortran and in fact has to do special things in the build dependent on the version of gcc/gfortran a user happens to use. I dont think this is a good situation. So I see two realistic strategies. The first is already talked about a lot and is the cleanest approach for gfortran: 1) Focus on distribution packages such as Fedora, Debian, Ubuntu, Windows, etc. Building of these packages needs to be automated into the distributions. I think mostly this is what is happening and relies on the various distribution maintainers to do so. Their support is greatly appreciated and this really is the cleanest approach. The second option is not discussed as much because it leaves OpenCoarrays behind in a sense and requires an editing cycle in two places to fix bugs or add features. 2) Take the one source file, edit out all the macros that define prefixes to function calls, hard code the gfortran prefixes etc and fork it directly into the libgfortran library under GPL with attributions to the original developers as appropriate. Strategy 2 would lock into specific current standard versions of the MPI interface and would support less bleeding edge changes. It would also require either OpenMPI or MPICH as a new gfortran dependency for building, which not all users may need. So we would need some configuration magic to enable or disable this portion of the build. Something like --with-MPI-support would do the trick. Strategy 2 does add burden to gfortran maintainers who are already overloaded. But, as the code matures the burden would decrease, particularly once TEAMS are finished. Strategy 2 does have some advantages. For example, eliminating the need for separate CAF and CAFRUN scripts which are a wrapper on gfortran. The coarray features are part of the Fortran language and gfortran should just "handle it" transparently using an environment variable to define the number of images at run time. It would also actually eliminate the need to manage all of the separate distribution packages. So from a global point of view the overall maintanance effort would be reduced. Strategy 2 would enable a set of users who are not focused so much on distributions and loading packages, etc etc and those who are dependent on getting through bureaucratic administrations who already are loading gfortran on systems and would not have to also get another package approved. People would just have to stop thinking about it and just use it. So I think there are real advantages to Strategy 2 as well as Strategy 1 and think it should be at least included in discussions. I would even suggest there is likely a combination of 1 and 2 that may hit the mark. For example, keeping OpenCoarrays as a separate package for bleeding edge development and migrating the stable features into libgfortran on a less frequent cycle. As I said, my 2 cents worth. Regards to all, Jerry
Re: [PATCH] Use vectored writes when reporting errors and warnings.
Janne, this looks OK. Since you are touching on configuration and posix dependencies have you tested under any other systems? Jerry On 9/21/18 1:41 AM, Janne Blomqvist wrote: PING On Wed, Sep 12, 2018 at 10:17 PM Janne Blomqvist wrote: When producing error and warning messages, libgfortran writes a message by using many system calls. By using vectored writes (the POSIX writev function) when available and feasible to use without major surgery, we reduce the chance that output gets intermingled with other output to stderr. In practice, this is done by introducing a new function estr_writev in addition to the existing estr_write. In order to use this, the old st_vprintf is removed, replaced by direct calls of vsnprintf, allowing more message batching. Regtested on x86_64-pc-linux-gnu, Ok for trunk? libgfortran/ChangeLog: 2018-09-12 Janne Blomqvist * config.h.in: Regenerated. * configure: Regenerated. * configure.ac: Check for writev and sys/uio.h. * libgfortran.h: Include sys/uio.h. (st_vprintf): Remove prototype. (struct iovec): Define if not available. (estr_writev): New prototype. * runtime/backtrace.c (error_callback): Use estr_writev. * runtime/error.c (ST_VPRINTF_SIZE): Remove. (estr_writev): New function. (st_vprintf): Remove. (gf_vsnprintf): New function. (ST_ERRBUF_SIZE): New macro. (st_printf): Use vsnprintf. (os_error): Use estr_writev. (runtime_error): Use vsnprintf and estr_writev. (runtime_error_at): Likewise. (runtime_warning_at): Likewise. (internal_error): Use estr_writev. (generate_error_common): Likewise. (generate_warning): Likewise. (notify_std): Likewise. * runtime/pause.c (pause_string): Likewise. * runtime/stop.c (report_exception): Likewise. (stop_string): Likewise. (error_stop_string): Likewise. --- snip ---
Re: [PATCH] Remove Pascal-related entries in code and comments.
On Fri, 21 Sep 2018, Martin Liška wrote: > Hi. > > This is removal of some Pascal-related comments. There are two different kinds of comments being removed here. There are comments relating to GNU Pascal, which has long been a dead project, so removing those seems reasonable. But there are also comments / documentation references referring to Pascal as a language that has some feature, rather than to the GNU Pascal implementation, and it's much less clear those should be removed. And where you change "As in Algol and Pascal, lexical scoping of functions.", which is one of the latter kind, I'd think Algol is likely to be more obscure than Pascal to readers of the manual, so if it changes at all it should probably be to refer to more modern examples of languages with nested functions that form closures. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] PR libstdc++/87135 Rehash only when necessary (LWG2156)
On 21/09/18 18:10 +0200, François Dumont wrote: Here is the patch complement. load_factor.cc failure revealed a bug in load factor management. Now computation of _M_next_resize is consistent throughout the different places where it is set. The 2 other tests only have to be adapted. PR libstdc++/87135 * src/c++11/hashtable_c++0x.cc (_Prime_rehash_policy::_M_next_bkt): Use __builtin_floor to compute _M_next_resize. * testsuite/23_containers/unordered_set/hash_policy/71181.cc: Adapt. * testsuite/23_containers/unordered_set/hash_policy/prime_rehash.cc: Adapt. Now fully tested under x86_64. Ok to commit ? OK, thanks.
Re: [PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)
On 09/17/2018 07:30 PM, Jeff Law wrote:
On 8/28/18 6:12 PM, Martin Sebor wrote:
Sadly, dstbase is the PARM_DECL for d. That's where things are going
"wrong". Not sure why you're getting the PARM_DECL in that case. I'd
debug get_addr_base_and_unit_offset to understand what's going on.
Essentially you're getting different results of
get_addr_base_and_unit_offset in a case where they arguably should be
the same.
Probably get_attr_nonstring_decl has the same "mistake" and returns
the PARM_DECL instead of the SSA name pointer. So we're comparing
apples and oranges here.
Returning the SSA_NAME_VAR from get_attr_nonstring_decl() is
intentional but the function need not (perhaps should not)
also set *REF to it.
Yeah:
/* If EXPR refers to a character array or pointer declared attribute
nonstring return a decl for that array or pointer and set *REF to
the referenced enclosing object or pointer. Otherwise returns
null. */
tree
get_attr_nonstring_decl (tree expr, tree *ref)
{
tree decl = expr;
if (TREE_CODE (decl) == SSA_NAME)
{
gimple *def = SSA_NAME_DEF_STMT (decl);
if (is_gimple_assign (def))
{
tree_code code = gimple_assign_rhs_code (def);
if (code == ADDR_EXPR
|| code == COMPONENT_REF
|| code == VAR_DECL)
decl = gimple_assign_rhs1 (def);
}
else if (tree var = SSA_NAME_VAR (decl))
decl = var;
}
if (TREE_CODE (decl) == ADDR_EXPR)
decl = TREE_OPERAND (decl, 0);
if (ref)
*ref = decl;
I see a lot of "magic" here again in the attempt to "propagate"
a nonstring attribute.
That's the function's purpose: to look for the attribute. Is
there a better way to do this?
Note
foo (char *p __attribute__(("nonstring")))
{
p = "bar";
strlen (p); // or whatever is necessary to call get_attr_nonstring_decl
}
is perfectly valid and p as passed to strlen is _not_ nonstring(?).
I don't know if you're saying that it should get a warning or
shouldn't. Right now it doesn't because the strlen() call is
folded before we check for nonstring.
I could see an argument for diagnosing it but I suspect you
wouldn't like it because it would mean more warning from
the folder. I could also see an argument against it because,
as you said, it's safe.
If you take the assignment to p away then a warning is issued,
and that's because p is declared with attribute nonstring.
That's also why get_attr_nonstring_decl looks at SSA_NAME_VAR.
I think in your code comparing bases you want to look at the _original_
argument to the string function rather than what get_attr_nonstring_decl
returned as ref.
I've adjusted get_attr_nonstring_decl() to avoid setting *REF
to SSA_NAME_VAR. That let me remove the GIMPLE_NOP code from
the patch. I've also updated the comment above SSA_NAME_VAR
to clarify its purpose per Jeff's comments.
Attached is an updated revision with these changes.
Martin
gcc-87028.diff
PR tree-optimization/87028 - false positive -Wstringop-truncation strncpy with
global variable source string
gcc/ChangeLog:
PR tree-optimization/87028
* calls.c (get_attr_nonstring_decl): Avoid setting *REF to
SSA_NAME_VAR.
* gimple-fold.c (gimple_fold_builtin_strncpy): Avoid folding
when statement doesn't belong to a basic block.
* tree.h (SSA_NAME_VAR): Update comment.
* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Simplify.
gcc/testsuite/ChangeLog:
PR tree-optimization/87028
* c-c++-common/Wstringop-truncation.c: Remove xfails.
* gcc.dg/Wstringop-truncation-5.c: New test.
Index: gcc/calls.c
===
--- gcc/calls.c (revision 263928)
+++ gcc/calls.c (working copy)
@@ -1503,6 +1503,7 @@ tree
get_attr_nonstring_decl (tree expr, tree *ref)
{
tree decl = expr;
+ tree var = NULL_TREE;
if (TREE_CODE (decl) == SSA_NAME)
{
gimple *def = SSA_NAME_DEF_STMT (decl);
@@ -1515,17 +1516,25 @@ get_attr_nonstring_decl (tree expr, tree *ref)
|| code == VAR_DECL)
decl = gimple_assign_rhs1 (def);
}
- else if (tree var = SSA_NAME_VAR (decl))
- decl = var;
+ else
+ var = SSA_NAME_VAR (decl);
}
if (TREE_CODE (decl) == ADDR_EXPR)
decl = TREE_OPERAND (decl, 0);
+ /* To simplify calling code, store the referenced DECL regardless of
+ the attribute determined below, but avoid storing the SSA_NAME_VAR
+ obtained above (it's not useful for dataflow purposes). */
if (ref)
*ref = decl;
- if (TREE_CODE (decl) == ARRAY_REF)
+ /* Use the SSA_NAME_VAR that was determined above to see if it's
+ declared nonstring. Otherwise drill down into the referenced
+ DECL. */
+ if (var)
+decl = var;
+ else if (TREE_CODE (decl) == ARRAY_REF)
decl = TREE_OPERAND (decl, 0);
else if (TREE_CODE (decl) == COMPONENT_REF)
decl = TREE_OPERAND (decl, 1);
The m
[Patch, fortran] PR87359 [9 regression] pointer being freed was not allocated
This bug was something of a disaster for Jeurgen Reuter and so I set
to it right away. Jeurgen's reduction of the failing programs save a
huge amount of time and the fix turned out to be a one-liner.
Committed after testing by Dominique.
Bootstrapped and regtested on FC28/x86_64.
Paul
Author: pault
Date: Fri Sep 21 17:26:23 2018
New Revision: 264485
URL: https://gcc.gnu.org/viewcvs?rev=264485&root=gcc&view=rev
Log:
2018-09-21 Paul Thomas
PR fortran/87359
* trans-stmt.c (gfc_trans_allocate): Don't deallocate alloc
components if must_finalize is set for expr3.
2018-09-21 Paul Thomas
PR fortran/87359
* gfortran.dg/finalize_33.f90 : New test.
Added:
trunk/gcc/testsuite/gfortran.dg/finalize_33.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
Index: gcc/fortran/trans-stmt.c
===
*** gcc/fortran/trans-stmt.c (revision 264426)
--- gcc/fortran/trans-stmt.c (working copy)
*** gfc_trans_allocate (gfc_code * code)
*** 5996,6002
if ((code->expr3->ts.type == BT_DERIVED
|| code->expr3->ts.type == BT_CLASS)
&& (code->expr3->expr_type != EXPR_VARIABLE || temp_obj_created)
! && code->expr3->ts.u.derived->attr.alloc_comp)
{
tmp = gfc_deallocate_alloc_comp (code->expr3->ts.u.derived,
expr3, code->expr3->rank);
--- 5996,6003
if ((code->expr3->ts.type == BT_DERIVED
|| code->expr3->ts.type == BT_CLASS)
&& (code->expr3->expr_type != EXPR_VARIABLE || temp_obj_created)
! && code->expr3->ts.u.derived->attr.alloc_comp
! && !code->expr3->must_finalize)
{
tmp = gfc_deallocate_alloc_comp (code->expr3->ts.u.derived,
expr3, code->expr3->rank);
Index: gcc/testsuite/gfortran.dg/finalize_33.f90
===
*** gcc/testsuite/gfortran.dg/finalize_33.f90 (nonexistent)
--- gcc/testsuite/gfortran.dg/finalize_33.f90 (working copy)
***
*** 0
--- 1,119
+ ! { dg-do run }
+ ! { dg-options "-fdump-tree-original" }
+ !
+ ! Tests the fix for PR87359 in which the finalization of
+ ! 'source=process%component%extract_mci_template()' in the allocation
+ ! of 'process%mci' caused invalid reads and freeing of already freed
+ ! memory. This test is a greatly reduced version of the original code.
+ !
+ ! Contributed by Juergen Reuter
+ !
+ module mci_base
+ implicit none
+ private
+ public :: mci_t
+ public :: mci_midpoint_t
+ public :: cnt
+ integer :: cnt = 0
+ type, abstract :: mci_t
+ integer, dimension(:), allocatable :: chain
+ end type mci_t
+ type, extends (mci_t) :: mci_midpoint_t
+ contains
+ final :: mci_midpoint_final
+ end type mci_midpoint_t
+ contains
+ IMPURE ELEMENTAL SUBROUTINE mci_midpoint_final(arg)
+ TYPE(mci_midpoint_t), INTENT(INOUT) :: arg
+ cnt = cnt + 1
+ END SUBROUTINE mci_midpoint_final
+ end module mci_base
+
+ !
+
+ module process_config
+ use mci_base
+ implicit none
+ private
+ public :: process_component_t
+ type :: process_component_t
+ class(mci_t), allocatable :: mci_template
+contains
+ procedure :: init => process_component_init
+ procedure :: extract_mci_template => process_component_extract_mci_template
+ end type process_component_t
+
+ contains
+
+ subroutine process_component_init (component, mci_template)
+ class(process_component_t), intent(out) :: component
+ class(mci_t), intent(in), allocatable :: mci_template
+ if (allocated (mci_template)) &
+ allocate (component%mci_template, source = mci_template)
+ end subroutine process_component_init
+
+ function process_component_extract_mci_template (component) &
+ result (mci_template)
+ class(mci_t), allocatable :: mci_template
+ class(process_component_t), intent(in) :: component
+ if (allocated (component%mci_template)) &
+allocate (mci_template, source = component%mci_template)
+ end function process_component_extract_mci_template
+ end module process_config
+
+ !
+
+ module process
+ use mci_base
+ use process_config
+ implicit none
+ private
+ public :: process_t
+ type :: process_t
+ private
+ type(process_component_t) :: component
+ class(mci_t), allocatable :: mci
+contains
+ procedure :: init_component => process_init_component
+ procedure :: setup_mci => process_setup_mci
+ end type process_t
+ contains
+ subroutine process_init_component &
+(process, mci_template)
+ class(process_t), intent(inout), target :: process
+ class(mci_t), intent(in), allocatable :: mci_template
+ call process%component%init (mci_template)
+ end subroutine process_init_component
+
+ subroutine p
Re: C++ PATCH for c++/87372, __func__ constexpr evaluation
On Fri, Sep 21, 2018 at 11:19:34AM -0400, Jason Merrill wrote:
> On Fri, Sep 21, 2018 at 11:04 AM, Marek Polacek wrote:
> > On Fri, Sep 21, 2018 at 09:37:53AM +0200, Jakub Jelinek wrote:
> >> On Thu, Sep 20, 2018 at 11:56:37PM -0400, Marek Polacek wrote:
> >> > The patch for P0595R1 - is_constant_evaluated had this hunk:
> >> >
> >> > @@ -5279,7 +5315,9 @@ maybe_constant_init_1 (tree t, tree decl, bool
> >> > allow_non_constant)
> >> >else if (CONSTANT_CLASS_P (t) && allow_non_constant)
> >> > /* No evaluation needed. */;
> >> >else
> >> > -t = cxx_eval_outermost_constant_expr (t, allow_non_constant, false,
> >> > decl);
> >> > +t = cxx_eval_outermost_constant_expr (t, allow_non_constant,
> >> > + !allow_non_constant,
> >> > + pretend_const_required, decl);
> >> >if (TREE_CODE (t) == TARGET_EXPR)
> >> > {
> >> >tree init = TARGET_EXPR_INITIAL (t);
> >> >
> >> > the false -> !allow_non_constant change means that when calling
> >> > cxx_constant_init strict will be true because cxx_constant_init does not
> >> > allow
> >> > non constants. That means that for VAR_DECLs such as __func__ we'll call
> >> > decl_really_constant_value instead of decl_constant_value. But only the
> >> > latter
> >> > can evaluate __func__ to "foo()".
> >> >
> >> > Jakub, was there a specific reason for this change? Changing it back
> >> > still
> >> > regtests cleanly and the attached test compiles again.
> >>
> >> It just didn't feel right that cxx_constant_init which looks like a
> >> function
> >> that requires strict conformance still passes false as strict.
> >> If there is a reason to pass false, I think we need a comment that explains
> >> it.
> >
> > I think we use strict = true for *_constant_value, but *_constant_init
> > should
> > get strict = false.
>
> Right. In _init we try to get constant values for more than just C++
> constant expressions.
Is the patch OK then?
Marek
[Patch, fortran] PR77325 - ICE in gimplify_var_or_parm_decl, at gimplify.c:1933
This is yet another deferred character problem occurring at exactly
the same place as 87239 and 84109. I found another bug while going
along and so have fixed that too.
Bootstrapped and regtested on FC28/x86_64.
I will apply all three to 8-branch in slightly more than one week's time.
Paul
2018-09-21 Paul Thomas
PR fortran/77325
* trans-array.c (gfc_alloc_allocatable_for_assignment): If the
rhs has a charlen expression, convert that and use it.
* trans-expr.c (gfc_trans_assignment_1): The rse.pre for the
assignment of deferred character array vars to a realocatable
lhs should not be added to the exterior block since vector
indices, for example, generate temporaries indexed within the
loop.
2018-09-21 Paul Thomas
PR fortran/77325
* gfortran.dg/deferred_character_22.f90 : New test.
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (revision 264426)
--- gcc/fortran/trans-array.c (working copy)
*** gfc_alloc_allocatable_for_assignment (gf
*** 9964,9969
--- 9964,9978
tmp = concat_str_length (expr2);
expr2->ts.u.cl->backend_decl = gfc_evaluate_now (tmp, &fblock);
}
+ else if (!tmp && expr2->ts.u.cl->length)
+ {
+ gfc_se tmpse;
+ gfc_init_se (&tmpse, NULL);
+ gfc_conv_expr_type (&tmpse, expr2->ts.u.cl->length,
+ gfc_charlen_type_node);
+ tmp = tmpse.expr;
+ expr2->ts.u.cl->backend_decl = gfc_evaluate_now (tmp, &fblock);
+ }
tmp = fold_convert (TREE_TYPE (expr1->ts.u.cl->backend_decl), tmp);
}
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c (revision 264427)
--- gcc/fortran/trans-expr.c (working copy)
*** gfc_trans_assignment_1 (gfc_expr * expr1
*** 10275,10291
/* When assigning a character function result to a deferred-length variable,
the function call must happen before the (re)allocation of the lhs -
otherwise the character length of the result is not known.
! NOTE: This relies on having the exact dependence of the length type
parameter available to the caller; gfortran saves it in the .mod files.
! NOTE ALSO: The concatenation operation generates a temporary pointer,
whose allocation must go to the innermost loop.
! NOTE ALSO (2): Elemental functions may generate a temporary, too. */
if (flag_realloc_lhs
&& expr2->ts.type == BT_CHARACTER && expr1->ts.deferred
&& !(lss != gfc_ss_terminator
&& rss != gfc_ss_terminator
! && ((expr2->expr_type == EXPR_FUNCTION
! && expr2->value.function.esym != NULL
&& expr2->value.function.esym->attr.elemental)
|| (expr2->expr_type == EXPR_FUNCTION
&& expr2->value.function.isym != NULL
--- 10275,10295
/* When assigning a character function result to a deferred-length variable,
the function call must happen before the (re)allocation of the lhs -
otherwise the character length of the result is not known.
! NOTE 1: This relies on having the exact dependence of the length type
parameter available to the caller; gfortran saves it in the .mod files.
! NOTE 2: Vector array references generate an index temporary that must
! not go outside the loop. Otherwise, variables should not generate
! a pre block.
! NOTE 3: The concatenation operation generates a temporary pointer,
whose allocation must go to the innermost loop.
! NOTE 4: Elemental functions may generate a temporary, too. */
if (flag_realloc_lhs
&& expr2->ts.type == BT_CHARACTER && expr1->ts.deferred
&& !(lss != gfc_ss_terminator
&& rss != gfc_ss_terminator
! && ((expr2->expr_type == EXPR_VARIABLE && expr2->rank)
! || (expr2->expr_type == EXPR_FUNCTION
! && expr2->value.function.esym != NULL
&& expr2->value.function.esym->attr.elemental)
|| (expr2->expr_type == EXPR_FUNCTION
&& expr2->value.function.isym != NULL
Index: gcc/testsuite/gfortran.dg/deferred_character_22.f90
===
*** gcc/testsuite/gfortran.dg/deferred_character_22.f90 (nonexistent)
--- gcc/testsuite/gfortran.dg/deferred_character_22.f90 (working copy)
***
*** 0
--- 1,27
+ ! { dg-do run }
+ !
+ ! Test the fix for PR77325, which casued an ICE in the gimplifier. The
+ ! segafults in 'contains_struct_check' were found while diagnosing the PR.
+ !
+ ! Contributed by Gerhard Steinmetz
+ !
+ program p
+character(3), parameter :: a(3) = ['abc', 'def', 'ghi']
+character(1), parameter :: c(3) = ['a', 'b', 'c']
+character(:), allocatable :: z(:)
+z = c([3,2]) ! Vector subscripts caused an iCE in the gimplifier.
+if (any (z .ne. ['c', 'b'])) stop 1
+z = c
+if (any (z .ne. ['a', 'b', 'c']
Re: [PATCH] middle-end/81035: Mention that noreturn suppresses tail call optimization
On Fri, Sep 21, 2018 at 12:59:27PM +0200, Florian Weimer wrote:
> 2018-09-21 Florian Weimer
>
> PR middle-end/81035
> * doc/extend.texi (Common Function Attributes): Mention that
> noreturn suppresses tail call optimization.
> +In order to preserve backtraces, GCC will never turn calls to
> +@code{noreturn} functions into tail calls.
Should we document this? Shouldn't we fix it, instead?
Segher
Re: [PATCH] Use vectored writes when reporting errors and warnings.
On Fri, Sep 21, 2018 at 7:37 PM Jerry DeLisle wrote: > Janne, this looks OK. Thanks, committed as r264487. Since you are touching on configuration and posix > dependencies have you tested under any other systems? > No, unfortunately I don't have easy access to such a system for testing. The patch, as can be seen, contains backwards compatibility stuff for targets that don't have writev() and struct iovec, but that code is untested. I'll keep an eye out for regression reports, of course! -- Janne Blomqvist
Re: [PATCH] middle-end/81035: Mention that noreturn suppresses tail call optimization
* Segher Boessenkool:
> On Fri, Sep 21, 2018 at 12:59:27PM +0200, Florian Weimer wrote:
>> 2018-09-21 Florian Weimer
>>
>> PR middle-end/81035
>> * doc/extend.texi (Common Function Attributes): Mention that
>> noreturn suppresses tail call optimization.
>
>> +In order to preserve backtraces, GCC will never turn calls to
>> +@code{noreturn} functions into tail calls.
>
> Should we document this? Shouldn't we fix it, instead?
Fix how? What is currently broken?
For things like assertion failures, we do not want to replace the
current stack frame with that of __assert_fail, I think.
Thanks,
Florian
Re: [PATCH] middle-end/81035: Mention that noreturn suppresses tail call optimization
> On Sep 21, 2018, at 2:17 PM, Florian Weimer wrote:
>
> * Segher Boessenkool:
>
>> On Fri, Sep 21, 2018 at 12:59:27PM +0200, Florian Weimer wrote:
>>> 2018-09-21 Florian Weimer
>>>
>>> PR middle-end/81035
>>> * doc/extend.texi (Common Function Attributes): Mention that
>>> noreturn suppresses tail call optimization.
>>
>>> +In order to preserve backtraces, GCC will never turn calls to
>>> +@code{noreturn} functions into tail calls.
>>
>> Should we document this? Shouldn't we fix it, instead?
>
> Fix how? What is currently broken?
>
> For things like assertion failures, we do not want to replace the
> current stack frame with that of __assert_fail, I think.
I agree. Also, tailcalls are optimizations. Speed optimizing noreturn calls
is obviously not interesting. Calls to noreturn functions are short, and
turning them into a jump probably makes no difference in size, or if it does,
not enough to matter.
paul
Re: [PATCH] middle-end/81035: Mention that noreturn suppresses tail call optimization
* Paul Koning:
>> On Sep 21, 2018, at 2:17 PM, Florian Weimer wrote:
>>
>> * Segher Boessenkool:
>>
>>> On Fri, Sep 21, 2018 at 12:59:27PM +0200, Florian Weimer wrote:
2018-09-21 Florian Weimer
PR middle-end/81035
* doc/extend.texi (Common Function Attributes): Mention that
noreturn suppresses tail call optimization.
>>>
+In order to preserve backtraces, GCC will never turn calls to
+@code{noreturn} functions into tail calls.
>>>
>>> Should we document this? Shouldn't we fix it, instead?
>>
>> Fix how? What is currently broken?
>>
>> For things like assertion failures, we do not want to replace the
>> current stack frame with that of __assert_fail, I think.
>
> I agree. Also, tailcalls are optimizations. Speed optimizing
> noreturn calls is obviously not interesting. Calls to noreturn
> functions are short, and turning them into a jump probably makes no
> difference in size, or if it does, not enough to matter.
The example in the bug report shows that tail calls can avoid setting up
a stack frame, leading to smaller code size and CFI.
Thanks,
Florian
Re: C++ PATCH for c++/87372, __func__ constexpr evaluation
Yes.
On Fri, Sep 21, 2018 at 1:40 PM, Marek Polacek wrote:
> On Fri, Sep 21, 2018 at 11:19:34AM -0400, Jason Merrill wrote:
>> On Fri, Sep 21, 2018 at 11:04 AM, Marek Polacek wrote:
>> > On Fri, Sep 21, 2018 at 09:37:53AM +0200, Jakub Jelinek wrote:
>> >> On Thu, Sep 20, 2018 at 11:56:37PM -0400, Marek Polacek wrote:
>> >> > The patch for P0595R1 - is_constant_evaluated had this hunk:
>> >> >
>> >> > @@ -5279,7 +5315,9 @@ maybe_constant_init_1 (tree t, tree decl, bool
>> >> > allow_non_constant)
>> >> >else if (CONSTANT_CLASS_P (t) && allow_non_constant)
>> >> > /* No evaluation needed. */;
>> >> >else
>> >> > -t = cxx_eval_outermost_constant_expr (t, allow_non_constant,
>> >> > false, decl);
>> >> > +t = cxx_eval_outermost_constant_expr (t, allow_non_constant,
>> >> > + !allow_non_constant,
>> >> > + pretend_const_required, decl);
>> >> >if (TREE_CODE (t) == TARGET_EXPR)
>> >> > {
>> >> >tree init = TARGET_EXPR_INITIAL (t);
>> >> >
>> >> > the false -> !allow_non_constant change means that when calling
>> >> > cxx_constant_init strict will be true because cxx_constant_init does
>> >> > not allow
>> >> > non constants. That means that for VAR_DECLs such as __func__ we'll
>> >> > call
>> >> > decl_really_constant_value instead of decl_constant_value. But only
>> >> > the latter
>> >> > can evaluate __func__ to "foo()".
>> >> >
>> >> > Jakub, was there a specific reason for this change? Changing it back
>> >> > still
>> >> > regtests cleanly and the attached test compiles again.
>> >>
>> >> It just didn't feel right that cxx_constant_init which looks like a
>> >> function
>> >> that requires strict conformance still passes false as strict.
>> >> If there is a reason to pass false, I think we need a comment that
>> >> explains
>> >> it.
>> >
>> > I think we use strict = true for *_constant_value, but *_constant_init
>> > should
>> > get strict = false.
>>
>> Right. In _init we try to get constant values for more than just C++
>> constant expressions.
>
> Is the patch OK then?
>
> Marek
Re: OpenCoarrays integration with gfortran
On Fri, Sep 21, 2018 at 7:25 PM Jerry DeLisle wrote: > My apologies for kidnapping this thread: > On 9/20/18 1: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.) > > I would like to put in my humble 2 cents worth here. > > OpenCoarrays was/is intended for a very broad audience, various large > systems such as Cray, etc. I think this influenced heavily the path of > its development, which is certainly OK. > > It was/is intended to interface libraries such as OpenMPI or MPICH to > gfortran as well as other Fortran compilers. > > The actual library source code is contained mostly in one source file. > After all the attempts to integrate into the GNU build systems without > much success my thinking has shifted. Keep in mind that the OpenCoarrays > implementation is quite dependent on gfortran and in fact has to do > special things in the build dependent on the version of gcc/gfortran a > user happens to use. I dont think this is a good situation. > > So I see two realistic strategies. The first is already talked about a > lot and is the cleanest approach for gfortran: > > 1) Focus on distribution packages such as Fedora, Debian, Ubuntu, > Windows, etc. Building of these packages needs to be automated into the > distributions. I think mostly this is what is happening and relies on > the various distribution maintainers to do so. Their support is greatly > appreciated and this really is the cleanest approach. > > The second option is not discussed as much because it leaves > OpenCoarrays behind in a sense and requires an editing cycle in two > places to fix bugs or add features. > > 2) Take the one source file, edit out all the macros that define > prefixes to function calls, hard code the gfortran prefixes etc and fork > it directly into the libgfortran library under GPL with attributions to > the original developers as appropriate. > > Strategy 2 would lock into specific current standard versions of the MPI > interface and would support less bleeding edge changes. It would also > require either OpenMPI or MPICH as a new gfortran dependency for > building, which not all users may need. So we would need some > configuration magic to enable or disable this portion of the build. > Something like --with-MPI-support would do the trick. > > Strategy 2 does add burden to gfortran maintainers who are already > overloaded. But, as the code matures the burden would decrease, > particularly once TEAMS are finished. > > Strategy 2 does have some advantages. For example, eliminating the need > for separate CAF and CAFRUN scripts which are a wrapper on gfortran. > The coarray features are part of the Fortran language and gfortran > should just "handle it" transparently using an environment variable to > define the number of images at run time. It would also actually > eliminate the need to manage all of the separate distribution packages. > So from a global point of view the overall maintanance effort would be > reduced. > > Strategy 2 would enable a set of users who are not focused so much on > distributions and loading packages, etc etc and those who are dependent > on getting through bureaucratic administrations who already are loading > gfortran on systems and would not have to also get another package > approved. People would just have to stop thinking about it and just use > it. > > So I think there are real advantages to Strategy 2 as well as Strategy 1 > and think it should be at least included in discussions. I would even > suggest there is likely a combination of 1 and 2 that may hit the mark. > For example, keeping OpenCoarrays as a separate package for bleeding > edge development and migrating the stable features into libgfortran on a > less frequent cycle. > > As I said, my 2 cents worth. > > Regards to all, > > Jerry > > I recall one motivation for the current sort-of loose coupling between the coarray library and gfortran was to support, at runtime, different MPI libraries. This can be useful on cluster and supercomputers, where it's important to use a MPI library that can use the high-performance cluster network. If libgfortran includes the coarray library which links against a MPI library, it means libgfortran has to be rebuilt against every MPI library in use on a system, and most likely, one cannot use the distro-provided gfortran. This might not be insurmountable on cluster using some kind of module system, but still. I gues
Re: OpenCoarrays integration with gfortran
On September 21, 2018 6:24:45 PM GMT+02:00, Jerry DeLisle wrote: >My apologies for kidnapping this thread: >On 9/20/18 1: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.) > >I would like to put in my humble 2 cents worth here. > >OpenCoarrays was/is intended for a very broad audience, various large >systems such as Cray, etc. I think this influenced heavily the path of >its development, which is certainly OK. > >It was/is intended to interface libraries such as OpenMPI or MPICH to >gfortran as well as other Fortran compilers. > >The actual library source code is contained mostly in one source file. >After all the attempts to integrate into the GNU build systems without >much success my thinking has shifted. Keep in mind that the >OpenCoarrays >implementation is quite dependent on gfortran and in fact has to do >special things in the build dependent on the version of gcc/gfortran a >user happens to use. I dont think this is a good situation. > >So I see two realistic strategies. The first is already talked about a > >lot and is the cleanest approach for gfortran: > >1) Focus on distribution packages such as Fedora, Debian, Ubuntu, >Windows, etc. Building of these packages needs to be automated into the > >distributions. I think mostly this is what is happening and relies on >the various distribution maintainers to do so. Their support is >greatly >appreciated and this really is the cleanest approach. > >The second option is not discussed as much because it leaves >OpenCoarrays behind in a sense and requires an editing cycle in two >places to fix bugs or add features. > >2) Take the one source file, edit out all the macros that define >prefixes to function calls, hard code the gfortran prefixes etc and >fork >it directly into the libgfortran library under GPL with attributions to > >the original developers as appropriate. > >Strategy 2 would lock into specific current standard versions of the >MPI >interface and would support less bleeding edge changes. It would also >require either OpenMPI or MPICH as a new gfortran dependency for >building, which not all users may need. So we would need some >configuration magic to enable or disable this portion of the build. >Something like --with-MPI-support would do the trick. > >Strategy 2 does add burden to gfortran maintainers who are already >overloaded. But, as the code matures the burden would decrease, >particularly once TEAMS are finished. > >Strategy 2 does have some advantages. For example, eliminating the need > >for separate CAF and CAFRUN scripts which are a wrapper on gfortran. >The coarray features are part of the Fortran language and gfortran >should just "handle it" transparently using an environment variable to >define the number of images at run time. It would also actually >eliminate the need to manage all of the separate distribution packages. > >So from a global point of view the overall maintanance effort would be >reduced. > >Strategy 2 would enable a set of users who are not focused so much on >distributions and loading packages, etc etc and those who are dependent > >on getting through bureaucratic administrations who already are loading > >gfortran on systems and would not have to also get another package >approved. People would just have to stop thinking about it and just >use it. > >So I think there are real advantages to Strategy 2 as well as Strategy >1 >and think it should be at least included in discussions. I would even >suggest there is likely a combination of 1 and 2 that may hit the mark. > >For example, keeping OpenCoarrays as a separate package for bleeding >edge development and migrating the stable features into libgfortran on >a >less frequent cycle. Sounds reasonable to me. License issues will be the most difficult here given integration with libgfortran likely requires a FSF copyright rather than just a compatible license. Richard. >As I said, my 2 cents worth. > >Regards to all, > >Jerry
Re: [PATCH] middle-end/81035: Mention that noreturn suppresses tail call optimization
On 9/21/18 4:59 AM, Florian Weimer wrote: > 2018-09-21 Florian Weimer > > PR middle-end/81035 > * doc/extend.texi (Common Function Attributes): Mention that > noreturn suppresses tail call optimization. OK. jeff
Re: [PATCH] Guard memory block allocation.
On 9/21/18 3:24 AM, Martin Liška wrote: > Hi. > > Following patch marks releases memory blocks as not accesible for valgrind. > That can help us in the future in order to catch memory corruptions. > > Ready for trunk? > Martin > > gcc/ChangeLog: > > 2018-09-21 Martin Liska > > * memory-block.h (memory_block_pool::release): Annotate with > valgrind that the memory is not accessible. OK jeff
Re: [PATCH] Improve location information of -Wcoverage-mismatch.
On 9/12/18 6:37 AM, Martin Liška wrote: > Hi. > > The patch improves locations of the warning in following way: > > sample.c: In function ‘main’: > sample.c:16:1: error: source locations for function ‘main’ have changed, the > profile data may be out of date [-Werror=coverage-mismatch] > 16 | } >| ^ > sample.c:16:1: error: source locations for function ‘main’ have changed, the > profile data may be out of date [-Werror=coverage-mismatch] > cc1: some warnings being treated as errors > > into: > > sample.c: In function ‘main’: > sample.c:10:5: error: source locations for function ‘main’ have changed, the > profile data may be out of date [-Werror=coverage-mismatch] > 10 | int main() >| ^~~~ > sample.c:10:5: error: source locations for function ‘main’ have changed, the > profile data may be out of date [-Werror=coverage-mismatch] > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > Thanks, > Martin > > gcc/ChangeLog: > > 2018-09-12 Martin Liska > > * coverage.c (get_coverage_counts): Use warning_at > with current_function_decl location. Use %qD in warning > message. OK. jeff
C++ PATCH: trivial cleanup
Use the proper type for "complain".
I guess it's obvious, but anyway, bootstrapped/regtested on x86_64-linux, ok
for trunk?
2018-09-21 Marek Polacek
* cp-tree.h (build_noexcept_spec, add_exception_specifier): Adjust
declarations.
* except.c (build_noexcept_spec): Change the type of the complain
parameter to tsubst_flags_t.
* typeck2.c (add_exception_specifier): Likewise.
diff --git gcc/cp/cp-tree.h gcc/cp/cp-tree.h
index 2203e92dda8..efbdad83966 100644
--- gcc/cp/cp-tree.h
+++ gcc/cp/cp-tree.h
@@ -6461,7 +6461,7 @@ extern void perform_deferred_noexcept_checks (void);
extern bool nothrow_spec_p (const_tree);
extern bool type_noexcept_p(const_tree);
extern bool type_throw_all_p (const_tree);
-extern tree build_noexcept_spec(tree, int);
+extern tree build_noexcept_spec(tree, tsubst_flags_t);
extern void choose_personality_routine (enum languages);
extern tree build_must_not_throw_expr (tree,tree);
extern tree eh_type_info (tree);
@@ -7415,7 +7415,7 @@ extern tree build_x_arrow (location_t,
tree,
tsubst_flags_t);
extern tree build_m_component_ref (tree, tree, tsubst_flags_t);
extern tree build_functional_cast (tree, tree, tsubst_flags_t);
-extern tree add_exception_specifier(tree, tree, int);
+extern tree add_exception_specifier(tree, tree, tsubst_flags_t);
extern tree merge_exception_specifiers (tree, tree);
/* in mangle.c */
diff --git gcc/cp/except.c gcc/cp/except.c
index 2db90eedcf7..3449b59b3cc 100644
--- gcc/cp/except.c
+++ gcc/cp/except.c
@@ -1187,7 +1187,7 @@ type_throw_all_p (const_tree type)
constant-expression of EXPR. COMPLAIN is as for tsubst. */
tree
-build_noexcept_spec (tree expr, int complain)
+build_noexcept_spec (tree expr, tsubst_flags_t complain)
{
/* This isn't part of the signature, so don't bother trying to evaluate
it until instantiation. */
diff --git gcc/cp/typeck2.c gcc/cp/typeck2.c
index b13ed2660de..fec1db00ca4 100644
--- gcc/cp/typeck2.c
+++ gcc/cp/typeck2.c
@@ -2215,7 +2215,7 @@ build_functional_cast (tree exp, tree parms,
tsubst_flags_t complain)
know what we're doing. */
tree
-add_exception_specifier (tree list, tree spec, int complain)
+add_exception_specifier (tree list, tree spec, tsubst_flags_t complain)
{
bool ok;
tree core = spec;
Re: [PATCH 09/14] Add D2 Testsuite Dejagnu files.
Ok.
Re: [PATCH 09/14] Add D2 Testsuite Dejagnu files.
On Sep 19, 2018, at 1:36 PM, Iain Buclaw wrote: > > On 18 September 2018 at 02:36, Iain Buclaw wrote: >> >> This patch adds D language support to the GCC testsuite. >> >> As well as generating the DejaGNU options for compile and link tests, >> handles the conversion from DMD-style compiler options to GDC. > > https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00112.html > > I take it from the comment in the last review, that I can self-approve > this, and the other testsuite related patches. If you're a maintainer for D... :-) Presently, you're not listed as maintainer. If appointed, then you will modify MAINTAINERS and move your entry up and put D front end on the line. In the time span between the two events I'd punt to the SC. If you have been appointed, yes, that remains until you step down or the SC changes their mind or some other big event. You can also ask for advice or ask for a review, even if you can approve.
Re: [PATCH 09/14] Add D2 Testsuite Dejagnu files.
On 21 September 2018 at 22:04, Mike Stump wrote: > On Sep 19, 2018, at 1:36 PM, Iain Buclaw wrote: >> >> On 18 September 2018 at 02:36, Iain Buclaw wrote: >>> >>> This patch adds D language support to the GCC testsuite. >>> >>> As well as generating the DejaGNU options for compile and link tests, >>> handles the conversion from DMD-style compiler options to GDC. >> >> https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00112.html >> >> I take it from the comment in the last review, that I can self-approve >> this, and the other testsuite related patches. > > If you're a maintainer for D... :-) Presently, you're not listed as > maintainer. If appointed, then you will modify MAINTAINERS and move your > entry up and put D front end on the line. In the time span between the two > events I'd punt to the SC. If you have been appointed, yes, that remains > until you step down or the SC changes their mind or some other big event. > You can also ask for advice or ask for a review, even if you can approve. I have been appointed maintainer when the D language was accepted for inclusion. I have been delaying adding myself to MAINTAINERS until all this work is signed off. Iain
Re: OpenCoarrays integration with gfortran
On Fri, Sep 21, 2018 at 9:25 AM Jerry DeLisle wrote: > The actual library source code is contained mostly in one source file. There are as many files as there are options for the underlying parallel programming model. The default is MPI, but I've co-authored conference papers last year and this year in which the OpenCoarrays OpenSHEM option outperformed MPI. One paper even described a platform on which OpenSHMEM was the only option beyond a few thousand cores because the required MPI features were immature on that platform. Early versions of OpenCoarrays also provided GASNet and ARMCI options. I recommend against tying gfortran to MPI only. > After all the attempts to integrate into the GNU build systems without > much success my thinking has shifted. Thanks for all your efforts! > Keep in mind that the OpenCoarrays > implementation is quite dependent on gfortran and in fact has to do > special things in the build dependent on the version of gcc/gfortran a > user happens to use. I dont think this is a good situation. I agree. Possibly OpenCoarrays could drop support for older gfortran versions at some point to avoid maintaining code that exists solely to support compiler versions that are several years old. > > 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. > 2) Take the one source file, edit out all the macros that define > prefixes to function calls, hard code the gfortran prefixes etc and fork > it directly into the libgfortran library under GPL with attributions to > the original developers as appropriate. See above. Also, this means that changes in the gfortran repository would not propagate back upstream unless each gfortran developer agrees to distribute his or her work under both GPL and BSD. Even that is only feasible if the copied files stay cohesive and don't reference code outside the copied file. I think it's more likely that copying the code into gfortran would be a branch point, after which the relevant files would diverge and work on the GPL side would be harder to fund than the BSD side. Most commercial entities are more likely to contribute to a BSD-licensed project than a GPL-licensed one. Over the past several months, one commercial compiler vendor authorized one of their developers to contribute to OpenCoarrays. and another commercial compiler vendor invited community input on whether to use OpenCoarrays during a public teleconference. The prospect of commercial support is the motivation for using BSD. > Strategy 2 does have some advantages. For example, eliminating the need > for separate CAF and CAFRUN scripts which are a wrapper on gfortran. Even in the case of just one underlying parallel programming model, this is tricky. To wit, Cray uses a compiler wrapper and a program launcher. Intel was able to eliminate the compiler wrapper, but still required a program launcher for distributed-memory execution until recently. I don't know the details, but I've heard it was not trivial for Intel to accomplish this and I imagine it would be even more complicated if they weren't hardwiring Intel MPI into their back-end. > People would just have to stop thinking about it and just use it. The same would be true if someone could coax the GCC build system to build OpenCoarrays just as it builds other prerequisites. The big difference is that OpenCoarrays is a prerequisite for using gfortran rather than for building gfortran so it needs to be built after gfortran rather than before like other prerequisites. The real problem is finding anyone who can work the proper magic in the GCC build system. Thanks for your input. I hope my response is helpful. Damian
Re: [PATCH 13/14] Add D Phobos standard library and license.
On Sep 19, 2018, at 1:49 PM, Iain Buclaw wrote: > > On 18 September 2018 at 02:38, Iain Buclaw wrote: >> This patch add the Phobos runtime library and license (Boost) files. >> Phobos is the standard runtime library that comes with the D language >> compiler. The bulk of which is comprised mostly of generic algorithms >> and high level primitives for D applications. >> >> ftp://ftp.gdcproject.org/patches/v4/13-v4-d-phobos-library.patch >> > > As far as I can tell, no one has made a comment on this yet. So, the important review point here will be the license. I'd expect Law to review it, and the SC to be involved as he requires it. You can't just self-approve license things, that's the domain of the SC. He'll wake up and look at this soon, don't worry.
Re: [PATCH 10/14] Add GDC Testsuite files.
On Sep 17, 2018, at 5:37 PM, Iain Buclaw wrote: > > This patch adds a further number of tests, but were added as part of > fixing gdc-specific bugs. Ok. Trivial, and self-review applicable.
Re: [PATCH 08/14] Add D2 Testsuite files.
On Sep 17, 2018, at 5:36 PM, Iain Buclaw wrote: > > This patch adds part of the D2 testsuite, which includes D source code > files that are considered compilable; files that are considered > uncompilable, but should not ICE; and files that should execute on > targets with crash or assertion failures. Ok. [ not needed, you can self-review things like this no problem ] I see you are sneaking in Alice in Wonderland...
Re: [PATCH 10/14] Add GDC Testsuite files.
On Sep 17, 2018, at 5:37 PM, Iain Buclaw wrote: > This patch adds a further number of tests, but were added as part of > fixing gdc-specific bugs. Ok. Trivial, and self-review applicable.
[PATCH] v2: C++: suggestions for misspelled private members (PR c++/84993)
This is v2 of the patch; I managed to bit-rot my own patch due to my
fix for r264335, which tightened up the "is this meaningful" threshold
on edit distances when finding spelling correction candidates.
The only change in this version is to rename various things in
the testcase so that they continue to be suggested
("colour" vs "m_color" are no longer near enough, so I renamed
"colour" to "m_colour").
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
OK for trunk?
Blurb from v1:
PR c++/84993 identifies a problem with our suggestions for
misspelled member names in the C++ FE for the case where the
member is private.
For example, given:
class foo
{
public:
double get_ratio() const { return m_ratio; }
private:
double m_ratio;
};
void test(foo *ptr)
{
if (ptr->ratio >= 0.5)
;// etc
}
...we currently emit this suggestion:
: In function 'void test(foo*)':
:12:12: error: 'class foo' has no member named 'ratio'; did you mean
'm_ratio'?
if (ptr->ratio >= 0.5)
^
m_ratio
...but if the user follows this suggestion, they get:
: In function 'void test(foo*)':
:12:12: error: 'double foo::m_ratio' is private within this context
if (ptr->m_ratio >= 0.5)
^~~
:7:10: note: declared private here
double m_ratio;
^~~
:12:12: note: field 'double foo::m_ratio' can be accessed via 'double
foo::get_ratio() const'
if (ptr->m_ratio >= 0.5)
^~~
get_ratio()
It feels wrong to be emitting a fix-it hint that doesn't compile, so this
patch adds the accessor fix-it hint logic to this case, so that we directly
offer a valid suggestion:
: In function 'void test(foo*)':
:12:12: error: 'class foo' has no member named 'ratio'; did you mean
'double foo::m_ratio'? (accessible via 'double foo::get_ratio() const')
if (ptr->ratio >= 0.5)
^
get_ratio()
gcc/cp/ChangeLog:
PR c++/84993
* call.c (enforce_access): Move diagnostics to...
(complain_about_access): ...this new function.
* cp-tree.h (class access_failure_info): Rename split out field
"m_field_decl" into "m_decl" and "m_diag_decl".
(access_failure_info::record_access_failure): Add tree param.
(access_failure_info::was_inaccessible_p): New accessor.
(access_failure_info::get_decl): New accessor.
(access_failure_info::get_diag_decl): New accessor.
(access_failure_info::get_any_accessor): New member function.
(access_failure_info::add_fixit_hint): New static member function.
(complain_about_access): New decl.
* typeck.c (access_failure_info::record_access_failure): Update
for change to fields.
(access_failure_info::maybe_suggest_accessor): Split out into...
(access_failure_info::get_any_accessor): ...this new function...
(access_failure_info::add_fixit_hint): ...and this new function.
(finish_class_member_access_expr): Split out "has no member named"
error-handling into...
(complain_about_unrecognized_member): ...this new function, and
check that the guessed name is accessible along the access path.
Only provide a spell-correction fix-it hint if it is; otherwise,
attempt to issue an accessor fix-it hint.
gcc/testsuite/ChangeLog:
PR c++/84993
* g++.dg/torture/accessor-fixits-9.C: New test.
---
gcc/cp/call.c| 64 ++
gcc/cp/cp-tree.h | 17 ++-
gcc/cp/typeck.c | 150 +--
gcc/testsuite/g++.dg/torture/accessor-fixits-9.C | 119 ++
4 files changed, 282 insertions(+), 68 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/torture/accessor-fixits-9.C
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 69503ca..445dde8 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6512,6 +6512,38 @@ build_op_delete_call (enum tree_code code, tree addr,
tree size,
return error_mark_node;
}
+/* Issue diagnostics about a disallowed access of DECL, using DIAG_DECL
+ in the diagnostics.
+
+ If ISSUE_ERROR is true, then issue an error about the
+ access, followed by a note showing the declaration.
+ Otherwise, just show the note. */
+
+void
+complain_about_access (tree decl, tree diag_decl, bool issue_error)
+{
+ if (TREE_PRIVATE (decl))
+{
+ if (issue_error)
+ error ("%q#D is private within this context", diag_decl);
+ inform (DECL_SOURCE_LOCATION (diag_decl),
+ "declared private here");
+}
+ else if (TREE_PROTECTED (decl))
+{
+ if (issue_error)
+ error ("%q#D is protected within this context", diag_decl);
+ inform (DECL_SOURCE_LOCATION (diag_decl),
+ "declared protected here");
+}
+ else
+{
+ if (issue_error)
+ error ("%q#D is inaccessible within this context", diag_decl);
+ inform (DECL_SOURCE_LOCATION (di
Re: [PATCH 08/14] Add D2 Testsuite files.
On 21 September 2018 at 22:54, Mike Stump wrote: > On Sep 17, 2018, at 5:36 PM, Iain Buclaw wrote: >> >> This patch adds part of the D2 testsuite, which includes D source code >> files that are considered compilable; files that are considered >> uncompilable, but should not ICE; and files that should execute on >> targets with crash or assertion failures. > > Ok. [ not needed, you can self-review things like this no problem ] > > I see you are sneaking in Alice in Wonderland... > I had forgotten about that test. I recall another project written in D (Dustmite) ran into some trouble with Debian due to the Project Gutenberg small print, which they ended up removing. The "small print" section in the text file says: DISTRIBUTION UNDER "PROJECT GUTENBERG-tm" You may distribute copies of this etext electronically, or by disk, book or any other medium if you either delete this "Small Print!" and all other references to Project Gutenberg, or: [...] I'll look into convincing upstream to also do the same. Iain
Re: [PATCH] middle-end/81035: Mention that noreturn suppresses tail call optimization
On Fri, Sep 21, 2018 at 08:36:45PM +0200, Florian Weimer wrote:
> * Paul Koning:
>
> >> On Sep 21, 2018, at 2:17 PM, Florian Weimer wrote:
> >>
> >> * Segher Boessenkool:
> >>
> >>> On Fri, Sep 21, 2018 at 12:59:27PM +0200, Florian Weimer wrote:
> 2018-09-21 Florian Weimer
>
> PR middle-end/81035
> * doc/extend.texi (Common Function Attributes): Mention that
> noreturn suppresses tail call optimization.
> >>>
> +In order to preserve backtraces, GCC will never turn calls to
> +@code{noreturn} functions into tail calls.
> >>>
> >>> Should we document this? Shouldn't we fix it, instead?
> >>
> >> Fix how? What is currently broken?
It prevents a useful optimisation for no good reason.
> >> For things like assertion failures, we do not want to replace the
> >> current stack frame with that of __assert_fail, I think.
This isn't much different with all other tail calls.
> > I agree. Also, tailcalls are optimizations. Speed optimizing
> > noreturn calls is obviously not interesting. Calls to noreturn
> > functions are short, and turning them into a jump probably makes no
> > difference in size, or if it does, not enough to matter.
>
> The example in the bug report shows that tail calls can avoid setting up
> a stack frame, leading to smaller code size and CFI.
Yes. For example on PowerPC, *all* calls require the caller to have a
stack frame. (This isn't different on other architectures' ABIs; it's
just that we don't create stack frames implicitly). Avoiding to create
a stack frame is a serious optimisation. With better shrink-wrapping
it is less of an issue than it was in the past, but still.
The whole point of tail calls is to destroy a stack frame. If that makes
debugging too hard, then -Og should not create sibcalls. Only doing it
for noreturn functions (and not only doing it in debug builds) doesn't
make much sense IMO.
Segher
Re: [PATCH, OpenACC] Fortran "declare create"/allocate support for OpenACC
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?
Thanks,
Julian
ChangeLog
2018-09-20 Cesar Philippidis
Julian Brown
gcc/
* omp-low.c (scan_sharing_clauses): Update handling of OpenACC declare
create, declare copyin and declare deviceptr to have local lifetimes.
(convert_to_firstprivate_int): Handle pointer types.
(convert_from_firstprivate_int): Likewise. Create local storage for
the values being pointed to. Add new orig_type argument.
(lower_omp_target): Handle GOMP_MAP_DECLARE_{ALLOCATE,DEALLOCATE}.
Add orig_type argument to convert_from_firstprivate_int call.
Allow pointer types with GOMP_MAP_FIRSTPRIVATE_INT. Don't privatize
firstprivate VLAs.
* tree-pretty-print.c (dump_omp_clause): Handle
GOMP_MAP_DECLARE_{ALLOCATE,DEALLOCATE}.
gcc/fortran/
* gfortran.h (enum gfc_omp_map_op): Add OMP_MAP_DECLARE_ALLOCATE,
OMP_MAP_DECLARE_DEALLOCATE.
(gfc_omp_clauses): Add update_allocatable.
* trans-array.c (gfc_array_allocate): Call
gfc_trans_oacc_declare_allocate for decls that have oacc_declare_create
attribute set.
* trans-decl.c (add_attributes_to_decl): Enable lowering of OpenACC
declare create, declare copyin and declare deviceptr clauses.
(add_clause): Don't duplicate OpenACC declare clauses. Populate
sym->backend_decl so that it can be used to determine if two symbols are
unique.
(find_module_oacc_declare_clauses): Relax oacc_declare_create to
OMP_MAP_ALLOC, and oacc_declare_copyin to OMP_MAP_TO, in order to
match OpenACC 2.5 semantics.
* trans-openmp.c (gfc_trans_omp_clauses): Use GOMP_MAP_ALWAYS_POINTER
(for update directive) or GOMP_MAP_FIRSTPRIVATE_POINTER (otherwise) for
allocatable scalar decls. Handle OMP_MAP_DECLARE_{ALLOCATE,DEALLOCATE}
clauses.
(gfc_trans_oacc_executable_directive): Use GOMP_MAP_ALWAYS_POINTER
for allocatable scalar data clauses inside acc update directives.
(gfc_trans_oacc_declare_allocate): New function.
* trans-stmt.c (gfc_trans_allocate): Call
gfc_trans_oacc_declare_allocate for decls with oacc_declare_create
attribute set.
(gfc_trans_deallocate): Likewise.
* trans.h (gfc_trans_oacc_declare_allocate): Declare.
gcc/testsuite/
* gfortran.dg/goacc/declare-allocatable-1.f90: New test.
include/
* gomp-constants.h (enum gomp_map_kind): Define
GOMP_MAP_DECLARE_{ALLOCATE,DEALLOCATE} and GOMP_MAP_FLAG_SPECIAL_4.
libgomp/
* oacc-mem.c (gomp_acc_declare_allocate): New function.
* oacc-parallel.c (GOACC_enter_exit_data): Handle
GOMP_MAP_DECLARE_{ALLOCATE,DEALLOCATE}.
* testsuite/libgomp.oacc-fortran/allocatable-array.f90: New test.
* testsuite/libgomp.oacc-fortran/allocatable-scalar.f90: New test.
* testsuite/libgomp.oacc-fortran/declare-allocatable-1.f90: New test.
* testsuite/libgomp.oacc-fortran/declare-allocatable-2.f90: New test.
* testsuite/libgomp.oacc-fortran/declare-allocatable-3.f90: New test.
* testsuite/libgomp.oacc-fortran/declare-allocatable-4.f90: New test.
commit 2601a2c2c6222026baf0e73cd2d9694c64356e77
Author: Julian Brown
Date: Wed Sep 12 20:15:08 2018 -0700
Fortran "declare create"/allocate support for OpenACC
gcc/
* omp-low.c (scan_sharing_clauses): Update handling of OpenACC declare
create, declare copyin and declare deviceptr to have local lifetimes.
(convert_to_firstprivate_int): Handle pointer types.
(convert_from_firstprivate_int): Likewise. Create local storage for
the values being pointed to. Add new orig_type argument.
(lower_omp_target): Handle GOMP_MAP_DECLARE_{ALLOCATE,DEALLOCATE}.
Add orig_type argument to convert_from_firstprivate_int call.
Allow pointer types with GOMP_MAP_FIRSTPRIVATE_INT. Don't privatize
firstprivate VLAs.
* tree-pretty-print.c (dump_omp_clause): Handle
GOMP_MAP_DECLARE_{ALLOCATE,DEALLOCATE}.
gcc/fortran/
* gfortran.h (enum gfc_omp_map_op): Add OMP_MAP_DECLARE_ALLOCATE,
OMP_MAP_DECLARE_DEALLOCATE.
(gfc_omp_clauses): Add update_al
Re: [PATCH] PR86957
Attached is the refreshed patch for trunk.
After commit 264462 (Remove arc profile histogram in non-LTO mode.), the API
of get_coverage_counts was changed a bit. So the main difference between the
current version of my patch from the previous one is that :
Now I use
+ if (counter == GCOV_COUNTER_ARCS)
+ warning_at (DECL_SOURCE_LOCATION (current_function_decl),
+ OPT_Wmissing_profile,
+ "profile for function %qD not found in profile data",
+ current_function_decl);
instead of
+ if (summary)
+ warning_at (DECL_SOURCE_LOCATION (current_function_decl),
+ OPT_Wmissing_profile,
+ "profile for function %qD not found in profile data",
+ current_function_decl);
to warn about missing profile of a function only once (get_coverage_counts is
called from two diff flows : getting exec counts for arc counter and computing
histogram for other other counters)
I am not sure of any better way to avoid superfluous warnings per function.
Is the patch OK ?
diff --git a/gcc/common.opt b/gcc/common.opt
index ef6a630..53aac19 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -811,6 +811,10 @@ Wcoverage-mismatch
Common Var(warn_coverage_mismatch) Init(1) Warning
Warn in case profiles in -fprofile-use do not match.
+Wmissing-profile
+Common Var(warn_missing_profile) Init(1) Warning
+Warn in case profiles in -fprofile-use do not exist.
+
Wvector-operation-performance
Common Var(warn_vector_operation_performance) Warning
Warn when a vector operation is compiled outside the SIMD.
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 26cce2b..4b6df8a 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -304,16 +304,23 @@ get_coverage_counts (unsigned counter, unsigned cfg_checksum,
{
static int warned = 0;
- if (!warned++ && dump_enabled_p ())
+ if (!warned++)
{
- dump_user_location_t loc
- = dump_user_location_t::from_location_t (input_location);
- dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, loc,
+ warning (OPT_Wmissing_profile,
+ "%qs profile count data file not found",
+ da_file_name);
+ if (dump_enabled_p ())
+ {
+ dump_user_location_t loc
+ = dump_user_location_t::from_location_t (input_location);
+ dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, loc,
+ "file %s not found\n",
+ da_file_name);
+ dump_printf (MSG_OPTIMIZED_LOCATIONS,
(flag_guess_branch_prob
- ? "file %s not found, execution counts estimated\n"
- : "file %s not found, execution counts assumed to "
- "be zero\n"),
- da_file_name);
+ ? "execution counts estimated\n"
+ : "execution counts assumed to be zero\n"));
+ }
}
return NULL;
}
@@ -327,10 +334,17 @@ get_coverage_counts (unsigned counter, unsigned cfg_checksum,
elt.ctr = counter;
entry = counts_hash->find (&elt);
if (!entry)
-/* The function was not emitted, or is weak and not chosen in the
- final executable. Silently fail, because there's nothing we
- can do about it. */
-return NULL;
+{
+ if (counter == GCOV_COUNTER_ARCS)
+ warning_at (DECL_SOURCE_LOCATION (current_function_decl),
+ OPT_Wmissing_profile,
+ "profile for function %qD not found in profile data",
+ current_function_decl);
+ /* The function was not emitted, or is weak and not chosen in the
+ final executable. Silently fail, because there's nothing we
+ can do about it. */
+ return NULL;
+}
if (entry->cfg_checksum != cfg_checksum)
{
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index abbd9ec..ed56af3 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -315,7 +315,7 @@ Objective-C and Objective-C++ Dialects}.
-Wlogical-op -Wlogical-not-parentheses -Wlong-long @gol
-Wmain -Wmaybe-uninitialized -Wmemset-elt-size -Wmemset-transposed-args @gol
-Wmisleading-indentation -Wmissing-attributes -Wmissing-braces @gol
--Wmissing-field-initializers -Wmissing-include-dirs @gol
+-Wmissing-field-initializers -Wmissing-include-dirs -Wmissing-profile @gol
-Wno-multichar -Wmultistatement-macros -Wnonnull -Wnonnull-compare @gol
-Wnormalized=@r{[}none@r{|}id@r{|}nfc@r{|}nfkc@r{]} @gol
-Wnull-dereference -Wodr -Wno-overflow -Wopenmp-simd @gol
@@ -4218,8 +4218,8 @@ Warn about an invalid memory access that is found by Pointer Bounds Checker
@opindex Wcoverage-mismatch
Warn if feedback profiles do not match when using the
@option{-fprofile-use} option.
-If a source file is changed between compiling with @option{-fprofile-gen} and
-with @option{-fprofile-use}, the files with the profile feedback can fail
+If a source file is changed between compiling with @option{-fprofile-generate}
+and with @option{-fprofile-use}, the files with the profile feedback can fail
to match the source file and GCC cannot use the profile feedback
information. By default, this warning is enabled a
Re: OpenCoarrays integration with gfortran
On 9/21/18 1:16 PM, Damian Rouson wrote:> On Fri, Sep 21, 2018 at 9:25 AM Jerry DeLisle wrote: > >> The actual library source code is contained mostly in one source file. > > There are as many files as there are options for the underlying > parallel programming > model. The default is MPI, but I've co-authored conference papers last year > and this year in which the OpenCoarrays OpenSHEM option outperformed MPI. > One paper even described a platform on which OpenSHMEM was the only option > beyond a few thousand cores because the required MPI features were immature on > that platform. Early versions of OpenCoarrays also provided GASNet > and ARMCI options. > I recommend against tying gfortran to MPI only. I agree with you on this point. Perhaps the Opencoarrays implementation should somehow do some runtime introspection to allow the library to sync to whatever is desired on a given system. The gfortran interface was designed to be generic. Implementation should be more dynamic in run time linking and abstracted in such a way that OpenCoarrays could be compiled stand alone and use something like "plugins" to allow post build the determination of what which interface to use. I am by no means a software expert in these techniques, but they are becoming common practice in other areas, for example linux/Gnu kernel modules > >> After all the attempts to integrate into the GNU build systems without >> much success my thinking has shifted. > > Thanks for all your efforts! > >> Keep in mind that the OpenCoarrays >> implementation is quite dependent on gfortran and in fact has to do >> special things in the build dependent on the version of gcc/gfortran a >> user happens to use. I dont think this is a good situation. > > I agree. Possibly OpenCoarrays could drop support for older gfortran versions > at some point to avoid maintaining code that exists solely to support compiler > versions that are several years old. See my comments above about pluggable modules. Maybe libgfortran should have this pluggable interface and Opencoarrays provide the plugins. Think how useful it would be to be able to choose the backend at time of execution based on a simple envoronment variable set by the user. > >> >> 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. > >> 2) Take the one source file, edit out all the macros that define >> prefixes to function calls, hard code the gfortran prefixes etc and fork >> it directly into the libgfortran library under GPL with attributions to >> the original developers as appropriate. > > See above. Also, this means that changes in the gfortran repository would not > propagate back upstream unless each gfortran developer agrees to > distribute his or her > work under both GPL and BSD. Even that is only feasible if the copied > files stay cohesive The flip of this would be to have the OpenCorrays developers to agree to the GPL and release under both. The libgfortran license says: "Under Section 7 of GPL version 3, you are granted additional permissions described in the GCC Runtime Library Exception, version 3.1, as published by the Free Software Foundation." Probably worth a fresh look. > and don't reference code outside the copied file. I think it's more > likely that copying the code > into gfortran would be a branch point, after which the relevant files > would diverge and > work on the GPL side would be harder to fund than the BSD side. > > Most commercial entities are more likely to contribute to a > BSD-licensed project than a > GPL-licensed one. Over the past several months, one commercial compiler vendor > authorized one of their developers to contribute to OpenCoarrays. and > another commercial > compiler vendor invited community input on whether to use OpenCoarrays > during a public > teleconference. The prospect of commercial support is the motivation > for using BSD. I really have no commercial interest. So I will not comment on GPL vs BSD other than referring to the multitude of FSF recommendations about why one should choose one of the FSF flavors rather than BSD. > >> Strategy 2 does have some advantages. For example, eliminating the need >> for separate CAF and CAFRUN scripts which are a wrapper on gfortran. > > Even in the case of just one underlying parallel programming model, > this is tricky. To wit, Cray uses > a compiler wrapper and a program launcher. Intel was able to > eliminate the compiler wrapper, > but still required a program launcher for distributed-memory execution > until recently. I don't > know the details, but I've heard it was not trivial for Intel to > accomplish this and I imagine it would be > even more complicated if they weren't hardwiring Intel MPI into their back-end. Well here i
Re: [PATCH v4] [aarch64] Add HiSilicon tsv110 CPU support
Hi Kyrill, On 2018/9/21 20:25, Kyrill Tkachov wrote: > Hi Shaokun, > > On 20/09/18 15:54, Zhangshaokun wrote: >> Hi James, >> >> On 2018/9/20 22:22, James Greenhalgh wrote: >>> On Wed, Sep 19, 2018 at 04:53:52AM -0500, Shaokun Zhang wrote: This patch adds HiSilicon's an mcpu: tsv110, which supports v8_4A. It has been tested on aarch64 and no regressions from this patch. >>> This patch is OK for Trunk. >>> >>> Do you need someone to commit it on your behalf? >>> >> Sure, it is great. > > I've committed this on your behalf with revision 264470. > Thank you for your patience and persistence. > It is pretty nice. I shall appreciate you and other maintainers professional comments and guidance, it is really kind and helpful. Thanks, Shaokun > Kyrill > >> Thanks in advance, >> Shaokun >> >>> Thanks, >>> James >>> --- gcc/ChangeLog| 9 +++ gcc/config/aarch64/aarch64-cores.def | 3 + gcc/config/aarch64/aarch64-cost-tables.h | 104 +++ gcc/config/aarch64/aarch64-tune.md | 2 +- gcc/config/aarch64/aarch64.c | 82 gcc/doc/invoke.texi | 2 +- 6 files changed, 200 insertions(+), 2 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 69e2e14..a040daa 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,12 @@ +2018-09-19 Shaokun Zhang +Bo Zhou + +* config/aarch64/aarch64-cores.def (tsv110): New CPU. +* config/aarch64/aarch64-tune.md: Regenerated. +* doc/invoke.texi (AArch64 Options/-mtune): Add "tsv110". +* config/aarch64/aarch64.c (tsv110_tunings): New tuning table. +* config/aarch64/aarch64-cost-tables.h: Add "tsv110" extra costs. + 2018-09-18 Marek Polacek P1064R0 - Allowing Virtual Function Calls in Constant Expressions >>> >>> . >>> > > > . >
