On Mon, Oct 25, 2021 at 6:29 PM Guillermo E. Martinez via Gcc-patches
wrote:
>
> Hello people,
>
> This patch v2 to add support for atomics operations in eBPF target
> using the gcc built-in functions:
>
> __atomic__fetch
> __atomic_fetch_
>
> This new version restrict/enable the use of `add +
On 2021/10/21 18:55, Richard Biener wrote:
> On Thu, 21 Oct 2021, Xionghu Luo wrote:
>
>>
>>
>> On 2021/10/15 13:51, Xionghu Luo via Gcc-patches wrote:
>>>
>>>
>>> On 2021/9/23 20:17, Richard Biener wrote:
On Wed, 22 Sep 2021, Xionghu Luo wrote:
>
>
> On 2021/8/11 17:16, Ri
Hi,
As PR102897 shows, there is one incorrect assertion in function
simplify_permutation, which is based on the wrong assumption that
all cases with op2_type == tgt_type are handled previously, the
proposed fix is to remove this wrong assertion.
Bootstrapped and regtested on x86_64-redhat-linux,
Hello people,
This patch v2 to add support for atomics operations in eBPF target
using the gcc built-in functions:
__atomic__fetch
__atomic_fetch_
This new version restrict/enable the use of `add + fetch' and the
rest of atomic instructions using the -m[no-]atomics option to
generate code ru
On Mon, 25 Oct 2021, Richard Biener via Gcc-patches wrote:
> So it looks like tm_d.h is much more stripped down compared to regular
> tm_p.h but also oddly enough config/default-d.c includes tm_d.h
> while config/default-c.c explicitely documents itself to not do that.
I think the intent of that
On Mon, Oct 25, 2021 at 10:01 PM Rainer Orth
wrote:
>
> gcc.target/i386/avx512f-pr96891-3.c currently FAILs on 32-bit Solaris/x86:
>
> FAIL: gcc.target/i386/avx512f-pr96891-3.c scan-assembler-times
> (?n)vpcmp[bwdq][ t]*\$7 4
>
> There are only 3 instances of the expected pattern because
I think this can be put in as an obvious fix.
Thanks for the patch.
Rainer Orth 于2021年10月25日周一 下午9:53写道：
>
> The gcc.target/i386/avx512fp16-trunchf.c test FAILs on 32-bit Solaris/x86:
>
> FAIL: gcc.target/i386/avx512fp16-trunchf.c scan-assembler-times vcvttsh2si[
> t]+[^{\\n]*(?:%xmm[0-9]|\
VRP currently performs a simplification that we can move into the
general simplification code. I'll just quote the comment:
If the conditional is of the form SSA_NAME op constant and the SSA_NAME
was set via a type conversion, try to replace the SSA_NAME with the RHS
of the type convers
This patch changes the ranger VRP pass to simplify all statements, not
just the ones with ranges. I believe Jeff had mentioned we were no
longer doing this a while back. Now we need it when running as the VRP2
pass to satisfy the testcase: gcc.dg/wrapped-binop-simplify.c
This also requires a
This fixes bootstrap for the current problems building libffi.
I'll work on getting this into upstream as well. If the maintainers
want it done differently, at least we have bootstrap working again
until then.
Tested on powerpc64-linux {-m32,-m64}.
Segher
2021-10-25 Segher Boessenkool
li
Hi!
On Mon, Oct 25, 2021 at 03:33:21PM -0500, Paul A. Clarke wrote:
> * config/rs6000/x86intrin.h: Move some included headers to new
> headers; include new immintrin.h instead.
s/; i/. I/ (And instead of what?)
> * config/rs6000/immintrin.h: New.
> * config/rs6000/x86gp
On 10/25/21 2:24 PM, Jeff Law wrote:
On 10/25/2021 1:31 PM, Martin Sebor wrote:
On 10/25/21 12:57 PM, Jeff Law wrote:
On 10/23/2021 5:49 PM, Martin Sebor via Gcc-patches wrote:
Somewhat belatedly following Aldy's lead on finishing
the conversion to Ranger, the attached patch modifies
gimpl
On 10/25/21 4:24 PM, Jeff Law via Gcc-patches wrote:
On 10/25/2021 1:31 PM, Martin Sebor wrote:
On 10/25/21 12:57 PM, Jeff Law wrote:
On 10/23/2021 5:49 PM, Martin Sebor via Gcc-patches wrote:
Somewhat belatedly following Aldy's lead on finishing
the conversion to Ranger, the attached patc
Tests which only include expect many other include files
to be brought in, but not enough are.
Try to increase compatibility with x86 headers by:
- Create new immintrin.h, including the analogous subset of intrinsics
headers available for powerpc.
- Create new x86gprintrin.h, serving exclusivel
Ping...
On 10/11/21 5:17 PM, Bill Schmidt wrote:
> Hi! Ping, please. :-)
>
> Bill
>
> On 9/29/21 3:38 PM, Bill Schmidt wrote:
>> Hi Segher,
>>
>> Might as well ping this before I go on vacation. :-) I think we're up to
>> 06/18:
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/57
Inline functions defined in smmintrin.h need "extern" as part of their
declaration, otherwise instances of those functions are created in the
objects which include them.
Fixes commits:
- acd4b9103c1a30c833de4eee31fb69c3ff13cd77
- 9d352c68e8c8b642a36a6bcfc7f6b5dba11ac748
- bd9a8737d478f7f1d01a9d5f1
On 10/25/2021 1:31 PM, Martin Sebor wrote:
On 10/25/21 12:57 PM, Jeff Law wrote:
On 10/23/2021 5:49 PM, Martin Sebor via Gcc-patches wrote:
Somewhat belatedly following Aldy's lead on finishing
the conversion to Ranger, the attached patch modifies
gimple-ssa-warn-access and other passes th
On 10/25/21 12:57 PM, Jeff Law wrote:
On 10/23/2021 5:49 PM, Martin Sebor via Gcc-patches wrote:
Somewhat belatedly following Aldy's lead on finishing
the conversion to Ranger, the attached patch modifies
gimple-ssa-warn-access and other passes that use
the pointer_query machinery to provide R
On 10/25/21 12:57 PM, Jeff Law wrote:
On 10/23/2021 5:49 PM, Martin Sebor via Gcc-patches wrote:
Somewhat belatedly following Aldy's lead on finishing
the conversion to Ranger, the attached patch modifies
gimple-ssa-warn-access and other passes that use
the pointer_query machinery to provide R
On 10/25/2021 12:49 PM, Aldy Hernandez wrote:
On Mon, Oct 25, 2021 at 8:42 PM Jeff Law wrote:
On 10/24/2021 12:25 PM, Aldy Hernandez wrote:
On 10/24/21 6:57 PM, Jeff Law wrote:
Ugwe could put the test back, check for some random large
number, and come up with a more satisfactory
On 10/23/2021 5:49 PM, Martin Sebor via Gcc-patches wrote:
Somewhat belatedly following Aldy's lead on finishing
the conversion to Ranger, the attached patch modifies
gimple-ssa-warn-access and other passes that use
the pointer_query machinery to provide Ranger with
the statement it's being ca
On Mon, Oct 25, 2021 at 4:16 PM Roger Sayle wrote:
>
>
> Hi Uros,
> I believe the proposed sequences should be dramatically faster than LLVM's
> implementation(s), due to the large latencies required to move values between
> the vector and scalar parts on modern x86_64 microarchitectures. All of
In PR testsuite/102910 there was some discussion about alloca.h and
whether that header exists or whether 'alloca' is provided by stdlib.h
or ...
Well, some grepping showed that libgomp.oacc-c-c++-common/loop-gwv-2.c
also used 'alloca'. Solution: Do it like other testcases and use
__builtin_alloc
On Mon, Oct 25, 2021 at 8:42 PM Jeff Law wrote:
>
>
>
> On 10/24/2021 12:25 PM, Aldy Hernandez wrote:
> > On 10/24/21 6:57 PM, Jeff Law wrote:
> >
> >>> Ugwe could put the test back, check for some random large
> >>> number, and come up with a more satisfactory test later? ;-)
> >> I thoug
On 10/23/2021 3:14 AM, Aldy Hernandez wrote:
First, ssa-dom-thread-7 was looking at a dump file that was not
being generated. This probably happened in the detangling of the VRP
threader from VRP, and I didn't notice because the test came back as
with UNRESOLVED instead of FAIL.
Second, aarc
On 10/24/2021 12:25 PM, Aldy Hernandez wrote:
On 10/24/21 6:57 PM, Jeff Law wrote:
Ugwe could put the test back, check for some random large
number, and come up with a more satisfactory test later? ;-)
I thought our "counting" based tests could only check equality (ie,
expect to see
Tamar Christina writes:
>> >>
>> >> int32x4_t foo(int32x4_t x) {
>> >> return vshlq_s32(x, vdupq_n_s32(256)); }
>> >>
>> >> should fold to “x” (if we fold it at all). Similarly:
>> >>
>> >> int32x4_t foo(int32x4_t x) {
>> >> return vshlq_s32(x, vdupq_n_s32(257)); }
>> >>
>> >> should fold to
This patch is for PR102910. There's no reason why the testcase in
question needs to use alloca, but I wasn't aware there were portability
issues with it until I saw this issue.
I think this fix is probably obvious and will commit it tomorrow unless
I get some feedback on it meanwhile.
-Sand
New patch with the proposed workaround below.
I also slightly change the _M_merge_multi implementation so that if the
new hash code computation raise an exception the node is simply not
extracted rather than extracted and then released. This way, if it takes
place on the 1st moved node the _GL
On Wed, Oct 20, 2021 at 03:22:10PM +0200, Richard Biener via Gcc-patches wrote:
> This maps -ftrapv to -fsanitize=signed-integer-overflow
> -fsanitize-undefined-trap-on-error, effectively removing
> flag_trapv (or rather making it always false).
>
> This has implications on language support - whil
On 10/25/2021 10:58 AM, Andrew MacLeod wrote:
On 10/20/21 6:28 AM, Aldy Hernandez wrote:
Sometimes we can solve a candidate path without having to recurse
further back. This can mostly happen in fully resolving mode, because
we can ask the ranger what the range on entry to the path is, but
t
On Mon, Oct 25, 2021 at 6:58 PM Andrew MacLeod wrote:
>
> On 10/20/21 6:28 AM, Aldy Hernandez wrote:
> > Sometimes we can solve a candidate path without having to recurse
> > further back. This can mostly happen in fully resolving mode, because
> > we can ask the ranger what the range on entry to
On 10/20/21 6:28 AM, Aldy Hernandez wrote:
Sometimes we can solve a candidate path without having to recurse
further back. This can mostly happen in fully resolving mode, because
we can ask the ranger what the range on entry to the path is, but
there's no reason this can't always apply. This on
On 10/20/21 7:22 AM, Richard Biener via Gcc-patches wrote:
This maps -ftrapv to -fsanitize=signed-integer-overflow
-fsanitize-undefined-trap-on-error, effectively removing
flag_trapv (or rather making it always false).
It sounds like C/C++ programmers might benefit from this change
but users of
Hi!
On Mon, Oct 25, 2021 at 03:36:25PM +0200, Martin Liška wrote:
> --- a/gcc/config/rs6000/rs6000-internal.h
> +++ b/gcc/config/rs6000/rs6000-internal.h
> @@ -189,4 +189,13 @@ extern bool rs6000_passes_vector;
> extern bool rs6000_returns_struct;
> extern bool cpu_builtin_p;
>
> +struct rs600
> >>
> >> int32x4_t foo(int32x4_t x) {
> >> return vshlq_s32(x, vdupq_n_s32(256)); }
> >>
> >> should fold to “x” (if we fold it at all). Similarly:
> >>
> >> int32x4_t foo(int32x4_t x) {
> >> return vshlq_s32(x, vdupq_n_s32(257)); }
> >>
> >> should fold to x << 1 (again if we fold it at all)
On Mon, Oct 25, 2021 at 7:35 AM Martin Liška wrote:
>
> Hello.
>
> The patch adds missing Makefile mostlyclean.
>
> Ready to be installed?
> Thanks,
> Martin
>
Generally the way the various "*clean" targets are arranged, in order
of cleanliness, from least clean to most clean, is:
mostlyclean
cle
On Mon, Oct 25, 2021 at 12:46:30PM +0200, Richard Biener wrote:
> On Thu, Oct 21, 2021 at 5:42 PM Segher Boessenkool
> wrote:
> > It's disgusting, and fragile. The define is slightly better than having
> > to write it out every time. But can this not be done properly?
> >
> > If you use object-o
On 10/21/21 3:59 PM, Andrew Pinski wrote:
On Thu, Oct 21, 2021 at 8:04 AM Andrew MacLeod wrote:
On 10/19/21 7:13 PM, Andrew Pinski wrote:
On Tue, Oct 19, 2021 at 3:32 PM Andrew MacLeod wrote:
On 10/19/21 5:13 PM, Andrew Pinski wrote:
On Tue, Oct 19, 2021 at 1:29 PM Andrew MacLeod via Gcc-pa
These tools are no longer maintained and have never supported project
files. They are replaced by the Ada Language Server which implements the
Language Server Protocol.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* gcc-interface/Make-lang.in, gcc-interface/Makefile.in: Rem
This patch improves the handling of the Ada_2022 aspect involving
user-defined literals on integers, reals, and strings, when the literal
that must be converted to a type (for which the aspect is defined)
appears as an operand of a predefined operator. The target type may be
given by the type of th
Subsequent to prior major cleanups of Uint fields, this patch includes a
few more, fairly minor, cleanups.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* freeze.adb (Freeze_Fixed_Point_Type): Remove
previously-inserted test for Uint_0; no longer needed.
* ge
Update all ?X? to ?.x? (likewise for [-gnatwx]
* ?_x? -> [-gnatw_x]
* ?.x? -> [-gnatw.x]
With the support of the ?_x? insertion sequences, messages that related
to -gnatw_a, -gnatw_c, -gnatw_p, -gnatw_r are now correctly advertised as
relating to these.
Tested on x86_64-pc-linux-gnu, committed o
If a field has Type_Only set to something other than No_Type_Only, then
we need to fetch the field from a possibly different node. For example,
the Modulus field has Type_Only = Base_Type_Only (and is documented as a
"[base type only]" field in Einfo). Therefore if we try to get Modulus
from node N
Replace a confusing loop with two exit staments by a straightforward
while loop with an explicit condition. Also, explicitly iterate over
discriminants and components, not over entities.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_ch4.adb (Expand_Composite_Equality):
When casing on a composite value, certain component types/subtypes were
previously disallowed. These included access types, real types,
nonstatic discrete subtypes, and others. This restriction is relaxed so
that such components are now allowed, but no non-box value may be
specified for such a comp
The GMP variant of Ada.Numerics.Big_Numbers.Big_Integers is currently
not used, but since we keep it, it seems worth to keep it up-to-date
with respect to the corresponding spec.
Part of providing a gdb pretty-printer for Big_Integer objects.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc
This patch changes Declaration_Node to avoid returning certain strange
node kinds. We don't avoid them all (in particular N_Null_Statement),
but we document what it's returning with a pragma Assert.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* einfo-utils.adb (Declaration
For consistency, add Global => null contracts also to expression
functions in the Ada.Strings.Superbounded package.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/a-strsup.ads (Super_Length, Super_Element,
Super_Slice): Add Global contracts.diff --git a/gcc/
Replace subtle conditions on First_Entity/Last_Entity with a
straightforward Number_Formals/First_Formal/Last_Formal.
Code cleanup related to handling of dispatching equality in SPARK.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_ch3.adb (Predefined_Primitive_Bodies)
Routine Predefined_Primitive_Bodies, which create predefined primitives
for derived tagged types, is only called with non-interface types
entities (which is even enforced with an assertion at the very start of
its body). There is no need to recheck this condition when creating
individual primitive
When spawning subprocesses with fork & execv there is no need to check
the result of execve, because it either succeeds and does not return or
fails and returns -1.
This is only a code cleanup related to the use of fork-vs-vfork in
GNATprove; behaviour is unaffected, though the GNAT runtime librar
CodePeer was warning about this variable being potentially used without
being initialized.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_ch8.adb (Analyze_Subprogram_Renaming): Set New_S to Empty.diff --git a/gcc/ada/sem_ch8.adb b/gcc/ada/sem_ch8.adb
--- a/gcc/ada/sem_c
There are two variants of the Ada.Strings.Unbounded_String package, with
and without atomic reference counters. The underlying pointer is never
null in one variant (and had a null-excluding type) and almost never
null in the other variant (and now has a null-excluding type as well).
Cleanup relate
When using cross-reference information to get subprogram effects in
SPARK (i.e. its reads and writes), we were calling Renamed_Object on
enumeration literals. This was pointless but harmless; now it rightly
triggers an assertion failure in developer builds, so avoid that.
Tested on x86_64-pc-linux
Which is a false positive, caused by a confusion on the expanded code
for pragma Loop_Variant.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/s-widthu.adb: Add pragma Annotate.diff --git a/gcc/ada/libgnat/s-widthu.adb b/gcc/ada/libgnat/s-widthu.adb
--- a/gcc/ada/lib
Ada 2022 specifies that when the controlling type of a formal abstract
subprogram declaration is a formal type, and the actual type is a
class-wide type T'Class, the actual subprogram can be an implicitly
declared subprogram corresponding to a primitive operation of type T
(AI12-0165-1/05).
Tested
There are three "fields" that are aliases for the Renamed_Or_Alias
field: Alias, Renamed_Entity, and Renamed_Object. The getters and
setters were (mis)used more or less interchangeably, in violation of the
comments.
This patch adds assertions to enforce the comments, and changes all of
the call si
Checking for ghost placement was only occurring inside the various
versions of predicate aspects, not inside the pragma Predicate. Now
fixed.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_ch13.adb (Freeze_Entity_Checks): Perform same check on
predicate expressi
Count_Compile_Time_Pragma_Warnings also counted deleted pragmas. This
caused discrepancies ultimately leading to a crash when Compile_Time
warnings were suppressed by a Warnings(Off, ...) pragma.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* erroutc.adb (Count_Compile_Time
This patch makes execute_ranger_vrp () match what VRP does and output
any exported ranges at the end of the pass to a dump file, without
needing TDF_DETAILS to be provided.
Bootstraps onx86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
>From 17d26698aa31268acdf5e1d4d0bc363dd35378ac Mon
When I split out the ranger debug flags from the evrp-mode flag, I
should have also made the 3 separate debug flags their own unique flag
value, and combined them for the various options. As it is, when you
ask for a trace, you also gets cache output, which is unintended. This
patch resolves
On 10/21/21 3:02 PM, Andrew MacLeod wrote:
As I'm tweaking installing ranger as the VRP2 pass, I am getting a
stage 2 bootstrap failure now:
In file included from
/opt/notnfs/amacleod/master/gcc/gcc/fortran/trans-decl.c:28:
/opt/notnfs/amacleod/master/gcc/gcc/tree.h: In function ‘void
gfc_con
"Andre Vieira (lists)" writes:
> Hi,
>
> This fixes the alignment on the memory access type for neon loads &
> stores in the gimple lowering. Bootstrap ubsan on aarch64 builds again
> with this change.
>
>
> 2021-10-25 Andre Vieira
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-buil
Hello.
The patch adds missing Makefile mostlyclean.
Ready to be installed?
Thanks,
Martin
PR other/102657
libcody/ChangeLog:
* Makefile.in: Add mostlyclean Makefile target.
---
libcody/Makefile.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libcody/
nt 13 [0xd])
> (const_int 15 [0xf])
> (const_int 0 [0])
> ]))
>
> (insn 8 7 9 2 (set (reg:V8QI 92 [ _2 ])
> (const_vector:V8QI [
> (const_int 8 [0x8])
> (const_int 9 [0x9])
>
> -Original Message-
> From: Richard Biener
> Sent: Friday, October 15, 2021 12:31 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek ; nd
>
> Subject: Re: [PATCH] middle-end: fix de-optimizations with bitclear patterns
> on signed values
>
> On Fri, 15 Oct 2021, Tama
Ping….
Is this Okay for trunk?
> On Oct 18, 2021, at 2:26 PM, Qing Zhao via Gcc-patches
> wrote:
>
> Hi, Jakub,
>
> This is the 2nd version of the patch based on your comment.
>
> Bootstrapped on both x86 and aarch64. Regression testings are ongoing.
The regression testing looks good.
Than
Hi Uros,
I believe the proposed sequences should be dramatically faster than LLVM's
implementation(s), due to the large latencies required to move values between
the vector and scalar parts on modern x86_64 microarchitectures. All of the
SSE2 instructions used in the sequences proposed by my pat
Hi All,
These tests are testing Advanced SIMD codegen, so if the compiler or the
testsuite is forcing SVE they will fail.
This adds +nosve so that we always generate neon.
Regtested on aarch64-none-linux-gnu and no issues.
Committed under the obvious rule.
Thanks,
Tamar
gcc/testsuite/ChangeLo
gcc.target/i386/avx512f-pr96891-3.c currently FAILs on 32-bit Solaris/x86:
FAIL: gcc.target/i386/avx512f-pr96891-3.c scan-assembler-times (?n)vpcmp[bwdq][
t]*\$7 4
There are only 3 instances of the expected pattern because Solaris/x86
defaults to -mno-stv. Fixed by compiling with -mstv
The gcc.target/i386/avx512fp16-trunchf.c test FAILs on 32-bit Solaris/x86:
FAIL: gcc.target/i386/avx512fp16-trunchf.c scan-assembler-times vcvttsh2si[
t]+[^{\\n]*(?:%xmm[0-9]|(%esp))+, %eax(?:\\n|[ t]+#) 3
FAIL: gcc.target/i386/avx512fp16-trunchf.c scan-assembler-times vcvttsh2usi
On Mon, Oct 25, 2021 at 6:42 AM Rainer Orth
wrote:
>
> gcc.target/i386/pr100704-[12].c currently FAIL on 64-bit Solaris/x86:
>
> FAIL: gcc.target/i386/pr100704-1.c scan-assembler-not pushq
> FAIL: gcc.target/i386/pr100704-2.c scan-assembler-not pushq
>
> Fixed by compiling with -fomit-frame-point
On Mon, Oct 25, 2021 at 6:46 AM Rainer Orth
wrote:
>
> Several of the gcc.target/i386/pieces-memset-*.c tests FAIL on 32-bit
> Solaris/x86:
>
> FAIL: gcc.target/i386/pieces-memset-1.c scan-assembler-not %[re]bp
> FAIL: gcc.target/i386/pieces-memset-4.c scan-assembler-not %[re]bp
> FAIL: gcc.targe
Several of the gcc.target/i386/pieces-memset-*.c tests FAIL on 32-bit
Solaris/x86:
FAIL: gcc.target/i386/pieces-memset-1.c scan-assembler-not %[re]bp
FAIL: gcc.target/i386/pieces-memset-4.c scan-assembler-not %[re]bp
FAIL: gcc.target/i386/pieces-memset-41.c scan-assembler-not %[re]bp
FAIL: gcc.tar
gcc.target/i386/pr100704-[12].c currently FAIL on 64-bit Solaris/x86:
FAIL: gcc.target/i386/pr100704-1.c scan-assembler-not pushq
FAIL: gcc.target/i386/pr100704-2.c scan-assembler-not pushq
Fixed by compiling with -fomit-frame-pointer.
Tested on i386-pc-solaris2.11 and x86_64-pc-linux-gnu.
Ok f
PING^1
On 10/19/21 08:49, Martin Liška wrote:
On 10/18/21 12:08, Richard Biener wrote:
Can you please use a subdirectory for the sources, a "toplevel"
license.txt doesn't make much sense. You can simply amend
vect.exp to process tsvc/*.c as well as sources so no need for an
extra .exp file.
gcc.target/i386/pr101346.c currently FAILs on Solaris/x86:
FAIL: gcc.target/i386/pr101346.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr101346.c:6:1:
error: decimal floating-point not supported for this target
/vol/gcc/src/hg/master/local/
On 10/22/21 23:00, Thomas Schwinge wrote:
|Turns out, there is another issue, observed in combination with a few "BadYear" occurrences
due to "improper" copyright lines (Bill, for your information). OK to push "Fix
'contrib/update-copyright.py':|
Thank you for the fix, it seems to me obvious
28_regex/basic_regex/84110.cc currently FAILs on Solaris:
FAIL: 28_regex/basic_regex/84110.cc (test for excess errors)
UNRESOLVED: 28_regex/basic_regex/84110.cc compilation failed to produce
executable
Excess errors:
/vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/28_regex/basic_regex/84110.
Hi,
This fixes the alignment on the memory access type for neon loads &
stores in the gimple lowering. Bootstrap ubsan on aarch64 builds again
with this change.
2021-10-25 Andre Vieira
gcc/ChangeLog:
* config/aarch64/aarch64-builtins.c
(aarch64_general_gimple_fold_builtin): Fix
17_intro/names.cc and experimental/names.cc currently FAIL on Solaris
FAIL: 17_intro/names.cc (test for excess errors)
FAIL: experimental/names.cc (test for excess errors)
Excess errors:
/usr/include/sys/timespec_util.h:22: error: expected ')' before ';' token
/usr/include/stdlib.h:157: error: ex
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, October 25, 2021 10:54 AM
> To: Tamar Christina
> Cc: Tamar Christina via Gcc-patches ; Richard
> Earnshaw ; nd ; Marcus
> Shawcroft
> Subject: Re: [PATCH 2/2]AArch64: Add better costing for vector constants
> and operations
"Roger Sayle" writes:
> This patch adds compile-time evaluation of signed saturating left shift
> (SS_ASHIFT) and unsigned saturating left shift (US_ASHIFT) to simplify-rtx's
> simplify_const_binary_operation. US_ASHIFT saturates to the maximum
> unsigned value on overflow (which occurs when the
On Mon, Oct 25, 2021 at 6:42 AM Jeff Law wrote:
>
>
>
> On 10/24/2021 8:15 PM, Jeff Law wrote:
> >
> >
> > On 10/18/2021 2:17 AM, Aldy Hernandez wrote:
> >>
> >>
> >> On 10/18/21 12:52 AM, Jeff Law wrote:
> >>>
> >>>
> >>> On 10/8/2021 9:12 AM, Aldy Hernandez via Gcc-patches wrote:
> The foll
Previous refactoring made the possibility of considering re-aligned
loads for unlimited cost model alignment peeling difficult so I
ditched that. Later refactoring made it easily possible again so
the following patch re-instantiates this which should fix the
observed regression on powerpc with alt
On Thu, Oct 21, 2021 at 5:42 PM Segher Boessenkool
wrote:
>
> On Thu, Oct 21, 2021 at 02:42:10PM +0200, Richard Biener wrote:
> > +#define rs6000_casm static_cast (casm)
> >
> > maybe there's a better way? Though I can't think of one at the moment.
> > There are only 10 uses so eventually we can
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Saturday, October 23, 2021 11:40 AM
>> To: Tamar Christina via Gcc-patches
>> Cc: Tamar Christina ; Richard Earnshaw
>> ; nd ; Marcus Shawcroft
>>
>> Subject: Re: [PATCH 2/2]AArch64: Add better costing for
On Fri, 22 Oct 2021, Prathamesh Kulkarni wrote:
> On Fri, 22 Oct 2021 at 14:56, Richard Biener wrote:
> >
> > On Fri, 22 Oct 2021, Prathamesh Kulkarni wrote:
> >
> > > On Wed, 20 Oct 2021 at 18:21, Richard Biener wrote:
> > > >
> > > > On Wed, 20 Oct 2021, Prathamesh Kulkarni wrote:
> > > >
> >
Hi Matt,
> On 23 Oct 2021, at 09:46, Iain Sandoe via Gcc-patches
> wrote:
>
>> On 20 Oct 2021, at 04:51, Matt Jacobson via Gcc-patches
>> wrote:
>>
>>
>>> On Sep 26, 2021, at 11:45 PM, Matt Jacobson wrote:
>>>
>>> Fix protocol list layout for non-LP64. clang and objc4 both give the
>>>
On Mon, 25 Oct 2021 00:30:16 +0200
Bernhard Reutner-Fischer wrote:
> Hi!
>
> Quickly skimming through the frontend headers.
> There are a couple of declarations for functions that do not have
> definitions. And there are a couple of functions that can be static.
> Bootstraps fine, regression te
As we discussed in the last RISC-V GNU sync up, I've committed this
patch-set to trunk after rebase and running regression with latest
binutils.
On Mon, Oct 18, 2021 at 11:23 AM Kito Cheng wrote:
>
> Hi Vineet:
>
> I am not familiar with buildroot, so I am not sure which GCC version will
> work,
On Mon, Oct 25, 2021 at 1:59 PM liuhongt wrote:
>
> Canoicalize & and nop_convert order for
> __atomic_fetch_or_*, __atomic_fetch_xor_*,
> __atomic_xor_fetch_*,__sync_fetch_and_or_*,
> __sync_fetch_and_xor_*,__sync_xor_and_fetch_*,
> __atomic_fetch_and_*,__sync_fetch_and_and_* when mask is constan
On Mon, Oct 25, 2021 at 10:26 AM Hongtao Liu wrote:
>
> On Mon, Oct 25, 2021 at 1:59 PM liuhongt wrote:
> >
> > Similar for sqrt/sqrtl.
> >
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
> Ok for trunk?
OK.
> > gcc/ChangeLog:
> >
> > PR target/102464
> > * match.
On Sun, Oct 24, 2021 at 11:28 AM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> Just like PR 100382, here we have a DCE removing a
> null pointer load which is needed still.
> In this case, execute_fixup_cfg removes a store (correctly)
> and then removes the null load (incorrectly)
This fixes a latent issue exposed by now allowing VN_TOP in PHI
arguments. We may only use optimistic equality when merging values on
different edges, not when merging values on the same edge - in particular
we may not choose the undef value on any edge when there's a not undef
value as well.
Boo
On Mon, Oct 25, 2021 at 1:59 PM liuhongt wrote:
>
> Similar for sqrt/sqrtl.
>
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
Ok for trunk?
> gcc/ChangeLog:
>
> PR target/102464
> * match.pd: Simplify (_Float16) sqrtf((float) a) to .SQRT(a)
> when direct_inter
On Sun, 24 Oct 2021, Jan-Benedict Glaw wrote:
> Hi Richard,
>
> On Sun, 2021-10-24 08:36:36 +0200, Richard Biener wrote:
> > On October 23, 2021 10:00:05 PM GMT+02:00, Jan-Benedict Glaw
> > wrote:
> > >On Tue, 2021-09-21 16:25:19 +0200, Richard Biener via Gcc-patches
> > > wrote:
> > >> I hav
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/102464
* config/i386/i386-builtin-types.def (V8HF_FTYPE_V8HF): New
function type.
(V16HF_FTYPE_V16HF): Ditto.
(V32HF_FTYPE_V32HF): Ditto.
(V8HF_FTYP
On Sun, Oct 24, 2021 at 6:34 PM Roger Sayle wrote:
>
>
> This patch provides RTL expanders to implement logical shifts and
> rotates of 128-bit values (stored in vector integer registers) by
> constant bit counts. Previously, GCC would transfer these values
> to a pair of scalar registers (TImode
1 - 100 of 103 matches
Mail list logo
