On Fri, 4 Nov 2022 at 05:36, Hongyu Wang via Gcc-patches
wrote:
>
> Hi,
>
> This is a follow-up patch for PR98167
>
> The sequence
> c1 = VEC_PERM_EXPR (a, a, mask)
> c2 = VEC_PERM_EXPR (b, b, mask)
> c3 = c1 op c2
> can be optimized to
> c = a op b
> c3 = VEC_PERM_EXPR (c
Signed overflow is an undefined behavior, so we need to prevent it from
happening, instead of "checking" the result.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_emit_int_compare):
Avoid signed overflow.
---
Bootstrapped and regtested on loongarch64-linux-gnu. OK fo
On Fri, 2022-11-04 at 13:29 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2022-10-21 at 22:15 +, Joseph Myers wrote:
>
> > * config/loongarch/loongarch.cc
> > (loongarch_setup_incoming_varargs): Likewise.
>
> Hi,
>
> One test fails on loongarch64-linux-gnu:
>
> FAIL: gcc
On Fri, 2022-10-21 at 22:15 +, Joseph Myers wrote:
> * config/loongarch/loongarch.cc
> (loongarch_setup_incoming_varargs): Likewise.
Hi,
One test fails on loongarch64-linux-gnu:
FAIL: gcc.dg/c2x-stdarg-4.c execution test
I've not got time to debug the issue yet.
--
Xi Ruo
在 2022/11/4 上午10:56, Xi Ruoyao 写道:
On Fri, 2022-11-04 at 10:33 +0800, Lulu Cheng wrote:
在 2022/11/4 上午10:22, Xi Ruoyao 写道:
On Tue, 2022-11-01 at 20:04 +0800, Lulu Cheng wrote:
gcc/ChangeLog:
* config/loongarch/constraints.md (x): New constraint.
* config/loongarch/loonga
On Fri, 2022-11-04 at 10:33 +0800, Lulu Cheng wrote:
>
> 在 2022/11/4 上午10:22, Xi Ruoyao 写道:
> > On Tue, 2022-11-01 at 20:04 +0800, Lulu Cheng wrote:
> > > gcc/ChangeLog:
> > >
> > > * config/loongarch/constraints.md (x): New constraint.
> > > * config/loongarch/loongarch.cc (str
在 2022/11/4 上午10:22, Xi Ruoyao 写道:
On Tue, 2022-11-01 at 20:04 +0800, Lulu Cheng wrote:
gcc/ChangeLog:
* config/loongarch/constraints.md (x): New constraint.
* config/loongarch/loongarch.cc (struct loongarch_address_info):
Adds a method to load the immediate 32 to 6
On Tue, 2022-11-01 at 20:04 +0800, Lulu Cheng wrote:
> gcc/ChangeLog:
>
> * config/loongarch/constraints.md (x): New constraint.
> * config/loongarch/loongarch.cc (struct loongarch_address_info):
> Adds a method to load the immediate 32 to 64 bit field.
> (struct lo
I would like to see some benchmark results instead of just a simple
case, to make sure everything is alright, the add pattern is used
literally anywhere, my most worry is the clobber might bring some
negative impact like cause register pressure estimation get higher,
and then result worse code gen.
This is the identical patch with
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604814.html, but with
the correct plaintext format.
>The loop still seems a bit odd which may point to further improvements
>that could be made to this patch. Consider this fragment of the loop:
Thank yo
Hi,
This is a follow-up patch for PR98167
The sequence
c1 = VEC_PERM_EXPR (a, a, mask)
c2 = VEC_PERM_EXPR (b, b, mask)
c3 = c1 op c2
can be optimized to
c = a op b
c3 = VEC_PERM_EXPR (c, c, mask)
for all integer vector operation, and float operation with
full permutation.
On Thu, 2022-11-03 at 15:59 -0400, Jason Merrill via Gcc-patches wrote:
> Tested x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> The c++-contracts branch uses this to retrieve the source form of the
> contract predicate, to be returned by contract_violation::comment().
>
> gcc/ChangeLog:
>
On 11/3/22 14:47, Bernhard Reutner-Fischer via Gcc-patches wrote:
Ok for trunk if testing passes?
gcc/ChangeLog:
* cgraph.cc (cgraph_node::make_local): Remove redundant set_section.
* multiple_target.cc (create_dispatcher_calls): Likewise.
OK after testing passes.
jeff
Hi!
I encounter a problem/pilot error when using the target_clones
attribute.
The symptom is that the default clone is not renamed in the output and
thus conflicts with the (proper) global name which is used for the
ifunc:
$ nl -ba < /tmp/cc3jBX3x.s | grep sub1
12 .type __m_MOD_su
On 11/2/22 18:26, Palmer Dabbelt wrote:
I also tried to remove that restriction but it looks like it can't
work because we can't create
pseudo-registers during shrink wrapping and shrink wrapping can't
work either.
I believe this means that shrink wrapping cannot interfere with a long
stac
Am 03.11.22 um 11:06 schrieb Mikael Morin:
Le 02/11/2022 à 22:19, Harald Anlauf via Fortran a écrit :
Am 02.11.22 um 18:20 schrieb Mikael Morin:
Unfortunately no, the coarray case works, but the other problem remains.
The type problem is not visible in the definition of S, it is in the
declarat
It looks like there was some memory leak in the handling
of attribute target_clones, introduced in 5928bc2ec06d .
Ok for trunk if testing passes?
gcc/ChangeLog:
* multiple_target.cc (expand_target_clones): Free memory.
Signed-off-by: Bernhard Reutner-Fischer
---
gcc/multiple_target.cc
Ok for trunk if testing passes?
gcc/ChangeLog:
* cgraph.cc (cgraph_node::make_local): Remove redundant set_section.
* multiple_target.cc (create_dispatcher_calls): Likewise.
Signed-off-by: Bernhard Reutner-Fischer
---
gcc/cgraph.cc | 1 -
gcc/multiple_target.cc | 1 -
On Fri, Oct 28, 2022 at 10:28:21AM +0200, Richard Biener wrote:
> Yes, the idea was also to free up memory but then that part never
> really materialized - the idea was to always run free-lang-data, not
> just when later outputting LTO bytecode. The reason is probably
> mainly the diagnostic regre
Tested x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The c++-contracts branch uses this to retrieve the source form of the
contract predicate, to be returned by contract_violation::comment().
gcc/ChangeLog:
* input.cc (get_source_text_between): New fn.
* input.h (get_source_text_b
Tested x86_64-pc-linux-gnu. OK for trunk?
-- >8 --
This patch adds the library support for the experimental C++ Contracts
implementation. This now consists only of a default definition of the
violation handler, which users can override through defining their own
version. To avoid ABI stability
Turning ranger on by default for the VRP1 pass fixed 3 outstanding PRs:
93917, 66, and 102650. Adding testcases for those PRs.
Andrew
From 863f50c84be7302ba14ce650838e3fd475b0cd56 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Thu, 3 Nov 2022 13:07:33 -0400
Subject: [PATCH] Add testc
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
It was always weird that -fconcepts in C++17 mode meant the same thing as
-fconcepts-ts in C++20 mode; this patch harmonizes the flags so that for TS
concepts you always need to write -fconcepts-ts.
In the unlikely event anyone is still usi
On 11/1/22 13:01, Marek Polacek wrote:
It seems wrong to issue a -Wignored-qualifiers warning for code like:
static_assert(!is_same_v);
because there the qualifier matters. Likewise in template
specialization:
template struct S { };
template<> struct S { };
template<> struct S { }
On Wed, Nov 2, 2022 at 7:12 PM Palmer Dabbelt wrote:
>
> On Wed, 02 Nov 2022 10:19:15 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> > Could you add some test cases?
>
> Also documentation, and ideally some sort of spec for what this should
> do so we can maintain compatibility with LLVM as well as
On Thu, Nov 03, 2022 at 02:54:12PM -0400, Jason Merrill wrote:
> On 11/1/22 18:06, Marek Polacek wrote:
> > -Wdangling-reference complains here:
> >
> >std::vector v = ...;
> >std::vector::const_iterator it = v.begin();
> >while (it != v.end()) {
> > const int &r = *it++; // warni
On 11/3/22 11:45, Patrick Palka wrote:
Like during satisfaction, we need to check access immediately during
substitution of a requires-expr since the outcome of an access check can
determine the value of the requires-expr. And otherwise, in contexts
where access checking is deferred (such as dur
On 11/1/22 18:06, Marek Polacek wrote:
-Wdangling-reference complains here:
std::vector v = ...;
std::vector::const_iterator it = v.begin();
while (it != v.end()) {
const int &r = *it++; // warning
}
because it sees a call to
__gnu_cxx::__normal_iterator >::operator*
which retu
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
It was always weird that -fconcepts in C++17 mode meant the same thing as
-fconcepts-ts in C++20 mode; this patch harmonizes the flags so that for TS
concepts you always need to write -fconcepts-ts.
In the unlikely event anyone is still usi
On 03/11/2022 17:47, Kwok Cheung Yeung wrote:
Hello
This patch fixes a bug introduced in a previous patch adding support for
generating native instructions for the exp2 and log2 patterns. The
problem is that the name of the instruction implementing the exp2
operation is v_exp (and not v_exp2)
gcc/analyzer/ChangeLog:
* analyzer.h: Use std::unique_ptr for state machines from plugins.
* engine.cc: Likewise.
gcc/testsuite/ChangeLog:
* gcc.dg/plugin/analyzer_gil_plugin.c: Use std::unique_ptr for
state machines from plugins.
Signed-off-by: David Malcolm
---
gcc/analyzer/ChangeLog:
* call-info.cc: Use std::unique_ptr for checker_event.
* checker-path.cc: Likewise.
* checker-path.h: Likewise.
* diagnostic-manager.cc: Likewise.
* engine.cc: Likewise.
* pending-diagnostic.cc: Likewise.
* sm-signal.cc
gcc/analyzer/ChangeLog:
* call-info.cc: Add define of INCLUDE_MEMORY.
* call-summary.cc: Likewise.
* checker-path.cc: Likewise.
* constraint-manager.cc: Likewise.
* diagnostic-manager.cc: Likewise.
(saved_diagnostic::saved_diagnostic): Use std::unique
gcc/analyzer/ChangeLog:
* analysis-plan.cc: Define INCLUDE_MEMORY before including
system.h.
* analyzer-pass.cc: Likewise.
* analyzer-selftests.cc: Likewise.
* analyzer.cc: Likewise.
* analyzer.h: Use std::unique_ptr in bifurcation code.
* cal
gcc/analyzer/ChangeLog:
* analyzer.h: Use std::unique_ptr for known functions.
* engine.cc: Likewise.
* known-function-manager.cc: Likewise.
* known-function-manager.h: Likewise.
gcc/testsuite/ChangeLog:
* gcc.dg/plugin/analyzer_kernel_plugin.c: Use std::uni
gcc/analyzer/ChangeLog:
* checker-path.cc (rewind_event::rewind_event): Update for usage of
std::unique_ptr on custom_edge_info.
* engine.cc (exploded_node::on_longjmp): Likewise.
(exploded_edge::exploded_edge): Likewise.
(exploded_edge::~exploded_edge): Dele
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (saved_diagnostic::saved_diagnostic): Make
stmt_finder const.
(saved_diagnostic::~saved_diagnostic): Remove explicit delete of
m_stmt_finder.
(diagnostic_manager::add_diagnostic): Make stmt_finder const.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc: Include "make-unique.h".
Use std::unique_ptr for feasibility_problems and exploded_path.
Delete explicit saved_diagnostic dtor.
* diagnostic-manager.h: Likewise.
* engine.cc: Likewise.
* exploded-graph.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-3629-g6341f14e369a5c through
r13-3636-ge177be86c7d327.
David Malcolm (8):
analyzer: use std::unique_ptr for pending_diagnostic/note
analyzer: use std::unique_ptr for saved_diagnostic::m_stmt_finder
analyzer
Hello
This patch fixes a bug introduced in a previous patch adding support for
generating native instructions for the exp2 and log2 patterns. The
problem is that the name of the instruction implementing the exp2
operation is v_exp (and not v_exp2), and similarly log2 is implemented
by v_log,
Whenever the IL changes under ranger, its possible the resulting range
calculation could be different. Once cached, we don't really recalculate
ranges unless we can detect an input range has caused the result to go
stale.
Simplification and folding can both change the IL in such a way that the
On Wed, 2 Nov 2022 at 13:42, Patrick Palka via Libstdc++
wrote:
>
> IIUC such variables should be declared inline to avoid potential ODR
> violations since they're otherwise considered to be distinct (internal
> linkage) entities across TUs.
>
> The changes inside the regex_constants and execution
On 11/3/22 08:33, Patrick Palka wrote:
We're rejecting the below testcase with
error: 'virtual constexpr Base::~Base()' used before its definition
error: 'virtual constexpr Derived::~Derived()' used before its definition
due to an early exit added to mark_used by r181272 to defer synthesi
Like during satisfaction, we need to check access immediately during
substitution of a requires-expr since the outcome of an access check can
determine the value of the requires-expr. And otherwise, in contexts
where access checking is deferred (such as during substitution into a
base-clause), a f
On 2022-11-03 15:17, Nathan Sidwell wrote:
On 10/28/22 05:15, Torbjörn SVENSSON wrote:
On Windows, the ':' character is special and when the module name is
a single character, like 'A', then the flatname would be (for
example) 'A:Foo'. On Windows, 'A:Foo' is treated as an absolute
path by the
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-3626-g5acc10a9ea6641.
gcc/analyzer/ChangeLog:
PR analyzer/107486
* analyzer.cc (is_pipe_call_p): New.
* analyzer.h (is_pipe_call_p): New decl.
* region-model.cc (region_model::on_c
On 10/28/22 05:15, Torbjörn SVENSSON wrote:
On Windows, the ':' character is special and when the module name is
a single character, like 'A', then the flatname would be (for
example) 'A:Foo'. On Windows, 'A:Foo' is treated as an absolute
path by the module loader and is likely not found.
Withou
On 11/3/22 09:48, Torbjorn SVENSSON wrote:
Hello Nathan,
On 2022-11-03 14:13, Nathan Sidwell wrote:
On 11/3/22 05:37, Torbjörn SVENSSON wrote:
v1 -> v2:
Updated expression in bad-mapper-3.C
Ok for trunk?
---
Without the patch, the output for bad-mapper-3.C would be:
/src/gcc/gcc/testsuite/
Hello Nathan,
On 2022-11-03 14:13, Nathan Sidwell wrote:
On 11/3/22 05:37, Torbjörn SVENSSON wrote:
v1 -> v2:
Updated expression in bad-mapper-3.C
Ok for trunk?
---
Without the patch, the output for bad-mapper-3.C would be:
/src/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-3.C:2:1: error:
u
Hi,
With Tamar's patch
(https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604880.html)
enabling the vectorization of early-breaks, I'd like to allow bitfield
lowering in such loops, which requires the relaxation of allowing
multiple exits when doing so. In order to avoid a similar issu
On Thu, Nov 03, 2022 at 02:35:03PM +0100, Tobias Burnus wrote:
> On 03.11.22 13:44, Jakub Jelinek wrote:
> > [...]
> > Otherwise LGTM, assuming it actually works correctly.
> >
> > I don't remember support for non-contiguous copying to/from devices
> > being actually added, [...] And I think it is
[PATCH v3] c++: parser - Support for target address spaces in C++
First of all, it is great news that GCC is going to implement named
address spaces for C++.
I have some questions:
1. How is name-mangling going to work?
==
Clang supports address spaces in
On 03.11.22 13:44, Jakub Jelinek wrote:
[...]
Otherwise LGTM, assuming it actually works correctly.
I don't remember support for non-contiguous copying to/from devices
being actually added, [...] And I think it is not ok to copy bytes
that aren't requested to be copied.
I have now removed that
On 02/11/2022 16.45, Jeff Law wrote:
>
> On 11/2/22 06:35, Rasmus Villemoes wrote:
>> However, when I try to push the new master branch I get
>>
>> $ git push origin master
>> fatal: remote error: service not enabled: /git/gcc.git
>>
>> I do gcc patches sufficiently rare that I may have forgotten
The eliminate reg-reg move by inverting the condition of
a cmove #2 peephole2 converts the following sequence:
473: bx:DI=[r14:DI*0x8+r12:DI]
960: r15:DI=r8:DI
485: {flags:CCC=cmp(r15:DI+bx:DI,bx:DI);r15:DI=r15:DI+bx:DI;}
737: r15:DI={(geu(flags:CCC,0))?r15:DI:bx:DI}
to:
1110: {flags:CC
On 11/3/22 05:37, Torbjörn SVENSSON wrote:
v1 -> v2:
Updated expression in bad-mapper-3.C
Ok for trunk?
---
Without the patch, the output for bad-mapper-3.C would be:
/src/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-3.C:2:1: error: unknown
Compiled Module Interface: no such module
As this l
On Mon, Oct 31, 2022 at 03:46:25PM +0100, Tobias Burnus wrote:
> OpenMP/Fortran: 'target update' with strides + DT components
>
> OpenMP 5.0 permits to use arrays with strides and derived
> type components for the list items to the 'from'/'to' clauses
> of the 'target update' directive.
>
> gcc/f
Should we go ahead with this, i.e. push the change and wait for fallout?
I guess we're still early enough in the cycle for that. There are no
regressions anymore on s390, Power9, x86 and aarch64 (at least on the
farm machines I checked).
Regards
Robin
We're rejecting the below testcase with
error: 'virtual constexpr Base::~Base()' used before its definition
error: 'virtual constexpr Derived::~Derived()' used before its definition
due to an early exit added to mark_used by r181272 to defer synthesis of
virtual destructors until EOF where we
Hi Martin,
On Wed, 26 Oct 2022, Martin Liška wrote:
> +Note the enabled sanitizer options tend to increase a false-positive rate
> +of selected warnings, most notably @option{-Wmaybe-uninitialized}.
> +And thus we recommend to disable @option{-Werror}.
I've been sitting muling over this and here
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This is needed to support a move-only output iterator when the input
iterators are specializations of __normal_iterator.
libstdc++-v3/ChangeLog:
* include/bits/ranges_algobase.h (__detail::__copy_or_move):
Move output iterator.
Le 02/11/2022 à 22:19, Harald Anlauf via Fortran a écrit :
Am 02.11.22 um 18:20 schrieb Mikael Morin:
Unfortunately no, the coarray case works, but the other problem remains.
The type problem is not visible in the definition of S, it is in the
declaration of S's prototype in P.
S is defined a
When a list of dirnames is provided to genmultilib, its length is
expected to match the number of options. If this is not the case, the
build fails later for reasons not obviously related to this mistake.
This patch adds a sanity check to help diagnose such cases.
Tested by adding an option to t-
> -Original Message-
> From: Torbjorn SVENSSON
> Sent: Wednesday, November 2, 2022 6:19 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: PING^1 [PATCH] arm: Allow to override location of .gnu.sgstubs
> section
>
> Hi,
>
> Ping, https://gcc.gnu.org/pipermail/gcc-patches
v1 -> v2:
Updated expression in bad-mapper-3.C
Ok for trunk?
---
Without the patch, the output for bad-mapper-3.C would be:
/src/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-3.C:2:1: error: unknown
Compiled Module Interface: no such module
As this line is unexpected, the test case would fail.
> -Original Message-
> From: Gcc-patches bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Jeff Law via
> Gcc-patches
> Sent: Wednesday, November 2, 2022 10:33 PM
> To: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH 1/2]middle-end: Support early break/return auto-
> vectorization.
>
On Thu, Nov 3, 2022 at 2:53 PM Kong, Lingling wrote:
>
> > > > diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
> > > > index 7c6bfa6e..cd0282f1 100644
> > > > --- a/htdocs/gcc-13/changes.html
> > > > +++ b/htdocs/gcc-13/changes.html
> > > > @@ -230,6 +230,8 @@ a work-in-progre
On Thu, Nov 3, 2022 at 7:29 AM Haochen Jiang wrote:
>
> Hi all,
>
> I just revised the patch according to review. The changes comparing to
> previous version is mentioned below.
>
> Ok for trunk?
>
> BRs,
> Haochen
>
> gcc/ChangeLog:
>
> * common/config/i386/cpuinfo.h (get_available_featur
68 matches
Mail list logo
