On Fri, 23 Apr 2021, Jakub Jelinek wrote:
> On Tue, Feb 02, 2021 at 11:38:11AM -0700, Jeff Law via Gcc-patches wrote:
> > On 1/16/21 11:13 AM, Jakub Jelinek wrote:
> > > Hi!
> > >
> > > The following patch tests both x / y * y and x - x % y expansion for the
> > > former GIMPLE code and chooses th
On Fri, 23 Apr 2021, Jakub Jelinek wrote:
> On Tue, Feb 02, 2021 at 07:40:02PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > On Tue, Feb 02, 2021 at 11:39:30AM -0700, Jeff Law wrote:
> > > > This patch adds some ctz simplifications (e.g. ctz (x) >= 3 can be done
> > > > by
> > > > testing if th
Hi!
register keyword was removed in C++17, and in vmsdbgout.c it served no
useful purpose.
Tested with x86_64-linux -> ia64-hp-vms cross configured with
CXX='g++ -std=c++17', committed to trunk as obvious.
2021-04-26 Jakub Jelinek
PR debug/100255
* vmsdbgout.c (ASM_OUTPUT_DEB
On Wed, Apr 14, 2021 at 4:27 PM Richard Biener wrote:
>
> This removes update_call_from_tree in favor of
> gimplify_and_update_call_from_tree, removing some code duplication
> and simplifying the API use. Some users of update_call_from_tree
> have been transitioned to replace_call_with_value and
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 to the default
> newlib/libgloss startup code to enable the FPU a
This fixes the pre-condition on cselim to include all references
and decls when they end up as auto-var.
Bootstrapped/tested on x86_64-linux, pushed to trunk.
2021-03-09 Richard Biener
PR tree-optimization/99473
* tree-ssa-phiopt.c (cond_store_replacement): Handle all
On Fri, Apr 16, 2021 at 12:41 PM Richard Biener wrote:
>
> This moves the legacy gimplify_buildN API to tree-vect-generic.c,
> its only user and elides the gimplification step, making it a wrapper
> around gimple_build, adjusting tree_vec_extract for this.
>
> I've noticed that vector CTOR expansi
Hi,
As the PR shows, we currently miscompile V2DImode loads and stores for
MVE. We're currently using 64-bit loads/stores, but need to be using
128-bit vector loads and stores.
Some intrinsics tests were checking that we (incorrectly) used the
64-bit loads/stores: these have been updated.
Regres
Hi!
On 2016-02-09T07:14:31-0800, Cesar Philippidis wrote:
> This patch [...]
... as eventually commited in r234840 (commit
c42cfb5ca3b02756705485e013fa9107aaf28acd "re PR lto/70289 ([openacc] ICE
in input_varpool_node)") added 'dg-additional-options "-w"' for a bunch
of testcases. We'd like to
Hi!
On 2021-02-26T04:21:54-0800, Julian Brown wrote:
> This patch adds warnings for strange partitioning choices -- specifying
> either more or fewer partitioning levels on a parallel directive than the
> enclosed offload region actually uses.
Thanks!
> We've used a version of this patch on the
libstdc++-v3/ChangeLog:
PR libstdc++/100259
* include/experimental/internet (net::ip::make_error_code)
(net::ip::make_error_condition, net::ip::make_network_v4)
(net::ip::operator==(const udp&, const udp&)): Add 'inline'.
Tested x86_64-linux. Committed to trunk.
c
Hi all,
While playing with other unrelated changes I hit an assemble-failure bug where
a pattern (one of the get_lane ones) that was using V4BF, V8BF as part of a
mode iterator and outputting registers with the vwcore attribute,
but there is no vwcore mapping for V4BF and V8BF.
This patch fixes t
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
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
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 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 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
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
[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
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
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
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
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
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
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
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/
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
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
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
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
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 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 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
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
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
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
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
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
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 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
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
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:
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
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/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/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 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
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 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
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:
> 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.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:
> 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.
>
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
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
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
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
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 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
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
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
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 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:
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 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
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
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
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_
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
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
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 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
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
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,
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
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 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 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
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 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, 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
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
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
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
> 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 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
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 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.
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
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
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
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
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 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 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
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 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.
>
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
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
1 - 100 of 112 matches
Mail list logo
