Hi,
This patch is to replace the current hardcoded weight factor 50
for those statements in an inner loop relative to the loop being
vectorized with a specific parameter vect-inner-loop-weight-factor.
The motivation behind this change is: if targets want to have one
unique function to gather some
On Tue, May 18, 2021 at 5:32 AM Martin Liška wrote:
>
> On 5/18/21 12:07 PM, Iain Buclaw wrote:
> > Excerpts from Martin Liska's message of March 17, 2021 4:36 pm:
> >>
> >> gcc/d/ChangeLog:
> >>
> >> * d-builtins.cc (do_build_builtin_fn): Use startswith
> >> function instead of strncmp.
This patch updates the libgo configure script to the current source
repo. This just fixes a couple of line numbers. Bootstrapped and ran
Go testsuite on x86_64-pc-linux-gnu.
Ian
commit c922c6539e63a775ee29751320d678f0a0a33d07
Author: Ian Lance Taylor
Date: Tue May 18 18:09:27 2021 -0700
I've committed a trivial patch to libgo to update two compression test
cases to match the main sources: the file
libgo/go/compress/bzip2/testdata/Mark.Twain-Tom.Sawyer.txt.bz2 is
removed, and the file
libgo/go/compress/bzip2/testdata/Isaac.Newton-Opticks.txt.bz2 is
updated. No patch appended here
I've committed a trivial patch to use the correct Windows line endings
in the libgo test file
libgo/go/runtime/testdata/testwinsignal/main.go.
Ian
diff --git a/libgo/go/runtime/testdata/testwinsignal/main.go
b/libgo/go/runtime/testdata/testwinsignal/main.go
index 1e7c9475fd6..d8cd884ffac 100644
-
Just a note that this patch should not have been committed to the
libgo directory. As described in libgo/README.gcc, the libgo
directory is a mirror of a repository stored elsewhere. Changes
committed directly to the gcc repo will eventually be lost. Thanks.
I'll take care of handling this patc
Hello.
This patch adds support for TLS variables.
One thing to fix before we merge it is the libgccjit.map file which
contains LIBGCCJIT_ABI_16 instead of LIBGCCJIT_ABI_17.
LIBGCCJIT_ABI_16 was added in one of my other patches.
Thanks for the review.
From 6092e3d347972d331ed9ac6cae153168e98ecd0d Mo
The change to only look at the global binding for non-classes meant that
here, when dealing with decimal32 which is magically mangled like its first
non-static data member, we got a collision with the mangling for float.
Fixed by also looking up an existing binding for such magical classes.
Tested
Here we have a pack expansion of a template template parameter pack, of
which the pattern is a TEMPLATE_DECL, which strip_typedefs doesn't want to
see.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/100372
gcc/cp/ChangeLog:
* tree.c (strip_typedefs): Only look at the patt
Hi,
This patch updates TypeVisitor in types.cc to use startswith instead of
strncmp.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
* types.cc (TypeVisitor::visit (TypeEnum *)): Use startswith function
inst
It turned out that there are codebases that profusely use GNU attributes
on friend declarations, so we have to dial back our checking and allow
them. And for C++11 attributes let's just warn instead of giving
errors.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/100
Hi,
This patch updates prefixed_path in d-incpath.cc to use filename_ncmp
instead of strncmp.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
* d-incpath.cc (prefixed_path): Use filename_ncmp instead of strncmp.
---
[PATCH 2/2] Fix tests when running on power10, PR testsuite/100166
This patch updates the various tests in the testsuite to adjust the test
if power10 code generation is used.
Some tests would not generate the expected instructions because power10
provides new instructions that the compiler now g
Hi,
This reverts changes to the DMD front-end in commit
6ba3079dce89d9b63bf5dbd5e320ea2bf96f196b.
Changes were incorrectly committed directly to the GCC repo instead of
the master repository.
Committed to mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
* dmd/dinterpret.c (evaluateIfBuil
[PATCH 1/2] Deal with prefixed loads/stores in tests, PR testsuite/100166
This patch updates the various tests in the testsuite to treat plxv
and pstxv as being vector loads/stores. This shows up if you run the
testsuite with a compiler configured with the option: --with-cpu=power10.
I have boot
I decided to do a run on our prototype power10 hardware, comparing using
--with-cpu=power9 and --with-cpu=power10. I noticed several tests were failing
with power10 code generation.
Most of the tests were failing because the regex's did not include prefixed
loads and stores. These are fixed in t
[PATCH] Fix vec-splati-runnable.c test.
I noticed that the vec-splati-runnable.c did not have an abort after one
of the tests. If the test was run with optimization, the optimizer could
delete some of the tests and throw off the count.
I have bootstraped this on LE power9 and BE power8 systems.
[PATCH 2/2] Fix xxeval predicates.
In doing the patch to move the XX* built-in functions from altivec.md to
vsx.md, I noticed that the xxeval built-in function used the
altivec_register_operand predicate. Since it takes vsx registers, this
might force the register allocate to issue a move when it
[PATCH 1/2] Move xx* builtins to vsx.md.
I noticed that the xx built-in functions (xxspltiw, xxspltidp, xxsplti32dx,
xxeval, xxblend, and xxpermx) were all defined in altivec.md. However, since
the XX instructions can take both traditional floating point and Altivec
registers, these built-in func
[PATCH 0/2] Move xx* builtins to vsx.md.
I noticed that the xx built-in functions (xxspltiw, xxspltidp, xxsplti32dx,
xxeval, xxblend, and xxpermx) were all defined in altivec.md. However, since
the XX instructions can take both traditional floating point and Altivec
registers, these built-in func
[PATCH] Change rs6000_const_f32_to_i32 return type.
The function rs6000_const_f32_to_i32 called REAL_VALUE_TO_TARGET_SINGLE
with a long long type and returns it. This patch changes the type to long
which is the proper type for REAL_VALUE_TO_TARGET_SINGLE.
I have done bootstraps on little endian
[PATCH] Allow __ibm128 on older PowerPC systems.
On January 8th, 2018, I added code to ibm-ldouble.c to use the built-in
function __builtin_pack_ibm128 if long double is IEEE 128-bit and continue to
use __builtin_pack_longdouble if long double is IBM extended double. This code
was needed because
[PATCH] Fix long double tests when default long double is not IBM.
This patch adds 3 more selections to target-supports.exp to see if we can force
the compiler to use a particular long double format (IEEE 128-bit, IBM extended
double, 64-bit), and the library support will track the changes for the
On Tue, 18 May 2021, David Lamparter wrote:
> On Fri, May 07, 2021 at 06:09:35PM +0200, David Lamparter wrote:
> > The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
> > resulting in all information about the typedef's involvement getting
> > lost. This drops necessary informat
[PATCH 2/2] Add IEEE 128-bit fp conditional move on PowerPC.
This patch adds the support for power10 IEEE 128-bit floating point conditional
move and for automatically generating min/max.
In this patch, I simplified things compared to previous patches. Instead of
allowing any four of the modes t
[PATCH 1/2] Add IEEE 128-bit min/max support on PowerPC.
This patch adds the support for the IEEE 128-bit floating point C minimum and
maximum instructions. The next patch will add the support for using the
compare and set mask instruction to implement conditional moves.
This patch does not try
The following two patches are new versions of the patches I've submitted in the
past to add support for the power10 IEEE 128-bit XSMAXCQP, XSMINCQP, XSCMPEQQ,
XSCMPGTQ, and XSCMPGEQ instructions.
This time I'm not trying to share code with the DFmode/SFmode min, max, or
conditional move support.
On Tue, 18 May 2021, Martin Liška wrote:
> +@quotation
> +aix7.1, aix7.2, amdhsa, androideabi, aout, cygwin, darwin, darwin10, darwin7,
> +darwin8, darwin9, eabi, eabialtivec, eabisim, eabisimaltivec, elf, elf32,
> +elfbare, elfoabi, freebsd4, freebsd6, gnu, hpux, hpux10.1, hpux11.0,
> hpux11.3,
On Tue, 18 May 2021, Patrick Palka wrote:
> This implements the P0896 changes to reverse_view's member types
Whoops, s/reverse_view/reverse_iterator rather... consider this typo
fixed throughout.
> value_type, difference_type and reference in C++20 mode, which fixes
> problems taking the reverse
This implements the P0896 changes to reverse_view's member types
value_type, difference_type and reference in C++20 mode, which fixes
problems taking the reverse_iterator of an iterator with a non-integral
difference_type (such as iota_view).
Tested on x86_64-pc-linux-gnu, does this look OK for tr
This test was fixed by my second patch for PR93314, which distinguishes
between constant-expression and potentially-constant-evaluated contexts in a
way that my first patch did not.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/100205
PR c++/99314
gcc/testsuite/ChangeLog:
Here we were ignoring the template constructor because the implicit move
constructor had all perfect conversions. But CWG1402 says that an
implicitly deleted move constructor is ignored by overload resolution; we
implement that instead by preferring any other candidate in joust, to get
better diag
* gcc.target/i386/pieces-memcpy-10.c: New test.
* gcc.target/i386/pieces-memcpy-11.c: Likewise.
* gcc.target/i386/pieces-memcpy-12.c: Likewise.
* gcc.target/i386/pieces-memcpy-13.c: Likewise.
* gcc.target/i386/pieces-memcpy-14.c: Likewise.
* gcc.targe
Expect no stack realignment since we no longer realign stack when
copying data.
* gcc.target/i386/incoming-11.c: Expect no stack realignment.
---
gcc/testsuite/gcc.target/i386/incoming-11.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/i
When expanding a constant constructor, don't call expand_constructor if
it is more efficient to load the data from the memory via move by pieces.
gcc/
PR middle-end/90773
* expr.c (expand_expr_real_1): Don't call expand_constructor if
it is more efficient to load the data
We can use TImode/OImode/XImode integers for piecewise move and store.
1. Define MAX_MOVE_MAX to 64, which is the constant maximum number of
bytes that a single instruction can move quickly between memory and
registers or between two memory locations.
2. Define MOVE_MAX to MOVE_MAX_PIECES, which i
Also pass -mno-avx to sw-1.c for ia32 since copying data with YMM or ZMM
registers disables shrink-wrapping when the second argument is passed on
stack.
* gcc.target/i386/sw-1.c: Also pass -mno-avx for ia32.
---
gcc/testsuite/gcc.target/i386/sw-1.c | 1 +
1 file changed, 1 insertion(+)
d
Also pass -mno-avx to pr72839.c to avoid copying data with YMM or ZMM
registers.
* gcc.target/i386/cold-attribute-1.c: Also pass -mno-avx.
---
gcc/testsuite/gcc.target/i386/cold-attribute-1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386
PR middle-end/90773
* gcc.target/i386/pr90773-20.c: New test.
* gcc.target/i386/pr90773-21.c: Likewise.
* gcc.target/i386/pr90773-22.c: Likewise.
* gcc.target/i386/pr90773-23.c: Likewise.
---
gcc/testsuite/gcc.target/i386/pr90773-20.c | 13 +
gcc
1. Make ix86_expand_vector_init_duplicate global to duplicate QImode
value to TImode/OImode/XImode.
2. Make ix86_minimum_incoming_stack_boundary global and add an argument
to ignore stack_alignment_estimated.
3. Define SCRATCH_SSE_REG as a scratch register for ix86_gen_memset_value.
4. Add TARGET_R
Also pass -mno-avx to pr72839.c to avoid copying data with YMM or ZMM
registers.
* gcc.target/i386/pr72839.c: Also pass -mno-avx.
---
gcc/testsuite/gcc.target/i386/pr72839.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr72839.c
b/gcc/
Changes in the v4 patches:
1. Define x86 MAX_MOVE_MAX to 64, which is the constant maximum number
of bytes that a single instruction can move quickly between memory and
registers or between two memory locations.
2. Define x86 MOVE_MAX to MOVE_MAX_PIECES, which is the maximum number of
bytes we can
Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE to support
target instructions to duplicate QImode value to TImode/OImode/XImode
value for memmset.
PR middle-end/90773
* builtins.c (builtin_memset_read_str): Call
targetm.read_memset_value.
(builtin_memset_g
To avoid stack realignment, use SCRATCH_SSE_REG to copy data from one
memory location to another.
gcc/
* config/i386/i386-expand.c (ix86_expand_vector_move): Use
SCRATCH_SSE_REG to copy data from one memory location to
another.
gcc/testsuite/
* gcc.target/i386/eh
It is only defined for i386 and everyone uses the default:
#define MAX_BITSIZE_MODE_ANY_INT (64*BITS_PER_UNIT)
Whatever problems we had before, they have been fixed now.
* config/i386/i386-modes.def (MAX_BITSIZE_MODE_ANY_INT): Removed.
---
gcc/config/i386/i386-modes.def | 15 +++---
On 5/13/21 6:08 PM, Marek Polacek wrote:
[ Repost from GCC 11 stage 3. Rebased onto current trunk. ]
I was looking at the LCOV coverage report for the C++ FE and
found a bunch of unused functions that I think we can remove.
Obviously, I left alone various dump_* and debug_* routines.
I haven't
On Linux/x86_64,
46ca31d65092e5afcef292f807fcf14c5363280d is the first bad commit
commit 46ca31d65092e5afcef292f807fcf14c5363280d
Author: Uros Bizjak
Date: Tue May 18 17:25:54 2021 +0200
i386: Implement 4-byte vector support [PR100637]
caused
FAIL: gcc.dg/vect/pr71264.c -flto -ffat-lto-o
The generation of the new runtime check picked up the wrong attributes
in the case of CLASS array arguments. There is related new code in
gfc_conv_procedure_call which served as reference for the fix.
Regtested on x86_64-pc-linux-gnu.
OK for mainline / 11-branch?
Thanks,
Harald
Fortran: Fix e
On 5/18/2021 2:56 AM, Joern Rennecke wrote:
I find that when compiling some files, lra goes into an infinite loop
reloading constant
addresses. This patch allows them to just be recognized as matching addresses
immediately, which also saves a bit of space for a few other files.
Bootstrapped a
On 5/18/21 3:22 AM, Richard Biener wrote:
On Tue, May 18, 2021 at 1:23 AM Andrew MacLeod via Gcc-patches
wrote:
The code in PR 100512 triggers an interaction between ranger and the
propagation engine related to undefined values.
I put the detailed analysis in the PR, but it boils down to the e
On Tue, May 18, 2021 at 07:35:52PM +0200, Franz Sirl wrote:
> Am 2021-05-14 um 00:08 schrieb Marek Polacek via Gcc-patches:
> > On Wed, May 12, 2021 at 08:27:18PM -0400, Jason Merrill wrote:
> > > On 5/12/21 8:03 PM, Marek Polacek wrote:
> > > > diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
> > > >
Am 2021-05-14 um 00:08 schrieb Marek Polacek via Gcc-patches:
On Wed, May 12, 2021 at 08:27:18PM -0400, Jason Merrill wrote:
On 5/12/21 8:03 PM, Marek Polacek wrote:
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 89f874a32cc..2bcefb619aa 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -
On 5/18/21 11:30 AM, Segher Boessenkool wrote:
On Tue, May 18, 2021 at 09:09:07AM -0500, Bill Schmidt wrote:
Long ago we were forced to make some small ABI breaks to correct errors
in the implementation, and we added warning messages for the changes
from GCC 4.9 to GCC 5. Enough time has passed
PR analyzer/100615 reports a missing leak diagnostic.
The issue is that the code calls strsep which the analyzer doesn't
have special knowledge of, and so conservatively assumes that it
could free the pointer, so drops malloc state for it.
Properly "teaching" the analyzer about strsep would requir
On 5/18/21 3:22 AM, Richard Biener wrote:
On Tue, May 18, 2021 at 1:23 AM Andrew MacLeod via Gcc-patches
wrote:
The code in PR 100512 triggers an interaction between ranger and the
propagation engine related to undefined values.
I put the detailed analysis in the PR, but it boils down to the e
On Tue, May 18, 2021 at 09:09:07AM -0500, Bill Schmidt wrote:
> Long ago we were forced to make some small ABI breaks to correct errors
> in the implementation, and we added warning messages for the changes
> from GCC 4.9 to GCC 5. Enough time has passed that these are now just
> irritants, so let
Hi,
As subject, this patch adds tests to confirm that a *2 (write to high-half)
Neon instruction is generated from vcombine* of a narrowing intrinsic
sequence.
Ok for master?
Thanks,
Jonathan
---
gcc/testsuite/ChangeLog:
2021-05-14 Jonathan Wright
* gcc.target/aarch64/narrow_high_
Hi,
As subject, this patch splits the aarch64_qshrn_n
pattern into separate scalar and vector variants. It further splits the vector
pattern into big/little endian variants that model the zero-high-half
semantics of the underlying instruction - allowing for more combinations
with the write-to-high
On 5/17/21 11:49 AM, H.J. Lu via Gcc-patches wrote:
On Thu, May 13, 2021 at 9:15 AM Bernd Edlinger
wrote:
On 5/13/21 3:37 PM, H.J. Lu via Gcc-patches wrote:
Warn for excessive argument alignment in main instead of ICE.
gcc/
PR c/100575
* cfgexpand.c (expand_stack_alignment): A
Hi!
Is the attached "Add '__OPTIMIZE__' DejaGnu selector" OK to push after
testing?
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
>From f2228df26acc303635
Hi,
As subject, this patch uses UNSPEC_SQXTUN instead of UNSPEC_SQXTUN2
in the aarch64_sqxtun2 patterns. This allows for more more
aggressive combinations and ultimately better code generation - which will
be confirmed by a new set of tests in
gcc.target/aarch64/narrow_high_combine.c (patch 5/5 in
On Tue, May 18, 2021 at 12:31 AM Bernd Edlinger
wrote:
>
> On 5/17/21 3:15 PM, H.J. Lu via Gcc-patches wrote:
> > Changes in the v3 patches:
> >
> > 1. Split the TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE changes
> > into the generic part and the x86 part.
> >
> >
> > 1. Add TARGET_READ_
Hi,
As subject, this patch implements saturating right-shift and narrow high
Neon intrinsic RTL patterns using a vec_concat of a register_operand
and a VQSHRN_N unspec - instead of just a VQSHRN_N unspec. This
more relaxed pattern allows for more aggressive combinations and
ultimately better code
Hi,
As subject, this patch implements v[r]addhn2 and v[r]subhn2 Neon intrinsic
RTL patterns using a vec_concat of a register_operand and an ADDSUBHN
unspec - instead of just an ADDSUBHN2 unspec. This more relaxed pattern
allows for more aggressive combinations and ultimately better code
generation
Add infrastructure, logic and arithmetic support for 4-byte vectors.
These can be used with SSE2 targets, where movd instructions from/to
XMM registers are available. x86_64 ABI passes 4-byte vectors in
integer registers, so also add logic operations with integer registers.
2021-05-18 Uroš Bizja
On 5/18/2021 9:08 AM, Mike Frysinger wrote:
On 13 May 2021 09:24, Jeff Law wrote:
On 5/11/2021 10:28 PM, Mike Frysinger via Gcc-patches wrote:
Nothing in gcc or binutils or gdb or anything anywhere uses these.
config/
* acinclude.m4 (CYG_AC_PATH_SIM, CYG_AC_PATH_DEVO): Delete.
"DEV
Hongtao Liu via Gcc-patches writes:
> On Mon, May 17, 2021 at 5:56 PM Richard Sandiford
> wrote:
>> It looks like the rtx “used” flag is unused for INSNs, so we could
>> use that as a CALL_INSN flag that indicates a fake call. We could just
>> need to make:
>>
>> /* For all other RTXes cle
On 13 May 2021 09:24, Jeff Law wrote:
> On 5/11/2021 10:28 PM, Mike Frysinger via Gcc-patches wrote:
> > Nothing in gcc or binutils or gdb or anything anywhere uses these.
> >
> > config/
> >
> > * acinclude.m4 (CYG_AC_PATH_SIM, CYG_AC_PATH_DEVO): Delete.
>
> "DEVO", yea, that's old. I had a
Committed as r12-881-gcc193ac840d58ee0ffb57b14b542706cde3db0e7
I have done grepping and think that EXEC_OMP_DEPOBJ was the only one
missing.
(All ..._END_... are also missing but I think needed.)
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Regi
In the earlier commit r12-854 I forgot to also rewrite the other operator-
overload in terms of the split-out member function _M_distance_from.
Tested on x86_64-pc-linux-gnu, committed as obvious.
libstdc++-v3/ChangeLog:
PR libstdc++/100631
* include/std/ranges (elements_view::_S
On 18.05.21 15:57, Richard Biener wrote:
Doh. So -foffload=default -foffloat=nvptx-none=-latomic maybe?
We really need a good documentation for -foffload= and something like
-foffload=default would be good as well – I think we currently only have
'disabled' and an explicit list. (Documentation
Hi!
Long ago we were forced to make some small ABI breaks to correct errors
in the implementation, and we added warning messages for the changes
from GCC 4.9 to GCC 5. Enough time has passed that these are now just
irritants, so let's remove them. Also clean up associated macros using
rs6000_spe
Fix a mode mismatch.
2021-05-18 Uroš Bizjak
gcc/
* config/i386/sse.md (v4qiv4di2):
Fix a mode mismatch with operand 1.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Pushed to master, will be backported to other release branches.
Uros.
diff --git a/gcc/config/i386/s
On Tue, 18 May 2021, Thomas Schwinge wrote:
> Hi!
>
> On 2021-04-21T09:10:52-0600, Jeff Law via Gcc-patches
> wrote:
> > On 4/21/2021 6:56 AM, Richard Biener wrote:
> >> libatomic isn't built for amdgcn but reduction-16.c adds it
> >> via -foffload=-latomic when offloading for nvptx is enabled.
split_double_mode calls simplify_gen_subreg, which fails for the
high half of the paradoxical subreg. Return temporary register
instead of NULL RTX in this case.
I was not able to construct a testcase without warnings.
2021-05-18 Uroš Bizjak
gcc/
PR target/100626
* config/i386/i386-e
On 2021-05-18 14:58, Richard Biener wrote:
On Mon, 17 May 2021, Ian Lance Taylor wrote:
On Mon, May 17, 2021 at 1:17 AM Richard Biener via Gcc-patches
wrote:
>
> On Fri, May 14, 2021 at 11:19 AM guojiufu via Gcc-patches
> wrote:
> >
> > On 2021-05-14 15:39, guojiufu via Gcc-patches wrote:
> >
On Mon, May 17, 2021 at 5:56 PM Richard Sandiford
wrote:
>
> Hongtao Liu via Gcc-patches writes:
> > On Fri, May 14, 2021 at 10:27 AM Hongtao Liu wrote:
> >>
> >> On Thu, May 13, 2021 at 7:52 PM Richard Sandiford
> >> wrote:
> >> >
> >> > Jakub Jelinek writes:
> >> > > On Thu, May 13, 2021 at
Hi!
On 2021-04-21T09:10:52-0600, Jeff Law via Gcc-patches
wrote:
> On 4/21/2021 6:56 AM, Richard Biener wrote:
>> libatomic isn't built for amdgcn but reduction-16.c adds it
>> via -foffload=-latomic when offloading for nvptx is enabled.
(ACK for that problem.)
>> The following avoids linker e
On Tue, May 18, 2021 at 08:23:56AM -0400, Antoni Boucher via Gcc-patches wrote:
> Hello.
> This patch add support for sized integer types.
> Maybe it should check whether the size of a byte for the current
> platform is 8 bits and do other checks so that they're only available
> when it makes sense
I had forgotten to update the documentation.
This new patch contains it.
Le mardi 18 mai 2021 à 08:23 -0400, Antoni Boucher a écrit :
> Hello.
> This patch add support for sized integer types.
> Maybe it should check whether the size of a byte for the current
> platform is 8 bits and do other chec
On 5/18/21 12:07 PM, Iain Buclaw wrote:
Excerpts from Martin Liska's message of March 17, 2021 4:36 pm:
gcc/d/ChangeLog:
* d-builtins.cc (do_build_builtin_fn): Use startswith
function instead of strncmp.
* dmd/dinterpret.c (evaluateIfBuiltin): Likewise.
* dmd/dm
Hello.
This patch add support for sized integer types.
Maybe it should check whether the size of a byte for the current
platform is 8 bits and do other checks so that they're only available
when it makes sense.
What do you think?
Thanks.
From d194a03fe3f2e8164c39413b79da9c43e236cf37 Mon Sep 17 00:0
On 5/18/21 1:55 PM, Bernd Edlinger wrote:
> On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote:
>> libstdc++-v3/ChangeLog:
>>
>> * include/std/thread (jthread::_S_create): Fix static assert
>> message.
>> * testsuite/30_threads/jthread/95989.cc: Re-enable test.
>> * tests
On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote:
> libstdc++-v3/ChangeLog:
>
> * include/std/thread (jthread::_S_create): Fix static assert
> message.
> * testsuite/30_threads/jthread/95989.cc: Re-enable test.
> * testsuite/30_threads/jthread/jthread.cc: Do not re
On Tue, May 18, 2021 at 1:26 PM Richard Earnshaw via Gcc-patches
wrote:
>
>
>
> On 17/05/2021 21:52, Hans-Peter Nilsson wrote:
> > On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
> >>
> >> Normally we expect the gimple optimizers to fold away comparisons that
> >> are always true, but
Hi!
On 2019-11-27T18:54:45+0100, I wrote:
> On 2019-11-14T18:22:39+0100, Jakub Jelinek wrote:
>> On Thu, Nov 14, 2019 at 05:18:41PM +, Andrew Stubbs wrote:
>>> On 14/11/2019 17:05, Jakub Jelinek wrote:
>>> > On Thu, Nov 14, 2019 at 04:47:49PM +, Andrew Stubbs wrote:
>>> > > This patch [..
On 5/18/21 1:00 PM, Segher Boessenkool wrote:> On Tue, May 18, 2021 at
08:36:34AM +0200, Bernd Edlinger wrote:
>> On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
>>> Bootstrap and regtest pass on ppc64le. Is this ok for trunk?
>
>> I've tried this patch and it does not seem to pass its own
On Fri, May 07, 2021 at 06:09:35PM +0200, David Lamparter wrote:
> The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
> resulting in all information about the typedef's involvement getting
> lost. This drops necessary information for warnings and can make them
> confusing or eve
On 2021/5/17 10:26 PM, Julian Brown wrote:
OK, understood. But, I'm a bit concerned that we're ignoring some
"hidden rules" with regards to OMP pointer clause ordering/grouping that
certain code (at least the bit that creates GOMP_MAP_STRUCT node
groups, and parts of omp-low.c) relies on. I belie
Hi!
On 2021-05-07T12:05:11+0200, Tobias Burnus wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c-c++-common/reduction-5.c
> @@ -0,0 +1,193 @@
> +/* { dg-additional-options "-foffload=-latomic" { target {
> offload_target_nvptx } } } */
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.
"Andre Vieira (lists)" writes:
> Hi,
>
> Using aarch64_pred_mov for these was tricky as it did both store and
> load. Furthermore there was some concern it might allow for a predicated
> mov to end up as a mem -> mem and a predicated load being wrongfully
> reloaded to a full-load to register.
On 2021-05-18 18:32, guojiufu wrote:
On 2021-05-18 17:28, guojiufu via Gcc-patches wrote:
On 2021-05-18 14:36, Bernd Edlinger wrote:
On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
When there is the possibility that overflow/wrap may happen on the
loop index,
a few optimizations would no
Hi!
On 2021-05-03T19:03:24+0200, Tom de Vries wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c/target-44.c
> @@ -0,0 +1,27 @@
> +/* { dg-additional-options "-foffload=-latomic" { target {
> offload_target_nvptx } } } */
Causes issues if more than nvptx offloading compilation is enable
Richard Biener writes:
> On Tue, 18 May 2021, Richard Biener wrote:
>
>> On Tue, 18 May 2021, Richard Sandiford wrote:
>>
>> > Richard Biener writes:
>> > > @@ -6621,9 +6637,31 @@ pass_expand::execute (function *fun)
>> > > (int) param_ssp_buffer_size);
>> > > }
>> > >
>
On Tue, May 18, 2021 at 08:36:34AM +0200, Bernd Edlinger wrote:
> On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
> > Bootstrap and regtest pass on ppc64le. Is this ok for trunk?
> I've tried this patch and it does not seem to pass its own test:
>
> FAIL: gcc.dg/loop-split1.c scan-tree-dump
On Tue, 18 May 2021, Richard Earnshaw wrote:
> On 17/05/2021 21:52, Hans-Peter Nilsson wrote:
> > On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
> > >
> > > Normally we expect the gimple optimizers to fold away comparisons that
> > > are always true, but at some lower optimization lev
On Tue, 18 May 2021, Richard Biener wrote:
> On Tue, 18 May 2021, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > @@ -6621,9 +6637,31 @@ pass_expand::execute (function *fun)
> > >(int) param_ssp_buffer_size);
> > > }
> > >
> > > + /* Temporarily mark PARM_DECLs an
Hi!
On Tue, May 18, 2021 at 07:43:49PM +0930, Alan Modra wrote:
> On Mon, May 10, 2021 at 04:39:55PM -0500, Segher Boessenkool wrote:
> > Huh, did it not already do that?! Hrm, all the other hooks seem to be
> > called via rs6000.c currently. But you do the same, so why do you need
> > to includ
Hi!
On 2020-11-30T12:28:31-0700, Jeff Law via Gcc-patches
wrote:
> On 11/24/20 2:53 AM, Thomas Schwinge wrote:
>> On 2020-11-06T10:26:46+0100, I wrote:
>>> On 2018-09-25T16:00:14-0400, David Malcolm wrote:
As noted at Cauldron, dumpfile.c currently emits "note: " for all kinds
of dump
Hi,
Using aarch64_pred_mov for these was tricky as it did both store and
load. Furthermore there was some concern it might allow for a predicated
mov to end up as a mem -> mem and a predicated load being wrongfully
reloaded to a full-load to register. So instead we decided to let the
extendin
1 - 100 of 138 matches
Mail list logo
