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
https://gcc.gnu.org/g:81c627d47c2063b7f143c974e9733ce43c0d142e
commit r14-10213-g81c627d47c2063b7f143c974e9733ce43c0d142e
Author: Joseph Myers
Date: Thu May 16 21:21:48 2024 +
Update gcc sv.po
* sv.po: Update.
Diff:
---
gcc/po/sv.po | 514
https://gcc.gnu.org/g:0b2c333e1a3c0bb800add1daab5b6fc8ba5c1cef
commit r15-584-g0b2c333e1a3c0bb800add1daab5b6fc8ba5c1cef
Author: Joseph Myers
Date: Thu May 16 21:20:36 2024 +
Update gcc sv.po
* sv.po: Update.
Diff:
---
gcc/po/sv.po | 514
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 Sat, 4 May 2024, Ben Boeckel via Gcc wrote:
> - every push is stored in a ghostflow-director-side unique ref
> (`refs/mr/ID/heads/N` where `N` is an incrementing integer) to avoid
> forge-side garbage collection (especially problematic on Github;
> I've not noticed GitLab
On Thu, 2 May 2024, Fangrui Song wrote:
> > On the other hand, GitHub structures the concept of pull requests
> > around branches and enforces a branch-centric workflow. A pull request
> > centers on the difference (commits) between the base branch and the
> > feature branch. GitHub does not
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 Wed, 24 Apr 2024, Krishna Narayanan via Gcc wrote:
> Hi all,
> Is the RISC-V community planning to add support for trapping math in RISC-V
> in the near future!?
> This LLVM thread
> https://discourse.llvm.org/t/trapping-math-for-risc-v/72168/7 suggests a
> software emulation of traps, is the
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 Mon, 22 Apr 2024, Mark Wielaard wrote:
> > A system that uses git as the source of
> > truth for all the pull request data and has refs through which all this
> > can be located (with reasonably straightforward, documented formats for
> > the data, not too closely tied to any particular
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.
>
https://gcc.gnu.org/g:e8f0540f23762ca155fe9ed70d6adb864be096b5
commit r14-10042-ge8f0540f23762ca155fe9ed70d6adb864be096b5
Author: Joseph Myers
Date: Fri Apr 19 20:02:56 2024 +
Update gcc sv.po
* sv.po: Update.
Diff:
---
gcc/po/sv.po | 785
On Thu, 18 Apr 2024, Frank Ch. Eigler via Gcc wrote:
> Hi -
>
> > [...] I suggest that a basic principle for such a system is that it
> > should be *easy* to obtain and maintain a local copy of the history
> > of all pull requests. That includes all versions of a pull request,
> > if it gets
On Thu, 18 Apr 2024, Mark Wielaard wrote:
> But we like to get more feedback on what people really think a
> "pull-request" style framework should look like. We used to have a
> gerrit setup which wasn't really popular. And we already have a
> sourcehut mirror that can be used to turn your
On Wed, 17 Apr 2024, Sandra Loosemore wrote:
> Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove
> support from all toolchain components after the release is made. I'm not sure
> there is an established process for obsoleting/removing support in other
> components; besides
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
+++
---
commit 6eeeb6a53c2e57e3f02f97da176589cf15877247
Author: Joseph Myers
Date: Thu Apr 4 17:04:33 2024 +
gcc-14: Add release notes for C23 features
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 ad
https://gcc.gnu.org/g:f37555028717cb1454ee258afdf68aea1c7a50e9
commit r14-9778-gf37555028717cb1454ee258afdf68aea1c7a50e9
Author: Joseph Myers
Date: Wed Apr 3 20:47:47 2024 +
Update gcc sv.po
* sv.po: Update.
Diff:
---
gcc/po/sv.po | 203
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
>
https://gcc.gnu.org/g:f2af129b68bc6b20f79a9a44b28c96650baa702c
commit r13-8495-gf2af129b68bc6b20f79a9a44b28c96650baa702c
Author: Joseph Myers
Date: Wed Jan 31 21:39:53 2024 +
c: Fix ICE for nested enum redefinitions with/without fixed underlying type
[PR112571]
Bug 112571
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"
>
https://gcc.gnu.org/g:18555b914316e8c1fb11ee821f2ee839d834e58e
commit r14-9656-g18555b914316e8c1fb11ee821f2ee839d834e58e
Author: Joseph Myers
Date: Mon Mar 25 18:28:48 2024 +
Update gcc sv.po
* sv.po: Update.
Diff:
---
gcc/po/sv.po | 700
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
https://gcc.gnu.org/g:9b3243858bed000b0ee8c3cf718f61b0e75e72ec
commit r14-9431-g9b3243858bed000b0ee8c3cf718f61b0e75e72ec
Author: Joseph Myers
Date: Mon Mar 11 19:36:52 2024 +
Update gcc sv.po
* sv.po: Update.
Diff:
---
gcc/po/sv.po | 437
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 Tue, 13 Feb 2024, Ties Klappe via Gcc wrote:
> Thank you both for your quick replies.
>
> @Joseph, thank you for linking me to the other issue. If I understand
> correctly what the point is, would you then agree that the program main
> when calling foo2 has *defined* behavior?
I think that's
On Tue, 13 Feb 2024, Ties Klappe via Gcc wrote:
> int foo2(int *restrict *p, int *restrict *q)
> {
> **p = 10;
> **q = 11;
> return **p;
> }
In this case, *p and *q might be the same restricted pointer object. See
the more detailed explanation at
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 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 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 Mon, 15 Jan 2024, Florian Weimer via Gcc wrote:
> The change conflated multiple issues: sanitizer support,
> async-signal-safe TLS access, and eager allocation of all TLS-related
> memory, so that subsequent accesses cannot fail. My impression was the
> main point of contention was eager
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
1 - 100 of 3367 matches
Mail list logo
