c: Allow comparison of pointers to complete and incomplete types for C11 [PR95630]

). Implement that change by using pedwarn_c99 with OPT_Wpedantic for this diagnostic. Bootstrapped with no regressions for x86_64-pc-linux-gnu. Applied to mainline. gcc/c/ 2020-11-23 Joseph Myers PR c/95630 * c-typeck.c (build_binary_op): Use pedwarn_c99 with OPT_Wpedantic

Re: [C PATCH] Do not drop qualifiers for _Atomic in typeof

On Mon, 23 Nov 2020, Uecker, Martin wrote: > Joseph, > > here is the patch to not drop qualifiers for _Atomic in > typeof. I am not sure whether this is appropriate in > stage3, but I wanted to leave it here for you to comment > and so that it does not lost. > > First, I noticed that the change

Re: Add -std=c2x, -std=gnu2x, -Wc11-c2x-compat, C2X _Static_assert support

On Mon, 23 Nov 2020, Martin Liška wrote: > On 10/18/18 1:59 AM, Joseph Myers wrote: > > - || strcmp (language_string, "GNU C17") == 0) > > + || strcmp (language_string, "GNU C17") == 0 > > + || strcmp (language_string, &quo

Re: [C PATCH] Drop qualifiers during lvalue conversion

On Thu, 19 Nov 2020, Uecker, Martin wrote: > Apparently I did not have enough coffee when > generalizing this to the other qualifiers.  > > Ok, with the following test? OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [C PATCH] Drop qualifiers during lvalue conversion

On Thu, 19 Nov 2020, Uecker, Martin wrote: > Here is another version of the patch. The > only difference is the additional the check > using 'tree_ssa_useless_type_conversion'. The code changes in this one are OK. However, in the test: > +void f(void) > +{ > + const int j; > + typeof((0,j))

Re: [PATCH] options, lto: Optimize streaming of optimization nodes

On Wed, 18 Nov 2020, Jakub Jelinek via Gcc-patches wrote: > Hi! > > Reposting with self-contained description per Joseph's request: > > Honza mentioned that especially for the new param machinery, most of > streamed values are probably going to be the default values. Perhaps > somehow we could

Re: [PATCH] configury: --enable-link-serialization support

On Wed, 18 Nov 2020, Jakub Jelinek via Gcc-patches wrote: > Bootstrapped/regtested again last night on x86_64-linux and i686-linux, ok > for trunk? OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] plugins: Allow plugins to handle global_options changes

On Wed, 18 Nov 2020, Jakub Jelinek via Gcc-patches wrote: > On Wed, Nov 18, 2020 at 10:39:46AM +0100, Richard Biener wrote: > > We already have --{enable,disable}-plugin, so could remove it when > > those are not enabled. > > Here is a variant that does that: > > 2020-11-18 Jakub Jelinek >

Re: [PATCH] Practical Improvement to libgcc Complex Divide

On Tue, 8 Sep 2020, Patrick McGehearty via Gcc-patches wrote: > This project started with an investigation related to > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714. Study of Beebe[1] > provided an overview of past and recent practice for computing complex > divide. The current glibc

Re: [PATCH][driver] Don't add suffix for non-files

On Tue, 27 Oct 2020, Tamar Christina via Gcc-patches wrote: > Hi All, > > This patch fixes an issue where on systems that are > HAVE_TARGET_EXECUTABLE_SUFFIX the driver calls convert_filename in order to > add the suffix to the filename. However while it excludes `-` it doesn't > exclude the

Re: [C PATCH RFC] Drop qualifiers during lvalue conversion

On Sun, 15 Nov 2020, Uecker, Martin wrote: > > I think it might be safest to avoid doing any conversion in the case where  > > the value is still of array type at this point (C90 non-lvalue arrays). > > I added a test for arrays, but I am not sure what effect it has. > What would be C90

Ping^3 Re: float.h: C2x NaN and Inf macros

Ping^3. This patch is still pending review (the DFP sNaN followup has been approved). (The independent C2x patches and

Re: [PATCH][RFC] Make mingw-w64 printf/scanf attribute alias to ms_printf/ms_scanf only for C89

On Fri, 13 Nov 2020, Liu Hao via Gcc-patches wrote: > 在 2020/11/13 2:46, Joseph Myers 写道: > > I'd expect these patches to include updates to the gcc.dg/format/ms_*.c > > tests to reflect the changed semantics (or new tests there if some of the > > changes don't r

float.h: Handle C2x __STDC_WANT_IEC_60559_EXT__

not controlled by a feature test macro at all. Thus, add a check of __STDC_WANT_IEC_60559_EXT__ for CR_DECIMAL_DIG in float.h, the only case of this change relevant to GCC. Bootstrapped with no regressions for x86_64-pc-linux-gnu. OK to commit? gcc/ 2020-11-14 Joseph Myers * ginclude

c: C2x binary constants

. Bootstrapped with no regressions for x86_64-pc-linux-gnu. Applied to mainline. gcc/testsuite/ 2020-11-13 Joseph Myers * gcc.dg/binary-constants-2.c, gcc.dg/binary-constants-3.c, gcc.dg/system-binary-constants-1.c: Update expected diagnostics. * gcc.dg/c11-binary

float.h: C2x *_IS_IEC_60559 macros

tps://gcc.gnu.org/pipermail/gcc-patches/2020-October/557136.html> (pending review), there are no actual dependencies between the patches; new tests are named to avoid conflicts with the tests added in that patch. gcc/c-family/ 2020-11-13 Joseph Myers * c-cppbui

Re: [PATCH] C-Family, Objective-C : Implement Objective-C nullability Part 1 [PR90707].

On Thu, 12 Nov 2020, Iain Sandoe wrote: > OK for the C-family changes? OK. > +When @var{nullability kind} is @var{"unspecified"} or @var{0}, nothing is I think you mean @code or @samp for the second and third @var on this line, they look like literal code not metasyntactic variables.

c: C2x __has_c_attribute

the resulting pp-number in a #if expression, where long and int have the same set of values. Bootstrapped with no regressions for x86_64-pc-linux-gnu. Applied to mainline. gcc/ 2020-11-12 Joseph Myers * doc/cpp.texi (__has_attribute): Document when scopes are allowed for C

Re: [PATCH 1/3] C-family, Objective-C [1/3] : Implement Wobjc-root-class [PR77404].

On Thu, 12 Nov 2020, Iain Sandoe wrote: > OK for the c-family parts? OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH][RFC] Make mingw-w64 printf/scanf attribute alias to ms_printf/ms_scanf only for C89

I'd expect these patches to include updates to the gcc.dg/format/ms_*.c tests to reflect the changed semantics (or new tests there if some of the changes don't result in any failures in the existing tests). -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

On Wed, 11 Nov 2020, Jakub Jelinek via Gcc-patches wrote: > So indeed, 0x80 << 24 is UB in C99/C11 and C++98, unclear in C89 and > well defined in C++11 and later. I don't know if C2X is considering > mandating two's complement and making it well defined like C++20 did. C2x requires two's

Re: [PATCH] C-family : Add attribute 'unavailable'.

This patch seems to be missing documentation for the new attribute in extend.texi. -- Joseph S. Myers jos...@codesourcery.com

Re: [C PATCH RFC] Drop qualifiers during lvalue conversion

On Sat, 7 Nov 2020, Uecker, Martin wrote: > In 'gcc.dg/cond-constqual-1.c' we test for the opposite > behavior for conditional operators. I do not know why. > We could just invert the test. That's probably a relic of the old idea that rvalues might actually have qualified type in some cases; it

Ping^2 Re: float.h: C2x NaN and Inf macros

Ping^2. This patch is still pending review (the DFP sNaN followup has been approved). -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] mixing of labels and code in C2X

On Fri, 6 Nov 2020, Uecker, Martin wrote: > Am Freitag, den 06.11.2020, 22:07 + schrieb Joseph Myers: > > On Fri, 6 Nov 2020, Uecker, Martin wrote: > > > > > Hi Joseph, > > > > > > here is the revised patch. I remove the 'fallthrough' > >

Re: [PATCH] mixing of labels and code in C2X

On Fri, 6 Nov 2020, Uecker, Martin wrote: > Hi Joseph, > > here is the revised patch. I remove the 'fallthrough' > code as suggested, so everything becomes even simpler. > Some tests had to be changed then, but it seems Ok to > me. This patch is missing the new tests. > + *

Re: [PATCH] Objective-C/C++ (C-family) : Add missing 'atomic' property attribute.

On Fri, 6 Nov 2020, Iain Sandoe wrote: > Hi > > Arguably, this is actually a bug fix since the ‘atomic’ attribute is > paired with the ‘nonatomic’ one. However it is the default and was > omitted when the @property implementation was added. > > ‘atomic’ in Objective-C terms is not specified in

Re: [PATCH] Objective-C : Implement NSObject attribute.

On Fri, 6 Nov 2020, Iain Sandoe wrote: > Hi > > Originally, I had this as a Darwin-only patch, however GNUStep > also makes use of NSObject and similar constructs, so this really > needs to be available to linux-gnu as well. > > tested across several Darwin versions and on x86_64-linux-gnu. >

float.h: C2x decimal signaling NaN macros

tml> and <https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558126.html> (both pending review) applied. Bootstrapped with no regressions for x86_64-pc-linux-gnu. OK to commit? gcc/ 2020-11-05 Joseph Myers * ginclude/float.h (DEC32_SNAN, DEC64_SNAN, DEC128_SNAN): New C2x

builtins: Add DFP signaling NaN built-in functions

onfirm they do work in the case (hardware DFP) where floating-point exceptions are supported for DFP. OK to commit? gcc/ 2020-11-05 Joseph Myers * builtins.def (BUILT_IN_NANSD32, BUILT_IN_NANSD64) (BUILT_IN_NANSD128): New built-in functions. * fold-const-

Re: [PATCH v5] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

On Wed, 4 Nov 2020, Richard Biener wrote: > AFAICS you do nothing to marshall with the actually used libc > implementation which AFAIU can choose arbitrary values for > the FE_* macros. I'm not sure we require the compiler to be > configured for one specific C library and for example require >

Re: [PATCH v5] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

On Wed, 4 Nov 2020, Raoni Fassina Firmino via Gcc-patches wrote: > IMHO, It seems like it is not necessary if there not a libc that have > different values for the FE_* macros. I didn't check other archs, but if > is the case for some other arch I think it could be changed if and when > some

c: Implement C2x nodiscard attribute

C2x adds the nodiscard standard attribute, with an optional string argument, as in C++; implement it for C. Bootstrapped with no regressions for x86_64-pc-linux-gnu. Applied to mainline. gcc/c/ 2020-11-04 Joseph Myers * c-decl.c (handle_nodiscard_attribute): New

Re: [04/32] cpp lexer

On Tue, 3 Nov 2020, Nathan Sidwell wrote: > @@ -888,9 +915,9 @@ struct GTY(()) cpp_hashnode { >unsigned int directive_index : 7; /* If is_directive, > then index into directive table. > Otherwise, a

Re: PowerPC: Add __float128 conversions to/from Decimal

On Mon, 2 Nov 2020, Segher Boessenkool wrote: > > Also note that if you want to use printf as opposed to strfromf128 for > > IEEE binary128 you'll need to use __printfieee128 (the version that > > expects long double to be IEEE binary128) which was introduced in glibc > > 2.32, so that doesn't

Re: [PATCH] mixing of labels and code in C2X

On Sun, 1 Nov 2020, Uecker, Martin wrote: > @@ -5693,27 +5692,54 @@ c_parser_compound_statement_nostart (c_parser *parser) >     last_label = true; >     last_stmt = false; >     mark_valid_location_for_stdc_pragma (false); > -   c_parser_label (parser); > +   c_parser_label

Ping Re: float.h: C2x NaN and Inf macros

Ping. This patch is pending review. -- Joseph S. Myers jos...@codesourcery.com

Re: PowerPC: Add __float128 conversions to/from Decimal

On Thu, 29 Oct 2020, Segher Boessenkool wrote: > > Doing these conversions accurately is nontrivial. Converting via strings > > is the simple approach (i.e. the one that moves the complexity somewhere > > else). There are more complicated but more efficient approaches that can > > achieve

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

On Wed, 22 Jul 2020, Asher Gordon via Gcc-patches wrote: > Hello Joseph, Martin, > > Asher Gordon writes: > > > Joseph Myers writes: > > > >> I don't see you in the FSF copyright assignment list; could you > >> complete > >> https://git.s

Re: PowerPC: Add __float128 conversions to/from Decimal

On Thu, 29 Oct 2020, Segher Boessenkool wrote: > Hi! > > On Thu, Oct 29, 2020 at 12:45:15PM -0400, Michael Meissner wrote: > > On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote: > > > > +#if HAVE_KF_MODE > > > > + strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x); > > > >

stdbool.h: Update true and false expansions for C2x

that would introduce the new keywords. Bootstrapped with no regressions on x86_64-pc-linux-gnu. OK to commit? gcc/ 2020-10-28 Joseph Myers * ginclude/stdbool.c [__STDC_VERSION__ > 201710L] (true, false): Define with type _Bool. gcc/testsuite/ 2020-10-28 Joseph My

c: Allow omitted parameter names for C2x

that is disabled by -Wno-c11-c2x-compat. The logic for avoiding unused-parameter warnings for unnamed parameters is in code shared between C and C++, so no changes are needed there. Bootstrapped with no regressions for x86_64-pc-linux-gnu. Applied to mainline. gcc/c/ 2020-10-28 Joseph Myers

c: Allow duplicate C2x standard attributes

checking for this (standard attributes aren't in any released version of the C standard) and update tests accordingly. Bootstrapped with no regressions on x86_64-pc-linux-gnu. Applied to mainline. gcc/c/ 2020-10-27 Joseph Myers * c-parser.c (c_parser_std_attribute_specifier): Allow

Re: *PING^4* [PATCH] doc: gcc.c: Update documentation for spec files

First, as a general principle I don't think it's really a good idea to have the documentation for specs duplicated in two places. It would be better to have it in exactly one place, and so avoid having two copies getting out of sync in future. I'd say that specs are an internal implementation

float.h: C2x NaN and Inf macros

. Because uses #undef on all macros before defining them, even with -Wsystem-headers there could only ever be issues when is included after . Bootstrapped with no regressions on x86_64-pc-linux-gnu. OK to commit? gcc/ 2020-10-27 Joseph Myers * ginclude/float.h (INFINITY, NAN

Re: Fix fnspecs for math builtins

On Mon, 26 Oct 2020, Jan Hubicka wrote: > Hi, > this patch makes us to use ".C" and ".P" fnspecs where > applicable. I also noticed that gamma and variants are > declared as storing to memory while they are not (gamma_r does) I think the point is that they store to the global signgam. --

Re: [patch] Add an if-exists-then-else spec function

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

Re: [PATCH v3] c, c++: Implement -Wsizeof-array-div [PR91741]

The C parts are OK. -- Joseph S. Myers jos...@codesourcery.com

Re: Patch ping

On Thu, 22 Oct 2020, Jakub Jelinek via Gcc-patches wrote: > https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554804.html > - PR97164 - reject forming arrays with elt sizes not divisible by elt > alignment OK. > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556153.html > -

Re: [RFC] Automatic linking of libatomic via gcc.c or ...? [PR81358] (dependency for libgomp on nvptx dep, configure overriddable, ...)

On Thu, 15 Oct 2020, Tobias Burnus wrote: > Hi Joseph, hi Jakub, > > (a) For the driver route: > > On 10/15/20 12:22 AM, Joseph Myers wrote: > > I think it should be somewhere in the expansion of %(link_gcc_c_sequence) > > (i.e. LINK_GCC_C_SEQUENCE_SPEC, which

Re: [RFC] Automatic linking of libatomic via gcc.c or ...? [PR81358] (dependency for libgomp on nvptx dep, configure overriddable, ...)

On Wed, 14 Oct 2020, Tobias Burnus wrote: > Question: Where do you think should it be in the driver? I think it should be somewhere in the expansion of %(link_gcc_c_sequence) (i.e. LINK_GCC_C_SEQUENCE_SPEC, which has various target-specific definitions), since that's what expands to something

Re: [ Preprocessor ] [ Common ] Feature: Macros for identifying the wide and narrow execution string literal encoding

On Thu, 8 Oct 2020, JeanHeyd Meneide via Gcc-patches wrote: > * gcc/doc/cpp.texi: Document new predefined macro. This documentation doesn't seem sufficient to use the macros. Do they expand to (narrow) string literals? To an unquoted sequence of characters? I think from the

Re: [r11-3641 Regression] FAIL: gcc.dg/torture/pta-ptrarith-1.c -Os scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}" on Linux/x86_64 (-m32 -march=cascadelake)

On Sun, 4 Oct 2020, H.J. Lu via Gcc-patches wrote: > This email is generated by an automated script. Does GCC BZ have > an email gateway? Bugzilla has a REST API that you can use to interact with it via JSON messages over HTTP. contrib/mark_spam.py has an example to mark bugs as spam.

Re: [Patch] libgomp: Add, if existing, -latomic to libgomp.spec --as-needed (was: Re: [RFC] Offloading and automatic linking of libraries)

On Fri, 2 Oct 2020, Tobias Burnus wrote: > However, this flag can be added into the offload-target's libgomp.spec, > which avoids all kind of issues. That's what this patch now does. > > I tested it with x86_64-gnu-linux w/o + w/ nvptx-none. Result: > * x86_64-gnu-linux's libgomp.spec: >

Re: [PATCH 1/9] PowerPC: Map long double built-in functions if IEEE 128-bit long double.

On Thu, 24 Sep 2020, Michael Meissner via Gcc-patches wrote: > To map the math functions, typically this patch changes l to f128. > However there are some exceptions that are handled with this patch. glibc 2.32 added __*ieee128 names for the *f128 functions, to allow the long double functions

Re: [RFC] Offloading and automatic linking of libraries

On Thu, 24 Sep 2020, Tobias Burnus wrote: > Hi all, > > we got the user comment that it is far from obvious to > use -foffload=-latomic if the following error shows up: > > unresolved symbol __atomic_compare_exchange_16 > collect2: error: ld returned 1 exit status > mkoffload: fatal error:

Re: [PATCH V2 0/4] Unify C and C++ handling of loops and switches

On Thu, 17 Sep 2020, Jason Merrill via Gcc-patches wrote: > The C++ changes are OK. A C maintainer will need to sign off on the changes > there. The C front-end changes are OK. Note: for a long time there used to be actual (undesired) semantic differences between the C and C++ loop handling,

Re: [PING 2][PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

On Wed, 16 Sep 2020, Martin Sebor via Gcc-patches wrote: > Attached is an updated revision of the patch. Besides the tweaks > above it also contains a cosmetic change to the warning issued > for mismatches in unspecified VLA bounds: it points at the decl > with more of them to guide the user to

Re: [patch] Fix dangling references in thunks at -O0

This introduces an ICE building the glibc testsuite for alpha (bisected), s390 and sparc (symptoms appear the same, not bisected to confirm the exact revision). See bug 97078. -- Joseph S. Myers jos...@codesourcery.com

Re: Problem with static const objects and LTO

On Wed, 16 Sep 2020, Jeff Law via Gcc-patches wrote: > ISTM this is a lot like the problem we have where we inline functions > with static data.   To fix those we use STB_GNU_UNIQUE.  But I don't see > any code in the C front-end which would utilize STB_GNU_UNIQUE.  It's > support seems limited

Re: [PING][PATCH] improve validation of attribute arguments (PR c/78666)

On Wed, 9 Sep 2020, Martin Sebor via Gcc-patches wrote: > Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552500.html > > Aldy provided a bunch of comments on this patch but I'm still looking > for a formal approval. This patch is OK. > > Some testing revealed that the code has

Re: [PING 2][PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

On Wed, 9 Sep 2020, Martin Sebor via Gcc-patches wrote: > Joseph, do you have any concerns with or comments on the most > recent patch or is it okay as is? > > https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html I'm not yet convinced by the logic for extracting an array bound from

Re: [PATCH] c, c++: Implement -Wsizeof-array-div [PR91741]

On Mon, 14 Sep 2020, Marek Polacek via Gcc-patches wrote: > so I followed suit. In the C++ FE this was rather easy, because > finish_parenthesized_expr already set TREE_NO_WARNING. In the C FE > it was trickier; I've added a NOP_EXPR to discern between the non-() > and () versions. This sort

Re: [PATCH] mixing of labels and code in C2X

On Sun, 13 Sep 2020, Uecker, Martin wrote: > Hi Joseph, > > here is the (unfinished) patch to support > mixing of labels in C2X. I think there should be explicit tests for old standard versions (c11-labels-1.c etc.) that these usages are errors with -pedantic-errors with the old -std option,

Re: gcc git hook

On Thu, 10 Sep 2020, Nathan Sidwell wrote: > Is it possible for the git hooks to reject pushes with overly-long subject > lines? > > I occasionally see pushes that forgot to add a separate title line, and so the > whole of the commit description gets used. Is that where the whole description is

Re: [PATCH v1] [include] Add codes for DWARF v5 .dwp sections to dwarf2.h

On Wed, 9 Sep 2020, Caroline Tice via Gcc-patches wrote: > For DWARF v5 Dwarf Package Files (.dwp files), the section identifier > encodings have changed. This patch updates dwarf2.h to contain the new > encodings. (see http://dwarfstd.org/doc/DWARF5.pdf, section 7.3.5). > > This patch has

RE: [PING] floatformat.h: Add bfloat16 support.

On Tue, 8 Sep 2020, Willgerodt, Felix via Gcc-patches wrote: > Thanks for your review. It seems like the format issue was introduced by > my email client when hitting reply. Sorry for that! The original patch > is formatted correctly, as I used git send-email: >

Re: [PING] floatformat.h: Add bfloat16 support.

On Mon, 7 Sep 2020, Willgerodt, Felix via Gcc-patches wrote: > @@ -133,6 +133,9 @@ extern const struct floatformat > floatformat_ia64_quad_little; > /* IBM long double (double+double). */ extern const struct floatformat > floatformat_ibm_long_double_big; extern const struct floatformat >

Re: [PATCH] separate reading past the end from -Wstringop-overflow

On Tue, 1 Sep 2020, Jeff Law via Gcc-patches wrote: > > With this commit: > > https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553109.html > > the remaining failures should now be gone. Please let me know if > > any persist. > There's a related glibc build failure, but I think Joseph

Re: [PATCH] avoid erroneous argument types when checking built-in signatures (PR c/96596)

On Thu, 27 Aug 2020, Martin Sebor via Gcc-patches wrote: > The attached change has match_builtin_function_types() fail > for erroneous argument types to prevent an ICE due to assuming > they are necessarily valid. OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH 4/6] Add `+' for Jobserver Integration

On Thu, 20 Aug 2020, Giuliano Belinassi via Gcc-patches wrote: > libbacktrace/Makefile.in | 2 +- > zlib/Makefile.in | 64 ++-- These directories use makefiles generated by automake. Rather than modifying the generated files, you need to modify the sources (whether that's

Re: [PATCH] libgccjit: Fix several memory leaks in the driver

On Thu, 9 Jul 2020, Alex Coplan wrote: > 2020-07-09 Alex Coplan > > * gcc.c (set_static_spec): New. > (set_static_spec_owned): New. > (set_static_spec_shared): New. > (driver::maybe_putenv_COLLECT_LTO_WRAPPER): Use > set_static_spec_owned() to take ownership of

Re: [Patch] configure: Also check C++11 (flags) for ${build} compiler not only for ${host}

On Thu, 20 Aug 2020, Tobias Burnus wrote: > Thanks for the first review; new version attached. Thanks, this version is OK for GCC (but the GCC version will need updating if autoconf-archive ends up with a different version of these changes). -- Joseph S. Myers jos...@codesourcery.com

Re: [Patch] configure: Also check C++11 (flags) for ${build} compiler not only for ${host}

On Thu, 13 Aug 2020, Tobias Burnus wrote: > diff --git a/config/ax_cxx_compile_stdcxx.m4 b/config/ax_cxx_compile_stdcxx.m4 > index 9413da624d2..0cd515fc65b 100644 > --- a/config/ax_cxx_compile_stdcxx.m4 > +++ b/config/ax_cxx_compile_stdcxx.m4 > @@ -25,6 +25,10 @@ > # regardless, after defining

Re: [PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

On Wed, 19 Aug 2020, Martin Sebor via Gcc-patches wrote: > > I think you need a while loop there, not just an if, to account for the > > case of multiple consecutive cdk_attrs. At least the GNU attribute syntax > > > > direct-declarator: > > [...] > > ( gnu-attributes[opt] declarator

Re: [PATCH] middle-end: Fix PR middle-end/85811: Introduce tree_expr_maybe_nan_p et al.

On Mon, 17 Aug 2020, Segher Boessenkool wrote: > Ah, so "When both arguments are NaNs, the return value should be a qNaN" > means the QNaN corresponding to eother x or y. I see, thanks! Yes. (The precise choice of NaN result given a NaN input is the subject of various "should"s, in 6.2.3 NaN

Re: [PATCH] middle-end: Fix PR middle-end/85811: Introduce tree_expr_maybe_nan_p et al.

On Sat, 15 Aug 2020, Segher Boessenkool wrote: > Hi! > > On Sat, Aug 15, 2020 at 12:10:42PM +0100, Roger Sayle wrote: > > I'll quote Joseph Myers (many thanks) who describes things clearly as: > > > (a) When both arguments are NaNs, the return value should be a q

Re: [PATCH] c: Fix -Wunused-but-set-* warning with _Generic [PR96571]

On Fri, 14 Aug 2020, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The following testcase shows various problems with -Wunused-but-set* > warnings and _Generic construct. I think it is best to treat the selector > and the ignored expressions as (potentially) read, because when they are >

Re: [PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

On Thu, 13 Aug 2020, Martin Sebor via Gcc-patches wrote: > > * Maybe cdk_pointer is followed by cdk_attrs before cdk_id. In this case > > the code won't return. > > I think I see the problem you're pointing out (I just don't see how > to trigger it or test that it doesn't happen). If the tweak

Re: [PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

On Fri, 7 Aug 2020, Martin Sebor via Gcc-patches wrote: > > I don't see anything in the tests in this patch to cover this sort of case > > (arrays of pointers, including arrays of pointers to arrays etc.). > > I've added a few test cases and reworked the declarator parsing >

Re: [PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

On Thu, 6 Aug 2020, Maciej W. Rozycki via Gcc-patches wrote: > Given that for the `riscv64-linux-gnu' target and the ilp32d multilib > glibc currently fails to link against libgcc.a built at -O0 I first ran > reference testing with target libraries built at -O2, but comparing that > to

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

On Mon, 3 Aug 2020, Asher Gordon via Gcc-patches wrote: > Hello, > > Asher Gordon writes: > > > My copyright assignment finally got finished, so you should be able to > > apply my patches now. > > Is there any reason my patches haven't been applied yet? Is there > anything else I need to do?

Re: [PATCH] CSKY: Add -mfloat-abi= option.

My glibc bot is showing the build of libgcc for csky-linux-gnuabiv2 (configured --with-float=hard --disable-multilib) has recently broken, likely from this change. https://sourceware.org/pipermail/libc-testresults/2020q3/006566.html The errors are of the form: /tmp/cc7H0Zu7.s: Assembler

Re: [PATCH] c: Fix bogus vector initialisation error [PR96377]

On Fri, 31 Jul 2020, Richard Sandiford wrote: > Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu. > OK to instal? OK. -- Joseph S. Myers jos...@codesourcery.com

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

On Wed, 29 Jul 2020, Richard Biener wrote: > Note that any workable solution is fine with me, I just > don't feel comfortable approving the solution involving > ../curr_stage and friends. Joseph, would HJs latest > patch be OK technically? Yes, I think that's OK. -- Joseph S. Myers

Re: [PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

On Tue, 28 Jul 2020, Martin Sebor via Gcc-patches wrote: > + /* A list of VLA variable bounds or null if not specified. */ > + tree vbchain = NULL_TREE; > + if (parm->declarator->kind == cdk_array) > + if (pd->kind != cdk_array) > + break; > + /* Skip all constant

Re: [PATCH v3] genemit.c (main): split insn-emit.c for compiling parallelly

On Fri, 24 Jul 2020, Jojo R wrote: > + -csplit insn-$*.c /parallel\ compilation/ -k -s > {$(insn-generated-split-num)} -f insn-$* -b "%d.c" > + -( [ ! -s insn-$*0.c ] && for i in {1..$(insn-generated-split-num)}; do > touch insn-$*$$i.c; done && echo "" > insn-$*.c) Ignoring errors

Re: [PATCH 1/2] Add new RTX instruction class FILLER_INSN

New insn types should be documented in rtl.texi (I think in the "Insns" section). -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH PR96053] Add "#pragma GCC no_reduc_chain"

A new pragma needs to be documented in extend.texi. Such documentation should be comprehensible to users who don't know anything about the internals of GCC or other compilers, so that they can understand when it would be appropriate to use the pragma in their source code. -- Joseph S. Myers

Re: [committed] libstdc++: Add std::from_chars for floating-point types

On Tue, 21 Jul 2020, Jonathan Wakely via Gcc-patches wrote: > I also noticed some strings give an underflow error with glibc's > strtod, but are valid for the Microsoft implementation. For example, > this one: >

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 >

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