On Tue, Nov 29, 2022 at 7:10 PM Arthur Cohen wrote:
>
> Hi Richard,
>
> (...)
>
> +
> + unsigned HOST_WIDE_INT ltype_length
> += wi::ext (wi::to_offset (TYPE_MAX_VALUE (ltype_domain))
> +- wi::to_offset (TYPE_MIN_VALUE (ltype_domain)) + 1,
> >>>
> >>> TYPE_
On Tue, Nov 29, 2022 at 11:05 AM Manolis Tsamis wrote:
>
> When using SWAR (SIMD in a register) techniques a comparison operation within
> such a register can be made by using a combination of shifts, bitwise and and
> multiplication. If code using this scheme is vectorized then there is
> potent
On Thu, Nov 24, 2022 at 4:27 PM Iskander Shakirzyanov
wrote:
>
> How did you test the patch? If you bootstrapped it and ran the
> testsuite then it's OK.
>
> Yes, i ran testsuite and bootstrapped and everything seemed OK, but i missed
> fail of tests gcc.dg/Warray-bounds-34.c and gcc.dg/Warray-b
Update in V2:
Add documentation for -mlam={none,u48,u57} to x86 options in invoke.texi.
gcc/ChangeLog:
* doc/invoke.texi (x86 options): Document
-mlam={none,u48,u57}.
* config/i386/i386-opts.h (enum lam_type): New enum.
* config/i386/i386.c (ix86_memtag_can_tag_add
Thanks for your comment!
Date: Wed, 30 Nov 2022 12:30:02 +0800
Message-ID: <7ebkopxdx1@pike.rch.stglabs.ibm.com>
Segher Boessenkool writes:
>> > + else if ((ud4 == 0x && ud3 == 0x)
>> > + && ((ud1 & 0x8000) || (ud1 == 0 && !(ud2 & 0x8000
>> > +{
>> > + temp = !can_c
Ping.
> -Original Message-
> From: Tamar Christina
> Sent: Monday, October 31, 2022 12:00 PM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Kyrylo Tkachov
> ; Richard Sandiford
>
> Subject: [PATCH 7/8]AArch64: Consolidate zero and sign extension patterns
Ping x3
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, November 22, 2022 4:01 PM
> To: Tamar Christina ; Richard Sandiford
>
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: RE: [PATCH 5/8]AArch64 aarch64: Make existin
> > "Joel" == Joel Brobecker via Gdb-patches
> > writes:
>
> Joel> ChangeLog:
>
> Joel> * src-release.sh (GDB_SUPPORT_DIRS): Add libsframe.
>
> Joel> Ok to apply to master?
>
> Looks good to me.
> I think we recently agreed that gdb and binutils maintainers can approve
> patch
Hi,
This patch is just using a more readable pattern for "rldicl x,x,0,32"
to clean high 32bits.
Old pattern looks like: r118:DI=zero_extend(r120:DI#0)
new pattern looks like: r118:DI=r120:DI&0x
Bootstrap and regtest pass on ppc64{,le}.
Is this ok for trunk?
BR,
Jeff (Jiufu)
gcc/ChangeL
On Wed, Nov 30, 2022 at 3:12 AM H.J. Lu wrote:
>
> On Mon, Nov 28, 2022 at 11:04 PM Hongtao Liu wrote:
> >
> > On Mon, Nov 28, 2022 at 9:06 PM liuhongt wrote:
> > >
> > > For __builtin_ia32_vec_set_v16qi (a, -1, 2) with
> > > !flag_signed_char. it's transformed to
> > > __builtin_ia32_vec_set_v1
PR analyzer/103546 tracks various false positives seen on
flex-generated lexers.
Whilst investigating them, I noticed an ICE with
-fanalyzer-call-summaries due to attempting to store sm-state
for an UNKNOWN svalue, which this patch fixes.
This patch also provides known_function implementations of
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4400-g84046b192e568e.
gcc/analyzer/ChangeLog:
* region-model-impl-calls.cc (class kf_fgets): Move to sm-file.cc.
(kf_fgets::impl_call_pre): Likewise.
(class kf_fread): Likewise.
(k
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4398-g3a32fb2eaa761a.
gcc/analyzer/ChangeLog:
PR analyzer/105784
* region-model-manager.cc
(region_model_manager::maybe_fold_binop): For POINTER_PLUS_EXPR,
PLUS_EXPR and MINUS_EXPR
On Tue, Nov 29, 2022 at 9:54 AM wrote:
>
> From: Sören Tempel
>
> On glibc, there are two versions of strerror_r: An XSI-compliant and a
> GNU-specific version. The latter is only available on glibc. In order
> to avoid duplicating the post-processing code of error messages, this
> commit provide
On Tue, Nov 29, 2022 at 04:38:50PM -0500, Jason Merrill wrote:
> > --- gcc/testsuite/g++.dg/gomp/for-21.C.jj 2020-01-12 11:54:37.178401867
> > +0100
> > +++ gcc/testsuite/g++.dg/gomp/for-21.C 2022-11-29 13:06:59.038410557
> > +0100
> > @@ -54,9 +54,9 @@ void
> > f6 (S (&a)[10])
> > {
>
Weitergeleitete Nachricht
Betreff: [PATCH] libstdc++: Add error handler for
Datum: Tue, 29 Nov 2022 22:41:07 +0100
Von: Björn Schäpers
An: gcc-patc...@gc.gnu.org, libstd...@gcc.gnu.org
From: Björn Schäpers
Not providing an error handler results in a nullpointer dereferen
On 11/29/22 07:32, Jakub Jelinek wrote:
Hi!
The PR84469 patch I've just posted regresses the for-21.C testcase,
when in OpenMP loop there are at least 2 associated loops and
in a template outer structured binding with non type dependent expression
is used in the expressions of some inner loop, w
On 11/29/22 15:03, Patrick Palka wrote:
In a SFINAE context composite_pointer_type returns error_mark_node if
the given pointer types are incompatible, but the SPACESHIP_EXPR case of
cp_build_binary_op wasn't prepared to handle error_mark_node, which led
to an ICE (from spaceship_comp_cat) for th
Hi Iain,
On Tue, 29 Nov 2022, Iain Buclaw via Gcc-patches wrote:
> This looks obvious, however I don't know how things are generated for
> the online documentation site in order to say this won't cause any
> problems for whatever process is building these pages.
>> maintainer-scripts/ChangeLog:
>
In a SFINAE context composite_pointer_type returns error_mark_node if
the given pointer types are incompatible, but the SPACESHIP_EXPR case of
cp_build_binary_op wasn't prepared to handle error_mark_node, which led
to an ICE (from spaceship_comp_cat) for the below testcase where we form
a <=> with
On Mon, Nov 28, 2022 at 11:04 PM Hongtao Liu wrote:
>
> On Mon, Nov 28, 2022 at 9:06 PM liuhongt wrote:
> >
> > For __builtin_ia32_vec_set_v16qi (a, -1, 2) with
> > !flag_signed_char. it's transformed to
> > __builtin_ia32_vec_set_v16qi (_4, 255, 2) in the gimple,
> > and expanded to (const_int 2
Ping.
This looks obvious, however I don't know how things are generated for
the online documentation site in order to say this won't cause any
problems for whatever process is building these pages.
Excerpts from Iain Buclaw's message of November 21, 2022 11:29 am:
> Hi,
>
> This patch adds gdc t
Hi PA, hi Andrew, hi Jakub, hi all,
On 29.11.22 16:56, Paul-Antoine Arras wrote:
This patch adds support for 'gfx803' as an alias for 'fiji' in OpenMP
context selectors, [...]
I think this should be documented somewhere. We have
https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Context-Selectors.h
Hi Richard,
(...)
+
+ unsigned HOST_WIDE_INT ltype_length
+= wi::ext (wi::to_offset (TYPE_MAX_VALUE (ltype_domain))
+- wi::to_offset (TYPE_MIN_VALUE (ltype_domain)) + 1,
TYPE_MIN_VALUE is not checked to be constant, also the correct
check would be to use TREE_CODE (..) ==
From: Sören Tempel
On glibc, there are two versions of strerror_r: An XSI-compliant and a
GNU-specific version. The latter is only available on glibc. In order
to avoid duplicating the post-processing code of error messages, this
commit provides a separate strerror_go symbol which always refers t
On 29/11/2022 15:56, Paul-Antoine Arras wrote:
Hi all,
This patch adds support for 'gfx803' as an alias for 'fiji' in OpenMP
context selectors, so as to be consistent with LLVM. It also adds test
cases checking all supported AMD ISAs are properly recognised when used
in a 'declare variant' co
Can we get the three patches in this patch set reviewed? Without them, GCC 13
can't be built on Fedora 37 which defaults to IEEE 128-bit long double.
| Date: Tue, 1 Nov 2022 22:44:01 -0400
| Subject: [PATCH 3/3] Update float 128-bit conversions, PR target/107299.
| Message-ID:
--
Michael Meiss
Can we get the three patches in this patch set reviewed? Without the patches
applied, GCC 13 will not build on Fedora 37, which uses long double defaulting
to IEEE 128-bit.
| Date: Tue, 1 Nov 2022 22:42:30 -0400
| Subject: [PATCH 2/3] Make __float128 use the _Float128 type, PR target/107299
| Mes
From: Sören Tempel
On glibc, there are two versions of strerror_r: An XSI-compliant and a
GNU-specific version. The latter is only available on glibc. In order
to avoid duplicating the post-processing code of error messages, this
commit provides a separate strerror_go symbol which always refers t
Can we please get this patch reviewed? GCC 13 won't build on Fedora 37 (which
defaults to long double being IEEE 128-bit) without the 3 patches in this set.
| Date: Tue, 1 Nov 2022 22:40:43 -0400
| Subject: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR
target/107299
| Message-ID:
Tested x86_64-linux. Pushed to trunk.
-- >8 --
GCC assumes that any global variable might be modified by operator new,
and so in the testcase for this PR all data members get reloaded after
allocating new storage. By making local copies of the _M_start and
_M_finish members we avoid that, and the
Tested x86_64-linux. Pushed to trunk.
-- >8 --
There's no need to call a _M_xxx_dispatch function with a
statically-known __false_type tag, we can just directly call the
function that should be dispatched to. This will compile a tiny bit
faster and save a function call with optimization or inlini
On Tue, 29 Nov 2022 at 20:43, Andrew Pinski wrote:
>
> On Tue, Nov 29, 2022 at 6:40 AM Prathamesh Kulkarni via Gcc-patches
> wrote:
> >
> > Hi,
> > For the following test-case:
> >
> > int16x8_t foo(int16_t x, int16_t y)
> > {
> > return (int16x8_t) { x, y, x, y, x, y, x, y };
> > }
>
> (Not to
Hi all,
This patch adds support for 'gfx803' as an alias for 'fiji' in OpenMP
context selectors, so as to be consistent with LLVM. It also adds test
cases checking all supported AMD ISAs are properly recognised when used
in a 'declare variant' construct.
Is it OK for mainline?
Thanks,
--
PA
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These names (and __unused) are defined as macros by newlib.
libstdc++-v3/ChangeLog:
* include/std/format: Rename all variables called __used or
__packed.
* testsuite/17_intro/badnames.cc: Add no_pch options.
* testsu
On Tue, Nov 29, 2022 at 6:40 AM Prathamesh Kulkarni via Gcc-patches
wrote:
>
> Hi,
> For the following test-case:
>
> int16x8_t foo(int16_t x, int16_t y)
> {
> return (int16x8_t) { x, y, x, y, x, y, x, y };
> }
(Not to block this patch)
Seems like this trick can be done even with less than perf
Hi,
For the following test-case:
int16x8_t foo(int16_t x, int16_t y)
{
return (int16x8_t) { x, y, x, y, x, y, x, y };
}
Code gen at -O3:
foo:
dupv0.8h, w0
ins v0.h[1], w1
ins v0.h[3], w1
ins v0.h[5], w1
ins v0.h[7], w1
ret
For
On Tue, 2022-11-29 at 09:52 +, 陈 小龙 wrote:
> +(define_insn "2"
> + [(set (match_operand:ANYF 0 "register_operand" "=f")
> + (unspec:ANYF[(match_operand:ANYF 1 "register_operand" "f")]
> + FLOAT))]
> + "TARGET_HARD_FLOAT&&(flag_fp_int_builtin_inexact ||
> !flag_trapping_mat
Hi Richard,
> Just to make sure I understand: isn't it really just MOVN? I would have
> expected a 32-bit MOVZ to be equivalent to (and add no capabilities over)
> a 64-bit MOVZ.
The 32-bit MOVZ immediates are equivalent, MOVN never overlaps, and
MOVI has some overlaps . Since we allow all 3 var
While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be. This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.
We
While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
caused by DFP types handling. These tests are generated during 'make
check' and enabling DFP made generation different (not sure if new
non-DFP tests are generated,
Hi,
This patch is just add test cases, and tested on ppc64{,le}.
With previous patches on this serial passed, Bootstrap and regtest
passed on ppc64{,le} and x86_64.
Is this ok for trunk?
BR,
Jeff (Jiufu)
PR target/65421
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr65421-1
Hi,
This patch checks an assignment to see if it is copy block to a return
variable, and if the function return through registers, then use the
register mode to move sub-blocks for the assignment.
Bootstraped and regtested on ppc{,le} and x86_64.
Is this ok for trunk?
BR,
Jeff (Jiufu)
P
Hi,
This patch checks an assignment to see if the "from" is about parameter,
and if the parameter may passing through registers, then use the register
mode to move sub-blocks for the assignment.
Bootstraped and regtested on ppc{,le} and x86_64.
Is this ok for trunk?
BR,
Jeff (Jiufu)
gcc/ChangeL
Hi,
When assigning a parameter to a variable, or assigning a variable to
return value with struct type, "block move" are used to expand
the assignment. It would be better to use the register mode according
to the target/ABI to move the blocks. And then this would raise more
opportunities for othe
The following deals with the situation where we have
[local count: 1073741824]:
_5 = bytes.D.25336._M_impl.D.24643._M_start;
_6 = bytes.D.25336._M_impl.D.24643._M_finish;
pretmp_66 = bytes.D.25336._M_impl.D.24643._M_end_of_storage;
if (_5 != _6)
goto ; [70.00%]
else
goto ; [30.00%]
...
[lo
Hi Segher,
Thanks for your comment!
Segher Boessenkool writes:
> On Mon, Nov 28, 2022 at 03:51:59PM +0800, Jiufu Guo wrote:
>> Jiufu Guo via Gcc-patches writes:
>> > Segher Boessenkool writes:
>> >>> > + else
>> >>> > + {
>> >>> > +emit_move_insn (temp,
>> >>> > +
Hi!
The PR84469 patch I've just posted regresses the for-21.C testcase,
when in OpenMP loop there are at least 2 associated loops and
in a template outer structured binding with non type dependent expression
is used in the expressions of some inner loop, we don't diagnose those
any longer, as the
Hi!
As shown on the decomp56.C testcase, if the range for expression
when using structured bindings is not type dependent, we deduce
the finish the structured binding types only when not in template
(cp_convert_range_for takes care of that), but if in templates,
do_range_for_auto_deduction is call
When we version loops for vectorization during if-conversion it
can happen that either loop vanishes because we run some VN and
CFG cleanup. If the to-be vectorized part vanishes we already
redirect the versioning condition to the original loop. The following
does the same in case the original lo
This just makes the pattern matching more robust.
Tested on SPARC64/Solaris and x86-64/Linux, applied on the mainline.
2022-11-29 Eric Botcazou
PR ada/107810
* gnat.dg/unchecked_convert9.adb: Adjust pattern.
--
Eric Botcazoudiff --git a/gcc/testsuite/gnat.dg/unchecked_conve
Hi all,
based on everyone's comments I have sent a v2 of this patch that can
be found here
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607472.html
As per Richard's comments the pattern now uses vec_cond_expr instead and
includes other fixes as requested.
Also based on Tamar's suggest
When using SWAR (SIMD in a register) techniques a comparison operation within
such a register can be made by using a combination of shifts, bitwise and and
multiplication. If code using this scheme is vectorized then there is potential
to replace all these operations with a single vector comparison
Hi!
While for the normal cases it seems to be correct to implement
reverse multiplication (op1_range/op2_range) through division
with float_binary_op_range_finish, reverse division (op1_range)
through multiplication with float_binary_op_range_finish or
(op2_range) through division with float_binar
The target clone pass is the only small IPA pass that doesn't disable
itself after errors but has properties whose verification can fail
because we cut off build SSA passes after errors.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR ipa/107897
* multiple_target.c
The following avoids ICEing with a mismatched prototype for alloca
and -Walloca-larger-than using irange for checks which doesn't
like mismatched types.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/107898
* gimple-ssa-warn-alloca.cc (alloca_cal
Hi Segher,
Thanks for your review!
Segher Boessenkool writes:
> On Mon, Nov 28, 2022 at 11:37:34AM +0800, Jiufu Guo wrote:
>> Segher Boessenkool writes:
>> > On Fri, Nov 25, 2022 at 04:11:49PM +0800, Kewen.Lin wrote:
>> >> on 2022/10/26 19:40, Jiufu Guo wrote:
>> >> for "li/lis + oris/xoris",
> >>> Yeah, I personally want to support RVV intrinsics in GCC13. As RVV
> >>> intrinsic is going to release soon next week.
> >>
> >> OK, that's fine with me -- I was leaning that way, and I think Jeff only
> >> had a weak opposition. Are there any more changes required outside the
> >> RISC-V ba
gcc/ChangeLog:
* configure: Regenerate.
---
gcc/configure | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/configure b/gcc/configure
index aa0960991c9..a742d4406a8 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -7843,7 +7843,8 @@ if test x${enable_multiar
On Tue, Nov 29, 2022 at 2:15 AM HAO CHEN GUI wrote:
>
> Hi Richard,
>
> 在 2022/11/29 2:46, Richard Biener 写道:
> > Anyhow - my question still stands - what's the fallback for the callers
> > that do not check for failure? How are we sure we're not running into
> > these when relaxing the requireme
Hi Harald,
It looks good to me.
Thanks to you and Steve for the patch.
Paul
On Mon, 28 Nov 2022 at 20:05, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> as reported, the Fortran standard requires all actual argument
> expressions to be evaluated (e.g. F2018:15.5.3).
>
> There were two case
61 matches
Mail list logo
