Re: Avoid char[] array in tree_def
> On 10/29/20 1:40 PM, Richard Biener wrote:
> > On Thu, 29 Oct 2020, Jakub Jelinek wrote:
> >
> > > On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote:
> > > > >
> > > > > That's ugly and will for sure defeat warning / access code
> > > > > when we access this as char[], no? I mean, we could
> > > > > as well use 'int str[1];' here?
> > > >
> > > > Well, we always get char pointer via macro that is IMO OK, but I am also
> > > > not very much in love with this.
> > >
> > > Do we treat signed char [...]; as typeless storage too, or just
> > > what the C++ standard requires (i.e. char, unsigned char and std::byte
> > > where the last one is enum type with unsigned char underlying type)?
> >
> > All that is covered by is_byte_access_type which includes all
> > character types (including char16_t and wchar it seems) and std::byte.
>
> Well, that's a bug, apparently from the PR94923 patch (r11-499); previously
> it was char, signed char, and unsigned char. And even that is too much;
> even C++98 said just char and unsigned char could be used for bytewise
> access.
>
> When C++17 clarified this with the notion of "provides storage", it applied
> to only unsigned char and std::byte, not even the full set of byte-access
> types. We still need to allow bytewise access using plain char, but perhaps
> we don't need to treat plain char arrays as typeless.
>
> Attributes to say that a particular array does or does not provide storage
> for objects of other types do sound useful.
Thanks a lot for explanation!
I am adding Martin Sebor to CC. Perhaps you can fix the problem with
std::byte, and signed char to imply typeless storage and ideally also
add an attribute? This seem too deep into C++ FE details for me.
I was thiking a bit more about all accesses to trees getting same alias
set. This is because we allow type puning through unions. If our tree
datastructure was a C++ class hiearchy, this would not happen since
accesses to specialized tree node would not be through unions but
through casted pointers.
We could do that with our acessor macros, too.
I tried to turn (NODE)->base in our accesors to ((tree_base *)(node))->base
and this breaks with const_tree pointers. However the following seem to
work and get better TBAA.
I think converting other acessors should be quite easy and make our
predicates more easy to optimize.
What do you think?
Honza
diff --git a/gcc/tree.h b/gcc/tree.h
index 7f0aa5b8d1d..cd8146808f7 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -235,13 +235,24 @@ as_internal_fn (combined_fn code)
#define NULL_TREE (tree) NULL
+inline tree_base *
+as_a_tree_base (tree t)
+{
+ return (tree_base *)t;
+}
+inline const tree_base *
+as_a_tree_base (const_tree t)
+{
+ return (const tree_base *)t;
+}
+
/* Define accessors for the fields that all tree nodes have
(though some fields are not used for all kinds of nodes). */
/* The tree-code says what kind of node it is.
Codes are defined in tree.def. */
-#define TREE_CODE(NODE) ((enum tree_code) (NODE)->base.code)
-#define TREE_SET_CODE(NODE, VALUE) ((NODE)->base.code = (VALUE))
+#define TREE_CODE(NODE) ((enum tree_code) (as_a_tree_base (NODE)->code))
+#define TREE_SET_CODE(NODE, VALUE) (as_a_tree_base (NODE)->code = (VALUE))
/* When checking is enabled, errors will be generated if a tree node
is accessed incorrectly. The macros die with a fatal error. */
@@ -642,7 +653,7 @@ extern void omp_clause_range_check_failed (const_tree,
const char *, int,
In IDENTIFIER_NODEs, this means that some extern decl for this name
had its address taken. That matters for inline functions.
In a STMT_EXPR, it means we want the result of the enclosed expression. */
-#define TREE_ADDRESSABLE(NODE) ((NODE)->base.addressable_flag)
+#define TREE_ADDRESSABLE(NODE) (as_a_tree_base (NODE)->addressable_flag)
/* Set on a CALL_EXPR if the call is in a tail position, ie. just before the
exit of a function. Calls for which this is true are candidates for tail
@@ -670,7 +681,7 @@ extern void omp_clause_range_check_failed (const_tree,
const char *, int,
/* In a VAR_DECL, nonzero means allocate static storage.
In a FUNCTION_DECL, nonzero if function has been defined.
In a CONSTRUCTOR, nonzero means allocate static storage. */
-#define TREE_STATIC(NODE) ((NODE)->base.static_flag)
+#define TREE_STATIC(NODE) (as_a_tree_base (NODE)->static_flag)
/* In an ADDR_EXPR, nonzero means do not use a trampoline. */
#define TREE_NO_TRAMPOLINE(NODE) (ADDR_EXPR_CHECK (NODE)->base.static_flag)
@@ -701,7 +712,7 @@ extern void omp_clause_range_check_failed (const_tree,
const char *, int,
warnings concerning the decl should be suppressed. This is used at
least for used-before-set warnings, and it set after one warning is
emitted. */
-#define TREE_NO_WARNING(NODE) ((NODE)->base.nowarning_flag)
+#define TREE_NO_WARNING(NODE) (as_a_tree_base (NODE)->nowarning_flag)
/* Nonzero if we should warn about the change in
Re: [PATCH][PR target/97540] Don't extract memory from operand for normal memory constraint.
On Thu, 29 Oct 2020, Richard Sandiford via Gcc-patches wrote:
> Hongtao Liu via Gcc-patches writes:
> > On Tue, Oct 27, 2020 at 7:13 PM Richard Sandiford
> > wrote:
> >>
> >> Hongtao Liu via Gcc-patches writes:
> >> > Hi:
> >> > For inline asm, there could be an operand like (not (mem:)), it's
> >> > not a valid operand for normal memory constraint.
> >> > Bootstrap is ok, regression test is ok for make check
> >> > RUNTESTFLAGS="--target_board='unix{-m32,}'"
> >> >
> >> > gcc/ChangeLog
> >> > PR target/97540
> >> > * ira.c: (ira_setup_alts): Extract memory from operand only
> >> > for special memory constraint.
> >> > * recog.c (asm_operand_ok): Ditto.
> >> > * lra-constraints.c (process_alt_operands): MEM_P is
> >> > required for normal memory constraint.
> >> >
> >> > gcc/testsuite/ChangeLog
> >> > * gcc.target/i386/pr97540.c: New test.
> >>
> >> Sorry to stick my oar in, but I think we should reconsider the
> >> bcst_mem_operand approach. It seems like these patches (and the
> >> previous one) are fighting against the principle that operands
> >> cannot be arbitrary expressions.
> >>
> >> This kind of thing was attempted long ago (even before my time!)
> >> for SIGN_EXTEND on MIPS. It ended up causing more problems than
> >> it solved and in the end it had to be taken out. I'm worried that
> >> we might end up going through the same cycle again.
> >>
> >
> > Could you provide the thread link for the issue of SIGN_EXTEND on
> > MIPS, then I can take a look to see if it's exactly the same issue as
> > mine.
>
> I couldn't find anything, sorry. The patch that finally removed
> the MIPS handling was:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2002-October/088178.html
>
> I know there was some discussion about the problems around then,
> but some of it might have been private rather than on-list.
> I can't remember the details now.
To further muddy the waters, I vaguely remember the SH makes (or
made) use of some peculiar feature regarding (optional?)
sign/zero-extend in operands. Joern and I had an "exchange of
views" where I (IIRC) wanted to remove a supporting middle-end
feature which was in the way of something I wanted to do and
actually didn't help the SH. (Register allocation silently
swallowing an unary operator in constraints?) I think he
conceded but the legwork to remove it was never done.
Point being, to make that bell ring, perhaps it helps to look in
mail archives even long before then (maybe before 2000) or at
least a look at the SH port. Looking there now, maybe it's
related to its arith_reg_operand, that oddly appears to allow
sign_extend but where the body doesn't match it due to an #if 0.
So, all support has likely decayed since then and now be just
dust...
brgds, H-P
Re: [PATCH] Fix gnu-versioned-namespace build
After completion of test in normal and versioned namespace mode I
committed the attached patch.
Note that there are still failures in versioned namespace mode do to
missing symbol exports for which I'll propose an other patch.
On 30/10/20 7:48 pm, Jonathan Wakely wrote:
On 30/10/20 18:51 +0100, François Dumont wrote:
On 30/10/20 2:37 pm, Jonathan Wakely wrote:
On 30/10/20 13:23 +, Jonathan Wakely wrote:
On 30/10/20 13:59 +0100, François Dumont via Libstdc++ wrote:
The gnu-versioned-namespace build is broken.
The fix in charconv/floating_from_chars.cc is quite trivial. I am
not so sure about the fix in sstream-inst.cc.
The change for src/c++20/sstream-inst.cc is OK to commit. It would
probably be better to not build that file at all if the cxx11 ABI is
not supported at all, but then the src/c++20 directory would be empty
and I'm not sure if that would work. So just making the file empty is
fine.
The change for from_chars is not OK. With your change the
header doesn't declare those functions if included by a file using the
old ABI. That's wrong, they should be declared unconditionally.
I see two ways to fix it. Either make the declarations in the header
depend on ! _GLIBCXX_INLINE_VERSION (so they're disabled for
gnu-versioned namespace) or fix the code in floating_from_chars to not
use a pmr::memory_resource for allocation in the versioned namespace
build.
Here's a patch for the second way.
A third way to fix it would be to make basic_string work with C++
allocators, so that pmr::string is usable for the gnu-versioned
namespace.
And the fourth would be to switch the versioned namespace to use the
new ABI unconditionally, instead of using the old ABI unconditionally.
Can I commit this one once tested then ?
Yes please.
I'll try to put the fourth way in place however.
N.B. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 tracks that.
diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc b/libstdc++-v3/src/c++17/floating_from_chars.cc
index d52c0a937b9..c279809cf35 100644
--- a/libstdc++-v3/src/c++17/floating_from_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
@@ -27,6 +27,9 @@
// 23.2.9 Primitive numeric input conversion [utility.from.chars]
//
+// Prefer to use std::pmr::string if possible, which requires the cxx11 ABI.
+#define _GLIBCXX_USE_CXX11_ABI 1
+
#include
#include
#include
@@ -87,6 +90,12 @@ namespace
void* m_ptr = nullptr;
};
+#if _GLIBCXX_USE_CXX11_ABI
+ using buffered_string = std::pmr::string;
+#else
+ using buffered_string = std::string;
+#endif
+
inline bool valid_fmt(chars_format fmt)
{
return fmt != chars_format{}
@@ -130,7 +139,7 @@ namespace
// Returns a nullptr if a valid pattern is not present.
const char*
pattern(const char* const first, const char* last,
- chars_format& fmt, pmr::string& buf)
+ chars_format& fmt, buffered_string& buf)
{
// fmt has the value of one of the enumerators of chars_format.
__glibcxx_assert(valid_fmt(fmt));
@@ -359,6 +368,22 @@ namespace
return result;
}
+#if ! _GLIBCXX_USE_CXX11_ABI
+ inline bool
+ reserve_string(std::string& s) noexcept
+ {
+__try
+ {
+ s.reserve(buffer_resource::guaranteed_capacity());
+ }
+__catch (const std::bad_alloc&)
+ {
+ return false;
+ }
+return true;
+ }
+#endif
+
} // namespace
// FIXME: This should be reimplemented so it doesn't use strtod and newlocale.
@@ -369,10 +394,16 @@ from_chars_result
from_chars(const char* first, const char* last, float& value,
chars_format fmt) noexcept
{
+ errc ec = errc::invalid_argument;
+#if _GLIBCXX_USE_CXX11_ABI
buffer_resource mr;
pmr::string buf(&mr);
+#else
+ string buf;
+ if (!reserve_string(buf))
+return make_result(first, 0, {}, ec);
+#endif
size_t len = 0;
- errc ec = errc::invalid_argument;
__try
{
if (const char* pat = pattern(first, last, fmt, buf)) [[likely]]
@@ -389,10 +420,16 @@ from_chars_result
from_chars(const char* first, const char* last, double& value,
chars_format fmt) noexcept
{
+ errc ec = errc::invalid_argument;
+#if _GLIBCXX_USE_CXX11_ABI
buffer_resource mr;
pmr::string buf(&mr);
+#else
+ string buf;
+ if (!reserve_string(buf))
+return make_result(first, 0, {}, ec);
+#endif
size_t len = 0;
- errc ec = errc::invalid_argument;
__try
{
if (const char* pat = pattern(first, last, fmt, buf)) [[likely]]
@@ -409,10 +446,16 @@ from_chars_result
from_chars(const char* first, const char* last, long double& value,
chars_format fmt) noexcept
{
+ errc ec = errc::invalid_argument;
+#if _GLIBCXX_USE_CXX11_ABI
buffer_resource mr;
pmr::string buf(&mr);
+#else
+ string buf;
+ if (!reserve_string(buf))
+return make_result(first, 0, {}, ec);
+#endif
size_t len = 0;
- errc ec = errc::invalid_argument;
__try
{
if (const char* pat = pattern(first, last, fmt, buf)) [[likely]]
diff --git a/libstdc++-v3/src/c++20/
Re: [PATCH] ASAN: disable -Wno-stringop-overflow for 2 tests
On Tue, Oct 13, 2020 at 1:17 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Tue, Oct 13, 2020 at 10:11:26AM +0200, Martin Liška wrote:
> > --- a/gcc/testsuite/g++.dg/asan/asan_test.C
> > +++ b/gcc/testsuite/g++.dg/asan/asan_test.C
> > @@ -9,6 +9,7 @@
> > // { dg-additional-options "-DASAN_AVOID_EXPENSIVE_TESTS=1" { target { !
> > run_expensive_tests } } }
> > // { dg-additional-options "-msse2" { target { i?86-*-linux*
> > x86_64-*-linux* i?86-*-freebsd* x86_64-*-freebsd*} } }
> > // { dg-additional-options "-D__NO_INLINE__" { target { *-*-linux-gnu } } }
> > +/* { dg-additional-options "-Wno-stringop-overflow" } */
>
> I'd put this one on the dg-options line next to other -Wno-* options.
> Otherwise LGTM.
>
> > // { dg-set-target-env-var ASAN_OPTIONS "handle_segv=2" }
> > // { dg-final { asan-gtest } }
> > diff --git a/gcc/testsuite/gcc.dg/asan/pr80166.c
> > b/gcc/testsuite/gcc.dg/asan/pr80166.c
> > index 629dd23a31c..5e153b274fa 100644
> > --- a/gcc/testsuite/gcc.dg/asan/pr80166.c
> > +++ b/gcc/testsuite/gcc.dg/asan/pr80166.c
> > @@ -1,5 +1,6 @@
> > /* PR sanitizer/80166 */
> > /* { dg-do run } */
> > +/* { dg-additional-options "-Wno-stringop-overflow" } */
> > #include
> > #include
> > --
> > 2.28.0
>
> Jakub
>
Can you backport this to release branches?
Thanks.
--
H.J.
[patch] Fix build when source directory includes @ character
Hi,
Attached is a fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57076
Currently, we cannot build GCC when the source directory contains a @ character
(which is a problem for Homebrew, where we typically build in directories such
as /tmp/gcc@10/src: https://github.com/Homebrew/brew/pull/9007)
The problem is because gcc-vers.texi then contain an unquoted @ character,
which is interpreted as a texinfo command.
The patch fixes the rule in gcc/Makefile.in so that stray @ characters are
quoted as @@
Tested and bootstrapped on x86_64-apple-darwin19
PS: It’s possible the same issue occurs with characters { and } in the path
(according to
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Conventions.html).
Do you think they should be quoted too?
Cheers,
FX
at.diff
Description: Binary data
Re: [PATCH] rs6000, vector integer multiply/divide/modulo instructions
On Fri, Oct 30, 2020 at 4:07 PM Carl Love wrote: > > GCC maintainers: > > The following patch adds new builtins for the vector integer multiply, > divide and modulo operations. The builtins are: > vec_mulh(), vec_div(), vec_dive(), vec_mod() for signed and unsigned > integers and long long integers. Support for signed and unsigned long > long integers the exiting vec_mul() is added. Note that the existing > support for the vec_div()and vec_mul() builtins emulate the vector > operations with multiple scalar instructions. This patch adds support > for these builtins to use the new vector instructions. > > The patch was compiled and tested on: > > powerpc64le-unknown-linux-gnu (Power 9 LE) > > with no regressions. Additionally the new test case was compiled and > executed by hand on Mambo to verify the test case passes. > > Please let me know if this patch is acceptable for mainline. Thanks. > > Carl Love > > - > > 2020-10-30 Carl Love > > gcc/ > * config/rs6000/altivec.h (vec_mulh, vec_div, vec_dive, vec_mod): New > defines. > * config/rs6000/altivec.md (VIlong): Move define to file vector.md. > * config/rs6000/rs6000-builtin.def (VDIVES_V4SI, VDIVES_V2DI, > VDIVEU_V4SI, VDIVEU_V2DI, VDIVS_V4SI, VDIVS_V2DI, VDIVU_V4SI, > VDIVU_V2DI, VMODS_V2DI, VMODS_V4SI, VMODU_V2DI, VMODU_V4SI, > VMULHS_V2DI, > VMULHS_V4SI, VMULHU_V2DI, VMULHU_V4SI, VMULLD_V2DI): Add builtin > define. > (VMUL, VMULH, VDIVE, VMOD): Add new BU_P10_OVERLOAD_2 definitions. > * config/rs6000/rs6000-call.c (VSX_BUILTIN_VEC_DIV, > P10_BUILTIN_VEC_VDIVE, > P10_BUILTIN_VEC_VMOD, P10_BUILTIN_VEC_VMULH): New overloaded > definitions. > (builtin_function_type) > [P10V_BUILTIN_VDIVEU_V4SI, P10V_BUILTIN_VDIVEU_V2DI, > P10V_BUILTIN_VDIVU_V4SI, P10V_BUILTIN_VDIVU_V2DI, > P10V_BUILTIN_VMODU_V2DI, P10V_BUILTIN_VMODU_V4SI, > P10V_BUILTIN_VMULHU_V2DI, > P10V_BUILTIN_VMULHU_V4SI, P10V_BUILTIN_VMULLD_V2DI]: Add case > statement > for builtins. > * config/rs6000/vector.md (UNSPEC_VDIVES, UNSPEC_VDIVEU, > UNSPEC_VMULHS, > UNSPEC_VMULHU, UNSPEC_VMULLD): Add enum for UNSPECs. > (VIlong_char): Add define_mod_attribute. > (vdives_, vdiveu_, vdiv3, uuvdiv3, > vdivs_, > vdivu_, vmods_, vmodu_, vmulhs_, > vmulhu_, > mulv2di3): Add define_insn, mode is VIlong. > config/rs6000/vsx.md (vsx_mul_v2di, vsx_udiv_v2di): Add if > (TARGET_POWER10) > statement. > * doc/extend.texi (vec_mulh, vec_mul, vec_div, vec_dive, vec_mod): Add > builtin descriptions. > --- a/gcc/config/rs6000/vector.md > +++ b/gcc/config/rs6000/vector.md Hi, Carl I thought that vector.md was a transfer vector for the patterns and instructions were defined in vsx.md. Why are the new insn patterns defined in vector.md? > +(define_insn "div3" > + [(set (match_operand:VIlong 0 "vsx_register_operand" "=v") > + (div:VIlong (match_operand:VIlong 1 "vsx_register_operand" "v") > + (match_operand:VIlong 2 "vsx_register_operand" "v")))] > + "TARGET_POWER10" > + "vdivs %0,%1,%2" > + [(set_attr "type" "vecsimple")]) > + > +(define_insn "udiv3" > + [(set (match_operand:VIlong 0 "vsx_register_operand" "=v") > + (udiv:VIlong (match_operand:VIlong 1 "vsx_register_operand" "v") > + (match_operand:VIlong 2 "vsx_register_operand" "v")))] > + "TARGET_POWER10" > + "vdivu %0,%1,%2" > + [(set_attr "type" "vecsimple")]) > + > +(define_insn "vdivs_" > + [(set (match_operand:VIlong 0 "vsx_register_operand" "=v") > + (div:VIlong (match_operand:VIlong 1 "vsx_register_operand" "v") > + (match_operand:VIlong 2 "vsx_register_operand" "v")))] > + "TARGET_POWER10" > + "vdivs %0,%1,%2" > + [(set_attr "type" "vecsimple")]) > + > +(define_insn "vdivu_" > + [(set (match_operand:VIlong 0 "vsx_register_operand" "=v") > + (udiv:VIlong (match_operand:VIlong 1 "vsx_register_operand" "v") > +(match_operand:VIlong 2 "vsx_register_operand" "v")))] > + "TARGET_POWER10" > + "vdivu %0,%1,%2" > + [(set_attr "type" "vecsimple")]) Also, what is the reason to define div3 and udiv3, then repeat the patterns for vdivs_ and vdivu_? Is there a difference between the two patterns that I'm missing? The new builtins should be able to invoke the new named standard patterns. Or we really want an additional set of patterns that match the builtin names? The div3 and udiv3 patterns do not seem to be listed in the ChangeLog. Thanks, David
Re: [PATCH] PowerPC: PR libgcc/97543, build libgcc with -mno-gnu-attribute
Hi Mike, On Wed, Oct 28, 2020 at 08:42:04PM -0400, Michael Meissner via Gcc-patches wrote: > PowerPC: PR libgcc/97543, fix 64-bit long double issues > > There are two issues in PR libgcc/97543 which shows up if you build a GCC > compiler with long double defaulting to 64-bit instead of 128-bit with IBM > extended double: > > 1)The first issue was the t-linux file forced the entire libgcc > library > to be compiled with the -mlong-double-128 option. Why is this is wrong? If you are configuring using --without-long-double-128 then that doesn't mean 128-bit long doubles are unsupported, it just selects the default to be 64-bit long double. A compiler built using --without-long-double-128 can generate code for 128-bit long double by simply using -mlong-double-128. In which case you need the libgcc support for 128-bit long doubles. Well, I suppose you are passing -mlong-double-128 for those objects that need it, but I can't see any harm in passing -mlong-double-128 everywhere in libgcc. It seems to me that *not* using -mlong-double-128 then opens you up to the .gnu_attribute bug where we mark an object as using 64-bit long double when it really is just using plain double. > > 2)The second issue is that the GNU attribute #4 is set to reflect > using > 128-bit long doubles, and you get linker warnings when you use use the > compiler, since libgcc_s.so indicates 128-bit IBM long doubles were > used. I ran into a similar issue with my patches to extend libgcc to > work if long doubles were configured to use the 128-bit IEEE format > instead of the 128-bit IBM format. > > One feature of the current GNU attribute implementation is if you have a > shared > library (such as libgcc_s.so), the GNU attributes for the shared library is an > inclusive OR of all of the modules within the library. We do OR in non-conflicting attributes, but conflicting ones cause errors, or are removed if the linker is given --no-warn-mismatch. For example: cat > attr-ibm.s < attr-64.s < This means if any > module uses the -mlong-double-128 option and uses long double, the GNU > attributes for the library will indicate that it uses 128-bit IBM long > doubles. If you have a static library, you will get the warning only if you > actually reference a module with the attribute set. > > This patch does two things: > > 1)Instead of compiling the whole library with -mlong-double-128, > it only > compiles the modules that process the IBM extended double format with > this switch. It also specifies that these files must be compiled using > the IBM format for long double. > > 2)I turned off GNU attributes for the whole library. Originally, > I just > turned off GNU attributes for just the modules that process IBM > extended format values. But this doesn't work if the compiler defaults > long double to 64-bits. What happens is the logic in rs6000.c that > sets the GNU attribute bits, will set the bits for 64-bit long double > if a normal double (DFmode) is used. So I just turned off the > attributes for the whole library. > > This patch replaces the patch I previously did for IEEE 128-bit to turn off > GNU attributes for just the ibm-ldouble.o module. > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556863.html > > I have tested this by building a compiler on a little endian power9 system > running Linux with long double defaulting to 64-bits using the configure > option: --without-long-double-128, and I verified that the warning no longer > is > generated by the linker. > > I then built a bootstrap compiler, by first building a non-bootstrap version. > With that non-bootstrap compiler, I built versions of the MPC and MPFR. Using > those libraries, and the non-bootstrap compiler as the host compiler, I was > able to do a full bootstrap compiler. > > There are differences in the regression test suite where the test implicitly > assumed long double was 128-bits or was a float128 test. > > Can I install this patch into the master branch? I would also like to install > it in the GCC 10 branch after an appropriate period. > > libgcc/ > 2020-10-28 Michael Meissner > > PR libgcc/97543 > * config/rs6000/t-linux (HOST_LIBGCC2_CFLAGS): Don't set > -mlong-double-128 for all modules. Instead set > -mno-gnu-attributes. > (IBM128_OBJS): New make variable for long double support. > (IBM128_S_OBJS): New make variable for long double support. > (IBM128_ALL_OBJS): New make variable for long double support. > (IBM128_CFLAGS): New make variable for long double support. > --- > libgcc/config/rs6000/t-linux | 18 +- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/libgcc/config/rs6000/t-linux b/libgcc/config/rs6000/t-linux > index ed821947b66..b2a079c6b54 100644 > --- a/libgcc/config/rs6000/t-linux >
[committed] libstdc++: Prefer double to long double in std::shuffle_order_engine
The transition algorithm for std::shuffle_order_engine uses long double
to ensure that the value (max() - min() + 1) can be accurately
represented, to avoid bias in the shuffling. However, when the base
engine's range is small enough we can avoid slower long double
arithmetic by using double. For example, long double is unnecessary for
any base engine returning 32-bit values.
This makes std::knuth_b::operator() about 15% faster on x86_64, and
probably even more on targets where long double uses soft-float.
libstdc++-v3/ChangeLog:
* include/bits/random.h (independent_bit_engine): Fix typo
in comment.
(shuffle_order_engine): Fix incorrect description in comment.
* include/bits/random.tcc (__representable_as_double
(__p1_representable_as_double): New helper functions.
(shuffle_order_engine::operator()): Use double for calculation
if (max() - min() + 1) is representable as double.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
line number.
Tested powerpc64le-linux. Committed to trunk.
commit 60d9f254876a00260992b2f37639ef4d82d9db8f
Author: Jonathan Wakely
Date: Sat Oct 31 07:16:47 2020
libstdc++: Prefer double to long double in std::shuffle_order_engine
The transition algorithm for std::shuffle_order_engine uses long double
to ensure that the value (max() - min() + 1) can be accurately
represented, to avoid bias in the shuffling. However, when the base
engine's range is small enough we can avoid slower long double
arithmetic by using double. For example, long double is unnecessary for
any base engine returning 32-bit values.
This makes std::knuth_b::operator() about 15% faster on x86_64, and
probably even more on targets where long double uses soft-float.
libstdc++-v3/ChangeLog:
* include/bits/random.h (independent_bit_engine): Fix typo
in comment.
(shuffle_order_engine): Fix incorrect description in comment.
* include/bits/random.tcc (__representable_as_double
(__p1_representable_as_double): New helper functions.
(shuffle_order_engine::operator()): Use double for calculation
if (max() - min() + 1) is representable as double.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
line number.
diff --git a/libstdc++-v3/include/bits/random.h
b/libstdc++-v3/include/bits/random.h
index 0be1191e07de..32537f80df72 100644
--- a/libstdc++-v3/include/bits/random.h
+++ b/libstdc++-v3/include/bits/random.h
@@ -1099,7 +1099,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
/**
* Produces random numbers by combining random numbers from some base
- * engine to produce random numbers with a specifies number of bits @p __w.
+ * engine to produce random numbers with a specified number of bits @p __w.
*/
template
class independent_bits_engine
@@ -1316,9 +1316,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
/**
- * @brief Produces random numbers by combining random numbers from some
- * base engine to produce random numbers with a specifies number of bits
- * @p __k.
+ * @brief Produces random numbers by reordering random numbers from some
+ * base engine.
+ *
+ * The values from the base engine are stored in a sequence of size @p __k
+ * and shuffled by an algorithm that depends on those values.
*/
template
class shuffle_order_engine
diff --git a/libstdc++-v3/include/bits/random.tcc
b/libstdc++-v3/include/bits/random.tcc
index bf39a51559bb..3205442f2f69 100644
--- a/libstdc++-v3/include/bits/random.tcc
+++ b/libstdc++-v3/include/bits/random.tcc
@@ -804,13 +804,47 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
constexpr size_t
shuffle_order_engine<_RandomNumberEngine, __k>::table_size;
+ namespace __detail
+ {
+// Determine whether an integer is representable as double.
+template
+ constexpr bool
+ __representable_as_double(_Tp __x) noexcept
+ {
+ static_assert(numeric_limits<_Tp>::is_integer);
+ static_assert(!numeric_limits<_Tp>::is_signed);
+ // All integers <= 2^53 are representable.
+ return (__x <= (1ull << __DBL_MANT_DIG__))
+ // Between 2^53 and 2^54 only even numbers are representable.
+ || (!(__x & 1) && __detail::__representable_as_double(__x >> 1));
+ }
+
+// Determine whether x+1 is representable as double.
+template
+ constexpr bool
+ __p1_representable_as_double(_Tp __x) noexcept
+ {
+ static_assert(numeric_limits<_Tp>::is_integer);
+ static_assert(!numeric_limits<_Tp>::is_signed);
+ return numeric_limits<_Tp>::digits < __DBL_MANT_DIG__
+ || (bool(__x + 1u) // return false if x+1 wraps around to zero
+ && __detail::__representable_as_double(__x + 1u));
+ }
+ }
+
template
typename shuffle_order_engine<_RandomNumberEngine, __k>::result_type
shuffle_order_engi
Re: [PATCH] libstdc++: remove unused variables
Recently merged by 86558afc09e65b172377d4e759b00094dd985e8a. Thanks!
On Mon, 24 Aug 2020 at 13:26, Krystian Kuźniarek <
krystian.kuznia...@gmail.com> wrote:
> Hi,
>
> A description of the problem/bug and how your patch addresses it:
> I've got a small patch for -Wunused-variable in system headers. These
> aren't needed (i.e. no preprocessor conditions are there).
>
> Testcases:
> N/A, it's only a warning.
>
> ChangeLog:
> Sorry, contrib/mklog.py didn't quite work for me.
> For some reason after instruction in line 129: "diff = PatchSet(data)" my
> "diff" variable is always empty.
>
> Bootstrapping and testing:
> Tested that manually by recompling GCC, unfolding all headers with
> `#include ` and compiling what's been included by it.
>
> The patch itself:
> diff --git a/libstdc++-v3/include/tr1/ell_integral.tcc
> b/libstdc++-v3/include/tr1/ell_integral.tcc
> index 3706d8a033a..f3cf12ea2ca 100644
> --- a/libstdc++-v3/include/tr1/ell_integral.tcc
> +++ b/libstdc++-v3/include/tr1/ell_integral.tcc
> @@ -78,9 +78,7 @@ namespace tr1
> __ellint_rf(_Tp __x, _Tp __y, _Tp __z)
> {
>const _Tp __min = std::numeric_limits<_Tp>::min();
> - const _Tp __max = std::numeric_limits<_Tp>::max();
>const _Tp __lolim = _Tp(5) * __min;
> - const _Tp __uplim = __max / _Tp(5);
>
>if (__x < _Tp(0) || __y < _Tp(0) || __z < _Tp(0))
> std::__throw_domain_error(__N("Argument less than zero "
> @@ -319,10 +317,8 @@ namespace tr1
> {
>const _Tp __eps = std::numeric_limits<_Tp>::epsilon();
>const _Tp __errtol = std::pow(__eps / _Tp(8), _Tp(1) / _Tp(6));
> - const _Tp __min = std::numeric_limits<_Tp>::min();
>const _Tp __max = std::numeric_limits<_Tp>::max();
>const _Tp __lolim = _Tp(2) / std::pow(__max, _Tp(2) / _Tp(3));
> - const _Tp __uplim = std::pow(_Tp(0.1L) * __errtol / __min, _Tp(2) /
> _Tp(3));
>
>if (__x < _Tp(0) || __y < _Tp(0))
> std::__throw_domain_error(__N("Argument less than zero "
> @@ -498,9 +494,7 @@ namespace tr1
> __ellint_rc(_Tp __x, _Tp __y)
> {
>const _Tp __min = std::numeric_limits<_Tp>::min();
> - const _Tp __max = std::numeric_limits<_Tp>::max();
>const _Tp __lolim = _Tp(5) * __min;
> - const _Tp __uplim = __max / _Tp(5);
>
>if (__x < _Tp(0) || __y < _Tp(0) || __x + __y < __lolim)
> std::__throw_domain_error(__N("Argument less than zero "
> @@ -569,10 +563,7 @@ namespace tr1
> __ellint_rj(_Tp __x, _Tp __y, _Tp __z, _Tp __p)
> {
>const _Tp __min = std::numeric_limits<_Tp>::min();
> - const _Tp __max = std::numeric_limits<_Tp>::max();
>const _Tp __lolim = std::pow(_Tp(5) * __min, _Tp(1)/_Tp(3));
> - const _Tp __uplim = _Tp(0.3L)
> -* std::pow(_Tp(0.2L) * __max, _Tp(1)/_Tp(3));
>
>if (__x < _Tp(0) || __y < _Tp(0) || __z < _Tp(0))
> std::__throw_domain_error(__N("Argument less than zero "
> @@ -599,8 +590,7 @@ namespace tr1
>const _Tp __eps = std::numeric_limits<_Tp>::epsilon();
>const _Tp __errtol = std::pow(__eps / _Tp(8), _Tp(1) / _Tp(6));
>
> - _Tp __lambda, __mu;
> - _Tp __xndev, __yndev, __zndev, __pndev;
> + _Tp __mu, __xndev, __yndev, __zndev, __pndev;
>
>const unsigned int __max_iter = 100;
>for (unsigned int __iter = 0; __iter < __max_iter; ++__iter)
>
>
> Best regards,
> Krystian
>
Re: [PATCH] libstdc++: remove an ignored qualifier on function return type
Yeah, that's true. Ok, it's not applicable then. Thanks!
On Thu, 29 Oct 2020 at 18:18, Jonathan Wakely wrote:
> On Fri, 28 Aug 2020 at 07:56, Krystian Kuźniarek via Libstdc++
> wrote:
> >
> > > So then you need to produce a changelog entry by hand.
> > I had this problem on some old Ubuntu 18.04. Anyway, here's new
> ChangeLog:
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/std/variant: Fix -Wignored-qualifiers
> > in system headers.
> >
> >
> > >That doesn't test this header at all.
> > It does but indirectly. What I meant by manual test was:
> > ${GCC_GIT} -E contains_only_stdcpp_include.cpp > preprocessed.cpp
> > ${GCC_GIT} -Wall -Wextra -pedantic -fsyntax-only preprocessed.cpp
> > By manipulating GCC_GIT variable to trunk GCC and patched GCC, I checked
> if
> > the warning is gone.
> >
> > >What about the libstdc++ testsuite?
> > I hope you mean calling make bootstrap and make check. If that's ok, I
> > confirm it works on Manjaro and Ubuntu 18.04 with gcc10 and gcc8
> > respectively.
> >
> > >I don't remember exactly why I put it there, but I seem to recall it
> > >was necessary.
> > I don't know your reasons but I can only tell that this patch seems to
> > compile and work just fine.
>
> I see new test failures with that change:
>
> include/variant:1039: error: invalid conversion from
> 'std::enable_if_t (*)(test02()::Visitor&&,
> std::variant&)' {aka 'void (*)(test02()::Visitor&&,
> std::variant&)'} to
> 'std::__detail::__variant::_Multi_array nst void (*)(test02()::Visitor&&, std::variant double>&)>::__untag_result std::variant&)>::element_type' {aka 'const void
> (*)(test02()::Visitor&&, std::variant&)'} [-fpermissive]
> UNRESOLVED: 20_util/variant/visit_r.cc compilation failed to produce
> executable
>
>
> So I still think it's there for a reason.
>
PING^3 [PATCH] Use the section flag 'o' for __patchable_function_entries
On Fri, Oct 23, 2020 at 5:41 AM H.J. Lu wrote: > > On Fri, Oct 2, 2020 at 6:00 AM H.J. Lu wrote: > > > > On Thu, Feb 6, 2020 at 6:57 PM H.J. Lu wrote: > > > > > > This commit in GNU binutils 2.35: > > > > > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=b7d072167715829eed0622616f6ae0182900de3e > > > > > > added the section flag 'o' to .section directive: > > > > > > .section __patchable_function_entries,"awo",@progbits,foo > > > > > > which specifies the symbol name which the section references. Assembler > > > creates a unique __patchable_function_entries section with the section, > > > where foo is defined, as its linked-to section. Linker keeps a section > > > if its linked-to section is kept during garbage collection. > > > > > > This patch checks assembler support for the section flag 'o' and uses > > > it to implement __patchable_function_entries section. Since Solaris may > > > use GNU assembler with Solairs ld. Even if GNU assembler supports the > > > section flag 'o', it doesn't mean that Solairs ld supports it. This > > > feature is disabled for Solairs targets. > > > > > > gcc/ > > > > > > PR middle-end/93195 > > > PR middle-end/93197 > > > * configure.ac (HAVE_GAS_SECTION_LINK_ORDER): New. Define if > > > the assembler supports the section flag 'o' for specifying > > > section with link-order. > > > * dwarf2out.c (output_comdat_type_unit): Pass 0 as flags2 > > > to targetm.asm_out.named_section. > > > * config/sol2.c (solaris_elf_asm_comdat_section): Likewise. > > > * output.h (SECTION2_LINK_ORDER): New. > > > (switch_to_section): Add an unsigned int argument. > > > (default_no_named_section): Likewise. > > > (default_elf_asm_named_section): Likewise. > > > * target.def (asm_out.named_section): Likewise. > > > * targhooks.c (default_print_patchable_function_entry): Pass > > > current_function_decl to get_section and SECTION2_LINK_ORDER > > > to switch_to_section. > > > * varasm.c (default_no_named_section): Add an unsigned int > > > argument. > > > (default_elf_asm_named_section): Add an unsigned int argument, > > > flags2. Use 'o' flag for SECTION2_LINK_ORDER if assembler > > > supports it. > > > (switch_to_section): Add an unsigned int argument and pass it > > > to targetm.asm_out.named_section. > > > (handle_vtv_comdat_section): Pass 0 to > > > targetm.asm_out.named_section. > > > * config.in: Regenerated. > > > * configure: Likewise. > > > * doc/tm.texi: Likewise. > > > > > > gcc/testsuite/ > > > > > > PR middle-end/93195 > > > * g++.dg/pr93195a.C: New test. > > > * g++.dg/pr93195b.C: Likewise. > > > * lib/target-supports.exp > > > (check_effective_target_o_flag_in_section): New proc. > > > > PING > > > > https://gcc.gnu.org/pipermail/gcc-patches/2020-February/539963.html > > PING. > PING. -- H.J.
PING^2 [PATCH] x86: Require MMX for __builtin_ia32_maskmovq
On Fri, Oct 2, 2020 at 6:28 AM H.J. Lu wrote:
>
> On Mon, Sep 21, 2020 at 6:09 AM H.J. Lu wrote:
> >
> > On Mon, Sep 21, 2020 at 5:54 AM H.J. Lu wrote:
> > >
> > > Since "MASKMOVQ mm1, mm2" is an SSE instruction which requires MMX and
> > > MMX/SSE ISAs are handled separately, make __builtin_ia32_maskmovq require
> > > MMX instead of SSE.
> > >
> > > gcc/
> > >
> > > PR target/97140
> > > * config/i386/i386-expand.c (ix86_expand_builtin): Require MMX
> > > for __builtin_ia32_maskmovq.
> > > * config/i386/mmx.md (mmx_maskmovq): Replace TARGET_SSE with
> > > TARGET_MMX.
> > > (*mmx_maskmovq): Likewise.
> > >
> > > gcc/testsuite/
> > >
> > > PR target/97140
> > > * gcc.target/i386/pr97140.c: New test.
> > > ---
> > > gcc/config/i386/i386-expand.c | 6 +-
> > > gcc/config/i386/mmx.md | 4 ++--
> > > gcc/testsuite/gcc.target/i386/pr97140.c | 10 ++
> > > 3 files changed, 17 insertions(+), 3 deletions(-)
> > > create mode 100644 gcc/testsuite/gcc.target/i386/pr97140.c
> > >
> > > diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
> > > index e6f8b314f18..e6285cf592e 100644
> > > --- a/gcc/config/i386/i386-expand.c
> > > +++ b/gcc/config/i386/i386-expand.c
> > > @@ -10982,7 +10982,11 @@ ix86_expand_builtin (tree exp, rtx target, rtx
> > > subtarget,
> > > == (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4))
> > >&& (isa & (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4)) != 0)
> > > isa |= (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4);
> > > - if ((bisa & OPTION_MASK_ISA_MMX) && !TARGET_MMX && TARGET_MMX_WITH_SSE)
> > > + /* NB: __builtin_ia32_maskmovq requires MMX. */
> > > + if (fcode != IX86_BUILTIN_MASKMOVQ
> > > + && (bisa & OPTION_MASK_ISA_MMX)
> > > + && !TARGET_MMX
> > > + && TARGET_MMX_WITH_SSE)
> > > {
> > >bisa &= ~OPTION_MASK_ISA_MMX;
> > >bisa |= OPTION_MASK_ISA_SSE2;
> > > diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
> > > index 7c9640d4f9f..610e4b591f7 100644
> > > --- a/gcc/config/i386/mmx.md
> > > +++ b/gcc/config/i386/mmx.md
> > > @@ -2549,7 +2549,7 @@ (define_expand "mmx_maskmovq"
> > > (match_operand:V8QI 2 "register_operand")
> > > (match_dup 0)]
> > > UNSPEC_MASKMOV))]
> > > - "TARGET_SSE || TARGET_3DNOW_A")
> > > + "TARGET_MMX || TARGET_3DNOW_A")
> > >
> > > (define_insn "*mmx_maskmovq"
> > >[(set (mem:V8QI (match_operand:P 0 "register_operand" "D"))
> > > @@ -2557,7 +2557,7 @@ (define_insn "*mmx_maskmovq"
> > > (match_operand:V8QI 2 "register_operand" "y")
> > > (mem:V8QI (match_dup 0))]
> > > UNSPEC_MASKMOV))]
> > > - "TARGET_SSE || TARGET_3DNOW_A"
> > > + "TARGET_MMX || TARGET_3DNOW_A"
> > >;; @@@ check ordering of operands in intel/nonintel syntax
> > >"maskmovq\t{%2, %1|%1, %2}"
> > >[(set_attr "type" "mmxcvt")
> >
> > Leave mmx.md alone since maskmovq isn't an MMX instruction.
> >
>
> PING:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554385.html
>
PING.
--
H.J.
Re: [PATCH v2] c++: Prevent warnings for value-dependent exprs [PR96742]
Hi Marek,
Marek Polacek via Gcc-patches wrote:
> On Wed, Oct 28, 2020 at 02:46:36PM -0400, Jason Merrill wrote:
>> On 10/28/20 2:00 PM, Marek Polacek wrote:
>>> On Tue, Oct 27, 2020 at 01:36:30PM -0400, Jason Merrill wrote:
On 10/24/20 6:52 PM, Marek Polacek wrote:
> Here, in r11-155, I changed the call to uses_template_parms to
> type_dependent_expression_p_push to avoid a crash in C++98 in
> value_dependent_expression_p on a non-constant expression. But that
> prompted a host of complaints that we now warn for value-dependent
> expressions in templates. Those warnings are technically valid, but
> people still don't want them because they're awkward to avoid. So let's
> partially revert my earlier fix and make sure that we don't ICE in
> value_dependent_expression_p by checking potential_constant_expression
> first.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10?
>
> gcc/cp/ChangeLog:
>
> PR c++/96675
> PR c++/96742
> * pt.c (tsubst_copy_and_build): Call uses_template_parms instead of
> type_dependent_expression_p_push. Only call uses_template_parms
> for expressions that are potential_constant_expression.
>
> gcc/testsuite/ChangeLog:
>
> PR c++/96675
> PR c++/96742
> * g++.dg/warn/Wdiv-by-zero-3.C: Turn dg-warning into dg-bogus.
> * g++.dg/warn/Wtautological-compare3.C: New test.
> * g++.dg/warn/Wtype-limits5.C: New test.
> * g++.old-deja/g++.pt/crash10.C: Remove dg-warning.
> —
>
>>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10?
>>
>> OK.
>
> Thanks,
This regresses Objective-C++ template-4.mm with an ICE (because we don’t have a
check for message_send_expr, which can’t be constexpr).
I am testing the following fix (which is mostly Objective-C-local), but open to
alternate
solutions. Personally, I prefer to avoid double-negatives in code but because
of the
fallthrough to the sorry case, it seems hard to avoid.
OK for master if testing is sucessful?
(I assume we will also need to do the same on 10.x if you backported already)
cheers
Iain
[PATCH] Objective-C++ : Fix ICE in potential_constant_expression_1.
We cannot, as things stand, handle Objective-C tree codes in
the switch and deal with this by calling out to a function that
has a dummy version when Objective-C is not enabled.
Because of the way the logic works (with a fall through to a
'sorry' in case of unhandled expressions), the function reports
cases that are known to be unsuitable for constant exprs. The
dummy function always reports 'false' and thus will fall through
to the 'sorry'.
gcc/c-family/ChangeLog:
* c-objc.h (objc_non_constant_expr_p): New.
* stub-objc.c (objc_non_constant_expr_p): New.
gcc/cp/ChangeLog:
* constexpr.c (potential_constant_expression_1): Handle
expressions known to be non-constant for Objective-C.
gcc/objc/ChangeLog:
* objc-act.c (objc_non_constant_expr_p): New.
---
gcc/c-family/c-objc.h| 1 +
gcc/c-family/stub-objc.c | 6 ++
gcc/cp/constexpr.c | 2 +-
gcc/objc/objc-act.c | 16 +++-
4 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/gcc/c-family/c-objc.h b/gcc/c-family/c-objc.h
index 6025283e5cf..4577e4f1c7f 100644
--- a/gcc/c-family/c-objc.h
+++ b/gcc/c-family/c-objc.h
@@ -101,6 +101,7 @@ extern void objc_add_synthesize_declaration (location_t,
tree);
extern void objc_add_dynamic_declaration (location_t, tree);
extern const char * objc_maybe_printable_name (tree, int);
extern bool objc_is_property_ref (tree);
+extern bool objc_non_constant_expr_p (tree);
extern bool objc_string_ref_type_p (tree);
extern void objc_check_format_arg (tree, tree);
extern void objc_finish_function (void);
diff --git a/gcc/c-family/stub-objc.c b/gcc/c-family/stub-objc.c
index c30f0b3c67d..9ced68b2b3e 100644
--- a/gcc/c-family/stub-objc.c
+++ b/gcc/c-family/stub-objc.c
@@ -331,6 +331,12 @@ objc_is_property_ref (tree ARG_UNUSED (node))
return 0;
}
+bool
+objc_non_constant_expr_p (tree ARG_UNUSED (node))
+{
+ return 0;
+}
+
tree
objc_maybe_build_component_ref (tree ARG_UNUSED (datum), tree ARG_UNUSED
(component))
{
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index b46824f128d..03a826ba250 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -8410,7 +8410,7 @@ potential_constant_expression_1 (tree t, bool want_rval,
bool strict, bool now,
return false;
default:
- if (objc_is_property_ref (t))
+ if (objc_non_constant_expr_p (t))
return false;
sorry ("unexpected AST of kind %s", get_tree_code_name (TREE_CODE (t)));
diff --git a/gcc/objc/objc-act.c b/gcc/objc/objc-act.c
index 0393bc44500..c0d07ae9182 100644
--- a/gcc/objc/objc-act.c
+++ b/gcc/objc/objc-act.c
@@ -1720,7 +1720,6 @@ objc_build_class_component_ref (tree class_name, tree
property_ident)
}
-
/* This is u
Move clone_info to summary
Hi,
this patch moves clone_info to summary.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
2020-10-31 Jan Hubicka
* Makefile.in: (OBJS): Add symtab-clones.o
(GTFILES): Add symtab-clones.h
* cgraph.c: Include symtab-clones.h.
(cgraph_edge::resolve_speculation): Fix formating
(cgraph_edge::redirect_call_stmt_to_callee): Update.
(cgraph_update_edges_for_call_stmt): Update
(release_function_body): Fix formating.
(cgraph_node::remove): Fix formating.
(cgraph_node::dump): Fix formating.
(cgraph_node::get_availability): Fix formating.
(cgraph_node::call_for_symbol_thunks_and_aliases): Fix formating.
(set_const_flag_1): Fix formating.
(set_pure_flag_1): Fix formating.
(cgraph_node::can_remove_if_no_direct_calls_p): Fix formating.
(collect_callers_of_node_1): Fix formating.
(clone_of_p): Update.
(cgraph_node::verify_node): Update.
(cgraph_c_finalize): Call clone_info::release ().
* cgraph.h (struct cgraph_clone_info): Move to symtab-clones.h.
(cgraph_node): Remove clone_info.
(symbol_table): Add m_clones.
* cgraphclones.c: Include symtab-clone.h.
(duplicate_thunk_for_node): Update.
(cgraph_node::create_clone): Update.
(cgraph_node::create_virtual_clone): Update.
(cgraph_node::find_replacement): Update.
(cgraph_node::materialize_clone): Update.
* gengtype.c (open_base_files): Include symtab-clones.h.
* ipa-cp.c: Include symtab-clones.h.
(initialize_node_lattices): Update.
(want_remove_some_param_p): Update.
(create_specialized_node): Update.
* ipa-fnsummary.c: Include symtab-clones.h.
(ipa_fn_summary_t::duplicate): Update.
* ipa-modref.c: Include symtab-clones.h.
(update_signature): Update.
* ipa-param-manipulation.c: Include symtab-clones.h.
(ipa_param_body_adjustments::common_initialization): Update.
* ipa-prop.c: Include symtab-clones.h.
(adjust_agg_replacement_values): Update.
(ipcp_get_parm_bits): Update.
(ipcp_update_bits): Update.
(ipcp_update_vr): Update.
* ipa-sra.c: Include symtab-clones.h.
(process_isra_node_results): Update.
(disable_unavailable_parameters): Update.
* lto-cgraph.c: Include symtab-clone.h.
(output_cgraph_opt_summary_p): Update.
(output_node_opt_summary): Update.
(input_node_opt_summary): Update.
* symtab-clones.cc: New file.
* symtab-clones.h: New file.
* tree-inline.c (expand_call_inline): Update.
(update_clone_info): Update.
(tree_function_versioning): Update.
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 7fc03c8d946..7b94497b6f2 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1299,6 +1299,7 @@ OBJS = \
cfgrtl.o \
symtab.o \
symtab-thunks.o \
+ symtab-clones.o \
cgraph.o \
cgraphbuild.o \
cgraphunit.o \
@@ -2594,6 +2595,7 @@ GTFILES = $(CPPLIB_H) $(srcdir)/input.h
$(srcdir)/coretypes.h \
$(srcdir)/output.h $(srcdir)/cfgloop.h $(srcdir)/cfg.h
$(srcdir)/profile-count.h \
$(srcdir)/cselib.h $(srcdir)/basic-block.h $(srcdir)/ipa-ref.h
$(srcdir)/cgraph.h \
$(srcdir)/symtab-thunks.h $(srcdir)/symtab-thunks.cc \
+ $(srcdir)/symtab-clones.h \
$(srcdir)/reload.h $(srcdir)/caller-save.c $(srcdir)/symtab.c \
$(srcdir)/alias.c $(srcdir)/bitmap.c $(srcdir)/cselib.c $(srcdir)/cgraph.c \
$(srcdir)/ipa-prop.c $(srcdir)/ipa-cp.c $(srcdir)/ipa-utils.h \
diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 9129bcf12d2..9f3a7284310 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -66,6 +66,7 @@ along with GCC; see the file COPYING3. If not see
#include "ipa-inline.h"
#include "tree-nested.h"
#include "symtab-thunks.h"
+#include "symtab-clones.h"
/* FIXME: Only for PROP_loops, but cgraph shouldn't have to know about this.
*/
#include "tree-pass.h"
@@ -1236,7 +1237,7 @@ cgraph_edge::resolve_speculation (cgraph_edge *edge, tree
callee_decl)
{
cgraph_edge *tmp = edge;
if (dump_file)
-fprintf (dump_file, "Speculative call turned into direct call.\n");
+ fprintf (dump_file, "Speculative call turned into direct call.\n");
edge = e2;
e2 = tmp;
/* FIXME: If EDGE is inlined, we should scale up the frequencies
@@ -1488,38 +1489,43 @@ cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge
*e)
return e->call_stmt;
}
}
-
if (flag_checking && decl)
{
cgraph_node *node = cgraph_node::get (decl);
- gcc_assert (!node || !node->clone.param_adjustments);
+ clone_info *info = clone_info::get (node);
+ gcc_assert (!node || !info || !info->param_adjustments);
}
+ clone_info *callee_info = clone_info::get (e->callee);
+ clone_info *caller_info = clone_info::get (e->caller);
+
Handle builtins on local modref, v3
Hi,
this is verion of patch I comitted (so benchmark teters picks it through
weekend). Failure caused by array descriptors are loved.
There is still one pdt_14 failure for which I opened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652
It is a previously latent problem in fortran related to pdt.
Honza
2020-10-31 Jan Hubicka
* ipa-modref.c (modref_summary::dump): Dump writes_errno.
(parm_map_for_arg): Break out from ...
(merge_call_side_effects): ... here.
(get_access_for_fnspec): New function.
(process_fnspec): New function.
(analyze_call): Use it.
(analyze_stmt): Update.
(analyze_function): Initialize writes_errno.
(modref_summaries::duplicate): Duplicate writes_errno.
* ipa-modref.h (struct modref_summary): Add writes_errno.
* tree-ssa-alias.c (call_may_clobber_ref_p_1): Check errno.
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index b903d772c3b..007cebaa3a2 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -59,6 +59,7 @@ along with GCC; see the file COPYING3. If not see
#include "value-range.h"
#include "ipa-prop.h"
#include "ipa-fnsummary.h"
+#include "attr-fnspec.h"
/* Class (from which there is one global instance) that holds modref summaries
for all analyzed functions. */
@@ -318,6 +319,8 @@ modref_summary::dump (FILE *out)
dump_records (loads, out);
fprintf (out, " stores:\n");
dump_records (stores, out);
+ if (writes_errno)
+fprintf (out, " Writes errno\n");
}
/* Dump summary. */
@@ -511,6 +514,43 @@ ignore_stores_p (tree caller, int flags)
return false;
}
+/* Determine parm_map for argument I of STMT. */
+
+modref_parm_map
+parm_map_for_arg (gimple *stmt, int i)
+{
+ tree op = gimple_call_arg (stmt, i);
+ bool offset_known;
+ poly_int64 offset;
+ struct modref_parm_map parm_map;
+
+ offset_known = unadjusted_ptr_and_unit_offset (op, &op, &offset);
+ if (TREE_CODE (op) == SSA_NAME
+ && SSA_NAME_IS_DEFAULT_DEF (op)
+ && TREE_CODE (SSA_NAME_VAR (op)) == PARM_DECL)
+{
+ int index = 0;
+ for (tree t = DECL_ARGUMENTS (current_function_decl);
+ t != SSA_NAME_VAR (op); t = DECL_CHAIN (t))
+ {
+ if (!t)
+ {
+ index = -1;
+ break;
+ }
+ index++;
+ }
+ parm_map.parm_index = index;
+ parm_map.parm_offset_known = offset_known;
+ parm_map.parm_offset = offset;
+}
+ else if (points_to_local_or_readonly_memory_p (op))
+parm_map.parm_index = -2;
+ else
+parm_map.parm_index = -1;
+ return parm_map;
+}
+
/* Merge side effects of call STMT to function with CALLEE_SUMMARY
int CUR_SUMMARY. Return true if something changed.
If IGNORE_STORES is true, do not merge stores. */
@@ -527,37 +567,21 @@ merge_call_side_effects (modref_summary *cur_summary,
fprintf (dump_file, " - Merging side effects of %s with parm map:",
callee_node->dump_name ());
+ /* We can not safely optimize based on summary of callee if it does
+ not always bind to current def: it is possible that memory load
+ was optimized out earlier which may not happen in the interposed
+ variant. */
+ if (!callee_node->binds_to_current_def_p ())
+{
+ if (dump_file)
+ fprintf (dump_file, " - May be interposed: collapsing loads.\n");
+ cur_summary->loads->collapse ();
+}
+
parm_map.safe_grow_cleared (gimple_call_num_args (stmt));
for (unsigned i = 0; i < gimple_call_num_args (stmt); i++)
{
- tree op = gimple_call_arg (stmt, i);
- bool offset_known;
- poly_int64 offset;
-
- offset_known = unadjusted_ptr_and_unit_offset (op, &op, &offset);
- if (TREE_CODE (op) == SSA_NAME
- && SSA_NAME_IS_DEFAULT_DEF (op)
- && TREE_CODE (SSA_NAME_VAR (op)) == PARM_DECL)
- {
- int index = 0;
- for (tree t = DECL_ARGUMENTS (current_function_decl);
- t != SSA_NAME_VAR (op); t = DECL_CHAIN (t))
- {
- if (!t)
- {
- index = -1;
- break;
- }
- index++;
- }
- parm_map[i].parm_index = index;
- parm_map[i].parm_offset_known = offset_known;
- parm_map[i].parm_offset = offset;
- }
- else if (points_to_local_or_readonly_memory_p (op))
- parm_map[i].parm_index = -2;
- else
- parm_map[i].parm_index = -1;
+ parm_map[i] = parm_map_for_arg (stmt, i);
if (dump_file)
{
fprintf (dump_file, " %i", parm_map[i].parm_index);
@@ -575,17 +599,138 @@ merge_call_side_effects (modref_summary *cur_summary,
/* Merge with callee's summary. */
changed |= cur_summary->loads->merge (callee_summary->loads, &parm_map);
if (!ignore_stores)
-changed |= cur_summary->stores->merge (callee_summary->stores,
- &parm_map);
+{
+ changed |= cur_summ
