On Sat, 6 Sep 2025, Martin Uecker wrote:
>
> This is the revised version adding the test to C_DECL_REGISTER.
> This meant I also had to change one place where it is set on
> function declarators before it becomes an error.
>
> Bootstrapped and regression tested on x86_64.
>
> Martin
>
>
>
On Thu, 11 Sep 2025, Alejandro Colomar wrote:
> Warn about this:
>
> void f(int x; int x; int x);
>
> This would allow eventually adding another semicolon in function
> prototypes to separate a different feature.
I don't think that's a plausible future addition. The small visual
differe
C2Y removes various instances of undefined behavior, typically making
them either constraint violations or implementation-defined.
In many but not all such cases, GCC's existing behavior is compatible
with the C2Y changes. For an initial batch of such cases, add
explicit tests for how GCC behaves
On Tue, 9 Sep 2025, Alejandro Colomar wrote:
> > I don't think we should support any of these. We tightened up various
> > cases of void in parameter lists in C2y (constraint "A parameter
> > declaration shall not specify a void type, except for the special case of
> > a single unnamed paramet
On Sat, 6 Sep 2025, Alejandro Colomar wrote:
> While this syntax is not standard, there's a certain degree of consensus
> within the C Committee that, if this was ever standardized, there's a
> preference to have a single list of forward declarations of parameters.
I think that's exaggerating con
On Thu, 4 Sep 2025, Martin Uecker wrote:
> This change adds a warning -Wuse-after-missed-init which is similar to
> -Wjump-misses-init but better supports idiomatic C code by emitting a
> diagnostic only when the variable is used somewhere after the label,
> e.g. no warning is emit
On Fri, 8 Aug 2025, Martin Uecker wrote:
> diff --git a/gcc/c/c-tree.h b/gcc/c/c-tree.h
> index bb0b113754e..372fcbd8aa1 100644
> --- a/gcc/c/c-tree.h
> +++ b/gcc/c/c-tree.h
> @@ -80,6 +80,11 @@ along with GCC; see the file COPYING3. If not see
> /* For a PARM_DECL, nonzero if it was declared as
On Thu, 21 Aug 2025, Joerg Boehmer wrote:
> diff --git a/libcpp/mkdeps.cc b/libcpp/mkdeps.cc
> index a4bea6e47d4..40fd5062a8a 100644
> --- a/libcpp/mkdeps.cc
> +++ b/libcpp/mkdeps.cc
> @@ -121,10 +121,11 @@ public:
> };
>
> /* Apply Make quoting to STR, TRAIL. Note that it's not possible to
>
On Fri, 5 Sep 2025, Jakub Jelinek wrote:
> Hi!
>
> I've noticed a lot of diagnostic messages in the C FE aren't marked
> for translation.
> The reason is some weird coding style which wraps the string
> literals into (), especially when they don't fit on a single line.
> With that fixed, there we
On Mon, 11 Aug 2025, mmalcom...@nvidia.com wrote:
> + /* Ensure that this doesn't get optimised out of the COMPOUND_EXPR we
> + * define below. It appears on first glance that the fact the
> + * initialisation argument is a function call would mean this
> + * automatically
On Wed, 3 Sep 2025, Alejandro Colomar wrote:
> Hi Joseph,
>
> On Wed, Sep 03, 2025 at 03:44:28PM +0000, Joseph Myers wrote:
> > On Wed, 3 Sep 2025, Alejandro Colomar wrote:
> >
> > > Hi Joseph,
> > >
> > > I'd like to ping about this thread.
On Mon, 11 Aug 2025, mmalcom...@nvidia.com wrote:
> diff --git a/libatomic/cas_n.c b/libatomic/cas_n.c
> index d75c2ea5b99..d1e27fbd4e2 100644
> --- a/libatomic/cas_n.c
> +++ b/libatomic/cas_n.c
> @@ -29,7 +29,7 @@
> /* If we support the builtin, just use it. */
> #if !DONE && defined(atomic_co
On Mon, 11 Aug 2025, mmalcom...@nvidia.com wrote:
> It is somewhat unfortunate that there are some targets which have a type
> available behind a command line flag. I do not know how to generally
> test for this in the configure scripts for libatomic. While it seems
> possible to record the know
On Wed, 13 Aug 2025, Aleksandar Rakic wrote:
> From: Aleksandar Rakic
>
> This patch applies the previously introduced --with-multi-buildlist
> mechanism to the MIPS target.
Actually, this patch appears to contain lots of the target-independent
parts of the feature as well. The division into
On Tue, 19 Aug 2025, Martin Uecker wrote:
> +/* Record a forbidden or possibly unsafe jump of type JTYPE from
> + GOTO_LOC to LABEL at LABEL_LOC skipping initialization of DECL. */
> +
> +static void warn_about_jump(enum jump_type jtype, location_t goto_loc,
> + location
On Wed, 3 Sep 2025, Alejandro Colomar wrote:
> Hi Joseph,
>
> I'd like to ping about this thread.
As far as I know, nothing has been resolved about the semantics (and then
associated documentation and testcases) in the case of parameter forward
declarations where multiple declarations for a pa
On Mon, 1 Sep 2025, Jakub Jelinek wrote:
> Hi!
>
> The following patch implements the
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3457.htm
> paper without the first 3 lines in Recommended practice.
> Seems GCC behavior already matches the expected behavior except for
> diagnostics of more
On Thu, 28 Aug 2025, alfie.richa...@arm.com wrote:
> @@ -3373,6 +3406,56 @@ pushdecl (tree x)
> TREE_TYPE (b_use->decl) = b_use->u.type;
> }
> }
> +
> + /* Check if x is part of a FMV set with b_use. */
> + if (b_use && TREE_CODE (b_use->decl) == FUNCTION_D
On Mon, 1 Sep 2025, Jakub Jelinek wrote:
> Hi!
>
> The following patch implements
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3577.txt
> No big deal on the GCC side, for uimaxabs we just won't
> recognize it as builtin and I don't see it worth preserving
> __builtin_uimaxabs, I doubt anyt
On Sun, 10 Aug 2025, Prathamesh Kulkarni wrote:
> Hi Matthew,
> Thanks for the suggestions! In the attached patch, I have modified
> libatomic/configure.ac to use
> __libatomic_save_CFLAGS__ instead of save_CFLAGS, so it isn't (accidentally)
> modified by ACX_PROG_CC_WARNING_OPTS.
>
> The patch
On Fri, 22 Aug 2025, David Faust wrote:
> +{
> + /* Treat btf_type_tag applied to a function type as applying to the
> + return type instead. Otherwise with GNU syntax there is no way to
> + apply type_tag to the return type; the parser always associates it
> + to the func
On Wed, 28 May 2025, Trevor Gross wrote:
> Documentation for `__cmpsf2` and similar functions currently indicate a
> return type of `int`. This is not correct however; the `libgcc`
> functions return `CMPtype`, the size of which is determined by the
> `libgcc_cmp_return` mode.
>
> Update document
On Thu, 28 Aug 2025, Sam James wrote:
> Joseph Myers writes:
>
> > On Thu, 28 Aug 2025, Richard Biener wrote:
> >
> >> I wonder if we can piggy-back on the existing --with-glibc-version=...
> >> somehow?
> >
> > Indeed, that's
On Thu, 28 Aug 2025, Richard Biener wrote:
> I wonder if we can piggy-back on the existing --with-glibc-version=...
> somehow?
Indeed, that's the correct way to handle such features so that cross
compilers default to the same correct configuration as native.
The configure tests in this patch u
On Tue, 26 Aug 2025, Anna (navi) Figueiredo Gomes wrote:
> this is similar to the failure test `i ()` in gcc/testsuite/gcc.dg/defer-2.c,
> and the technical specification covers such case:
>
> > 6.4:
> > Constraints:
> > Jumps by means of goto in E shall not jump over a defer statement in E.
There has been a significant discussion on the reflector in the past few
days concerning jumping backwards across a defer block within a scope.
How do you handle this case, what is the rationale for the decisions made
about that case, and are there appropriate testcases for it included?
int v
On Thu, 21 Aug 2025, Pietro Monteiro wrote:
> Both GCC and binutils/gdb trees do not use any of the macros defined
> in these files. Removing them from both trees and regenerating the
> build scripts results in no diff.
Can you confirm they're also not used in newlib-cygwin, the other tree
shar
On Thu, 21 Aug 2025, David Faust wrote:
> Hi Joseph,
>
> On 8/20/25 15:49, Joseph Myers wrote:
> > On Tue, 12 Aug 2025, David Faust wrote:
> >
> >> + if (TREE_CODE (*node) == FUNCTION_TYPE || TREE_CODE (*node) ==
> >> METHOD_TYPE)
> >> +
On Thu, 21 Aug 2025, Andrew Pinski wrote:
> The middle-end does not fully understand NULLPTR_TYPE. So it
> gets confused a lot of the time when dealing with it.
> This adds the folding that is similarly done in the C++ front-end already.
> In some cases it should produce slightly better code as th
On Tue, 12 Aug 2025, David Faust wrote:
> + if (TREE_CODE (*node) == FUNCTION_TYPE || TREE_CODE (*node) == METHOD_TYPE)
> +{
> + /* Treat btf_type_tag applied to a function type as applying to the
> + return type instead. Otherwise with GNU syntax there is no way to
> + apply
On Fri, 15 Aug 2025, Alejandro Colomar wrote:
> Hi Joseph,
>
> On Thu, Aug 14, 2025 at 10:03:00PM +0000, Joseph Myers wrote:
> > On Thu, 14 Aug 2025, Alejandro Colomar wrote:
> >
> > > And I'm proposing it as a GNU extension, which means we don't even
On Thu, 14 Aug 2025, Alejandro Colomar wrote:
> And I'm proposing it as a GNU extension, which means we don't even need
> to care about what ISO C says about [n]. We, as a quality
> implementation, treat it with stronger semantics, which this patch uses.
As a GNU extension, it's also necessary t
We'd need standard wording that's gone through several rounds of review in
WG14 before there's a reasonable basis for reviewing such a patch, given
how it's based on a very different conceptual model to how array
parameters are currently handled in the C standard. (And as noted on the
reflecto
On Mon, 11 Aug 2025, Bill Wendling wrote:
> On Thu, Jul 31, 2025 at 12:01 PM Joseph Myers wrote:
> >
> > On Thu, 24 Jul 2025, Aaron Ballman wrote:
> >
> > > Question on the .N syntax: I thought I heard that this was something
> > > GCC could handle, but
On Fri, 1 Aug 2025, Qing Zhao wrote:
> + /* For a poiner array address as:
"poiner" should be "pointer".
OK with that fix, in the absence of objections within the next week from
other maintainers or reviewers.
--
Joseph S. Myers
josmy...@redhat.com
On Thu, 7 Aug 2025, John Ericson wrote:
> The VPATH workaround however is akin to:
>
> mkdir -p $build/mach0/mach1/libgcc
> cd $build/mach0/mach1/libgcc
> ln -s $gcc_source/libgcc/* ./
> ./configure
>
> and it's that --- using the build dir with the symlinked sources inside
> as the src/obj dir
On Fri, 1 Aug 2025, Qing Zhao wrote:
> Currently, we generate a call to a .ACCESS_WITH_SIZE for a FAM with counted_by
> attribute for every component_ref that corresponds to such an object.
> Actually, such .ACCESS_WITH_SIZE calls are useless when they are generated
> for a written site or an addr
On Fri, 1 Aug 2025, Qing Zhao wrote:
> gcc/c-family/ChangeLog:
>
> * c-attribs.cc (handle_counted_by_attribute): Accept counted_by
> attribute for pointer fields.
>
> gcc/c/ChangeLog:
>
> * c-decl.cc (verify_counted_by_attribute): Change the 2nd argument
> to a vector of
On Thu, 7 Aug 2025, David Faust wrote:
> Changes from v6:
> - Patch 1: Check for and reject wide string arguments in the attribute
>handlers. Factor common argument checking shared by both attribute
>handlers to a small helper.
I think there should be testcases for this error (with L",
On Thu, 7 Aug 2025, John Ericson wrote:
> I think upon further reflection, I have a slightly different read of
> what's going on.
>
> See also https://gcc.gnu.org/legacy-ml/gcc/2005-07/msg00236.html /
> https://www.airs.com/ian/configure/configure_8.html (rendering of
> since-deleted from the
On Wed, 6 Aug 2025, David Faust wrote:
> So IMO the best option will be to reject wide strings in the attribute
> handler. (The alternative, I guess, is to ensure the argument is
> always exported to UTF-8 before being written (?))
>
> I see that we can get the character size from the TREE_TYPE
On Wed, 6 Aug 2025, Jakub Jelinek wrote:
> On Tue, Aug 05, 2025 at 03:52:12PM -0700, Jason Merrill wrote:
> > Hmm, the names in "Table 4"
> > https://eel.is/c++draft/lex.name#tab:lex.name.special are also
> > context-sensitive. I agree with ignoring the ObjC keywords because they
> > aren't part
On Wed, 6 Aug 2025, John Ericson wrote:
> I can't quite tell, but I have a nagging suspicion that this is unused.
> It would be nice to simplify some of the multilib stuff, and the
> complexity around source directory (rather than build directory)
> handling seems like it ought not to be so necess
On Tue, 5 Aug 2025, John Ericson wrote:
> > That's unavoidable to some extent, given that the GCC libraries have
> > additional concepts for installation directories (such as a directory for
> > shared libgcc used at runtime separate from directories used at compile
> > time).
>
> What's the r
On Tue, 5 Aug 2025, Yuao Ma wrote:
> On 8/5/2025 4:05 AM, Joseph Myers wrote:
> > On Sun, 3 Aug 2025, Yuao Ma wrote:
> >
> > > By the way, could you please take another look at the libquadmath update?
> > >
> > > https://inbox.sourceware.org/for
On Mon, 4 Aug 2025, Anna (navi) Figueiredo Gomes wrote:
> On Mon Aug 4, 2025 at 9:49 PM CEST, Joseph Myers wrote:
> > On Sun, 3 Aug 2025, Anna (navi) Figueiredo Gomes wrote:
> >
> >> based on n3589[1], this feature mostly makes use of already-established
> >> l
On Mon, 4 Aug 2025, David Faust wrote:
> Hi Joseph,
>
> Could you please take a look at the front-end portion of this
> series when you have a moment?
>
> New attributes/handlers - Patch 1:
> https://gcc.gnu.org/pipermail/gcc-patches/2025-July/690142.html
It looks like the front-end code wou
On Sun, 3 Aug 2025, Yuao Ma wrote:
> By the way, could you please take another look at the libquadmath update?
>
> https://inbox.sourceware.org/fortran/kl1pr0601mb4291e1457dc09fe3aa6652c884...@kl1pr0601mb4291.apcprd06.prod.outlook.com/
>
> This update uses a script to transform glibc's implement
On Sun, 3 Aug 2025, John Ericson wrote:
> > and "get those settings passed down from top level" is one plausible
> > end state - sharing logic implicitly that way rather than expanding it
> > all locally in each target library configure script, even if expanding
> > it locally for each library
On Sun, 3 Aug 2025, Anna (navi) Figueiredo Gomes wrote:
> based on n3589[1], this feature mostly makes use of already-established
> logic, namely push_cleanup used by the cleanup attribute, and the
> constraints put in place for checking local jumps against statement
> expressions
>
> 1: https://
On Sat, 2 Aug 2025, Martin Uecker wrote:
> In preparation N3652, this removes some UB from the conditional
> operator when forming a composite type. This is an improvement
> also for earlier language modes (previously I submitted PR108931
> for this).
>
> Bootstrapped and regression tested on x8
On Thu, 24 Jul 2025, Alexandre Oliva wrote:
> hardbools didn't behave quite like bools when incremented,
> decremented, or otherwise modified using their previous value, as in
> += et al. Fix that.
>
> Also fix some checking errors that come up when using qualified base
> types.
>
> Regstrapped
On Sun, 27 Jul 2025, Martin Uecker wrote:
> gcc/c/ChangeLog:
> * c/c-decl.cc (get_parm_array_spec): Remove.
> (push_parm_decl): Do not add `arg spec` attribute.
> (build_arg_spec_attribute): New function.
> (grokdeklarator): Add `arg spec` attrib
On Thu, 17 Jul 2025, John Ericson wrote:
> This current patch doesn't go as far as removing all such subdir logic
> from the libgcc build --- rather, as an intermediate goal, it moves it
> out of the Makefiles and into the configure script. That is to say, in
> the makefiles there is no longer any
On Wed, 30 Jul 2025, John Ericson wrote:
> This macro deduplicates the
>
> $CC -v 2>&1 | sed -n 's/^Thread model: //p'
>
> check that was occurring in various runtime libs.
>
> Additionally, as a bit of an Easter egg, this also allows overriding
> what the compiler would return by setting t
On Wed, 30 Jul 2025, John Ericson wrote:
> My goal is to be able to build libgcc cleanly in isolation --- today one
> needs to figure `make ...` misc things in the gcc subdir.
>
> Following Andrew Pinski's suggestions in
> https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, this
> co
On Tue, 29 Jul 2025, Martin Uecker wrote:
> Fixes an ICE on invalid code (15/16 regression).
>
> Bootstrapped and regression tested on x86_64.
>
>
> c: Fix ICE on invalid code involving bit fields [PR121217]
>
> Under some error condition we can end up with NULL_TREEs for
> the
On Thu, 24 Jul 2025, Aaron Ballman wrote:
> Question on the .N syntax: I thought I heard that this was something
> GCC could handle, but that it still requires late parsing to ensure
> type information for N is available and that was a problem. e.g.,
>
> void func(char *buffer __counted_by(.N * s
On Wed, 23 Jul 2025, Aleksandar Rakic wrote:
> Public
>
> Hi,
>
> > So I'm not at all concerned about the mips specific bits of this patch.
> > After all, they only affect mips ports and the changes seem sensible.
> > They would need a ChangeLog entry to go forward through.
>
> > What is concer
On Thu, 17 Jul 2025, Simon Marchi wrote:
> On 6/26/25 12:14 PM, Simon Marchi wrote:
> > I keep hitting the bug fixed by this patch with gcc 15.1:
> >
> > make[3]: Entering directory
> > '/home/simark/build/binutils-gdb-all-targets/sim'
> > CC bfin/gui.o
> > In file included from /usr/inc
On Wed, 16 Jul 2025, John Ericson wrote:
> From: John Ericson
>
> Following Andrew Pinski's suggestions in
> https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, just
> use the output of:
>
>$(CC) -print-sysroot
>
> It is just used in one spot, in an AIX code-path. I just made
On Wed, 16 Jul 2025, John Ericson wrote:
> gcc/ChangeLog:
>
> * Makefile.in:: Remove NO_PIE_CFLAGS logic, since it is now in
> libgcc.
> * configure.ac: Remove the enable_default_pie substitution, since
> libgcc now has its own logic.
>
> libgcc/ChangeLog:
>
> * Ma
On Wed, 16 Jul 2025, John Ericson wrote:
> config/ChangeLog:
>
> * gthr.m4: Create new GCC_AC_THREAD_MODEL macro
>
> libatomic/ChangeLog:
>
> * configure.ac: Use GCC_AC_THREAD_MODEL instead of hand-rolled
>
> libgcc/ChangeLog:
>
> * configure.ac: Use GCC_AC_THREAD_MODEL inst
On Tue, 15 Jul 2025, Ijaz, Abdul B wrote:
> config/ChangeLog:
>
> * lib-link.m4: Handle dash in the library name for
> AC_LIB_LINKFLAGS_BODY.
OK.
--
Joseph S. Myers
josmy...@redhat.com
On Sun, 6 Jul 2025, Yuao Ma wrote:
> +#ifndef HAVE_COSPI
> +#define HAVE_COSPI 1
> +double cospi (double);
> +
> +double
> +cospi (double x)
> +{
> + return cos (x * pihi_d + x * pilo_d);
For reasonable results for large x you should first reduce mod 2 to the
range [-1, 1] (or reduce mod 1 and
On Wed, 23 Jul 2025, Martin Uecker wrote:
> IMHO there are enough reasons to reject delayed parsing
> as bad design for C. We should work towards proper
> language features that cleanly fit into the language,
> instead of pushing the boundaries with macros.
At the last WG14 meeting it was said t
On Thu, 3 Jul 2025, Michael Matz wrote:
> Yes. And then the above is multiplied by PI, passed to cos/sin and that
> one then tries to figure out the multiple of PI (i.e. the 'x' above) again
> via range reduction (not a _terribly_ slow one anymore in a good
> implementation, because of the lim
On Thu, 3 Jul 2025, Jakub Jelinek wrote:
> > Isn't the whole raison d'etre for the trig-pi functions that the internal
> > argument reduction against multiples of pi becomes trivial and hence (a)
> > performant, and (b) doesn't introduce rounding artifacts? Expressing the
> > trig-pi functions
On Sat, 28 Jun 2025, Jason Merrill wrote:
> + if (!flag_use_cxa_atexit != !DEFAULT_USE_CXA_ATEXIT)
> +{
> + const char *opt, *copt;
> + if (flag_use_cxa_atexit)
> + opt = "-fuse-cxa-atexit", copt = "--enable-__cxa_atexit";
> + else
> + opt = "-fno-use-cxa-atexit", copt
On Fri, 27 Jun 2025, Richard Biener wrote:
> > I think such a warning should be based on an attribute on the time_t type
> > that means "warn for implicit truncation of this type" (I'm less clear on
> > why warnings for implicit widening conversions *to* time_t are supposed to
> > be useful), r
On Thu, 26 Jun 2025, Richard Biener wrote:
> The following prototypes diagnostics for conversions to/from time_t
> where the source/destination does not have sufficient precision for it.
> I've lumped this into -Wconversion for the moment and didn't bother
> fixing up the testcase for !ilp32 or th
On Mon, 23 Jun 2025, Marek Polacek wrote:
> Thanks for the review. Ok?
OK.
--
Joseph S. Myers
josmy...@redhat.com
On Mon, 23 Jun 2025, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping some C family patches:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681741.html
> - PR44677 - c, c++: Extend -Wunused-but-set-* warnings
>
> https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685543.html
> - P
On Fri, 13 Jun 2025, Marek Polacek wrote:
> doesn't need any changes, I think. Another is "modified existing functions
> to preserve the const-ness of the type placed into the function", I don't
> what this is talking about.
It's a duplicate of the entry "added qualifier preserving macros for
b
On Wed, 18 Jun 2025, Gábor Németh wrote:
> > If normal user code that includes gets this warning (built with
> > an installed compiler), that needs fixing in some way. If not, what is
> > different about how GCC uses its own libstdc++? (For example, it's
> > important to include system headers
On Mon, 16 Jun 2025, Qing Zhao wrote:
> Current array bound checker only instruments ARRAY_REF, and the INDEX
> information is the 2nd operand of the ARRAY_REF.
>
> When extending the array bound checker to pointer references with
> counted_by attributes, the hardest part is to get the INDEX of t
On Mon, 16 Jun 2025, Qing Zhao wrote:
> +The counted_by attribute is not allowed for a pointer to @code{void},
@code{counted_by}.
This patch is OK with that fix once the rest of this series is approved.
--
Joseph S. Myers
josmy...@redhat.com
On Wed, 18 Jun 2025, Alfie Richards wrote:
> gcc/c-family/ChangeLog:
>
> * c-format.cc (local_string_slice_node): New node type.
> (asm_fprintf_char_table): New entry.
> (init_dynamic_diag_info): Add support for string_slice.
> * c-format.h (T_STRING_SLICE): New node type.
On Fri, 13 Jun 2025, Pietro Monteiro wrote:
> > Adding this \ at end of file looks suspect.
> >
> > OK with that ChangeLog entry fixed and the stray \ at end of file removed
> > (assuming the same output files are still generated after that change).
>
> I applied the patch on top of trunk (), re
On Wed, 21 May 2025, Pietro Monteiro wrote:
> lto-plugin/ChangeLog:
>
> * configure: Regenerate.
> * configure.ac: Replace AC_CANONICAL_SYSTEM with AC_CANONICAL_SYSTEM.
That ChangeLog entry is clearly incorrect.
> diff --git a/config/asmcfi.m4 b/config/asmcfi.m4
> index a725aa11de4.
On Fri, 13 Jun 2025, Gábor Németh wrote:
> > > A new option is added to warn if floating point literals have non-standard
> > > suffices (currently Q and W) in pedantic mode. The option is ON by
> > > default.
> >
> > I don't think we should turn this off when building GCC itself (as opposed
> >
On Tue, 10 Jun 2025, Kito Cheng wrote:
> GCC will try to read the spec file from the directory where it is
> installed, but it should try to read from gcc_exec_prefix rather than
> standard_exec_prefix, because the latter is not the right one if
> compiler has been relocated into other places othe
On Thu, 12 Jun 2025, Marek Polacek wrote:
> +
> +
> +Support ++ and -- on complex values
> + href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3259.pdf";>N3259
> +15
> +
> +
This should be when the feature was supported (either GCC 2.5 when complex
types were introd
On Thu, 12 Jun 2025, Qing Zhao wrote:
> > In general I think we'd only expect an error if the information required
> > to give it is visible at the point where the counted_by attribute is used.
> > There might be a possibility of giving an error for this case when the
> > pointer gets derefere
On Wed, 11 Jun 2025, Marek Polacek wrote:
> This patch adds the C23 Support in GCC table (compiler features only).
>
> While creating it, I've consulted Annex M.2, our own changes.html,
> Joseph's "ISO C23 support in the GNU Toolchain" Cauldron presentation,
> https://en.cppreference.com/w/c/comp
On Wed, 11 Jun 2025, Qing Zhao wrote:
> Then how about the following case:
>
> typedef struct item3 Item3;
> struct pointer_array_9 {
>
> int count3;
> Item3 *array_3 __attribute__ ((counted_by (count3)));
> }
>
> struct item3 {
> int a;
> float b[];
> }
>
> In the above, the “Item3”
On Wed, 11 Jun 2025, Qing Zhao wrote:
> When I was adding more testing cases for the pointee type being
> structure/union, I have a question for the following case:
>
> struct item5 {
> int a;
> float b[];
> };
>
> struct pointer_array_9 {
>...
> int count5;
> struct item5 *array_5
On Wed, 11 Jun 2025, Uecker, Martin wrote:
> c: remaining fix for the composite type inconsistency [PR120510]
>
> There is an old GNU extension which allows overriding the
> promoted old-style arguments when there is an earlier prototype
> An example (from a test added for PR1
On Tue, 10 Jun 2025, Martin Uecker wrote:
> Here I simply override the type with the one with the prototype.
> This is not a perfect replacement for forming the composite type,
> but I assume this does not matter for any existing code. But if
> you think it is better to keep forming the composite
On Tue, 10 Jun 2025, Martin Uecker wrote:
> When looking for the casue of PR120510 I noticed there
> is some minor issues that make the code harder to understand
> which are left over from previous changes.
>
> Bootstrapped and regression tested for x86_64.
>
>
> c: clean up some functions
On Tue, 10 Jun 2025, Martin Uecker wrote:
> Small fix.
>
> Bootstrapped and regression tested for x86_64.
>
> Martin
>
> c: fix ICE for invalid code in generic selection [PR120303]
>
> Fix an error recovery ICE that occurs when a type name
> can not be parsed correctly in the c
On Tue, 13 May 2025, Qing Zhao wrote:
> + /* This attribute cannot be applied to a pointer type whose pointee type
> + is void. */
> + else if (TREE_CODE (TREE_TYPE (decl)) == POINTER_TYPE
> +&& TREE_CODE (TREE_TYPE (TREE_TYPE (decl))) == VOID_TYPE)
> +{
> + error_at (DECL_
On Tue, 10 Jun 2025, Marek Polacek wrote:
> +
> +Anonymous structures and unions
> + href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1406.pdf";>N1406
> +4.6
> +
> +
4.6 is probably a reasonable version to list here given that a significant
piece (support for designato
On Tue, 10 Jun 2025, Gábor Németh wrote:
> A new option is added to warn if floating point literals have non-standard
> suffices (currently Q and W) in pedantic mode. The option is ON by default.
> The negative form `-Wno-non-standard-suffix` is expected to be used typically,
> as is done for GCC
On Tue, 10 Jun 2025, Gábor Németh wrote:
> diff --git a/gcc/testsuite/c-c++-common/pr92826.c
> b/gcc/testsuite/c-c++-common/pr92826.c
> new file mode 100644
> index 000..ea2e20c6331
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/pr92826.c
> @@ -0,0 +1,6 @@
> +/* { dg-options "-pedanti
On Mon, 9 Jun 2025, Marek Polacek wrote:
> I've checked our C99 status table against the list in Annex M.5 in C23
> (n3220).
> I found no issues.
For this it probably makes sense to refer to the latest C2y draft, but
there shouldn't be any significant changes to the pre-C23 lists there.
(C2y
On Mon, 9 Jun 2025, Jakub Jelinek wrote:
> Hi!
>
> For C++26 P2786R13 I'm afraid I'll need 4 new flags on class types
> in struct lang_type (1 bit for trivially_relocatable_if_eligible,
> 1 for replaceable_if_eligible, 1 for not_trivially_relocatable and
> 1 for not_replaceable) and there are jus
On Sat, 7 Jun 2025, Martin Uecker wrote:
> Add a helper function to replace repeated code for removing
> qualifiers but not atomic. Make sure to also remove qualifiers
> but not atomic on the element type of arrays.
>
> PR c/120510
>
> gcc/c/ChangeLog:
> * c-typeck.c (remove_qualifi
On Sat, 7 Jun 2025, Martin Uecker wrote:
> This fixes a case where we invoke composite_type with types
> that do not have matching qualifiers. With this change, we can
> activate the checking assertion that makes sure the composite
> type is compatible with the two original types also for arrays.
On Sat, 7 Jun 2025, Martin Uecker wrote:
> Checking assertion revealed that we sometimes produce
> composite types with incorrect qualifiers, e.g. the example
>
> int f(int [_Atomic]);
> int f(int [_Atomic]);
> int f(int [_Atomic]);
>
> was rejected because atomic was lost in the second declarat
1 - 100 of 1359 matches
Mail list logo
