On Mon, 2 Oct 2023, Sandra Loosemore wrote:
> Going beyond that, though, I think we should also document that the standard
> syntax is now the preferred way to do it, and change the examples (except for
> the parts documenting the old syntax) to use the new standard syntax. It's
> been accepted b
On Tue, 3 Oct 2023, Sandra Loosemore wrote:
> Is __attribute__ also considered more powerful than the standard [[]] syntax,
> enough to recommend it over writing standard-conforming code?
Anything that can be expressed with __attribute__ should also be
expressible with [[]], so use of [[]] is pr
On Sat, 14 Oct 2023, Martin Uecker wrote:
> + if (!initialized
> + && storage_class != csc_static
> + && storage_class != csc_auto
> + && current_scope != file_scope)
I think it would be better to use TREE_PUBLIC (decl) in place of
storage_class != csc_static && stora
On Sat, 14 Oct 2023, Andrew Pinski wrote:
> When checking to see if we have a function declaration has a conflict due to
> promotations, there is no test to see if the type was an error mark and then
> calls
> c_type_promotes_to. c_type_promotes_to is not ready for error_mark and causes
> an
> I
On Sat, 14 Oct 2023, Andrew Pinski wrote:
> This is a simple error recovery issue when c_safe_arg_type_equiv_p
> was added in r8-5312-gc65e18d3331aa999. The issue is that after
> an error, an argument type (of a function type) might turn
> into an error mark node and c_safe_arg_type_equiv_p was no
On Tue, 24 Jul 2018, tamar.christ...@arm.com wrote:
> This patch defines a configure option to allow the setting of the default
> guard size via configure flags when building the target.
If you add a configure option, you must also add documentation for it in
install.texi.
--
Joseph S. Myers
j
On Fri, 6 Jul 2018, Segher Boessenkool wrote:
> Version checks are terrible. This is nothing new.
The key principle behind --with-glibc-version is that you can pass that
option *when building the static-only inhibit_libc bootstrap compiler
without having built glibc yet* and it will result in
On Mon, 16 Jul 2018, Alexander von Gluck IV wrote:
> * We have been dragging these around since gcc 4.x.
> * Some tweaks will likely be needed, but this gets our foot
> in the door.
>
> Authors:
> Fredrik Holmqvist
> Jerome Duval
> Augustin Cavalier
> François Revol
> Simon South
>
On Wed, 18 Jul 2018, Janne Blomqvist wrote:
> minimumNumber(a, NaN) = minimumNumber(NaN, a) = a
>
> That is minimumNumber corresponds to minnum in IEEE 754-2008 and fmin* in
No, it differs in the handling of signaling NaNs (with minimumNumber, if
the NaN argument is signaling, it results in the
On Thu, 19 Jul 2018, Martin Liška wrote:
> I must admit that was my intention :) In my eyes it makes it more consistent
> and
> it gives consumers feedback about usage of an option that does nothing.
> For x86_64 there's list of options that are Ignore and don't produce a
> warning:
The design
On Fri, 20 Jul 2018, Martin Liška wrote:
> +C++ ObjC++ Ignore)
Stray ')' at the end of this line.
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 24 Jul 2018, Sandra Loosemore wrote:
> On 07/23/2018 10:17 PM, Sandra Loosemore wrote:
>
> > C-SKY proposes Han Mao and Yunhai Shang
> > as maintainers for this port.
>
> I apologize, I made a mistake here. The correct proposed maintainers are
> Xianmiao Qu and Yunhai Shang
> .
I'
On Wed, 25 Jul 2018, Richard Earnshaw (lists) wrote:
> >> Port maintainers DO need to decide what to do about speculation, even if
> >> it is explicitly that no mitigation is needed.
> >
> > Agreed. But I didn't yet see a request for maintainers to decide that?
> >
>
> consider it made, then :
On Fri, 27 Jul 2018, Richard Earnshaw (lists) wrote:
> The c-c++-common/spec-barrier-1.c test will fail on any target that has
> not been updated (it deliberately doesn't check for
> __HAVE_SPECULATION_BARRIER before trying to use the new intrinsic). The
> test contains a comment to that effect.
On Fri, 27 Jul 2018, Bogdan Harjoc wrote:
> If a struct contains an anonymous union and both have a field with the
> same name, detect_field_duplicates_hash() will replace one of them
> with NULL. If compilation doesn't stop immediately, it may later call
> lookup_field() on the union, which false
On Fri, 27 Jul 2018, Ramana Radhakrishnan wrote:
> Joseph,
>
> A lot of such information seems to come out from a number of reviewers
> only during patch review from new contributors. Would you mind
> improving https://gcc.gnu.org/contribute.html and especially around
> "Testing patches" or star
On Fri, 27 Jul 2018, Alexander von Gluck IV wrote:
> >> It's much better for issues to be identified within a day or two of the
> >> commit causing them than many months later, possibly only after a release
> >> has come out with the issue - but that requires an ongoing commitment to
> >> keep mon
On Mon, 30 Jul 2018, Bernd Edlinger wrote:
> Hi,
>
> this is how I would like to handle the over length strings issue in the C FE.
> If the string constant is exactly the right length and ends in one explicit
> NUL character, shorten it by one character.
I don't think shortening should be limite
On Mon, 30 Jul 2018, Bernd Edlinger wrote:
> In the moment I would already be happy if all STRING_CSTs would
> be zero terminated.
generic.texi says they need not be. Making the STRING_CST contain only
the bytes of the initializer and not the trailing NUL in the C case where
the trailing NUL d
On Mon, 30 Jul 2018, Jakub Jelinek wrote:
> On Mon, Jul 30, 2018 at 03:52:39PM +0000, Joseph Myers wrote:
> > On Mon, 30 Jul 2018, Bernd Edlinger wrote:
> >
> > > In the moment I would already be happy if all STRING_CSTs would
> > > be zero terminated.
> >
On Mon, 30 Jul 2018, John Ericson wrote:
> I understand this building them separately is not supported, but am
> nevertheless hoping the patch can nevertheless be upstreamed on the grounds
> that this generally cleans up the build system in accordance with the
> principle that "feature foo" variab
On Mon, 30 Jul 2018, John Ericson wrote:
> That said, it is my tentative understanding that the point of having config-ml
> is to cordon-off all the necessarily-multilib-specific logic so it doesn't
> pollute everything else. When that script isn't run, I think the Makefiles
> already contain defa
On Tue, 31 Jul 2018, Bogdan Harjoc wrote:
> With fresh git sources and contrib/gcc_update the tests pass:
>
> === gcc Summary ===
>
> # of expected passes 133500
> # of expected failures 422
> # of unsupported tests 2104
>
> gcc-build/gcc/xgcc version 9.0.0 20180730 (experimental) (GCC)
>
> I
On Tue, 31 Jul 2018, David Malcolm wrote:
> I didn't exhaustively check every callsite to the changed calls; I'm
> assuming that -Wformat during bootstrap has effectively checked that
> for me. Though now I think about it, I note that we use
> HOST_WIDE_INT_PRINT_DEC in many places: is this guara
On Tue, 24 Jul 2018, Jakub Jelinek wrote:
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
> release branches?
>
> 2018-07-24 Jakub Jelinek
>
> PR c/85704
> * c-typeck.c (field_decl_cmp): New function.
> (output_pending_init_elements): Use it for fie
On Tue, 31 Jul 2018, Jakub Jelinek wrote:
> On Tue, Jul 31, 2018 at 08:04:58PM +0000, Joseph Myers wrote:
> > On Tue, 24 Jul 2018, Jakub Jelinek wrote:
> >
> > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
> > > release branches?
>
On Wed, 1 Aug 2018, Bogdan Harjoc wrote:
> So array[0] < component < array[2], which loops (I removed the gdb p
> commands for field_array[1] and so on).
Is the key thing here that you end up with DECL_NAME (field) == NULL_TREE,
but DECL_NAME (field_array[bot]) != NULL_TREE - and in this particu
On Thu, 25 May 2023, Qing Zhao via Gcc-patches wrote:
> > On May 25, 2023, at 4:51 PM, Joseph Myers wrote:
> >
> > The documentation in this case is OK, though claims about how a future
> > version will behave have a poor track record (we tend to end up with such
>
On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote:
> > What if the string is a wide string? I don't expect that to work (either
> > as a matter of interface design, or in the present code), but I think that
> > case should have a specific check and error.
>
> Dump question: how to check whe
On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote:
> Another question: is it better for me to rearrange the Patch 1/2 and Patch
> 2/2 a little bit,
> to put the FE , doc change and corresponding testing case together into one
> patch, (you have approved the FE part of change in Patch 1/2).
On Fri, 26 May 2023, Martin Uecker via Gcc-patches wrote:
> c: -Wstringop-overflow for parameters with forward-declared sizes
>
> Warnings from -Wstringop-overflow do not appear for parameters declared
> as VLAs when the bound refers to a parameter forward declaration. This
>
On Mon, 29 May 2023, Martin Uecker via Gcc-patches wrote:
> Support instrumentation of function arguments for functions
> called via a declaration. We can support only simple size
What do you mean by "via a declaration"?
If the *definition* is visible (and known to be the definition use
On Tue, 30 May 2023, Qing Zhao via Gcc-patches wrote:
> Joseph,
>
> could you please review this patch and see whether it's Okay for commit
> now?
This version is OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
> Hi, Joseph,
>
> A question here: can an identifier in C be a wide char string?
Identifiers and strings are different kinds of tokens; an identifier can't
be a string of any kind, wide or narrow. It just so happens that the
proposed inte
On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
> Are you suggesting to use identifier directly as the argument of the
> attribute?
> I tried this in the beginning, however, the current parser for the attribute
> argument can not identify that this identifier is a field identifier inside
>
On Sat, 10 Jun 2023, Jakub Jelinek via Gcc-patches wrote:
> I have looked at gnulib stdckdint.h and they are full of workarounds
> for various compilers, EDG doesn't do this, clang <= 14 can't multiply
> __int128, ..., so I think the header belongs into the compiler rather
> than C library, becaus
On Tue, 13 Jun 2023, Jakub Jelinek via Gcc-patches wrote:
> There is always the possibility to have the header co-owned by both
> the compiler and C library, limits.h style.
> Just
> #if __has_include_next()
> # include_next
> #endif
> perhaps guarded with some macro at the end of the GCC versio
On Tue, 13 Jun 2023, Thomas Schwinge wrote:
> Hi!
>
> On 2023-06-05T14:25:18+0200, I wrote:
> > OK to push the attached
> > "driver: Forward '-lgfortran', '-lm' to offloading compilation"?
> > (We didn't have a PR open for that, or did we?)
>
> Ping.
OK.
--
Joseph S. Myers
jos...@codesourcery
On Tue, 13 Jun 2023, Jakub Jelinek via Gcc-patches wrote:
> Yeah, having say __builtin_{clz,ctz,ffs,popcount,parity} variants which would
> be typegeneric and would allow say any normal integral or _BitInt type
> (or just unsigned versions thereof?) would be useful. Even without _BitInt
> we have
On Tue, 13 Jun 2023, Paul Eggert wrote:
> > There is always the possibility to have the header co-owned by both
> > the compiler and C library, limits.h style.
> > Just
> > #if __has_include_next()
> > # include_next
> > #endif
>
> I don't see how you could implement __has_include_next() for
> a
On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
> Comparing B with A, I don’t see too much benefit, either from
> user-interface point of view, or from implementation point of view.
>
> For implementation, both A and B need to search the fields of the
> containing structure by the name of
On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
> B. The argument of the new attribute “counted_by” is an identifier that can be
> accepted by “c_parser_attribute_arguments”:
>
> struct trailing_array_B {
> Int count;
> int array_B[] __attribute ((counted_by (count)));
> };
>
>
> From
On Mon, 17 Jul 2023, Michael Matz via Gcc-patches wrote:
> So, essentially you want unignorable attributes, right? Then implement
> exactly that: add one new keyword "__known_attribute__" (invent a better
> name, maybe :) ), semantics exactly as with __attribute__ (including using
> the same u
On Mon, 24 Jul 2023, Jakub Jelinek via Gcc-patches wrote:
> I believe it is only +- which has this problematic behavior and I think
fma has the same property (of rounding-mode-dependent exact results), but
I think that's not relevant here?
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, 27 Jul 2023, Jakub Jelinek via Gcc-patches wrote:
> - _BitInt(N) bit-fields aren't supported yet (the patch rejects them); I'd
> like
> to enable those incrementally, but don't really see details on how such
> bit-fields should be laid-out in memory nor passed inside of function
> a
I think there should be tests for _Atomic _BitInt types. Hopefully atomic
compound assignment just works via the logic for compare-and-exchange
loops, but does e.g. atomic_fetch_add work with _Atomic _BitInt types?
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 28 Jul 2023, Jakub Jelinek via Gcc-patches wrote:
> I had a brief look at libbid and am totally unimpressed.
> Seems we don't implement {,unsigned} __int128 <-> _Decimal{32,64,128}
> conversions at all (we emit calls to __bid_* functions which don't exist),
That's bug 65833.
> the librar
On Fri, 28 Jul 2023, Jakub Jelinek via Gcc-patches wrote:
> The C++ way of dealing with this is using __builtin_clear_padding,
> done on atomic stores/updates of the atomic memory (padding is cleared
> if any on the value to be stored, or on the expected and desired values).
>
> I don't know enou
On Fri, 28 Jul 2023, Jakub Jelinek via Gcc-patches wrote:
> But I ran into a compiler divergence on _Generic with bit-field expressions.
> My understanding is that _Generic controlling expression undergoes array
> to pointer and function to pointer conversions, but not integral promotions
> (other
On Tue, 18 Jul 2023, Hamza Mahfooz wrote:
> Resolves:
> PR c/65213 - Extend -Wmissing-declarations to variables [i.e. add
> -Wmissing-variable-declarations]
>
> gcc/c-family/ChangeLog:
>
> PR c/65213
> * c.opt (-Wmissing-variable-declarations): New option.
>
> gcc/c/ChangeLog:
>
>
This patch is OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 28 Jul 2023, Jason Merrill via Gcc-patches wrote:
> > Thanks, I had thought there could be a potential issue with needing to also
> > check cpp_get_options(pfile)->traditional. But looking at it more, there's
> > no
> > code path currently that can end up here in traditional mode, so yes w
On Mon, 31 Jul 2023, Martin Uecker via Gcc-patches wrote:
> Joseph, I would appreciate if you could take a look at this?
>
> This fixes the remaining issues which requires me to turn the
> warnings off with -Wno-vla-parameter and -Wno-nonnull in my
> projects.
The front-end changes are OK.
--
On Mon, 31 Jul 2023, Hamza Mahfooz wrote:
> Hey Joseph,
>
> On Fri, Jul 28 2023 at 08:32:31 PM +00:00:00, Joseph Myers
> wrote:
> > > OK.
> >
> > --
> > Joseph S. Myers
> > jos...@codesourcery.com
>
> Since I don't have write acces
On Mon, 31 Jul 2023, Lewis Hyatt via Gcc-patches wrote:
> I added some additional testcases from the PR for x86. The other targets
> that support `#pragma GCC target' (aarch64, arm, nios2, powerpc, s390)
> already had tests verifying that the pragma sets macros as expected; here I
> have added -sa
On Tue, 1 Aug 2023, Michael Matz via Gcc-patches wrote:
> Only because cmpxchg is defined in terms of memcpy/memcmp. If it were
> defined in terms of the == operator (obviously applied recursively
> member-wise for structs) and simple-assignment that wouldn't be a problem.
It also wouldn't w
On Thu, 7 Jul 2022, Kito Cheng wrote:
> +/* Implement TARGET_MANGLE_TYPE. */
> +
> +static const char *
> +riscv_mangle_type (const_tree type)
> +{
> + /* Half-precision float. */
> + if (TREE_CODE (type) == REAL_TYPE && TYPE_PRECISION (type) == 16)
> +return "Dh";
Are you sure you wish t
On Mon, 11 Jul 2022, Lewis Hyatt via Gcc-patches wrote:
> Hello-
>
> As discussed here:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598136.html
>
> Here is another short patch that improves "#pragma GCC diagnostic" handling.
> Longer term, it will be desirable to make the handling of t
On Tue, 19 Jul 2022, Maciej W. Rozycki wrote:
> Our documentation indicates that it is the `-frounding-math' invocation
> option that controls whether we respect what the FENV_ACCESS pragma
> would imply, should we implement it, regarding the floating point
> environment. It is only a part of
On Sun, 24 Jul 2022, Tom Honermann via Gcc-patches wrote:
> Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
> (see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
> require that the target diagnostic option be enabled for the preprocessor
> (see c_option_
On Mon, 25 Jul 2022, Tom Honermann via Gcc-patches wrote:
> diff --git a/gcc/ginclude/stdatomic.h b/gcc/ginclude/stdatomic.h
> index bfcfdf664c7..75ed7965689 100644
> --- a/gcc/ginclude/stdatomic.h
> +++ b/gcc/ginclude/stdatomic.h
> @@ -49,6 +49,10 @@ typedef _Atomic long atomic_long;
> typedef _
On Mon, 25 Jul 2022, Tom Honermann via Gcc-patches wrote:
> This change provides new tests for the core language and compiler
> dependent library changes adopted for C2X via WG14 N2653.
I'd expect this patch also to add tests verifying that u8"" strings have
the old type for C11 (unless there ar
On Mon, 1 Aug 2022, Tom Honermann via Gcc-patches wrote:
> diff --git a/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
> b/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
> new file mode 100644
> index 000..3456105563a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
> @@ -
On Mon, 1 Aug 2022, Tom Honermann via Gcc-patches wrote:
> This change provides new tests for the core language and compiler
> dependent library changes adopted for C2X via WG14 N2653.
Could you please send a complete patch series? I'm not sure what the
matching patches 1 and 3 are. Also, I do
On Tue, 2 Aug 2022, Tom Honermann via Gcc-patches wrote:
> This patch implements the core language and compiler dependent library
> changes adopted for C2X via WG14 N2653. The changes include:
> - Change of type for UTF-8 string literals from array of const char to
> array of const char8_t (uns
On Tue, 2 Aug 2022, Tom Honermann via Gcc-patches wrote:
> This patch corrects handling of UTF-8 character literals in preprocessing
> directives so that they are treated as unsigned types in char8_t enabled
> C++ modes (C++17 with -fchar8_t or C++20 without -fno-char8_t). Previously,
> UTF-8 char
On Fri, 5 Aug 2022, Jose E. Marchesi via Gcc-patches wrote:
> +Wcompare-distinct-pointer-types
> +C C++ Var(warn_compare_distinct_pointer_types) Warning Init(1)
> +Warn if pointers of distinct types are compared without a cast.
There's no implementation for C++ in this patch, so the option should
On Mon, 8 Aug 2022, Tom Honermann via Gcc-patches wrote:
> On 8/2/22 6:14 PM, Joseph Myers wrote:
> > On Tue, 2 Aug 2022, Tom Honermann via Gcc-patches wrote:
> >
> > > This patch corrects handling of UTF-8 character literals in preprocessing
> > > directives so
On Wed, 2 Aug 2023, Tamar Christina via Gcc-patches wrote:
> Ping.
>
> > -Original Message-
> > From: Tamar Christina
> > Sent: Wednesday, July 26, 2023 8:35 PM
> > To: Tamar Christina ; gcc-patches@gcc.gnu.org
> > Cc: nd ; jos...@codesourcery.com
> > Subject: RE: [PATCH 2/2][frontend]:
On Thu, 3 Aug 2023, Jakub Jelinek via Gcc-patches wrote:
> --- gcc/testsuite/gcc.dg/bitint-18.c.jj 2023-08-03 12:26:35.510922996
> +0200
> +++ gcc/testsuite/gcc.dg/bitint-18.c 2023-08-03 12:26:42.114831050 +0200
> @@ -0,0 +1,44 @@
> +/* PR c/102989 */
> +/* { dg-do compile { target bitint
On Thu, 3 Aug 2023, Qing Zhao via Gcc-patches wrote:
> +@opindex Wflex-array-member-not-at-end
> +@opindex Wno-flex-array-member-not-at-end
> +@item -Wflex-array-member-not-at-end
I'd expect this to have @r{(C and C++ only)} to indicate what languages
the option applies to. OK with that change.
On Fri, 4 Aug 2023, Martin Uecker via Gcc-patches wrote:
> Here is a patch to reduce false positives in _Generic.
>
> Bootstrapped and regression tested on x86_64-linux.
>
> Martin
>
> c: _Generic should not warn in non-active branches [PR68193,PR97100]
>
> To avoid false diagnosti
On Fri, 4 Aug 2023, Richard Biener via Gcc-patches wrote:
> > Sorry, I hoped it wouldn't take me almost 3 months and would be much shorter
> > as well, but clearly I'm not good at estimating stuff...
>
> Well, it’s definitely feature creep with now the _Decimal and bitfield stuff …
I think featu
On Tue, 8 Aug 2023, Arsen Arsenović via Gcc-patches wrote:
> Yes. Libtool was forked over a decade ago. My next project is syncing
> upstream and us back up. Unsure about pkg.m4.
Note as per previous discussions that libtool commit
3334f7ed5851ef1e96b052f2984c4acdbf39e20c will need reverting
Do you have any comments on the interaction of AVX10 with the
micro-architecture levels defined in the ABI (and supported with
glibc-hwcaps directories in glibc)? Given that the levels are cumulative,
should we take it that any future levels will be ones supporting 512-bit
vector width for AVX
On Tue, 8 Aug 2023, David Malcolm via Gcc-patches wrote:
> However, consider a situation in which someone attempted to, say, embed
> libgccjit inside a web browser to generate machine code from
> JavaScript, where the JavaScript is potentially controlled by an
> attacker. I think we want to expli
On Wed, 9 Aug 2023, Arsen Arsenović via Gcc-patches wrote:
> Joseph Myers writes:
>
> > On Tue, 8 Aug 2023, Arsen Arsenović via Gcc-patches wrote:
> >
> >> Yes. Libtool was forked over a decade ago. My next project is syncing
> >> upstream and us back up.
On Wed, 9 Aug 2023, Wang, Phoebe via Gcc-patches wrote:
> Proposal 3: Change the ABI of 512-bit vector and always be
> passed/returned from memory.
Changing ABIs like that for existing code that has worked for some time on
existing hardware is a bad idea.
At this point it seems appropriate to
On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote:
> - _Complex _BitInt(N) isn't supported; again mainly because none of the psABIs
> mention how those should be passed/returned; in a limited way they are
> supported internally because the internal functions into which
> __builtin_{add
The GCC_ENABLE_PLUGINS configure logic for detecting whether -rdynamic
is necessary and supported uses an appropriate objdump for $host
binaries (running on $build) in cases where $host is $build or
$target.
However, it is missing such logic in the case where $host is neither
$build nor $target, r
On Thu, 10 Aug 2023, Martin Uecker via Gcc-patches wrote:
> c: Support for -Wuseless-cast [RR84510]
>
> Add support for Wuseless-cast C (and ObjC).
>
> PR c/84510
>
> gcc/c/:
> * c-typeck.cc (build_c_cast): Add warning.
>
> gcc/doc/:
> * invoke.texi: Update.
>
On Thu, 10 Aug 2023, Richard Biener via Gcc-patches wrote:
> Isn't this situation similar to the not defined ABI when passing generic
> vectors (via __attribute__((vector_size))) that do not map to vectors
> supported
> by the current ISA? There's cases like vector<2> char or vector<1> double
>
On Thu, 10 Aug 2023, Jakub Jelinek via Gcc-patches wrote:
> I'd like to ping this patch. Reposting it as the extend.texi hunk
> didn't apply cleanly anymore. Bootstrapped/regtested again on x86_64-linux
> and i686-linux, ok for trunk?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, 10 Aug 2023, Jason Merrill via Gcc-patches wrote:
> On 8/10/23 11:35, Jakub Jelinek wrote:
> > Hi!
> >
> > I'd like to ping this patch. Reposting it as I found a typo in the
> > documentation - s/builtin-in/built-in/. Bootstrapped/regtested again
> > on x86_64-linux and i686-linux, ok f
On Thu, 10 Aug 2023, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The following patch (on top of the stdckdint.h patch and _BitInt patch
> series) adds a test for _BitInt diagnostics of ckd_{add,sub,mul} macros.
I remain unconvinced that diagnosing use with types where it's clear what
the rig
On Fri, 11 Aug 2023, Jakub Jelinek wrote:
> All that is diagnosed is when result is bool or enum (any kind). Even for
I'd suggest tests that other nonsense cases are diagnosed, such as
floating-point or pointer arguments or results (hopefully such cases are
already diagnosed and just need test
On Fri, 11 Aug 2023, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Aug 11, 2023 at 01:25:38PM +0000, Joseph Myers wrote:
> > On Fri, 11 Aug 2023, Jakub Jelinek wrote:
> >
> > > All that is diagnosed is when result is bool or enum (any kind). Even for
> >
&g
On Tue, 15 Aug 2023, chenxiaolong wrote:
> In the implementation process, the "q" suffix function is
> Re-register and associate the "__float128" type with the
> "long double" type so that the compiler can handle the
> corresponding function correctly. The functions i
On Wed, 16 Aug 2023, chenxiaolong wrote:
> Thanks for the tip! Similar functions (e.g. __builtin_fabsf128
> (_Float128 a) are already supported by the compiler and can be handled
> correctly, but functions that can be implemented on the LoongArch
> architecture directly using the "bstrins" directi
On Wed, 16 Aug 2023, Richard Sandiford via Gcc-patches wrote:
> Would it be OK to add support for:
>
> [[__extension__ ...]]
>
> to suppress the pedwarn about using [[]] prior to C2X? Then we can
That seems like a plausible feature to add.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, 16 Aug 2023, Eric Gallager via Gcc-patches wrote:
> PING
>
> On Tue, Aug 8, 2023 at 8:17 PM Eric Gallager wrote:
> >
> > On Tue, May 30, 2023 at 5:42 PM Eric Gallager wrote:
> > >
> > > PR109836 is a request to have -Wpointer-sign enabled by default. There
> > > were points of disagreem
On Thu, 17 Aug 2023, Xi Ruoyao via Gcc-patches wrote:
> So I guess we just need
>
> builtin_define ("__builtin_fabsq=__builtin_fabsf128");
> builtin_define ("__builtin_nanq=__builtin_nanf128");
>
> etc. to map the "q" builtins to "f128" builtins if we really need the
> "q" builtins.
>
> Joseph:
On Thu, 17 Aug 2023, Jose E. Marchesi via Gcc-patches wrote:
> +@opindex Wcompare-distinct-pointer-types
> +@item -Wcompare-distinct-pointer-types
This @item should say @r{(C and Objective-C only)}, since the option isn't
implemented for C++. OK with that change.
--
Joseph S. Myers
jos...@cod
On Fri, 18 Aug 2023, Richard Sandiford via Gcc-patches wrote:
> [[]] attributes are a recent addition to C, but as a GNU extension,
> GCC allows them to be used in C11 and earlier. Normally this use
> would trigger a pedwarn (for -pedantic, -Wc11-c2x-compat, etc.).
>
> This patch allows the pedw
On Tue, 15 Aug 2023, FX Coudert via Gcc-patches wrote:
> I am currently retesting the patches on various archs (Linux and Darwin)
> after a final rebase, but various previous versions were
> regression-tested, and have been shipped for a long time in Homebrew.
>
> OK to commit?
The driver chan
On Fri, 18 Aug 2023, Iain Sandoe via Gcc-patches wrote:
> There is quite extensive Apple Developer documentation on delivering
> packages with co-installed libraries using @rpath (that is the intended
> mechanism for delivery since it allows drag-and-drop installation and
> moving of built appl
On Mon, 21 Aug 2023, Jakub Jelinek via Gcc-patches wrote:
> Joseph, could I ask now at least for an overall design review of the
> C patches (8-10,13) whether its interfaces with middle-end are ok,
> so that Richi can review the middle-end parts?
I am fine with the interface to the middle-end par
On Fri, 16 Jun 2023, Martin Uecker via Gcc-patches wrote:
> > Note that no expressions can start with the '.' token at present. As soon
> > as you invent a new kind of expression that can start with that token, you
> > have syntactic ambiguity.
> >
> > struct s1 { int c; char a[(struct s2 { in
On Fri, 16 Jun 2023, Qing Zhao via Gcc-patches wrote:
> > So for
> >
> > struct foo { int c; int buf[(struct { int d; }){ .d = .c }]; };
> >
> > one knows during parsing that the .d is a designator
> > and that .c is not.
>
> Therefore, the above should be invalid based on this rule since .c i
On Wed, 21 Jun 2023, Richard Biener via Gcc-patches wrote:
> > This patch sets the address space of the array type to that of the
> > element type.
> >
> > Regression tests for avr look ok. Ok for trunk?
>
> The patch looks OK to me but please let a C frontend maintainer
> double-check (I'v
1 - 100 of 2945 matches
Mail list logo
