On Wed, Mar 10, 2021 at 7:04 AM Alexandre Oliva wrote:
>
>
> ppc configurations that have -mstrict-align enabled by default fail
> gcc.dg/strlenopt-80.c, because some memcpy calls don't get turned into
> MEM_REFs, which defeats the tested-for strlen optimization.
>
> This was regstrapped on
On Thu, Mar 11, 2021 at 8:51 PM Segher Boessenkool
wrote:
>
> On Thu, Mar 11, 2021 at 04:52:18AM -0300, Alexandre Oliva wrote:
> > Several ipa-sra tests fail because -mlongcall on powerpc is a
> > TYPE_ATTRIBUTE, and those disable ipa-sra.
> >
> > This local workaround disables -mlongcall for the
On Thu, Mar 11, 2021 at 3:47 PM Alexandre Oliva wrote:
>
> On Mar 11, 2021, Richard Biener wrote:
>
> > I think that's OK.
>
> Cool, here's the patch I'm nearly done regstrapping on x86_64-linux-gnu
> and x-ppc64-vx7r2. Ok to install?
OK.
Richard.
> > It's probably difficult to make the test
On Thu, Mar 11, 2021 at 11:22 PM H.J. Lu wrote:
>
> Update 'P' operand modifier for -fno-plt to support inline assembly
> statements. In 64-bit, we can always load function address with
> @GOTPCREL. In 32-bit, we load function address with @GOT only for
> non-PIC since PIC register may not be
On Thu, Mar 11, 2021 at 11:22 PM H.J. Lu wrote:
>
> Update 'P' operand modifier for -fno-plt to support inline assembly
> statements. In 64-bit, we can always load function address with
> @GOTPCREL. In 32-bit, we load function address with @GOT only for
> non-PIC since PIC register may not be
Hello Kyrill,
As you said, this patch is only effective for generic SVE tuning.
So, I will evaluate performance without -mcpu option on a64fx.
I'll tell you the result next week.
Regards,
Qian
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Wednesday, March 10, 2021 10:56 PM
> To:
I merged trunk revision 7ad5a72c8bc6aa71a0d195ddfa207db01265fe0b to
the gccgo branch.
Ian
The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
resulting in all information about the typedef's involvement getting
lost. This drops necessary information for warnings and can make them
confusing or even misleading. It also makes specialized warnings for
unspecified-size
On Wed, Mar 10, 2021 at 02:41:50AM -0300, Alexandre Oliva wrote:
> ppc configurations that have -mstrict-align enabled by default fail
> gcc.dg/strlenopt-80.c, because some memcpy calls don't get turned into
> MEM_REFs, which defeats the tested-for strlen optimization.
>
> This was regstrapped on
On Wed, Mar 10, 2021 at 02:06:24AM -0300, Alexandre Oliva wrote:
> On Mar 9, 2021, Segher Boessenkool wrote:
>
> > +return [check_no_compiler_messages powerpc_sqrt object {
>
> I don't think you really need to assemble this. s/object/assembly/
> would do. Even preprocessing alone would
Looks good Tobias, OK,
Odd about that line in set_internal_unit. Probably leftover from a
copy/paste. I see in comment #5 of the PR that you mentioned trying the
assert to make sure it is useless code.
Thanks for the patch,
Jerry
On 3/11/21 2:38 AM, Tobias Burnus wrote:
Revised version –
On Thu, Mar 11, 2021 at 03:47:17PM -0600, Qing Zhao wrote:
> Hi, Kees,
>
> Sorry for the late reply (I have been busy with other work recently).
>
> Currently, I am working on the issue of flexible length array as the last
> field of the structure.
>
> In order to fix it correctly, I have the
The Go frontend generally doesn't create a temporary for an expression
that is a variable, because it's normally valid to simply reload
thevalue from the variable. However, if the variable is in the heap,
then loading the value is a pointer indirection. The process of
creating GCC IR can cause
The analyzer builds an exploded graph of (point,state) pairs and when
it finds a problem, records a diagnostic at the relevant exploded node.
Once it has finished exploring the graph, the analyzer needs to generate
the shortest feasible path through the graph to each diagnostic's node.
This is
This patch generalizes shortest-path.h so that it can be used to
find the shortest path from each node to a given target node (on top
of the existing support for finding the shortest path from a given
origin node to each node).
I've marked this as "analyzer" as this is the only code using
This bulletproofs the shortest_paths code against unreachable nodes,
gracefully handling them, rather than failing an assertion.
I've marked this as "analyzer" as this is the only code using
shortest-paths.h.
This patch is required by followup work to fix PR analyzer/96374.
Successfully
Update 'P' operand modifier for -fno-plt to support inline assembly
statements. In 64-bit, we can always load function address with
@GOTPCREL. In 32-bit, we load function address with @GOT only for
non-PIC since PIC register may not be available at call site.
gcc/
PR target/99504
On Thu, 11 Mar 2021, Alexandre Oliva wrote:
> I kind of like the notion of adding a comment to the test itself, but I
> wasn't sure that's what you meant.
Yes, adding a comment to the test itself is what I meant.
--
Joseph S. Myers
jos...@codesourcery.com
GCC on AIX generates thread local uninitialized data in the common section,
which could conflict with another module.
This patch changes the code generation to place static uninitialized
thread local data into the local common section specified with .lcomm.
This change also
Hi, Kees,
Sorry for the late reply (I have been busy with other work recently).
Currently, I am working on the issue of flexible length array as the last field
of the structure.
In order to fix it correctly, I have the following question:
> On Feb 26, 2021, at 3:42 PM, Kees Cook wrote:
>
>
This was a simple thinko about which object held the reference to the
binding vector. I also noticed stale code in the tree dumper, as I
recently removed the flags from a lazy number.
PR c++/99248
gcc/cp/
* name-lookup.c (lookup_elaborated_type_1): Access slot not
I was looking at the LCOV coverage report for the C++ FE and
found a bunch of unused functions that I think we can remove.
Obviously, I left alone various dump_* and debug_* routines.
I haven't removed cp_build_function_call although it is also
currently unused.
* lambda_return_type: was used in
Thank you so much for taking the time to help me with this! It was greatly
appreciated.
-Original Message-
From: Jonathan Wakely
Sent: Thursday, March 11, 2021 11:56 AM
To: Hoyer, David
Cc: libstdc++ ; gcc-patches@gcc.gnu.org
Subject: Re: printers.py issue
NetApp Security WARNING:
On Thu, Mar 11, 2021 at 04:52:18AM -0300, Alexandre Oliva wrote:
> Several ipa-sra tests fail because -mlongcall on powerpc is a
> TYPE_ATTRIBUTE, and those disable ipa-sra.
>
> This local workaround disables -mlongcall for the failing tests on
> powerpc*-*-vxworks*, so they get a chance to run
On 11/03/21 17:54 +, Jonathan Wakely wrote:
Contrary to what POSIX says, some directory operations on MacOS can fail
with EPERM instead of EACCES, so we need to handle both.
libstdc++-v3/ChangeLog:
PR libstdc++/99537
Oh drat, that's the wrong PR number. It should be PR 99533, as
On Thu, Mar 11, 2021 at 11:29:57AM -0300, Alexandre Oliva wrote:
> On Mar 11, 2021, Richard Biener wrote:
> > I wonder what the effect of this switch is - it's documented as
> > affecting the call site (different call insn sequence by default), so
> > the best representation would be an attribute
On 11/03/21 19:09 +0100, Daniel Krügler via Libstdc++ wrote:
It seems to me that basically all uint128_t operations should be
unconditionally noexcept. Currently none of them is so (The constexpr
keyword is a red herring in this regard).
None of this code is exposed to users (so nobody is
On 11/03/21 12:16 -0500, Patrick Palka via Libstdc++ wrote:
--- /dev/null
+++ b/libstdc++-v3/src/c++17/uint128_t.h
@@ -0,0 +1,297 @@
+// A relatiely minimal unsigned 128-bit integer class type, used by the
"relatively"
Apart from that, all four patches in the series are OK for trunk.
Am Do., 11. März 2021 um 18:17 Uhr schrieb Patrick Palka via Libstdc++
:
>
> This implements a minimal integer class type that emulates 128-bit
> unsigned arithmetic using a pair of 64-bit integers, which the
> floating-point std::to_chars implementation then uses as a drop-in
> replacement for
More extensive testing of the patch I just committed in r11-7563 to
avoid the false positive -Warray-bounds on accesses to members of
virtual bases has exposed a couple of problems that cause many false
negatives for even basic bugs like:
typedef struct A { int i; } A;
void* g (void)
{
On 10/03/21 16:57 +, Hoyer, David wrote:
I wanted to finally follow up on these issues I reported.
On issue 1, the patch you provided did fix the problem
Thanks for confirming. It's committed to the master branch now (as
attached to this mail). I also plan to backport it to the active
As Lewis Baker wrote in the PR:
> The 'fetch_sub()' operation in _M_release_ownership() should be using
> memory_order::acq_rel instead of memory_order::release. The use of
> 'release' only is insufficient as it does not synchronise with any
> corresponding 'acquire' operation.
> With the
The standard only specifies that barrier::arrival_token is a move
constructible and move assignable type. We originally used a scoped enum
type, but that means we do not diagnose non-portable code that makes
copies of arrival tokens (or compares them for equality, or uses them as
keys in map!)
Contrary to what POSIX says, some directory operations on MacOS can fail
with EPERM instead of EACCES, so we need to handle both.
libstdc++-v3/ChangeLog:
PR libstdc++/99537
* src/c++17/fs_dir.cc (recursive_directory_iterator): Use new
helper function to check for
This avoids a false positive -Wmaybe-uninitialized warning, by
initializing _M_saved on construction.
libstdc++-v3/ChangeLog:
PR libstdc++/99536
* include/bits/random.h (normal_distribution): Use
default-initializer for _M_saved and _M_saved_available.
Tested
I eventually prefer to propose this version.
Compared to the previous one I have the _M_can_advance calling the
former one with correct number of elements to check for advance. And the
former _M_can_advance is also properly making use of the
__dp_sign_max_size precision.
Here is the
This turned out to be an existing problem, which had been hidden by
other bugs. Templated members of templated classes can end up
instantiating the template itself, and we were not handling the
mergeableness of that correctly.
PR c++/99528
gcc/cp/
* module.cc (enum
This implements a minimal integer class type that emulates 128-bit
unsigned arithmetic using a pair of 64-bit integers, which the
floating-point std::to_chars implementation then uses as a drop-in
replacement for unsigned __int128 on targets that lack the latter.
This allows us to fully support
This makes Ryu consistently use the uint128_t alias defined in
floating_to_chars.cc.
libstdc++-v3/ChangeLog:
* src/c++17/ryu/LOCAL_PATCHES: Update.
* src/c++17/ryu/d2s_intrinsics.h: Don't define uint128_t.
* src/c++17/ryu/generic_128.h: Likewise.
*
This file keeps track of the local modifications we've made to our copy
of Ryu.
libstdc++-v3/ChangeLog:
* src/c++17/ryu/LOCAL_PATCHES: New file.
---
libstdc++-v3/src/c++17/ryu/LOCAL_PATCHES | 1 +
1 file changed, 1 insertion(+)
create mode 100644
Since Ryu has an alias uint128_t for this same purpose, it seems best
for us to use this name as well, so as to minimize the amount of local
modifications we'd need to make to our copy of Ryu. (In a subsequent
patch, we're going to remove Ryu's aliases so that it uses the one
defined in
This fixes an ICE with OpenMP 'omp decare simd' but is a generic bug.
Namely TREE_TYPE(fndecl) has a mismatch to the arglist chain,
missing some hidden arguments with -fcoarray=lib.
OK for mainline and GCC 10?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201,
On 11/03/21 17:46 +0100, Jakub Jelinek via Libstdc++ wrote:
On Thu, Mar 11, 2021 at 04:31:51PM +, Jonathan Wakely via Gcc-patches wrote:
On 11/03/21 16:27 +, Jonathan Wakely wrote:
> That seems cleaner to me, rather than adding another variable with
> minor differences from the existing
Hi!
On 2021-02-23T22:52:38+0100, Jakub Jelinek via Gcc-patches
wrote:
> On Tue, Feb 23, 2021 at 09:43:51PM +, Kwok Cheung Yeung wrote:
>> On 19/02/2021 7:12 pm, Kwok Cheung Yeung wrote:
>> > I have included the current state of my patch. All task-detach-* tests
>> > pass when executed
On Thu, Mar 11, 2021 at 04:31:51PM +, Jonathan Wakely via Gcc-patches wrote:
> On 11/03/21 16:27 +, Jonathan Wakely wrote:
> > That seems cleaner to me, rather than adding another variable with
> > minor differences from the existing AM_CXXFLAGS.
>
> My specific concern is that
On 11/03/21 16:27 +, Jonathan Wakely wrote:
That seems cleaner to me, rather than adding another variable with
minor differences from the existing AM_CXXFLAGS.
My specific concern is that AM_CXXFLAGS and AM_CXXFLAGS_LT will get
out of sync, i.e. we'll add something to the former and forget
These updates came out of a private conversation with Robert.
Pushed to the trunk.
Jeff
commit 52db241345a81207681733c5316b6fbf44596ac0
Author: Jeff Law
Date: Thu Mar 11 09:28:50 2021 -0700
MAINTAINERS updates for ex-ImgTec employees
/
* MAINTAINERS: Update entries
On 11/03/21 07:31 -0800, Caroline Tice via Libstdc++ wrote:
Adding the libstdc++ mailing list to the patch.
Thanks.
-- Caroline
cmt...@google.com
On Wed, Mar 10, 2021 at 8:50 PM Caroline Tice wrote:
This patch is to fix PR 99172.
Currently when GCC is configured with
On Mar 10, 2021, Hans-Peter Nilsson wrote:
> On Wed, 10 Mar 2021, Alexandre Oliva wrote:
>>
>> The test expects shrink-wrapping of the fsqrt call, but that will only
>> occur when there is a usable sqrt insn.
>>
>> Arrange for dejagnu to add the options that enable the sqrt insn, if
>> one is
Adding the libstdc++ mailing list to the patch.
-- Caroline
cmt...@google.com
On Wed, Mar 10, 2021 at 8:50 PM Caroline Tice wrote:
>
> This patch is to fix PR 99172.
>
> Currently when GCC is configured with --enable-vtable-verify, the
> libstdc++-v3 Makefiles add "-fvtable-verify=std
>
Some powerpc tests that require the fsqrt insn to be enabled
explicitly use the -mpowerpc-gpopt option. This fails if the fsqrt
opcode is not available on the target machine.
Switch to dg-add-options sqrt_insn for compile tests, that adds the
option for the feature (pending approval of another
Pushed as obvious, the original change was done
in g:e05a117dc4b98f3ac60851608f532ba7cee7343a.
Martin
ChangeLog:
* Makefile.tpl: The change was done Makefile.in which
is generated file.
---
Makefile.tpl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Alexandre Oliva wrote:
On Mar 11, 2021, Iain Sandoe wrote:
Alexandre Oliva wrote:
On Mar 10, 2021, Alexandre Oliva wrote:
* gcc.target/powerpc/prefix-ds-dq.c: Enable __float128.
I've been reminded that this is not enough for the scan-assembler tests
to pass, at least in our
On Mar 10, 2021, Joseph Myers wrote:
> In my view, such an XFAIL (for a GCC bug as opposed to an environmental
> issue) should have a comment pointing to a corresponding open bug in GCC
> Bugzilla. In this case, that's bug 58684.
Thanks, yeah, that's valuable information to add.
So far, I
On Mar 11, 2021, Iain Sandoe wrote:
> Alexandre Oliva wrote:
>> On Mar 10, 2021, Alexandre Oliva wrote:
>>
>>> * gcc.target/powerpc/prefix-ds-dq.c: Enable __float128.
>>
>> I've been reminded that this is not enough for the scan-assembler tests
>> to pass, at least in our configurations.
On Mar 11, 2021, Richard Biener wrote:
> I think that's OK.
Cool, here's the patch I'm nearly done regstrapping on x86_64-linux-gnu
and x-ppc64-vx7r2. Ok to install?
> It's probably difficult to make the test UNSUPPORTED
> when dg-additional-sources is discovered with a dg-do compile test?
On Mar 11, 2021, Richard Biener wrote:
> I wonder what the effect of this switch is - it's documented as
> affecting the call site (different call insn sequence by default), so
> the best representation would be an attribute on actual call stmts
I don't think that would fulfill its purpose.
My
Here is the amended commit log:
--
Ada: Ensure correct predefined equality behavior for Cursor objects of
hashed containers.
2021-03-11 Richard Wai
gcc/ada/
* libgnat/a-cohase.ads (Cursor): Synchronize comments for the Cursor
type definition to be consistent with identical
The ICE occurs because the 't' == NULL for assumed-size arrays.
For them, the size is not known – but as this should only occur
for use_device_{addr,ptr}, the size is not needed.
OK for mainline?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
On 3/11/21 3:52 AM, Jakub Jelinek wrote:
Hi!
build_cxx_call calls convert_from_reference at the end, so if an immediate
function returns a reference, we were constant evaluating not just that
call, but that call wrapped in an INDIRECT_REF. That unfortunately means
it can constant evaluate to
On 3/9/21 10:31 AM, Jakub Jelinek wrote:
Hi!
My PR82304/PR95307 fix moved reinterpret cast from pointer to integer
diagnostics from cxx_eval_outermost_constant_expr where it caught
invalid code only at the outermost level down into
cxx_eval_constant_expression.
Unfortunately, it regressed
Checking the number of pluses is unreliable since the vector size
isn't known. Instead see that the unwanted scalar compute is not
there.
Pushed.
2021-03-11 Richard Biener
PR testsuite/98245
* gcc.dg/vect/bb-slp-46.c: Scan for the scalar compute
instead of verifying
While we could at least vectorize it on targets which support
re-alignment tokens we fail to do this because of imperfections in
alignment analysis. XFAIL when the HW cannot deal with misaligned
vector accesses for now.
Pushed.
2021-03-11 Richard Biener
PR testsuite/97494
*
This is a missed optimization due to bogus alignment analysis.
Pushed.
2021-03-11 Richard Biener
PR testsuite/97494
* gcc.dg/vect/vect-complex-5.c: XFAIL on !vect_hw_misalign.
---
gcc/testsuite/gcc.dg/vect/vect-complex-5.c | 2 +-
1 file changed, 1 insertion(+), 1
As reported in the PR all powerpc64 targets fail
FAIL: gcc.dg/vect/slp-21.c scan-tree-dump-times vect "vectorizing stmts using
SLP" 2
because like on arm we now vectorize 4 opportunities. This adjusts
the testcase to follow the arm example.
compile-tested on powerpc64le-linux-gnu, pushed.
Richard Biener via Gcc-patches writes:
> On Thu, Mar 11, 2021 at 9:03 AM Alexandre Oliva wrote:
>>
>>
>> When vect.exp finds our configuration disables altivec by default, it
>> disables the execution of vectorization tests, assuming the test
>> hardware doesn't support it.
>>
>> Tests become
This makes sure to dump SSA names without identifier in the
declaration part of a function dump. While we dump the
anonymous variable decls the SSA names referencing them appear
without a clear reference as to what anonymous variable is used
(_3 vs. D.1234).
Bootstrapped and tested on
Revised version – the previous had a lock inversion, which could lead to
a deadlock, found by -fsanitize=thread. See transfer.c for the changes.
OK?
Tobias
On 11.03.21 10:42, Tobias Burnus wrote:
Hi all,
as found by Martin (thanks!) there is a race for newunit_free.
While that call is
On Thu, Mar 11, 2021 at 9:19 AM Alexandre Oliva wrote:
>
>
> Several ipa-sra tests fail because -mlongcall on powerpc is a
> TYPE_ATTRIBUTE, and those disable ipa-sra.
>
> This local workaround disables -mlongcall for the failing tests on
> powerpc*-*-vxworks*, so they get a chance to run even in
Hi,
On Thu, Mar 11 2021, Alexandre Oliva wrote:
> Several ipa-sra tests fail because -mlongcall on powerpc is a
> TYPE_ATTRIBUTE, and those disable ipa-sra.
>
> This local workaround disables -mlongcall for the failing tests on
> powerpc*-*-vxworks*, so they get a chance to run even in kernel
On Thu, Mar 11, 2021 at 9:03 AM Alexandre Oliva wrote:
>
>
> When vect.exp finds our configuration disables altivec by default, it
> disables the execution of vectorization tests, assuming the test
> hardware doesn't support it.
>
> Tests become just compile tests, but compile tests won't work
>
Hi all,
as found by Martin (thanks!) there is a race for newunit_free.
While that call is within the unitlock for the calls in io/unit.c,
the call in transfer.c did not use locks.
Additionally,
unit = get_gfc_unit (dtp->common.unit, do_create);
set_internal_unit (dtp, unit, kind);
On Thu, 11 Mar 2021, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because IPA-ICF considers the two
> functions identical. They aren't, the types of the .VEC_CONVERT call
> lhs is different. But for calls to internal functions, there is no
> fntype nor callee with a
Alexandre Oliva wrote:
On Mar 10, 2021, Alexandre Oliva wrote:
* gcc.target/powerpc/prefix-ds-dq.c: Enable __float128.
I've been reminded that this is not enough for the scan-assembler tests
to pass, at least in our configurations. Nearly all of the asm
expectations are unmet. I'm yet
Hi!
build_cxx_call calls convert_from_reference at the end, so if an immediate
function returns a reference, we were constant evaluating not just that
call, but that call wrapped in an INDIRECT_REF. That unfortunately means
it can constant evaluate to something non-addressable, so if code later
There was a case of the implicit non-static pointer member mapping
not working properly with templates.
What happened was that the code in finish_omp_target() created the
map clauses (which normally runs after finish_omp_clauses), but being
a template class it was put through all the tsubst_*
Hi!
The following testcase is miscompiled, because IPA-ICF considers the two
functions identical. They aren't, the types of the .VEC_CONVERT call
lhs is different. But for calls to internal functions, there is no
fntype nor callee with a function type to compare, so all we compare
is just the
On Mar 10, 2021, Alexandre Oliva wrote:
> * gcc.target/powerpc/prefix-ds-dq.c: Enable __float128.
I've been reminded that this is not enough for the scan-assembler tests
to pass, at least in our configurations. Nearly all of the asm
expectations are unmet. I'm yet to identify the root
78 matches
Mail list logo
