Hi!
The following testcase ICEs during regimplificatgion since the addition of
(convert (eqne zero_one_valued_p@0 INTEGER_CST@1))
simplification. That simplification is novel in the sense that in
gimplify_expr it can turn an expression (comparison in particular) into
a SSA_NAME. Normally when gi
Hi,jiahao:
The instruction latencies of the two instructions I tested here are
the same on 3a5000 and 3a6000.
This issue needs to be confirmed again.
在 2024/1/5 下午3:37, Jiahao Xu 写道:
For zero_extendqisi2 and zero_extendqidi2, use andi instead of bstrpick.w,
because andi is 6 times faster th
From: liwei
We found that the current combine optimization pass in gcc cannot handle
the following redundant sign extension situations:
(insn 77 76 78 5 (set (reg:SI 143)
(plus:SI (subreg/s/u:SI (reg/v:DI 104 [ len ]) 0)
(const_int 1 [0x1]))) {addsi3}
(expr_list:REG_DEAD
There are two mode iterators defined in the loongarch.md:
(define_mode_iterator GPR [SI (DI "TARGET_64BIT")])
and
(define_mode_iterator X [(SI "!TARGET_64BIT") (DI "TARGET_64BIT")])
Replace the mode in the bit arithmetic from GPR to X.
Since the bitwise operation instruction does
From: liwei
Eliminate the redundant sign extension that exists after the conditional
move when the target register is SImode.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_expand_conditional_move):
Adjust.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/sig
Hi!
The following testcase ICEs (on ARM/RISCV with certain options), because niters
analysis
computes number of latch executions for the loop as
(short unsigned int) (a.0_1 + 255) + 1 > 256 ? ~(short unsigned int) (a.0_1 +
255) : 0
where a.0_1 is unsigned char. This is correct, but given that a
Hi Harald,
OK to push, thanks for picking it up!
FX
On Sat, 2024-01-06 at 16:54 +0800, Lulu Cheng wrote:
> +(define_expand "addsi3"
> + [(set (match_operand:SI 0 "register_operand" "=r,r,r,r,r")
> + (plus:SI (match_operand:SI 1 "register_operand" "r,r,r,r,r")
> + (match_operand:SI 2 "plus_si_operand" "r,I,La,Le,Lb")))]
> + ""
> +
On Sat, 2024-01-06 at 16:54 +0800, Lulu Cheng wrote:
> There are two mode iterators defined in the loongarch.md:
> (define_mode_iterator GPR [SI (DI "TARGET_64BIT")])
> and
> (define_mode_iterator X [(SI "!TARGET_64BIT") (DI "TARGET_64BIT")])
> Replace the mode in the bit arithmetic f
On Sat, 2024-01-06 at 16:54 +0800, Lulu Cheng wrote:
/* snip */
> diff --git a/gcc/testsuite/gcc.target/loongarch/sign-extend-2.c
> b/gcc/testsuite/gcc.target/loongarch/sign-extend-2.c
> index a45dde4f73f..428535cb8e3 100644
> --- a/gcc/testsuite/gcc.target/loongarch/sign-extend-2.c
> +++ b/gcc/
I found a bugged test while finishing off the patch.
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-type.C
line 72 has
same_type(); // { dg-error "" "not captured" }
The behavior has changed now, and this test should have failed, but
didn't as it has an empty regex expression. The actual error being
emit
Hi Ben,
Ben Boeckel writes:
> Ping? Is this the right place to submit this patch?
Yes, this is the correct list, though it is usually recommended to use
--subject-prefix='PATCH wwwdocs' or such, to catch the right eyes. See:
https://gcc.gnu.org/contribute.html#webchanges
I've added it to my s
This patch improves the cost/gain calculation used during the i386 backend's
SImode/DImode scalar-to-vector (STV) conversion pass. The current code
handles loads and stores, but doesn't consider that converting other
scalar operations with a memory destination, requires an explicit load
before an
On Fri, 5 Jan 2024 at 14:12, Jonathan Wakely wrote:
>
> On 06/12/23 15:34 +0100, Gwenole Beauchesne wrote:
> >Tested on x86_64-pc-linux-gnu with --enable-languages=c,c++ and
> >additional -Wformat to CXXFLAGS.
>
> Please CC the libstd...@gcc.gnu.org list on all libstdc++ patches, as
> documented at
On Sat, Jan 6, 2024 at 11:40 AM Jonathan Wakely wrote:
>
> Here's a V2 patch which addresses the two things I mentioned: the new
> Python script now generates a complete file that can just be included by
> , and the full Unicode 15.1.0 grapheme cluster break
> rules are supported (I think ... more
On Sat, 6 Jan 2024 at 16:57, Lewis Hyatt wrote:
>
> On Sat, Jan 6, 2024 at 11:40 AM Jonathan Wakely wrote:
> >
> > Here's a V2 patch which addresses the two things I mentioned: the new
> > Python script now generates a complete file that can just be included by
> > , and the full Unicode 15.1.0 g
These PRs come about because of gfortran's single pass parsing. If the
function in the title is parsed after the associate construct, then its
type and rank are not known. The point at which this becomes a problem is
when expressions within the associate block are parsed. primary.cc
(gfc_match_vars
This fixes more of the sloppy tests that assume sizeof(int) = 4 etc.
Johann
--
testsuite/52641: Fix sloppy tests that did not care for sizeof(int)=2 etc.
gcc/testsuite/
PR testsuite/52641
* gcc.c-torture/compile/attr-complex-method-2.c [target=avr]: Check
for "divsc3" a
This patch set adds support for metadirectives and dynamic selectors
in metadirectives. To give credit where it's due, this is primarily
Kwok's work, originally posted 2+ years ago (and WIP for some time
before that):
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586600.html
There's al
From: Kwok Cheung Yeung
This patch adds the OMP_METADIRECTIVE tree node and shared tree-level
support for manipulating metadirectives. It defines/exposes
interfaces that will be used in subsequent patches that add front-end
and middle-end support, but nothing generates these nodes yet.
This pat
From: Kwok Cheung Yeung
This patch adds middle-end support for OpenMP metadirectives. Some
context selectors can be resolved during gimplification, but others need to
be deferred until the omp_device_lower pass, which requires that cgraph,
LTO streaming, inlining, etc all know about this constru
From: Kwok Cheung Yeung
This patch adds support for metadirectives to the Fortran front end.
gcc/fortran/ChangeLog
* decl.cc (gfc_match_end): Handle metadirectives.
* dump-parse-tree.cc (show_omp_node): Likewise.
(show_code_node): Likewise.
* gfortran.h (enum gfc_
From: Kwok Cheung Yeung
This patch implements the libgomp runtime support for the dynamic
target_device selector via the GOMP_evaluate_target_device function.
include/ChangeLog
* cuda/cuda.h (CUdevice_attribute): Add definitions for
CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR an
From: Kwok Cheung Yeung
This patch adds C++ support for metadirectives. It uses the
c-family support committed with the corresponding C front end patch
to do early parse-time metadirective resolution when possible.
Additional C/C++ common testcases are provided i
From: Kwok Cheung Yeung
This patch adds support to the C front end to parse OpenMP metadirective
constructs. It includes support for early parse-time resolution
of metadirectives (when possible) that will also be used by the C++ front
end.
Additional common C/C++ testcases are in a later patch
libgomp/ChangeLog
* libgomp.texi (OpenMP 5.0): Mark metadirective as implemented.
(OpenMP 5.1): Mark target_device as partially supported.
(OpenMP 5.2): Mark otherwise clause as supported, note that
default is also still accepted.
---
libgomp/libgomp.texi | 15 +
From: Kwok Cheung Yeung
gcc/testsuite/ChangeLog
* c-c++-common/gomp/metadirective-1.c: New.
* c-c++-common/gomp/metadirective-2.c: New.
* c-c++-common/gomp/metadirective-3.c: New.
* c-c++-common/gomp/metadirective-4.c: New.
* c-c++-common/gomp/metadirective
Hi Sandra,
given that it is "just" a revised patch of previously posted patch and
(code wise not file wise) very localized to OpenMP code - and even there
touching only 'declare ...' code in a simple way:
I would be still fine to have it in GCC 14, but I want to give Jakub a
chance to shout.
On Sat, 6 Jan 2024 at 17:03, Jonathan Wakely wrote:
>
> On Sat, 6 Jan 2024 at 16:57, Lewis Hyatt wrote:
> >
> > On Sat, Jan 6, 2024 at 11:40 AM Jonathan Wakely wrote:
> > >
> > > Here's a V2 patch which addresses the two things I mentioned: the new
> > > Python script now generates a complete fi
Hi Andrew,
I just spotted that this define was missing.
OK for mainline?
Tobiasgcn.h: Add builtin_define ("__gfx1030")
gcc/ChangeLog:
* config/gcn/gcn.h (TARGET_CPU_CPP_BUILTINS): Add
builtin_define ("__gfx1030").
diff --git a/gcc/config/gcn/gcn.h b/gcc/config/gcn/gcn.h
index c350cbb0545..
Am 04.01.2024 um 23:33 schrieb Björn Schäpers:
Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote:
From: Björn Schäpers
Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
t
Ok,
I think I js=ust thought this unnecessary.
On 11/11/23 20:59, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu. I don't have write
access.
-- >8 --
Currently the first depset for an EK_BINDING is not seeded. This breaks
the attached testcase as then the namespace i
This is ok -- sorry, I thought I'd already acked this
On 12/16/23 06:03, Nathaniel Shead wrote:
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638089.html
On Fri, Nov 24, 2023 at 10:32:13PM +1100, Nathaniel Shead wrote:
On Thu, Nov 23, 2023 at 12:11:58PM -0500, Nathan Sidwel
ok
On 1/3/24 05:01, Nathaniel Shead wrote:
Bootstrapped & regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This patch stops 'add_binding_entity' from ignoring all names in the
global module fragment, since they should still be exported if named
in an exported using-declaration.
Richard Smith & I discussed whether we should use the module interface's
capability of giving vague linkage entities a strong location. I didn't want to
go messing with that, 'cos it was changing yet more stuff.
But, perhaps we should revisit that? Any keyless polymorphic class in module
purv
ok
On 11/10/23 17:52, Nathaniel Shead wrote:
I noticed while fixing PR106849 that we don't currently check validity
of exporting non-functions via using-declarations either; this patch
adds those checks factored out into a new function. I also tried to make
the error messages a bit more descrip
I;m not sure about this, there was clearly a reason I did it the way it is, but
perhaps that reasoning became obsolete -- something about an existing
declaration and reading in a definition maybe?
nathan
On 11/22/23 06:33, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-g
ok
On 1/2/24 17:43, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The attached testcase Patrick found in PR c++/112899 ICEs because it is
attempting to write a variable initializer that is no longer in the
static_aggregates map.
The issue is
Hi Sandra,
looks quite okay, but I have a couple of remarks:
Sandra Loosemore wrote:
From: Kwok Cheung Yeung
This patch implements the libgomp runtime support for the dynamic
target_device selector via the GOMP_evaluate_target_device function.
...
--- /dev/null
+++ b/libgomp/config/gcn/sele
Hi Hongtao,
Many thanks for the review. This revised patch implements several
of your suggestions, specifically to use pshufd for V4SImode and
punpcklqdq for V2DImode. These changes are demonstrated by the
examples below:
typedef unsigned int v4si __attribute((vector_size(16)));
typedef unsigne
Bootstrapped and tested on x86_64-linux with no regressions.
I'm considering this finished, I have CWG2586 working but I have not
included it in this version of the patch. I was not happy with the
amount of work I had done on it. I will try to get it finished before
we get cut off, and I'm pretty
Bootstrapped and tested on x86_64-linux with no regressions.From 32a713d9826a042b260e84dcfbfd31c619a122fb Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Fri, 5 Jan 2024 14:34:34 -0700
Subject: [PATCH 3/4] C++23 P0847R7 (deducing this) - diagnostics. [PR102609]
Diagnostics for xobj member functions.
Bootstrapped and tested on x86_64-linux with no regressions.
That's it for now. If I manage to finish CWG2586 in time I guess I'll
submit it as patch 5/4? I'm definitely locked in on all these changes
unless there's a really good reason.
Alex
On Sun, Jan 07, 2024 at 12:05:50AM +, waffl3x wrote:
> Bootstrapped and tested on x86_64-linux with no regressions.
>
> That's it for now. If I manage to finish CWG2586 in time I guess I'll
> submit it as patch 5/4? I'm definitely locked in on all these changes
> unless there's a really good r
Obvious fix, Committed.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc: replace std::max by MAX.
---
gcc/config/riscv/riscv-vsetvl.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index 7d748edc
On Saturday, January 6th, 2024 at 5:17 PM, Jakub Jelinek
wrote:
>
>
> On Sun, Jan 07, 2024 at 12:05:50AM +, waffl3x wrote:
>
> > Bootstrapped and tested on x86_64-linux with no regressions.
> >
> > That's it for now. If I manage to finish CWG2586 in time I guess I'll
> > submit it
Pushed to trunk now.
On Thu, 14 Dec 2023 at 01:09, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> Does this look right? Can we do it faster, or simplify it?
>
> -- >8 --
>
> This reduces the overhead of using std::is_trivially_destructible_v and
> as a result fixes some recent regressions se
Tested x86_64-linux. Pushed to trunk.
-- >8 --
As the comment notes, the increased timeout was needed because of PR
102780, but that was fixed long ago.
libstdc++-v3/ChangeLog:
* testsuite/20_util/variant/87619.cc: Remove dg-timeout-factor.
---
libstdc++-v3/testsuite/20_util/variant/87
Tested x86_64-linux. Pushed to trunk.
-- >8 --
r14-1527-g2415024e0f81f8 changed the parameter of the
__cxa_call_terminate definition, but there's also a declaration in
unwind-cxx.h which should have been changed too.
libstdc++-v3/ChangeLog:
PR libstdc++/112997
* libsupc++/unwind
On Tue, 19 Dec 2023, Jeff Law wrote:
>
> So the strub tests in c-c++-common are problematical. They get run twice,
> once for C, once for C++. Yet the name of the test is the same in both runs.
> (by the name, I mean the name emitted into the dejagnu summary and log files).
>
> Thus if you have
> Date: Sat, 6 Jan 2024 23:15:24 +0100
> From: Björn Schäpers
> Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
>
> This patch adds libraries which are loaded after backtrace_initialize, like
> plugins or similar.
>
> I don't know what style is preferred for the Win32 typedefs, should the code
>
51 matches
Mail list logo
