Re: [PATCH] PR libstdc++/80538 Only call sleep for non-zero values
On 11 October 2018 23:36:15 CEST, Jonathan Wakely wrote: >But I'm assuming that systems with no usleep are probably rare, and >can live with rounding up to sleep for a full second. Well conforming implementations usually won't have usleep which was obscolencent in SUSv3 and removed from SUSv4. As you certainly know we have clock_nanosleep / nanosleep nowadays. thanks,
Re: Relocation (= move+destroy)
On Sun, 2 Sep 2018, Jonathan Wakely wrote:
On 01/09/18 21:56 +0200, Marc Glisse wrote:
On Sat, 1 Sep 2018, Marc Glisse wrote:
this patch passed bootstrap+regtest on powerpc64le-unknown-linux-gnu.
I realized afterwards that for a C++17-only feature, that's not testing
much... So I changed it to apply in C++14 and fixed a minor issue. There is
now a single regression:
23_containers/vector/modifiers/push_back/49836.cc
The PR was about not using assignment for an operation that should only use
construction, and that's fine. But we ended up with a stricter testcase
using CopyConsOnlyType, where the type has a deleted move constructor
which, as far as I understand the standard, makes it an invalid type for
use in vector::push_back. Is that something we want to keep supporting, or
may I break it? What is happening is that
I think you can break it. I'll look back over the history of the test
case, but I don't think supporting deleted moves is intended.
Here is a version where I adapt the test. Bootstrap+testsuite on gcc112.
2018-10-15 Marc Glisse
PR libstdc++/87106
* include/bits/alloc_traits.h (_S_construct, _S_destroy, construct,
destroy): Add noexcept specification.
* include/bits/allocator.h (construct, destroy): Likewise.
* include/ext/alloc_traits.h (construct, destroy): Likewise.
* include/ext/malloc_allocator.h (construct, destroy): Likewise.
* include/ext/new_allocator.h (construct, destroy): Likewise.
* include/bits/stl_uninitialized.h (__relocate, __relocate_a,
__relocate_a_1): New functions.
(__is_trivially_relocatable): New class.
* include/bits/stl_vector.h (__use_relocate): New static member.
* include/bits/vector.tcc (reserve, _M_realloc_insert,
_M_default_append): Use __relocate_a.
(reserve, _M_assign_aux, _M_realloc_insert, _M_fill_insert,
_M_default_append, _M_range_insert): Move _GLIBCXX_ASAN_ANNOTATE_REINIT
after _Destroy.
* testsuite/23_containers/vector/modifiers/push_back/49836.cc:
Replace CopyConsOnlyType with DelAnyAssign.
--
Marc GlisseIndex: libstdc++-v3/include/bits/alloc_traits.h
===
--- libstdc++-v3/include/bits/alloc_traits.h (revision 265131)
+++ libstdc++-v3/include/bits/alloc_traits.h (working copy)
@@ -233,38 +233,43 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
using type = decltype(__test<_Alloc>(0));
};
template
using __has_construct
= typename __construct_helper<_Tp, _Args...>::type;
template
static _Require<__has_construct<_Tp, _Args...>>
_S_construct(_Alloc& __a, _Tp* __p, _Args&&... __args)
+ noexcept(noexcept(__a.construct(__p, std::forward<_Args>(__args)...)))
{ __a.construct(__p, std::forward<_Args>(__args)...); }
template
static
_Require<__and_<__not_<__has_construct<_Tp, _Args...>>,
is_constructible<_Tp, _Args...>>>
_S_construct(_Alloc&, _Tp* __p, _Args&&... __args)
+ noexcept(noexcept(::new((void*)__p)
+ _Tp(std::forward<_Args>(__args)...)))
{ ::new((void*)__p) _Tp(std::forward<_Args>(__args)...); }
template
static auto
_S_destroy(_Alloc2& __a, _Tp* __p, int)
+ noexcept(noexcept(__a.destroy(__p)))
-> decltype(__a.destroy(__p))
{ __a.destroy(__p); }
template
static void
_S_destroy(_Alloc2&, _Tp* __p, ...)
+ noexcept(noexcept(__p->~_Tp()))
{ __p->~_Tp(); }
template
static auto
_S_max_size(_Alloc2& __a, int)
-> decltype(__a.max_size())
{ return __a.max_size(); }
template
static size_type
@@ -333,33 +338,36 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @param __p Pointer to memory of suitable size and alignment for Tp
* @param __args Constructor arguments.
*
* Calls __a.construct(__p, std::forward(__args)...)
* if that expression is well-formed, otherwise uses placement-new
* to construct an object of type @a _Tp at location @a __p from the
* arguments @a __args...
*/
template
static auto construct(_Alloc& __a, _Tp* __p, _Args&&... __args)
+ noexcept(noexcept(_S_construct(__a, __p,
+ std::forward<_Args>(__args)...)))
-> decltype(_S_construct(__a, __p, std::forward<_Args>(__args)...))
{ _S_construct(__a, __p, std::forward<_Args>(__args)...); }
/**
* @brief Destroy an object of type @a _Tp
* @param __a An allocator.
* @param __p Pointer to the object to destroy
*
* Calls @c __a.destroy(__p) if that expression is well-formed,
* otherwise calls @c __p->~_Tp()
*/
template
static void destroy(_Alloc& __a, _Tp* __p)
+ noexcept(noexcept(_S_destroy(__a, __p, 0)))
{ _S_destroy(__a, __p, 0); }
/**
* @brief The maximum supported allocation size
* @param __a An allocator.
* @return @c __a.max_size() or @c numeric_limits::max(
Re: [PATCH] PR libstdc++/80538 Only call sleep for non-zero values
On Sat, 13 Oct 2018 at 08:49, Bernhard Reutner-Fischer wrote: > > On 11 October 2018 23:36:15 CEST, Jonathan Wakely wrote: > > >But I'm assuming that systems with no usleep are probably rare, and > >can live with rounding up to sleep for a full second. > > Well conforming implementations usually won't have usleep which was > obscolencent in SUSv3 and removed from SUSv4. > As you certainly know we have clock_nanosleep / nanosleep nowadays. Yes, of course. We don't even look for usleep unless nanosleep isn't available, so I mean systems with no nanosleep *and* no usleep.
Re: Building with old gcc
On Tue, 9 Oct 2018 at 14:48, Paolo Carlini wrote:
>
> Hi,
>
> On 09/10/18 15:33, Jonathan Wakely wrote:
> > On Tue, 9 Oct 2018 at 14:30, Paul Koning wrote:
> >> I'm trying to build the current code on Linux with GCC 4.3.2 (stock
> >> compiler in Fedora 10 which is my old test system). It fails like this:
> >>
> >> In file included from
> >> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/tree-data-ref.h:27,
> >> from
> >> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/gimple-loop-interchange.cc:44:
> >> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h: In constructor
> >> ‘opt_result::opt_result(bool, opt_problem*)’:
> >> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: class
> >> ‘opt_result’ does not have any field named ‘opt_wrapper’
> >> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: no
> >> matching function for call to ‘opt_wrapper::opt_wrapper()’
> >> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:160: note:
> >> candidates are: opt_wrapper::opt_wrapper(T, opt_problem*) [with T =
> >> bool]
> >> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:147: note:
> >> opt_wrapper::opt_wrapper(const opt_wrapper&)
> >> make[3]: *** [gimple-loop-interchange.o] Error 1
> >>
> >> Is 9.0 supposed to build with a build compiler this old?
> > Yes.
> >
> > GCC 4.3 doesn't define the injected-class-name for the base, so this
> > patch is needed:
> >
> > --- a/gcc/opt-problem.h
> > +++ b/gcc/opt-problem.h
> > @@ -214,7 +214,7 @@ class opt_result : public opt_wrapper
> > /* Private ctor. Instances should be created by the success and failure
> >static member functions. */
> > opt_result (wrapped_t result, opt_problem *problem)
> > - : opt_wrapper (result, problem)
> > + : opt_wrapper (result, problem)
> > {}
> > };
>
> At the end of August my colleague Jose Marchesi fixed another instance
> of the same issue, affecting classes auto_edge_flag and auto_bb_flag. I
> think we can commit this change too as obvious.
Committed as obvious.
commit a40f123115ad44525029a7abe5304b45c0a9d43d
Author: Jonathan Wakely
Date: Sat Oct 13 12:12:00 2018 +0100
Fix compilation failure with C++98 compilers
* opt-problem.h (opt_wrapper): Use template-argument-list when
naming
the base class, because using the injected-class-name was not
clearly
specified until DR 176.
diff --git a/gcc/opt-problem.h b/gcc/opt-problem.h
index 68d7e4a5f7b..55d0ff024f7 100644
--- a/gcc/opt-problem.h
+++ b/gcc/opt-problem.h
@@ -214,7 +214,7 @@ class opt_result : public opt_wrapper
/* Private ctor. Instances should be created by the success and failure
static member functions. */
opt_result (wrapped_t result, opt_problem *problem)
- : opt_wrapper (result, problem)
+ : opt_wrapper (result, problem)
{}
};
Re: [Patch, Fortran] PR87597 - fix off-by-one issue with inline matmul
Hi Tobias,
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O0 scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O1 scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O2 scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O3 -g scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -Os scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
IMO this comes from
! { dg-options "-ffrontend-optimize -fdump-tree-original" }
…
! { dg-final { scan-tree-dump-times "gamma5\[__var_1_do \\* 4 \\+ __var_2_do\]"
1 "optimized" } }
Shouldn’t -fdump-tree-original be -fdump-tree-optimized?
TIA
Dominique
Re: Relocation (= move+destroy)
On 13/10/18 11:07 +0200, Marc Glisse wrote: --- libstdc++-v3/include/bits/alloc_traits.h(revision 265131) +++ libstdc++-v3/include/bits/alloc_traits.h(working copy) @@ -233,38 +233,43 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION using type = decltype(__test<_Alloc>(0)); }; template using __has_construct = typename __construct_helper<_Tp, _Args...>::type; template static _Require<__has_construct<_Tp, _Args...>> _S_construct(_Alloc& __a, _Tp* __p, _Args&&... __args) + noexcept(noexcept(__a.construct(__p, std::forward<_Args>(__args)...))) You could use std::declval<_Args>()... instead of forwarding __args... which would be slightly shorter (and might keep some of the others on a single line). No need to change it unless you want to, either is OK. I'll finish reviewing the rest on Monday.
[PATCH] v2: Run selftests for C++ as well as C
On Fri, 2018-10-12 at 14:17 -0400, David Malcolm wrote: > On Fri, 2018-10-12 at 14:45 -0400, David Malcolm wrote: > > [re this thread "ToT build failure?": > > https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00344.html ] > > > > On Thu, 2017-07-06 at 20:58 +0200, Jakub Jelinek wrote: > > > On Thu, Jul 06, 2017 at 01:45:42PM -0400, David Malcolm wrote: > > > > Given that the previous status quo of the selftests was to > > > > require > > > > the > > > > C frontend, I committed the attached patch (as r250036), under > > > > the > > > > "obvious" rule, retaining the ability to optionally run the > > > > selftests > > > > within the C++ frontend. > > > > > > You should do something similar for how we make check etc.: > > > CHECK_TARGETS = @check_languages@ > > > > > > check: $(CHECK_TARGETS) > > > > > > and then each Make-lang.in defining its check- goal. > > > So similarly to that s-selftest-c++ should be in cp/Make-lang.in > > > and based on the configured languages should include the s- > > > selftest- > > > > > > dependencies. > > > > > > Jakub > > > > Thanks. > > > > I attemped the above, but it required each Make-lang.in to define > > a check- goal, but there are only two that make sense to run > > (those that set LANG_HOOKS_RUN_LANG_SELFTESTS: C and C++). > > > > Rather than add one to every Make-lang.in, I borrowing the "append" > > approach used by "lang_checks", so that only the Make-lang.in files > > that opt-in to having selftests need to do anything, appending > > their s-selftest- to lang_selftests. > > > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > I manually verified that the self-tests were run 6 times: C and > > C++, > > for each of the three stages (each run taking well under a second). > > > > OK for trunk? > > Sorry; I failed to properly check the case Steve ran into back in > July, > and my patch doesn't handle it (all of the Make-lang.in files are > included, regardless of configuration, via LANG_MAKEFRAGS). > > I'm working on an updated patch. > > Dave Here's an updated version; sorry for the earlier noise. This one follows the approach you suggested, adding a SELFTEST_TARGETS built from a configure-supplied selftest_languages. Each Make-lang.in defines a selftest-LANG, which becomes a dependency of "selftest". Almost all of the selftest-LANG are empty, apart from those for c and c++. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. As before, I manually verified that the self-tests were run 6 times: c and c++, for each of the three stages (each run taking well under a second). This time I also verified that it builds successfully without c++ (via: "--enable-languages=c --disable-bootstrap"), for which it just ran the c selftests. OK for trunk? gcc/ChangeLog: * Makefile.in (SELFTEST_TARGETS): New. (selftest) Change from s-selftest-c to $(SELFTEST_TARGETS). (C_SELFTEST_FLAGS, C_SELFTEST_DEPS, s-selftest-c, selftest-c-gdb) (selftest-gdb, selftest-c-valgrind, selftest-valgrind): Move to c/Make-lang.in. (CPP_SELFTEST_FLAGS, CPP_SELFTEST_DEPS, s-selftest-c++) (selftest-c++-gdb, selftest-c++-valgrind): Move to cp/Make-lang.in. * configure: Regenerate. * configure.ac (selftest_languages): New. gcc/brig/ChangeLog: * Make-lang.in (selftest-brig): New. gcc/c/ChangeLog: * Make-lang.in (selftest-c): New. (C_SELFTEST_FLAGS, C_SELFTEST_DEPS, s-selftest-c, selftest-c-gdb) (selftest-gdb, selftest-c-valgrind, selftest-valgrind): Move here from gcc/Makefile.in. gcc/cp/ChangeLog: * Make-lang.in (selftest-c++): New. (CPP_SELFTEST_FLAGS, CPP_SELFTEST_DEPS, s-selftest-c++) (selftest-c++-gdb, selftest-c++-valgrind): Move here from gcc/Makefile.in. gcc/fortran/ChangeLog: * Make-lang.in (selftest-fortran): New. gcc/go/ChangeLog: * Make-lang.in (selftest-go): New. gcc/jit/ChangeLog: * Make-lang.in (selftest-jit): New. gcc/lto/ChangeLog: * Make-lang.in (selftest-lto): New. gcc/objc/ChangeLog: * Make-lang.in (selftest-objc): New. gcc/objcp/ChangeLog: * Make-lang.in (selftest-obj-c++): New. --- gcc/Makefile.in| 52 -- gcc/ada/gcc-interface/Make-lang.in | 3 +++ gcc/brig/Make-lang.in | 3 +++ gcc/c/Make-lang.in | 32 +++ gcc/configure | 12 +++-- gcc/configure.ac | 7 + gcc/cp/Make-lang.in| 26 +++ gcc/fortran/Make-lang.in | 3 +++ gcc/go/Make-lang.in| 3 +++ gcc/jit/Make-lang.in | 3 +++ gcc/lto/Make-lang.in | 3 +++ gcc/objc/Make-lang.in | 3 +++ gcc/objcp/Make-lang.in | 3 +++ 13 files changed, 104 insertions(+), 49 deletions(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 116ed6e..522
Re: Relocation (= move+destroy)
On Sat, 13 Oct 2018, Jonathan Wakely wrote: On 13/10/18 11:07 +0200, Marc Glisse wrote: --- libstdc++-v3/include/bits/alloc_traits.h(revision 265131) +++ libstdc++-v3/include/bits/alloc_traits.h(working copy) @@ -233,38 +233,43 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION using type = decltype(__test<_Alloc>(0)); }; template using __has_construct = typename __construct_helper<_Tp, _Args...>::type; template static _Require<__has_construct<_Tp, _Args...>> _S_construct(_Alloc& __a, _Tp* __p, _Args&&... __args) + noexcept(noexcept(__a.construct(__p, std::forward<_Args>(__args)...))) You could use std::declval<_Args>()... instead of forwarding __args... which would be slightly shorter (and might keep some of the others on a single line). No need to change it unless you want to, either is OK. In order to reduce the risk of bugs, my preference is 1) noexcept(auto): I am amazed that no compiler has implemented it yet, even as a private extension spelled __noexcept_auto or whatever, since it reduces significantly the burden on standard library developers. As a recent example, PR 87538 would never have had a chance to exist. 2) an exact copy-paste of the body of the function. 3) something else only if needed, for instance because 2) misses the conversion to the result type. Of course, since there is more chance *you* will have to maintain that mess, whatever style you find easier to maintain is more important. -- Marc Glisse
Fix ICE during RTL CFI generation pass
This fixes an assertion failure compiling the Ada Web Server package (soap/
soap-message-xml.adb to be precise) at -O2 -gnatn -fPIC on x86/Linux:
+===GNAT BUG DETECTED==+
| Pro 20.0w (20181010-90) (i686-pc-linux-gnu) GCC error: |
| in connect_traces, at dwarf2cfi.c:2825 |
| Error detected around /byram.a/gnatmail/sandbox/gcc-head/x86-linux/ |
| aws_bootstrap-gcc-head/src/src/soap/soap-message-xml.adb:914:8 |
The ICE is extremely elusive and all my attempts at reducing the code failed.
The assertion is meant to check that, if a trace contains an insn that can
throw internally, then the incoming args_size values from preceding traces are
all the same. That's not the case here because cross-jumping commonalized an
insn restoring the stack pointer from the frame pointer, i.e setting args_size
to 0, and redirected a jump to just before the insn. Now, before this insn,
the args_size values need not match, for example if you have on one path a
call whose post-call stack adjustments have not been emitted (because the
stack pointer is restored just after in any case) and on another path a call
whose post-call stack adjustments have been emitted as usual.
So the attached patch relaxes the assertion by allowing the case where an insn
sets the args_size in the current trace before the first insn that can throw
internally. That's OK since DW_CFA_GNU_args_size notes are emitted only on
this first insn or after it, and not at the start of the trace.
Tested on x86/Linux and x86-64/Linux, applied on the mainline.
2018-10-13 Eric Botcazou
* dwarf2cfi.c (struct dw_trace_info): Add args_size_defined_for_eh.
(notice_args_size): Set it in the current trace if no insn that can
throw internally has been seen yet.
(connect_traces): When connecting args_size between traces, allow the
incoming values not to match if there is an insn setting it before the
first insn that can throw internally; in that case, force the creation
of a CFI note on this latter insn.
--
Eric BotcazouIndex: dwarf2cfi.c
===
--- dwarf2cfi.c (revision 264986)
+++ dwarf2cfi.c (working copy)
@@ -147,6 +147,9 @@ struct dw_trace_info
/* True if we've seen different values incoming to beg_true_args_size. */
bool args_size_undefined;
+
+ /* True if we've seen an insn with a REG_ARGS_SIZE note before EH_HEAD. */
+ bool args_size_defined_for_eh;
};
@@ -942,6 +945,9 @@ notice_args_size (rtx_insn *insn)
if (note == NULL)
return;
+ if (!cur_trace->eh_head)
+cur_trace->args_size_defined_for_eh = true;
+
args_size = get_args_size (note);
delta = args_size - cur_trace->end_true_args_size;
if (known_eq (delta, 0))
@@ -2820,11 +2826,17 @@ connect_traces (void)
if (ti->switch_sections)
prev_args_size = 0;
+
if (ti->eh_head == NULL)
continue;
- gcc_assert (!ti->args_size_undefined);
- if (maybe_ne (ti->beg_delay_args_size, prev_args_size))
+ /* We require either the incoming args_size values to match or the
+ presence of an insn setting it before the first EH insn. */
+ gcc_assert (!ti->args_size_undefined || ti->args_size_defined_for_eh);
+
+ /* In the latter case, we force the creation of a CFI note. */
+ if (ti->args_size_undefined
+ || maybe_ne (ti->beg_delay_args_size, prev_args_size))
{
/* ??? Search back to previous CFI note. */
add_cfi_insn = PREV_INSN (ti->eh_head);
Re: [PATCH] PR libstdc++/80538 Only call sleep for non-zero values
On 13 October 2018 12:56:14 CEST, Jonathan Wakely wrote: >Yes, of course. We don't even look for usleep unless nanosleep isn't >available, so I mean systems with no nanosleep *and* no usleep. Right. Wasn't obvious to me from just the patch. Sorry for the noise..
[PATCH] i386: Add register source to movddup
Add register source to movddup so that IRA will allow register source
for *vec_dupv2di when SSE3 is enabled.
gcc/
PR target/87599
* config/i386/sse.md (*vec_dupv2di): Add register source to
movddup.
gcc/testsuite/
PR target/87599
* gcc.target/i386/pr87599.c: New test.
---
gcc/config/i386/sse.md | 2 +-
gcc/testsuite/gcc.target/i386/pr87599.c | 12
2 files changed, 13 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr87599.c
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index af4d80d8c9b..4b2193e0462 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -18185,7 +18185,7 @@
(define_insn "*vec_dupv2di"
[(set (match_operand:V2DI 0 "register_operand" "=x,v,v,x")
(vec_duplicate:V2DI
- (match_operand:DI 1 "nonimmediate_operand" " 0,Yv,m,0")))]
+ (match_operand:DI 1 "nonimmediate_operand" " 0,Yv,vm,0")))]
"TARGET_SSE"
"@
punpcklqdq\t%0, %0
diff --git a/gcc/testsuite/gcc.target/i386/pr87599.c
b/gcc/testsuite/gcc.target/i386/pr87599.c
new file mode 100644
index 000..abbeb7a41af
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr87599.c
@@ -0,0 +1,12 @@
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-options "-march=corei7 -O2" } */
+/* { dg-final { scan-assembler-times "punpcklqdq\[ \\t\]+%xmm\[0-9\],\[
\\t\]+%xmm\[0-9\]" 1 } } */
+
+#include
+
+__m128i
+foo (long long val)
+{
+ __m128i rval = {val, val};
+ return rval;
+}
--
2.17.2
[PATCH] i386: Also disable AVX512IFMA/AVX5124FMAPS/AVX5124VNNIW
Also disable AVX512IFMA, AVX5124FMAPS and AVX5124VNNIW when disabling
AVX512F.
gcc/
PR target/87572
* common/config/i386/i386-common.c (OPTION_MASK_ISA_AVX512F_UNSET):
Add OPTION_MASK_ISA_AVX512IFMA_UNSET,
OPTION_MASK_ISA_AVX5124FMAPS_UNSET and
OPTION_MASK_ISA_AVX5124VNNIW_UNSET.
gcc/testsuite/
PR target/87572
* gcc.target/i386/pr87572.c: New test.
---
gcc/common/config/i386/i386-common.c| 8 ++--
gcc/testsuite/gcc.target/i386/pr87572.c | 10 ++
2 files changed, 16 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr87572.c
diff --git a/gcc/common/config/i386/i386-common.c
b/gcc/common/config/i386/i386-common.c
index 3b5312d7250..36ef999df83 100644
--- a/gcc/common/config/i386/i386-common.c
+++ b/gcc/common/config/i386/i386-common.c
@@ -194,8 +194,12 @@ along with GCC; see the file COPYING3. If not see
(OPTION_MASK_ISA_AVX512F | OPTION_MASK_ISA_AVX512CD_UNSET \
| OPTION_MASK_ISA_AVX512PF_UNSET | OPTION_MASK_ISA_AVX512ER_UNSET \
| OPTION_MASK_ISA_AVX512DQ_UNSET | OPTION_MASK_ISA_AVX512BW_UNSET \
- | OPTION_MASK_ISA_AVX512VL_UNSET | OPTION_MASK_ISA_AVX512VBMI2_UNSET \
- | OPTION_MASK_ISA_AVX512VNNI_UNSET | OPTION_MASK_ISA_AVX512VPOPCNTDQ_UNSET \
+ | OPTION_MASK_ISA_AVX512VL_UNSET | OPTION_MASK_ISA_AVX512IFMA_UNSET \
+ | OPTION_MASK_ISA_AVX5124FMAPS_UNSET \
+ | OPTION_MASK_ISA_AVX5124VNNIW_UNSET \
+ | OPTION_MASK_ISA_AVX512VBMI2_UNSET \
+ | OPTION_MASK_ISA_AVX512VNNI_UNSET \
+ | OPTION_MASK_ISA_AVX512VPOPCNTDQ_UNSET \
| OPTION_MASK_ISA_AVX512BITALG_UNSET)
#define OPTION_MASK_ISA_AVX512CD_UNSET OPTION_MASK_ISA_AVX512CD
#define OPTION_MASK_ISA_AVX512PF_UNSET OPTION_MASK_ISA_AVX512PF
diff --git a/gcc/testsuite/gcc.target/i386/pr87572.c
b/gcc/testsuite/gcc.target/i386/pr87572.c
new file mode 100644
index 000..ea1beb78f5c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr87572.c
@@ -0,0 +1,10 @@
+/* PR target/82483 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -mavx512ifma -mno-sse2 -w -Wno-psabi" } */
+
+typedef long long __m512i __attribute__((__vector_size__(64)));
+__m512i
+foo (__m512i c, __m512i d, __m512i e, int b)
+{
+ return __builtin_ia32_vpmadd52huq512_maskz (c, d, e, b); /* { dg-error
"incompatible types" } */
+}
--
2.17.2
Re: [PATCH] i386: Add register source to movddup
On Sat, 13 Oct 2018, H.J. Lu wrote: > Add register source to movddup so that IRA will allow register source > for *vec_dupv2di when SSE3 is enabled. > > gcc/ > > PR target/87599 > * config/i386/sse.md (*vec_dupv2di): Add register source to > movddup. > > gcc/testsuite/ > > PR target/87599 > * gcc.target/i386/pr87599.c: New test. I doubt this is a correct fix, and I think the issue merits more investigation. Please see comment #5 in the PR. Alexander
Re: [Patch, Fortran] PR87597 - fix off-by-one issue with inline matmul
Hi Dominique,
Dominique d'Humières wrote:
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O0 scan-tree-dump-times optimized
"gamma5[__var_1_do * 4 + __var_2_do]" 1
! { dg-final { scan-tree-dump-times "gamma5\[__var_1_do \\* 4 \\+ __var_2_do\]" 1
"optimized" } }
Shouldn’t -fdump-tree-original be -fdump-tree-optimized?
As it is a front-end optimization (which is explicitly enabled),
-fdump-tree-original should work (and avoids issues with further later
optimizations).
What do you get on your system? Seemingly something else than I do. Can
you look for the gamma5 line in your dump?
Tobias
Re: [Patch, Fortran] PR87597 - fix off-by-one issue with inline matmul
> Le 14 oct. 2018 à 00:43, Tobias Burnus a écrit :
>
> Hi Dominique,
>
> Dominique d'Humières wrote:
>> UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O0 scan-tree-dump-times
>> optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
>>
>> ! { dg-final { scan-tree-dump-times "gamma5\[__var_1_do \\* 4 \\+
>> __var_2_do\]" 1 "optimized" } }
>>
>> Shouldn’t -fdump-tree-original be -fdump-tree-optimized?
>
> As it is a front-end optimization (which is explicitly enabled),
> -fdump-tree-original should work (and avoids issues with further later
> optimizations).
>
> What do you get on your system? Seemingly something else than I do. Can you
> look for the gamma5 line in your dump?
>
> Tobias
Then
! { dg-final { scan-tree-dump-times "gamma5\[__var_1_do \\* 4 \\+ __var_2_do\]"
1 "optimized" } }
should be
! { dg-final { scan-tree-dump-times "gamma5\[__var_1_do \\* 4 \\+ __var_2_do\]"
1 "original" } }
isn’t it?
see https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg01721.html for non darwin
log.
Dominique
Re: [PATCH] add simple attribute introspection
Attached is an updated/enhanced patch with many more tests and the suggested documentation tweak. It also restores the handling of empty attributes that the first revision inadvertently removed from the C parser. The tests are much more comprehensive now but still not exhaustive. I have added warning for the mode attribute that cannot be supported. Enumerator attributes aren't detected in C because they are folded to constants before they reach the built-in, and label attributes aren't handled yet either in C or in C++. Supporting those will take a minor enhancement. I haven only added handful of test cases for x86_64 target attributes, The built-in is not exercised for any other target yet. I don't expect any surprises there. Either it will work or (where the attributes aren't hanging off a node) it will return false. Supporting those will have to wait until the later (I think the best way is to add a callback to struct attribute_spec to let each back end query a node for the properties unique to such attributes analogously to attribute vector_size). I haven't done any work on supporting templates. I would like to but I don't expect to be able to get it done before stage 1 is over (I have another feature I need to finish, the one that prompted this work to begin with). I think the new built-in is quite useful even without template support. I've kept the name __builtin_has_attribute: it is close to the __has_attribute macro, and I think that's fine because the built-in's purpose is very close to that of the macro. Martin On 10/11/2018 08:54 AM, Martin Sebor wrote: On 10/11/2018 06:04 AM, Joseph Myers wrote: On Thu, 11 Oct 2018, Martin Sebor wrote: The attached patch introduces a built-in function called __builtin_has_attribute that makes some of this possible. See the documentation and tests for details. I see nothing in the documentation about handling of equivalent forms of an attribute - for example, specifying __aligned__ in the attribute but aligned in __builtin_has_attribute, or vice versa. I'd expect that to be documented to work (both of those should return true), with associated tests. (And likewise the semantics should allow for a format attribute using printf in one place and __printf__ in the other, for example, or the same constant argument represented with different expressions.) Yes, it occurred to me belatedly that I should add a test for those as well. I can also mention it in the documentation, although I'd have thought it would be implicit in how attributes work in general. (Or are there some differences between the underscored forms and the one without it)? What are the semantics of __builtin_has_attribute for attributes that can't be tested for? (E.g. the mode attribute, which ends up resulting in some existing type with the required mode being used, so there's nothing to indicate the attribute was originally used to declare things.) With a few exceptions (like aligned) the built-in returns false for attributes that aren't attached to a node. I haven't exercised nearly all the attributes yet, and this one could very well be among those that aren't and perhaps can't be handled. I suspect some target attributes might be in the same group. If there's no way to tell it should probably be documented as a limitation of the function, maybe also under the attribute itself that can't be detected. Alternatively, the built-in return type could be changed to a tri-state: "don't know," false, true. Can you think of a better solution? Martin gcc/c/ChangeLog: * c-parser.c (c_parser_has_attribute_expression): New function. (c_parser_attribute): New function. (c_parser_attributes): Move code into c_parser_attribute. (c_parser_unary_expression): Handle RID_HAS_ATTRIBUTE_EXPRESSION. gcc/c-family/ChangeLog: * c-attribs.c (type_for_vector_size): New function. (type_valid_for_vector_size): Same. (handle_vector_size_attribute): Move code to the functions above and call them. (validate_attribute, has_attribute): New functions. * c-common.h (has_attribute): Declare. (rid): Add RID_HAS_ATTRIBUTE_EXPRESSION. * c-common.c (c_common_resword): Same. gcc/cp/ChangeLog: * cp-tree.h (cp_check_const_attributes): Declare. * decl2.c (cp_check_const_attributes): Declare extern. * parser.c (cp_parser_has_attribute_expression): New function. (cp_parser_unary_expression): Handle RID_HAS_ATTRIBUTE_EXPRESSION. (cp_parser_gnu_attribute_list): Add argument. gcc/ChangeLog: * doc/extend.texi (Other Builtins): Add __builtin_has_attribute. gcc/testsuite/ChangeLog: * c-c++-common/builtin-has-attribute-2.c: New test. * c-c++-common/builtin-has-attribute-3.c: New test. * c-c++-common/builtin-has-attribute-4.c: New test. * c-c++-common/builtin-has-attribute.c: New test. * gcc.dg/builtin-has-attribute.c: New test. * gcc/testsuite/gcc.target/i386/builtin-has-attribute.c: New test. diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c index 3a88766..c0a1b
