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
On Tue, 19 Dec 2023, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, OK for trunk?
>
> -- 8< --
>
> -Werror=foo implying -Wfoo wasn't working for -Wdeprecated-copy-dtor,
> because it is specified as the value 2 of warn_deprecated_copy, which shows
> up as CLVC_EQUAL, which is not one of the
On Mon, 18 Dec 2023, Jeff Law wrote:
>
>
> On 12/18/23 15:16, Vladimir Makarov wrote:
> > The following patch fixes
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918
> >
> > The patch was successfully bootstrapped and tested on x86-64, aarch64, and
> > ppc64.
> >
> > The patch
On Thu, 14 Dec 2023, David Malcolm wrote:
> Are these OK for trunk, assuming I followup with adding CI for this?
> (that said, I disappear for the rest of 2023 at the end of this week, so
> I'd work on the CI in early January)
Patches 2 (updated at the time of commit to reflect the latest
On Thu, 14 Dec 2023, David Malcolm wrote:
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> index 26a7e9c35070..9a394b3e2c77 100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -813,6 +813,10 @@ options supported by this target (@pxref{Run-time
>
On Sun, 17 Dec 2023, Martin Uecker wrote:
> + tree f = build_decl (input_location, FIELD_DECL, DECL_NAME (a),
> +composite_type_internal (ta, tb, cache));
> +
> + DECL_PACKED (f) = DECL_PACKED (a);
> + SET_DECL_ALIGN (f, DECL_ALIGN
On Sun, 17 Dec 2023, Martin Uecker wrote:
> +/* While tese tests check that incompatible definitions
> + * of enums can alias. */
s/tese/these/
Patch 3 is OK with that fix.
--
Joseph S. Myers
jos...@codesourcery.com
On Sun, 17 Dec 2023, Martin Uecker wrote:
> diff --git a/gcc/testsuite/gcc.dg/c23-tag-enum-1.c
> b/gcc/testsuite/gcc.dg/c23-tag-enum-1.c
> new file mode 100644
> index 000..a81a5afc456
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/c23-tag-enum-1.c
> +void test2(void)
> +{
> + enum ee
On Sun, 17 Dec 2023, Martin Uecker wrote:
> Here is the revised series. The first three patches only
> have changes in the tests as well as the return value
> changes. The fourth patch was now also revised,
> with changes and tests to make sure that the composite
> type works correctly for
On Mon, 18 Dec 2023, Jakub Jelinek wrote:
> Hi!
>
> The following patch changes -Walloc-size warning to no longer warn
> about int *p = calloc (1, sizeof (int));, because as discussed earlier,
> the size is IMNSHO sufficient in that case, for alloc_size with 2
> arguments warns if the product of
On Fri, 8 Sep 2023, Arthur Cohen wrote:
> + if (c < 0x80)
> + {
> +if (('A' <= c && c <= 'Z') || ('a' <= c && c <= 'z'))
> + return CPP_XID_START | CPP_XID_CONTINUE;
> +if (('0' <= c && c <= '9') || c == '_')
> + return CPP_XID_CONTINUE;
This may be an artifact of how the patch was
On Sat, 16 Dec 2023, Jeff Law wrote:
> I tracked this down to the port unconditionally adding -funsigned-bitfields to
> CC1_SPEC. According to the comment it's how the ABI is defined for the mcore
> targets.
We explicitly document (under Non-bugs in trouble.texi) that we don't do
this, and
On Sun, 17 Dec 2023, Florian Weimer wrote:
> This matches other compiler diagnostics. No test updates are needed
> because c-c++-common/pr95378.c does not match a specific -W option.
>
> Fixes commit d2384b7b24f8557b66f6958a05ea99ff4307e75c ("c-family:
> check qualifiers of arguments to
On Mon, 27 Nov 2023, Martin Uecker wrote:
> diff --git a/gcc/c/c-tree.h b/gcc/c/c-tree.h
> index a5dd9a37944..ece5b6a5d26 100644
> --- a/gcc/c/c-tree.h
> +++ b/gcc/c/c-tree.h
> @@ -758,6 +758,7 @@ extern tree require_complete_type (location_t, tree);
> extern bool same_translation_unit_p
On Mon, 27 Nov 2023, Martin Uecker wrote:
> + enum B : short { M = 1 } *y2e = /* { dg-warning "incompatible"
> } */
This probably now needs to be dg-error because
-Wincompatible-pointer-types is now an error by default. OK with that
changed as needed (you may also need such a change
On Mon, 27 Nov 2023, Martin Uecker wrote:
> Note that there is an additional change in parser_xref_tag
> to address the issue regarding completeness in redefinition
> which affects also structs / unions. The test c23-tag-6.c
> was changed accordingly.
>
>
> c23: tag compatibility rules for
On Mon, 11 Dec 2023, Alexandre Oliva wrote:
> On Dec 11, 2023, Joseph Myers wrote:
>
> > On Fri, 8 Dec 2023, Alexandre Oliva wrote:
> >> @@ -20589,7 +20589,7 @@ allocation before or after interprocedural
> >> optimization.
> >> This option enables
On Sat, 9 Dec 2023, Martin Uecker wrote:
> Fix regression causing ICE for structs with VLAs [PR 112488]
>
> A previous patch the fixed several ICEs related to size expressions
> of VM types (PR c/70418, ...) caused a regression for structs where
> a DECL_EXPR is not generated anymore although
On Fri, 8 Dec 2023, Alexandre Oliva wrote:
> @@ -20589,7 +20589,7 @@ allocation before or after interprocedural
> optimization.
> This option enables multilib-aware @code{TFLAGS} to be used to build
> target libraries with options different from those the compiler is
> configured to use by
1 - 100 of 2596 matches
Mail list logo
