Re: [PATCH] Require CET support only for the final GCC build

On Wed, 15 Jul 2020, Richard Biener wrote: > But note one of the issues is that when not cross-compiling we're > using a single libiberty for target and host objects (likewise There shouldn't be a target libiberty, since commit 8499116aa30a46993deff5acf73985df6b16fb8b (re PR regression/47836

Ping Re: c: Add C2X BOOL_MAX and BOOL_WIDTH to limits.h

Ping for this limits.h patch . -- Joseph S. Myers jos...@codesourcery.com

c: Add C2X BOOL_MAX and BOOL_WIDTH to limits.h

be hardcoded directly in rather than needing corresponding predefined macros. Bootstrapped with no regressions on x86_64-pc-linux-gnu. OK to commit? gcc/ 2020-07-02 Joseph Myers * glimits.h [__STDC_VERSION__ > 201710L] (BOOL_MAX, BOOL_WIDTH): New macros. gcc/testsuite/ 2020-07

Re: [RFC] rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

On Mon, 29 Jun 2020, Richard Biener via Gcc-patches wrote: > I'm not sure if the actual choice of macro values for the fe* builtins > need glueing logic or if we want them to be determined statically > by the target configuration - see how we handle folding of > fpclassify. At least without

Re: [PATCH] Treat { 0 } specially for structs with the designated_init attribute.

I think both the patches in this discussion (special { 0 } handling and the new warning option) generally look good. I don't see you in the FSF copyright assignment list; could you complete https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future (unless you're

Re: [PATCH] Treat { 0 } specially for structs with the designated_init attribute.

On Wed, 24 Jun 2020, Asher Gordon via Gcc-patches wrote: > I see. So perhaps this isn't the best way to go about implementing > attribute locations. What do you think would be a better way? Perhaps > using a DECL_MINIMAL for attributes? In general, too many things in GCC have the static type

RE: [PATCH] simplify-rtx: Two easy pieces.

On Sat, 20 Jun 2020, Hans-Peter Nilsson wrote: > Hi! Good to see you "back"! > > On Sat, 20 Jun 2020, Roger Sayle wrote: > > Thanks to you too. Alas, my credentials from the CVS days of GCC almost > > certainly don't > > work any more (in git), > > My guess is that your credentials are fine

Re: [PATCH] c-family: check qualifiers of arguments to __atomic built-ins (PR 95378)

On Tue, 16 Jun 2020, Jonathan Wakely via Gcc-patches wrote: > Currently the __atomic_{load,store,exchange,compare_exchange} built-ins > will happily store values through pointers to const, or use pointers to > volatile as the input and output arguments. This patch ensures that any > pointer that

Re: [PATCH V2] Practical Improvement to Double Precision Complex Divide

On Thu, 11 Jun 2020, Patrick McGehearty wrote: > I will study real.c carefully along with the C99 std > to determine if I can find useful values for RMIN2 and RMINSCAL > for each format which are within range for all instances > of that format. A quick skim of real.c shows we have ieee half

Re: [PATCH V2] Practical Improvement to Double Precision Complex Divide

On Wed, 10 Jun 2020, Patrick McGehearty wrote: > #ifdef L_divhc3 > #define RBIG  (correct value for half precision) > #define RMIN  (correct value for half precision) > #define RMIN2 ...  (correct value for half precision) > #define RMINSCAL ... (correct value for half precision) > #endif >

Re: [PATCH V2] Practical Improvement to Double Precision Complex Divide

On Wed, 10 Jun 2020, Patrick McGehearty wrote: > I see your point about other floating point formats. > According to the C standard, DOUBLE precision must > have a DBL_MAX of at least 1E+37. That is (slightly) > greater than 0x1.0p+63. > > Would > #define RMIN2 (0x1.0p-53) > #define RMINSCAL

Re: [PATCH] diagnostics: Consistently add fixit hint for implicit builtin declaration

This patch is OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH V2] Practical Improvement to Double Precision Complex Divide

On Fri, 5 Jun 2020, Patrick McGehearty wrote: > diff --git a/libgcc/libgcc2.c b/libgcc/libgcc2.c > index e0a9fd7..2a1d3dc 100644 > --- a/libgcc/libgcc2.c > +++ b/libgcc/libgcc2.c > @@ -2036,26 +2036,77 @@ CONCAT3(__mul,MODE,3) (MTYPE a, MTYPE b, MTYPE c, > MTYPE d) > CTYPE >

Re: [PATCH 1/2] Provide diagnostic hints for missing C inttypes.h string constants.

On Mon, 1 Jun 2020, Mark Wielaard wrote: > On Sun, May 24, 2020 at 02:30:13AM +0200, Mark Wielaard wrote: > > This adds a flag to c_parser so we know when we were trying to > > construct a string literal. If there is a parse error and we were > > constructing a string literal, and the next token

Re: [PATCH] diagnostics: Add function call parens matching to c_parser.

On Sun, 31 May 2020, Mark Wielaard wrote: > On Sun, May 24, 2020 at 11:46:34PM +0200, Mark Wielaard wrote: > > The C++ parser already tracks function call parens matching, but the C > > parser doesn't. This adds the same functionality to the C parser and adds > > a testcase showing the C++ and C

Re: collect2.exe errors not pruned

On Tue, 19 May 2020, Alexandre Oliva wrote: > > I don't think the error should mention .exe, but I also don't think the > > error should mention collect2 (see what I said in > > , the existence > > of collect2 is an implementation

Re: [PATCH][C] c/95141 - fix bogus integer overflow warning

On Tue, 19 May 2020, Richard Biener wrote: > This fixes an integer overflow warning that ultimatively happens because > of TREE_OVERFLOW propagating through transforms and the existing guard > against this, > > 375 if (TREE_OVERFLOW_P (ret) > 376 && !TREE_OVERFLOW_P (op0)

Re: New mklog script

On Tue, 19 May 2020, Martin Liška wrote: > On 5/19/20 10:11 AM, Martin Liška wrote: > > Can you please share how do you do it? It would be easy to add it. > > I added the feature via --fill-up-bug-titles option. It uses common > request and beatifulsoup packages. The REST interface is much

Re: [PATCH] TESTSUITE: Fix tests for 16-bit targets

On Fri, 15 May 2020, Jozef Lawrynowicz wrote: > The attached patch fixes many GCC and G++ tests for 16-bit targets. These > targets can have the following properties: > - "int", "size_t", "ptrdiff_t", "void *" are 16-bit types > - sizeof(int) == sizeof(short) Some of the tests are disabled by

Re: ChangeLog files - server and client scripts

On Thu, 14 May 2020, Martin Liška wrote: > On 5/13/20 7:53 PM, Joseph Myers wrote: > > On Wed, 13 May 2020, Martin Liška wrote: > > > > > I'm sending the gcc-changelog relates scripts which should be added to > > > contrib > > > folder. The patch contai

Re: ChangeLog files - server and client scripts

On Wed, 13 May 2020, Martin Liška wrote: > I'm sending the gcc-changelog relates scripts which should be added to contrib > folder. The patch contains: > - git_check_commit.py - checking script that verifies git message format We need a documentation patch to contribute.html or gitwrite.html

Re: [PATCH] make minmax detection work with FMIN/FMAX IFNs

On Fri, 8 May 2020, Richard Biener wrote: > The IFNs are supposed to match fmin and fmax from the C standard which > IIRC have IEEE semantics. fmin and fmax have IEEE (2008) semantics (where an sNaN operand results in a qNaN result with "invalid" raised", but a quiet NaN results in the other

Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

On Wed, 6 May 2020, Richard Biener wrote: > > Here is the updated patch for the record. > > Jakub, richi, is this ok for the GCC 10 branch? > > I'll defer to Joseph who is release manager as well. This version is OK with me. -- Joseph S. Myers jos...@codesourcery.com

RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

On Tue, 5 May 2020, Kyrylo Tkachov wrote: > This version of the fix uses __getauxval instead of getauxval. > The whole thing is guarded simply on __GLIBC__ >= 2. > __getauxval was introduced in 2.16 but the aarch64 port was added in 2.17 so > in practice I expect all aarch64 glibcs to support

Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

On Tue, 5 May 2020, Szabolcs Nagy wrote: > > A design principle is that glibc built with libgcc configured without > > glibc headers but with --with-glibc-version should produce an identical > > stripped binary to the glibc resulting from a longer alternating sequence > > of GCC and glibc

Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

On Mon, 4 May 2020, Szabolcs Nagy wrote: > i think __getauxval needs to be declared where it is used. Yes. > and libgcc should do a link test in configure becasuse a > libc may provide sys/auxv.h but not have __getauxval e.g. > musl libc does not export __getauxval, only getauxval. libgcc

RE: Should ARMv8-A generic tuning default to -moutline-atomics

I think this change is what introduced a glibc testsuite regression in the localplt test. https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html Contents of elf/check-localplt.out: Extra PLT reference: libc.so: getauxval A reference to getauxval from libgcc is also a namespace

Re: [PATCH] c: Fix ICE with _Atomic side-effect in nested fn param decls [PR94842]

On Thu, 30 Apr 2020, Jakub Jelinek via Gcc-patches wrote: > Hi! > > If there are _Atomic side-effects in the parameter declarations > of non-nested function, when they are parsed, current_function_decl is > NULL, the create_artificial_label created labels during build_atomic* are > then adjusted

Re: [PATCH v2] diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostcs

This is missing documentation for the new configure option in install.texi. -- Joseph S. Myers jos...@codesourcery.com

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, 23 Apr 2020, Richard Biener via Gcc-patches wrote: > I think at least one step would be uncontroversical(?), namely moving > the RTL expansion "magic" > up to a GIMPLE pass. Where the "magic" would be to turn > GIMPLE stmts not directly expandable via an existing optab into > GIMPLE that

Re: [PATCH] gcc/gcc.c: add outfiles spec

On Tue, 14 Apr 2020, Rasmus Villemoes wrote: > On 06/04/2020 23.18, Joseph Myers wrote: > > On Sat, 4 Apr 2020, Rasmus Villemoes wrote: > > > >> +#ifndef OUTFILES_SPEC > >> +#define OUTFILES_SPEC "%o" > >> +#endif > > > > A new

Re: [committed] cselib: Fix endless cselib loop on (plus:P (reg) (const_int 0))

This introduces an ICE building glibc for m68k (and the same ICE appears for microblaze, though I haven't bisected there). See bug 94526. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] gcc/gcc.c: add outfiles spec

On Sat, 4 Apr 2020, Rasmus Villemoes wrote: > +#ifndef OUTFILES_SPEC > +#define OUTFILES_SPEC "%o" > +#endif A new target macro needs to be documented in tm.texi.in, with tm.texi then being regenerated. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] Improve svn-rev to search for pattern at line beginning.

Thanks, this matches the commit hook (which only rejects From-SVN: at start of line, not elsewhere in a commit message). -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] c: After issuing errors about array size, for error-recovery don't make the array VLA [PR93573]

On Sat, 28 Mar 2020, Jakub Jelinek via Gcc-patches wrote: > Hi! > > After we report various errors about array size, we set for error-recovery > the size to be 1, but because size_int_const is false, it still means we > pretend the array is a VLA, can emit a second diagnostics in that case etc.

Re: [PATCH] c-family: Tighten vector handling in type_for_mode [PR94072]

On Thu, 19 Mar 2020, Richard Sandiford wrote: > In this PR we had a 512-bit VECTOR_TYPE whose mode is XImode > (an integer mode used for four 128-bit vectors). When trying > to expand a zero constant for it, we hit code in expand_expr_real_1 > that tries to use the associated integer type

Re: [PATCH] c: Fix up cfun->function_end_locus from the C FE [PR94029]

On Thu, 19 Mar 2020, Jakub Jelinek via Gcc-patches wrote: > The second instead propagates the location_t from the parsing of the > outermost compound statement (the function body) to finish_function. > > Both patches successfully bootstrapped/regtested on x86_64-linux and > i686-linux, ok for

Re: [stage1][PATCH] optgen: make more sanity checks for enums.

On Wed, 18 Mar 2020, Martin Liška wrote: > On 3/17/20 11:41 PM, Martin Sebor wrote: > > The script reports errors by emitting them as #error directives into > > standard output (so they cause the build to fail). Should this new > > routine do the same thing?  (/dev/stderr is also not available on 

Re: [stage1][PATCH] optgen: make more sanity checks for enums.

On Tue, 17 Mar 2020, Martin Liška wrote: > Hi. > > The patch is about better sanity check in option generation script. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed in stage1? OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] c: Handle C_TYPE_INCOMPLETE_VARS even for ENUMERAL_TYPEs [PR94172]

On Tue, 17 Mar 2020, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The following testcases ICE, because they contain extern variable > declarations with incomplete enum types that is later completed and after > that those variables are accessed. The ICEs are because the vars then may > have >

Re: [PATCH] avoid treating more incompatible redeclarations as builtin-ins [PR94040]

On Fri, 13 Mar 2020, Martin Sebor via Gcc-patches wrote: > On 3/12/20 7:17 PM, Joseph Myers wrote: > > On Thu, 5 Mar 2020, Martin Sebor wrote: > > > > > Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9? > > > > OK for GCC 10. > >

Re: c: ignore initializers for elements of variable-size types [PR93577]

On Fri, 13 Mar 2020, Christophe Lyon via Gcc-patches wrote: > The attached small patch fixes the problem (tested on arm and aarch64). > OK? > > gcc/c/ChangeLog: > > 2020-03-13 Christophe Lyon > > * c-typeck.c (process_init_element): Handle constructor_type with > type size

Re: [PATCH] driver: Fix typos in options descriptions

On Thu, 30 Jan 2020, Lewis Hyatt wrote: > Is this something that would be desirable to change for GCC 10? Attached > patch would do so, and the output would become instead: This patch is OK. (It may mean some translation updates, but we generally do such bug fixes when the issue is found by

Re: [PATCH] avoid treating more incompatible redeclarations as builtin-ins [PR94040]

On Thu, 5 Mar 2020, Martin Sebor wrote: > Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9? OK for GCC 10. -- Joseph S. Myers jos...@codesourcery.com

Re: c: ignore initializers for elements of variable-size types [PR93577]

On Tue, 10 Mar 2020, Christophe Lyon wrote: > sizeless-1.c and sizeless-2.c have the same code, but the latter is > compiled with -msve-vector-bits=256 and expects different > warnings/errors. > For line 33: > svint8_t *invalid_sve_sc_ptr = &(svint8_t) { *global_sve_sc_ptr }; > we now have: >

Re: c: ignore initializers for elements of variable-size types [PR93577]

On Mon, 9 Mar 2020, Christophe Lyon wrote: > Hi Joseph, > > I've noticed that your patch introduces regressions on aarch64: > FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-1.c > -march=armv8.2-a+sve (test for errors, line 33) > we now get >

c: ignore initializers for elements of variable-size types [PR93577]

type name, and adds tests for a few variations on what such initializers might look like, as well as tests for cases identified from ICEs seen with an earlier version of this patch. Bootstrapped with no regressions for x86_64-pc-linux-gnu. Applied to mainline. gcc/c: 2020-03-05 Joseph Myers

Re: [Committed 4/4] IBM Z: zTPF: Include glibc-stdint.h

On Wed, 4 Mar 2020, Andreas Krebbel wrote: > Building a zTPF cross currently fails when building libstdc++ > complaining about the __UINTPTR_TYPE__ to be missing. > > Fixed by including the glibc-stdint.h header. To confirm: TPF provides a header, which uses the same types as glibc's does?

Re: [PATCH v2 0/3] Introduce a new GCC option, --record-gcc-command-line

On Tue, 3 Mar 2020, Egeyar Bagcioglu wrote: > Although we discussed after the submission of the first version that > there are several other options performing similar tasks, I believe we > established that there is still a need for this specific functionality. > Therefore, I am skipping in

Re: [PATCH] Clear --help=language and --help=common interaction.

On Tue, 3 Mar 2020, Martin Liška wrote: > On 3/2/20 11:52 PM, Joseph Myers wrote: > > On Mon, 2 Mar 2020, Martin Liška wrote: > > > > > +version of GCC@. If an option is supported by all languages, one needs > > > +to use @var{common} qualifier instead. >

Re: [PATCH] Clear --help=language and --help=common interaction.

On Mon, 2 Mar 2020, Martin Liška wrote: > +version of GCC@. If an option is supported by all languages, one needs > +to use @var{common} qualifier instead. "common" is literal text, so it should be @samp{common} not @var{common}, and the existing documentation here describes it as a "class"

Re: maxval on -inf and nan in Fortran

On Fri, 28 Feb 2020, Tobias Burnus wrote: > Regarding MIN and MAX: I think the IEEE 754 decided at some point > decided that MAX(x, NaN) = x (IEEE 754:2008 alias ISO 60559:2011, if I > recall correctly). I think one has to check what exactly the test case > does and what is guaranteed where. I

Re: collect2.exe errors not pruned

On Fri, 28 Feb 2020, Alexandre Oliva wrote: > I'm not sure it's appropriate for the error to not omit the host > platform's executable suffix, just as it omits directory components from > argv[0], so I'm undecided between fixing collect2.c's initialization of > progname or extending the regexp,

Re: [PATCH] maintainer-scripts: Speed up git clone in gcc_release

On Wed, 26 Feb 2020, Jakub Jelinek wrote: > Hi! > > When doing the 8.4-rc1, I've noticed (probably also because of the dying > disk on sourceware) that git clone is extremely slow, and furthermore when > all of us have some local snapshots, it is a waste of resources to download > everything

Re: GLIBC libmvec status

On Tue, 25 Feb 2020, GT wrote: > 2. In GCC making SIMD clones available only for powerpc64le should be > sufficient to guarantee that the Vector Function ABI is applied only for > systems implementing the ELFv2 ABI. Right? Then, which macro is to be > tested for in rs6000_simd_clone_usable? I

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

On Thu, 20 Feb 2020, GT wrote: > What more needs to be done other than documenting the GLIBC and GCC > versions for which 'b' and 'c' vector versions are available? It is how > x86_64 explained the differences between Examples 1 and 2 at > https://sourceware.org/glibc/wiki/libmvec This is

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

On Wed, 19 Feb 2020, GT wrote: > 1. In the Vector Function ABI document, under section "Vector Function > Name Mangling", state that all vector variants will be created by > the compiler. And that it will be up to the caller of vectorized > functions to select the preferred version ('b' or

Re: [PATCH] i18n: Fix translation of --help [PR93759]

On Tue, 18 Feb 2020, Jakub Jelinek wrote: > Hi! > > The first two hunks make sure we actually translate what has been marked > for translation, i.e. the cl_options[...].help strings, rather than those > strings ammended in various ways, like: > _("%s Same as %s."), help, ... > or > "%s %s",

Re: [PATCH] c/86134 avoid errors for unrecognized -Wno- options

On Fri, 14 Feb 2020, Richard Biener wrote: > diff --git a/gcc/opts-global.c b/gcc/opts-global.c > index d5e308bf800..52ea083a6d5 100644 > --- a/gcc/opts-global.c > +++ b/gcc/opts-global.c > @@ -139,8 +139,10 @@ print_ignored_options (void) >const char *opt; > >opt =

Re: [PATCH] Use a non-empty test program to test ability to link

On Wed, 12 Feb 2020, Sandra Loosemore wrote: > Hmmm, I tried again and saw that autoconf didn't even touch the timestamp on > the existing configure file, but I was able to force it to regenerate the > files by removing the old ones first. Is this version of the patch OK to > check in? OK. --

Re: [PATCH] real: Fix roundeven on inf/nan [PR93663]

On Wed, 12 Feb 2020, Jakub Jelinek wrote: > As can be seen in the testcase, roundeven with inf or nan arguments > ICE because of those asserts where nothing prevents from is_halfway_below > being called with those arguments. > > The following patch fixes that by just returning false for

Re: [PATCH] Fix -ffast-math flags handling inconsistencies

On Mon, 10 Feb 2020, Ulrich Weigand wrote: > Given the above rule, in the last case __FINITE_MATH_ONLY__ should > also be 0, right? Yes. > I'm not sure how this can be implemented in the current option handling > framework. The -ffast-math handling case would have to check whether > or not

Re: [PATCH] Use a non-empty test program to test ability to link

On Sat, 8 Feb 2020, Sandra Loosemore wrote: > > > BTW, I did run autoconf in every subdirectory that contains a > > > configure.ac, > > > but it appears only libstc++-v3 actually uses this test; all the other > > > regenerated configure scripts were unchanged. > > > > There's some problem with

Re: [PATCH] Fix -ffast-math flags handling inconsistencies

On Fri, 7 Feb 2020, Ulrich Weigand wrote: > I thought that a *more specific* option like -fsignalling-nans was always > intended to override a more generic option like -ffast-math, no matter > whether it comes before or after it on the command line. Yes, that's correct. (There are cases where

Re: [PATCH] avoid issuing -Wrestrict from folder (PR 93519)

On Fri, 7 Feb 2020, Richard Biener wrote: > To me it's a QOI question that depends on the actual case. > Turning memcpy (p, p, N) into a no-op is the correct thing, > even though with (too) large N it might trap. Folding > a read from outside of an object to zero might be OK > (it's undefined),

Re: [committed] avoid pedantic warning in C++ 98 mode: comma at end of enumerator list

On Wed, 5 Feb 2020, Martin Sebor wrote: > I removed the trailing comma and (after a few false starts) managed > to push the change in commit > r10-6466-g297aa668293d55ffe100d810e92fbe592f262557. > > I got the error below for my first few attempts. The message had > the expected format so I

Re: [PATCH] Use a non-empty test program to test ability to link

On Wed, 5 Feb 2020, Sandra Loosemore wrote: > This patch is for PR 79193 and 88999, problems where libstdc++ is > mis-configuring itself when building for a bare-metal target because it thinks > it can link programs without pulling in the BSP that provides low-level I/O > support. (Specifically,

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, 3 Feb 2020, Michael Matz wrote: > I understand that, but the subject line of this thread says "e-mail > subject lines", so I thought we were talking about, well, exactly that; > and I see no value of these tags in e-mails either. I agree that [PATCH] is not useful (and in general,

Re: [PATCH] diagnostics: Add options to control the column units [PR49973] [PR86904]

This seems to be missing invoke.texi documentation for the new options. -- Joseph S. Myers jos...@codesourcery.com

Re: [RFA] [c/88660] Fix bogus set-but-unused warning

On Wed, 29 Jan 2020, Jeff Law wrote: > In the last major change in this code was ~5 years ago and twiddled the > handling of the switch expression to call convert_lvalue_to_rvalue. > > The last argument to that function indicates whether or not we should > mark the switch expression as a use of

Support gnu_unique_object symbols on MIPS

-dlopen-nodelete-reloc, which relies on the compiler generating such symbols, for MIPS. 2020-01-27 Joseph Myers * config/mips/mips.c (mips_declare_object_name) [USE_GNU_UNIQUE_OBJECT]: Support use of gnu_unique_object. diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c

Re: [RFC] [c-family] PR92867 - Add returns_arg attribute

On Fri, 24 Jan 2020, Prathamesh Kulkarni wrote: > The middle-end representation issue of ERF_RETURNS_ARG still remains, > which restricts the attribute till first four args. The patch simply > emits sorry(), for arguments beyond first four.. I think this should be fixed (e.g. make the middle-end

Re: wwwdocs: Document the gcc git repository layout

On Wed, 22 Jan 2020, Richard Earnshaw (lists) wrote: > Joseph, have I got all of these right? refs/meta in that list should be refs/meta/config, there isn't anything else under refs/meta/ at present. -- Joseph S. Myers jos...@codesourcery.com

Update update_web_docs_svn references in sourcebuild.texi

These needed updating after the replacement of update_web_docs_svn by update_web_docs_git. Committed. 2020-01-22 Joseph Myers * doc/sourcebuild.texi (Texinfo Manuals, Front End): Refer to update_web_docs_git instead of update_web_docs_svn. diff --git a/gcc/doc

Fix ICE with cast of division by zero (PR c/93348)

, as is done in other similar cases. Bootstrapped with no regressions for x86_64-pc-linux-gnu. Applied to mainline. Will also backport to GCC 9 and 8 branches. gcc/c: 2020-01-22 Joseph Myers PR c/93348 * c-typeck.c (build_c_cast): Call remove_c_maybe_const_expr

Re: [PATCH] doc: clarify the situation with pointer arithmetic

On Tue, 21 Jan 2020, Richard Biener wrote: > Second. Fact is RTL does not distinguish between pointers and > integers and thus any attempt to make something valid when you > use integers and invalid when you use pointers is not going to work. That simply means that an earlier stage in the

Re: [PATCH] doc: clarify the situation with pointer arithmetic

On Tue, 21 Jan 2020, Alexander Monakov wrote: > My intent was more basic. I observed that the paragraph can be interpreted as > saying that if you have a cast 'I1 = (intptr_t) P1', then perform some > computations on I1 that do not in any way depend on values of other pointers, > then casting the

Re: [PATCH v3] Add `--with-toolexeclibdir=' configuration option

On Mon, 2 Dec 2019, Maciej W. Rozycki wrote: > Provide means, in the form of a `--with-toolexeclibdir=' configuration > option, to override the default installation directory for target > libraries, otherwise known as $toolexeclibdir. This is so that it is > possible to get newly-built

Re: [RFC c-common PATCH] PR c++/40752 - useless -Wconversion with short +=.

On Fri, 10 Jan 2020, Jason Merrill wrote: > Joseph argued that those warnings are sometimes useful, and that they should > be controlled by a separate flag. So this patch introduces > -Warith-conversion, which is off by default in this patch. > > Joseph, is that default OK with you? I am OK

Re: [PATCH] doc: clarify the situation with pointer arithmetic

On Mon, 20 Jan 2020, Alexander Monakov wrote: > Hi, > > we have this paragraph in the documentation that attempts to prohibit > something that is allowed by the language. Instead, I think we should > say that this generally should work and explain that a problem in GCC > implementation

Re: [RFC] [c-family] PR92867 - Add returns_arg attribute

On Mon, 20 Jan 2020, Prathamesh Kulkarni wrote: > Hi, > This patch attempts to add returns_arg attribute for c-family > languages. For C++ methods, first arg is assumed to be this pointer, This is missing .texi documentation explaining the attribute and the cases for which it would be useful.

Update branching and branch closing instructions for move to git.

update_version_svn has been replaced by update_version_git. The scripts directory in ~gccadmin is now a symlink into a gcc-checkout directory. Various commands using SVN are replaced by git commands and instructions for updating the old git mirror are removed. Instructions for adding a new

Re: limit on emails for merge commits.

On Fri, 17 Jan 2020, Richard Biener wrote: > We also make sure (?) to not make them show up in bugzilla, right? That's already done; the email-to-bugzilla-filtered script only passes commits to master and release branches (i.e., pushes that update those refs) to Bugzilla. -- Joseph S. Myers

Re: limit on emails for merge commits.

On Fri, 17 Jan 2020, Joel Brobecker wrote: > The main goal of the limit is really to avoid accidents where someone > pushes something he shouldn't or something he didn't realize would > push so many commits. If the GCC repository is such that merges of > 100 commits or more is going to be, if not

Re: limit on emails for merge commits.

On Fri, 17 Jan 2020, Iain Sandoe wrote: > So I know that the policy is under review (and agree, from my PoV, that > something that represents these in a similar way to the SVN single mail > containing all the changes is probably optimum). > > However, right now I’m stuck - and really want to get

Re: drop -aux{dir,base}, revamp -dump{dir,base}

On Thu, 16 Jan 2020, Alexandre Oliva wrote: > And here's a followup that fixes a limitation (bug?) in libiberty that > was hit when I attempted a last-minute simplification in lto-wrapper. > > Regstrapped separately on x86_64-linux-gnu. Ok to install? > > > [libiberty] output empty args as a

Re: Copy list of development branches from svn.html into git.html

On Fri, 17 Jan 2020, Jakub Jelinek wrote: > On Thu, Jan 16, 2020 at 11:22:15PM +0000, Joseph Myers wrote: > > Committed. I think the main remaining things that need work in our git > > documentation on the website are: > > Shouldn't we move some of the branches fr

Re: [PATCH] Fix ICE caused by swallowing a token in c_parser_consume_token

Thanks, patch committed. -- Joseph S. Myers jos...@codesourcery.com

Copy list of development branches from svn.html into git.html

This patch makes a start on making the branch information from svn.html available in git.html. The list is copied, some notes added on devel/, refs/dead/heads/ and refs/vendors/ naming, and inactive branches from the general section (ones not present in refs/heads/devel/, automatically moved to

Re: [patch] contrib: Don't add push rules for personal and vendor spaces.

A reasonable replacement for those push rules might be command aliases (e.g. "git upush " to push the user branch ). -- Joseph S. Myers jos...@codesourcery.com

Fix setting of DECL_CONTEXT in pushdecl (PR c/93072)

, the two are equivalent.) Bootstrapped with no regressions for x86_64-pc-linux-gnu. Applied to mainline. Will backport to GCC 9 and 8 branches. gcc/c: 2020-01-15 Joseph Myers PR c/93072 * c-decl.c (pushdecl): Use TREE_PUBLIC, not DECL_EXTERNAL, to determine whether

Say more about conflict messages on git pull

Give an example of the message you get for such a conflict, and discuss options for keeping local changes when pulling. Committed. diff --git a/htdocs/git.html b/htdocs/git.html index 70cc7b73..725bd81c 100644 --- a/htdocs/git.html +++ b/htdocs/git.html @@ -95,13 +95,30 @@ is: Autoconf, Bison,

Remove warning at top of git web pages

Although the documentation is still a work in progress, with various forms of git usage (e.g. contrib/gcc-git-customization.sh) not yet documented and development branches not yet listed on git.html as they are on svn.html, the warning about the conversion still being in progress is no longer

Give example of error message when pushing to a branch with other changes

Giving explicit example of git messages seems helpful for novice users to understand when they are in a particular situation for which instructions are given. Committed. diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html index f420fe22..e55cfa92 100644 --- a/htdocs/gitwrite.html +++

Correct git config command syntax

There is no --set option, git config sets variables without such an option. Committed. diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html index 85a0da2d..f420fe22 100644 --- a/htdocs/gitwrite.html +++ b/htdocs/gitwrite.html @@ -78,7 +78,7 @@ git clone

Re: Fix for LTO compromised autoconf test in libiberty

My preference is still what I said in : either eliminate C alloca from libiberty, or don't build it with any compiler defining __GNUC__. I'd be surprised if there are host compilers that build libiberty, have the relevant optimizations

Re: [PATCH] contrib: git descr/undescr aliases

On Tue, 14 Jan 2020, Roman Zhuykov wrote: > PS. We at ISPRAS see that for ~28 hours (11 Jan 2020, 18:00 UTC - 12 Jan 2020, > 22:00 UTC) our servers haven't received any gcc mailing list letters, but they > are available at https://gcc.gnu.org/ml/ archives (totally 6 mails on gcc@ and > 16 on

Re: Replace update_web_docs_svn with update_web_docs_git

On Mon, 13 Jan 2020, Jonathan Wakely wrote: > On 13/01/20 17:46 +0000, Joseph Myers wrote: > > This patch replaces the update_web_docs_svn script, that updates > > online documentation from its sources in the GCC repository, run once > > a day from cron, with update_web_docs_

Re: Replace update_web_docs_svn with update_web_docs_git

I've also applied this corresponding web page update. diff --git a/htdocs/releasing.html b/htdocs/releasing.html index 5d08550c..48853f9c 100644 --- a/htdocs/releasing.html +++ b/htdocs/releasing.html @@ -89,9 +89,9 @@ the main web page, and add a proper news item there as well. and add a link

Replace update_web_docs_svn with update_web_docs_git

This patch replaces the update_web_docs_svn script, that updates online documentation from its sources in the GCC repository, run once a day from cron, with update_web_docs_git. Applied to mainline. 2020-01-13 Joseph Myers * update_web_docs_git: New file

<    4   5   6   7   8   9   10   11   12   13   >