[wwwdocs] codingconventions.html/codingrationale.html -- prepare for HTML 5 migration
These were two of the few remaining pages where we still had instead of using ids. Changed thusly. Gerald Index: codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v retrieving revision 1.81 diff -u -r1.81 codingconventions.html --- codingconventions.html 2 Jun 2018 21:16:09 - 1.81 +++ codingconventions.html 1 Sep 2018 10:13:50 - @@ -82,7 +82,7 @@ -Documentation +Documentation Documentation, both of user interfaces and of internals, must be maintained and kept up to date. In particular: @@ -109,7 +109,7 @@ -ChangeLogs +ChangeLogs GCC requires ChangeLog entries for documentation changes; for the web pages (apart from java/ and libstdc++/) the CVS @@ -137,7 +137,7 @@ java/58 is the actual number of the PR) at the top of the ChangeLog entry. -Portability +Portability There are strict requirements for portability of code in GCC to older systems whose compilers do not implement all of the @@ -201,13 +201,13 @@ necessary, to break mutually recursive cycles. -Makefiles +Makefiles touch should never be used in GCC Makefiles. Instead of touch foo always use $(STAMP) foo. -Testsuite Conventions +Testsuite Conventions Every language or library feature, whether standard or a GNU extension, and every warning GCC can give, should have testcases @@ -237,7 +237,7 @@ to the testsuite. -Diagnostics Conventions +Diagnostics Conventions Use of the input_location global, and of the @@ -288,7 +288,7 @@ -Spelling, terminology and markup +Spelling, terminology and markup The following conventions of spelling and terminology apply throughout GCC, including the manuals, web pages, diagnostics, @@ -678,24 +678,24 @@ -C and C++ Language Conventions +C and C++ Language Conventions The following conventions apply to both C and C++. -Compiler Options +Compiler Options The compiler must build cleanly with -Wall -Wextra. -Language Use +Language Use -Assertions +Assertions Code should use gcc_assert (EXPR) to check invariants. Use gcc_unreachable () to mark places that should never be @@ -711,7 +711,7 @@ by using gcc_checking_assert. -Character Testing +Character Testing Code testing properties of characters from user source code should use macros such as ISALPHA from safe-ctype.h @@ -720,7 +720,7 @@ language accepted. -Error Node Testing +Error Node Testing Testing for ERROR_MARKs should be done by comparing against error_mark_node rather than by comparing the @@ -728,13 +728,13 @@ href="https://gcc.gnu.org/ml/gcc-patches/2000-10/msg00792.html";>message. -Parameters Affecting Generated Code +Parameters Affecting Generated Code Internal numeric parameters that may affect generated code should be controlled by --param rather than being hardcoded. -Inlining Functions +Inlining Functions Inlining functions only when @@ -744,15 +744,15 @@ -Formatting Conventions +Formatting Conventions -Line Length +Line Length Lines shall be at most 80 columns. -Names +Names Macros names should be in ALL_CAPS @@ -771,7 +771,7 @@ -Expressions +Expressions Code in GCC should use the following formatting conventions: @@ -802,7 +802,7 @@ -C++ Language Conventions +C++ Language Conventions The following conventions apply only to C++. @@ -814,7 +814,7 @@ -Language Use +Language Use C++ is a complex language, @@ -834,7 +834,7 @@ component maintainers make the final decisions about those components.) -Variable Definitions +Variable Definitions Variables should be defined at the point of first use, @@ -853,7 +853,7 @@ -Struct Definitions +Struct Definitions Use the struct keyword for @@ -865,7 +865,7 @@ Rationale and Discussion -Class Definitions +Class Definitions Use the class keyword for @@ -920,7 +920,7 @@ -Constructors and Destructors +Constructors and Destructors All constructors should initialize data members @@ -936,7 +936,7 @@ Rationale and Discussion -Conversions +Conversions Single argument constructors should nearly always be declared explicit. @@ -951,7 +951,7 @@ -Overloading Functions +Overloading Functions Overloading functions is permitted, @@ -965,7 +965,7 @@ -Overloading Operators +Overloading Operators Overloading operators is permitted, @@ -982,7 +982,7 @@ -Default Arguments +Default Arguments Default arguments are another type of function overloading, @@ -996,7 +996,7 @@ -Inlining Functions +Inlining Functions Constructors and destructors, even those with empty bodies, @@ -1006,7 +1006,7 @@ -Templates +Templates To avoid excessive compiler size, @@ -1015,7 +1015,7 @@ -Namespaces +Namespaces Namespaces are encouraged. @@ -1033,7 +1033,7 @@ Rationale and Discussion -RTTI and dynamic_cast +RTTI and dynamic_cast
Re: [Patch][GCC] Document and fix -r (partial linking)
On Montag, 27. August 2018 15:37:15 CEST Joseph Myers wrote: > On Sun, 26 Aug 2018, Allan Sandfeld Jensen wrote: > > Patch updated. I specifically edited a number of the existing tests that > > used both -r and -nostdlib and removed -nostdlib so the patch is > > exercised by existing tests. The patch bootstrapped, I didn't notice any > > relevant failures when running the test suite (though I could have missed > > something, I am never comfortable reading that output). > > Note that Iain's comments also included that the patch is incomplete > because of more specs in gcc.c (VTABLE_VERIFICATION_SPEC, > SANITIZER_EARLY_SPEC, SANITIZER_SPEC) that needs corresponding updates to > handle -r like -nostdlib. Okay, I can add that, or whoever commits the patch can add that. We can also improve the feature if we discover more places that needs updating. Do you want me to post an version updated with with these two places? 'Allan
Re: [Patch][GCC] Document and fix -r (partial linking)
On Montag, 27. August 2018 15:37:15 CEST Joseph Myers wrote:
> On Sun, 26 Aug 2018, Allan Sandfeld Jensen wrote:
> > Patch updated. I specifically edited a number of the existing tests that
> > used both -r and -nostdlib and removed -nostdlib so the patch is
> > exercised by existing tests. The patch bootstrapped, I didn't notice any
> > relevant failures when running the test suite (though I could have missed
> > something, I am never comfortable reading that output).
>
> Note that Iain's comments also included that the patch is incomplete
> because of more specs in gcc.c (VTABLE_VERIFICATION_SPEC,
> SANITIZER_EARLY_SPEC, SANITIZER_SPEC) that needs corresponding updates to
> handle -r like -nostdlib.
Updated (but tests not rerun)>From 1d164bced7979c94767c260174e3c486d4fc8c5d Mon Sep 17 00:00:00 2001
From: Allan Sandfeld Jensen
Date: Sat, 1 Sep 2018 12:59:14 +0200
Subject: [PATCH] Fix and document -r option
The option has existed and been working for years,
make sure it implies the right extra options, and list
it in the documentation.
2018-09-01 Allan Sandfeld Jensen
gcc/doc/
* invoke.texi: Document -r.
gcc/
* gcc.c (LINK_COMMAND_SPEC): Handle -r like -nostdlib.
(VTABLE_VERIFICATION_SPEC): Ditto
(SANITIZER_EARLY_SPEC): Ditto
(SANITIZER_SPEC): Ditto
* config/darwin.h (LINK_COMMAND_SPEC): Ditto
* cp/g++spec.c (lang_specific_driver): Ditto
* fortran/gfortranspec.c (lang_specific_driver): Ditto
* go/gospec.c (lang_specific_driver): Ditto
gcc/testsuite/
* g++.dg/ipa/pr64059.C: Removed now redundant -nostdlib.
* g++.dg/lto/20081109-1_0.C: Ditto
* g++.dg/lto/20090302_0.C: Ditto
* g++.dg/lto/pr45621_0.C: Ditto
* g++.dg/lto/pr60567_0.C: Ditto
* g++.dg/lto/pr62026.C: Ditto
* gcc.dg/lto/pr45736_0.c: Ditto
* gcc.dg/lto/pr52634_0.c: Ditto
* gfortran.dg/lto/20091016-1_0.f90: Ditto
* gfortran.dg/lto/pr79108_0.f90: Ditto
---
gcc/config/darwin.h| 8
gcc/cp/g++spec.c | 1 +
gcc/doc/invoke.texi| 7 ++-
gcc/fortran/gfortranspec.c | 1 +
gcc/gcc.c | 18 +-
gcc/go/gospec.c| 1 +
gcc/testsuite/g++.dg/ipa/pr64059.C | 2 +-
gcc/testsuite/g++.dg/lto/20081109-1_0.C| 2 +-
gcc/testsuite/g++.dg/lto/20090302_0.C | 2 +-
gcc/testsuite/g++.dg/lto/pr45621_0.C | 2 +-
gcc/testsuite/g++.dg/lto/pr60567_0.C | 2 +-
gcc/testsuite/g++.dg/lto/pr62026.C | 2 +-
gcc/testsuite/gcc.dg/lto/pr45736_0.c | 2 +-
gcc/testsuite/gcc.dg/lto/pr52634_0.c | 2 +-
gcc/testsuite/gfortran.dg/lto/20091016-1_0.f90 | 2 +-
gcc/testsuite/gfortran.dg/lto/pr79108_0.f90| 2 +-
16 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index cd6d6521658..87f610259c0 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -180,20 +180,20 @@ extern GTY(()) int darwin_ms_struct;
"%X %{s} %{t} %{Z} %{u*} \
%{e*} %{r} \
%{o*}%{!o:-o a.out} \
-%{!nostdlib:%{!nostartfiles:%S}} \
+%{!nostdlib:%{!r:%{!nostartfiles:%S}}} \
%{L*} %(link_libgcc) %o %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} \
%{fopenacc|fopenmp|%:gt(%{ftree-parallelize-loops=*:%*} 1): \
%{static|static-libgcc|static-libstdc++|static-libgfortran: libgomp.a%s; : -lgomp } } \
%{fgnu-tm: \
%{static|static-libgcc|static-libstdc++|static-libgfortran: libitm.a%s; : -litm } } \
-%{!nostdlib:%{!nodefaultlibs:\
+%{!nostdlib:%{!r:%{!nodefaultlibs:\
%{%:sanitize(address): -lasan } \
%{%:sanitize(undefined): -lubsan } \
%(link_ssp) \
" DARWIN_EXPORT_DYNAMIC " %
Re: DWARF: Represent hard frame pointer as stack pointer + offset
Hi! On Fri, Aug 31, 2018 at 02:54:17PM -0700, H.J. Lu wrote: > On Fri, Aug 31, 2018 at 1:32 PM, Jason Merrill wrote: > > On Fri, Aug 31, 2018 at 3:33 PM, H.J. Lu wrote: > >> On Thu, Aug 30, 2018 at 10:21 AM, Jason Merrill wrote: > >>> > r138335 allowed arg_pointer_rtx to be eliminated by either FP or SP, > but only when dynamic stack alignment is supported. In this case, > arg_pointer_rtx is eliminated by FP even when frame_pointer_needed > is false and there is no dynamic stack alignment at all. > > > gcc_assert (elim == stack_pointer_rtx || (frame_pointer_needed && elim > > == hard_frame_pointer_rtx)); > > > > so as not to allow eliminating to an uninitialized FP. > > FP isn't uninitialized. It is initialized the same way as in the case of > SUPPORTS_STACK_ALIGNMENT is true. > >>> > >>> How is that? Why would it be initialized when frame_pointer_needed is > >>> false? What does it mean for frame_pointer_needed to be false, if > >>> not, as in the documentation of -fomit-frame-pointer, > >>> > >>> "This avoids the instructions to save, set up and restore the frame > >>> pointer; on many targets it also makes an extra register available." > >>> > >>> ? > >> > >> A backend may not set up frame pointer even with -fno-omit-frame-pointer. > >> In the case of x86, hard frame pointer can be represented by stack pointer > >> - UNITS_PER_WORD. > >> > >> This patch adds hard_frame_pointer_from_stack_pointer_plus_offset and > >> hard_frame_pointer_offset to rtl_data to allow a backend to represent > >> hard frame pointer as stack pointer + offset. > > > > Shouldn't this be fixed in eliminate_regs rather than dwarf2out? > > > > With -fno-omit-frame-pointer, arg pointer is eliminated with hard frame > pointer. But > > commit cd557ff63f388ad27c376d0a225e74d3594a6f9d > Author: hjl > Date: Thu Aug 10 15:29:05 2017 + > > i386: Don't use frame pointer without stack access > > When there is no stack access, there is no need to use frame pointer > even if -fno-omit-frame-pointer is used and caller's frame pointer is > unchanged. > > changed it in the last minute. It is too late to go back. When it is done, > hard frame pointer must be replaced by stack pointer - UNITS_PER_WORD > if it is ever used. So after that patch something uses the hard frame pointer, while it also claims nothing uses the hard frame pointer? Sounds to me you should fix the uses, and all will be fine. Segher
[wwwdocs] gcc-4.3/changes.html -- reduce links to mpfr.org
This page already has a link to mpfr.org (which I updated recently), and this being more of a historical page and to make future link maintenance easier, this reduces the number of links. Applied. Gerald Index: gcc-4.3/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.3/changes.html,v retrieving revision 1.135 diff -u -r1.135 changes.html --- gcc-4.3/changes.html26 Aug 2018 13:04:29 - 1.135 +++ gcc-4.3/changes.html1 Sep 2018 11:44:51 - @@ -172,11 +172,10 @@ The GCC middle-end has been integrated with the -http://www.mpfr.org/";>MPFR library. This allows GCC +MPFR library. This allows GCC to evaluate and replace at compile-time calls to built-in math functions having constant arguments with their mathematically -equivalent results. In making use of http://www.mpfr.org/";>MPFR, GCC can generate correct +equivalent results. In making use of MPFR, GCC can generate correct results regardless of the math library implementation or floating point precision of the host platform. This also allows GCC to generate identical results regardless of whether one compiles in @@ -201,7 +200,7 @@ functions (e.g. sinf and sinl) are also handled. The sqrt and cabs functions with constant arguments were already optimized in prior GCC -releases. Now they also use http://www.mpfr.org/";>MPFR. +releases. Now they also use MPFR. A new forward propagation pass on RTL was added. The new pass replaces several slower transformations, resulting in compile-time
[wwwdocs] readings.html -- link maintenance
Update a few sites from http to https and update some links in other ways. On the way remove duplicate . Committed. Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.297 diff -u -r1.297 readings.html --- readings.html 17 Aug 2018 19:22:22 - 1.297 +++ readings.html 1 Sep 2018 11:54:15 - @@ -6,7 +6,6 @@ --> - Links and Selected Readings https://gcc.gnu.org/gcc.css"; /> @@ -26,7 +25,7 @@ https://en.wikibooks.org/wiki/GNU_C_Compiler_Internals";>GNU C Compiler Internals (Wikibook), numerous contributors. - http://www.immerundewig.at/thesis/";>Compilation + http://www.pspace.org/a/thesis/";>Compilation of Functional Programming Languages using GCC -- Tail Calls by Andreas Bauer. @@ -93,7 +92,7 @@ Blackfin Manufacturer: Analog Devices - http://www.analog.com/en/products/processors-dsp/blackfin.html";>Blackfin Documentation + http://www.analog.com/en/products/processors-dsp/dsp/blackfin.html";>Blackfin Documentation c4x @@ -152,7 +151,7 @@ Some information about optimizing for x86 processors, links to x86 manuals and documentation: - http://www.agner.org/optimize/";>http://www.agner.org/optimize/ + https://www.agner.org/optimize/";>https://www.agner.org/optimize/ http://www.sandpile.org";>www.sandpile.org: Christian Ludloff's technical x86 processor information. @@ -405,7 +404,7 @@ -http://www.j3-fortran.org/";>Fortran standards committee +https://j3-fortran.org";>Fortran standards committee (includes references to the current draft of the Fortran standard) @@ -617,7 +616,7 @@ ftp://ftp.sgi.com/sgi/dev/davea/objectinfo.html";>Debugging/object info by David B.Anderson (including links to some DWARF tools) - http://www.compilerconnection.com/";>Links related to many + http://compilerconnection.com";>Links related to many compiler topics https://compilers.iecc.com";>comp.compilers archive
Re: [Patch, fortran] PR86328 - [8/9 Regression] Runtime segfault reading an allocatable class(*) object in allocate statements
Hi Janus, Thanks for the review. I decided to commit just the parts that address the regression to both branches. Assignment to polymorphic variables is in such a mess that I did not consider it sensible to apply part of a fragment of Band Aid. I will raise a PR for the bugs that I know of. Committed to 8-branch as r264027 and trunk as r264008 Cheers Paul On 29 August 2018 at 20:18, Janus Weil wrote: > Hi Paul, > >> The attached patch fixes PR86328 and PR86760. The regression was >> caused by my commit r252949. >> >> The parts of the patch that fix the PRs are in trans.c and >> trans-array.c. The problem was caused by fixing the expressions that >> would provide the 'span' in gfc_build_array_ref, since the latter >> expected a variable expression. A number of evaluations of component >> array elements were producing pre blocks that were not added and so >> the temporaries were not being evaluated. >> >> The fix is to pass the COMPONENT_REF and extract the 'span' directly from it. >> >> The rest of the patch arises from PR86328 comment #12. In fact, this >> took most of the time that I have spent on these PRs :-( Having done >> this, I felt that I had to include this part of the patch in the >> submission. However, I have found a host of related bugs, which I will >> put together in one PR. >> >> My inclination is to commit the patch without the parts in resolve.c, >> trans-expr.c and pr86328_12.f90, especially for 8-branch. I am open to >> suggestions for 9-branch. >> >> Bootstraps and regtests on FC28/x68_64 - OK for 8- and 9-branches? > > the patch is ok for trunk from my side. I also agree that it makes > sense to backport those parts that address the regression to 8-branch. > Thanks for the fix! > > Cheers, > Janus -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[wwwdocs] Update link to Mono project at projects/cli.html
Committed. Gerald Index: projects/cli.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cli.html,v retrieving revision 1.32 diff -u -r1.32 cli.html --- projects/cli.html 29 Jul 2018 20:31:35 - 1.32 +++ projects/cli.html 1 Sep 2018 12:00:49 - @@ -412,7 +412,7 @@ Implementation overview Gcccil does not implement its own CLR metadata parser. -Instead, it uses http://www.mono-project.com/";>Mono +Instead, it uses https://www.mono-project.com";>Mono to "parse" the input assembly. That is, Mono is used to load the assembly and parse the metadata and types. The front end only has to parse the actual CIL code of each method. Mono provides a comprehensive API to
[wwwdocs] Remove gcc.skazkaforyou.com mirror
This mirror has gone rogue and the domain is for sale, so I went ahead and removed it with the patch below. Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.251 diff -u -r1.251 mirrors.html --- mirrors.html2 Jun 2018 21:16:10 - 1.251 +++ mirrors.html1 Sep 2018 12:09:33 - @@ -19,7 +19,6 @@ Austria: ftp://gd.tuwien.ac.at/gnu/gcc/";>gd.tuwien.ac.at, thanks to Antonin.Sprinzl at tuwien.ac.at --> Canada: http://gcc.parentingamerica.com";>http://gcc.parentingamerica.com, thanks to James Miller (jmiller at parentingamerica.com). -Canada: http://gcc.skazkaforyou.com";>http://gcc.skazkaforyou.com, thanks to Sergey Ivanov (mirrors at skazkaforyou.com) France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/";>ftp.lip6.fr, thanks to ftpmaint at lip6.fr France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/";>ftp.irisa.fr, thanks to ftpmaint at irisa.fr France, Versailles: ftp://ftp.uvsq.fr/pub/gcc/";>ftp.uvsq.fr, thanks to ftpmaint at uvsq.fr
[wwwdocs] Remove border="0" from tables
...since it's the default (and also stands in the way of moving to HTML 5). Applied. Gerald Index: egcs-1.1/regress.html === RCS file: /cvs/gcc/wwwdocs/htdocs/egcs-1.1/regress.html,v retrieving revision 1.9 diff -u -r1.9 regress.html --- egcs-1.1/regress.html 2 Jun 2018 21:16:13 - 1.9 +++ egcs-1.1/regress.html 1 Sep 2018 12:07:01 - @@ -67,7 +67,7 @@ Current Regression Testing Status - + Platform Index: gcc-2.95/othertest.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-2.95/othertest.html,v retrieving revision 1.8 diff -u -r1.8 othertest.html --- gcc-2.95/othertest.html 2 Jun 2018 21:16:13 - 1.8 +++ gcc-2.95/othertest.html 1 Sep 2018 12:07:01 - @@ -15,7 +15,7 @@ are the Linux kernel, GNU C library, Red Hat 6.0 sources and the LAPACK library. - + Platform Index: gcc-2.95/regress.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-2.95/regress.html,v retrieving revision 1.109 diff -u -r1.109 regress.html --- gcc-2.95/regress.html 2 Jun 2018 21:16:13 - 1.109 +++ gcc-2.95/regress.html 1 Sep 2018 12:07:01 - @@ -19,7 +19,8 @@ Regression Testing Status - + + Platform @@ -332,7 +333,8 @@ Package/Feature Testing - + + Platform
[wwwdocs] Update various links to openmp.org
Committed. Gerald Index: gcc-5/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.151 diff -u -r1.151 changes.html --- gcc-5/changes.html 26 Aug 2018 13:04:30 - 1.151 +++ gcc-5/changes.html 1 Sep 2018 12:29:47 - @@ -189,13 +189,13 @@ New Languages and Language specific improvements -http://www.openmp.org/wp-content/uploads/OpenMP4.0.0.pdf";> +https://www.openmp.org/wp-content/uploads/OpenMP4.0.0.pdf";> OpenMP 4.0 specification offloading features are now supported by the C, C++, and Fortran compilers. Generic changes: Infrastructure (suitable for any vendor). Testsuite which covers offloading from the - http://www.openmp.org/wp-content/uploads/OpenMP4.0.0.Examples.pdf";> + https://www.openmp.org/wp-content/uploads/OpenMP4.0.0.Examples.pdf";> OpenMP 4.0 Examples document. Specific for upcoming Intel Xeon Phi products: Index: gcc-7/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v retrieving revision 1.107 diff -u -r1.107 changes.html --- gcc-7/changes.html 10 Jun 2018 14:22:57 - 1.107 +++ gcc-7/changes.html 1 Sep 2018 12:29:47 - @@ -769,7 +769,7 @@ At line 8 of file do_check_12.f90 Fortran runtime error: Loop iterates infinitely - Version 4.5 of the http://www.openmp.org/specifications/"; + Version 4.5 of the https://www.openmp.org/specifications/"; >OpenMP specification is now partially supported in the Fortran compiler; the largest missing item is structure element mapping. Index: projects/gomp/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/gomp/index.html,v retrieving revision 1.23 diff -u -r1.23 index.html --- projects/gomp/index.html2 Jun 2018 21:16:21 - 1.23 +++ projects/gomp/index.html1 Sep 2018 12:29:47 - @@ -9,7 +9,7 @@ Welcome to the home of GOMP The GOMP project has developed an implementation of -http://www.openmp.org";>OpenMP +https://www.openmp.org";>OpenMP for the C, C++, and Fortran compilers in the GNU Compiler Collection and is further improving it. As part of the November 14, 2015 The final http://www.openmp.org/wp-content/uploads/openmp-4.5.pdf";>OpenMP v4.5 +href="https://www.openmp.org/wp-content/uploads/openmp-4.5.pdf";>OpenMP v4.5 specification has been released. October 13, 2015
[doc] install.texi - mpfr.org link adjustment
I made a similar change to the web pages earlier today; this is
the complementary one for the installation documentation.
Applied.
Gerald
2018-09-01 Gerald Pfeifer
* doc/install.texi (Prerequisites): Adjust link mpfr.org.
Index: doc/install.texi
===
--- doc/install.texi(revision 264027)
+++ doc/install.texi(working copy)
@@ -366,7 +366,7 @@
@item MPFR Library version 2.4.2 (or later)
Necessary to build GCC@. It can be downloaded from
-@uref{http://www.mpfr.org/}. If an MPFR source distribution is found
+@uref{https://www.mpfr.org}. If an MPFR source distribution is found
in a subdirectory of your GCC sources named @file{mpfr}, it will be
built together with GCC. Alternatively, if MPFR is already installed
but it is not in your default library search path, the
[libstdc++,doc] Update three ieeexplore.ieee.org references
I caught these three while looking at borken/changed links on our web page. (There are a few more I want to look into the coming days.) Applied. 2018-09-01 Gerald Pfeifer * doc/xml/manual/profile_mode.xml: Update three ieeexplore.ieee.org references. Index: doc/xml/manual/profile_mode.xml === --- doc/xml/manual/profile_mode.xml (revision 264027) +++ doc/xml/manual/profile_mode.xml (working copy) @@ -26,7 +26,7 @@ various components at interesting entry/exit points to/from the standard library. Process trace, recognize suboptimal patterns, give advice. For details, see the - http://www.w3.org/1999/xlink"; xlink:href="http://ieeexplore.ieee.org/document/4907670/";>Perflint + http://www.w3.org/1999/xlink"; xlink:href="https://ieeexplore.ieee.org/document/4907670/";>Perflint paper presented at CGO 2009. @@ -328,7 +328,7 @@ For details, see - http://www.w3.org/1999/xlink"; xlink:href="http://ieeexplore.ieee.org/document/4907670/";>paper presented at + http://www.w3.org/1999/xlink"; xlink:href="https://ieeexplore.ieee.org/document/4907670/";>paper presented at CGO 2009. @@ -1403,7 +1403,7 @@ See papers: http://www.w3.org/1999/xlink"; xlink:href="https://dl.acm.org/citation.cfm?doid=1065944.1065981";> A framework for adaptive algorithm selection in STAPL and - http://www.w3.org/1999/xlink"; xlink:href="http://ieeexplore.ieee.org/document/4228227/";> + http://www.w3.org/1999/xlink"; xlink:href="https://ieeexplore.ieee.org/document/4228227/";> Optimizing Sorting with Machine Learning Algorithms. Sample runtime reduction:60%.
[wwwdocs] readings.html - update link
...to "A formal model of sequence points and related issues". Committed. Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.298 diff -u -r1.298 readings.html --- readings.html 1 Sep 2018 11:56:19 - 1.298 +++ readings.html 1 Sep 2018 13:33:58 - @@ -348,7 +348,7 @@ http://www.open-std.org/jtc1/sc22/wg14/www/docs/n925.htm";> A formal model of sequence points and related issues by Clive Feather -http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-453.pdf";> +https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-453.pdf";> C formalised in HOL, thesis by Michael Norrish http://www.open-std.org/jtc1/sc22/wg14/www/docs/n926.htm";> Sequence points analysis by Raymond Mak
Relocation (= move+destroy)
Hello,
this patch passed bootstrap+regtest on powerpc64le-unknown-linux-gnu.
The main idea is manually performing loop fusion when we see 2 consecutive
loops where the first moves data from A to B, and the second destroys the
same elements in A.
This is beneficial because there is one loop fewer (as usual with loop
fusion), but also because the move constructor and the destructor can
combine relatively well for several types. I performed some simple tests
on std::vector, and for a loop that just emplace_back many
empty strings, I see a performance gain close to 20%. With not-small
strings, I am still seeing a noticable gain (maybe 10%? The noise makes it
hard to be precise).
I had to add a special case for trivial types, using memmove, to avoid
perf regressions, since relocation takes precedence over the old path that
is specialized to call memmove.
_GLIBCXX_ASAN_ANNOTATE_REINIT: I am not familiar with those annotations.
It was convenient in one function to move this annotation after _Destroy,
to reduce code duplication. For consistency, I did the same in the whole
file. As far as I understand, the macro makes it ok to access memory
between _M_finish and _M_end_of_storage, and at the end of the block marks
again the region after the new _M_finish as protected. Since _Destroy
should stop at _M_finish, moving the macro looks safe. But maybe the
position of the macro was chosen to reduce needless checking in ASAN?
It might be possible to introduce some helpers that do relocate if
noexcept and copy otherwise, but it is much less convenient than for
move_if_noexcept, because they don't want to execute the destructors at
the same point, so we might also want a destroy_if_no_relocate to go with
it...
The exact form of the relocate functions is whatever I had when things
started working, it is probably not that important as long as we don't
document them. I had a _n version taking a size, but I ended up not using
it, so I removed it.
The change is limited to C++17+, because I felt like using if constexpr.
Actually, I think g++ accepts if constexpr in C++11 with a warning (ok in
a system header), I don't remember if I ended up using any other recent
features...
Possible future stuff:
* use relocation in more places: there should be 1 or 2 places left in
vector, deque may also be a good candidate, I didn't look elsewhere.
* specialize relocation for some types (maybe deque?) where it can be
noexcept, possibly even trivial, whereas the move constructor cannot. If
we do that, we may want to specialize for pair/tuple/array as well, in
case one of the members is specialized.
2018-09-01 Marc Glisse
PR libstdc++/87106
* include/bits/alloc_traits.h (_S_construct, _S_destroy, construct,
destroy): Add noexcept specification.
* include/bits/allocator.h (construct, destroy): Likewise.
* include/ext/alloc_traits.h (construct, destroy): Likewise.
* include/ext/malloc_allocator.h (construct, destroy): Likewise.
* include/ext/new_allocator.h (construct, destroy): Likewise.
* include/bits/stl_uninitialized.h (__relocate, __relocate_a,
__relocate_a_1): New functions.
(__is_trivially_relocatable): New class.
* include/bits/stl_vector.h (__use_relocate): New static member.
* include/bits/vector.tcc (reserve, _M_realloc_insert,
_M_default_append): Use __relocate_a.
(reserve, _M_assign_aux, _M_realloc_insert, _M_fill_insert,
_M_default_append, _M_range_insert): Move _GLIBCXX_ASAN_ANNOTATE_REINIT
after _Destroy.
--
Marc GlisseIndex: include/bits/alloc_traits.h
===
--- include/bits/alloc_traits.h (revision 264027)
+++ include/bits/alloc_traits.h (working copy)
@@ -233,38 +233,43 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
using type = decltype(__test<_Alloc>(0));
};
template
using __has_construct
= typename __construct_helper<_Tp, _Args...>::type;
template
static _Require<__has_construct<_Tp, _Args...>>
_S_construct(_Alloc& __a, _Tp* __p, _Args&&... __args)
+ noexcept(noexcept(__a.construct(__p, std::forward<_Args>(__args)...)))
{ __a.construct(__p, std::forward<_Args>(__args)...); }
template
static
_Require<__and_<__not_<__has_construct<_Tp, _Args...>>,
is_constructible<_Tp, _Args...>>>
_S_construct(_Alloc&, _Tp* __p, _Args&&... __args)
+ noexcept(noexcept(::new((void*)__p)
+ _Tp(std::forward<_Args>(__args)...)))
{ ::new((void*)__p) _Tp(std::forward<_Args>(__args)...); }
template
static auto
_S_destroy(_Alloc2& __a, _Tp* __p, int)
+ noexcept(noexcept(__a.destroy(__p)))
-> decltype(__a.destroy(__p))
{ __a.destroy(__p); }
template
static void
_S_destroy(_Alloc2&, _Tp* __p, ...)
+ noexcept(noexcept(__p->~_Tp()))
{ __p->~_Tp(); }
template
static auto
_S_max_size(_Alloc2& __a, int)
-> decltyp
Re: Relocation (= move+destroy)
I forgot to attach the "diff -w" version of the patch, which may be a bit
more readable.
--
Marc GlisseIndex: include/bits/alloc_traits.h
===
--- include/bits/alloc_traits.h (revision 264027)
+++ include/bits/alloc_traits.h (working copy)
@@ -233,38 +233,43 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
using type = decltype(__test<_Alloc>(0));
};
template
using __has_construct
= typename __construct_helper<_Tp, _Args...>::type;
template
static _Require<__has_construct<_Tp, _Args...>>
_S_construct(_Alloc& __a, _Tp* __p, _Args&&... __args)
+ noexcept(noexcept(__a.construct(__p, std::forward<_Args>(__args)...)))
{ __a.construct(__p, std::forward<_Args>(__args)...); }
template
static
_Require<__and_<__not_<__has_construct<_Tp, _Args...>>,
is_constructible<_Tp, _Args...>>>
_S_construct(_Alloc&, _Tp* __p, _Args&&... __args)
+ noexcept(noexcept(::new((void*)__p)
+ _Tp(std::forward<_Args>(__args)...)))
{ ::new((void*)__p) _Tp(std::forward<_Args>(__args)...); }
template
static auto
_S_destroy(_Alloc2& __a, _Tp* __p, int)
+ noexcept(noexcept(__a.destroy(__p)))
-> decltype(__a.destroy(__p))
{ __a.destroy(__p); }
template
static void
_S_destroy(_Alloc2&, _Tp* __p, ...)
+ noexcept(noexcept(__p->~_Tp()))
{ __p->~_Tp(); }
template
static auto
_S_max_size(_Alloc2& __a, int)
-> decltype(__a.max_size())
{ return __a.max_size(); }
template
static size_type
@@ -333,33 +338,36 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @param __p Pointer to memory of suitable size and alignment for Tp
* @param __args Constructor arguments.
*
* Calls __a.construct(__p, std::forward(__args)...)
* if that expression is well-formed, otherwise uses placement-new
* to construct an object of type @a _Tp at location @a __p from the
* arguments @a __args...
*/
template
static auto construct(_Alloc& __a, _Tp* __p, _Args&&... __args)
+ noexcept(noexcept(_S_construct(__a, __p,
+ std::forward<_Args>(__args)...)))
-> decltype(_S_construct(__a, __p, std::forward<_Args>(__args)...))
{ _S_construct(__a, __p, std::forward<_Args>(__args)...); }
/**
* @brief Destroy an object of type @a _Tp
* @param __a An allocator.
* @param __p Pointer to the object to destroy
*
* Calls @c __a.destroy(__p) if that expression is well-formed,
* otherwise calls @c __p->~_Tp()
*/
template
static void destroy(_Alloc& __a, _Tp* __p)
+ noexcept(noexcept(_S_destroy(__a, __p, 0)))
{ _S_destroy(__a, __p, 0); }
/**
* @brief The maximum supported allocation size
* @param __a An allocator.
* @return @c __a.max_size() or @c numeric_limits::max()
*
* Returns @c __a.max_size() if that expression is well-formed,
* otherwise returns @c numeric_limits::max()
*/
@@ -465,32 +473,34 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @brief Construct an object of type @a _Up
* @param __a An allocator.
* @param __p Pointer to memory of suitable size and alignment for Tp
* @param __args Constructor arguments.
*
* Calls __a.construct(__p, std::forward(__args)...)
*/
template
static void
construct(allocator_type& __a, _Up* __p, _Args&&... __args)
+ noexcept(noexcept(__a.construct(__p, std::forward<_Args>(__args)...)))
{ __a.construct(__p, std::forward<_Args>(__args)...); }
/**
* @brief Destroy an object of type @a _Up
* @param __a An allocator.
* @param __p Pointer to the object to destroy
*
* Calls @c __a.destroy(__p).
*/
template
static void
destroy(allocator_type& __a, _Up* __p)
+ noexcept(noexcept(__a.destroy(__p)))
{ __a.destroy(__p); }
/**
* @brief The maximum supported allocation size
* @param __a An allocator.
* @return @c __a.max_size()
*/
static size_type
max_size(const allocator_type& __a) noexcept
{ return __a.max_size(); }
Index: include/bits/allocator.h
===
--- include/bits/allocator.h (revision 264027)
+++ include/bits/allocator.h (working copy)
@@ -81,25 +81,29 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#if __cplusplus >= 201103L
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 2103. std::allocator propagate_on_container_move_assignment
typedef true_type propagate_on_container_move_assignment;
typedef true_type is_always_equal;
template
void
construct(_Up* __p, _Args&&... __args)
+ noexcept(noexcept(::new((void *)__p)
+ _Up(std::forward<_Args>(__args)...)))
{ ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
template
void
- destroy(_Up* __p)
Re: [PATCH][debug] Add -gdescribe-dies
On 08/31/2018 11:19 PM, Jason Merrill wrote:
> On Fri, Aug 24, 2018 at 11:38 AM, Tom de Vries wrote:
>> [ was: Re: [PATCH][debug] Add -gdescriptive-dies ]
>> On Fri, Aug 24, 2018 at 12:44:38PM +0200, Richard Biener wrote:
>>> On Wed, 22 Aug 2018, Tom de Vries wrote:
>>>
[ was: Re: [PATCH][debug] Add -gforce-named-dies ]
On 08/22/2018 11:46 AM, Tom de Vries wrote:
> On 08/22/2018 08:56 AM, Tom de Vries wrote:
>> This is an undocumented developer-only option, because using this option
>> may
>> change behaviour of dwarf consumers, f.i., gdb shows the artificial
>> variables:
>> ...
>> (gdb) info locals
>> a = 0x7fffda90 "\005"
>> D.4278 =
>> ...
> I just found in the dwarf 5 spec the attribute DW_AT_description
> (present since version 3):
> ...
> 2.20 Entity Descriptions
> Some debugging information entries may describe entities in the program
> that are artificial, or which otherwise have a “name” that is not a
> valid identifier in the programming language.
>
> This attribute provides a means for the producer to indicate the purpose
> or usage of the containing debugging infor
>
> Generally, any debugging information entry that has, or may have, a
> DW_AT_name attribute, may also have a DW_AT_description attribute whose
> value is a null-terminated string providing a description of the entity.
>
> It is expected that a debugger will display these descriptions as part
> of displaying other properties of an entity.
> ...
>
> AFAICT, gdb currently does not explicitly handle this attribute, which I
> think means it's ignored.
>
> It seems applicable to use DW_AT_description at least for the artificial
> decls.
>
> Perhaps even for all cases that are added by the patch?
>
I've chosen for this option. Using DW_AT_desciption instead of
DW_AT_name should minimize difference in gdb behaviour with and without
-gdescriptive-dies.
>>>
>>> -gdescribe-dies?
>>>
>>
>> Done.
>>
> I'll rewrite the patch.
OK for trunk?
>>>
>>> Few comments:
>>>
>>> +static void
>>> +add_desc_attribute (dw_die_ref die, tree decl)
>>> +{
>>> + tree decl_name;
>>> +
>>> + if (!flag_descriptive_dies || dwarf_version < 3)
>>> +return;
>>> +
>>>
>>> you said this is a DWARF5 "feature",
>>
>> No, it's a DWARF3 "feature". I copied the text from the DWARF5 spec.
>>
>>> I'd suggest changing the
>>> check to
>>>
>>> if (!flag_desctiprive_dies || (dwarf_version < 5 && dwarf_strict))
>>>
>>> given -gdescribe-dies is enough of a user request to enable the
>>> feature.
>>
>> Done.
>>
>>> Not sure if we should warn about -gstrict-dwarf
>>> combination with it and -gdwarf-N < 5.
>>>
>>
>> Not sure either, left it out.
>>
>>> + else if (TREE_CODE (decl) == VAR_DECL || TREE_CODE (decl) ==
>>> CONST_DECL)
>>> +{
>>> + char buf[32];
>>> + char decl_letter = TREE_CODE (decl) == CONST_DECL ? 'C' : 'D';
>>> + sprintf (buf, "%c.%u", decl_letter, DECL_UID (decl));
>>> + add_desc_attribute (die, buf);
>>> +}
>>>
>>> I wondered before if we can use pretty-printing of decl here. At
>>> least I wouldn't restrict it to VAR_DECLs, FUNCTION_DECLs can
>>> certainly appear here I think.
>>>
>>
>> Done.
>>
>>> +@item -gdescriptive-dies
>>> +@opindex gdescriptive-dies
>>> +Add description attribute to DWARF DIEs that have no name attribute.
>>> +
>>>
>>> Either "description attributes" or "a description attribute", not
>>> 100% sure being a non-native speaker.
>>>
>>
>> Went for "description attributes".
>>
>>> Otherwise the patch looks OK to me but please leave Jason time
>>> to comment.
>>>
>>
>> Will do.
>>
>> Untested patch attached.
>>
Now bootstrapped and reg-tested on x86_64.
>> [debug] Add -gdescribe-dies
>>
>> This patch adds option -gdescribe-dies. It sets the DW_AT_description
>> attribute of dies that do not get a DW_AT_name attribute, to make it easier
>> to
>> figure out what the die is describing.
>>
>> The option exports the names of artificial variables:
>> ...
>> DIE0: DW_TAG_variable (0x7fa934dd54b0)
>> + DW_AT_description: "D.1922"
>>DW_AT_type: die -> 0 (0x7fa934dd0d70)
>>DW_AT_artificial: 1
>>
>> ...
>> which can be traced back to gimple dumps:
>> ...
>> char a[0:D.1922] [value-expr: *a.0];
>> ...
>>
>> Furthermore, it adds names to external references:
>> ...
>> DIE0: DW_TAG_subprogram (0x7fa88b9650f0)
>> +DW_AT_description: "main"
>> DW_AT_abstract_origin: die -> label: vla_1.c.6719312a + 29 (0x7fa88b965140)
>
> Please add more of this description to the one-line documentation
> patch you have now;
Done.
> there are many DIEs that have no name because they
> don't need one, and this patch doesn't add names to all of them.
>
I've added the qualification "some" (to both documentation and command
line option description).
> These two cases seem like they have very different uses, but I
Re: [patch,nvptx] Basic -misa support for nvptx
On 08/31/2018 04:14 PM, Cesar Philippidis wrote:
> Attached is an nvptx patch that adds support for a new, albeit rarely
> used, compiler option -misa. At present, there are only two valid ISA
> arguments, SM_30 and SM_35. Without that flag, GCC will default to
> SM_30. The major advantage of using the SM_35 ISA is to enable the use
> PTX atom instructions for __atomic_fetch_{add,and,or,xor} for DI
> integers. Without -misa, GCC would use an atomic CAS loop for them.
> As
> an aside, this patch also enables PTX atom instructions for those
> aforementioned functions for SI integers.
Make the SI part a separate patch, and make sure that one has a
testcase. Pre-approved.
>
> Is this patch OK for trunk?
>
Well, how did you test this (
https://gcc.gnu.org/contribute.html#patches : "Bootstrapping and
testing. State the host and target combinations you used to do proper
testing as described above, and the results of your testing.") ?
> Thanks,
> Cesar
>
>
> 0001-Basic-misa-support-for-nvptx.patch
>
>
> Basic -misa support for nvptx
>
> 2018-XX-YY Cesar Philippidis
> Bernd Schmidt
>
> gcc/
> * config/nvptx/nvptx-opts.h: New file.
> * config/nvptx/nvptx.c (nvptx_file_start): Print the correct .target.
> * config/nvptx/nvptx.h: Include "nvptx-opts.h".
> (ASM_SPEC): Define.
> (TARGET_SM35): New macro.
> * config/nvptx/nvptx.md (atomic_fetch_): Enable with the
> correct predicate.
> * config/nvptx/nvptx.opt (ptx_isa, sm_30, sm_35): New enum and its
> values.
> (misa=): New option.
> * doc/invoke.texi (Nvidia PTX Options): Document -misa.
>
> gcc/testsuite/
> * gcc.target/nvptx/atomic_fetch-1.c: New test.
> * gcc.target/nvptx/atomic_fetch-1.c: New test.
>
>
> diff --git a/gcc/config/nvptx/nvptx-opts.h b/gcc/config/nvptx/nvptx-opts.h
> new file mode 100644
> index 000..55d9599917e
> --- /dev/null
> +++ b/gcc/config/nvptx/nvptx-opts.h
> @@ -0,0 +1,30 @@
> +/* Definitions for the NVPTX port needed for option handling.
> + Copyright (C) 2015-2018 Free Software Foundation, Inc.
> +
> + This file is part of GCC.
> +
> + GCC 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.
> +
> + GCC 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 GCC; see the file COPYING3. If not see
> +
Re: Relocation (= move+destroy)
On Sat, 1 Sep 2018, Marc Glisse wrote:
this patch passed bootstrap+regtest on powerpc64le-unknown-linux-gnu.
I realized afterwards that for a C++17-only feature, that's not testing
much... So I changed it to apply in C++14 and fixed a minor issue. There
is now a single regression:
23_containers/vector/modifiers/push_back/49836.cc
The PR was about not using assignment for an operation that should only
use construction, and that's fine. But we ended up with a stricter
testcase using CopyConsOnlyType, where the type has a deleted move
constructor which, as far as I understand the standard, makes it an
invalid type for use in vector::push_back. Is that something we want to
keep supporting, or may I break it? What is happening is that the
definition of __use_relocate asks if some expression involving a move of
_Tp is noexcept, which causes a hard error. It would certainly be possible
to work around that, but it would complicate the code and seems quite
pointless to me.
--
Marc GlisseIndex: include/bits/alloc_traits.h
===
--- include/bits/alloc_traits.h (revision 264027)
+++ include/bits/alloc_traits.h (working copy)
@@ -233,38 +233,43 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
using type = decltype(__test<_Alloc>(0));
};
template
using __has_construct
= typename __construct_helper<_Tp, _Args...>::type;
template
static _Require<__has_construct<_Tp, _Args...>>
_S_construct(_Alloc& __a, _Tp* __p, _Args&&... __args)
+ noexcept(noexcept(__a.construct(__p, std::forward<_Args>(__args)...)))
{ __a.construct(__p, std::forward<_Args>(__args)...); }
template
static
_Require<__and_<__not_<__has_construct<_Tp, _Args...>>,
is_constructible<_Tp, _Args...>>>
_S_construct(_Alloc&, _Tp* __p, _Args&&... __args)
+ noexcept(noexcept(::new((void*)__p)
+ _Tp(std::forward<_Args>(__args)...)))
{ ::new((void*)__p) _Tp(std::forward<_Args>(__args)...); }
template
static auto
_S_destroy(_Alloc2& __a, _Tp* __p, int)
+ noexcept(noexcept(__a.destroy(__p)))
-> decltype(__a.destroy(__p))
{ __a.destroy(__p); }
template
static void
_S_destroy(_Alloc2&, _Tp* __p, ...)
+ noexcept(noexcept(__p->~_Tp()))
{ __p->~_Tp(); }
template
static auto
_S_max_size(_Alloc2& __a, int)
-> decltype(__a.max_size())
{ return __a.max_size(); }
template
static size_type
@@ -333,33 +338,36 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @param __p Pointer to memory of suitable size and alignment for Tp
* @param __args Constructor arguments.
*
* Calls __a.construct(__p, std::forward(__args)...)
* if that expression is well-formed, otherwise uses placement-new
* to construct an object of type @a _Tp at location @a __p from the
* arguments @a __args...
*/
template
static auto construct(_Alloc& __a, _Tp* __p, _Args&&... __args)
+ noexcept(noexcept(_S_construct(__a, __p,
+ std::forward<_Args>(__args)...)))
-> decltype(_S_construct(__a, __p, std::forward<_Args>(__args)...))
{ _S_construct(__a, __p, std::forward<_Args>(__args)...); }
/**
* @brief Destroy an object of type @a _Tp
* @param __a An allocator.
* @param __p Pointer to the object to destroy
*
* Calls @c __a.destroy(__p) if that expression is well-formed,
* otherwise calls @c __p->~_Tp()
*/
template
static void destroy(_Alloc& __a, _Tp* __p)
+ noexcept(noexcept(_S_destroy(__a, __p, 0)))
{ _S_destroy(__a, __p, 0); }
/**
* @brief The maximum supported allocation size
* @param __a An allocator.
* @return @c __a.max_size() or @c numeric_limits::max()
*
* Returns @c __a.max_size() if that expression is well-formed,
* otherwise returns @c numeric_limits::max()
*/
@@ -465,32 +473,34 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @brief Construct an object of type @a _Up
* @param __a An allocator.
* @param __p Pointer to memory of suitable size and alignment for Tp
* @param __args Constructor arguments.
*
* Calls __a.construct(__p, std::forward(__args)...)
*/
template
static void
construct(allocator_type& __a, _Up* __p, _Args&&... __args)
+ noexcept(noexcept(__a.construct(__p, std::forward<_Args>(__args)...)))
{ __a.construct(__p, std::forward<_Args>(__args)...); }
/**
* @brief Destroy an object of type @a _Up
* @param __a An allocator.
* @param __p Pointer to the object to destroy
*
* Calls @c __a.destroy(__p).
*/
template
static void
destroy(allocator_type& __a, _Up* __p)
+ noexcept(noexcept(__a.destroy(__p)))
{ __a.destroy(__p); }
/**
* @brief The maximum supported allocation size
* @param __a An allocato
[wwwdocs] gcc-4.0/changes.html -- update link to note on Unicode quotations marks
Committed. Gerald Index: gcc-4.0/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.0/changes.html,v retrieving revision 1.73 diff -u -r1.73 changes.html --- gcc-4.0/changes.html26 Aug 2018 13:04:29 - 1.73 +++ gcc-4.0/changes.html1 Sep 2018 21:23:09 - @@ -60,7 +60,7 @@ locale. Programs that parse diagnostics and expect plain ASCII English-language messages should set LC_ALL=C. See http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html";>Markus + href="https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html";>Markus Kuhn's explanation of Unicode quotation marks for more information. The specs file is no longer installed on most
[doc] Adjust link to openmp.org in generic.texi and invoke.texi
Committed.
Gerald
2018-09-01 Gerald Pfeifer
* doc/generic.texi (OpenMP): Adjust link to openmp.org.
* doc/invoke.texi (C Dialect Options): Ditto.
Index: doc/generic.texi
===
--- doc/generic.texi(revision 264030)
+++ doc/generic.texi(working copy)
@@ -2198,7 +2198,7 @@
@tindex OMP_CLAUSE
All the statements starting with @code{OMP_} represent directives and
-clauses used by the OpenMP API @w{@uref{http://www.openmp.org/}}.
+clauses used by the OpenMP API @w{@uref{https://www.openmp.org}}.
@table @code
@item OMP_PARALLEL
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 264030)
+++ doc/invoke.texi (working copy)
@@ -2179,7 +2179,7 @@
Enable handling of OpenMP directives @code{#pragma omp} in C/C++ and
@code{!$omp} in Fortran. When @option{-fopenmp} is specified, the
compiler generates parallel code according to the OpenMP Application
-Program Interface v4.5 @w{@uref{http://www.openmp.org/}}. This option
+Program Interface v4.5 @w{@uref{https://www.openmp.org}}. This option
implies @option{-pthread}, and thus is only supported on targets that
have support for @option{-pthread}. @option{-fopenmp} implies
@option{-fopenmp-simd}.
[wwwdocs] Remove last traces of (gcc-3.4/mips-abi.html)
This removes the last traces of from our web pages, a key step towards HTML 5. Committed. Gerald Index: gcc-3.4/mips-abi.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.4/mips-abi.html,v retrieving revision 1.4 diff -u -r1.4 mips-abi.html --- gcc-3.4/mips-abi.html 2 Jun 2018 21:16:15 - 1.4 +++ gcc-3.4/mips-abi.html 1 Sep 2018 21:22:39 - @@ -81,7 +81,7 @@ -B. Small aggregate arguments (2) +B. Small aggregate arguments (2) @@ -241,7 +241,7 @@ -E. Structure return values +E. Structure return values
[doc] install.texi -- update link for MPC
Committed.
Probably not worth backporting to the GCC 8, 7, and 6 branches?
Gerald
2018-09-01 Gerald Pfeifer
* doc/install.texi (Prerequisites): Update link for MPC.
Index: doc/install.texi
===
--- doc/install.texi(revision 264032)
+++ doc/install.texi(working copy)
@@ -378,7 +378,7 @@
@item MPC Library version 0.8.1 (or later)
Necessary to build GCC@. It can be downloaded from
-@uref{http://www.multiprecision.org/}. If an MPC source distribution
+@uref{http://www.multiprecision.org/mpc/}. If an MPC source distribution
is found in a subdirectory of your GCC sources named @file{mpc}, it
will be built together with GCC. Alternatively, if MPC is already
installed but it is not in your default library search path, the
[wwwdocs] Simplify gcc-3.x/criteria.html (no more align="left")
Remove align="left" (which does not seem to have any impact nowadays) from table headers in the criterial.html files for all GCC 3.x releases. Committed. Gerald Index: gcc-3.0/criteria.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.0/criteria.html,v retrieving revision 1.32 diff -u -r1.32 criteria.html --- gcc-3.0/criteria.html 2 Jun 2018 21:16:14 - 1.32 +++ gcc-3.0/criteria.html 1 Sep 2018 22:26:08 - @@ -292,9 +292,9 @@ for measuring code quality: -Name -Language -Source URL +Name +Language +Source URL gzip 1.2.4aC @@ -338,11 +338,11 @@ In order to measure compile-time performance, we will use the following unit tests: -Name -Language -Source -Flags -Comments +Name +Language +Source +Flags +Comments insn-attrtab.cC -O2 Index: gcc-3.1/criteria.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.1/criteria.html,v retrieving revision 1.37 diff -u -r1.37 criteria.html --- gcc-3.1/criteria.html 2 Jun 2018 21:16:14 - 1.37 +++ gcc-3.1/criteria.html 1 Sep 2018 22:26:08 - @@ -309,9 +309,9 @@ quality: -Name -Language -Source URL +Name +Language +Source URL gzip 1.2.4aC @@ -351,11 +351,11 @@ In order to measure compile-time performance, we will use the following unit tests: -Name -Language -Source -Flags -Comments +Name +Language +Source +Flags +Comments insn-attrtab.c C Index: gcc-3.3/criteria.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/criteria.html,v retrieving revision 1.13 diff -u -r1.13 criteria.html --- gcc-3.3/criteria.html 2 Jun 2018 21:16:15 - 1.13 +++ gcc-3.3/criteria.html 1 Sep 2018 22:26:08 - @@ -313,9 +313,9 @@ quality: -Name -Language -Source URL +Name +Language +Source URL gzip 1.2.4aC @@ -356,11 +356,11 @@ In order to measure compile-time performance, we will use the following unit tests: -Name -Language -Source -Flags -Comments +Name +Language +Source +Flags +Comments insn-attrtab.c C Index: gcc-3.4/criteria.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.4/criteria.html,v retrieving revision 1.6 diff -u -r1.6 criteria.html --- gcc-3.4/criteria.html 2 Jun 2018 21:16:15 - 1.6 +++ gcc-3.4/criteria.html 1 Sep 2018 22:26:08 - @@ -313,9 +313,9 @@ quality: -Name -Language -Source URL +Name +Language +Source URL gzip 1.2.4aC @@ -356,11 +356,11 @@ In order to measure compile-time performance, we will use the following unit tests: -Name -Language -Source -Flags -Comments +Name +Language +Source +Flags +Comments insn-attrtab.c C
[doc] standards.texi -- update Objective-C reference
2018-09-02 Gerald Pfeifer
* doc/standards.texi (Standards): Update Objective-C reference.
Committed.
Gerald
Index: doc/standards.texi
===
--- doc/standards.texi (revision 264033)
+++ doc/standards.texi (working copy)
@@ -294,7 +294,7 @@
The authoritative manual on Objective-C 2.0 is available from Apple:
@itemize
@item
-@uref{https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html}
+@uref{https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html}
@end itemize
For more information concerning the history of Objective-C that is
[patch, libgfortran] Fix warning about mismatched type declarations.
All,
The subject patch fixes the declaration for the vlist argument of the
formatted_dtio function pointer definition which currently gives a
warnings during compilation for mismatched types.
Regression tested on x86_64-pc-linux.
OK for trunk?
Regards,
Jerry
2018-09-01 Jerry DeLisle
* io/io.h: Change declaration of vlist type to
gfc_full_array_i4 to eliminate warning for mismatched type.
* io/format.c ((parse_format_list): Use gfc_full_array_i4.
* io/io.h: Use gfc_full_array_i4.
diff --git a/libgfortran/ChangeLog b/libgfortran/ChangeLog
diff --git a/libgfortran/io/format.c b/libgfortran/io/format.c
index b4920aaf1f1..f5d3158d21d 100644
--- a/libgfortran/io/format.c
+++ b/libgfortran/io/format.c
@@ -1058,7 +1058,7 @@ parse_format_list (st_parameter_dt *dtp, bool *seen_dd)
{
/* We have parsed the complete vlist so initialize the
array descriptor and save it in the format node. */
- gfc_array_i4 *vp = tail->u.udf.vlist;
+ gfc_full_array_i4 *vp = tail->u.udf.vlist;
GFC_DESCRIPTOR_DATA(vp) = xmalloc (i * sizeof(GFC_INTEGER_4));
GFC_DIMENSION_SET(vp->dim[0],1, i, 1);
memcpy (GFC_DESCRIPTOR_DATA(vp), temp, i * sizeof(GFC_INTEGER_4));
diff --git a/libgfortran/io/format.h b/libgfortran/io/format.h
index ad7e1c14b8f..19882bcf095 100644
--- a/libgfortran/io/format.h
+++ b/libgfortran/io/format.h
@@ -78,7 +78,7 @@ struct fnode
{
char *string;
int string_len;
- gfc_array_i4 *vlist;
+ gfc_full_array_i4 *vlist;
}
udf; /* User Defined Format. */
diff --git a/libgfortran/io/io.h b/libgfortran/io/io.h
index d31213106ed..902eb412848 100644
--- a/libgfortran/io/io.h
+++ b/libgfortran/io/io.h
@@ -100,7 +100,8 @@ array_loop_spec;
/* Subroutine formatted_dtio (struct, unit, iotype, v_list, iostat,
iomsg, (_iotype), (_iomsg)) */
-typedef void (*formatted_dtio)(void *, GFC_INTEGER_4 *, char *, gfc_array_i4 *,
+typedef void (*formatted_dtio)(void *, GFC_INTEGER_4 *, char *,
+ gfc_full_array_i4 *,
GFC_INTEGER_4 *, char *,
gfc_charlen_type, gfc_charlen_type);
