When 2 vectors are equal, kmask is allones and kortest will set CF,
else CF will be cleared.
So CF bit can be used to check for the result of the comparison.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
Before:
vmovdqu (%rsi), %ymm0
vpxorq (%rdi),
> -Original Message-
> From: Jiang, Haochen
> Sent: Friday, October 27, 2023 10:52 AM
> To: Jiang, Haochen ; gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com; Gerald Pfeifer
>
> Subject: RE: [PATCH] [gcc-wwwdocs]gcc-13/14: Mention Intel new ISA and
> march support
>
> >
> -Original Message-
> From: Haochen Jiang
> Sent: Monday, October 23, 2023 10:18 AM
> To: gcc-patches@gcc.gnu.org
> Cc: ger...@pfeifer.com; ubiz...@gmail.com; Liu, Hongtao
>
> Subject: [gccwwwdocs PATCH] gcc-13/14: Mention Intel new ISA and march
> support
>
> Hi all,
>
> This patch
> -Original Message-
> From: Gcc-patches bounces+haochen.jiang=intel@gcc.gnu.org> On Behalf Of Haochen Jiang
> via Gcc-patches
> Sent: Monday, July 17, 2023 11:34 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com
> Subject: [PATCH] [gcc-wwwdocs]gcc-13/14: Mention
Thanks Richard S for comments.
> In other words, I don't think simply removing the test from the vectoriser
> is correct. It needs to be replaced by something more selective.
Does it mean we need to check if the internal fun allow different modes/sizes
here?
For example, standard name
+cc maintainers.
On 2023/10/26 11:25, Xionghu Luo wrote:
Fix the long lasting issue of `gcov-tool overlap xxx yyy`,
divide to 0 caused the output shows a lot of nans, another problem
is the counts in file are never acculated leads to incorrect results.
Signed-off-by: Xionghu Luo
Hi,
Compare with previous version:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632399.html
This verion supports TI/VEC mode of the access.
There are a few PRs (meta-bug PR101926) on various targets.
The root causes of them are similar: the aggeragte param/
returns are passed by
On 10/26/23 17:37, Patrick Palka wrote:
On Thu, 26 Oct 2023, Patrick Palka wrote:
On Thu, 26 Oct 2023, Jason Merrill wrote:
On 10/25/23 14:55, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Now that we don't have to worry
On 9/18/23 13:21, Jakub Jelinek wrote:
Here is an updated version of the patch.
Compared to the last version, based on the discussion in the PR, the patch
1) warns (but only that) if size()/data() methods aren't declared
constexpr/consteval (or implicitly constexpr)
The language
Yeah. No worry. We will eventually run full coverage testing && fix all bugs in
stage 3 && stage 4.
We are planning to run the whole gcc testsuite with all these following compile
option:
-march=rv64gcv_zvl128b --param=riscv-autovec-lmul=m1
-march=rv64gcv_zvl128b --param=riscv-autovec-lmul=m2
Thanks Patrick. Committed.
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2023-10-27 02:12
To: Juzhe-Zhong; gcc-patches
CC: Kito Cheng; Robin Dapp
Subject: Re: [Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV
auto-vectorization
popcount and mask_gather_load_run fails seem to
Committed.
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2023-10-27 06:28
To: gcc-patches
CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong
Subject: [NFC] RISC-V: Move lmul calculation into macro
Notice we calculate LMUL according to --param=riscv-autovec-lmul
in multiple places:
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-10-27 03:19
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Fix cond_sqrt tests.
Hi,
as long as we do not have universal Zvfh support in binutils
linking against libm does
On Thu, 26 Oct 2023, Sam James wrote:
> These options both enabled more checking within the C++ standard library
> and can expose errors in submitted code.
This is a good addition, thank you! I was going to approve/push, but it's
probably better for Jonathan to give the final okay.
Just one
Hi, Robin.
+ machine_mode vmode;
+ switch (mode)
+{
+ case QImode:
+ vmode = E_RVVM1QImode;
+ break;
+ case HImode:
+ vmode = E_RVVM1HImode;
+ break;
+ case SImode:
+ vmode = E_RVVM1SImode;
+ break;
+ case DImode:
+ vmode = E_RVVM1DImode;
+ break;
+ default:
+
Notice we calculate LMUL according to --param=riscv-autovec-lmul
in multiple places: int lmul = riscv_autovec_lmul == RVV_DYNAMIC ? RVV_M8 :
riscv_autovec_lmul;
Create a new macro for it for easier matain.
gcc/ChangeLog:
* config/riscv/riscv-opts.h (TARGET_MAX_LMUL): New macro.
On 26/10/23 10:35, Richard Biener wrote:
On Mon, Oct 23, 2023 at 2:57 AM Mark Harmstone wrote:
This patch and the following add initial support for Microsoft's
CodeView debugging format, as used by MSVC, to mingw targets.
A high-level question - it seems there's almost no information in the
On Thu, 26 Oct 2023, Patrick Palka wrote:
> On Thu, 26 Oct 2023, Jason Merrill wrote:
>
> > On 10/25/23 14:55, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > > -- >8 --
> > >
> > > Now that we don't have to worry about
On Thu, 26 Oct 2023, Jason Merrill wrote:
> On 10/25/23 14:55, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > Now that we don't have to worry about looking thruogh NON_DEPENDENT_EXPR,
> > we can easily extend
On 8/28/23 06:34, Richard Biener wrote:
On Fri, 25 Aug 2023, Jakub Jelinek wrote:
Hi!
The following patch implements
CWG 2406 - [[fallthrough]] attribute and iteration statements
The genericization of some loops leaves nothing at all or just a label
after a body of a loop, so if the loop is
On 10/13/23 17:28, Lewis Hyatt wrote:
On Tue, Sep 12, 2023 at 04:09:21PM -0400, Lewis Hyatt wrote:
On Tue, Aug 8, 2023 at 5:53 PM Jason Merrill wrote:
On 7/31/23 22:22, Lewis Hyatt via Gcc-patches wrote:
`#pragma GCC target' is not currently handled in preprocess-only mode (e.g.,
when
From: Andrew Pinski
I noticed we were missing these simplifications so let's add them.
This adds the following simplifications:
U & N <= U -> true
U & N > U -> false
When U is known to be as non-negative.
When N is also known to be non-negative, this is also true:
U | N < U -> false
U | N
On 10/25/23 06:28, Alex Coplan wrote:
On 11/10/2023 14:31, Alex Coplan wrote:
On 27/09/2023 15:27, Alex Coplan wrote:
Hi,
This is a v4 patch to address Jason's feedback here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630911.html
w.r.t. v3 it just removes a comment now that
On Thu, 26 Oct 2023, Jason Merrill wrote:
> On 10/26/23 14:01, Patrick Palka wrote:
> > Since when in a template context we end up just discarding the result
> > of build_new_1, we don't have to bother with much of the code generation
> > it performs. This patch makes the function exit early,
On 10/25/23 14:55, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Now that we don't have to worry about looking thruogh NON_DEPENDENT_EXPR,
we can easily extend the -Wparentheses warning in convert_for_assignment
to consider
On 26/10/2023 12:43, Jonathan Wakely wrote:
On 26/10/23 07:18 +0200, François Dumont wrote:
libstdc++: [_Hashtable] Use RAII type to manage rehash functor state
Replace usage of __try/__catch with a RAII type to restore rehash
functor
state when needed.
Generally I really like
These options both enabled more checking within the C++ standard library
and can expose errors in submitted code.
-D_GLIBCXX_DEBUG is mentioned separately because while we want people to try it,
it's not always feasible because it requires the whole program and any used
libraries to also be built
Dear all,
the attached patch improves the diagnostics of MODULE PROCEDURE declaration
conflicts, when one of the declarations is an alternate return. We used to
ICE before.
Steve identified the cause of the issue and provided a partial fix.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
The MICROBLAZE_VERSION_COMPARE was incorrectly using strcasecmp
instead of strverscmp to check the mcpu version against feature
options. By simply changing the define to use strverscmp,
the new version 10.0 is treated correctly as a higher version
than previous versions.
Signed-off-by: Neal
On 10/26/23 14:01, Patrick Palka wrote:
Since when in a template context we end up just discarding the result
of build_new_1, we don't have to bother with much of the code generation
it performs. This patch makes the function exit early, returning a dummy
non-erroneous result, once we've done
> +(define_expand "vcond_mask_len_"
> + [(match_operand:V_VLS 0 "register_operand")
> + (match_operand: 3 "nonmemory_operand")
> + (match_operand:V_VLS 1 "nonmemory_operand")
> + (match_operand:V_VLS 2 "autovec_else_operand")
> + (match_operand 4 "autovec_length_operand")
> +
Hi,
this patch adds a vectorized rawmemchr expander.
It's basically strstr but for 8, 16 and 32-byte needles.
Apart from adjusting the common-code tests I re-used a
similar test that Stefan added to the s390 backend.
Regards
Robin
gcc/ChangeLog:
* config/riscv/autovec.md (rawmemchr):
Tested x86_64-linux. Pushed to trunk. Worth backporting to all active
branches, I think.
-- >8 --
The incorrect errc constant here looks like a copy error.
libstdc++-v3/ChangeLog:
PR libstdc++/112089
* include/std/shared_mutex (shared_lock::unlock): Change errc
constant
Tested x86_64-linux. Pushed to trunk. Worth backporting to gcc-13 too.
-- >8 --
This avoids failures due to compilation timeouts when testing with a low
tool_timeout value.
libstdc++-v3/ChangeLog:
* testsuite/20_util/duration/io.cc: Double timeout using
dg-timeout-factor.
On Thu, 2023-10-19 at 10:02 -0400, David Malcolm wrote:
> This patch adds a new function attribute to GCC for marking that an
> argument is expected to be a null-terminated string.
>
> For example, consider:
>
> void test_a (const char *p)
> __attribute__((null_terminated_string_arg (1)));
Hi Richard,
> On 26 Oct 2023, at 20:49, Richard Sandiford wrote:
>
> Iain Sandoe writes:
>> This was written before Thomas' modification to the ELF-handling to allow
>> a config-based change for target details. I did consider updating this
>> to try and use that scheme, but I think that it
I guess that what Kees wanted, ""fill the array without knowing the actual
final size" code pattern”, as following:
>> struct foo *f;
>> char *p;
>> int i;
>>
>> f = alloc(maximum_possible);
>> f->count = 0;
>> p = f->buf;
>>
>> for (i; data_is_available() &&
Iain Sandoe writes:
> This was written before Thomas' modification to the ELF-handling to allow
> a config-based change for target details. I did consider updating this
> to try and use that scheme, but I think that it would sit a little
> awkwardly, since there are some differences in the
On 10/25/23 01:02, Neal Frager wrote:
The MICROBLAZE_VERSION_COMPARE was incorrectly using strcasecmp
instead of strverscmp to check the mcpu version against feature
options. By simply changing the define to use strverscmp,
the new version 10.0 is treated correctly as a higher version
than
Iain Sandoe writes:
> tested on cfarm185 (aarch64-linux-gnu, xgene1) and with the aarch64
> Darwin prototype. It is possible that some initial fallout could occur
> on some test setups (where the default has been catered for in some
> way) - but that should stabilize. OK for trunk?
> thanks
>
This is an enablement patch (the initial use comes with the Darwin aarch64
port). Tested on aarch64-linux-gnu, aarch64-apple-darwin and x86_64-darwin
just for good measure, OK for trunk?
thanks
Iain.
--- 8< ---
Some assmblers have a bug that requires +crc to be emitted even
though the base
On Thu, Oct 26, 2023 at 12:18 PM Sam James wrote:
>
> These options both enabled more checking within the C++ standard library
> and can expose errors in submitted code.
>
> -D_GLIBCXX_DEBUG is mentioned separately because while we want people to try
> it,
> it's not always feasible because it
Hi,
as long as we do not have universal Zvfh support in binutils
linking against libm does not work out of the box. This patch
splits the cond_sqrt tests into non-zvfh and zvfh variants and
makes the run-zvfh ones depend on a zvfh target.
While at it, I also added Zvfh handling to the testsuite
This was written before Thomas' modification to the ELF-handling to allow
a config-based change for target details. I did consider updating this
to try and use that scheme, but I think that it would sit a little
awkwardly, since there are some differences in the start-up scanning for
Mach-O. I
Hi Paul,
this looks all good to me.
It is great that you added the handling of nested parentheses to the
resolution, as that appears to be needed also in other situations.
Thanks for the patch!
Harald
On 10/26/23 19:14, Paul Richard Thomas wrote:
Hi All,
The attached patch fixes the
> On Oct 26, 2023, at 1:05 PM, Martin Uecker wrote:
>
> Am Donnerstag, dem 26.10.2023 um 16:41 + schrieb Qing Zhao:
>>
>>> On Oct 26, 2023, at 5:20 AM, Martin Uecker wrote:
>>>
>>> Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener:
On Wed, Oct 25, 2023 at 8:16 PM
These options both enabled more checking within the C++ standard library
and can expose errors in submitted code.
-D_GLIBCXX_DEBUG is mentioned separately because while we want people to try it,
it's not always feasible because it requires the whole program and any used
libraries to also be built
Jonathan Wakely writes:
> On Thursday, 26 October 2023, Sam James wrote:
>> These options both enabled more checking within the C++ standard library
>> and can expose errors in submitted code.
>>
>> -D_GLIBCXX_DEBUG is mentioned separately because while we want people to try
>> it,
>> it's
On Thursday, 26 October 2023, Sam James wrote:
> These options both enabled more checking within the C++ standard library
> and can expose errors in submitted code.
>
> -D_GLIBCXX_DEBUG is mentioned separately because while we want people to
try it,
> it's not always feasible because it requires
On Thu, Oct 26, 2023 at 11:58 AM Iain Sandoe wrote:
>
> tested on cfarm185 (aarch64-linux-gnu, xgene1) and with the aarch64
> Darwin prototype. It is possible that some initial fallout could occur
> on some test setups (where the default has been catered for in some
> way) - but that should
tested on cfarm185 (aarch64-linux-gnu, xgene1) and with the aarch64
Darwin prototype. It is possible that some initial fallout could occur
on some test setups (where the default has been catered for in some
way) - but that should stabilize. OK for trunk?
thanks
Iain
--- 8< ---
When the
On Sun, Oct 15, 2023 at 12:40 PM Arsen Arsenović wrote:
>
> Evening,
>
> Arsen Arsenović writes:
>
> > Afternoon,
> >
> > This patch is a rebase and rewording of
> > https://inbox.sourceware.org/20230925150921.894157-1-ar...@aarsen.me/
> >
> > Changes since v1:
> > - Implement Brunos suggested
> On Oct 26, 2023, at 10:05 AM, Richard Biener
> wrote:
>
>
>
>> Am 26.10.2023 um 12:14 schrieb Martin Uecker :
>>
>> Am Donnerstag, dem 26.10.2023 um 11:20 +0200 schrieb Martin Uecker:
Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener:
On Wed, Oct 25, 2023 at
This patch fixes an issue with the cost on "int_div" in various RISC-V
tune parameters including those for Rocket, SiFive U7 series, and T-Head
C906. This incorrect cost value interferes with the optimization process.
For example, it prevents the optimization of division by a constant to a
more
On 10/26/23 11:15, Robin Dapp wrote:
rv32gcv:
FAIL: gfortran.dg/intrinsic_pack_6.f90 -O2 execution test
FAIL: gfortran.dg/intrinsic_pack_6.f90 -O3 -g execution test
FAIL: gfortran.dg/matmul_3.f90 -O2 execution test
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,
Andrew Carlotti writes:
> This patch adds support for the "target_version" attribute to the middle
> end and the C++ frontend, which will be used to implement function
> multiversioning in the aarch64 backend.
>
> Note that C++ is currently the only frontend which supports
> multiversioning using
On Thu, 26 Oct 2023 at 19:44, Lewis Hyatt wrote:
>
> On Thu, Oct 26, 2023 at 12:48 PM Christophe Lyon
> wrote:
> >
> > On Thu, 26 Oct 2023 at 18:18, Lewis Hyatt wrote:
> > >
> > > On Thu, Oct 26, 2023 at 4:49 AM Christophe Lyon
> > > wrote:
> > > > We have noticed that the new tests fail on
On Thu, Oct 26, 2023 at 2:29 AM Richard Biener
wrote:
>
> On Wed, Oct 25, 2023 at 5:51 AM Andrew Pinski wrote:
> >
> > I noticed we were missing optimizing `a / (1 << b)` when
> > we know that a is nonnegative but only due to ranger information.
> > This adds the use of the global ranger to
> rv32gcv:
> FAIL: gfortran.dg/intrinsic_pack_6.f90 -O2 execution test
> FAIL: gfortran.dg/intrinsic_pack_6.f90 -O3 -g execution test
> FAIL: gfortran.dg/matmul_3.f90 -O2 execution test
> FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution, -O2
> FAIL:
popcount and mask_gather_load_run fails seem to be an issue with my
setup or a bug with QEMU based on the v2 discussion :-)
OK with me regarding testing (I don't have the authority to approve a
patch, but Kito already said LGTM):
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Since when in a template context we end up just discarding the result
of build_new_1, we don't have to bother with much of the code generation
it performs. This patch makes the function exit early,
Richard Biener writes:
>> Am 26.10.2023 um 13:59 schrieb Li, Pan2 :
>>
>> Thanks Richard for comments.
>>
>>> Can you explain why this is necessary? In particular what is lhs_rtx
>>> mode vs ops[0].value mode?
>>
>> For testcase gcc.target/aarch64/sve/popcount_1.c, the rtl are list as below.
On Thu, Oct 26, 2023 at 12:48 PM Christophe Lyon
wrote:
>
> On Thu, 26 Oct 2023 at 18:18, Lewis Hyatt wrote:
> >
> > On Thu, Oct 26, 2023 at 4:49 AM Christophe Lyon
> > wrote:
> > > We have noticed that the new tests fail on aarch64 with:
> > > .../aarch64-unknown-linux-gnu/libc/usr/lib/crt1.o:
Ping^2
It'd be nice to get this patch into 14 (given the intended C strictness
changes, especially).
Have a lovely evening.
--
Arsen Arsenović
signature.asc
Description: PGP signature
> Am 26.10.2023 um 19:05 schrieb Martin Uecker :
>
> Am Donnerstag, dem 26.10.2023 um 16:41 + schrieb Qing Zhao:
>>
On Oct 26, 2023, at 5:20 AM, Martin Uecker wrote:
>>>
>>> Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener:
On Wed, Oct 25, 2023 at 8:16 PM
Hi All,
The attached patch fixes the original problem, in which parentheses around
the selector in select type constructs caused ICES. Stacked parentheses
caused problems in trans-stmt.cc. Rather than tracking this down, the
redundant parentheses were removed on resolution of the selector
These options both enabled more checking within the C++ standard library
and can expose errors in submitted code.
-D_GLIBCXX_DEBUG is mentioned separately because while we want people to try it,
it's not always feasible because it requires the whole program and any used
libraries to also be built
Am Donnerstag, dem 26.10.2023 um 16:41 + schrieb Qing Zhao:
>
> > On Oct 26, 2023, at 5:20 AM, Martin Uecker wrote:
> >
> > Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener:
> > > On Wed, Oct 25, 2023 at 8:16 PM Martin Uecker wrote:
> > > >
> > > > Am Mittwoch, dem
Ping. It would be nice to get this QoL fix in.
-Dimitry
> On 28 Sep 2023, at 18:37, Dimitry Andric wrote:
>
> Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
>
> When building gcc's C++ sources against recent libc++, the poisoning of
> the ctype macros due to including safe-ctype.h
Missed that, sorry. Please move the test to gfortran.dg/gomp/ — those tests are
automatically compiled with -fopenmp, hence, no need for
dg-(additional-)options.
Not applicable here, but tests that use omp.h or "use omp_lib" or the runtime
have to be under libgomp/testsuite - or, for compile
Missed this...
gcc/ChangeLog:
* range-op-float.cc (range_operator::fold_range): Delete unused
variable.
---
gcc/range-op-float.cc | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index ffa3dec133e..75816942f8c 100644
---
The floating point version of rv_fold returns its result in 3 pieces:
the lower bound, the upper bound, and a maybe_nan bit. It is cleaner
to return everything in an frange, thus bringing the floating point
version of rv_fold in line with the integer version.
This first patch adds an frange
Now that the floating point version of rv_fold calculates its result
in an frange, we can remove the superfluous LB, UB, and MAYBE_NAN
arguments.
gcc/ChangeLog:
* range-op-float.cc (range_operator::fold_range): Remove
superfluous code.
(range_operator::rv_fold): Remove
Hi PA!
On 2023-10-26T18:28:07+0200, Paul-Antoine Arras wrote:
> On 26/10/2023 18:16, you wrote:
>> On 2023-10-26T13:24:04+0200, Paul-Antoine Arras
>> wrote:
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gfortran.dg/c_ptr_tests_20.f90
>>> @@ -0,0 +1,57 @@
>>> +! { dg-do compile }
>>> +! {
On Thu, 26 Oct 2023 at 18:18, Lewis Hyatt wrote:
>
> On Thu, Oct 26, 2023 at 4:49 AM Christophe Lyon
> wrote:
> > We have noticed that the new tests fail on aarch64 with:
> > .../aarch64-unknown-linux-gnu/libc/usr/lib/crt1.o: in function `_start':
> >
Am Donnerstag, dem 26.10.2023 um 09:13 -0700 schrieb Kees Cook:
> On Thu, Oct 26, 2023 at 10:15:10AM +0200, Martin Uecker wrote:
> > but not this:
> >
x->count = 11;
> > char *p = >buf;
> > x->count = 1;
> > p[10] = 1; // !
>
> This seems fine to me -- it's how I'd expect it to work: "10" is
On 10/26/23 08:08, Cupertino Miranda wrote:
>
> Changes from v1:
> - Fixed Davids remarks on initial patch.
> - Fixed mistake with deleted '*'.
>
> Changes from v2:
> - Reversed return value for bpf_const_not_ok_for_debug_p function.
Hmm..
> +static bool
> +bpf_const_not_ok_for_debug_p
Le 26/10/2023 à 11:29, Richard Biener a écrit :
On Wed, Oct 25, 2023 at 5:51 AM Andrew Pinski wrote:
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 40767736389..2a2a90230f5 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -15047,15 +15047,33 @@
> On Oct 26, 2023, at 5:20 AM, Martin Uecker wrote:
>
> Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Biener:
>> On Wed, Oct 25, 2023 at 8:16 PM Martin Uecker wrote:
>>>
>>> Am Mittwoch, dem 25.10.2023 um 13:13 +0200 schrieb Richard Biener:
> Am 25.10.2023 um 12:47
Hi Thomas,
On 26/10/2023 18:16, you wrote:
Hi!
On 2023-10-26T13:24:04+0200, Paul-Antoine Arras wrote:
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/c_ptr_tests_20.f90
@@ -0,0 +1,57 @@
+! { dg-do compile }
+! { dg-additional-options "-fopenmp" }
+[...]
--- /dev/null
+++
On 10/26/23 06:30, Jeff Law wrote:
On 10/25/23 18:13, Patrick O'Neill wrote:
On rv32gcv testcases like g++.target/riscv/rvv/base/bug-22.C fail with:
FAIL: g++.target/riscv/rvv/base/bug-22.C (test for excess errors)
Excess errors:
cc1plus: error: ABI requires '-march=rv32'
This patch adds
On Thu, Oct 26, 2023 at 4:49 AM Christophe Lyon
wrote:
> We have noticed that the new tests fail on aarch64 with:
> .../aarch64-unknown-linux-gnu/libc/usr/lib/crt1.o: in function `_start':
> .../sysdeps/aarch64/start.S:110:(.text+0x38): undefined reference to `main'
>
> Looking at the test, I'd
Am Donnerstag, dem 26.10.2023 um 17:48 +0200 schrieb Richard Biener:
>
> > Am 26.10.2023 um 16:58 schrieb Qing Zhao :
> >
> >
> >
> > > On Oct 26, 2023, at 4:56 AM, Richard Biener
> > > wrote:
> > >
> > > > On Thu, Oct 26, 2023 at 7:22 AM Jakub Jelinek wrote:
> > > >
> > > > On Wed, Oct
Hi!
On 2023-10-26T13:24:04+0200, Paul-Antoine Arras wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/c_ptr_tests_20.f90
> @@ -0,0 +1,57 @@
> +! { dg-do compile }
> +! { dg-additional-options "-fopenmp" }
> +[...]
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/c_ptr_tests_21.f90
> @@
On Thu, Oct 26, 2023 at 10:15:10AM +0200, Martin Uecker wrote:
> but not this:
>
> char *p = >buf;
> x->count = 1;
> p[10] = 1; // !
This seems fine to me -- it's how I'd expect it to work: "10" is beyond
"1".
> (because the pointer is passed around the
> store to the counter)
>
> and also
On 10/26/23 16:23, Richard Sandiford wrote:
Victor Do Nascimento writes:
On 10/18/23 21:39, Richard Sandiford wrote:
Victor Do Nascimento writes:
Implement the aarch64 intrinsics for reading and writing system
registers with the following signatures:
uint32_t __arm_rsr(const
> Am 24.10.2023 um 21:09 schrieb Marek Polacek :
>
> On Tue, Oct 24, 2023 at 09:22:25AM +0200, Richard Biener wrote:
>>> On Mon, Oct 23, 2023 at 9:26 PM Marek Polacek wrote:
>>>
>>> On Thu, Oct 19, 2023 at 02:24:11PM +0200, Richard Biener wrote:
On Wed, Oct 11, 2023 at 10:48 PM Marek
> Am 26.10.2023 um 13:51 schrieb Siddhesh Poyarekar :
>
> On 2023-10-26 04:37, Martin Uecker wrote:
>> Hi Sid and Jakub,
>> here is the patch discussed in PR 109334.
>
> I can't approve, but here's a review:
Ok
Thanks for the review,
Richard
>> Martin
>> tree-optimization/109334:
> Am 26.10.2023 um 16:58 schrieb Qing Zhao :
>
>
>
>> On Oct 26, 2023, at 4:56 AM, Richard Biener
>> wrote:
>>
>>> On Thu, Oct 26, 2023 at 7:22 AM Jakub Jelinek wrote:
>>>
>>> On Wed, Oct 25, 2023 at 07:03:43PM +, Qing Zhao wrote:
For the code generation impact:
Control flow redundancy may choose abnormal edges for early checking,
but that breaks because we can't insert checks on such edges.
Introduce conditional checking on the dest block of abnormal edges,
and leave it for the optimizer to drop the conditional.
Also, oops, I noticed the new files
Victor Do Nascimento writes:
> Motivated by the need to print system register names in output
> assembly, this patch adds the required logic to
> `aarch64_print_operand' to accept rtxs of type CONST_STRING and
> process these accordingly.
>
> Consequently, an rtx such as:
>
> (set (reg/i:DI 0
Victor Do Nascimento writes:
> On 10/18/23 22:30, Richard Sandiford wrote:
>> Victor Do Nascimento writes:
>>> Add a build-time test to check whether system register data, as
>>> imported from `aarch64-sys-reg.def' has any duplicate entries.
>>>
>>> Duplicate entries are defined as any two
On Oct 26, 2023, at 5:34 AM, Richard Sandiford
wrote:
> dg-pch.exp handled dg-require-effective-target pch_supported_debug
> as a special case, by grepping the source code. This patch tries
> to generalise it to other dg-require-effective-targets, and to
> dg-skip-if.
>
> There also seemed to
Victor Do Nascimento writes:
> On 10/18/23 21:39, Richard Sandiford wrote:
>> Victor Do Nascimento writes:
>>> Implement the aarch64 intrinsics for reading and writing system
>>> registers with the following signatures:
>>>
>>> uint32_t __arm_rsr(const char *special_register);
>>>
Thanks for the updates.
Victor Do Nascimento writes:
> On 10/18/23 22:07, Richard Sandiford wrote:
>> Victor Do Nascimento writes:
>>> This patch defines the structure of a new .def file used for
>>> representing the aarch64 system registers, what information it should
>>> hold and the basic
On 10/18/23 22:30, Richard Sandiford wrote:
Victor Do Nascimento writes:
Add a build-time test to check whether system register data, as
imported from `aarch64-sys-reg.def' has any duplicate entries.
Duplicate entries are defined as any two SYSREG entries in the .def
file which share the
Tested on x86_64-darwin, x86_64-linux-gnu, pushed to trunk, thanks
Iain
--- 8< ---
Now we have shifted to using the same relocation mechanism as clang for
objective-c typeinfo the static linker needs to have a linker-visible
symbol for metadata names (this is only needed for GNU objective C, for
Changes from v1:
- Fixed Davids remarks on initial patch.
- Fixed mistake with deleted '*'.
Changes from v2:
- Reversed return value for bpf_const_not_ok_for_debug_p function.
Changes from v3:
- Fixed ICE in two bpf-next tests:
- if (!wi->is_lhs)
-
On 10/18/23 21:39, Richard Sandiford wrote:
Victor Do Nascimento writes:
Implement the aarch64 intrinsics for reading and writing system
registers with the following signatures:
uint32_t __arm_rsr(const char *special_register);
uint64_t __arm_rsr64(const char
> On Oct 26, 2023, at 4:56 AM, Richard Biener
> wrote:
>
> On Thu, Oct 26, 2023 at 7:22 AM Jakub Jelinek wrote:
>>
>> On Wed, Oct 25, 2023 at 07:03:43PM +, Qing Zhao wrote:
>>> For the code generation impact:
>>>
>>> turning the original x.buf
>>> to a builtin function call
>>>
1 - 100 of 162 matches
Mail list logo
