On Sun, Mar 27, 2022 at 5:15 PM Uros Bizjak wrote:
> On Fri, Mar 25, 2022 at 3:08 AM MayShao wrote:
> >
> > Hi Uros,
> >
> > This patch fix Zhaoxin CPU Vendor ID detection problem
> > and add Zhaoxin "lujiazui" processor support and tuning.
> >
> > Currently gcc can't recognize Zhaoxin CPU (Vendo
Hi!
The recent change didn't initialize comp_step while previously we used
XCNEW to allocate it.
I think RS_ANY is better than RS_INTERNAL (== 0) as the default.
Bootstrappedd/regtested on x86_64-linux and i686-linux, ok for trunk?
2022-03-26 Jakub Jelinek
PR tree-optimization/10505
On Fri, Mar 25, 2022 at 07:48:33PM +0100, Jakub Jelinek wrote:
> We then wouldn't propagate TREE_DEPRECATED/TREE_UNAVAILABLE from templates
> to their instantiations and wouldn't diagnose static data members in OpenMP
> declare target.
> But perhaps that is fine, with error_mark_attribute it is err
On Sat, 26 Mar 2022, Jakub Jelinek wrote:
> Hi!
>
> The recent change didn't initialize comp_step while previously we used
> XCNEW to allocate it.
>
> I think RS_ANY is better than RS_INTERNAL (== 0) as the default.
>
> Bootstrappedd/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Pushed.
2022-03-28 Richard Biener
* gcc.dg/torture/pr100786.c: Add dg-require alias.
---
gcc/testsuite/gcc.dg/torture/pr100786.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/torture/pr100786.c
b/gcc/testsuite/gcc.dg/torture/pr100786.c
index 42f4e485593..
On Fri, Mar 25, 2022 at 06:45:41PM +0100, Andreas Krebbel wrote:
> gcc/ChangeLog:
> PR target/102024
> * config/s390/s390-protos.h (s390_function_arg_vector): Remove
> prototype.
> * config/s390/s390.cc (s390_single_field_struct_p): New function.
> (s390_function_arg_v
On Mon, Mar 28, 2022 at 6:55 AM liuhongt wrote:
>
> pinsrw is available for both reg and mem operand under sse2.
> pextrw requires sse4.1 for mem operands.
>
> The patch change attr "isa" for pinsrw mem alternative from sse4_noavx
> to noavx, will enable below optimization.
>
> -movzwl (%
On Fri, Mar 25, 2022 at 10:27 PM David Malcolm via Gcc-patches
wrote:
>
> PR analyzer/104308 reports that when -Wanalyzer-use-of-uninitialized-value
> complains about certain memmove operations where the source is
> uninitialized, the diagnostic uses UNKNOWN_LOCATION:
>
> In function 'main':
> cc1
On Mon, Mar 28, 2022 at 12:50 AM Jan Hubicka via Gcc-patches
wrote:
>
> Hi,
> as seen on TSVC, Spec2017, the Zen3 gather instruction is a win only for
> vectors with 8 elements. At the time I was implementing the tuning vectorizer
> did not know how to open-code gather and thus it was still a win
Hi,
When building an nvptx offloading configuration on openSUSE Leap 15.3, the
site script /usr/share/site/x86_64-unknown-linux-gnu is activated, setting
libexecdir to ${exec_prefix}/lib rather than ${exec_prefix}/libexec:
...
| # If user did not specify libexecdir, set the correct target:
| # Nor
On Mon, 28 Mar 2022, Tom de Vries wrote:
> Hi,
>
> When building an nvptx offloading configuration on openSUSE Leap 15.3, the
> site script /usr/share/site/x86_64-unknown-linux-gnu is activated, setting
> libexecdir to ${exec_prefix}/lib rather than ${exec_prefix}/libexec:
> ...
> | # If user did
On Wed, 23 Mar 2022, Richard Biener wrote:
> The following extends the heuristical memcpy folding path with the
> ability to use misaligned accesses on strict-alignment targets just
> like the size-based path does. That avoids regressing the following
> testcase on arm
>
> uint64_t bar64(con
The following makes sure to annotate the tests generated by
switch lowering bit-clustering with locations which otherwise
can be completely lost even at -O0.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed to trunk
sofar.
2022-03-28 Richard Biener
PR tree-optimization/1050
Hi Harald,
On 27.03.22 21:44, Harald Anlauf via Fortran wrote:
when assigning character pointers, we have a check for same length,
which however does not trigger for character pointers within a
structure constructor.
The attached patch extends the character checks slightly to fix
this loophole.
Make the parsing stricter so that we won't parse:
This reverts commit r12-1434-g046a3beb1673bf to fix PR target/104882.
Installed.
Martin
contrib/ChangeLog:
* gcc-changelog/git_commit.py: Make the parsing stricter.
---
contrib/gcc-changelog/git_commit.py | 4 ++--
1 file changed, 2 in
On Mär 28 2022, Martin Liška wrote:
> +revert_regex = re.compile(r'This reverts commit (?P[0-9a-f]+).$')
Is the trailing '.' supposed to match literally?
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something comp
On 3/28/22 12:38, Andreas Schwab wrote:
On Mär 28 2022, Martin Liška wrote:
+revert_regex = re.compile(r'This reverts commit (?P[0-9a-f]+).$')
Is the trailing '.' supposed to match literally?
Yes, pushed as a74ccc8cb02220ca45a1d0222ba5ba986abae570.
Thanks,
Martin
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/20_util/optional/monadic/and_then.cc: Fix typo.
* testsuite/20_util/optional/monadic/transform.cc: Likewise.
* testsuite/22_locale/codecvt/always_noconv/char/1.cc: Likewise.
* tests
On 3/28/22 10:49, Richard Biener wrote:
On Mon, 28 Mar 2022, Tom de Vries wrote:
Hi,
When building an nvptx offloading configuration on openSUSE Leap 15.3, the
site script /usr/share/site/x86_64-unknown-linux-gnu is activated, setting
libexecdir to ${exec_prefix}/lib rather than ${exec_prefix}
On Mär 28 2022, Richard Biener via Gcc-patches wrote:
> OK in principle, but I have no idea on how portable
>
> $(libexecdir:\$(exec_prefix)/%=%)
>
> is going to be?
We already require GNU make, don't we?
> We should aim for POSIX shell compatibility here, whatever that
> exactly is.
It's not a
On Mon, 28 Mar 2022, Andreas Schwab wrote:
> On Mär 28 2022, Richard Biener via Gcc-patches wrote:
>
> > OK in principle, but I have no idea on how portable
> >
> > $(libexecdir:\$(exec_prefix)/%=%)
> >
> > is going to be?
>
> We already require GNU make, don't we?
>
> > We should aim for POSIX
On 3/28/22 14:04, Richard Biener wrote:
On Mon, 28 Mar 2022, Andreas Schwab wrote:
On Mär 28 2022, Richard Biener via Gcc-patches wrote:
OK in principle, but I have no idea on how portable
$(libexecdir:\$(exec_prefix)/%=%)
is going to be?
We already require GNU make, don't we?
We should
Hi,
On Sun, Mar 27, 2022 at 06:25:16PM -0300, Alexandre Oliva via Gcc-patches wrote:
> Hello, Marek,
>
> The patch looks good to me, and I'd have no trouble approving it if we
> were in stage1. Since we aren't, I'd prefer if we waited for another
> build system maintainer to give it a look, if i
chenglulu writes:
> Hi, all:
>
> This is the v10 version of LoongArch Port based on
> d1ca63a1b7d5986913b14567a4950b055a5a3f07.
OK for trunk. Thanks for the updates.
Richard
> Please review.
>
> We know it is stage4, I think it is ok for a new prot.
> The kernel side upstream waiting for a a
Gentile ping for this :), thanks.
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590906.html
R30_REGNUM could also be used as a component in shrink-wrapping
separate, this patch enables it in aarch64.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_get_separate_comp
When doing format diagnostics at -O0 we should make sure to make
SCEV available to avoid false positives due to ranges we otherwise
can trivially compute.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
OK if that succeeds?
Thanks,
Richard.
2022-03-28 Richard Biener
PR tr
On Mon, Mar 28, 2022 at 03:16:24PM +0200, Richard Biener wrote:
> When doing format diagnostics at -O0 we should make sure to make
> SCEV available to avoid false positives due to ranges we otherwise
> can trivially compute.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> OK if
On Mon, 28 Mar 2022, Jakub Jelinek wrote:
> On Mon, Mar 28, 2022 at 03:16:24PM +0200, Richard Biener wrote:
> > When doing format diagnostics at -O0 we should make sure to make
> > SCEV available to avoid false positives due to ranges we otherwise
> > can trivially compute.
> >
> > Bootstrap and
We weren't rejecting a concept declared with multiple template
parameter lists.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
PR c++/105067
gcc/cp/ChangeLog:
* pt.cc (finish_concept_definition): Require that a concept is
declared with ex
Here during declaration matching for the two constrained template
friends, we crash from maybe_substitute_reqs_for because the second
friend doesn't yet have DECL_TEMPLATE_INFO set (we're being called
indirectly from push_template_decl).
As far as I can tell, this situation happens only when decla
On Mon, 28 Mar 2022, Richard Biener wrote:
> On Mon, 28 Mar 2022, Jakub Jelinek wrote:
>
> > On Mon, Mar 28, 2022 at 03:16:24PM +0200, Richard Biener wrote:
> > > When doing format diagnostics at -O0 we should make sure to make
> > > SCEV available to avoid false positives due to ranges we otherw
This was breaking because when we stripped the 't' typedef in s...>
to be s, the TYPE_MAIN_VARIANT of "Args..." was still
"t...", because type pack expansions are treated as types. Fixed by
using the right function to copy a "type".
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/9
My implementation of union non-type template arguments in r11-2016 broke
braced casts of union type, because they are still in syntactic (undigested)
form.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104847
gcc/cp/ChangeLog:
* mangle.cc (write_expression): Don't write
When make_base_init_ok changes a call to a complete constructor into a call
to a base constructor, we were never marking the base ctor as used, so it
didn't get emitted.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/102045
gcc/cp/ChangeLog:
* call.cc (make_base_init_ok):
More quirks of rewriting member references to dependent references for
CTAD. A reference to a member of dependent scope is definitely dependent.
And since r11-7044, tsubst_baselink builds a SCOPE_REF, so
tsubst_qualified_id should just use it.
Tested x86_64-pc-linux-gnu, applying to trunk.
Here, we were wrongly thinking that (const Options&)Widget::c_options is
not value-dependent because neither the type nor the (value of) c_options
are dependent, but since we're binding it to a reference we also need to
consider that it has a value-dependent address.
Tested x86_64-pc-linux-gnu, ap
When building a deduction guide from the Test constructor, we need to
rewrite the use of _dummy into a dependent reference, i.e. Test::template
_dummy. We were using SCOPE_REF for both type and non-type templates; we
need to use UNBOUND_CLASS_TEMPLATE for type templates.
Tested x86_64-pc-linux-gn
When setting up the hidden namespace-scope decl for a local extern, we also
need to set its visibility.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/103291
gcc/cp/ChangeLog:
* name-lookup.cc (push_local_extern_decl_alias): Call
determine_visibility.
gcc/testsui
This test ICEd after the constexpr new patch (r10-3661) because alloc_call
had a NOP_EXPR around it; fixed by moving the NOP_EXPR to alloc_expr. And
the PR pointed out that the size_t cookie might need more alignment, so I
fix that as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
Richard Biener writes:
> Since we're now vectorizing by default at -O2 issues like PR101908
> become more important where we apply basic-block vectorization to
> parts of the function covering loads from function parameters passed
> on the stack. Since we have no good idea how the stack pushing
>
On Mon, Mar 28, 2022 at 03:26:11PM +0200, Richard Biener wrote:
> On Mon, 28 Mar 2022, Jakub Jelinek wrote:
>
> > On Mon, Mar 28, 2022 at 03:16:24PM +0200, Richard Biener wrote:
> > > When doing format diagnostics at -O0 we should make sure to make
> > > SCEV available to avoid false positives due
On 3/25/22 20:44, Jørgen Kvalsvik wrote:
Hello, and thanks for the review!
1) Do I correctly understand that __conditions_accu_true/false track
every short-circuit sub-expression of a condition and record
if a given sub-expr is seen to be true or false?
Sort-of. It is not really aware of sub-
On Sun, Mar 27, 2022 at 11:35 AM Uros Bizjak wrote:
>
> On Sun, Mar 27, 2022 at 8:14 PM H.J. Lu wrote:
> >
> > Since AVX512VL and AVX512BW are required for AVX512 VPSHUFB, replace the
> > "Yv" register constraint with the "Yw" register constraint.
>
> This is an obvious fix, as said in https://gc
On Mon, 28 Mar 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > Since we're now vectorizing by default at -O2 issues like PR101908
> > become more important where we apply basic-block vectorization to
> > parts of the function covering loads from function parameters passed
> > on the s
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-12.1-b20220213.sv.po'
Richard Biener writes:
> On Mon, 28 Mar 2022, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > Since we're now vectorizing by default at -O2 issues like PR101908
>> > become more important where we apply basic-block vectorization to
>> > parts of the function covering loads from function
Marc Poulhiès writes:
> On targets that do not have MXX/SSE enabled by default, pr97521
> and pr96713 fail because they emit warnings:
>
> pr97521.c:12:1: warning: MMX vector return without MMX enabled
> changes the ABI [-Wpsabi]
> pr97521.c:11:1: note: the ABI for passing paramet
Marc Poulhiès writes:
> Test must check for effective support of fpic.
>
> Tested on x86_64-pc-linux-gnu{-m32,}.
>
> ok for master?
ping?
For PR104008 we thought it might be enough to keep strip_typedefs from
removing this alias template specialization, but this PR demonstrates that
other parts of the compiler also need to know to consider it dependent.
So, this patch changes complex_alias_template_p to no longer consider
template p
"Andre Vieira (lists)" writes:
> Hi,
>
> Addressed all of your comments bar the pred ops one.
>
> Is this OK?
>
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.cc (aarch64_vector_costs): Define
> determine_suggested_unroll_factor and m_nosve_pattern.
> (determine_suggested_unrol
On 24/03/2022 13:03, Martin Liška wrote:
On 3/24/22 11:51, Sebastian Huber wrote:
Maybe we could add the file path into the gcov information stream
using a new tag:
#define GCOV_TAG_GCDA_FILE_NAME ((gcov_unsigned_t)0xa500)
Then the complete gcov information can be dumped using a single b
The following 4 patches fix PR target/99293. This bug complains that on power9
and power10:
vector long long v, v0, v1;
// ...
v0 = __builtin_vec_splats (__builtin_vec_extract (v, 0));
v1 = __builtin_vec_splats (__builtin_vec_extract (v, 1));
generates move from v
Optimize vec_splats of constant vec_extract for V2DI/V2DF, PR target 99293.
In PR target/99293, it was pointed out that doing:
vector long long dest0, dest1, src;
/* ... */
dest0 = vec_splats (vec_extract (src, 0));
dest1 = vec_splats (vec_extract (src, 1));
would
Make vsx_splat__reg use correct insn attributes, PR target/99293
In looking at PR target/99293, I noticed that the code in the insn
vsx_splat__reg used "vecmove" as the "type" insn attribute when the
"mtvsrdd" is generated. It should use "mfvsr". I also added a "p9v" isa
attribute for that alter
Make vsx_extract_ use correct insn attributes, PR target 99293.
In looking at PR target/99293, I noticed that the insn "type" attribute is
incorrect for the vsx_extract_ insns. In particular:
1) Simple vector register move should be vecmove (alternative 1);
2) Xxpermdi should be vecper
Allow vsx_extract_ to use Altivec registers, PR target/99293
In looking at PR target/99293, I noticed that the vsx_extract_
pattern for V2DImode and V2DFmode only allowed traditional floating point
registers, and it did not allow Altivec registers. The original code was
written a few years ago wh
PR target/105068
* config/i386/sse.md (*ssse3_pshufbv8qi3): Also replace "Yv" with
"Yw" in clobber.
---
gcc/config/i386/sse.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 01543afd111..1f9c496e7c0
Hi,
Currently we have:
...
$ gcc --target-help 2>&1 | egrep "misa|mptx"
-misa= Specify the version of the ptx ISA to use.
-mptx= Specify the version of the ptx version to use.
Known PTX ISA versions (for use with the -misa= option):
Known PTX versi
On Mon, Mar 28, 2022 at 12:26:02PM -0400, Michael Meissner wrote:
> However on power9 and power10 it generates:
>
> ;; vec_splats (vec_extract (src, 0))
> mfvsld 3,34
> mtvsrdd 34,9,9
>
> ;; vec_splats (vec_extract (src, 1))
> mfvsrd 9,34
> mtvsrdd 34,9,9
>
>
On 3/28/22 09:29, Patrick Palka wrote:
Here during declaration matching for the two constrained template
friends, we crash from maybe_substitute_reqs_for because the second
friend doesn't yet have DECL_TEMPLATE_INFO set (we're being called
indirectly from push_template_decl).
As far as I can tel
On 3/28/22 09:28, Patrick Palka wrote:
We weren't rejecting a concept declared with multiple template
parameter lists.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
PR c++/105067
gcc/cp/ChangeLog:
* pt.cc (finish_concept_definition): Re
Hi Tobias,
Am 28.03.22 um 12:05 schrieb Tobias Burnus:
Thanks for the patch! LGTM and I think GCC 12 is still okay.
However, I have a nit:
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -1375,11 +1375,22 @@ resolve_structure_cons (gfc_expr *expr, int init)
...
+ long l
Hi!
On Mon, Mar 28, 2022 at 12:27:05PM -0400, Michael Meissner wrote:
> In looking at PR target/99293, I noticed that the code in the insn
> vsx_splat__reg used "vecmove" as the "type" insn attribute when the
> "mtvsrdd" is generated. It should use "mfvsr". I also added a "p9v" isa
> attribute f
Hi Tobias,
sorry for replying to myself now, but
Am 28.03.22 um 22:03 schrieb Harald Anlauf via Fortran:
All current cases of printing a HOST_WIDE_INT in gcc/fortran/ use
'sprintf', and I did not find any other use of %wd/%wu. So the
mentioned implementation is not really stressed yet... ;-)
[Committed as obvious.]
A minor cosmetic fix.
2022-03-28 Indu Bhagat
gcc/ChangeLog:
* ctfout.cc (ctf_preprocess): Use ctfc_get_num_ctf_vars instead.
(output_ctf_vars): Likewise.
---
gcc/ctfout.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/ctf
On Mon, 28 Mar 2022, Harald Anlauf via Gcc-patches wrote:
> Hi Tobias,
>
> sorry for replying to myself now, but
>
> Am 28.03.22 um 22:03 schrieb Harald Anlauf via Fortran:
> > All current cases of printing a HOST_WIDE_INT in gcc/fortran/ use
> > 'sprintf', and I did not find any other use of %w
Hi!
On Mon, Mar 28, 2022 at 12:28:04PM -0400, Michael Meissner wrote:
> In looking at PR target/99293, I noticed that the insn "type" attribute is
> incorrect for the vsx_extract_ insns. In particular:
>
> 1)Simple vector register move should be vecmove (alternative 1);
> 2)
On Mon, Mar 28, 2022 at 12:14:09PM -0500, Segher Boessenkool wrote:
> On Mon, Mar 28, 2022 at 12:26:02PM -0400, Michael Meissner wrote:
> > However on power9 and power10 it generates:
> >
> > ;; vec_splats (vec_extract (src, 0))
> > mfvsld 3,34
> > mtvsrdd 34,9,9
> >
> > ;; vec_sp
Some ARM configurations, such as with -mlong-calls, load the call
target from the constant pool, breaking the expectation of the test as
on several other targets.
Tested on an affected target. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.dg/weak/typeof-2.c: Add arm*-*-* to targe
On Mon, Mar 28, 2022 at 06:30:41PM -0400, Michael Meissner wrote:
> On Mon, Mar 28, 2022 at 12:14:09PM -0500, Segher Boessenkool wrote:
> > On Mon, Mar 28, 2022 at 12:26:02PM -0400, Michael Meissner wrote:
> > > However on power9 and power10 it generates:
> > >
> > > ;; vec_splats (vec_extract (
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Croatian team of translators. The file is available at:
https://translationproject.org/latest/gcc/hr.po
(This file, 'gcc-12.1-b20220213.hr.po
On Mon, Mar 28, 2022 at 12:28:55PM -0400, Michael Meissner wrote:
> In looking at PR target/99293, I noticed that the vsx_extract_
> pattern for V2DImode and V2DFmode only allowed traditional floating point
> registers, and it did not allow Altivec registers. The original code was
> written a few
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-7868-g1203e8f7880c9751ece5f5302e413b20f4608a00.
gcc/analyzer/ChangeLog:
PR analyzer/105074
* region.cc (ipa_ref_requires_tracking): Drop "context_fndecl",
instead using the ref->referring
PR analyzer/105087 describes a false positive from
-Wanalyzer-double-free in which the analyzer erroneously considers two
successive inlined vasprintf calls to have allocated the same pointer.
The root cause is that the result written back from vasprintf is a
conjured_svalue, and that we normally
Add vxworks to the set of operating systems whose C libraries don't
support strndup.
Tested on affected systems and on x86_64-linux-gnu. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.dg/analyzer/strndup-1.c: Add *-*-vxworks* to no-strndup
in libc.
---
gcc/testsuite/gcc.d
On Thu, Mar 24, 2022 at 1:53 PM Jason Merrill wrote:
> Thanks! For future reference, the patch doesn't apply easily because
> gmail wrapped lines; for sending patches via gmail you'll need to use
> attachments. Or you can use another MUA, or git send-email. This time
> I fixed the wrapping by h
On Mon, 28 Mar 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > On Mon, 28 Mar 2022, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > Since we're now vectorizing by default at -O2 issues like PR101908
> >> > become more important where we apply basic-block vectorization
77 matches
Mail list logo
