Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote: > Then, this routine (flexible_array_type_p) is mainly for diagnostic purpose. > It cannot be used to determine whether the structure/union type recursively > include a flexible array member at the end. > > Is my understanding correct? My comm

Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

On Wed, 8 Feb 2023, Qing Zhao via Gcc-patches wrote: > But I noticed that “flexible_array_type_p” later was moved from FE to > middle-end and put into tree.cc, tree.h as a general utility routine, and to > > /* Determine whether TYPE is a structure with a flexible array member, >or a union

Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

On Wed, 8 Feb 2023, Siddhesh Poyarekar wrote: > On 2023-02-08 14:09, Joseph Myers wrote: > > What must be avoided is -pedantic diagnostics for > > > > struct flex1 { int n; int data[1]; }; > > struct out_flex_end1 { int m; struct flex1 flex_data; }; > > >

[committed] c: Update checks on constexpr pointer initializers

WG14 has agreed a change of the rules on constexpr pointer initializers, so that a (constant) null value that is not a null pointer constant is accepted in that context, rather than only accepting null pointer constants. (In particular, this means that a constexpr variable of pointer type can be u

[committed] c: Allow conversions of null pointer constants to nullptr_t

WG14 has agreed to allow conversions (explicit and implicit) from null pointer constants to nullptr_t; update GCC's nullptr_t implementation to match. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ * c-convert.cc (c_convert): Allow conversion of a null pointer co

Re: [wwwdocs] Add C status page

On Tue, 24 May 2022, Marek Polacek via Gcc-patches wrote: > > And cases where some support in GCC should > > definitely be done to consider the feature implemented, even when not > > needed for conformance (e.g. the %wN, %wfN printf/scanf formats need > > implementing in glibc, and correspondin

Re: [PATCH] c++: Allow mixing GNU/std-style attributes [PR69585]

On Fri, 3 Jun 2022, Marek Polacek via Gcc-patches wrote: > However, the patch does not touch the C FE. The C FE doesn't have > a counterpart to C++'s cp_parser_attributes_opt -- it only has > c_parser_transaction_attributes (which parses both GNU and [[]] > attributes), but that's TM-specific. T

Re: [PATCH, CFE] N2863: Improved Rules for Tag Compatibility

On Tue, 7 Jun 2022, Martin Uecker wrote: > here is a preliminary patch the implements the proposed > tag compatibility rules for C23 in GCC (N2863). It works I don't see any response on the reflector to my comments on that proposal (message 21374, Fri, 14 Jan 2022 23:32:47 +). Nor do I see

Re: [PATCH 03/12] Add more emit_diagnostic overloads

On Wed, 22 Jun 2022, David Malcolm via Gcc-patches wrote: > extern bool emit_diagnostic (diagnostic_t, rich_location *, int, >const char *, ...) ATTRIBUTE_GCC_DIAG(4,5); > +extern bool emit_diagnostic (diagnostic_t, rich_location *, > + const d

Re: [PATCH 5/8] intl: stop using fgrep for exgettext

On Fri, 24 Jun 2022, Xi Ruoyao via Gcc-patches wrote: > fgrep has been deprecated in favor of grep -F for a long time, and the > next grep release (3.8 or 4.0) will print a warning of fgrep is used. > And, the fgrep command in exgettext is no longer useful after we > migrated from SVN to Git. Rem

Re: [PATCH 0/8] Stop using obsoleted egrep/fgrep

On Fri, 24 Jun 2022, Andrew Pinski via Gcc-patches wrote: > Though I do find that -E/-F have been part of the POSIX standard since > at least 2004 which is interesting. grep -E and -F are already defined, and egrep and fgrep marked as obsolescent, in the 1992/1993 edition of POSIX.2. -- Joseph

Re: [PATCH] libcpp: Update cpp_wcwidth() to Unicode 14.0.0

On Fri, 24 Jun 2022, David Malcolm via Gcc-patches wrote: > > BTW, is this something simple enough I should just commit it without > > bugging > > the list for approval? > > The patch seems reasonable to me, but Joseph seems to be the expert on > i18n-related matters. > > Joseph, do we have a po

Re: [PATCH] fortran, libgfortran, v2: Avoid using libquadmath for glibc 2.26+

On Mon, 27 Jun 2022, Jakub Jelinek via Gcc-patches wrote: > On Sun, Jun 26, 2022 at 08:45:28PM +0200, Mikael Morin wrote: > > I don’t like the _Float128 vs __float128 business, it’s confusing. > > And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html > > they seem to be basicall

Re: [PATCH] libcpp: Update ucnid.h to Unicode 14

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

[committed] nios2: Fix PIC function call slowness

On Nios II, PIC function calls use R_NIOS2_CALL* relocations, which may refer to a GOT entry that initially points to a PLT entry to resolve the function on first call and that is then changed by the dynamic linker to point directly to the function to be called so subsequent calls do not go through

lto: Fix option merging [PR106129]

The LTO merging of options from different input files was broken by: commit 227a2ecf663d69972b851f51f1934d18927b62cd Author: Martin Liska Date: Fri Mar 12 11:53:47 2021 +0100 lto-wrapper: Use vec data type. Previously, find_and_merge_options would merge options it read into those in *opts

Re: xfail fetestexcept test - ppc always uses fcmpu

On Wed, 10 Mar 2021, Alexandre Oliva wrote: > operand exception for quiet NaN. I couldn't find any evidence that > the rs6000 backend ever outputs fcmpo. Therefore, I'm adding the same > execution xfail marker to this test. In my view, such an XFAIL (for a GCC bug as opposed to an environmental

Re: xfail fetestexcept test - ppc always uses fcmpu

On Thu, 11 Mar 2021, Alexandre Oliva wrote: > I kind of like the notion of adding a comment to the test itself, but I > wasn't sure that's what you meant. Yes, adding a comment to the test itself is what I meant. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] c: FIx up -Wunused-but-set-* warnings for _Atomics [PR99588]

On Fri, 19 Mar 2021, Jakub Jelinek via Gcc-patches wrote: > Hi! > > As the following testcases show, compared to -D_Atomic= case we have many > -Wunused-but-set-* warning false positives. > When an _Atomic variable/parameter is read, we call mark_exp_read on it in > convert_lvalue_to_rvalue, but

Re: [PATCH v8] Practical improvement to libgcc complex divide

On Mon, 22 Feb 2021, Patrick McGehearty via Gcc-patches wrote: > diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c > index 9f993c4..7dd319c 100644 > --- a/gcc/c-family/c-cppbuiltin.c > +++ b/gcc/c-family/c-cppbuiltin.c > @@ -1026,10 +1026,10 @@ c_cpp_builtins (cpp_reader *pfil

Re: RFC: Sphinx for GCC documentation

On Wed, 7 Apr 2021, Michael Matz wrote: > Random snippet for what I mean: the .texi contains: > > "The @code{access} attribute specifies that a function to whose > by-reference arguments the attribute applies accesses the referenced > object according to @var{access-mode}. The @var{access-mode

Re: [PATCH] c: Don't drop vector attributes that affect type identity [PR98852]

On Wed, 14 Apr 2021, Richard Sandiford via Gcc-patches wrote: > gcc/ > PR c/98852 > * attribs.h (affects_type_identity_attributes): Declare. > * attribs.c (remove_attributes_matching): New function. > (affects_type_identity_attributes): Likewise. > > gcc/c/ > PR c/98

Re: [PATCH] propagate attributes to local redeclaration (PR 99420)

On Thu, 8 Apr 2021, Martin Sebor via Gcc-patches wrote: > There's another similar piece of code in pushdecl() that I didn't > touch, although I couldn't come up with a test case showing it's > necessary. Both hunks go back ages so I wonder if they might have > been obviated by other improvements

Re: [PATCH v10] Practical improvement to libgcc complex divide

On Wed, 7 Apr 2021, Patrick McGehearty via Gcc-patches wrote: > + macro_name = XALLOCAVEC (char, name_len > ++ sizeof ("__LIBGCC__EXCESS_PRECISION__")); > sprintf (macro_name, "__LIBGCC_%s_EXCESS_PRECISION__", name); > builtin_define_with_int_v

Re: [committed] aarch64: Always use .init/.fini_array for GNU/Linux

On Wed, 21 Apr 2021, Andreas Schwab wrote: > On Apr 21 2021, Richard Sandiford via Gcc-patches wrote: > > > However, AArch64 postdates glibc and binutils support for > > .init/fini_array by some distance, so it's safe to hard-code the > > result to "yes" for cross compilers. > > Should there be

Re: [committed] aarch64: Always use .init/.fini_array for GNU/Linux

On Wed, 21 Apr 2021, Richard Sandiford wrote: > which AFAICT would test preprocessing for the host rather than the target. Ah, good point. (GCC_GLIBC_VERSION_GTE_IFELSE can be used to deal with glibc version conditionals in a way that works, given appropriate configure options, even when the t

Re: [PATCH] gcc/configure.ac: fix register issue for global_load assembler functions

On Wed, 16 Jun 2021, Julian Brown wrote: > > +if test x$gcc_cv_as_gcn_global_load_fixed = xyes; then > > + AC_DEFINE(HAVE_GCN_ASM_GLOBAL_LOAD_FIXED, 1, [Define if your > > assembler has fixed global_load functions.]) > > +else > > + AC_DEFINE(HAVE_GCN_ASM_GLOBAL_LOAD_FIXED, 0, [D

Re: [PATCH] gcc/configure.ac: fix register issue for global_load assembler functions

On Thu, 17 Jun 2021, Marcel Vollweiler wrote: > Thank you for your proposals. I adapted configure.ac and gcn.c > accordingly (similar to the GATHER_STATISTICS example). Thanks, the configure changes in this version are OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH RFA] expand: empty class return optimization [PR88529]

This introduces an ICE building libgomp for ColdFire, as detected by my glibc bot. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101170 -- Joseph S. Myers jos...@codesourcery.com

Re: GCC documentation: porting to Sphinx

On Wed, 23 Jun 2021, Martin Liška wrote: > @Joseph: Can you share your thoughts about the used Makefile integration? What > do you suggest for 2) > (note that explicit listing of all .rst file would be crazy)? You can write dependencies on e.g. doc/gcc/*.rst (which might be more files than actua

Re: [PATCH] Port GCC documentation to Sphinx

Are formatted manuals (HTML, PDF, man, info) corresponding to this patch version also available for review? -- Joseph S. Myers jos...@codesourcery.com

Re: [COMMITTED V10 3/7] CTF/BTF debug formats

There's now a build failure for sparc64-linux-gnu: In file included from ./tm_p.h:4:0, from /scratch/jmyers/glibc-bot/src/gcc/gcc/ctfout.c:24: /scratch/jmyers/glibc-bot/src/gcc/gcc/config/sparc/sparc-protos.h:46:47: error: use of enum 'memmodel' without previous declaration exte

Re: [COMMITTED V10 3/7] CTF/BTF debug formats

On Tue, 29 Jun 2021, David Edelsohn via Gcc-patches wrote: > On Tue, Jun 29, 2021 at 10:33 AM Joseph Myers wrote: > > > > There's now a build failure for sparc64-linux-gnu: > > > > In file included from ./tm_p.h:4:0, > > from /scratch/jm

Re: RFC: --help for Driver options (was: [Patch] gcc.c: Add -foffload= to display_help)

On Wed, 30 Jun 2021, Tobias Burnus wrote: > While looking at that issue, Jakub and I wondered whether there > should be some warning if a Driver option has a help text, > which never appears. Migrating from hardcoded help text in gcc.c to using .opt help text for Driver options to generate --hel

Re: [PATCH 0/2] Initial support for AVX512FP16

Some general comments, following what I said on libc-alpha: 1. Can you confirm that the ABI being used for 64-bit, for _Float16 and _Complex _Float16 argument passing and return, follows the current x86_64 ABI document? 2. Can you confirm that if you build with this instruction set extension

Re: [PATCH 56/62] AVX512FP16: Optimize (_Float16) sqrtf ((float) f16) to sqrtf16 (f16).

On Thu, 1 Jul 2021, liuhongt via Gcc-patches wrote: > +/* Optimize for code like (_Float16) __builtin_sqrtf ((float) f16) > + since it's not handled in frontend. */ If correct, it *should* be handled in front end (well, middle-end). See what convert.c:convert_to_real_1 does, with a long comm

Re: [PATCH 58/62] AVX512FP16: Optimize for code like (_Float16) __builtin_ceif ((float) f16).

On Thu, 1 Jul 2021, liuhongt via Gcc-patches wrote: > +/* Optimize for code like (_Float16) __builtin_ceif ((float) f16) > + since it's not handled in frontend. */ Much the same comments apply as for sqrt. But in this case, the conversion code is in match.pd - right now, specific to pairs of

Re: [PATCH 0/2] Initial support for AVX512FP16

On Thu, 1 Jul 2021, H.J. Lu via Gcc-patches wrote: > The main issue is complex _Float16 functions in libgcc. If _Float16 doesn't > require -mavx512fp16, we need to compile complex _Float16 functions in > libgcc without -mavx512fp16. Complex _Float16 performance is very > important for our _Float

Re: [PATCH 56/62] AVX512FP16: Optimize (_Float16) sqrtf ((float) f16) to sqrtf16 (f16).

On Thu, 1 Jul 2021, Richard Biener via Gcc-patches wrote: > > C++ FE doesn't support _FLoat16, and the place float/double are > > handled is in convert.c(which is GENERIC?), that's why I decided to do > > it in the backend. I think there ought to be a preliminary patch series adding whatever _Fl

Re: [PATCH] Add optional _Float16 support

On Thu, 1 Jul 2021, H.J. Lu via Gcc-patches wrote: > 2. Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1 registers. That restricts use of _Float16 to processors with SSE. Is that what we want in the ABI, or should _Float16 be available with base 32-bit x86 architecture features only

Re: [PATCH] Add optional _Float16 support

On Thu, 1 Jul 2021, H.J. Lu wrote: > BTW, _Float16 software emulation may require more than just SSE > since we need to do _Float16 load and store with XMM registers. > There is no 16bit load/store for XMM registers without AVX512FP16. You should be able to make the move go via general-purpose re

Support UTF-8 character constants for C2x

ainline. gcc/c: 2019-11-14 Joseph Myers * c-parser.c (c_parser_postfix_expression) (c_parser_check_literal_zero): Handle CPP_UTF8CHAR. * gimple-parser.c (c_parser_gimple_postfix_expression): Likewise. gcc/c-family: 2019-11-14 Joseph Myers * c-lex.c (lex_c

Support C2x [[deprecated]] attribute

also a pre-existing bug (91182 - although that's filed as a C++ bug, the code in question is language-independent, in tree.c). Bootstrapped with no regressions on x86_64-pc-linux-gnu. Applied to mainline. gcc/c: 2019-11-15 Joseph Myers * c-decl.c (std_attrib

Improve checks on C2x fallthrough attribute

. As with other attributes, there are still cases where warnings should be pedwarns because C2x constraints are violated, but this patch improves the attribute handling. Bootstrapped with no regressions on x86_64-pc-linux-gnu. Applied to mainline. gcc/c: 2019-11-15 Joseph Myers

Re: Symver attribute

On Fri, 15 Nov 2019, Jan Hubicka wrote: > I was originaly supporting multiple symvers like: > __attribute__ ((__symver__ ("foo@VERS_1"))) int > __attribute__ ((__symver__ ("foo@VERS_2"))) int > foo_v1 (void) > { > } > > but then noticed it is rejected by gas. That's

Support C2x [[maybe_unused]] attribute

otstrapped with no regressions on x86_64-pc-linux-gnu. Applied to mainline. This concludes the C2x features I'm doing for the present stage 1 (I won't get [[nodiscard]] done this stage 1), though there will be various followup fixes related to attributes. gcc/c: 2019-11-15 Joseph My

Diagnose duplicate C2x standard attributes

the list. Bootstrapped with no regressions on x86_64-pc-linux-gnu. Applied to mainline. gcc/c: 2019-11-15 Joseph Myers * c-parser.c (c_parser_std_attribute_specifier): Diagnose duplicate standard attributes. gcc/testsuite: 2019-11-15 Joseph Myers * gcc.dg/c2x-attr

Re: Support C2x [[]] attributes for C

On Sat, 16 Nov 2019, Iain Sandoe wrote: > Joseph Myers wrote: > > > This patch adds support for the C2x [[]] attribute syntax to the C > > front end. > > > gcc.dg/gnu2x-attrs-1.c: New tests. > > This test fails on targets without symbol alias support, b

Add more C2x attributes tests

the [[__fallthrough__]] spelling of [[fallthrough]] in the case of valid fallthrough attributes. Tested for x86_64-pc-linux-gnu. Applied to mainline. 2019-11-18 Joseph Myers * gcc.dg/c11-attr-syntax-1.c, gcc.dg/c11-attr-syntax-2.c, gcc.dg/c11-attr-syntax-3.c, gcc.dg/c2x-attr

Re: [PATCH v2] Add `--with-install-sysroot=' configuration option

On Mon, 18 Nov 2019, Maciej W. Rozycki wrote: > > 4. How does this interact with sysroot suffixes (again, this should be > > made clear in the documentation)? > > There is no interaction, the patch merely changes where the libraries are > installed. If the installation sysroot directory chose

Change some bad uses of C2x attributes into pedwarns

(including when mixed with fallthrough) and on statements. Bootstrapped with no regressions on x86_64-pc-linux-gnu. Applied to mainline. gcc/c: 2019-11-19 Joseph Myers * c-decl.c (c_warn_unused_attributes): Use pedwarn not warning for standard attributes. * c-parser.c

Re: Symver attribute

On Mon, 18 Nov 2019, Rainer Orth wrote: > So you certainly need such an effective-target test and, at least as > importantly, a configure test at build time that you can assemble, link, > and run a test correctly before enabling it in gcc. Just > unconditionally dropping it into elfos.h is wrong.

Re: [DRIVER PATCH]: Nadger subprocess argv[0]

On Tue, 14 May 2019, Nathan Sidwell wrote: > This patch nadgers the driver's subprocess names to include the driver name. > It results in more informative error messages. For instance, rather than: > > >./xg++ -B./ frob.cc -c -fdump-tree-nope > cc1plus: error: unrecognized command line optio

Re: [PATCH] Multibyte awareness for diagnostics (PR 49973)

On Tue, 19 Nov 2019, David Malcolm wrote: > If we're going with this approach, and redistributing those unicode data > files as part of our repo and tarballs, do we need some kind of > copyright/license statement that spells out the situation? What does > glibc do for this? glibc includes the fi

Re: [PING] Re: [PATCH] Fix PR92088

On Tue, 19 Nov 2019, Richard Biener wrote: > > +/* For nested functions disqualify ones taking VLAs by value > > + from inlining since the middle-end cannot deal with this. > > + ??? We should arrange for those to be passed by reference > > + with emitting the copy on the ca

Re: [PATCH] Multibyte awareness for diagnostics (PR 49973)

On Tue, 19 Nov 2019, David Malcolm wrote: > If we're going with this approach (which I'll leave to Joseph), perhaps I think reusing the glibc generator is appropriate. -- Joseph S. Myers jos...@codesourcery.com

Add more pedwarns for [[]] C attributes on types

/c: 2019-11-20 Joseph Myers * c-decl.c (c_warn_type_attributes): New function. (groktypename, grokdeclarator, finish_declspecs): Call c_warn_type_attributes before applying attributes to types. * c-tree.h (c_warn_type_attributes): Declare. gcc/testsuite: 2019-11

Add release notes for new C2X features in GCC 10

I've committed this patch to add release notes for new C2X features in GCC 10. diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html index 1e9c3f8d..52eb303c 100644 --- a/htdocs/gcc-10/changes.html +++ b/htdocs/gcc-10/changes.html @@ -63,6 +63,44 @@ a work-in-progress. +C + +

Document -Wc11-c2x-compat

Will apply to GCC 9 branch after reducing the list of features covered to reflect the more limited C2X support in GCC 9. 2019-11-20 Joseph Myers * doc/invoke.texi (-Wc11-c2x-compat): Document. Index: gcc/doc/invoke.texi ===

Re: [PATCH v2] Add `--with-install-sysroot=' configuration option

On Wed, 20 Nov 2019, Maciej W. Rozycki wrote: > > But even then, if you configure GCC using "--with-sysroot" or > > "--with-build-sysroot", both of those paths are the top-level sysroot, to > > which the sysroot suffix gets appended before GCC uses it for any purpose, > > unless you explicitly

Re: [PATCH] Switch gcc ftp URL's to http

This patch is OK with http changed to https. (That is, with it changed where the patch is already changing the URL. While changing http to https makes sense more generally in the documentation whenever a site supports https, that's probably best not mixed with the move from ftp.) -- Joseph S

Re: [PATCH 5/X] [libsanitizer][mid-end] Introduce stack variable handling for HWASAN

On Wed, 20 Nov 2019, Matthew Malcomson wrote: > I don't have much of a plan. > > The most promising lead I have is that libiberty/alloca.c has a similar > functionality but with macros to account for a special case. The comment in libiberty/aclocal.m4 is: # We always want a C version of alloca

Re: Reverting r278411

On Wed, 20 Nov 2019, Jakub Jelinek wrote: > On Wed, Nov 20, 2019 at 10:17:38AM -0600, Segher Boessenkool wrote: > > On Wed, Nov 20, 2019 at 03:46:29PM +, Richard Sandiford wrote: > > > Segher Boessenkool writes: > > > > UNLT & ORDERED is always LT. When would it not be true? > > > > > > LT

Re: [PATCH] Switch gcc ftp URL's to http

On Wed, 20 Nov 2019, Janne Blomqvist wrote: > On Wed, Nov 20, 2019 at 7:53 PM Joseph Myers wrote: > > > > This patch is OK with http changed to https. (That is, with it changed > > where the patch is already changing the URL. While changing http to https > > makes

Make more bad uses of fallthrough attribute into pedwarns

2019-11-20 Joseph Myers * gimplify.c (expand_FALLTHROUGH_r, expand_FALLTHROUGH): Use pedwarn instead of warning_at for fallthrough not preceding a case or default label. gcc/c-family: 2019-11-20 Joseph Myers * c-attribs.c (handle_fallthrough_attribute): Use pedwa

Re: [committed] [testsuite] Fix fp-int-convert-timode-1.c testism.

On Thu, 21 Nov 2019, Tamar Christina wrote: > Hi All, > > The test fp-int-convert-timode-1.c uses FE_TONEAREST without > actually checking if the target has defined it. > > Like the rest of the tests I now add a check to see if the target > has actually implemented it. FE_TONEAREST is the defau

Re: Support C2x [[]] attributes for C

On Mon, 18 Nov 2019, Joseph Myers wrote: > On Sat, 16 Nov 2019, Iain Sandoe wrote: > > > Joseph Myers wrote: > > > > > This patch adds support for the C2x [[]] attribute syntax to the C > > > front end. > > > > > gcc.dg/gnu2x-attrs-

RE: [committed] [testsuite] Fix fp-int-convert-timode-1.c testism.

On Thu, 21 Nov 2019, Tamar Christina wrote: > Hi Joseph, > > > FE_TONEAREST is the default rounding mode, so it would be better just to > > remove the fesetround call and include and fenv effective-target > > and -frounding-math option and let this test run for all configurations with > > int128

Re: [PATCH] doc: Remove claim about ISO C

On Thu, 21 Nov 2019, Harald van Dijk wrote: > Hi, > > The patch to make -fcommon the default introduces a bogus claim into the GCC > documentation. I already raised this issue on the patch itself, where it was > unfortunately ignored. Please find attached a followup patch to remove this > bogus c

Re: [PATCH] doc: Remove claim about ISO C

On Thu, 21 Nov 2019, Harald van Dijk wrote: > On 21/11/2019 22:15, Joseph Myers wrote: > > On Thu, 21 Nov 2019, Harald van Dijk wrote: > > > > > Hi, > > > > > > The patch to make -fcommon the default introduces a bogus claim into the > > > GCC

Properly handle C2x attributes on types

and array types, and the logic for postfix attributes on a list of declaration specifiers failed to handle some cases, so those bugs are also fixed in this patch. Bootstrapped with no regressions for x86_64-pc-linux-gnu. OK to commit (attribs.c and C++ testsuite changes)? gcc: 2019-11-22 Jo

Prevent all uses of DFP when unsupported (PR c/91985)

ssions for x86_64-pc-linux-gnu. Also tested with no regressions for cross to aarch64-linux-gnu, as a configuration without DFP support. OK to commit (the changes that aren't C front-end changes)? gcc: 2019-11-22 Joseph Myers PR c/91985 * builtin-types.def (BT_

Re: [committed] [testsuite] Fix fp-int-convert-timode-1.c testism.

On Fri, 22 Nov 2019, Tamar Christina wrote: > Hi Joseph, > > > > Or do you want me to send them separately? > > > > I think it's best to fix the test now not to have the #ifdef, then if you > > have execution failures those can be addressed separately. (If you want > > to avoid the test FAILi

Re: [C/C++ PATCH] Fix up build of GCC 4.6 and earlier with GCC 9+ (PR c/90677, take 2)

On Fri, 22 Nov 2019, Jason Merrill wrote: > On 11/22/19 2:10 PM, Jakub Jelinek wrote: > > On Wed, Nov 20, 2019 at 02:01:58PM -0500, Jason Merrill wrote: > > > I would think that get_named_type should find struct or enum names that > > > have > > > been hidden by another declaration; that would fix

Re: [PATCH v2] Add `--with-install-sysroot=' configuration option

On Fri, 22 Nov 2019, Maciej W. Rozycki wrote: > As I recall the MIPS sysroot setup (please correct me if I got something > wrong here) was like: Yes, that's the sort of layout you get with sysroot suffixes. See gcc/config/mips/{st.h,t-st} for an example. > Then the right-hand side of /path/

Re: [PATCH 2/4] The main m68k cc0 conversion

On Mon, 25 Nov 2019, Bernd Schmidt wrote: > On 11/23/19 6:36 PM, Jeff Law wrote: > > > Not really. I've already indicated to Bernd that he should go ahead and > > commit the changes and we can iterate on any problems that arise. > > After the last fix, I did some more testing and since I feel c

Re: Properly handle C2x attributes on types

On Mon, 25 Nov 2019, Rainer Orth wrote: > it seems you missed updating a couple of testcases that are ia32-only: I think it's unavoidable that such target-specific testcases need updating by someone testing on the target in question. -- Joseph S. Myers jos...@codesourcery.com

Re: Prevent all uses of DFP when unsupported (PR c/91985)

On Mon, 25 Nov 2019, Rainer Orth wrote: > and a few more, all DFP related. They used to be emitted by g++ for > __fundamental_type_info in libsupc++/fundamental_type_info.cc and lived > in the CXXABI_1.3.4 version. However, since Solaris *does* lack DFP > support, that's no longer the case. I'm

Re: [PATCH 2/4] The main m68k cc0 conversion

On Tue, 26 Nov 2019, Bernd Schmidt wrote: > On 11/26/19 1:36 AM, Joseph Myers wrote: > > I'm seeing a libgcc build failure for coldfire in my build-many-glibcs.py > > bot (m68k-linux-gnu configured --with-arch=cf --disable-multilib). That's > > building _m

Re: [PATCH 2/4] The main m68k cc0 conversion

On Tue, 26 Nov 2019, Bernd Schmidt wrote: > On 11/26/19 3:21 AM, Joseph Myers wrote: > > > > The soft-float ColdFire build (--with-arch=cf --with-cpu=54455 > > --disable-multilib) successfully built libgcc and glibc, but ran into an > > ICE building the glibc tests

Re: Prevent all uses of DFP when unsupported (PR c/91985)

On Wed, 27 Nov 2019, Rainer Orth wrote: > Hi Jonathan, > > > On 26/11/19 00:57 +0000, Joseph Myers wrote: > >>On Mon, 25 Nov 2019, Rainer Orth wrote: > >> > >>> and a few more, all DFP related. They used to be emitted by g++ fo

Re: [PATCH] Translate header for -fdbg-cnt-list.

On Wed, 27 Nov 2019, Martin Liška wrote: > Hi. > > The patch is about translation of titles in -fdbg-cnt-list table. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? OK. -- Joseph S. Myers jos...@codesourcery.com

Re: Prevent all uses of DFP when unsupported (PR c/91985)

On Wed, 27 Nov 2019, Thomas Schwinge wrote: > If I turn that conditional cited above into 'if (1)', then nvptx > offloading testing seems to return to normality, but I have not yet > assessed whether that has any ill effects on decimal float types support, > and/or how this should be fixed properl

Re: [PATCH] Fix decimal floating-point LTO streaming for offloading compilation

On Thu, 28 Nov 2019, Julian Brown wrote: > Unlike e.g. the _FloatN types, when decimal floating-point types are > enabled, common tree nodes are created for each float type size (e.g. > dfloat32_type_node) and also a pointer to each type is created > (e.g. dfloat32_ptr_type_node). tree-streamer.c:

Re: [PATCH] Fix decimal floating-point LTO streaming for offloading compilation

On Thu, 28 Nov 2019, Julian Brown wrote: > On Thu, 28 Nov 2019 15:04:05 + > Joseph Myers wrote: > > > On Thu, 28 Nov 2019, Julian Brown wrote: > > > > > Unlike e.g. the _FloatN types, when decimal floating-point types are > > > enabled, common tre

Re: [PATCH v2] Add `--with-install-sysroot=' configuration option

On Thu, 28 Nov 2019, Maciej W. Rozycki wrote: > > > > Rather, it's a suffix (as in SYSROOT_SUFFIX_SPEC, no command-line option > > to print it), > > Do you mean that there's no option to print SYSROOT_SUFFIX_SPEC on its > own or that no option prints it as a path component? If the latter, th

Handle C2x attributes in Objective-C

r_peek_nth_token_raw) (c_parser_check_balanced_raw_token_sequence): New functions. (c_parser_nth_token_starts_std_attributes): Use c_parser_check_balanced_raw_token_sequence for Objective-C. gcc/testsuite: 2019-11-29 Joseph Myers * objc.dg/attributes/gnu2x-attr-syntax-1.m: New test. Ind

Fix libdecnumber handling of non-canonical BID significands (PR middle-end/91226)

if no problems appear with it on trunk. Note 3: presumably binutils-gdb will pick this up at some point through a merge of libdecnumber from the GCC repository.) libdecnumber: 2019-11-29 Joseph Myers PR middle-end/91226 * bid/bid2dpd_dpd2bid.c (_bid_to_dpd64): Handle non-cano

Re: [PATCH v2 1/2] driver: Do not warn about ineffective `-x' option if no inputs were given

On Fri, 29 Nov 2019, Maciej W. Rozycki wrote: > Fix an issue with the GCC driver and the `-x' option where a warning is > issued in an invocation like: > > $ riscv64-linux-gnu-gcc -print-multi-directory -x c++ > riscv64-linux-gnu-gcc: warning: '-x c++' after last input file has no effect > lib64

Re: [PING][PATCH] doc: Correct `--enable-version-specific-runtime-libs' support information

On Fri, 29 Nov 2019, Maciej W. Rozycki wrote: > On Wed, 20 Nov 2019, Maciej W. Rozycki wrote: > > > The `--enable-version-specific-runtime-libs' configuration option is now > > supported throughout all of our target library subdirectories, so update > > installation documentation accordingly an

Re: [C] Add a target hook that allows targets to verify type usage

On Fri, 29 Nov 2019, Richard Sandiford wrote: > Ping > > Richard Sandiford writes: > > This patch adds a new target hook to check whether there are any > > target-specific reasons why a type cannot be used in a certain > > source-language context. It works in a similar way to existing > > hooks

Re: Symver attribute

On Sat, 30 Nov 2019, Jan Hubicka wrote: > > I'd rather GCC created those aliases automatically (with names that can't > > be used as C symbols, e.g. containing '.', if possible, or failing that > > implementation-namespace names that are unlikely to conflict with C > > symbols), so that the API

Re: [GCC][PATCH] Add ARM-specific Bfloat format support to middle-end

On Mon, 2 Dec 2019, Jeff Law wrote: > > 2019-11-13 Stam Markianos-Wright > > > >* real.c (struct arm_bfloat_half_format, > >encode_arm_bfloat_half, decode_arm_bfloat_half): New. > >* real.h (arm_bfloat_half_format): New. > > > > > Generally OK. Please consider using

Diagnose use of [*] in old-style parameter definitions (PR c/88704)

point we don't have location information for the [*], so the diagnostic location isn't ideal.) Bootstrapped with no regressions for x86_64-pc-linux-gnu. Applied to mainline. gcc/c: 2019-12-03 Joseph Myers PR c/88704 * c-decl.c (store_parm_decls_oldstyle): Diagnose use

Re: [PATCH] range-op: Implement floating point division fold_range [PR107569]

On Tue, 22 Nov 2022, Jan-Benedict Glaw wrote: > I'm running a slightly hacked [glibc]/scripts/build-many-glibcs.py to > to CI builds for glibc as well by now (hacked to allow for GCC master > being used) and this GCC commit > (2d5c4a16dd833aa083f13dd3e78e3ef38afe6ebb) triggers glibc's > elf/check-

Re: [PATCH] c: Propagate erroneous types to declaration specifiers [PR107805]

On Tue, 22 Nov 2022, Florian Weimer via Gcc-patches wrote: > Without this change, finish_declspecs cannot tell that whether there > was an erroneous type specified, or no type at all. This may result > in additional diagnostics for implicit ints, or missing diagnostics > for multiple types. > >

Re: [PATCH] c: Fix compile time hog in c_genericize [PR107127]

On Wed, 23 Nov 2022, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The complex multiplications result in deeply nested set of many SAVE_EXPRs, > which takes even on fast machines over 5 minutes to walk. > This patch fixes that by using walk_tree_without_duplicates where it is > instant. > > Boo

Re: Java front-end and library patches.

On Fri, 25 Nov 2022, Zopolis0 via Gcc-patches wrote: > Firstly, to get feedback and reviews on the 56 already existing > patches, even though most are just re-adding code or making idiomatic > changes, so that when the final issue is solved everything has already > been approved (hopefully) and th

Re: Java front-end and library patches.

On Wed, 30 Nov 2022, Zopolis0 via Gcc-patches wrote: > > * Each patch should have its own explanation of what it is doing and why, > > in the message body (not in an attachment). Just the commit summary line > > and ChangeLog entries aren't enough, we need the actual substantive commit > > messag

Re: [PATCH] libcpp: suppress builtin macro redefined warnings for __LINE__

On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote: > diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c > b/gcc/testsuite/gcc.dg/builtin-redefine.c > index 882b2210992..9d5b42252ee 100644 > --- a/gcc/testsuite/gcc.dg/builtin-redefine.c > +++ b/gcc/testsuite/gcc.dg/builtin-redefine.c > @@ -7

<    7   8   9   10   11   12   13   14   15   16   >