On Mon, 26 Apr 2021, Richard Sandiford wrote:
> Qing Zhao writes:
> >>> @@ -1831,6 +2000,17 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq
> >>> *seq_p)
> >>> as they may contain a label address. */
> >>> walk_tree (&init, force_labels_r, NULL, NULL);
> >>> }
> >>> + /* W
From: LevyHsu
Added implementation for builtin overflow detection, new patterns are listed
below.
---
Addition:
signed addition (SImode with RV32 || DImode with RV64):
add t0, t1, t2
sltit3, t2, 0
slt
Bootstrapped and regtested on s390x-redhat-linux. Tested with valgrind
on top of 52a5515ed (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100278). Ok for master?
gen_fprx2_to_tf() and gen_tf_to_fprx2() cannot handle hard registers,
since the subregs they create do not pass validation. Chan
On Mon, Apr 26, 2021 at 8:35 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Sat, Apr 24, 2021 at 3:43 PM Cui, Lili wrote:
> >
> > Hi Uros,
> >
> > This patch is to synchronize Rocket Lake's processor_names and
> > processor_cost_table with processor_type.
> >
> > Bootstrap is ok, and no regressio
Add an overlap_op_by_pieces_p target hook for op_by_pieces operations
between two areas of memory to generate one offset adjusted operation
in the smallest integer mode for the remaining bytes on the last piece
operation of a memory region to avoid doing more than one smaller
operations.
Pass the
Change a while loop in op_by_pieces_d::run to a do-while loop to prepare
for offset adjusted operation for the remaining bytes on the last piece
operation of a memory region.
PR middl-end/90773
* expr.c (op_by_pieces_d::get_usable_mode): New member function.
(op_by_pieces_d
Add an overlap_op_by_pieces_p target hook for op_by_pieces operations
between two areas of memory to generate one offset adjusted operation
in the smallest integer mode for the remaining bytes on the last piece
operation of a memory region to avoid doing more than one smaller
operations.
Pass the
On Mon, Apr 26, 2021 at 01:45:30PM +0200, Richard Biener wrote:
> On Mon, Apr 26, 2021 at 12:21 AM H.J. Lu wrote:
> >
> > On Fri, Apr 23, 2021 at 09:12:10AM +0200, Richard Biener wrote:
> > > On Fri, Apr 23, 2021 at 1:35 AM H.J. Lu via Gcc-patches
> > > wrote:
> > > >
> > > > For op_by_pieces ope
PR 90904 notes that auto_vec is unsafe to copy and assign because
the class manages its own memory but doesn't define (or delete)
either special function. Since I first ran into the problem,
auto_vec has grown a move ctor and move assignment from
a dynamically-allocated vec but still no copy ctor
The VLA bounds that are included by the C front end to attribute
access added to functions with VLA parameters to help detect
redeclaratations of function with "mismatched" VLA bounds are
cleared by the free_lang_data pass before the IL reaches the middle
end. The clearing was done to fix pr97172
> At least sizetype is for GIMPLE compatible with size_t or unsigned long (or
> whatever unsigned type has the same precision), so this looks wrong to me.
It's for bitsizetype here, as it's a conversion from bits into bytes, so
larger than DWARF2_ADDR_SIZE.
> For non-strict DWARF or DWARF5 and a
On Mon, Apr 26, 2021 at 2:32 PM Joseph Myers wrote:
>
> On Mon, 26 Apr 2021, Nick Clifton via Gcc-patches wrote:
>
> > Hi Guys,
> >
> > Given that gcc, gdb and now binutils are all now requiring C99 as a
> > minimum version of C, are there any objections to updating
> > configure.ac to refle
Hi all,
as discussed below/in this thread, the reset of the diagnostic
contest affects the output with ENABLE_OFFLOAD. The attached
patch now uses [Ww]arning in dg-bogus.
It might be possible to reduce the differences between
ENABLE_OFFLOAD being true or false, but it does not seem to
be simple
On 26.04.21 21:54, Thomas Schwinge wrote:
On 2021-04-26T14:32:10+0200, Tobias Burnus wrote:
first, can you add an entry regarding this flag
to https://gcc.gnu.org/gcc-12/changes.html ?
Is that a standard thing that all new command-line flags do get
highlighted there? (I wouldn't have consider
On Mon, 2021-04-26 at 14:00 -0500, acsaw...@linux.ibm.com wrote:
> From: Aaron Sawdey
>
> This adds some test cases to make sure that the combine patterns for p10
> fusion are working.
>
> OK for trunk?
>
> gcc/testsuite/ChangeLog:
> * gcc.target/powerpc/fusion-p10-ldcmpi.c: New file.
>
Leave it to gmail to mess things up. My apologies for the
inconvenience. Patch below.
Met vriendelijke groet,
Michael de Lang
diff --git a/gcc/testsuite/g++.dg/tsan/a.out b/gcc/testsuite/g++.dg/tsan/a.out
new file mode 100755
index 000..bce6d34f8d3
Binary files /dev/null and b/gcc/testsui
On Mon, 2021-04-26 at 13:04 -0500, acsaw...@linux.ibm.com wrote:
> From: Aaron Sawdey
>
> This adds new values for insn attr type for p10 fusion. The
> genfusion.pl
> script is modified to use them, and fusion.md regenerated to capture
> the new patterns. There are also some formatting only chang
From: Aaron Sawdey
This patch modifies the function in genfusion.pl for generating
the logical-logical patterns so that it can also generate the
add-logical and logical-add patterns which are very similar.
gcc/ChangeLog:
* config/rs6000/genfusion.pl (gen_logical_addsubf): Refactor to
On 4/26/21 3:57 PM, Aldy Hernandez wrote:
The -fstrict-enums comment in the VR_ANTI_RANGE handling code is out
of date, as out-of-range ranges have already been handled by this
time. I've removed it.
Furthermore, optimizing ~[MIN,MAX] as VARYING instead of UNDEFINED is
an old idiom. I've been
From: Aaron Sawdey
This patch adds a function to genfusion.pl to add a couple
more patterns so combine can do fusion of pairs of add and
vaddudm instructions.
gcc/ChangeLog:
* gcc/config/rs6000/genfusion.pl (gen_addadd): New function.
* gcc/config/rs6000/fusion.md: Regenerate fi
Similar to the previous commit, this fixes various problems with the
socket options classes in the header:
- The constructors were not noexcept.
- The __sockopt_base::value() member function was present
unconditionally (so was defined for socket_base::linger which is
incorrect).
- The __sock
From: Aaron Sawdey
Two more sets of combine patterns for p10 fusion. These require
the "Add insn types for fusion pairs" patch I posted earlier today.
If ok I would like to put these in gcc 12 trunk and backport for 11.2.
Thanks,
Aaron
Aaron Sawdey (2):
combine patterns for add-add fusio
This fixes some flaws in the socket option types defined in
net::socket_base:
- The constructors were not noexcept.
- The __sockopt_base::value() member function was present
unconditionally (so was defined for socket_base::linger which is
incorrect).
- The __socket_crtp::operator=(T) assignmen
On 23/04/21 13:58 +0100, Jonathan Wakely wrote:
libstdc++-v3/ChangeLog:
* include/experimental/socket (socket_base::shutdown_type):
(socket_base::wait_type, socket_base::message_flags):
Remove enumerators. Initialize constants directly with desired
values.
pthread_cond_clockwait wasn't added to TSAN_INTERCEPTORS which leads to
false positives regarding double locking of a mutex. This was uncovered by
a user reporting an issue to the google sanitizer github:
https://github.com/google/sanitizers/issues/1259
This patch copies code from the fix made in
On 26 Apr 2021 19:32, Joseph Myers wrote:
> On Mon, 26 Apr 2021, Nick Clifton via Gcc-patches wrote:
> > Given that gcc, gdb and now binutils are all now requiring C99 as a
> > minimum version of C, are there any objections to updating
> > configure.ac to reflect this ?
>
> This isn't an obj
> On Apr 26, 2021, at 12:47 PM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
@@ -1831,6 +2000,17 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
as they may contain a label address. */
walk_tree (&init, force_labels_r, NULL, NULL);
}
On 26.04.21 14:32, Tobias Burnus wrote:
Secondly, I now see FAILs like:
FAIL: gfortran.dg/goacc/classify-serial.f95 -O (test for excess errors)
[...]
Now fixed myself to reduce the clutter.
Committed as r12-130-g5a26ba75de623f75fb44cddc2a9c982d31c96213
Tobias
-
Mentor Gra
The -fstrict-enums comment in the VR_ANTI_RANGE handling code is out
of date, as out-of-range ranges have already been handled by this
time. I've removed it.
Furthermore, optimizing ~[MIN,MAX] as VARYING instead of UNDEFINED is
an old idiom. I've been wanting to change it for a while, but have
o
Hi!
On 2021-04-26T14:32:10+0200, Tobias Burnus wrote:
> first, can you add an entry regarding this flag
> to https://gcc.gnu.org/gcc-12/changes.html ?
Is that a standard thing that all new command-line flags do get
highlighted there? (I wouldn't have considered that one important
enough?)
> S
On Mon, 26 Apr 2021, Nick Clifton via Gcc-patches wrote:
> Hi Guys,
>
> Given that gcc, gdb and now binutils are all now requiring C99 as a
> minimum version of C, are there any objections to updating
> configure.ac to reflect this ?
This isn't an objection, since upgrading auto* for the t
On 4/26/21 11:04 AM, will schmidt wrote:
On Sun, 2021-04-25 at 20:50 -0500, Bill Schmidt via Gcc-patches wrote:
2021-03-25 Bill Schmidt
gcc/testsuite/
* gcc.target/powerpc/rop-1.c: New.
* gcc.target/powerpc/rop-2.c: New.
* gcc.target/powerpc/rop-3.c: New.
* gc
On Mon, 26 Apr 2021, Jason Merrill wrote:
> On 4/26/21 12:17 PM, Patrick Palka wrote:
> > During constexpr evaluation, a base-to-derived conversion may yield an
> > expression like (Derived*)(&D.2217.D.2106 p+ -4) where D.2217 is the
> > derived object and D.2106 is the base. But cxx_fold_indirec
On Mon, 26 Apr 2021, Tobias Burnus wrote:
> Comments? Wording suggestions? I think for OpenMP, the sentence will be
> modified several times before the release :-)
Can I take this as a promise? :-)
+
+ For Fortran, OpenMP 5.0 support has been extended for following features
+ which were be
From: Aaron Sawdey
This adds some test cases to make sure that the combine patterns for p10
fusion are working.
OK for trunk?
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/fusion-p10-ldcmpi.c: New file.
* gcc.target/powerpc/fusion-p10-2logical.c: New file.
---
.../gcc.target/po
On Linux/x86_64,
22cff118f7526bec195ed6e41452980820fdf3a8 is the first bad commit
commit 22cff118f7526bec195ed6e41452980820fdf3a8
Author: Thomas Schwinge
Date: Fri Apr 23 12:23:51 2021 +0200
Add '-Wopenacc-parallelism'
caused
FAIL: gfortran.dg/goacc/classify-serial.f95 -O (test for ex
From: Aaron Sawdey
This adds new values for insn attr type for p10 fusion. The genfusion.pl
script is modified to use them, and fusion.md regenerated to capture
the new patterns. There are also some formatting only changes to
fusion.md that apparently weren't captured after a previous commit
of g
Qing Zhao writes:
>>> @@ -1831,6 +2000,17 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
>>>as they may contain a label address. */
>>> walk_tree (&init, force_labels_r, NULL, NULL);
>>> }
>>> + /* When there is no explicit initializer, if the user requested,
Hi Joseph,
On 4/26/21 7:19 PM, Joseph Myers wrote:
On Sat, 24 Apr 2021, Alejandro Colomar via Libc-alpha wrote:
Some pages also document attributes, using GNU syntax
'__attribute__((xxx))'. Update those to use the shorter and more
portable C2x syntax, which hasn't been standardized yet, but i
On Sat, 24 Apr 2021, Alejandro Colomar via Libc-alpha wrote:
> Some pages also document attributes, using GNU syntax
> '__attribute__((xxx))'. Update those to use the shorter and more
> portable C2x syntax, which hasn't been standardized yet, but is
> already implemented in GCC, and available thr
With the opening of stage 1, It seems like an appropriate time to talk
about our vision for Ranger in GCC 12.
First, we have a queued up a list of
improvements/fixes/adjustments/performance to the existing code which
we'll check in first. We'll cover each of those in the patches as we
submit
On Mon, Apr 26, 2021 at 06:49:22PM +0200, Eric Botcazou wrote:
> the compiler can synthesize DWARF functions to describe the location and size
> of components in discriminated record types with variant part in Ada, but in
> peculiar cases the compiler drops expressions on the floor, for example in
Hi,
the compiler can synthesize DWARF functions to describe the location and size
of components in discriminated record types with variant part in Ada, but a
limitation is that most quantities must have DWARF2_ADDR_SIZE or else be the
result of a zero-extension to DWARF2_ADDR_SIZE of a smaller qua
Hi,
the compiler can synthesize DWARF functions to describe the location and size
of components in discriminated record types with variant part in Ada, but in
peculiar cases the compiler drops expressions on the floor, for example in
the divide case:
case ROUND_DIV_EXPR:
case TRUNC_DIV_
On 4/26/21 12:17 PM, Patrick Palka wrote:
During constexpr evaluation, a base-to-derived conversion may yield an
expression like (Derived*)(&D.2217.D.2106 p+ -4) where D.2217 is the
derived object and D.2106 is the base. But cxx_fold_indirect_ref
doesn't know how to resolve an INDIRECT_REF there
On 4/26/21 9:29 AM, Patrick Palka wrote:
On Fri, 23 Apr 2021, Jason Merrill wrote:
On 4/22/21 9:46 AM, Patrick Palka wrote:
On Wed, 21 Apr 2021, Patrick Palka wrote:
On Wed, 21 Apr 2021, Jason Merrill wrote:
On 4/12/21 1:20 PM, Patrick Palka wrote:
Here we're crashing during deduction for
Will, Segher:
This patch adds support for converting to/from 128-bit integers and
128-bit decimal floating point formats using the new P10 instructions
dcffixqq and dctfixqq. The new instructions are only used on P10 HW,
otherwise the conversions continue to use the existing SW routines.
The fil
Will, Segher:
The previous patch added the vector 128-bit integer shift instruction
support for the V1TI type. This patch renames and moves the VSX_TI
iterator from vsx.md to VEC_TI in vector.md. The uses of VEC_TI are
also updated.
The patch has been tested on
powerpc64-linux instead (Powe
Will, Segher:
This patch adds the 128-bit integer support for divide, modulo, shift,
compare of 128-bit integers instructions and builtin support.
The patch has been tested on
powerpc64-linux instead (Power 8 BE)
powerpc64-linux instead (Power 9 LE)
powerpc64-linux instead (Power 10 L
Will, Segher:
This patch adds support for converting to/from 128-bit integers and
128-bit decimal floating point formats.
The patch has been tested on
powerpc64-linux instead (Power 8 BE)
powerpc64-linux instead (Power 9 LE)
powerpc64-linux instead (Power 10 LE)
Please let me know if
Will, Segher:
This patch fixes the order of the argument in the vec_rlmi and
vec_rlnm builtins. The patch also adds a new test cases to verify
the fix.
The patch has been tested on
powerpc64-linux instead (Power 8 BE)
powerpc64-linux instead (Power 9 LE)
powerpc64-linux instead (Powe
Segher, Will:
Bill asked that I refresh thes 128-bit integer patch set and get it
reposted. I have rebased the patches onto the latest mainline
respository. I have also retested the patches on Power 8 BE, Power 9
LE and Power 10 LE hardware.
A request has been made last week to change the funct
On 4/26/21 11:01 AM, will schmidt wrote:
On Sun, 2021-04-25 at 20:50 -0500, Bill Schmidt via Gcc-patches wrote:
Add POWER10 support for hashst[p] and hashchk[p] operations. When
the -mrop-protect option is selected, any function that loads the
link
register from memory before returning must hav
On 4/26/21 5:03 PM, Andrew MacLeod wrote:
On 4/26/21 10:16 AM, Aldy Hernandez wrote:
Currently multi-ranges calculate the undefined and varying bits on the
fly, whereas legacy uses the m_kind field. Since we will always have
space in the irange class for a kind field, might as well keep it i
On Mon, Apr 26, 2021 at 11:50 AM Jonathan Wakely wrote:
>
> On 26/04/21 09:17 -0400, David Edelsohn via Libstdc++ wrote:
> >On Mon, Apr 26, 2021 at 7:19 AM Jonathan Wakely wrote:
> >>
> >> On 23/04/21 20:54 -0400, David Edelsohn via Libstdc++ wrote:
> >> >Some ports require libatomic for atomic o
When substituting into the arguments of a base initializer pack
expansion, tsubst_initializer_list uses a dummy EXPR_PACK_EXPANSION
in order to expand an initializer such as Bases(args)... into
Bases#{0}(args#{0}) and so on. But when an argument inside the base
initializer is itself an pack expans
During constexpr evaluation, a base-to-derived conversion may yield an
expression like (Derived*)(&D.2217.D.2106 p+ -4) where D.2217 is the
derived object and D.2106 is the base. But cxx_fold_indirect_ref
doesn't know how to resolve an INDIRECT_REF thereof to just D.2217,
because it doesn't handle
Hi all,
this patch documents a new OpenMP feature (many more to be added) in GCC 12.
And it documents a new flag for OpenACC.
Comments? Wording suggestions? I think for OpenMP, the sentence will be
modified several times before the release :-)
Tobias
-
Mentor Graphics (Deutschl
On Sun, 2021-04-25 at 20:50 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-25 Bill Schmidt
>
> gcc/testsuite/
> * gcc.target/powerpc/rop-1.c: New.
> * gcc.target/powerpc/rop-2.c: New.
> * gcc.target/powerpc/rop-3.c: New.
> * gcc.target/powerpc/rop-4.c: New.
>
On Sun, 2021-04-25 at 20:50 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-25 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Define
> __ROP_PROTECT__ if -mrop-protect is selected.
ok
> ---
> gcc/config/rs6000/rs6000-c.c | 3 +++
> 1 file
On Sun, 2021-04-25 at 20:50 -0500, Bill Schmidt via Gcc-patches wrote:
> Insert the hashst and hashchk instructions when -mrop-protect has been
> selected. The encrypted save slot for ROP mitigation is placed
> between the parameter save area and the alloca space (if any;
> otherwise the local var
On Sun, 2021-04-25 at 20:50 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-25 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000.c (rs6000_option_override_internal):
> Disable shrink wrap when inserting ROP-protect instructions.
> * config/rs6000/rs6000.opt (mrop-protect): N
On Sun, 2021-04-25 at 20:50 -0500, Bill Schmidt via Gcc-patches wrote:
> Add POWER10 support for hashst[p] and hashchk[p] operations. When
> the -mrop-protect option is selected, any function that loads the
> link
> register from memory before returning must have protection in the
> prologue and e
Hi,
We met the following linking error when building our important application:
> …./ld: .o(.text.startup+0x13): unresolvable R_X86_64_TPOFF32 relocation
> against symbol `__gcov_indirect_call’
Looks like that current “__gcov_indirect_call”’s TLS_MODEL is local exec.
If recompiling .
On 26/04/21 09:17 -0400, David Edelsohn via Libstdc++ wrote:
On Mon, Apr 26, 2021 at 7:19 AM Jonathan Wakely wrote:
On 23/04/21 20:54 -0400, David Edelsohn via Libstdc++ wrote:
>Some ports require libatomic for atomic operations, at least for some
>data types and widths. The libstdc++ testsui
On 4/8/2021 3:24 AM, Martin Jambor wrote:
Hi,
When IPA-SRA removes an SSA_NAME from a LHS of a call statement
because it is not necessary, it does not release it. This patch fixes
that.
Bootstrapped and tested on x86_64, at some point I'll LTO-bootstrap it
too. I assume this is GCC 12 mater
On 4/14/2021 3:43 PM, David Edelsohn via Gcc-patches wrote:
AIX uses a compiler-managed TOC for global data, including TLS symbols.
The GCC TOC implementation manages the TOC entries through the
constant pool.
TLS symbols sometimes require a function call to obtain the TLS base
On 4/21/2021 2:14 AM, Martin Liška wrote:
Hey.
It's quite common case that a build system does not a -flto=foo option
as part of linker command. We should merge -flto options from the corresponding
object files.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to
On 4/26/21 10:16 AM, Aldy Hernandez wrote:
This does for num_pairs() what my previous patch did for VR_UNDEFINED
and VR_VARYING.
Note that VR_ANTI_RANGE for legacy is always set to 2 ranges. There
is only one way of representing a range, so a range that can be
represented as a VR_RANGE will nev
Hi, Richard,
Thanks a lot for your review.
> On Apr 23, 2021, at 2:05 PM, Richard Sandiford
> wrote:
>
> Finally getting to this now that the GCC 11 rush is over. Sorry for
> the slow response.
>
> I've tried to review most of the code below, but skipped the testsuite
> parts in the interest
On 4/26/21 10:16 AM, Aldy Hernandez wrote:
Currently multi-ranges calculate the undefined and varying bits on the
fly, whereas legacy uses the m_kind field. Since we will always have
space in the irange class for a kind field, might as well keep it in
sync as ranges are created, thus speeding up
This patch is a good and simple improvement which could be an independent patch.
There is only 1 comment from me for this patch, could you also add @
to cbranch pattern for floating mode, I would prefer make the
gen_cbranch4 could handle floating mode for consistency.
So feel free to commit this
Right now we have GTY support for static storage iranges
(int_range<>). However, there's no reason why the base
class can't be used with GC, other than it was an oversight.
For that matter, the base class has a pointer to the sub-range
storage, so we can use the same implementation for both. Thi
This does for num_pairs() what my previous patch did for VR_UNDEFINED
and VR_VARYING.
Note that VR_ANTI_RANGE for legacy is always set to 2 ranges. There
is only one way of representing a range, so a range that can be
represented as a VR_RANGE will never have a kind of VR_ANTI_RANGE.
Also legacy
Currently multi-ranges calculate the undefined and varying bits on the
fly, whereas legacy uses the m_kind field. Since we will always have
space in the irange class for a kind field, might as well keep it in
sync as ranges are created, thus speeding up lookups.
This patch, along with an upcoming
As of a few releases ago, varying_p() ranges are also constant_p.
Consequently, there is no need to check varying_p from either
symbolic_p or constant_p.
I have adjusted a few users of constant_p that were depending on
constant_p returning false for varying_p. In these cases, I have
placed the va
A few of the undefined_p checks in the irange code are really checking if
there are sub-ranges. It just so happens that undefined_p is
implemented with num_ranges > 0, so it was a shorthand used throughout.
This shorthand was making the code unreadable.
gcc/ChangeLog:
* value-range.cc (i
On Fri, 23 Apr 2021, Jason Merrill wrote:
> On 4/22/21 9:46 AM, Patrick Palka wrote:
> > On Wed, 21 Apr 2021, Patrick Palka wrote:
> >
> > > On Wed, 21 Apr 2021, Jason Merrill wrote:
> > >
> > > > On 4/12/21 1:20 PM, Patrick Palka wrote:
> > > > > Here we're crashing during deduction for a templ
On Mon, Apr 26, 2021 at 7:19 AM Jonathan Wakely wrote:
>
> On 23/04/21 20:54 -0400, David Edelsohn via Libstdc++ wrote:
> >Some ports require libatomic for atomic operations, at least for some
> >data types and widths. The libstdc++ testsuite previously was updated
> >to link against libatomic, b
The existing CAS implementation uses an INSN definition, which provides
the core LR/SC sequence. Additionally to that, there is a follow-up code,
that evaluates the results and calculates the return values.
This has two drawbacks: a) an extension to sub-word CAS implementations
is not possible (eve
On RISC-V we are facing the fact, that our conditional branches
require Pmode conditions. Currently, we generate them explicitly
with a check for Pmode and then calling the proper generator
(i.e. gen_cbranchdi4 on RV64 and gen_cbranchsi4 on RV32).
Let's make simplify this code by using gen_cbranch4
The current model of the LR and SC INSNs requires a sign-extension
to use the generated SImode value for conditional branches, which
only operate on XLEN registers.
However, the sign-extension is actually not required in both cases,
therefore this patch introduces additional INSNs that consume
the
In order to emit LR/SC sequences, let's provide INSNs, which
take care of memory ordering constraints.
gcc/
PR 100266
* config/rsicv/sync.md (UNSPEC_LOAD_RESERVED): New.
* config/rsicv/sync.md (UNSPEC_STORE_CONDITIONAL): New.
* config/riscv/sync.md (riscv_load_r
A recent commit introduced a mechanism to emit proper fences
for RISC-V. Additionally, we already have emit_move_insn ().
Let's reuse this code and provide atomic_load and
atomic_store for RISC-V (as defined in section
"Code Porting and Mapping Guidelines" of the unpriv spec).
Note, that this works
mem_thread_fence gets the desired memory model as operand.
Let's emit fences according to this value (as defined in section
"Code Porting and Mapping Guidelines" of the unpriv spec).
gcc/
PR 100265
* config/riscv/sync.md (mem_thread_fence):
Emit fences according t
Using amoswap as atomic store is not an expected optimization
and most likely causes a performance penalty.
Neither SW nor HW have a benefit from this optimization,
so let's simply drop it.
gcc/
PR 100265
* config/riscv/sync.md (atomic_store):
Remove.
---
gcc/config/
A previous patch took care, that the proper memory ordering suffixes
for AMOs are emitted. Therefore there is no reason to keep the fence
generation mechanism for release operations.
gcc/
PR 100265
* config/riscv/riscv.c (riscv_memmodel_needs_release_fence):
Remove fu
We don't have any special treatment of MEMMODEL_SYNC_* values,
so let's hide them behind the memmodel_base() function.
gcc/
PR 100265
* config/riscv/riscv.c (riscv_memmodel_needs_amo_acquire):
Ignore MEMMODEL_SYNC_* values.
* config/riscv/riscv.c (riscv_memmod
The ratified A extension supports '.aq', '.rl' and '.aqrl' as
memory ordering suffixes. Let's emit them in case we get a '%A'
conversion specifier for riscv_print_operand().
As '%A' was already used for a similar, but restricted, purpose
(only '.aq' was emitted so far), this does not require any o
This series provides a cleanup of the current atomics implementation
of RISC-V:
* PR100265: Use proper fences for atomic load/store
* PR100266: Provide programmatic implementation of CAS
As both are very related, I merged the patches into one series
(to avoid merge issues if one overtake the othe
Hi Thomas,
first, can you add an entry regarding this flag
to https://gcc.gnu.org/gcc-12/changes.html ?
Secondly, I now see FAILs like:
FAIL: gfortran.dg/goacc/classify-serial.f95 -O (test for excess errors)
Excess errors:
gfortran.dg/goacc/classify-serial.f95:20:132: Warning: region contain
On Wed, Apr 7, 2021 at 6:43 PM Richard Biener wrote:
>
> When we apply store motion and DSE manually to the bwaves kernel
> in gfortran.dg/pr81303.f loop interchange no longer happens because
> the perfect nest considered covers outer loops we cannot analyze
> strides for. The following compensat
On Mon, Apr 26, 2021 at 12:21 AM H.J. Lu wrote:
>
> On Fri, Apr 23, 2021 at 09:12:10AM +0200, Richard Biener wrote:
> > On Fri, Apr 23, 2021 at 1:35 AM H.J. Lu via Gcc-patches
> > wrote:
> > >
> > > For op_by_pieces operations between two areas of memory on non-strict
> > > alignment target, add
[ree] PR rtl-optimization/100264: Handle more PARALLEL SET expressions
PR rtl-optimization/100264
* ree.c (get_sub_rtx): Ignore SET expressions without register
destinations.
(merge_def_and_ext): Eliminate destination check for register
as such SET expressio
libstdc++-v3/ChangeLog:
* include/bits/semaphore_base.h: Include and .
Tested x86_64-linux. Committed to trunk.
This should be backported to gcc-11 but it can wait until after the
11.1 release.
It affects non-linux targets which have POSIX semaphores. For linux
targets the header gets
Hi Guys,
Given that gcc, gdb and now binutils are all now requiring C99 as a
minimum version of C, are there any objections to updating
configure.ac to reflect this ?
Cheers
Nick
diff --git a/configure.ac b/configure.ac
index a721316d07b..59b4194fb24 100644
--- a/configure.ac
+++ b/conf
On Mon, 26 Apr 2021 at 10:55, Richard Sandiford
wrote:
>
> Christophe Lyon via Gcc-patches writes:
> > Some of the CMSE tests have 'dg-do run', but qemu-arm does not support
> > the privileged instructions involved; one has to use qemu-system-arm
> > for this, which in turn requires modifications
Hi all!
Proposed patch to:
PR92621 - Problems with memory handling with allocatable intent(out)
arrays with bind(c)
Patch tested only on x86_64-pc-linux-gnu.
The code currently generated tries to deallocate the undefined
artificial cfi.n pointer before it is associated with the allocatable
On 23/04/21 20:54 -0400, David Edelsohn via Libstdc++ wrote:
Some ports require libatomic for atomic operations, at least for some
data types and widths. The libstdc++ testsuite previously was updated
to link against libatomic, but the search path was hard-coded to
something that is not always c
On Sat, Apr 24, 2021 at 3:43 PM Cui, Lili wrote:
>
> Hi Uros,
>
> This patch is to synchronize Rocket Lake's processor_names and
> processor_cost_table with processor_type.
>
> Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
>
> OK for master?
>
> [PATCH] Synchronize Rocket Lake's
1 - 100 of 112 matches
Mail list logo
