> Am 28.07.2024 um 01:34 schrieb Sam James :
>
> Per gccint, dg-add-options must be placed after all dg-options directives.
>
> gcc/testsuite/ChangeLog:
>
>* gcc.target/riscv/rvv/base/cmpmem-2.c: Fix dg-add-options order.
Ok for both patches
Richard
> ---
> Simple dejagnu directive f
> Am 28.07.2024 um 06:41 schrieb Andrew Pinski :
>
> While doing some other cleanups with the properties I noticed that
> debug_properties
> was not updated for some of the new properties. So instead of just updating
> the function,
> this moves the properties over to its own .def file so we
While doing some other cleanups with the properties I noticed that
debug_properties
was not updated for some of the new properties. So instead of just updating the
function,
this moves the properties over to its own .def file so we don't need to update
this nor will
have a conflict in the bit or
PROP_no_crit_edges was made checked by r8-2993-ga7976089dba5e2 by
doing an explict splitting critical edges directly in PRE.
So let's remove it.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Note this depends on
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658447.html .
From: Pan Li
After add the matching for .SAT_SUB when one op is IMM, there
will be a new root PLUS_EXPR for the .SAT_SUB pattern. For example,
Form 3:
#define DEF_SAT_U_SUB_IMM_FMT_3(T, IMM) \
T __attribute__((noinline)) \
sat_u_sub_imm##IMM##_##T##_fmt_3 (T x) \
{
On Linux/x86_64,
a9e9f772c7488ac0c09dd92f28890bdab939771a is the first bad commit
commit a9e9f772c7488ac0c09dd92f28890bdab939771a
Author: Jason Merrill
Date: Fri Jul 26 17:20:18 2024 -0400
c++: consteval propagation and templates [PR115986]
caused
FAIL: g++.dg/cpp2a/consteval-prop21.C -
Per gccint, dg-add-options must be placed after all dg-options directives.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/cmpmem-2.c: Fix dg-add-options order.
---
Simple dejagnu directive fixes. OK?
gcc/testsuite/gcc.target/riscv/rvv/base/cmpmem-2.c | 2 +-
1 file changed, 1 inse
Per gccint, dg-do must precede dg-require-effective-target or
dg-require-support. Fix a handful of deviant cases.
gcc/testsuite/ChangeLog:
* gcc.dg/pr25521.c: Fix dg-do directive order.
* gcc.dg/vect/vect-simd-clone-19.c: Likewise.
* gcc.target/arm/stack-protector-7.c: Lik
Hi Mikael,
You were absolutely right. I looked at the caller and "just didn't get it".
Thanks. I will resubmit when I get back from a business trip.
Cordialement
Paul
On Sat, 27 Jul 2024 at 12:35, Mikael Morin wrote:
> Hello,
>
> Le 27/07/2024 à 11:25, Paul Richard Thomas a écrit :
> > This
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here the call to e() makes us decide to check d() for escalation at EOF, but
while checking it we try to fold_immediate 0_c, and get confused by the
template trees. Let's not mess with escalation for function templates.
PR c++/1159
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here when we want to synthesize methods for foo()::B maybe_push_to_top_level
calls push_function_context, which sets cfun to a dummy value; later
finish_call_expr tries to set something in
cp_function_chain (i.e. cfun->language), which isn't
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
I wanted to add more cases to the setting of std_list in g++-dg.exp, but
didn't want to do a full scan through the file for each case. So this patch
improves that in two ways: first, by extracting all interesting lines on a
single pass; sec
On 27 July 2024 21:11:19 CEST, Mikael Morin wrote:
>Le 27/07/2024 à 19:23, rep.dot@gmail.com a écrit :
>> On 22 July 2024 20:53:18 CEST, Mikael Morin wrote:
>>> From: Mikael Morin
>>>
>>> Hello,
>>>
>>> this fixes a null pointer dereference with absent optional dummy passed
>>> as BACK arg
On Sat, Jul 27, 2024 at 1:55 AM Lulu Cheng wrote:
>
> gcc/ChangeLog:
>
> * config/loongarch/lasx.md (xvandn3): Rename to ...
> (andn3): This.
> (xvorn3): Rename to ...
> (iorn3): This.
> * config/loongarch/loongarch-builtins.cc (CODE_FOR_lsx_vandn_v):
>
On Sat, Jul 27, 2024 at 1:38 AM Lulu Cheng wrote:
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.md (n): Rename to ...
> (n3): This.
Thanks for doing this for loongarch. Once I finish up my patch set;
loongarch should get benefit. Also it might be useful after my patch
set g
Le 27/07/2024 à 19:23, rep.dot@gmail.com a écrit :
On 22 July 2024 20:53:18 CEST, Mikael Morin wrote:
From: Mikael Morin
Hello,
this fixes a null pointer dereference with absent optional dummy passed
as BACK argument of MINLOC/MAXLOC.
Tested for regression on x86_64-linux.
OK for master
Hello-
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html
Ping please? Jakub + Jason, hope you don't mind that I CCed you, I saw
you had your attention on extended character identifiers a bit now :).
Thanks!
-Lewis
On Fri, Jul 5, 2024 at 4:23 PM Lewis Hyatt wrote:
>
> Hello-
>
Firstly, thanks to Haochen Gui for recently adding optab support for
isfinite and isnormal to the middle-end. This patch adds define_expand
for both these functions to the nvptx backend, which conveniently has
special instructions to simplify their implementation. As this patch
adds UNSPEC_ISFIN
On 22 July 2024 20:53:18 CEST, Mikael Morin wrote:
>From: Mikael Morin
>
>Hello,
>
>this fixes a null pointer dereference with absent optional dummy passed
>as BACK argument of MINLOC/MAXLOC.
>
>Tested for regression on x86_64-linux.
>OK for master?
>
>-- >8 --
>
>Protect the evaluation of BACK w
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The resolution was implemented in r14-8752-g6f75149488b74a but I didn't
add the usual _GLIBCXX_RESOLVE_LIB_DEFECTS comment.
libstdc++-v3/ChangeLog:
* include/bits/std_function.h: Add comment about LWG 3617 being
supported.
---
libs
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Cast ptrdiff_t to size_t to avoid a -Wsign-compare warning. We can check
in __to_chars_i that the ptrdiff_t won't be negative, so that we know
the cast is safe.
libstdc++-v3/ChangeLog:
* include/std/charconv (__to_chars_16, __to_chars_10)
Tested x86_64-linux. Pushed to trunk.
-- >8 --
As the numbers in PR libstdc++/88545 show, the manual loop unrolling in
std::__find_if doesn't actually help these days, and it prevents the
compiler from auto-vectorizing.
Remove the dispatching on iterator_category and just use the simple loop
for
Hello,
Le 27/07/2024 à 11:25, Paul Richard Thomas a écrit :
This patch is straightforward but I am still puzzled as to why it is
necessary for the particular case. Having looked at all the other chunks
of frontend code involving use renaming, it seems that the process just
works everywhere els
This patch is straightforward but I am still puzzled as to why it is
necessary for the particular case. Having looked at all the other chunks of
frontend code involving use renaming, it seems that the process just works
everywhere else. I tried putting the new code in gfc_find_symtree but it
caused
gcc/ChangeLog:
* config/loongarch/lasx.md (xvandn3): Rename to ...
(andn3): This.
(xvorn3): Rename to ...
(iorn3): This.
* config/loongarch/loongarch-builtins.cc (CODE_FOR_lsx_vandn_v):
Defined as the modified name.
(CODE_FOR_lsx_vorn_v): Lik
gcc/ChangeLog:
* config/loongarch/loongarch.md (n): Rename to ...
(n3): This.
---
gcc/config/loongarch/loongarch.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 459ad30b9bb..4e4ddd5
在 2024/7/27 下午4:41, Xi Ruoyao 写道:
On Sat, 2024-07-27 at 16:36 +0800, Lulu Cheng wrote:
gcc/ChangeLog:
* config/loongarch/loongarch.md (n): Rename to ...
(n3): This.
Ok.
Note that [x]vorn3 and [x]vandn3 should be renamed as well.
Uh, I just forgot about them, I'm modifying
On Sat, 2024-07-27 at 16:36 +0800, Lulu Cheng wrote:
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.md (n): Rename to ...
> (n3): This.
Ok.
Note that [x]vorn3 and [x]vandn3 should be renamed as well.
> ---
> gcc/config/loongarch/loongarch.md | 2 +-
> 1 file changed, 1 insertion
gcc/ChangeLog:
* config/loongarch/loongarch.md (n): Rename to ...
(n3): This.
---
gcc/config/loongarch/loongarch.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 459ad30b9bb..4e4ddd5
Hello, Jonathan,
ISTM I've failed to answer, sorry
On May 30, 2024, Jonathan Wakely wrote:
> I got bounces from oarcorp.com and rtems.org, are the details in
> MAINTAINERS out of date for Joel and Ralf?
I got bounces as well back then. I don't know whether this means the
addresses were outdat
30 matches
Mail list logo
