On Feb 26, 2021, David Edelsohn wrote:
> This patch is okay.
Thanks, I've finally checked it in.
>> From: Joel Brobecker
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/powerpc/undef-bool-2.c: Add
>> dg-require-effective-target powerpc_vsx_ok directive.
>> * g++.dg/ext/undef-bool-1.C: Add dg-r
Attached is a revised patch with three changes:
1) use wi::to_offset (max_object_size ()) instead of tree_to_shwi()
as requested,
2) avoid warning for accesses to elements of arrays of empty types
(PR 99475 that I noticed while testing the original patch),
3) include the size of the destina
On Mon, Mar 08, 2021 at 06:10:05PM -0700, Martin Sebor wrote:
> On 3/5/21 3:03 PM, Jason Merrill via Gcc-patches wrote:
> > On 3/4/21 9:37 PM, Marek Polacek wrote:
> > > This PR complains that we issue a -Wconversion warning in
> > >
> > > template struct X {};
> > > template X foo();
> >
Good Day,
We are following up to know your interest in obtaining the Potential mailing
list.
Australasian Oil & Gas Exhibition & Conference
10 - 11 Mar 2021
Perth Convention and Exhibition Centre, Perth, Australia
Visitors count: 6,723
FLAT 50% Discount on the list
Please let us know
On 3/5/21 3:03 PM, Jason Merrill via Gcc-patches wrote:
On 3/4/21 9:37 PM, Marek Polacek wrote:
This PR complains that we issue a -Wconversion warning in
template struct X {};
template X foo();
saying "conversion from 'long unsigned int' to 'int' may change value".
While it's not techn
On Fri, Mar 05, 2021 at 05:15:49PM -0500, Jason Merrill via Gcc-patches wrote:
> On 3/3/21 7:55 PM, Marek Polacek wrote:
> > In this test we are building a call in a template, but since neither
> > the function nor any of its arguments are dependent, we go down the
> > normal path in finish_call_ex
On Fri, Mar 05, 2021 at 05:03:45PM -0500, Jason Merrill wrote:
> On 3/4/21 9:37 PM, Marek Polacek wrote:
> > This PR complains that we issue a -Wconversion warning in
> >
> >template struct X {};
> >template X foo();
> >
> > saying "conversion from 'long unsigned int' to 'int' may chang
This libgo patch casts SIGSTKSZ to uintptr before comparing it to a
uintptr value. This fixes build failures with newer versions of glibc
in which SIGSTKSZ has changed such that the type is now long. The
build failure is a signed-unsigned comparison warning that turns into
an error due to -Werror
On Linux/x86_64,
bc56d27de97ecea813279ce5ba45b278dcccfe21 is the first bad commit
commit bc56d27de97ecea813279ce5ba45b278dcccfe21
Author: Nathan Sidwell
Date: Mon Mar 8 11:55:26 2021 -0800
C++: Enable c++2b module mode [PR 99436]
caused
FAIL: g++.dg/modules/builtin-3_a.C -std=c++17 scan
As some of you already know, Friday is my last day with Red Hat. This
adjusts my email address in the maintainers file to a personal one.
I'll update it for my new employer once I'm on-boarded and we've got all
the usual copyright stuff put in place.
I'll still be working with GNU tools, though
> This one worked. Is that what you had in mind?
>
> * raise-gcc.c: On Cygwin include mingw32.h to prevent
> windows.h from including x86intrin.h or emmintrin.h.
Yep, exactly, thanks, you may put it on whichever branch you need.
--
Eric Botcazou
On Mon, Mar 8, 2021 at 12:07 PM Eric Botcazou wrote:
>
> > I wonder why we include from this file at all,
> > and why it is not included from {t,}system.h instead which
> > is where system header specific fixups should be made
> > (and this one could be avoided because system headers
> > are incl
__gnu_debug::basic_string is not extensively used nor extensively tested
so not actively maintained.
So here is a first patch to fix some problems and increase test
coverage. I plan another patch cause I think it is missing some C++17
methods.
Tested under Linux x86_64, ok to commit ?
l
ping
> [Changes from V2:
> - Rebased to latest master.
> - Several bug fixes in the CTF support.
> - Several bug fixes in the BTF support.
> - New tests for BTF.
> - Fix a couple of tests in the CTF testsuite.
> - More testing: we are building Gentoo with -gctf activated by
> default and fixin
This works since the recent r11-7102, but we didn't have a test for
a template-argument context.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
PR c++/96268
* g++.dg/cpp2a/nontype-class41.C: New test.
---
gcc/testsuite/g++.dg/cpp2a/nontype-class41.C | 13
This adds support for c++23 mode to modules, and enables such testing.
PR c++/99436
gcc/cp/
* name-lookup.c (get_cxx_dialect_name): Add cxx23.
gcc/testsuite/
* g++.dg/modules/modules.exp (MOD_STD_LIST): Add 2b.
--
Nathan Sidwell
diff --git c/gcc/cp/name-l
On Mon, Mar 8, 2021 at 2:52 PM Martin Liška wrote:
>
> Hi.
>
> The bug is about usage of ix86_isa_flags instead of opts->x_ix86_isa_flags.
> I'm planning a bigger refactoring regarding the flags & PTA_PCLMUL conditions.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
>
We didn't specifically check for a module-decl inside a header unit.
That leads to a confusing diagostic. Fixed thusly.
gcc/cp/
* lex.c (module_token_filter::resume): Ignore module-decls inside
header-unit.
* parser.c (cp_parser_module_declaration): Reject in he
Class template partial specializations need to be in the
specialization hash, but not all of them. This defers adding
streamed-in entities to the hash table, in the same way I deferred
adding the instantiation and specialization lists for 99170.
PR c++/99285
gcc/cp/
* cp
In development of the Rust FE logging is useful in debugging. Instead of
rolling our own logger it became clear the loggers part of analyzer and jit
projects could be extracted and made generic so they could be reused in
other projects.
To test this patch make check-jit was invoked, for analyzer t
Hi!
On Mon, Mar 08, 2021 at 10:32:16AM -0600, acsaw...@linux.ibm.com wrote:
> PR99070 is caused by a fusion pattern matching that the individual
> instructions do not match when it is split later. In this case the
> ld+cmpi patterns were allowing a d-form load address, which the split
> condition
From: Aaron Sawdey
PR99070 is caused by a fusion pattern matching that the individual
instructions do not match when it is split later. In this case the
ld+cmpi patterns were allowing a d-form load address, which the split
condition would rightly split, however that left us with something that
co
Hi,
AFAICS the code in build_round_expr implicitly assumes that __float128 exists,
which is *not* the common case among 64-bit architectures since "long double"
is generally already 128-bit for them.
Tested on x86-64/Linux and SPARC64/Linux, OK for the mainline?
2021-03-08 Eric Botcazou
Hi,
this is a regression present on the mainline and 10 branch for architectures
that pass all structure types by reference, e.g. 32-bit PowerPC or SPARC.
Jakub posted a detailed analysis in the audit trail and this boils down to
the RTL expander trying to take the address of a DECL whose RTX is
On 08/03/2021 16:21, Richard Biener wrote:
> On Mon, Mar 8, 2021 at 4:14 PM Alex Coplan wrote:
> >
> > On 08/03/2021 14:57, Richard Biener wrote:
> > > On Mon, Mar 8, 2021 at 12:44 PM Alex Coplan via Gcc-patches
> > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > As discussed in the PR, we curre
On Mon, Mar 8, 2021 at 4:14 PM Alex Coplan wrote:
>
> On 08/03/2021 14:57, Richard Biener wrote:
> > On Mon, Mar 8, 2021 at 12:44 PM Alex Coplan via Gcc-patches
> > wrote:
> > >
> > > Hi all,
> > >
> > > As discussed in the PR, we currently have two different numbering
> > > schemes for SVE built
On 08/03/2021 14:57, Richard Biener wrote:
> On Mon, Mar 8, 2021 at 12:44 PM Alex Coplan via Gcc-patches
> wrote:
> >
> > Hi all,
> >
> > As discussed in the PR, we currently have two different numbering
> > schemes for SVE builtins: one for C, and one for C++. This is
> > problematic for LTO, whe
Hi all,
In this bug combine forms the (R)SHRN(2) instructions with an invalid shift
amount.
The intrinsic expanders for these patterns validate the right shift amount but
if the
final patterns end up being matched by combine (or other RTL passes I suppose)
they
still let the wrong const_vector
I'm going to push one libsanitizer commit. And I'm adding a test-case for it.
Martin
libsanitizer/ChangeLog:
PR sanitizer/98920
* asan/asan_interceptors.cpp (COMMON_INTERCEPT_FUNCTION_VER):
Cherry pick.
(COMMON_INTERCEPT_FUNCTION_VER_UNVERSIONED_FALLBACK): Likewi
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
The patch was successfully bootstrapped and tested on ppc64le, x86-64
and arm64.
commit 04b4828c6dd215385fde6964a5e13da8a01a78ba (HEAD -> master)
Author: Vladimir N. Makarov
Date: Mon Mar 8 09:24:57 2021 -0500
Alex Coplan writes:
> Hi all,
>
> As discussed in the PR, we currently have two different numbering
> schemes for SVE builtins: one for C, and one for C++. This is
> problematic for LTO, where we end up getting confused about which
> intrinsic we're talking about. This patch inserts placeholders i
On Mon, Mar 8, 2021 at 12:44 PM Alex Coplan via Gcc-patches
wrote:
>
> Hi all,
>
> As discussed in the PR, we currently have two different numbering
> schemes for SVE builtins: one for C, and one for C++. This is
> problematic for LTO, where we end up getting confused about which
> intrinsic we're
This patch is a merge of parts from:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562467.html
and devel/omp/gcc-10 commit 36a1eb, which was a modified merge of:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558975.html
to provide the equivalent front-end patches for support
On 3/8/21 2:15 PM, Uros Bizjak wrote:
OK, but looking at i386.h, similar handing for several other PTA_*
flags is missing.
Thanks.
Well, I think all other should be covered. I wrote a comparison script and
difference is following after my patch:
{'PTA_PREFETCH_SSE', 'PTA_64BIT', 'PTA_NO_80387
On Mon, Mar 8, 2021 at 1:45 PM Martin Liška wrote:
>
> Hello.
>
> The patch fixes missing features for -march targets that support
> PTA_UINTR and PTA_HRESET.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
Hi.
The bug is about usage of ix86_isa_flags instead of opts->x_ix86_isa_flags.
I'm planning a bigger refactoring regarding the flags & PTA_PCLMUL conditions.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
PR
On Mon, 8 Mar 2021, Tobias Burnus wrote:
> On 08.03.21 08:45, Richard Biener wrote:
> > On Fri, 5 Mar 2021, Tobias Burnus wrote:
> >> Nested functions are permitted for C but not C++ as extension.
> >> They are also permitted for Fortran, which generates DECL_CONTEXT
> >> == NAMESPACE_DECL for mod
On Mon, 8 Mar 2021, Jakub Jelinek wrote:
> On Mon, Mar 08, 2021 at 12:04:22PM +0100, Richard Biener wrote:
> > +;; Further split pinsrq variants of vec_concatv2di to hide the latency
> > +;; the GPR->XMM transition(s).
> > +(define_peephole2
> > + [(match_scratch:DI 3 "Yv")
> > + (set (match_op
Due to a common code change the comparison in the testcase is emitted
via vec_cmp instead of vcond. The testcase checks for an optimization
currently only available via vcond.
Fixed by implementing the same optimization also in
s390_expand_vec_compare.
Bootstrapped and regression tested on s390x
Hello.
The patch fixes missing features for -march targets that support
PTA_UINTR and PTA_HRESET.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
PR target/99463
* config/i386/i386-options.c (ix86_opti
On 08.03.21 08:45, Richard Biener wrote:
On Fri, 5 Mar 2021, Tobias Burnus wrote:
Nested functions are permitted for C but not C++ as extension.
They are also permitted for Fortran, which generates DECL_CONTEXT
== NAMESPACE_DECL for module variables.
That causes the gcc_assert (decl_function_co
On Mon, Mar 08, 2021 at 12:04:22PM +0100, Richard Biener wrote:
> +;; Further split pinsrq variants of vec_concatv2di to hide the latency
> +;; the GPR->XMM transition(s).
> +(define_peephole2
> + [(match_scratch:DI 3 "Yv")
> + (set (match_operand:V2DI 0 "sse_reg_operand")
> + (vec_concat:V2
Jonathan Wakely via Gcc-patches 于2021年3月8日周一 下午6:57写道：
>
> On 08/03/21 14:35 +0800, Chen Li wrote:
> >
> >When execute libstdc++ testcases on mips, I notice that last_write_time
> >alawys failed, and the failed VERIFY is "VERIFY(
> >approx_equal(last_write_time(f.path), time) );" where testing ti
> I wonder why we include from this file at all,
> and why it is not included from {t,}system.h instead which
> is where system header specific fixups should be made
> (and this one could be avoided because system headers
> are included _before_ poisoning anything).
is the Mother of All Things o
This reduces the latency of a V2DImode construction from two
GPRs by avoiding the dependence on the GPR->XMM move with the
used vpinsrq instruction and instead allow the two GPR->XMM moves
to be concurrently executed and scheduled, performing the insert
using vpunpcklqdq.
Bootstrapped and tested o
On 08/03/21 14:35 +0800, Chen Li wrote:
When execute libstdc++ testcases on mips, I notice that last_write_time
alawys failed, and the failed VERIFY is "VERIFY(
approx_equal(last_write_time(f.path), time) );" where testing time before
than epoch.
Below is the minimal case:
```
// gcc a.c
int
Hi all,
As discussed in the PR, we currently have two different numbering
schemes for SVE builtins: one for C, and one for C++. This is
problematic for LTO, where we end up getting confused about which
intrinsic we're talking about. This patch inserts placeholders into the
registered_functions vec
On Sun, Jan 10, 2021 at 2:05 PM Mikael Pettersson via Gcc-patches
wrote:
>
> On Sun, Jan 10, 2021 at 11:57 AM Arnaud Charlet wrote:
> >
> > > This fixes a compilation error preventing bootstrap with Ada on
> > > x86_64-pc-cygwin. See PR bootstrap/94918 for details.
> > >
> > > Compared to the ini
This is a backport of the cse_sve_vl_constants tuning param to GCC 10.
It's had a couple of trivial merge conflicts to resolve.
Bootstrapped and tested on the branch on aarch64-none-linux-gnu.
Pushing to the branch.
Thanks,
Kyrill
gcc/ChangeLog:
* config/aarch64/aarch64-tuning-flags.def
On 3/4/21 9:54 PM, Jason Merrill wrote:
On 3/4/21 10:52 AM, Martin Liška wrote:
On 3/4/21 4:45 PM, Jason Merrill wrote:
Sure, I guess you do need to set that flag for the local decls, but that should
be all.
Jason
Doing that also fails :/
This time likely due to how we set RECORD argument
50 matches
Mail list logo
