On Tue, Sep 09, 2025 at 04:52:08PM +0200, Jason Merrill wrote:
> > Ok. I wonder whether to keep adding CLOBBER (bob) as before to the start
> > of some of the ctors for -std=c++23 and earlier (unless
> > -ftrivial-auto-var-init= is specified). The current patch does that. If we
> > stop doing th
On Wed, Sep 10, 2025 at 10:06:07AM +0200, Jason Merrill wrote:
> It looks like these tests won't run on m68k, can you make at least the -2
> test run (and pass) there?
Sure, tested there just with a cross (and only on those 2 new tests).
2025-09-10 Jakub Jelinek
d backup
files for 2 tests.
Ok for trunk?
2025-09-10 Jakub Jelinek
* lib/lto.exp (lto-execute-1): Search for _1.* etc. files
only with a list of known extensions.
--- gcc/testsuite/lib/lto.exp.jj2025-04-08 14:09:22.197851050 +0200
+++ gcc/testsuite/lib/lto.exp 2025-09-0
;
location, optimizable_arith_overflow returned non-zero and so the
cast after IMAGPART_EXPR was after it and then a = _1; will copy from
the temporary VAR_DECL to memory.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/15/14?
2025-09-10 Jakub Jelinek
PR middle-end/
eces
cases it stores those by pieces using a new callback very similar to
string_cst_read_str, for the rest (unfortunately) forces it into a memory
and copies from there.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/15
branch?
2025-09-10 Jakub Jelinek
On Tue, Sep 09, 2025 at 02:58:58PM +, Qing Zhao wrote:
> Just briefly checked the v2, I have the following question:
>
> There is no change to the routine expand_DEFERRED_INIT for the new “init_type
> == AUTO_INIT_CXX26”,
> Is this intentional?
Yes. I've checked and all the checks during t
On Tue, Sep 09, 2025 at 06:08:12PM +0300, Ville Voutilainen wrote:
> The fail() can fall through when the contracts are evaluated in the
> "observe" evaluation mode.
> In that case it's not an actual "fail", it will call the contract
> violation handler and return from that.
>
> And then the conce
On Tue, Sep 09, 2025 at 09:32:41PM +0200, Harald Anlauf wrote:
> Running the related tests under valgrind did not reveal anything.
> The maybe-uninitialized errors are bogus.
They aren't, because the compiler doesn't know that those 17 or how many
calls in between
switch (code->resolved_isym->id
On Tue, Sep 09, 2025 at 06:14:40PM +0300, Ville Voutilainen wrote:
> On Tue, 9 Sept 2025 at 18:11, Jakub Jelinek wrote:
> >
> > On Tue, Sep 09, 2025 at 06:08:12PM +0300, Ville Voutilainen wrote:
> > > The fail() can fall through when the contracts are evaluated in the
&g
On Tue, Sep 09, 2025 at 04:52:08PM +0200, Jason Merrill wrote:
> > I'll try to work on this next, but it won't be trivial. The forward gotos
> > and switch cases are one thing and backward gotos another one, both need
> > to be handled differently, plus make it work properly with [[fallthrough]]
>
On Tue, Sep 09, 2025 at 03:30:07PM +0200, Michael Matz wrote:
> But it would also be an invalid transformation of the compiler. So I
> can't quite see the worry. The second check ("*p > 5") is conditional on
> the first one:
>
> if (!p)
> fail()
> if (*p > 5)
> fail2()
>
> The *p
On Fri, Sep 05, 2025 at 05:19:06PM +0200, Jason Merrill wrote:
> > Regarding temporaries, I wonder if we want to .DEFERRED_INIT them when
> > expanding TARGET_EXPRs in the gimplifier (but whether to do that always
> > when flag_auto_var_init != AUTO_INIT_UNINITIALIZED or for C++26 only),
> > or if
On Mon, Sep 08, 2025 at 05:40:00PM +0200, Jason Merrill wrote:
> > Also, the question is if we don't use the TYPE_SIZE_UNIT or TYPE_SIZE
> > to determine how many hex digits to print, what else should be used.
> > For decimal floating point, I think we need to keep doing what we used
> > before, th
On Mon, Sep 08, 2025 at 04:03:21PM +0200, Jason Merrill wrote:
> On 9/8/25 8:11 AM, Matthias Kretz wrote:
> > Andrew Pinski [Friday, 5 September 2025, 22:57:02 CEST]:
> > > > It seems that Clang and GCC disagree on mangling 80-Bit long double:
> > > >
> > > > https://compiler-explorer.com/z/W1d64P
On Mon, Sep 08, 2025 at 09:51:32PM +0800, Xi Ruoyao wrote:
> Besides r16-3595, there's another bug in this test: with -std=c23 the
> token _Sat isn't recognized as a keyword at all, thus an error massage
> different from the expected will be outputted.
>
> Fix it by using -std=gnu23 instead.
>
>
On Mon, Sep 08, 2025 at 03:05:58PM +0200, Richard Biener wrote:
> is reduced to __builtin_abort () (for C++). That's because it's
> __builtin_unreachable () at the end. I am not aware of any
> other "UB" than missed return that we turn into unreachable(),
> even
>
> unsigned int foo (unsigned in
On Mon, Sep 08, 2025 at 01:22:17PM +0100, Iain Sandoe wrote:
> For the testcase attached to the patch.
>
> Do we consider that the addition to x is considered observable?
I don't think so, it isn't any kind of barrier for moving statements
around in either direction.
I think a non-const/pure call
On Mon, Sep 08, 2025 at 12:23:49PM +0200, Matthias Kretz wrote:
> + if (words == 0)
> +{
> + /* _Float16 is the only supported type smaller than 32 bits. */
This comment is incorrect, although the assert is right.
Both _Float16 and decltype (0.0bf16) (aka std::bfloat16_t) are supported
t
On Mon, Sep 08, 2025 at 08:19:39AM +0200, Matthias Kretz wrote:
> Andrew Pinski [Friday, 5 September 2025, 22:50:30 CEST]:
> > On Fri, Sep 5, 2025 at 4:06 AM Matthias Kretz wrote:
> > > diff --git a/gcc/testsuite/g++.dg/pr121801_float16_cst_mangling.C b/gcc/
> > > testsuite/g++.dg/pr121801_float16
On Sat, Sep 06, 2025 at 03:54:31PM +1000, Nathaniel Shead wrote:
> * g++.dg/modules/default-arg-4_a.C: XFAIL bogus errors.
> * g++.dg/modules/default-arg-4_b.C: Likewise.
> --- a/gcc/testsuite/g++.dg/modules/default-arg-4_a.C
> +++ b/gcc/testsuite/g++.dg/modules/default-arg-4_a.C
> @@ -
On Mon, Sep 08, 2025 at 08:19:39AM +0200, Matthias Kretz wrote:
> Andrew Pinski [Friday, 5 September 2025, 22:50:30 CEST]:
> > On Fri, Sep 5, 2025 at 4:06 AM Matthias Kretz wrote:
> > > diff --git a/gcc/testsuite/g++.dg/pr121801_float16_cst_mangling.C b/gcc/
> > > testsuite/g++.dg/pr121801_float16
On Thu, Sep 04, 2025 at 07:47:17PM +, Qing Zhao wrote:
> > On Sep 4, 2025, at 11:01, Jakub Jelinek wrote:
> >
> > On Thu, Sep 04, 2025 at 02:45:16PM +0200, Jakub Jelinek via Gcc wrote:
> >> On Wed, Sep 03, 2025 at 03:38:53PM +0200, Jakub Jelinek via Gcc wrote:
&
On Sat, Sep 06, 2025 at 04:10:16PM +0200, Jason Merrill wrote:
> > > > 3. Should the paddings of the auto variables or temporaries be
> > > > zero-initialized per the standard?
> > >
> > > No.
> > Okay.
>
> I disagree, I think the padding should also be initialized; the
> specification says "the
On Fri, Sep 05, 2025 at 11:07:01AM +0200, Florian Weimer wrote:
> > +int x = 0;
> > +
> > +int
> > +here_b_ub ()
> > +{
> > + // missing return triggers UB (we must ignore the warning for this
> > test).
> > +}
> > +
> > +int
> > +main ()
> > +{
> > + __builtin_printf (" start \n");
> > + x +=
On Sat, Sep 06, 2025 at 03:27:53PM -0700, Andrew Pinski wrote:
> This new pass will ICE if the target does not define the macro_fusion_pair_p
> pass. The pass will not be useful in that case so it is best to return
> early.
>
> Pushed as obvious after a bootstrap on x86_64-linux-gnu.
>
> PR
trunk.
2025-09-06 Jakub Jelinek
* omp.h.in: Fix up formatting of __cplusplus >= 201103L
guarded code from libstc++ style to GCC/libgomp style.
--- libgomp/omp.h.in.jj 2025-09-06 03:19:29.002729171 +0200
+++ libgomp/omp.h.in2025-09-06 03:13:50.548210263 +0200
@@ -449,104
On Wed, Aug 13, 2025 at 12:55:40PM +0200, Jakub Jelinek wrote:
> Or if the multiple inclusion bits/functexcept.h header is too costly, we
> could instead split it into multiple headers, each with normal header
> guards:
> 1) bits/functexcept.h would stay for the __throw_* functions w
On Fri, Sep 05, 2025 at 05:19:06PM +0200, Jason Merrill wrote:
> > Regarding temporaries, I wonder if we want to .DEFERRED_INIT them when
> > expanding TARGET_EXPRs in the gimplifier (but whether to do that always
> > when flag_auto_var_init != AUTO_INIT_UNINITIALIZED or for C++26 only),
> > or if
On Fri, Sep 05, 2025 at 06:34:23PM +0200, Jason Merrill wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/pr121801_float16_cst_mangling.C
> > @@ -0,0 +1,12 @@
> > +// PR c++/121801
> > +// { dg-do compile { target c++20 } }
Not all targets have _Float16 support though.
So, I think you want
/
ed on x86_64-linux and i686-linux, committed to trunk
as obvious.
I really should rerun my scripts to search for this kind of errors in the
source soon.
2025-09-05 Jakub Jelinek
* constexpr.cc (cxx_eval_cxa_builtin_fn): Add missing word separating
space into invalid_nargs diagno
/regtested
on x86_64-linux and i686-linux, committed to trunk as obvious.
2025-09-05 Jakub Jelinek
* gcc.dg/fixed-point/bitint-1.c: Expect also error about _Sat used
without _Fract/_Accum.
--- gcc/testsuite/gcc.dg/fixed-point/bitint-1.c.jj 2023-11-09
09:04:19.666528529 +0100
On Fri, Sep 05, 2025 at 10:30:49AM +0100, Matthew Malcomson wrote:
> Ok -- TBH I don't have any extra details on this argument right now and your
> point on it's feasibility seems quite convincing. (Timezones are slowing
> communication with other compiler team about why it's hard in their case --
On Fri, Sep 05, 2025 at 08:51:10AM +0100, Iain Sandoe wrote:
> > BARRIER in RTL is like __builtin_unreachable (), so the observable
> > checkpoint certainly can't be represented like that.
> > Anyway, my point is that one call call std::observable_checkpoint ()
> > or exit (0) in any external funct
On Fri, Sep 05, 2025 at 08:40:27AM +0100, Iain Sandoe wrote:
> > On 5 Sep 2025, at 08:22, Jakub Jelinek wrote:
> >
> > On Fri, Sep 05, 2025 at 08:35:43AM +0200, Richard Biener wrote:
> >>> i.e. keep it as a call to an optimization barrier until runtime
> >>
On Fri, Sep 05, 2025 at 08:35:43AM +0200, Richard Biener wrote:
> > i.e. keep it as a call to an optimization barrier until runtime
> > but don't really do anything at that point.
>
> That's probably equivalent to the builtin.
But to a builtin which is preserved until end of expansion (not sure
i
On Fri, Sep 05, 2025 at 09:37:42AM +0200, Richard Biener wrote:
> Yes. I'll note that while we fixed some issues with code motion across
> possible exit points we do not have good means of testing for invalid
> code motion of UB invoking stmts. Guessing from the ones that actually
> caused traps
in declaration specifiers"
msgid "both %qs and %<_Float%d%s%> in declaration specifiers"
msgid "both %<__int%d%> and %qs in declaration specifiers"
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-09-05 Jakub Jelinek
* c-decl.cc
On Thu, Sep 04, 2025 at 05:24:15PM -0700, Kees Cook wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/kcfi/kcfi-adjacency.c
> @@ -0,0 +1,73 @@
> +/* Test KCFI check/transfer adjacency - regression test for instruction
> + insertion. */
> +/* { dg-do compile } */
> +/* { dg-options "-fsanitize=
On Thu, Sep 04, 2025 at 05:59:25PM +0100, Iain Sandoe wrote:
> PR c++/119060
>
> gcc/ChangeLog:
>
> * builtins.cc (expand_builtin): Handle BUILT_IN_OBSERVABLE_CHKPT.
> * builtins.def (BUILT_IN_OBSERVABLE_CHKPT): New.
>
> gcc/c-family/ChangeLog:
>
> * c-common.cc: Add __b
On Thu, Sep 04, 2025 at 02:45:16PM +0200, Jakub Jelinek via Gcc wrote:
> On Wed, Sep 03, 2025 at 03:38:53PM +0200, Jakub Jelinek via Gcc wrote:
> > But there is one thing the paper doesn't care about, which looks like a show
> > stopper to me, in particular the stuff -Wt
On Thu, Sep 04, 2025 at 09:58:14AM +0200, Richard Biener wrote:
> I'm in favor of disabling but I also fear the code will bitrot quickly if so?
> We might also want to have a set of testcases for the -fcompare-debug
> issues that are fixed by the change of defaults?
>
> Otherwise I defer to Jakub
On Tue, Sep 02, 2025 at 04:51:37PM +0200, Jakub Jelinek wrote:
> What about the following instead?
>
> The first two hunks aren't strictly necessary, I'm just trying to
> avoid calling build_qualified_type when it won't be needed.
>
> At least on s390x-linux (tri
On Wed, Sep 03, 2025 at 06:41:08PM +0200, Richard Biener wrote:
> > I'd be worried about C++23 deducing this, but e.g.
> > struct S;
> > extern S t;
> > struct S
> > {
> > void foo (this S *p, int x);
> > int s;
> > };
> > void S::foo (this S *p, int x)
> > {
> > p->s += x;
> > p = &t;
> > p->
On Wed, Sep 03, 2025 at 11:45:31AM +0100, Matthew Malcomson wrote:
> Ah -- to be honest we never considered this seriously due to how we came to
> this work.
>
> The implicit reason in how we made the decision is:
> - Using pattern matching would mean libstdc++ will be using the CAS loop to
> impl
On Wed, Sep 03, 2025 at 03:27:08PM +0200, Richard Biener wrote:
> When inside a method then we know the this pointer points to
> an object of at least the size of the methods base type. We
> can use this to compute more references as not trapping and
> enable invariant motion and in turn vectoriza
glibc side I think it will need to remain exported
for ABI compatibility :(
Tested on x86_64-linux, ok for trunk?
2025-09-01 Jakub Jelinek
* builtins.def: Implement C2Y N3577 - Rename s/uimaxabs/umaxabs/.
(BUILT_IN_UIMAXABS): Rename to ...
(BUILT_IN_UMAXABS): ... thi
test what libstdc++ uses anymore,
so the following patch uses -128 in all the spots.
Ok for trunk?
2025-09-02 Jakub Jelinek
* gcc.target/s390/spaceship-fp-1.c: Expect .SPACESHIP call with
-128 as last argument instead of 2.
(TEST): Use -128 instead of 2.
* gcc.t
On Tue, Sep 02, 2025 at 03:28:46PM +0200, Richard Biener wrote:
> On Tue, 2 Sep 2025, Jakub Jelinek wrote:
>
> > On Tue, Sep 02, 2025 at 11:34:59AM +0200, Richard Biener wrote:
> > >
> > > Oops, now also to the list.
> >
> > If so, it needs to punt on a
F F F F F F F
#define H G G G G G G G G
#define I H H H H H H H H
#define J I I I I I I I I
J J J J
__COUNTER__
just takes too long to preprocess).
Plus I've included all the snippets from the paper into one testcase.
Tested on x86_64-linux, ok for trunk?
2025-09-01 Jakub Je
and back to m_limb_type.
And on the other side on stores, for !bitint_extended happily store whatever
the whole m_limb_type value contains, for bitint_extended do the cast to
smaller precision and back on the writes.
2025-09-02 Jakub Jelinek
PR target/117599
* gimple-lower-bitint
On Tue, Sep 02, 2025 at 11:34:59AM +0200, Richard Biener wrote:
>
> Oops, now also to the list.
If so, it needs to punt on anything that uses something more than once.
So, alg_add_factor and alg_sub_factor are always bad (so return NULL),
because they do use accumulator both in the PLUS/MINUS and
On Tue, Sep 02, 2025 at 05:01:37AM -0500, Segher Boessenkool wrote:
> On Tue, Sep 02, 2025 at 07:56:58AM +0200, Jakub Jelinek wrote:
> > On Tue, Sep 02, 2025 at 09:32:15AM +0530, Surya Kumari Jangala wrote:
> > > Ping.
> > >
> > > Please review.
> >
&g
On Tue, Sep 02, 2025 at 10:36:52AM +0200, Richard Biener wrote:
> The recent change to vect_synth_mult_by_constant missed to handle
> the synth_shift_p case for alg_shift, so we still changed c * 4
> to c + c + c + c.
The reason for not handling alg_shift was that it expands (perhaps multiple
time
On Tue, Sep 02, 2025 at 12:03:59PM +0530, soum...@nvidia.com wrote:
> From: Soumya AR
>
> This patch adds builtin types and function declarations for integer atomic
> fetch
> min/max operations.
Do we really need the new builtins?
Isn't it better to just pattern recognize such operations using
past, so if
you have ideas how to change the code generation for the common case of
-1, 0, 1, -128 value, maybe it could be improved.
Bootstrapped/regtested on aarch64-linux, ok for trunk?
2025-09-02 Jakub Jelinek
PR testsuite/121732
PR target/117013
* g++.target/aa
mal programs never do that.
Another possibility would be to handle lines -1U and -2U as if it was say
-3U.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-09-02 Jakub Jelinek
PR middle-end/121663
* tree-cfg.cc (assign_discriminator): Change map argument
On Tue, Sep 02, 2025 at 09:32:15AM +0530, Surya Kumari Jangala wrote:
> Ping.
>
> Please review.
IMHO we shouldn't introduce new builtins for this, but instead
use new flag bits in the upper bits of the memorder arguments.
See how x86 uses __ATOMIC_HLE_ACQUIRE and __ATOMIC_HLE_RELEASE
in there.
On Fri, Aug 29, 2025 at 11:53:35PM -0700, Andrew Pinski wrote:
> >if (!TYPE_UNSIGNED (ty2) || !INTEGRAL_TYPE_P (ty2))
> > return false;
> > - if (TYPE_PRECISION (ty1) > TYPE_PRECISION (ty2))
> > + if (TYPE_PRECISION (ty2) != 8 || TYPE_PRECISION (ty1) < 8)
>
> Should 8 be
will not, but (x <=> y) <= 0 is fine (x <= y), because it
does raise those exceptions.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-08-30 Jakub Jelinek
PR tree-optimization/121698
* tree-ssa-phiopt.cc (spaceship_replacement): Adjust
Hi!
So, I had a look at the remaining part of C++26 P2686R4, which I think
we really should implement for GCC 16 because people are already filing
PRs about constexpr structured bindings or expansion statements not working
the way they should in some cases.
That plus the recent PR121670 and that
onstructible>>> {};
except that the is_aggregate part is more complex and can't be done purely
on the library side since CWG2605.
> For the rvalue case you can just use type1, and build_stub_object will add
> the rvalue reference.
Done.
2025-08-29 J
On Fri, Aug 29, 2025 at 10:15:33AM +0200, Richard Biener wrote:
> On Fri, 29 Aug 2025, Richard Biener wrote:
>
> > On Fri, 29 Aug 2025, Jakub Jelinek wrote:
> >
> > > Hi!
> > >
> > > Here is a variant of the patch which pretends there are also st
On Fri, Aug 29, 2025 at 10:56:45AM +0200, Tomasz Kaminski wrote:
> Yes, that is even better. C++ made me biased towards not using
> preprocessing,
> so I miss simple solutions.
Anyway, went with your requires case + added tests for starting
lifetime on static const variable.
2025-08-
Hi!
Here is a variant of the patch which pretends there are also stores
in the inline asms.
Plus the forgotten std.cc exports.
2025-08-29 Jakub Jelinek
* include/bits/version.def: Implement C++23 P2590R2 - Explicit
lifetime management.
(start_lifetime_as): New
On Fri, Aug 29, 2025 at 10:08:38AM +0200, Tomasz Kaminski wrote:
> > + if (sizeof(S) != sizeof(T))
> > +return;
> >
> These seem insufficient to prevent compilation errors that bit_cast(S{})
> would
> produce if their size is not much. My preference here would be to have some
> dr-require
> ex
On Thu, Aug 28, 2025 at 02:24:33PM -0700, Andi Kleen wrote:
> Jakub Jelinek writes:
>
> > On Wed, Aug 27, 2025 at 03:52:11PM +0200, Michal Jires wrote:
> >> This new pass heuristically detects symbols referenced by toplevel
> >> assembly to prevent their optimiza
On Fri, Aug 29, 2025 at 08:44:30AM +0200, Richard Biener wrote:
> You definitely cannot move loads across std::start_lifetime_as
> given they might be UB (wrt TBAA) on one of the "sides". So yes,
> it needs to appear as a store as well. But, since it isn't an
> actual store in the end, it may not
On Fri, Aug 29, 2025 at 08:48:02AM +0200, Tomasz Kaminski wrote:
> >From recent discussions, my understand was that this function can be
> implemented purely in library as:
> return launder(static_cast(memmove(p, p, sizeof(T;
It can't, we optimize memmove(p,p,whatever) away pretty much instant
On Thu, Aug 28, 2025 at 08:11:04PM +0200, Tomasz Kaminski wrote:
> Similar test, for Q being a base class, this is also aggregate in C++20.
> And if you could reorganize the library test so satic_assert follows the
> type definition,
> that would be great.
Done.
2025-08-28 Jakub Je
S type and be surprised by TBAA.
Though if it is a must-alias case, then we should be fine as well.
Though guess that would be the same case with a builtin.
Or shall we also pretend the inline asm modifies (or could modify) the
memory?
2025-08-28 Jakub Jelinek
* include/bits/version.d
On Wed, Aug 27, 2025 at 03:52:11PM +0200, Michal Jires wrote:
> This new pass heuristically detects symbols referenced by toplevel
> assembly to prevent their optimization.
>
> Heuristics is done by comparing identifiers in assembly to known
> symbols.
>
> The pass is split into 2 passes, in LGEN
mplicit lifetime types that you have, like Q.
This adds the AA, AB and AC cases both to the g++.dg test and libstdc++
test. Anything else you'd like to see?
2025-08-28 Jakub Jelinek
gcc/cp/
* cp-trait.def: Implement C++23 P2674R1 - A trait for implicit
lifetime types
not, but perhaps
there is some reason for that.
Because std::is_array_v is false, it returns false for that
as well, dunno if that shouldn't be changed for implicit-lifetime.
It accepts also VLAs.
Tested on x86_64-linux, ok for trunk?
2025-08-28 Jakub Jelinek
gcc/cp/
* cp-trait.def: Im
On Thu, Aug 28, 2025 at 04:50:15PM +0200, Jakub Jelinek wrote:
> On Thu, Aug 28, 2025 at 04:24:46PM +0200, Richard Biener wrote:
> > That said, if we ever want to improve on this (and solve the redundant
> > store elimination issue), we need an actual GIMPLE/RTL statement
>
On Thu, Aug 28, 2025 at 04:24:46PM +0200, Richard Biener wrote:
> That said, if we ever want to improve on this (and solve the redundant
> store elimination issue), we need an actual GIMPLE/RTL statement
> doing what std::start_lifetime_as does (but not generate code).
>
> Meaning, I'd vote for a
On Thu, Aug 28, 2025 at 02:08:12PM +0200, Jason Merrill wrote:
> > So, do you think for P2590R2 we want a purely library implementation which
> > does nothing (well, define the needed templates)?
> > Or do you prefer some builtin which will do nothing initially but might be
> > changed to do someth
On Thu, Aug 28, 2025 at 09:28:57AM +0200, Tomasz Kaminski wrote:
> I have no experience with backend optimization, so I would need help to fix
> the above.
> >From my side I could only offer reverting the change, but I do not think we
> should do so,
> see below.
I'll look at it momentarily.
That
On Thu, Aug 28, 2025 at 10:49:36AM +0200, Jason Merrill wrote:
> > I know, but P2590R2 is not implemented yet and as written in
> > https://gcc.gnu.org/PR106658 I have actually no idea what needs to be done
> > if anything on the compiler side. Because at least the GIMPLE model
> > basically allow
On Wed, Aug 27, 2025 at 10:21:30PM +0200, Tobias Burnus wrote:
> [gcn] gcc/configure.ac + install.texi - changes to detect HAVE_AS_LEB128
> [PR119367]
>
> The llvm-mc linker by default assemblies to another assembly file and not to
> an ELF
> binary; that usually does not matter – but for the LE
On Wed, Aug 27, 2025 at 07:45:14PM +0200, Tobias Burnus wrote:
> PR debug/119367
> * configure.ac (check_leb128_asflags): For gcn, use "--filetype=obj
> --arch=amdgcn", if supported.
> * configure: Regenerate.
> * doc/install.texi (amdgcn-*-*): Also add llvm-objdump to
Hi!
The following patch adds a readelf fallback if objdump nor otool don't
exist. All of GNU binutils readelf, eu-readelf and llvm-readelf can
handle it with those options.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-08-27 Jakub Jelinek
PR debug/1
tedly gas generated .debug_line is even smaller, 501374 bytes (with
-fpic and without -gno-as-loc{,view}-support options).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-08-27 Jakub Jelinek
PR debug/119367
* dwarf2out.cc (output_one_line_info_table)
that
>
> Sounds good.
The following passed bootstrap/regtest on x86_64-linux and i686-linux, ok?
2025-08-27 Jakub Jelinek
Jason Merrill
PR c++/121575
* pt.cc (tsubst_expr) : If DECL_CONTEXT (t) isn't a
template return t for PARM_DECLs with
On Mon, Aug 25, 2025 at 04:00:37PM -0400, Jason Merrill wrote:
> On 8/25/25 12:02 PM, Jakub Jelinek wrote:
> > On Mon, Aug 25, 2025 at 11:55:24AM -0400, Patrick Palka wrote:
> > > > The following patch fixes that by testing DECL_TEMPLATE_INFO, dunno
> > > > what e
On Wed, Aug 27, 2025 at 03:18:55PM +0200, Tomasz Kamiński wrote:
> For any minimum value of a signed type, its negation (with wraparound) results
> in the same value, behaving like zero. Representing the unordered result with
> this minimum value, along with 0 for equal, 1 for greater, and -1 for l
On Wed, Aug 27, 2025 at 03:50:26PM +0200, Richard Biener wrote:
> Ah, thanks for the write-up how to compute the number of uses.
>
> I'll test the following.
> --- a/gcc/tree-vect-patterns.cc
> +++ b/gcc/tree-vect-patterns.cc
> @@ -4303,6 +4303,8 @@ vect_synth_mult_by_constant (vec_info *vinfo, tr
On Wed, Aug 27, 2025 at 02:48:33PM +0200, Richard Biener wrote:
> I don't understand how synth-mult works, but it does introduce
> multiple uses of a reduction variable which will ultimatively
> fail vectorization (or ICE with a pending change). So avoid
> applying the pattern. I've tried to do s
On Tue, Aug 26, 2025 at 12:26:17AM +0200, Jakub Jelinek wrote:
> Unfortunately that version (unlike the previous one) regresses:
...
> UNRESOLVED: std/ranges/access/rend.cc -std=gnu++26 compilation failed to
> produce executable
>
> Will try to investigate what's going on
__ or __imag__ parts of static vars.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-08-27 Jakub Jelinek
PR c++/121678
* tree.cc (staticp): Handle REALPART_EXPR and IMAGPART_EXPR.
* g++.dg/ext/pr121678.C: New test.
* gcc.dg/pr121678.c: New
, tested on the
testcase on cross to powerpc64le-linux, ok for trunk?
2025-08-27 Jakub Jelinek
PR target/121520
* c-cppbuiltin.cc (c_cpp_builtins): Properly call cpp_warn
for __STDCPP_FLOAT_T__ if FLOATN_NX_TYPE_NODE (i) is NULL
for C++23 for non-extended ty
On Tue, Aug 26, 2025 at 12:46:51PM -0600, Sandra Loosemore wrote:
> > There is also no means to obtain
> > targetm.simd_clone.compute_vecsize_and_simdlen
> > on the non-offload compiler for the offload compiler (but see below).
>
> Right, this is what I was getting at. It doesn't make sense fo
On Tue, Aug 26, 2025 at 04:09:11PM +0200, Anna (navi) Figueiredo Gomes wrote:
> --- a/gcc/c-family/c-common.h
> +++ b/gcc/c-family/c-common.h
> @@ -97,11 +97,11 @@ enum rid
>RID_IMAGINARY,
>
>/* C */
> - RID_INT, RID_CHAR, RID_FLOAT,RID_DOUBLE, RID_VOID,
> - RID_ENUM,RID_S
On Mon, Aug 25, 2025 at 08:24:18PM -0600, Sandra Loosemore wrote:
> On 8/25/25 00:13, Jakub Jelinek wrote:
> > Yes, GCC doesn't have it implemented fully, but that doesn't mean it should
> > be ripped off, the implementation should be simply finished.
>
> Well,
GEN_INT (0).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-08-25 Jakub Jelinek
PR target/121658
* config/i386/sse.md (3 any_shift): Use const0_rtx
instead of GEN_INT (0).
(cond_ any_shift): Likewise. Formatting fix.
(3 any
ports.
2025-08-26 Jakub Jelinek
PR middle-end/121453
* omp-expand.cc (expand_omp_for_init_counts): Clear fd->loop.n2
before first zero count check if zero_iter1_bb is non-NULL upon
entry and fd->loop.n2 has not been written yet.
* gcc.dg/gomp/pr1214
On Mon, Aug 25, 2025 at 03:49:56PM -0400, Jason Merrill wrote:
> On 8/25/25 10:53 AM, Jakub Jelinek wrote:
> > On Mon, Aug 25, 2025 at 09:44:29AM -0400, Jason Merrill wrote:
> > > > --- gcc/cp/pt.cc.jj 2025-08-23 15:00:04.262787988 +0200
> > > > +++ gcc
On Mon, Aug 25, 2025 at 06:43:11PM +0200, Jakub Jelinek wrote:
> On Mon, Aug 25, 2025 at 10:23:52AM -0600, Sandra Loosemore wrote:
> > On 8/25/25 09:29, Jakub Jelinek wrote:
> > > On Mon, Aug 25, 2025 at 09:13:58AM -0600, Sandra Loosemore wrote:
> > > > How? Declare
On Mon, Aug 25, 2025 at 10:23:52AM -0600, Sandra Loosemore wrote:
> On 8/25/25 09:29, Jakub Jelinek wrote:
> > On Mon, Aug 25, 2025 at 09:13:58AM -0600, Sandra Loosemore wrote:
> > > How? Declare variant substitution presently happens primarily during
> > > gimplificat
On Mon, Aug 25, 2025 at 11:55:24AM -0400, Patrick Palka wrote:
> > The following patch fixes that by testing DECL_TEMPLATE_INFO, dunno
> > what else would be more appropriate for this function is a template,
> > maybe decl_dependent_p?
>
> I was going to suggest just replacing the !processing_temp
On Mon, Aug 25, 2025 at 05:29:13PM +0200, Jakub Jelinek wrote:
> That is not what should be done. The lookup should be done at the declare
> variant declaration side, that is how the design has been since that
> meeting. The compiler records the variants and later on just picks from
&g
1 - 100 of 2620 matches
Mail list logo
