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: [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: [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] 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: 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 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: [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: 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: 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: [commited] [PR99378] LRA: Skip decomposing address for asm insn operand with unknown constraint

This introduced an ICE building glibc for i686. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422 https://sourceware.org/pipermail/libc-testresults/2021q1/007615.html -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH 2/3 V2] Do not include stdio.h in libgcc's Decimal/Float128 conversions.

On Wed, 3 Mar 2021, Michael Meissner via Gcc-patches wrote: > As we have discussed many times, on 32-bit BE, you cannot use hardware > _Float128 support on power9/power10 because there is no TImode in 32-bit. > Various machine independent parts of GCC require an integer type to be the > same > si

Re: [PATCH] c-family: Avoid ICE on va_arg [PR99324]

On Wed, 3 Mar 2021, Jakub Jelinek via Gcc-patches wrote: > Hi! > > build_va_arg calls the middle-end mark_addressable, which e.g. requires that > cfun is non-NULL. The following patch calls instead > c_common_mark_addressable_vec > which is the c-family variant similarly to the FE c_mark_addres

Re: [PATCH] Honor --disable-decimal-float in building _Float128 support.

On Fri, 26 Feb 2021, Michael Meissner via Gcc-patches wrote: > Joseph, does this patch fix your problem? Yes, this fixes the build without libc done by build-many-glibcs.py. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH, V2] Add conversions between _Float128 and Decimal.

On Wed, 24 Feb 2021, Segher Boessenkool wrote: > The other option, which we need for correctness *anyway*, is to have > libgcc do the conversion without using any specific libc. Which ends up being quite complicated (see e.g. https://www.cl.cam.ac.uk/~jrh13/papers/decimal.pdf for a more detailed

Re: [PATCH, V2] Add conversions between _Float128 and Decimal.

This change appears to have broken builds for powerpc in a configuration that bootstraps a cross toolchain starting with a GCC build with no libc available. Specifically, such a bootstrap build uses --disable-decimal-float among other options (in the first GCC build before libc has been built),

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

On Fri, 19 Feb 2021, Patrick McGehearty via Gcc-patches wrote: > > Here you're properly computing the mapping from mode to float.h macro > > prefix (though I think "modename" is a confusing name for the variable > > used for float.h macro prefixes; to me, "modename" suggests the names such > > as

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

On Tue, 2 Feb 2021, Patrick McGehearty via Gcc-patches wrote: > if (mode == TYPE_MODE (double_type_node)) > - ; /* Empty suffix correct. */ > + { > + ; /* Empty suffix correct. */ > + memcpy (modename, "DBL", 4); > + } > else if (mode =

Re: [PATCH] c: Fix ICE with -fexcess-precision=standard [PR99136]

On Thu, 18 Feb 2021, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The following testcase ICEs on i686-linux, because c_finish_return wraps > c_fully_folded retval back into EXCESS_PRECISION_EXPR, but when the function > return type is void, we don't call convert_for_assignment on it that would

Re: [PATCH] c, c++: Plug -Wduplicated-cond memory leaks [PR99057]

On Wed, 10 Feb 2021, Marek Polacek via Gcc-patches wrote: > Freeing the condition chain needs to use vec_free which does ->release, > or we leak memory. > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > gcc/c/ChangeLog: > > * c-parser.c (c_parser_if_statement): Use vec_

Re: [PATCH] mklog: automatically fill in generated entries

On Sun, 7 Feb 2021, Mike Frysinger via Gcc-patches wrote: > +# NB: Makefile.in isn't listed as it's not always generated. > +generated_files = {'aclocal.m4', 'config.h.in', 'configure'} libiberty/aclocal.m4 isn't a generated file either. -- Joseph S. Myers jos...@codesourcery.com

Add release notes for new C2X features in GCC 11

Binary constants aren't mentioned individually in this list because they are covered by the general wording about features previously supported as extensions. Allowing duplicate standard attributes isn't mentioned as it's considered a minor change of details of a feature supported in GCC 10, rathe

Re: [PATCH] improve detection of incompatible redeclarations (PR 97882)

On Thu, 4 Feb 2021, Martin Sebor via Gcc-patches wrote: > Okay, that's much simpler. Thanks for nudging me in the right > direction! How's the attached patch? Retested on x86_64-linux. OK, minus the addition of gcc/testsuite/c-c++-common/array-lit.s which looks like a mistake. -- Joseph S. M

Re: driver: error for nonexistent linker inputs [PR 98943]

On Thu, 4 Feb 2021, Nathan Sidwell wrote: > We used to check all unknown input files, even when passing them to a > compiler. But that caused problems. However, not erroring out on > non-existent would-be-linker inputs confuses configure machinery that > probes the compiler to see if it ac

Re: [PATCH] improve detection of incompatible redeclarations (PR 97882)

On Wed, 3 Feb 2021, Martin Sebor via Gcc-patches wrote: > +/* Return true of T1 and T2 are matching types for the purposes of > + redeclaring a variable or a function without a prototype (i.e., > + considering just its return type). */ I think this comment is confusing (it suggests it's chec

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

On Mon, 1 Feb 2021, Patrick McGehearty via Gcc-patches wrote: > The message which contains the attached gzipped tarball of the > development test programs is: > https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg254210.html > I'll include that link in the new patch as well. I think it's best

Re: [PATCH] varpool: Restore GENERIC TREE_READONLY automatic var optimization [PR7260]

On Tue, 26 Jan 2021, Richard Biener wrote: > If it is an initializer from constants we gimplify to a series of > assigns it might be still useful. OTOH, I'm not sure whether > a const auto is really readonly in C or if it is safe to assume > the stack part is writable and thus casting away the co

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

On Mon, 25 Jan 2021, Patrick McGehearty via Gcc-patches wrote: > Anyway, once I created the tarball and gzipped it, > I found it shrank to 100Kbytes. Rather than have further > delays, I've attached the gzip file to this email. Thanks. The next patch version can include the URL of this file in t

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

On Mon, 25 Jan 2021, Patrick McGehearty wrote: > On 1/21/2021 5:04 PM, Joseph Myers wrote: > > On Fri, 18 Dec 2020, Patrick McGehearty via Gcc-patches wrote: > > > > > TEST Data > > I'd still like to see the test data / code used to produce the accuracy > &g

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

On Fri, 18 Dec 2020, Patrick McGehearty via Gcc-patches wrote: > TEST Data I'd still like to see the test data / code used to produce the accuracy and performance results made available somewhere (presumably with a link then being provided in the commit message). > + if ((mode == TYPE_MO

Re: driver: do not check input file existence here [PR 98452]

On Thu, 21 Jan 2021, Nathan Sidwell wrote: > Do you want expandargv altered alongs the lines you mention? Or a bug filed? > [in order for my patch to be acceptable] The patch is OK as-is. Filing a bug for expandargv handling of missing files might be a good idea; it seems very arbitrary that @

Re: driver: do not check input file existence here [PR 98452]

On Wed, 20 Jan 2021, Nathan Sidwell wrote: > On 1/19/21 6:27 PM, Joseph Myers wrote: > > On Tue, 19 Jan 2021, Nathan Sidwell wrote: > > > > > Joseph, > > > I was relying on this patch on the modules branch, but didn't realize the > > > implications

Re: driver: do not check input file existence here [PR 98452]

On Tue, 19 Jan 2021, Nathan Sidwell wrote: > Joseph, > I was relying on this patch on the modules branch, but didn't realize the > implications when merging and thought it was just a cleanup. I'm not sure why > the driver wants to check here, rather than leave it to the compiler. Seems > optimiz

Re: [C PATCH] qualifiers of pointers to arrays in C2X [PR 98397]

On Sun, 17 Jan 2021, Uecker, Martin wrote: > I did not add tests for c11 for warnings because we already > had warnings before and the tests for these exist. (I removed  > -Wdiscarded-array-qualifiers from the old tests as this flag > is not needed.) Or should there be additional warnings > with -

Re: [PATCH] Hurd: Enable ifunc by default

On Wed, 13 Jan 2021, Thomas Schwinge wrote: > Hi! > > Thanks (and sorry for the delay), pushed "Hurd: Enable ifunc by default" > to master branch in commit e9cb89b936f831a02318d45fc4ddb06f7be55ae4, and > cherry-picked into releases/gcc-10 branch in commit > 92b131491c22eb4e4b663d226e9d97f1fd69306

Re: [PATCH 1/3] PowerPC: Add long double target-supports.

On Thu, 14 Jan 2021, Michael Meissner via Gcc-patches wrote: > +return [check_runtime_nocache ppc_long_double_ovveride_ibm128 { > +return [check_runtime_nocache ppc_long_double_ovveride_ieee128 { > +return [check_runtime_nocache ppc_long_double_ovveride_64bit { All these places have

Re: [patch] fix -Wformat-diag warnings in rs6000-call.c

On Tue, 12 Jan 2021, Segher Boessenkool wrote: > On Sat, Jan 09, 2021 at 07:44:31PM +0100, Matthias Klose wrote: > > These warnings, including the suggested fixes are seen on power*-linux > > builds. > > > > warning: misspelled term 'builtin function' in format; use 'bult-in > > function' > > i

Re: [PATCH] add g_nonstandard_bool attribute for GIMPLE FE use

On Tue, 5 Jan 2021, Richard Biener wrote: > would maybe result in a surprising result. One alternative > would be to make the attribute have the signedness specified as well > (C doesn't accept 'unsigned _Bool' or 'signed _Bool') or > simply name the attribute "signed_bool_precision". I guess th

Re: [C PATCH] [testsuite] bogus warning [P98029]

On Wed, 23 Dec 2020, Uecker, Martin wrote: > With the fix to PR98047 "C: Drop qualifiers of assignment expressions." > also the new incorrect warning for assignment of certain volatile expressions > introduced by dropping qualifiers in lvalue conversion (PR97702) > disappeared [P98029]. This patc

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

On Mon, 21 Dec 2020, Iain Sandoe wrote: > Hi Joseph, > > Nathan has approved this from the C++ perspective (and Martin said that his > comments were "not necessarily to object to the idea behind the attribute but > to draw attention to the fact that it's not suitable for standard APIs.”) > > So

Re: [C PATCH] qualifiers of pointers to arrays in C2X [PR 98397]

On Mon, 21 Dec 2020, Uecker, Martin wrote: > diff --git a/gcc/testsuite/gcc.dg/c2x-qual-1.c > b/gcc/testsuite/gcc.dg/c2x-qual-1.c > new file mode 100644 > index 000..058a840e04c > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/c2x-qual-1.c > @@ -0,0 +1,12 @@ > +/* Test that qualifiers are not

Re: V3 [PATCH 5/5] gnulib: Support variables from the top level Makefile

On Sat, 19 Dec 2020, H.J. Lu via Gcc-patches wrote: > Work around what appears to be a GNU make bug handling MAKEFLAGS > values defined in terms of make variables, as is the case for CC and > friends when we are called from the top level Makefile. This description, and the comment in Makefile.am

Re: [PATCH] maintainer-scripts: Prefer temp dir /sourceware/snapshot-tmp/gcc for update_version_git

On Tue, 15 Dec 2020, Jakub Jelinek via Gcc-patches wrote: > On Mon, Dec 14, 2020 at 11:58:05PM +0000, Joseph Myers wrote: > > > Thanks for heads up. I'm aware of it and I don't see reason why (running > > > the > > > update script in dry mode works)

Re: [PATCH] add g_nonstandard_bool attribute for GIMPLE FE use

On Sun, 13 Dec 2020, Martin Sebor via Gcc-patches wrote: > "nonstandard" isn't a very descriptive name. The leading g_ prefix > also looks a little too terse (is that supposed to stand dor GIMPLE?). > I would suggest choosing a better name, say, bool_precision. Since Indeed, g_ suggests the GLi

Re: [C PATCH] Avoid incorrect warning for volatile in compound expressions [PR 98260]

On Sun, 13 Dec 2020, Uecker, Martin wrote: > Here is a patch that fixes an incorrect warning for volatile > that appeared with the lvalue change.  > > > -- Martin > > C: Avoid incorrect warning for volatile in compound expressions [PR98260] OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [C PATCH] Drop qualifiers of assignment expressions [PR 97981]

On Sun, 13 Dec 2020, Uecker, Martin wrote: > Here is a patch to drop qualifiers in assignment expressions. > > -- Martin > > > > C: Drop qualifiers of assignment expressions. [PR98047] > > ISO C17 6.5.15.1 specifies that the result is the > type the LHS would have after lvalue conversion. OK

Re: [PATCH v5] Practical Improvement to libgcc Complex Divide

On Thu, 10 Dec 2020, Patrick McGehearty via Gcc-patches wrote: > Thank you for your rapid feedback. > I'll fix the various formatting issues (spaces in the wrong places > and such as well as revise the Changelog magic) in the next submission. I'll await a patch with the formatting issues fixed to

Re: [C PATCH] fix atomic loads [PR 97981]

On Sat, 5 Dec 2020, Uecker, Martin wrote: > I should have taken the new warning for > > _Atomic int y; > y; // warning statement with no effect > > as a tell-tale sign that something is wrong, > although I still think the warning would be > correct. Or has a atomic load some special > semantics

Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen3 CPU

On Fri, 4 Dec 2020, Richard Biener via Gcc-patches wrote: > Per rule changes to targets are allowed at any point per discretion of target > maintainers. Heck, we even accept _new_ targets during stage3/4! For architectures that are neither primary nor secondary targets, that's definitely the ca

Re: V3 [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions

On Wed, 2 Dec 2020, H.J. Lu via Gcc-patches wrote: > > Not sure if this is a GCC bug or indicates that glibc's libc_freeres_fn or > > related macros need to change to work with both old and new GCC. > > We may need to update glibc for GCC 11. Can you open a glibc bug and > CC me? https://source

Re: V3 [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions

This patch (GCC commit 6fbec038f7a7ddf29f074943611b53210d17c40c) has broken the glibc build (at least with current binutils master). The errors are of the form: In file included from : gconv_dl.c: In function 'free_mem': gconv_dl.c:202:18: error: 'free_mem' causes a section type conflict with

Re: [pushed] Darwin, D : Adjust the X spec to cater for duplicate use.

On Tue, 1 Dec 2020, Iain Sandoe wrote: > Joseph; I don’t know if you have any advice on a ‘better’ long-term > solution; in some ways I am surprised that the compiler built with > duplicate specifications for a flag - perhaps the uses merged in some > way. Since the use of ‘X’ in D is an upstream

preprocessor: Fix #line overflow check [PR97602]

an after it occurs (using essentially the same logic as used by e.g. glibc printf when reading width and precision values from strings). Bootstrapped with no regressions for x86_64-pc-linux-gnu. Applied to mainline. libcpp/ 2020-11-27 Joseph Myers PR preprocessor/97602

RE: [PATCH] fold-const: Don't consider NaN non-negative [PR97965]

On Thu, 26 Nov 2020, Roger Sayle wrote: > NaNs have a sign-bit, so copyexpr (and negate and ABS_EXPR) are > well-defined, and it's reasonable for nonnegative_p to reflect this. > IMHO, the true bug is that we can't fold away (any) comparisons against > NaN when flag_trapping_math, irrespective

Re: [PATCH] fold-const: Don't consider NaN non-negative [PR97965]

On Thu, 26 Nov 2020, Richard Biener wrote: > Is copysign (x, NaN) supposed to be well-defined? We'd stop folding copysign with NaN arguments (including sNaN) is well-defined and copies the sign bit without raising any exceptions. > this then, no? I think the ABS_EXPR < 0 to false folding is >

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

On Wed, 25 Nov 2020, Uecker, Martin wrote: > So OK to apply with the following Changelog? OK fixed as noted. > 2020-11-25  Martin Uecker   > > gcc/c/ Should mention the PR number in the ChangeLog entry (the part that will end up automatically added to the ChangeLog file), not just the

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

On Wed, 25 Nov 2020, Maciej W. Rozycki wrote: > For the other pieces that are missing perhaps my work I did many years > ago to port glibc 2.4 (the last one I was able to cook up without NPTL), > and specifically libm within, to the never-upstreamed VAX/Linux target > might be useful to comple

Re: [PATCH] unshare expressions in attribute arguments

On Fri, 20 Nov 2020, Martin Sebor via Gcc-patches wrote: > The VLA bounds are evaluated in function definitions so there > must be a point where that's done. I don't know where that > happens but unless at that point the most significant bound > is still associated with the param (AFAIK, it never

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)) i1

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 implem

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 nul

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 non-lvalu

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'

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

lt;https://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-c

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. Likewise

c: C2x __has_c_attribute

on of those macros, only to use 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 wh

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 comple

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. > + * gcc.dg/c11-label

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

136.html> 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 C

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 > ma

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 other

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 NODE_OPERATO

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 (p

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 cor

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://

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); > > > > +#e

stdbool.h: Update true and false expansions for C2x

WG14 at present 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-1

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):

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