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
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
> -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.
>
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: 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
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-
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
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.
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
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
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
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
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
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 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
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
[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 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
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
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
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/
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
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 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
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 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
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
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
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,
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
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.
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:
* 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:
* 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:
* 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:
* 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:
* 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:
* 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
---
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)
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 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
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 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 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 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 { }
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
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. 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
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
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
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 -
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
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
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
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/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
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:
>
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.
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
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.
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
在 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 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: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-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
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
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, 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
68 matches
Mail list logo
