On Thu, 20 Jun 2024, Jakub Jelinek wrote:
> 2024-06-19 Jakub Jelinek
> Martin Uecker
>
> PR c/114930
> PR c/115502
> gcc/c/
> * c-decl.cc (c_update_type_canonical): Assert t is main variant
> with 0 TYPE_QUALS. Simplify and don't use check_qualified_type.
On Mon, 17 Jun 2024, Jakub Jelinek wrote:
> 2024-06-17 Jakub Jelinek
>
> PR driver/115440
> * opts-common.cc (add_misspelling_candidates): If opt1 is non-NULL,
> add a space and opt1 to the alternative suggestion text.
>
> * g++.dg/cpp1z/pr115440.C: New test.
OK.
--
C2Y has adopted support for alignof applied to incomplete array types
(N3273). Add this support to GCC. As the relevant checks are in
c-family code that doesn't have access to functions such as
pedwarn_c23, this remains a hard error for older versions and isn't
handled by -Wc23-c2y-compat,
On Sat, 15 Jun 2024, Martin Uecker wrote:
> The patch fails on arm because the tests make assumptions
> about enums that are not true everywhere. Should we just
> limit the tests to x86?
For compilation tests, using -fno-short-enums should work. That won't
work for link / execute tests, but
On Fri, 14 Jun 2024, Jonathan Wakely wrote:
> Both, ideally. The libstdc++ test should definitely be fixed because
> it fails with released versions of glibc already in the wild. But
> glibc should also be fixed because it's a standards conformance issue.
The __ctx macro used in various
Support for complex increment and decrement (previously supported as
an extension) was voted into C2Y today (paper N3259). Thus, change
the pedwarn to a pedwarn_c23 and add associated tests.
Note: the type of the 1 to be added / subtracted is underspecified (to
be addressed in a subsequent
On Thu, 13 Jun 2024, Maciej W. Rozycki wrote:
> > This was tricky to duplicate without access to an alpha-linux-gnu
> > machine. I ended up building an uberbaum tree with --disable-shared
> > --disable-threads --enable-languages=ada up to all-target-libgcc, then I
> > replaced gcc/collect2 with
The first new C2Y feature, _Generic where the controlling operand is a
type name rather than an expression (as defined in N3260), was voted
into C2Y today. (In particular, this form of _Generic allows
distinguishing qualified and unqualified versions of a type.) This
feature also includes
On Tue, 4 Jun 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs in ipa-free-lang, because the
> fld_incomplete_type_of
> gcc_assert (TYPE_CANONICAL (t2) != t2
> && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE
> (t)));
> assertion doesn't hold.
On Sun, 2 Jun 2024, Kewen Lin wrote:
> diff --git a/gcc/m2/gm2-gcc/m2type.cc b/gcc/m2/gm2-gcc/m2type.cc
> index 571923c08ef..d52cbdf0b99 100644
> --- a/gcc/m2/gm2-gcc/m2type.cc
> +++ b/gcc/m2/gm2-gcc/m2type.cc
> @@ -1420,7 +1420,7 @@ build_m2_short_real_node (void)
>/* Define `REAL'. */
>
On Sun, 2 Jun 2024, Kewen Lin wrote:
> +value less than or equal to mode precision of the mode used for C type
> +@code{long double} (from hook @code{targetm.c.mode_for_floating_type}
> +with tree_index TI_LONG_DOUBLE_TYPE). If you do not define this macro,
> +mode precision of the mode used for
On Sat, 1 Jun 2024, Martin Uecker wrote:
> This is a new version of the patch. I changed the overflow warning to
> an error and added your other example to the test case.
>
> Bootstrapped and regression tested on x86_64.
>
>
> c23: Fix for redeclared enumerator initialized with different
On Thu, 30 May 2024, Qing Zhao wrote:
> In order to make this working, the routine digest_init in c-typeck.cc
> is updated to fold calls to .ACCESS_WITH_SIZE to its first argument
> when require_constant is TRUE.
The new changes here are OK.
--
Joseph S. Myers
josmy...@redhat.com
On Wed, 29 May 2024, Kewen.Lin wrote:
> > Note that when removing a target macro, it's a good idea to add it to the
> > "Old target macros that have moved to the target hooks structure." list
> > (of #pragma GCC poison) in system.h to ensure any new target that was
> > originally written
On Sun, 26 May 2024, Martin Uecker wrote:
> +/* Helper function for comptypes. For two compatible types, return 1
> + if they pass consistency checks. In particular we test that
> + TYPE_CANONICAL ist set correctly, i.e. the two types can alias. */
s/ist/is/. OK with that fix.
--
On Sun, 26 May 2024, Martin Uecker wrote:
> This is the patch I sent previously, but I tried to improve the
> description and added a long comment. This patch is needed so
> that we do not have to update TYPE_CANONICAL of structures / unions
> when a tagged type is completed that is
On Fri, 24 May 2024, Martin Uecker wrote:
> This is another version of this patch with two changes:
>
> - I added a fix (with test) for PR 115177 which is just the same
> issue for hardbools which are internally implemented as enums.
>
> - I fixed the golang issue. Since the addition of the
On Fri, 24 May 2024, Kewen.Lin wrote:
> Following your suggestion and comments, I made this patch
> for mode_for_floating_type first, considering this touches
> a few FE and port specific code, I think I have to split
> it into a patch series. Before making that, I'd like to
> ensure this meets
On Tue, 21 May 2024, Martin Uecker wrote:
>
> C: allow aliasing of compatible types derived from enumeral types
> [PR115157]
>
> Aliasing of enumeral types with the underlying integer is now allowed
> by setting the aliasing set to zero. But this does not allow aliasing
>
On Tue, 21 May 2024, Martin Uecker wrote:
> > The constraint violated is the general one "If an identifier has no
> > linkage, there shall be no more than one declaration of the identifier (in
> > a declarator or type specifier) with the same scope and in the same name
> > space, except that:
On Sun, 19 May 2024, Martin Uecker wrote:
> c23 specifies that the type of a redeclared enumerator is the one of the
> previous declaration. Convert initializers with different type
> accordingly
> and add -Woverflow warning.
It doesn't make sense to use -Woverflow. Either the
On Sat, 18 May 2024, Martin Uecker wrote:
> We did not propagate C_TYPE_VARIABLY_MODIFIED to pointers in all
> cases. I added this directly in two places, but maybe we should
> check all cases of build_pointer_type or integrate this into
> c_build_pointer_type and use this everywhere (but I do
On Mon, 13 May 2024, Kewen.Lin wrote:
> > In fact replacing all of X_TYPE_SIZE with a single hook might be worthwhile
> > though this removes the "convenient" defaulting, requiring each target to
> > enumerate all standard C ABI type modes. But that might be also a good
> > thing.
> >
>
> I
On Wed, 8 May 2024, Richard Biener wrote:
> So it's reasonable to require -fnon-call-exceptions (which now enables
> -fexceptions) and -fno-delete-dead-exceptions to have GCC preserve
> a change of control flow side-effect of x*x? We do not preserve
> FP exception bits set by otherwise unused
On Wed, 8 May 2024, Xi Ruoyao wrote:
> In GCC 14 we started to emit URLs for "command-line option is
> valid for but not " and "-Werror= argument
> '-Werror=' is not valid for " warnings. So we should
> have moved -fdiagnostics-urls= early like -fdiagnostics-color=, or
> -fdiagnostics-urls=
On Wed, 8 May 2024, Kewen.Lin wrote:
> to widen IFmode to TFmode. To make build_common_tree_nodes
> be able to find the correct mode for long double type node,
> it introduces one hook mode_for_longdouble to offer target
> a way to specify the mode used for long double type node.
I don't really
On Sat, 4 May 2024, Ben Boeckel wrote:
> diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
> index be3058dca63..4a164ad0c0b 100644
> --- a/gcc/c-family/c-opts.cc
> +++ b/gcc/c-family/c-opts.cc
> @@ -370,7 +370,7 @@ c_common_handle_option (size_t scode, const char *arg,
> HOST_WIDE_INT
On Fri, 3 May 2024, Richard Biener wrote:
> So what I do not necessarily agree with is that we need to preserve
> the multiplication with -fsignaling-nans. Do we consider a program doing
>
> handler() { exit(0); }
>
> x = sNaN;
> ...
> sigaction(SIGFPE, ... handler)
> x*x;
>
On Thu, 25 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> While the C23 standard isn't officially release yet,
> in 2011 we've changed __STDC_VERSION__ value for C11 already
> in the month in which the new __STDC_VERSION__ value has been
> finalized, so we want to change this now or wait
> until we
On Mon, 29 Apr 2024, Jakub Jelinek wrote:
> On Mon, Apr 29, 2024 at 01:44:24PM +0000, Joseph Myers wrote:
> > > glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is
> > > a
> > > dummy shared library with just some symbol versions fo
On Thu, 25 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
> dummy shared library with just some symbol versions for compatibility, but
> all the pthread_* APIs are in libc.so.6).
I suspect this has caused link failures in the
On Fri, 19 Apr 2024, Qing Zhao wrote:
> gcc/c/ChangeLog:
>
> * c-decl.cc (finish_struct): Change errors to pedwarns for the cases
> flexible array members in union or alone in structures.
The C front-end changes are OK for GCC 15 once everything else in the
series is ready for
On Tue, 23 Apr 2024, Qing Zhao wrote:
> However, I am not very confident on the wording of the doc, is the
> current wording good enough for this? Or do you have any suggestion on
> how to make it better?
I'm not convinced the statement about size (in relation to a structure
with the member
On Fri, 19 Apr 2024, Qing Zhao wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/flex-array-in-union-1.c: New test.
> * gcc.dg/flex-array-in-union-2.c: New test.
There should also be a -pedantic-errors test that these constructs get
errors with -pedantic-errors.
The tests mix two
On Fri, 19 Apr 2024, Qing Zhao wrote:
> +The size of the union is as if the flexiable array member were omitted
> +except that it may have more trailing padding than the omission would imply.
"trailing padding" is more a concept for structures than for unions (where
padding depends on which
This version of patch 1/5 is OK for GCC 15.
--
Joseph S. Myers
josmy...@redhat.com
On Fri, 19 Apr 2024, Jakub Jelinek wrote:
> Ok for trunk and later 13.3 if it passes bootstrap/regtest (so far just
> checked on the sentinel related C/C++ tests)?
>
> 2024-04-19 Jakub Jelinek
>
> PR c/114780
> * c-common.cc (check_function_sentinel): Allow as sentinel any
>
On Mon, 15 Apr 2024, Jakub Jelinek wrote:
> 2024-04-15 Martin Uecker
> Jakub Jelinek
>
> PR lto/114574
> PR c/114361
> gcc/c/
> * c-decl.cc (shadow_tag_warned): For flag_isoc23 and code not
> ENUMERAL_TYPE use SET_TYPE_STRUCTURAL_EQUALITY.
>
On Wed, 10 Apr 2024, Qing Zhao wrote:
> Okay, the above is very clear, thanks a lot for the explanation.
> So, basically, for “counted-by” attribute:
> **The following is good:
> struct f {
> int b;
> int c;
> int a[] __attribute__ ((counted_by (b))) };
> struct f {
> int b;
> int c;
On Wed, 10 Apr 2024, Qing Zhao wrote:
> A stupid question first, the same scope means the same file? (Or same
> function)
struct X { int a; };
struct X { int a; };
is an example of the same scope (file scope, in this case). The
structures must have the same contents (in an appropriate sense)
The C front-end changes in this patch are OK for GCC 15.
--
Joseph S. Myers
josmy...@redhat.com
On Fri, 29 Mar 2024, Qing Zhao wrote:
> +/* For a SUBDATUM field of a structure or union DATUM, generate a REF to
> + the object that represents its counted_by per the attribute counted_by
> + attached to this field if it's a flexible array member field, otherwise
> + return NULL_TREE.
> +
The C front-end changes in this patch are OK for GCC 15.
--
Joseph S. Myers
josmy...@redhat.com
On Fri, 29 Mar 2024, Qing Zhao wrote:
> + /* Issue error when there is a counted_by attribute with a different
> + field as the argument for the same flexible array member field. */
There's another case of this to consider, though I'm not sure where best
to check for it (Martin might have
Add release notes for C23 features added in GCC 14. This doesn't
cover any non-C23 new C features; any such features should also have
release notes added.
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 934cd1ad..045893cf 100644
--- a/htdocs/gcc-14/changes.html
+++
On Tue, 2 Apr 2024, Martin Uecker wrote:
> Am Dienstag, dem 02.04.2024 um 20:42 + schrieb Joseph Myers:
> > On Tue, 2 Apr 2024, Martin Uecker wrote:
> >
> > > [C23]fix aliasing for structures/unions with incomplete types
> > >
> > > When incomplete
On Tue, 2 Apr 2024, Martin Uecker wrote:
> [C23]fix aliasing for structures/unions with incomplete types
>
> When incomplete structure/union types are completed later, compatibility
> of struct types that contain pointers to such types changes. When forming
> equivalence classes for
On Tue, 2 Apr 2024, Martin Uecker wrote:
> Fix ICE with -g and -std=c23 related to incomplete types [PR114361]
>
> We did not copy TYPE_CANONICAL to the incomplete variants when
> completing a structure.
>
> PR c/114361
>
> gcc/c/
> * c-decl.c (finish_struct): Set
On Wed, 27 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> As written in the PR, torture/bitint-64.c test fails with -O2 -flto
> and the reason is that on _BitInt arches where the padding bits
> are undefined, the padding bits in the _Atomic vars are also undefined,
> but when __atomic_load or
On Tue, 26 Mar 2024, Qing Zhao wrote:
> > What happens when there are multiple counted_by attributes on the same
> > field? As far as I can see, all but one end up being ignored (by the code
> > that actually uses the attribute).
>
> In general, is there any rule for handling multiple same
On Tue, 26 Mar 2024, Qing Zhao wrote:
> >> +@cindex @code{counted_by} variable attribute
> >> +@item counted_by (@var{count})
> >> +The @code{counted_by} attribute may be attached to the C99 flexible array
> >> +member of a structure. It indicates that the number of the elements of
> >> the
>
On Wed, 20 Mar 2024, Qing Zhao wrote:
> + the size of the element can be retrived from the result type of the call,
> + which is the pointer to the array type. */
Again, start a sentence with an uppercase letter.
> + /* if not for dynamic object size, return. */
> + /* result type is a
On Wed, 20 Mar 2024, Qing Zhao wrote:
> + /* get the TYPE of the counted_by field. */
Start comments with an uppercase letter.
> + The type of the first argument of this function is a POINTER type
> + to the orignal flexible array type.
s/orignal/original/
> + If HANDLE_COUNTED_BY
On Wed, 20 Mar 2024, Qing Zhao wrote:
> + /* This attribute only applies to a C99 flexible array member type. */
> + else if (! c_flexible_array_member_type_p (TREE_TYPE (decl)))
> +{
> + error_at (DECL_SOURCE_LOCATION (decl),
> + "%qE attribute is not allowed for a non"
>
On Fri, 22 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> I've noticed that the c-c++-common/gomp/depobj-3.c test FAILs on i686-linux:
> PASS: c-c++-common/gomp/depobj-3.c -std=c++17 at line 17 (test for
> warnings, line 15)
> FAIL: c-c++-common/gomp/depobj-3.c -std=c++17 at line 39 (test for
>
On Wed, 20 Mar 2024, liuhongt wrote:
> gcc/ChangeLog:
>
> * doc/invoke.texi: Document -fexcess-precision=16.
OK.
--
Joseph S. Myers
josmy...@redhat.com
On Tue, 19 Mar 2024, Hongtao Liu wrote:
> On Tue, Mar 19, 2024 at 12:16 AM Joseph Myers wrote:
> >
> > On Mon, 18 Mar 2024, liuhongt wrote:
> >
> > > +If @option{-fexcess-precision=16} is specified, casts and assignments of
> > > +@code{_Float16} and @cod
On Mon, 18 Mar 2024, liuhongt wrote:
> +If @option{-fexcess-precision=16} is specified, casts and assignments of
> +@code{_Float16} and @code{bfloat16_t} cause value to be rounded to their
> +semantic types if they're supported by the target.
Isn't that option about rounding results of all
On Fri, 1 Mar 2024, Jonathan Wakely wrote:
> I'm seeing errors for --enable-maintainer-mode builds due to incorrectly
> regenerating these files. They should be touched by gcc_update so they
> aren't regenerated unnecessarily.
>
> contrib/ChangeLog:
>
> * gcc_update: Add more generated
On Fri, 15 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> While for __mulbitint3 we actually don't negate anything and perform the
> multiplication in unsigned style always, for __divmodbitint4 if the operands
> aren't unsigned and are negative, we negate them first and then try to
> negate them as
On Thu, 21 Dec 2023, Lewis Hyatt wrote:
> In libcpp/files.cc, the function _cpp_has_header(), which implements
> __has_include and __has_include_next, does not check for a NULL return value
> from search_path_head(), leading to an ICE tripping an assert when
> _cpp_find_file() tries to use it.
On Tue, 12 Dec 2023, Lewis Hyatt wrote:
> When the file name for a #include directive is the result of stringifying a
> macro argument, libcpp needs to take some care to get the whitespace
> correct; in particular stringify_arg() needs to see a CPP_PADDING token
> between macro tokens so that it
On Tue, 5 Mar 2024, Jakub Jelinek wrote:
> I can't bisect that far, supposedly predefined macros weren't included back
> in 1996 when this was written but maybe it changed in 1999 or even earlier.
It looks like this changed in 3.0 (so probably with the move to cpplib to
provide the default
On Mon, 26 Feb 2024, Alejandro Colomar wrote:
> > The idea seems reasonable, but the patch needs documentation for the new
> > option in invoke.texi.
>
> Thanks! Will do.
>
> I don't see an obvious order in that file. Where would you put the
> option? Do you want me to sort(1) it first, and
On Sun, 25 Feb 2024, Alejandro Colomar wrote:
> or if it's just that everyone was busy doing
> other stuff.
Yes, that's right. The patch was already listed on my patch review
backlog, but that backlog is long.
--
Joseph S. Myers
josmy...@redhat.com
On Sun, 25 Feb 2024, Mike Stump wrote:
> On Feb 6, 2024, at 2:45 AM, Alejandro Colomar wrote:
> >
> > Warn about the following:
> >
> >char s[3] = "foo";
>
> No ObjC specific impact here, so no need for ObjC review.
>
> As a member of the peanut gallery, I like the patch.
>
> Joseph,
On Fri, 23 Feb 2024, Jakub Jelinek wrote:
> Hi!
>
> The PR complains that for the __builtin_stdc_bit_* "builtins" the
> diagnostics doesn't mention the name of the builtin the user used, but
> instead __builtin_{clz,ctz,popcount}g instead (which is what the FE
> immediately lowers it to).
>
>
On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> But sure, if you prefer the COLON_SCOPE version of the patch, I can commit
> that. There is no PREV_WHITE in the preprocessor, there is
Yes, I prefer the COLON_SCOPE version.
--
Joseph S. Myers
josmy...@redhat.com
On Thu, 22 Feb 2024, Richard Earnshaw (lists) wrote:
> On 21/02/2024 21:34, rep.dot@gmail.com wrote:
> > On 21 February 2024 19:34:43 CET, Evgeny Karpov
> > wrote:
> >>
> >
> > Please use git send-email. Your mail ends up as empty as here, otherwise.
>
> I don't see anything wrong with
On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> Hi!
>
> We aren't able to parse __has_attribute (vendor::attr) (and __has_c_attribute
> and __has_cpp_attribute) in strict C < C23 modes. While in -std=gnu* modes
> or in -std=c23 there is CPP_SCOPE token, in -std=c* (except for -std=c23)
> there are
On Sat, 10 Feb 2024, Jakub Jelinek wrote:
> * c-format.cc (gcc_diag_length_specs): Add t and z modifiers.
> (PP_FORMAT_CHAR_TABLE, gcc_gfc_char_table): Add entries for t and
> z modifiers.
Please also add some tests of format checking for these modifiers in
On Fri, 9 Feb 2024, Siddhesh Poyarekar wrote:
> > I think disallowing running as root would be a big problem in practice -
> > the typical problem case is when people build software as non-root and run
> > "make install" as root, and for some reason "make install" wants to
> > (re)build or
On Fri, 9 Feb 2024, Siddhesh Poyarekar wrote:
> For privilege management we could add a --allow-root driver flag that allows
> gcc to run as root. Without the flag one could either outright refuse to run
> or drop privileges and run. Dropping privileges will be a bit tricky to
> implement
On Fri, 1 Dec 2023, David Malcolm wrote:
> * diagnostic-core.h (emit_diagnostic_valist): New overload decl.
This has broken regeneration of gcc.pot (overloads can't have the message
extracted for translation in different argument positions).
emit_diagnostic_valist used incompatibly as
My fix for bug 111059 and bug 111911 caused a conversion of a floating
constant to boolean to wrongly no longer be considered an integer
constant expression, because logic to insert a NOP_EXPR in
c_objc_common_truthvalue_conversion for an argument not an integer
constant expression itself now took
This series appears to be missing documentation for the new option in
invoke.texi.
--
Joseph S. Myers
josmy...@redhat.com
On Wed, 31 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> On Sat, Jan 27, 2024 at 08:53:42AM +0100, Jakub Jelinek wrote:
> > The following testcase ends up with SIGFPE in __divmodbitint4.
> > The problem is a thinko in my attempt to implement Knuth's algorithm.
>
> Here is an updated version of the
On Fri, 2 Feb 2024, Andi Kleen wrote:
> This patchkit implements a [[musttail]] attribute for C/C++.
>
> v4:
> Addressed all feedback except clang::musttail is still supported
> (I don't want to force an #ifdef to most users) and I'm also still
I'm fine with supporting [[clang::musttail]].
On Fri, 2 Feb 2024, Bernhard Reutner-Fischer via Gcc wrote:
> Hi Joseph!
>
> On Tue, 30 Jan 2024 14:54:49 + (UTC)
> Joseph Myers wrote:
>
> > On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:
> >
> > > * builtin-attrs.def (ATTR_TM_NOT
On Thu, 1 Feb 2024, Marek Polacek wrote:
> On Wed, Jan 31, 2024 at 11:39:56PM -0800, Andi Kleen wrote:
> > > This will run the test only once with -std=c++11. We'll get better
> > > coverage
> > > with dropping the line above and using
> > >
> > > /* { dg-do compile { target { tail_call && { c
On Wed, 31 Jan 2024, Jakub Jelinek wrote:
> On Wed, Jan 31, 2024 at 12:21:38PM -0800, Andi Kleen wrote:
> > > > + case RID_RETURN:
> > > > + {
> > > > + bool musttail_p = false;
> > > > + std_attrs = process_stmt_hotness_attribute (std_attrs,
> > > > attrs_loc);
Bug 112571 reports an ICE-on-invalid for cases where an enum is
defined, without a fixed underlying type, inside the enum type
specifier for a definition of that same enum with a fixed underlying
type.
The ultimate cause is attempting to access ENUM_UNDERLYING_TYPE in a
case where it is NULL.
C front-end bugs 111059 and 111911 both report ICEs with conversions
to boolean of expressions with integer constant operands that can
appear in an integer constant expression as long as they are not
evaluated (such as division by zero).
The issue is a nested C_MAYBE_CONST_EXPR, with the inner
On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:
> * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
> instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.
That doesn't make sense. ATTR_TM_NOTHROW_RT_LIST is specifically a
transactional
On Mon, 29 Jan 2024, Qing Zhao wrote:
> Thank you!
>
> Joseph and Richard, could you also comment on this?
I think Martin's suggestions are reasonable.
--
Joseph S. Myers
josmy...@redhat.com
On Sat, 27 Jan 2024, Martin Uecker wrote:
> Debug output ICEs when we do not set TYPE_STUB_DECL, fix this.
>
>
> Fix ICE with -g and -std=c23 when forming composite types [PR113438]
>
> Set TYPE_STUB_DECL to an artificial decl when creating a new structure
> as a composite
On Fri, 26 Jan 2024, Andi Kleen wrote:
> > > I don't have tests for that but since it's not new behavior I suppose
> > > that's sufficient.
> >
> > Each attribute should have tests that invalid uses are appropriately
> > diagnosed. See gcc.dg/c23-attr-fallthrough-2.c for examples of such tests
On Thu, 25 Jan 2024, Andi Kleen wrote:
> On Thu, Jan 25, 2024 at 08:08:23PM +0000, Joseph Myers wrote:
> > On Wed, 24 Jan 2024, Andi Kleen wrote:
> >
> > > Implement a C23 clang compatible musttail attribute similar to the earlier
> > > C++ implementation in
On Wed, 24 Jan 2024, Andi Kleen wrote:
> Implement a C23 clang compatible musttail attribute similar to the earlier
> C++ implementation in the C parser.
I'd expect diagnostics, and associated tests of those diagnostics, for:
* musttail attribute used with any arguments, even empty
On Tue, 23 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> As the following testcase shows, I forgot to call c_fully_fold on the
> __atomic_*/__sync_* operands called on _BitInt address, the expressions
> are then used inside of TARGET_EXPR initializers etc. and are never fully
> folded later, which
On Sat, 20 Jan 2024, Martin Uecker wrote:
> C23: Fix ICE for composite type for structs with unsigned bitfields [PR113492]
>
> This patch fixes a bug when forming a composite type from structs that
> contain an unsigned bitfield declared with int while using
> -funsigned-bitfields.
> In
On Wed, 17 Jan 2024, Jonathan Wakely wrote:
> So we can remove the dependency on __STRICT_ISO__ for 128-bit integer
> types, and implementing std::is_integral with a built-in seems like
> the perfect time to do that. But that seems like stage 1 material, as
> we need to go through the library and
On Fri, 12 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> When build_array_ref doesn't use ARRAY_REF, it casts the index to sizetype
> already, performs POINTER_PLUS_EXPR and then dereferences.
> While when emitting ARRAY_REF, we try to keep index expression as is in
> whatever type it had, which is
On Mon, 8 Jan 2024, Tamar Christina wrote:
> Hi All,
>
> In C you can have loops without a condition, the original version of the patch
> was rejecting the use of #pragma GCC novector, however during review it was
> changed to not due this with the reason that we didn't want to give a compile
>
Meteorologisch Instituut)
-Joseph Myers (CodeSourcery / Mentor Graphics) [co-Release Manager]
+Joseph Myers (Red Hat) [co-Release Manager]
Gerald Pfeifer (SUSE)
Ramana Radhakrishnan
Joel Sherrill (OAR Corporation)
--
Joseph S. Myers
josmy...@redhat.com
David S. Miller
-Joseph Myers
+Joseph Myers
Richard Sandiford
Bernd Schmidt
Ian Lance Taylor
On Tue, 2 Jan 2024, David Malcolm wrote:
> > > +#print(f'{url_suffix=} {index_text=}')
> >
> > Various commented-out or "if 0" debugging code like this should probably
> > be removed (or made into an actual runtime conditional if desired).
>
> I've removed them all.
There are still a
Jason Merrill
David S. Miller
-Joseph Myers
+Joseph Myers
Richard Sandiford
Bernd Schmidt
On Wed, 27 Dec 2023, Martin Uecker wrote:
> This patch hopefully fixes the test failure we see with gnu23-tag-4.c.
> It does for me locally with -march=native (which otherwise reproduces
> the problem).
>
> Bootstrapped and regession tested on x86_64
>
>
> C: Fix type compatibility for structs
On Thu, 21 Dec 2023, Martin Uecker wrote:
> This version now sets DECL_NONADDRESSABLE_P, DECL_PADDING_P
> and C_DECL_VARIABLE_SIZE and adds three new tests:
> c23-tag-alias-7.c, c23-tag-composite-10.c, and
> gnu23-tag-composite-5.c.
This version is OK.
--
Joseph S. Myers
1 - 100 of 2614 matches
Mail list logo
