On Wed, Jan 15, 2025 at 10:27:56AM -0500, Jason Merrill wrote:
> > @@ -7432,12 +7426,18 @@ reshape_init_r (tree type, reshape_iter
> > {
> > vec *v = 0;
> > CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, init);
> > - tree raw_init = cp_maybe_split_raw_data (d);
> > + bool inc_cur;
>
On 1/3/25 3:52 AM, Jakub Jelinek wrote:
Hi!
As the following testcases show (mangle80.C only after reversion of the
temporary reversion of C++ large array speedup commit), RAW_DATA_CST can
be seen during mangling of some templates and we ICE because
the mangler doesn't handle it.
The following
Sandra Loosemore wrote:
The code and test case previously implemented the OpenMP 5.0 spec,
which said in section 2.3.1:
"For functions within a declare target block, the target trait is added
to the beginning of the set..."
In OpenMP 5.1, this was changed to
"For device routines, the target tra
Dear all,
I've committed the attached obvious patch to reject an invalid NULL
in ALLOCATE after it was OK'ed in the PR by Steve.
Regtested on x86_64-pc-linux-gnu. Pushed as r15-6925-g892304f1fe .
Thanks,
Harald
From 892304f1fe3e808b9f498353c144f1ae0591 Mon Sep 17 00:00:00 2001
From: H
Sandra Loosemore wrote:
Additional shared C/C++ testcases are included in a subsequent patch in this
series.
LGTM.
Thanks,
Tobias
gcc/cp/ChangeLog
PR middle-end/112779
PR middle-end/113904
* cp-tree.h (struct saved_scope): Add new field
x_processing_omp_trait
When extracting the amount of vector elements, we currently
first check if the value is a contant with is_constant(),
followed by obtaining the value with to_constant(),
which internally calls is_constant() again.
We can address this by using is_constant (T*), which also
provides the constant value
As reported in PR118487, it is possible that the mask parameter
of a __builtin_shuffle() is not a VECTOR_CST.
If this is the case and checking is enabled then an ICE is triggered.
Let's add a check to fix this issue.
PR tree-optimization/118487
gcc/ChangeLog:
* tree-ssa-forwprop.
OK with one minor comment
On Wed, Jan 15, 2025 at 3:57 PM Monk C
> --- /dev/null
> +++ b/libgcc/config/riscv/shadow-stack-unwind.h
> @@ -0,0 +1,74 @@
> +/* _Unwind_Frames_Extra with shadow stack.
> + Copyright (C) 2016-2024 Free Software Foundation, Inc.
2025 rather than 2016-2024.
The following adds /* */ to dbg_line_numbers so there's the chance
to more easily lookup the ID of the match.pd line number used for
dumping when you want to debug a speicific replacement. It also cuts
the lines down to 10 entries.
static int dbg_line_numbers[1267] = {
/* 0 */ 161, 164
For things like
(x | 0x101) << 11
It's obvious to write:
ori $r4,$r4,257
slli.d $r4,$r4,11
But we are actually generating something insane:
lu12i.w $r12,524288>>12 # 0x8
ori $r12,$r12,2048
slli.d $r4,$r4,11
or
For bstrins, we can merge it into and3 instead of having a
separate define_insn.
For bstrpick, we can use the constraints to ensure the first source
register and the destination register are the same hardware register,
instead of emitting a move manually.
This will simplify the next commit where
On Wed, Jan 15, 2025 at 10:42:12AM +0100, Richard Biener wrote:
> Yes. I'll note there's a PR (or a bunch of) which are about
>
> x = FOO (y, ..);
>
>
> vs.
>
> FOO (y, ..);
>
>
> for FOO returning an argument (like for example memcpy). Where neither
> form is best in all cases. For your e
Hi!
And here is incremental (for now tested just on the new testcases)
patch to avoid VRP etc. to replace lhs of musttail call with something else.
2025-01-15 Jakub Jelinek
PR tree-optimization/118430
* tree-ssa-propagate.cc (may_propagate_copy): Return false if dest
i
On Wed, Jan 15, 2025 at 11:46:28AM +0100, Jakub Jelinek wrote:
> BTW, I think we don't optimize returns-arg stuff like that at least right
> now, and if we did, it wouldn't be through IPA-VRP, most of the returns-arg
> functions actually return a pointer, not integer and for prange we just
> track
> On 14 Jan 2025, at 20:45, Iain Buclaw wrote:
>
> Excerpts from Iain Sandoe's message of Januar 14, 2025 9:10 pm:
>> Tested on x86_64, i686 darwin17 and aarch64 darwin21,
>> OK for trunk, or alternate solution?
>> thanks,
>> Iain
>>
> Could a pull request be made upstream here?
>
> https:/
On Wed, Jan 15, 2025 at 04:33:26PM +0100, Jakub Jelinek wrote:
> I vaguely remember from writing the original patch (which introduced
> cp_maybe_split_raw_data) that here it actually mattered whether
> in the error case we move the reshape_iter or not and that it broke
> some tests, but I no longer
Re-reading again I realize I misread cache size from your question with cache
line size.
Cache size can be whatever yes. Cache line size must match.
But that doesn't change the fact that this patch is correct.
Thanks,
Tamar
From: Tamar Christina
Sent: Wednesday
Am 09.01.25 um 14:36 schrieb Thomas Koenig:
Am 09.01.25 um 14:34 schrieb Thomas Koenig:
This patch fixes and reorganizes dumping C prototypes.
And here is the "five seconds later, I realized I had forgotten
to attach the patch" e-mail...
... with the original text:
Hello world,
This patch
On 1/15/25 12:55 PM, Marek Polacek wrote:
On Wed, Jan 15, 2025 at 09:39:41AM -0500, Jason Merrill wrote:
On 11/15/24 9:08 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
The error here should also check that we aren't nested in another
lambda; in
On 1/15/25 10:19 AM, yxj-github-437 wrote:
On Fri, Jan 03, 2025 at 05:18:55PM +, xxx wrote:
From: yxj-github-437 <2457369...@qq.com>
This patch attempts to fix an error when build module std. The reason for the
error is __builrin_va_list (aka struct __va_list) is an internal linkage. so
att
On 1/15/25 10:13 AM, Patrick Palka wrote:
On Mon, 1 May 2023, Jason Merrill wrote:
On 4/28/23 15:40, Patrick Palka wrote:
On Fri, 28 Apr 2023, Patrick Palka wrote:
On Fri, 28 Apr 2023, Patrick Palka wrote:
After mechanically replacing RESULT_DECL within a constexpr call result
(for sake of R
Hi!
This is something we should have done when -std=c++23 was made the
primary option and -std=c++2b turned into undocumented alias.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-01-15 Jakub Jelinek
gcc/cp/
* parser.cc (cp_parser_lambda_declarator_opt,
Hi!
For T with non-trivial destructors, we were destructing objects in the
vector on release only when not using auto storage of auto_vec.
The following patch calls truncate (0) instead of m_vecpfx.m_num clearing,
and truncate takes care of that destruction:
unsigned l = length ();
gcc_checki
libstdc++-v3/ChangeLog:
PR libstdc++/109849
* include/bits/vector.tcc (vector::_M_range_insert): Fix
reversed args in length calculation.
---
Tested x86_64-linux, pushed to trunk. Backport to gcc-14 to follow after
testing.
libstdc++-v3/include/bits/vector.tcc | 2 +-
1
On Wed, Jan 15, 2025 at 10:27:56AM -0500, Jason Merrill wrote:
> > @@ -7432,12 +7426,18 @@ reshape_init_r (tree type, reshape_iter
> > {
> > vec *v = 0;
> > CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, init);
> > - tree raw_init = cp_maybe_split_raw_data (d);
> > + bool inc_cur;
>
This in this PR we have missed optimization where we miss that,
`1 >> x` and `(1 >> x) ^ 1` can't be equal. There are a few ways of
optimizing this, the easiest and simpliest is to simplify `1 >> x` into
just `x == 0` as those are equivalant (if we ignore out of range values for x).
we already have
Hi!
When writing the gcc-15/changes.html patch posted earlier, I've been
wondering where significant part of the Basic asm chapter went and the
problem was the insertion of a new @node in the middle of the Basic Asm
@node, plus not mentioning the new @node in the @menu. So the asm constexpr
node
On 12/12/24 2:07 PM, Simon Martin wrote:
We currently ICE upon the following valid (under -Wno-vla) code
=== cut here ===
void f(int c) {
constexpr int r = 4;
[&](auto) { int t[r * c]; }(0);
}
=== cut here ===
The problem is that when parsing the lambda body, and more specifically
the mul
On 11/29/24 9:33 AM, Simon Martin wrote:
We currently ICE upon the following code, that is valid under
-Wno-pointer-arith:
=== cut here ===
int main() {
decltype( [](auto) { return sizeof(void); } ) x;
return x.operator()(0);
}
=== cut here ===
The problem is that "fold_sizeof_expr (sizeo
On Wed, Jan 15, 2025 at 04:48:59PM -0500, Jason Merrill wrote:
> > --- a/gcc/cp/decl.cc
> > +++ b/gcc/cp/decl.cc
> > @@ -11686,6 +11686,7 @@ fold_sizeof_expr (tree t)
> > false, false);
> > if (r == error_mark_node)
> > r = size_one_node;
> > + r = cp_fold
101 - 130 of 130 matches
Mail list logo
