On Fri, Jul 18, 2025 at 09:07:35AM +0200, Richard Biener wrote:
> The PR shows that the uninit analysis limits are set too low in
> cases we lower switches to ifs as happens on s390x for a linux
> kernel TU. This causes false positive uninit diagnostics as we
> abort the attempt to prove that a va
On Thu, Jul 17, 2025 at 06:44:08PM -0400, Jason Merrill wrote:
> Hmm, perhaps, for stateful evaluation like define_aggregate. But we could
> address that with a flag on the STATIC_ASSERT like this patch puts on the
> STMT_EXPR.
Sure.
Jakub
On Thu, Jul 17, 2025 at 05:31:27PM -0400, Jason Merrill wrote:
> On 7/16/25 10:49 AM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > This patch implements consteval blocks, as specified by P2996.
> > They aren't very useful without define
.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk/15.2/14.4?
2025-07-17 Jakub Jelinek
PR tree-optimization/121131
* gimple-fold.cc (fold_nonarray_ctor_reference): Use
TREE_INT_CST_LOW (TYPE_SIZE ()) instead of
GET_MODE_BITSIZE (SCALAR_INT_TYPE_MODE
On Thu, Jul 17, 2025 at 03:26:05PM +, Qing Zhao wrote:
> How about add a new flag to distinguish these two cases, and put it to the
> 3th argument:
>
>ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE,
> TYPE_OF_SIZE + ACCESS_MODE + IS_POINTER, TYPE_SIZE_UNIT
> for element)
On Thu, Jul 17, 2025 at 03:31:57PM +0200, Tomasz Kamiński wrote:
> From: Jonathan Wakely
>
> Implement std::inplace_vector as specified in P0843R14, without follow
> up papers, in particular P3074R7 (trivial unions). In consequence
I think implementation of that paper is waiting mainly for
https
On Wed, Jul 16, 2025 at 09:22:19PM +, Qing Zhao wrote:
> Yes, the above solution could also resolve the undefined behavior issue. We
> can certainly go
> with this approach.
Another option is to use .ACCESS_WITH_SIZE (with different flags compared to
the FAM cases) solely on reads from the
On Tue, Jul 15, 2025 at 06:39:42PM +, Qing Zhao wrote:
> I re-implemented the patch based on B to fix PR120929, however, the approach
> B brings undefined behavior into the application.
>
> (Actually, I met this issue in the previous implementation but forgot to
> documented it.
> This iss
pret_cast not being valid during constant evaluation
time.
So, this patch just tests non-array std::relocate at both runtime and
constexpr time, everything else at runtime only.
2025-07-16 Jakub Jelinek
PR c++/119064
* include/bits/version.def (trivially_relocatable):
_error/* 19_diagnostics/logic_error/*
19_diagnostics/headers/stdexcept/* 20_util/expected/* 20_util/variant/*
20_util/optional/*'"
2025-07-16 Jakub Jelinek
* include/bits/version.def: Implement C++26 P3378R2 - constexpr
exception types.
(constexpr_exceptio
On Tue, Jul 15, 2025 at 09:02:09AM -0700, Andrew Pinski wrote:
> For aarch64, libgcc is built with -Werror, after the latest
> -Wunused-but-set* commit (r16-2258-g0eac9cfee8cb0b21d), a new warning
> showed up:
> ```
> ../../../gcc/libgcc/config/libbid/bid_binarydecimal.c: In function
> ‘__binary32_
On Tue, Jul 15, 2025 at 08:36:46AM -0700, Andrew Pinski wrote:
> On Tue, Jul 15, 2025 at 6:06 AM Jakub Jelinek wrote:
> >
> > On Tue, Jul 15, 2025 at 08:21:50AM -0400, Jason Merrill wrote:
> > > Given the above that seems rather unlikely, but I suppose it's fine if
On Tue, Jul 15, 2025 at 08:21:50AM -0400, Jason Merrill wrote:
> Given the above that seems rather unlikely, but I suppose it's fine if you
> want to do it that way. The patch is OK either way.
Committed just the v2 patch. I can test your patch next with other patches,
or do you want to test/com
On Tue, Jul 15, 2025 at 08:30:33AM -0400, Jason Merrill wrote:
> > The diagnostic only changed for C++26, and I'm not sure why (the _S_at
> > function isn't constexpr, so why wasn't it failing there before?)
>
> In C++23, we could see that the outermost thing in the expression is a call
> to _M_er
On Mon, Jul 14, 2025 at 11:58:32PM -0400, Jason Merrill wrote:
> Coming back to this comment, it still seems to me that we can generalize
> this and ignore anything cast to void here, as in the below; after something
> has been cast to void, it can no longer be read. I don't get any
> regressions
expr (and cp_build_unary_op), so your
simplification of cp_fold is ok and doesn't regress anything.
Here is an updated patch, with your cp_fold change, and different
finish_unary_op_expr change.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-07-14 Jakub Jelinek
On Mon, Jul 14, 2025 at 12:11:18PM +0200, Tomasz Kaminski wrote:
> > + if (__builtin_expect(__fwd, true))
> >
> We have a preference to use [[likely]] attribute when possible.
Ok, changed to
if (__fwd) [[likely]]
in my copy.
>
> > + {
> > + for (; __first != __last; ++__
On Fri, Jul 11, 2025 at 03:12:44PM +0100, Jonathan Wakely wrote:
> The if-consteval branches in std::make_exception_ptr and
> std::exception_ptr_cast use a try-catch block, which gives an error for
> -fno-exceptions. Just make them return a null pointer at compile-time
> when -fno-exceptions is use
On Sun, Jul 13, 2025 at 05:28:21PM +0100, Jonathan Wakely wrote:
> ---
>
> This is an anachronism: ChangeLog entries should never be part of the
> patch, because nobody should be editing them locally and including them
> in a commit. Whether you can self-approve or not isn't relevant.
>
> OK for
On Fri, Jul 11, 2025 at 02:34:24PM -0400, Jason Merrill wrote:
> But by the time we get to cp_fold, DECL_READ_P should have already been set
> appropriately when we built the thing we're now folding. And calling
Clearly it hasn't been, otherwise I'd need to patch different spots as well.
> mark_
On Fri, Jul 11, 2025 at 12:26:54PM -0400, Jason Merrill wrote:
> On 7/11/25 9:09 AM, Jakub Jelinek wrote:
> > On Thu, Jul 10, 2025 at 04:35:49PM -0400, Jason Merrill wrote:
> > > > --- gcc/cp/cp-gimplify.cc.jj2025-04-12 21:41:42.660924514 +0200
> > > > +++ gc
Hi!
On Tue, Jun 17, 2025 at 01:14:03PM +0200, Jakub Jelinek wrote:
> Here is a new version of the library side of the C++26 P2786R13 paper.
> For if constexpr the patch uses __builtin_constant_p trick to figure
> out if __result is non-equality comparable with __first, it adds recursion
On Fri, Jul 11, 2025 at 02:26:28PM +0100, Jonathan Wakely wrote:
> On Fri, 11 Jul 2025 at 14:19, Jakub Jelinek wrote:
> >
> > On Fri, Jul 11, 2025 at 01:47:18PM +0100, Jonathan Wakely wrote:
> > Thanks for doing this.
> >
> > > @@ -301,8 +301,9 @@ names
On Fri, Jul 11, 2025 at 01:47:18PM +0100, Jonathan Wakely wrote:
Thanks for doing this.
> @@ -301,8 +301,9 @@ namespace std _GLIBCXX_VISIBILITY(default)
> _GLIBCXX26_CONSTEXPR exception_ptr
> make_exception_ptr(_Ex __ex) _GLIBCXX_USE_NOEXCEPT
> {
> -#if __cplusplus >= 202400L
> +#if
On Fri, Jul 11, 2025 at 02:11:05PM +0100, Jonathan Wakely wrote:
> On Fri, 11 Jul 2025 at 14:02, Jonathan Wakely wrote:
> >
> > The if-consteval branches in std::make_exception_ptr and
> > std::exception_ptr_cast use a try-catch block, which gives an error for
> > -fno-exceptions. Just make them r
On Thu, Jul 10, 2025 at 04:35:49PM -0400, Jason Merrill wrote:
> > --- gcc/cp/cp-gimplify.cc.jj2025-04-12 21:41:42.660924514 +0200
> > +++ gcc/cp/cp-gimplify.cc 2025-04-23 21:33:19.050931604 +0200
> > @@ -3200,7 +3200,23 @@ cp_fold (tree x, fold_flags_t flags)
> > loc = EXPR_LOCAT
Hi!
This was a regression introduced by r16-1893 (and its backports) for C++,
though for C it had false positive warning for years. Fixed by r16-2000
(and its backports).
Tested on x86_64-linux, committed to trunk as obvious.
2025-07-11 Jakub Jelinek
PR c++/120954
* c-c
for trunk/15.2?
2025-07-11 Jakub Jelinek
Martin Jambor
PR ipa/121023
* ipa-fnsummary.cc (compute_fn_summary): Disallow signature changes
on cfun->has_musttail functions.
* c-c++-common/musttail32.c: New test.
--- gcc/ipa-fnsummary.cc.jj 2
p;& (type_memfn_quals (type) == TYPE_UNQUALIFIED
> > + && type_memfn_rqual (type) == REF_QUAL_NONE)));
>
> The inner parens seem redundant.
I was just moving the function earlier. Anyway, changed.
So far lightly tested, can bootstrap/regtest it overnight.
2
On Thu, Jul 10, 2025 at 05:49:53PM +, Qing Zhao wrote:
> One more note here, previously, ACCESS_MODE has 5 values:
> -1: Unknown access semantics
> 0: none
> 1: read_only
> 2: write_only
> 3: read_write
>
> For counted_by, I passed “-1” to the .ACCESS_WITH_SIZE.
>
On Thu, Jul 10, 2025 at 05:27:50PM +, Qing Zhao wrote:
> ACCESS_MODE is only for a future work to reimplement the attribute
> access with the internal function .ACCESS_WITH_SIZE.
>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-access-function-attribute
>
> For th
On Thu, Jul 10, 2025 at 04:03:30PM +, Qing Zhao wrote:
> gcc/c-family/ChangeLog:
>
> * c-ubsan.cc (get_bound_from_access_with_size): Adjust the position
> of the arguments per the new design.
>
> gcc/c/ChangeLog:
>
> * c-typeck.cc (build_counted_by_ref): Update comments.
>
On Thu, Jul 10, 2025 at 04:03:29PM +, Qing Zhao wrote:
> The size of the element of the FAM _cannot_ reliably depends on the original
> TYPE of the FAM that we passed as the 6th parameter to the .ACCESS_WITH_SIZE:
>
> TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (gimple_call_arg (call, 5
>
>
On Thu, Jul 10, 2025 at 07:26:52AM +, Kyrylo Tkachov wrote:
> … “Tunning” looks like a typo as well, should likely be “Tuning”.
You're right, but because like often it occurs in another place as well,
I've committed this separately as obvious.
Thanks for finding this.
2025
Hi!
While I'm not a native English speaker, I believe all the uses
of bellow (roar/bark/...) in comments in gcc are meant to be
below (beneath/under/...).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-07-10 Jakub Jelinek
gcc/
* tree-vect-lo
On Tue, Jul 08, 2025 at 09:43:20PM -0400, Jason Merrill wrote:
Thanks for the review.
Working on the rest (most of it already have in my working copy).
> > case CLEANUP_POINT_EXPR:
> > {
> > - auto_vec cleanups;
> > + auto_vec cleanups;
>
> What's the rationale for this increase
On Tue, Jul 08, 2025 at 11:54:23PM -0600, Alex (Waffl3x) wrote:
> --- a/gcc/tree.h
> +++ b/gcc/tree.h
> @@ -571,6 +571,15 @@ extern void omp_clause_range_check_failed (const_tree,
> const char *, int,
>TREE_CHECK6 (T, INTEGER_TYPE, ENUMERAL_TYPE, BOOLEAN_TYPE, REAL_TYPE,
> \
>
On Tue, Jul 08, 2025 at 03:17:39PM +0200, Richard Biener wrote:
> The following avoids inlining the actual main() (renamed to
> guality_main) into the guality plumbing. This can cause
> jump threading opportunities to appear and generally increase
> the chance what we actually test isn't what we t
On Tue, Jul 08, 2025 at 08:15:30AM +0200, Richard Biener wrote:
> > No. Because (most of the) pointer conversions are useless, if you have
> > _2 = &something.fam[0];
> > ...
> > _4 = &something.fam;
> > _5 = .ACCESS_WITH_SIZE (_4, ...);
> > (or whatever else where _4 has the carefully chosen p
On Mon, Jul 07, 2025 at 07:51:52PM -0400, Siddhesh Poyarekar wrote:
> On 2025-07-07 17:47, Jakub Jelinek wrote:
> > Even 6 arguments is IMHO too much.
> > /* Expand the IFN_ACCESS_WITH_SIZE function:
> > ACCESS_WITH_SIZE (REF_TO_OBJ, REF_T
On Mon, Jul 07, 2025 at 09:18:53PM +, Qing Zhao wrote:
> From OLD:
>
> _2 = &a->c;
> _3 = &a->count;
> _1 = .ACCESS_WITH_SIZE (_2, _3, 1, 0, -1, 0B);
> _4 = *_1;
> D.2964 = __builtin_dynamic_object_size (_4, 1);
>
> To NEW:
>
> _2 = a->c;
> _3 = &a->count;
> _1 = .ACCESS_WITH_SIZE (_
On Mon, Jul 07, 2025 at 11:59:48AM -0400, Jason Merrill wrote:
> > Another case are targets with implicit -fno-delete-null-pointer-checks or
> > when users use that explicitly. In that case one variable or function can
> > actually end up being at address 0, so am not sure if it is correct to
> >
On Thu, Jul 03, 2025 at 09:35:49AM -0400, Jason Merrill wrote:
> On 7/2/25 7:58 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk?
> >
> > -- >8 --
> >
> > Here the flag -fno-delete-null-pointer-checks causes the trivial address
> > co
On Mon, Jul 07, 2025 at 09:07:14AM -0400, Siddhesh Poyarekar wrote:
> On 2025-07-07 08:48, Jakub Jelinek wrote:
> > > The return value of .ACCESS_WITH_SIZE clobbering PTR (that subsequently
> > > gets
> > > passed to __builtin_dynamic_object_size) should be suffici
On Mon, Jul 07, 2025 at 07:21:26AM -0400, Siddhesh Poyarekar wrote:
> > is .ACCESS_WITH_SIZE documented? I can't find it documented in the
> > internals manual, internal-fn.def has
>
> It's documented in tree-object-size.cc as:
>
> /* Compute __builtin_object_size for a CALL to .ACCESS_WITH_SIZE
On Sat, Jul 05, 2025 at 08:46:31AM -0400, Jason Merrill wrote:
> I think we want these diagnostics enabled by default; I don't feel strongly
> about unconditional pedwarn vs. permerror.
So like this then?
2025-07-05 Jakub Jelinek
PR c++/84009
so that in the future
we don't need to differentiate it between range for and expansion
statements.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-07-05 Jakub Jelinek
PR c++/84009
* parser.cc (cp_parser_decomposition_declaration): Ped
Hi!
No idea how this slipped in, I'm terribly sorry.
Strangely nothing in the testsuite has caught this, so I've added
a new test for that.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
and for 15.2, 14.4, 13.4 and 12.5.
2025-07-03 Jakub Jelinek
On Thu, Jul 03, 2025 at 08:12:22PM +0200, Richard Biener wrote:
> > So, instead at least for now, the following patch keeps doing the
> > optimization, just doesn't perform it in pointer arithmetics.
> > pointer_int_sum itself actually adds the multiplication by size_exp,
> > so ptr + expr is turne
- cst)
into
ptr p+ ((sizetype)expr * size_exp +- (sizetype)cst * size_exp)
and
ptr - (expr +- cst)
into
ptr p+ -((sizetype)expr * size_exp +- (sizetype)cst * size_exp)
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-07-03 Jakub Jelinek
PR c/12083
On Thu, Jul 03, 2025 at 02:43:43PM +0200, Michael Matz wrote:
> Hello,
>
> On Thu, 3 Jul 2025, Yuao Ma wrote:
>
> > This patch adds the required function for Fortran trigonometric functions to
> > work with glibc versions prior to 2.26. It's based on glibc source commit
> > 632d895f3e5d98162f77b9
n body, if the test is not explicitly prepared for those.
> This might happen when the testsuite is passed additional options as
> e.g. via --target_board='unix{-fstack-protector-all}'.
>
> Co-Authored-By: Jakub Jelinek
> ---
> gcc/doc/sourcebuild.texi
On Thu, Jul 03, 2025 at 08:33:45AM +0200, Richard Biener wrote:
> On Wed, Jul 2, 2025 at 11:32 PM Siddhesh Poyarekar
> wrote:
> >
> > MEM_REF cast of a subobject to its containing object has negative
> > offsets, which objsz sees as an invalid access. Support this use case
> > by peeking into th
On Wed, Jul 02, 2025 at 11:43:13AM +0200, Stefan Schulze Frielinghaus wrote:
> On Tue, Jul 01, 2025 at 06:33:12PM +0200, Jakub Jelinek wrote:
> > On Tue, Jul 01, 2025 at 03:47:53PM +0200, Stefan Schulze Frielinghaus wrote:
> > > In the past years I have started to use more and
do any dump tests and just define the checking/main
for those.
Ok for trunk (both or just the first one)?
Jakub
2025-07-02 Jakub Jelinek
PR testsuite/118567
* gcc.target/powerpc/vsx-vectorize-1.c: Remove includes, checking
part of main1 and main.
* gcc.tar
On Tue, Jul 01, 2025 at 12:04:04PM -0500, Segher Boessenkool wrote:
> On Mon, Feb 17, 2025 at 02:28:50PM +, Alex Coplan wrote:
> > After the recent alignment peeling enhancements in the vectorizer we
> > started vectorizing the "checking" loops (that check for the right
> > result) in gcc.targe
The following patch fixes that by using arrays of 2 elements, so that
the overwriting of 1 byte happens to the part of the same variable.
Tested on powerpc64le-linux both without and with -fstack-protector-strong,
ok for trunk and 15.2/14.4?
2025-07-01 Jakub Jelinek
PR testsuite/12
On Tue, Jul 01, 2025 at 03:47:53PM +0200, Stefan Schulze Frielinghaus wrote:
> In the past years I have started to use more and more function body
> checks whenever gcc emits optimal code for a function. With that I
> wanted to make sure that we do not regress like introducing unnecessary
> extend
for trunk/15.2?
2025-07-01 Jakub Jelinek
* gcc.target/s390/vector/vec-abs-emu.c: Add -fno-stack-protector
to dg-options.
* gcc.target/s390/vector/vec-max-emu.c: Likewise.
* gcc.target/s390/vector/vec-min-emu.c: Likewise.
--- gcc/testsuite/gcc.target/s39
On Tue, Jul 01, 2025 at 10:55:00AM +0200, Jakub Jelinek wrote:
> I've actually tried
> --- gcc/passes.def2025-06-30 22:16:11.258688529 +0200
> +++ gcc/passes.def2025-07-01 10:47:37.020634803 +0200
> @@ -444,9 +444,9 @@ along with GCC; see the file COPYING
get with __int128 type, or
pdp endian gets __int128 support.
Tested on x86_64-linux and s390x-linux, committed to trunk and 15.2 as
obvious.
2025-07-01 Jakub Jelinek
PR ipa/119318
PR testsuite/120082
* gcc.dg/ipa/pr119318.c (main): Expect different result on big en
On Tue, Jul 01, 2025 at 11:23:48AM +0200, Richard Biener wrote:
> > Given that empty_eh_cleanup handles already almost everything, just
> > didn't know how to handle the resx to internal step which was quite
> > trivial, I thought it will be easier not to reorder cleanup_eh pass,
> > especially for
On Tue, Jul 01, 2025 at 10:43:09AM +0200, Richard Biener wrote:
> > The following patch fixes that by
> > 1) moving the musttail pass 2 passes earlier (this is mostly just
> >for -O0/-Og, for normal optimization levels musttail calls are
> >handled in the tailc pass), i.e. across the sanopt
On Sat, Jun 28, 2025 at 02:19:59AM +, Yuao Ma wrote:
> > signbit is documented to be a macro, so please don't declare
> > int signbit (double);
> > function in the testcase and instead of signbit use __builtin_signbit.
>
> This is indeed my negligence. Done.
>
> If everything looks good, coul
On Mon, Jun 30, 2025 at 04:56:47PM -0400, Jason Merrill wrote:
> On 6/30/25 4:24 PM, Jakub Jelinek wrote:
> > On Mon, Jun 30, 2025 at 03:55:46PM -0400, Jason Merrill wrote:
> > > Might go with my earlier !TREE_SIDE_EFFECTS && tree_invariant_p
> > > suggestion?
On Mon, Jun 30, 2025 at 03:55:46PM -0400, Jason Merrill wrote:
> Might go with my earlier !TREE_SIDE_EFFECTS && tree_invariant_p suggestion?
If you mean the following, it passes the 2 testcases and I can surely
bootstrap/regtest it tonight.
2025-06-30 Jakub Jelinek
PR
On Mon, Jun 30, 2025 at 05:14:06PM +0200, Jakub Jelinek wrote:
> 1) for idx being INTEGER_CST (case for which I believe the change has been
>added) it keeps doing what it did
> 2) if both op1 and op2 are arrays with invariant address or pointers to
>something with invariant
is only relevant to functions with musttail calls,
so something quite rare and only at -O0/-Og (unless one e.g.
disables the tailc pass).
2025-06-30 Jakub Jelinek
PR middle-end/120608
* passes.def (pass_musttail): Move before pass_sanopt.
* tree-tailcall.cc (empty_eh_cl
u've mentioned.
> > For release branches, would unshare_expr (idx) for the second arm be
> > enough?
>
> Ah, no, that doesn't help with SAVE_EXPR.
Neither with TARGET_EXPRs I think, for neither of those I think unshare_expr
actually unshares them and for a good reason, it can&
On Mon, Jun 23, 2025 at 09:47:51PM +, Joseph Myers wrote:
> On Mon, 23 Jun 2025, Jakub Jelinek wrote:
>
> > Hi!
> >
> > I'd like to ping some C family patches:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681741.html
> >
On Fri, Jun 27, 2025 at 06:49:12PM -0400, Jason Merrill wrote:
> On 6/27/25 5:58 PM, Jakub Jelinek wrote:
> > The following testcase is miscompiled since the introduction of UBSan,
> > cp_build_array_ref COND_EXPR handling replaces
> > (cond ? a : b)[idx] with cond ? a[idx] :
f the
branches.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-06-27 Jakub Jelinek
PR c++/120471
* typeck.cc (cp_build_array_ref) : Use cp_save_expr
on idx. If it has TREE_SIDE_EFFECTS, add it as lhs of COMPOUND_EXPR
in first COND_EXPR arg
ss
deleted during phase 2 when after backslash) ends the preprocessing
directive.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
15.2?
2025-06-27 Jakub Jelinek
PR c++/120845
libcpp/
* lex.cc (cpp_maybe_module_directive): If premature CPP_PRAGMA_EOL
On Fri, Jun 27, 2025 at 05:17:55PM -0400, Jason Merrill wrote:
> I've pushed those changes.
Great.
> > /* For a non-pointer simple base reference, express it as a
> > COMPONENT_REF
> >without taking its address (and so causing lambda capture, 91933).
> > */
> > - if (code == PLUS_
On Fri, Jun 27, 2025 at 03:38:32PM +, Yuao Ma wrote:
> Hi Jakub,
>
> > Please don't include math.h here.
>
> Done.
>
> > And instead of this line use __builtin_acospi (0.5).
> > and, in dejagnu for runtime tests we prefer __builtin_abort on failure, so
>
> Done.
Oh, one more thing.
signbit
On Fri, Jun 27, 2025 at 03:04:35PM +, Yuao Ma wrote:
> > I think the __builtin_constant_p(acospi(0.5)) approach is usable, but would
> > be much better done on the lib/target-supports.exp side.
> > So, have foldable_pi_based_trigonometry effective target, which would test
> > if __builtin_const
On Fri, Jun 27, 2025 at 02:00:26PM +0200, Richard Biener wrote:
> > + gcc_assert (RECORD_OR_UNION_TYPE_P (container));
> > +
> > + for (tree t = TYPE_FIELDS (container); t; t = DECL_CHAIN (t))
> > +{
> > + if (TREE_CODE (t) != FIELD_DECL)
> > +continue;
> > +
> > + tree byte_off
On Fri, Jun 27, 2025 at 03:33:39PM +0800, Yang Yujie wrote:
> [1] https://github.com/loongson/la-abi-specs
>
> PR target/117599
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.h: Define a PROMOTE_MODE case for
> small _BitInts.
> * config/loongarch/loongarch.cc (loong
On Fri, Jun 27, 2025 at 03:33:38PM +0800, Yang Yujie wrote:
> libgcc/ChangeLog:
>
> * config.host: Remove unused code. Include LoongArch-specific
> tmake_files after the OS-specific ones.
This should be reviewed by LoongArch maintainers.
Jakub
On Fri, Jun 27, 2025 at 03:33:36PM +0800, Yang Yujie wrote:
> In LoongArch psABI, large _BitInt(N) (N > 64) objects are only
> extended to fill the highest 8-byte chunk that contains any used bit,
> but the size of such a large _BitInt type is a multiple of their
> 16-byte alignment. So there may
On Fri, Jun 27, 2025 at 03:33:37PM +0800, Yang Yujie wrote:
> A _BitInt value may rely on a conversion to become properly extended.
> So a conversion to _BitInt is not trivially removable even if the
> types of the result and the operand have the same precision and size.
>
> This patches fixes gcc
On Fri, Jun 27, 2025 at 03:33:35PM +0800, Yang Yujie wrote:
> @@ -11291,6 +11296,13 @@ expand_expr_real_1 (tree exp, rtx target,
> machine_mode tmode,
>type = TREE_TYPE (exp);
>mode = TYPE_MODE (type);
>unsignedp = TYPE_UNSIGNED (type);
> + if (bitint_extended == -1 && TREE_CODE (type
On Fri, Jun 27, 2025 at 03:33:34PM +0800, Yang Yujie wrote:
> For targets that treat small _BitInts like the fundamental
> integral types, we should allow their machine modes to be promoted
> in the same way.
>
> gcc/ChangeLog:
>
> * explow.cc (promote_function_mode): Add a case for
>
On Fri, Jun 27, 2025 at 08:17:46AM +0200, Tobias Burnus wrote:
> Hi Yuao,
>
>
> Yuao Ma wrote:
> > >//but the testcases don't seem to be conditionalized on this. Would the
> > >//new tests fail if gcc is built against an insufficiently recent version
> > >//of mpfr,
> …
> > The test case is indee
On Thu, Jun 26, 2025 at 01:33:08PM +0200, Jakub Jelinek wrote:
> I get some regressions (which I didn't get with the earlier patch, but
> it isn't obvious by what it has been caused):
It ICEs were caused by the canonicalize_obj_off change and indeed
> The ICEs are a
bugs in libsupc++ or what we emit in the vtables
or if there aren't some constexpr dynamic_cast bugs too.
2025-06-26 Jakub Jelinek
PR c++/120777
gcc/
* gimple-fold.cc (gimple_get_virt_method_for_vtable): Revert
2018-09-18 changes.
gcc/c-family/
it from std.cc.in as well.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-06-26 Jakub Jelinek
* include/bits/version.def (exception_ptr_cast): Add.
* include/bits/version.h: Regenerate.
* libsupc++/exception: Define __glibcxx_want_exce
Can change that.
2025-06-26 Jakub Jelinek
gcc/cp/
* cp-trait.def: Implement C++26 P2830R10 - Constexpr Type Ordering.
(TYPE_ORDER): New.
* method.cc (type_order_value): Define.
* cp-tree.h (type_order_value): Declare.
* semantics.cc (trait_expr_value): U
trunk?
2025-06-24 Jakub Jelinek
PR c++/120773
* decl.cc (grokfndecl): Implement C++26 P3618R0 - Allow attaching
main to the global module. Only pedwarn for current_lang_name
other than lang_name_cplusplus and adjust pedwarn wording.
* g++.dg/parse/linka
86_64-linux and i686-linux, ok for trunk?
2025-06-25 Jakub Jelinek
gcc/cp/
* cp-trait.def: Implement C++26 P2830R10 - Constexpr Type Ordering.
(TYPE_ORDER): New.
* method.cc (type_order_value): Define.
* cp-tree.h (type_order_value): Declare.
* semanti
method of
exception_ptr, so that P3748R0 then can use if consteval and provide a
constant evaluation variant of it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-06-25 Jakub Jelinek
* include/bits/version.def (exception_ptr_cast): Add.
* include/bits
On Wed, Jun 25, 2025 at 12:37:33PM -0400, Jason Merrill wrote:
> Ah, looks like fixed_type_or_null needs to handle a CALL_EXPR of class type
> like a TARGET_EXPR. I also wonder why the call isn't already wrapped in a
> TARGET_EXPR by build_cxx_call=>build_cplus_new at this point.
Wonder if it has
On Tue, Jun 24, 2025 at 05:19:59PM -0400, Jason Merrill wrote:
> I think we could move the initialization of the fixed_type_p and
> virtual_access variables up, they don't need to be after cp_build_addr_expr.
I don't understand why it doesn't depend on cp_build_addr_expr.
I've tried the following
On Tue, Jun 24, 2025 at 10:33:01PM +0200, Jakub Jelinek wrote:
> On Tue, Jun 24, 2025 at 08:25:33PM +0200, Jakub Jelinek wrote:
> > > > know enough about dynamic_cast and cxx_eval_dynamic_cast_fn
> > > > to figure out what needs to change there. It is hint -2 that
On Tue, Jun 24, 2025 at 08:25:33PM +0200, Jakub Jelinek wrote:
> > > know enough about dynamic_cast and cxx_eval_dynamic_cast_fn
> > > to figure out what needs to change there. It is hint -2 that
> > > fails, not hint -1.
> >
> > Yes, this is a -
On Tue, Jun 24, 2025 at 11:57:01AM -0400, Jason Merrill wrote:
> > The two other errors on the testcase are expectedly gone with C++26,
> > but the last one remains. The problem is that when parsing nm3.a
> > inside of mutable_subobjects()::A::f()
> > build_class_member_access_expr calls build_bas
and cxx_eval_dynamic_cast_fn
to figure out what needs to change there. It is hint -2 that
fails, not hint -1.
In any case, this has been successfully bootstrapped/regtested on
x86_64-linux and i686-linux.
2025-06-24 Jakub Jelinek
PR c++/120777
gcc/c-family/
* c-cppbuiltin.cc
On Mon, Jun 23, 2025 at 11:06:39AM -0400, Jason Merrill wrote:
> P3491 define_static_* includes some reflection bits, but the core
> functionality is independent of reflection, so let's give it its own row in
> the table.
Ok. I've committed the following incremental patch then (plus created one
n
Hi!
I've created new PRs for the new papers and committed the following to
update cxx-status.html.
The html omits the R suffixes on papers which aren't public in wg21.link
link yet, we can change those incrementally.
diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
i
Hi!
I'd like to ping 2 patches:
PR120608 - expand: Allow musttail tail calls with -fsanitize=address
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686689.html
PR120608 - tailc: Allow musttail tail calls with -fsanitize=address
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686692.
1 - 100 of 2488 matches
Mail list logo
