C2x adds a macro unreachable to stddef.h, with the same semantics as
__builtin_unreachable. Define this macro accordingly.
Bootstrapped with no regressions for x86_64-pc-linux-gnu. OK to commit?
gcc/
* ginclude/stddef.h [__STDC_VERSION__ > 201710L] (unreachable):
New macro.
C2x follows C++ in making alignas, alignof, bool, false,
static_assert, thread_local and true keywords; implement this
accordingly. This implementation makes them normal keywords in C2x
mode just like any other keyword (C2x leaves open the possibility of
implementation using predefined macros
ISO C2x removes trigraphs, so disable them accordingly for -std=c2x
(they can still be enabled using -trigraphs).
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
libcpp/
* init.cc (lang_defaults): Disable trigraphs for C2x.
gcc/testsuite/
*
On Fri, 2 Sep 2022, Richard Biener via Gcc-patches wrote:
> To catch these cases with a diagnostic earlier is
> -Wstrict-prototypes -Wold-style-declaration enough to diagnose all cases
> that the new standard will reject?
I think so.
> I suppose -W*-c2x-compat are not the correct vehicle to
C2x has completely removed unprototyped functions, so that () now
means the same as (void) in both function declarations and
definitions, where previously that change had been made for
definitions only. Implement this accordingly.
This is a change where GNU/Linux distribution builders might wish
On Thu, 1 Sep 2022, Aldy Hernandez via Gcc-patches wrote:
> Now that we keep track of the signbit, we can use it to fold
> __builtin_signbit.
>
> I am assuming I don't have try too hard to get the actual signbit
> number and 1 will do. Especially, since we're inconsistent in trunk whether
> we
Implement some changes to the currently supported C2x standard
attributes that have been made to the specification since they were
first implemented in GCC, and some consequent changes:
* maybe_unused is now supported on labels. In fact that was already
accidentally supported in GCC as a
On Wed, 31 Aug 2022, Qing Zhao wrote:
> >> When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member
> >> [] is treated as a valid flexible array) present together,
> >
> > That seems reasonable enough without a warning. If people want a warning
> > for flexible array members in
On Wed, 31 Aug 2022, Qing Zhao wrote:
> Does the above mean that -std=gnu89 does not support C99 flexible array
> member, then
No.
Flexible array members are supported by GCC in all C standards modes. The
C90 standard doesn't support them, but that's irrelevant to what GCC
supports; it just
On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
> > How is level 3 (thus -fstrict-flex-array) interpreted when you specify
> > -std=c89? How for -std=gnu89?
>
> 1. what’s the major difference between -std=c89 and -std=gnu89 on flexible
> array? (Checked online, cannot find a concrete
On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
> > "a GNU extension" suggests a particular language feature, but I think
> > you're actually referring here to a whole language version rather than an
> > individual feature.
>
> Is “not supported by GNU extension GNU89” better?
There are
On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
> > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
> >
> >> I was hoping Joseph would chime in here - I recollect debugging this kind
> >> of thing and a thread
On Tue, 30 Aug 2022, Qing Zhao via Gcc-patches wrote:
> Hi, Joseph and Nathan,
>
> Could you please review the C and C++ FE parts of the patch?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599901.html
I think some work is still needed on the diagnostic wording.
> + "%qE
On Mon, 29 Aug 2022, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
> > For convenience, singleton_p() returns false for a NAN. IMO, it makes
> > the implementation cleaner, but I'm not wed to the idea if someone
> > objects.
>
> If
On Sat, 27 Aug 2022, Jose E. Marchesi via Gcc-patches wrote:
> + if (metadata + 1 > data) /* { dg-warning "comparison of distinct pointer
> types" } */
> + if (metadata + 1 > data) /* { dg-warning "comparison of distinct pointer
> types" } */
> + if (metadata + 1 > data) /* There shouldn't
On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
> I was hoping Joseph would chime in here - I recollect debugging this kind
> of thing and a thread about this a while back but unfortunately I do not
> remember the details here (IIRC some things get included where they
> better should
I'm seeing build failures of glibc for powerpc64, as illustrated by the
following C code:
#if 0
\NARG
#endif
(the actual sysdeps/powerpc/powerpc64/sysdep.h code is inside #ifdef
__ASSEMBLER__).
This shows some problems with this feature - and with delimited escape
sequences - as it affects
On Thu, 25 Aug 2022, Marek Polacek via Gcc-patches wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
This version is OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, 25 Aug 2022, Jakub Jelinek via Gcc-patches wrote:
> > + && vec_safe_is_empty (CONSTRUCTOR_ELTS (*from_p)))
>
> Perhaps
> && CONSTRUCTOR_NELTS (*from_p) == 0)
> instead?
>
> > +{
> > +maybe_with_size_expr (from_p);
>
> The indentation above is 8 spaces instead of
[Middle-end maintainers / global reviewers, note that there is a
gimplify.cc change to be reviewed here.]
ISO C2x standardizes empty initializer braces {}. Implement this
feature accordingly. The basic case was already supported and so just
needed diagnostic adjustments. However, the standard
On Wed, 24 Aug 2022, Marek Polacek via Gcc-patches wrote:
> Ah, okay. I had just copied what we do in C++ in null_ptr_cst_p and the
> rest of the patch worked under that assumption. I've added some tests
> for this too. Except I don't really understand the _Generic comment so
> I only have
On Thu, 25 Aug 2022, Martin Liška wrote:
> * config.sub: Remove cr16.
config.sub and config.guess are imported verbatim from config.git; any
changes should go upstream first. Removal from config.sub would only be
appropriate if *no* GNU package wants to support cr16 any more.
--
On Thu, 25 Aug 2022, David Laight wrote:
> From: Joseph Myers
> > Sent: 25 August 2022 15:39
> >
> > On Thu, 25 Aug 2022, Linus Torvalds wrote:
> >
> > > That's a small detail that yes, we've tried to avoid the absolute
> > > humongous mess that the
On Thu, 25 Aug 2022, Linus Torvalds wrote:
> That's a small detail that yes, we've tried to avoid the absolute
> humongous mess that the C standard library has with their horrendous
> 'PRId*' mess, but honestly, it's just a tiny detail.
I've not yet implemented it for glibc or for GCC format
When an object of decimal floating-point type is default-initialized,
GCC is inconsistent about whether it is given the all-zero-bits
representation (zero with the least quantum exponent) or whether it
acts like a conversion of integer 0 to the DFP type (zero with quantum
exponent 0). In
On Tue, 23 Aug 2022, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Aug 16, 2022 at 11:41:06AM +, Richard Biener wrote:
> > I'm OK with the rest of the patch if Joseph doesn't have comments
> > on the actual issignaling lowerings (which I didn't review for
> > correctness due to lack of
ISO C2x standardizes the existing #warning extension. Arrange
accordingly for it not to be diagnosed with -std=c2x -pedantic, but to
be diagnosed with -Wc11-c2x-compat.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/testsuite/
* gcc.dg/cpp/c11-warning-1.c,
On Thu, 18 Aug 2022, Jose E. Marchesi via Gcc-patches wrote:
> diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
> index de8780a1502..04af02add37 100644
> --- a/gcc/c/c-typeck.cc
> +++ b/gcc/c/c-typeck.cc
> @@ -12397,7 +12397,8 @@ build_binary_op (location_t location, enum tree_code
> code,
>
On Tue, 16 Aug 2022, Lewis Hyatt via Gcc-patches wrote:
> For the first patch, I think it is a worthwhile goal to fix all the
> places where libcpp fails to support UTF-8 correctly, and this is one
> of two remaining ones that I'm aware of. I can fix the other case
> (handling of #pragma
On Tue, 16 Aug 2022, Kito Cheng wrote:
> ping
Under our write access policies, "Importing files maintained outside the
tree from their official versions." does not require review or approval.
--
Joseph S. Myers
jos...@codesourcery.com
On Sat, 13 Aug 2022, Marek Polacek via Gcc-patches wrote:
> This patch also defines nullptr_t in . I'm uncertain about
> the __STDC_VERSION__ version I should be checking. Also, I'm not
We're using defined (__STDC_VERSION__) && __STDC_VERSION__ > 201710L until
the final version for C23 is
On Thu, 11 Aug 2022, Michael Meissner via Gcc-patches wrote:
> In looking at it, I now believe that the type for _Float128 and __float128
> should always be the same within the compiler. Whether we would continue to
> use the same type for long double and _Float128/__float128 remains to be seen.
On Mon, 8 Aug 2022, Tom Honermann via Gcc-patches wrote:
> On 8/2/22 6:14 PM, Joseph Myers wrote:
> > On Tue, 2 Aug 2022, Tom Honermann via Gcc-patches wrote:
> >
> > > This patch corrects handling of UTF-8 character literals in preprocessing
> > > directives so
On Fri, 5 Aug 2022, Jose E. Marchesi via Gcc-patches wrote:
> +Wcompare-distinct-pointer-types
> +C C++ Var(warn_compare_distinct_pointer_types) Warning Init(1)
> +Warn if pointers of distinct types are compared without a cast.
There's no implementation for C++ in this patch, so the option
On Tue, 2 Aug 2022, Tom Honermann via Gcc-patches wrote:
> This patch corrects handling of UTF-8 character literals in preprocessing
> directives so that they are treated as unsigned types in char8_t enabled
> C++ modes (C++17 with -fchar8_t or C++20 without -fno-char8_t). Previously,
> UTF-8
On Tue, 2 Aug 2022, Tom Honermann via Gcc-patches wrote:
> This patch implements the core language and compiler dependent library
> changes adopted for C2X via WG14 N2653. The changes include:
> - Change of type for UTF-8 string literals from array of const char to
> array of const char8_t
On Mon, 1 Aug 2022, Tom Honermann via Gcc-patches wrote:
> This change provides new tests for the core language and compiler
> dependent library changes adopted for C2X via WG14 N2653.
Could you please send a complete patch series? I'm not sure what the
matching patches 1 and 3 are. Also, I
On Mon, 1 Aug 2022, Tom Honermann via Gcc-patches wrote:
> diff --git a/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
> b/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
> new file mode 100644
> index 000..3456105563a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
> @@
On Mon, 25 Jul 2022, Tom Honermann via Gcc-patches wrote:
> This change provides new tests for the core language and compiler
> dependent library changes adopted for C2X via WG14 N2653.
I'd expect this patch also to add tests verifying that u8"" strings have
the old type for C11 (unless there
On Mon, 25 Jul 2022, Tom Honermann via Gcc-patches wrote:
> diff --git a/gcc/ginclude/stdatomic.h b/gcc/ginclude/stdatomic.h
> index bfcfdf664c7..75ed7965689 100644
> --- a/gcc/ginclude/stdatomic.h
> +++ b/gcc/ginclude/stdatomic.h
> @@ -49,6 +49,10 @@ typedef _Atomic long atomic_long;
> typedef
On Sun, 24 Jul 2022, Tom Honermann via Gcc-patches wrote:
> Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
> (see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
> require that the target diagnostic option be enabled for the preprocessor
> (see
On Tue, 19 Jul 2022, Maciej W. Rozycki wrote:
> Our documentation indicates that it is the `-frounding-math' invocation
> option that controls whether we respect what the FENV_ACCESS pragma
> would imply, should we implement it, regarding the floating point
> environment. It is only a part of
On Mon, 11 Jul 2022, Lewis Hyatt via Gcc-patches wrote:
> Hello-
>
> As discussed here:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598136.html
>
> Here is another short patch that improves "#pragma GCC diagnostic" handling.
> Longer term, it will be desirable to make the handling of
On Thu, 7 Jul 2022, Kito Cheng wrote:
> +/* Implement TARGET_MANGLE_TYPE. */
> +
> +static const char *
> +riscv_mangle_type (const_tree type)
> +{
> + /* Half-precision float. */
> + if (TREE_CODE (type) == REAL_TYPE && TYPE_PRECISION (type) == 16)
> +return "Dh";
Are you sure you wish
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
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
This patch is OK.
--
Joseph S. Myers
jos...@codesourcery.com
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
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
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.
--
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.
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
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
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.
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
On Tue, 24 May 2022, Marek Polacek via Gcc-patches wrote:
> +
This actually looks like a mix of papers approved at the Oct 2020 meeting
and those approved at the Nov/Dec 2020 meeting, though I haven't checked
the lists in detail against those the minutes show as being approved as-is
or
On Tue, 24 May 2022, Marek Polacek via Gcc-patches wrote:
> I thought it'd be nice to have a table that documents our C support
> status, like we have https://gcc.gnu.org/projects/cxx-status.html for C++.
> We have https://gcc.gnu.org/c99status.html, but that's C99 only.
>
> So here's a patch to
On Thu, 19 May 2022, Christophe Lyon via Gcc-patches wrote:
> Hi Joseph,
>
> May I ping you on this version? (I've moved the tests to gcc.dg/torture/ and
> checked they work on aarch64 and x86_64.
This version is OK, given a bug report filed in Bugzilla for the
double-rounding issues with
On Wed, 18 May 2022, Marek Polacek via Gcc-patches wrote:
> I've extended the tests to use an enum with __attribute__ ((__packed__)) to
> test the case when the underlying type is (un)signed char. But it seems like
> we can't have underlying types wider than int. I've also included two tests
>
On Wed, 18 May 2022, Gaius Mulley via Gcc-patches wrote:
> /* This is the contribution to the `documented_lang_options' array in
>toplev.c for gm2. */
I'm not sure what this is (an unused file?), but documented_lang_options
was removed in 2003. And in general, comments referring to .c
On Wed, 18 May 2022, Marek Polacek via Gcc-patches wrote:
> diff --git a/gcc/testsuite/gcc.dg/Wenum-int-mismatch-1.c
> b/gcc/testsuite/gcc.dg/Wenum-int-mismatch-1.c
> new file mode 100644
> index 000..f71a308bc19
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/Wenum-int-mismatch-1.c
> @@
On Tue, 17 May 2022, Marek Polacek via Gcc-patches wrote:
> The C and C++ FEs differ in TYPE_VALUES for an enum type: an entry in
> the list in the C++ FE has a CONST_DECL in the TREE_VALUE, but the C FE
> has only the numerical value of the CONST_DECL there. This has caused
> me some trouble in
On Mon, 16 May 2022, Jason Merrill via Gcc-patches wrote:
> Ping.
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 13 May 2022, Christophe Lyon via Gcc-patches wrote:
> diff --git a/gcc/testsuite/gcc.target/aarch64/convert-dfp-2.c
> b/gcc/testsuite/gcc.target/aarch64/convert-dfp-2.c
I still think the tests should run for x86 as well - that is, for any
target supporting both DFP and _Float16 (with
On Wed, 11 May 2022, Martin Liška wrote:
> May I please ping review for this?
There are various coding style issues in the patch; at least missing space
before '(' and '&&' at end of line (should be at start of line). It will
also need to be updated for .c files having been renamed to .cc in
On Tue, 10 May 2022, Christophe Lyon via Gcc-patches wrote:
> > Note that for conversion from DFP to HFmode, double rounding (going via
> > SFmode) probably produces incorrectly rounded results in some cases
> > (though we already have such incorrect results in the other direction for
> > DPD;
On Mon, 9 May 2022, Christophe Lyon via Gcc-patches wrote:
> This patch adds support for trunc and extend operations between HF
> mode (__fp16) and Decimal Floating Point formats (_Decimal32,
> _Decimal64 and _Decimal128).
>
> For simplicity we rely on the implicit conversions inserted by the
>
If you add a new configure option, it should be documented in
install.texi.
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, 5 May 2022, Richard Biener via Gcc-patches wrote:
> MIN/MAX_EXPR shouldn't even appear with -fsignalling-nans for this
> reason, at least that's what I thought. But yes, you might have a point
> here (but maybe it's also not strictly enough specified). One option would
> be to do
On Mon, 2 May 2022, David Faust via Gcc-patches wrote:
> Consider the following example:
>
>#define __typetag1 __attribute__((btf_type_tag("tag1")))
>#define __typetag2 __attribute__((btf_type_tag("tag2")))
>#define __typetag3 __attribute__((btf_type_tag("tag3")))
>
>int
On Fri, 29 Apr 2022, Jason Merrill via Gcc-patches wrote:
> Marek pointed out elsewhere that the first testcase should have
>
> // { dg-additional-options -g }
>
> OK for 13 with that change?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, 28 Apr 2022, Palmer Dabbelt wrote:
> On Thu, 28 Apr 2022 15:12:39 PDT (-0700), jos...@codesourcery.com wrote:
> > On Thu, 28 Apr 2022, Palmer Dabbelt wrote:
> >
> > > +proc check_effective_target_fenv_setround {} {
> > > + return [check_runtime fenv_setround {
> > > +#include
> > >
On Thu, 28 Apr 2022, Palmer Dabbelt wrote:
> +proc check_effective_target_fenv_setround {} {
> + return [check_runtime fenv_setround {
> +#include
> +#include
> +int
> +main (void)
> +{
> + if (fesetround (1) == 0)
There is no reason to expect that 1 is a valid
On Thu, 28 Apr 2022, Richard Biener via Gcc-patches wrote:
> We are eventually ICEing in decimal_to_decnumber on non-decimal
> REAL_VALUE_TYPE that creep in from uses of build_real (..., dconst*)
> for DFP types. The following extends the decimal_to_decnumber
> special-casing of dconst* to
On Wed, 27 Apr 2022, Jason Merrill via Gcc-patches wrote:
> + if (typedef_variant_p (type))
> + {
> + /* Set up the typedef all over again. */
This seems wrong when the typedef is just being used in another
declaration with the mode attribute, as opposed to being defined using
On Wed, 27 Apr 2022, Richard Biener via Gcc-patches wrote:
> Is this the correct strathegy to deal with this problem? Would
> it be valid to just set ->is_decimal in build_real based on
Just setting ->decimal isn't correct; that signifies that ->sig stores the
number in decimal128 format
On Tue, 12 Apr 2022, Navid Rahimi via Gcc-patches wrote:
> Hi GCC community,
>
> I need to have ability to point to custom repository in gcc_release
> script. This small patch 1) does add a parameter "-g" to add custom
The purpose of this script is for building official GCC releases, release
On Mon, 4 Apr 2022, Martin Liška wrote:
> Ignore:
>
> Checking 86d8e0c0652ef5236a460b75c25e4f7093cc0651: FAILED
> ERR: line should start with a tab: "This reverts commits r12-7804 and
> r12-7929."
> ERR: could not deduce ChangeLog file
>
> It seems Jason pushed the revision to origin/trunk
On Wed, 30 Mar 2022, Thomas Schwinge wrote:
> > I don't think we want to support different help strings for
> > different languages; if an option is supported for multiple languages, we
> > should have a generic description of that option that is correct for all
> > of them.
>
> To not just bury
On Wed, 30 Mar 2022, Thomas Schwinge wrote:
> > --- gcc/optc-gen.awk (revision 187427)
> > +++ gcc/optc-gen.awk (working copy)
>
> > else if (help[i] != "" && help[i + 1] != help[i])
> > - print "warning: multiple different help strings for "
> > \
> > -
On Tue, 29 Mar 2022, Thomas Schwinge wrote:
> I'm generally very much in favor of abstracting functionality into
> separate functions. Here, however, there ever existed only one user of
> 'gcc/opt-functions.awk:lang_enabled_by', its interface is a bit clumsy,
> leading to (slightly) confusing
On Tue, 29 Mar 2022, Thomas Schwinge wrote:
> | --- gcc/c-family/c.opt
> | +++ gcc/c-family/c.opt
> | [...]
> | +Wc++11-extensions
> | +C++ ObjC++ Var(warn_cxx11_extensions) Warning LangEnabledBy(C++ ObjC++)
> Init(1)
> | +Warn about C++11 constructs in code compiled with an older standard.
> |
On Tue, 29 Mar 2022, Thomas Schwinge wrote:
> | --- gcc/c-family/c.opt
> | +++ gcc/c-family/c.opt
> | [...]
> | +# Defining these options here in addition to common.opt is necessary
> | +# in order for the default -Wall setting of -Wuse-after-free=2 to take
> | +# effect.
> | +
> |
On Tue, 29 Mar 2022, Thomas Schwinge wrote:
> | --- gcc/c-family/c.opt
> | +++ gcc/c-family/c.opt
> | [...]
> | Warray-bounds
> | -LangEnabledBy(C ObjC C++ LTO ObjC++,Wall)
> | +LangEnabledBy(C ObjC C++ LTO ObjC++)
> | ; in common.opt
> |
> | Warray-bounds=
>
> OK to push the attached
On Mon, 28 Mar 2022, Harald Anlauf via Gcc-patches wrote:
> Hi Tobias,
>
> sorry for replying to myself now, but
>
> Am 28.03.22 um 22:03 schrieb Harald Anlauf via Fortran:
> > All current cases of printing a HOST_WIDE_INT in gcc/fortran/ use
> > 'sprintf', and I did not find any other use of
Committed.
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 9cff81b9..689feeba 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -193,6 +193,27 @@ a work-in-progress.
+C
+
+ Some new features from the upcoming C2X revision of the ISO C
On Tue, 22 Mar 2022, Marek Polacek via Gcc-patches wrote:
> PR c/82283
> PR c/84685
>
> gcc/c/ChangeLog:
>
> * c-typeck.cc (struct initializer_stack): Add 'designated' member.
> (start_init): Set it.
> (finish_init): Restore constructor_designated.
>
On Wed, 16 Mar 2022, Roger Sayle wrote:
> This is Christophe Lyon's fix to PR c/98198, an ICE-on-invalid-code
> regression affecting mainline, and a suitable testcase.
> Tested on x86_64-pc-linux-gnu with make bootstrap and make -k check
> with no new failures. Ok for mainline?
>
>
>
On Fri, 11 Mar 2022, Krishna Narayanan via Gcc-patches wrote:
> Hello,
> The following is a patch for the PR92209,which gives a warning when
> the function prototype does not specify its argument type.In this
> patch there has been a change in the warning message displayed for
>
The version of this patch applied to GCC 10 branch (commit
641b407763ecfee5d4ac86d8ffe9eb1eeea5fd10) has broken the glibc build for
powerpc64le-linux-gnu (it's fine with GCC 11 branch and master, just GCC
10 branch is broken)
In commit cc806126215c3f4dc187eff3bf923458d8cc6b4f, I implemented
changes that C2x had made to compatibility of unprototyped and
prototyped function types.
C2x has since completely removed unprototyped function types, making
() in a function declaration mean (void) as in C++. While that change
This breaks the build of libgcc for powerpc-linux-gnu (32-bit, default
CPU; configured --disable-multilib --enable-secureplt).
cc1: warning: The '-mfloat128' option may not be fully supported
/tmp/ccHCPzSh.s: Assembler messages:
/tmp/ccHCPzSh.s:163: Error: unrecognized opcode: `lfiwzx'
On Thu, 24 Feb 2022, Marek Polacek via Gcc-patches wrote:
> gmp/mpfr/mpc/isl are DSOs I believe and therefore always PIC.
They are *not* DSOs when built in-tree (see the use of --disable-shared in
the relevant parts of Makefile.def).
> intl: I have no idea about this; I don't see any binaries
On Tue, 15 Feb 2022, Jonathan Wakely via Gcc-patches wrote:
> Tested powerpc64le-linux, OK for trunk?
>
> -- >8 --
>
> C++ allows unnamed parameters, which means we don't need to call them
> 'dummy' and mark them with the unused attribute.
>
> gcc/c-family/ChangeLog:
>
> * c-pragma.cc
The logic in libcpp/Makefile.in listing diagnostic functions in a call
to xgettext was missing cpp_warning_at, cpp_pedwarning_at and
cpp_error_at, so resulting in some messages not being extracted for
translation; add those functions to those for which messages are
extracted.
Tested with "make
The move of source files to .cc names broke most message extraction by
exgettext because it processed .c files with --language=GCC-source but
didn't process .cc files that way. Fix to process files identified as
C++ that way as well.
Tested with "make gcc.pot". Applied to mainline.
*
Some general observations:
* There are various toplevel GCC subdirectories that are built for the
host (possibly in addition to the target in some cases) but aren't changed
in this patch. Do they get a PIE or PIC build anyway by default? Such
directories include, I think: fixincludes (as a
On Wed, 9 Feb 2022, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The following testcase ICEs, because when creating PAREN_EXPR for
> __builtin_assoc_barrier the FE doesn't do the usual tweaks for
> EXCESS_PRECISION_EXPR or C_MAYBE_CONST_EXPR. I believe that the
> declared effect of the
On Tue, 8 Feb 2022, Richard Biener via Gcc-patches wrote:
> which I think is OK? That is, when the abstract machine
> arrives at 'int i;' then the previous content in 'i' goes
> away? Or would
Yes, that's correct. "If an initialization is specified for the object,
it is performed each time
On Fri, 4 Feb 2022, Richard Biener via Gcc-patches wrote:
> This adds explicit variable birth CLOBBERs in an attempt to fix
> PR90348 and duplicates. The birth / death CLOBBER pairs are
> used to compute liveness and conflicts for stack variable
> coalescing where the lack of an explicit birth
401 - 500 of 2624 matches
Mail list logo
