Re: [PATCH] irange_pool class
On 9/19/20 10:32 PM, Martin Sebor wrote:
On 9/18/20 3:09 PM, Andrew MacLeod wrote:
On 9/18/20 4:35 PM, Martin Sebor wrote:
On 9/18/20 11:36 AM, Andrew MacLeod wrote:
On
it works exactly like one would expect a simple allocator to work..
as long as the allcoator is "live", its allocations are live. once
it is destructed, all the memory it manages is freed.. It purpose
is to avoid having to walk/find everything that was allocated so it
can be freed.
I'll give you the use case from the ranger. in fact, it *is* the
ranger's allocator, exposed for other passes to use.
Ranger uses the allocator to store the live-on-entry ranges for
ssa-names. Each basic block has a vec allocated as needed
which is indexed by ssa-name.
int_range_max is passed to range_on_entry() to go off and find the
range.. when it comes back, it could have 0-255 subranges,. it
doesnt matter.
we call allocate(range) to get a pointer to an efficent copy and
store it in the vector for the ssa name in that block.
If the updater later discovers that the range can be made more
accurate, it checks if the new range fits in the memory allocated
and if it does, simply copies. if it doesnt fit, then it frees the
old hunk, and allocates a new one and stores that.
The ranger creates an allocator when it starts up, and then frees it
when its being destructed. Thats the life of the on-entry cache, so
thats matches the life of the allocator..
I don't understand the proxy comment, or why one would ever want to
copy the allocator itself? or why would you derive from irange? why
cant you just create an allocator when the pass starts, use it when
you need to store a range, and then let it go at the end of the pass
with the other memory?
The int_range template is derived from irange and provides the array
of trees that the irange works with. The pool also provides memory
for iranges and effectively returns objects "derived" from irange
(they're bigger than it is).
What I meant by proxy is a substitute class each of whose objects
stands in for a single instance of int_range where N is
a runtime value. There's no class like that.
[Just to be clear, I don't meant for this discussion to hold up
the patch if you need the pool internally. Anothert class like
the one I propose can be added later if necessary.]
no, but that doesnt serve a lot of purpose either. you can call
allocator.allocate(N) which is effectively that... ?
Yes, but the allocator object isn't always conveniently accessible.
Imagine needing to allocate a dynamically sized irange is in a copy
ctor of some class that's stored in a vec, as the vec is being
resized. The allocator would need to be a global pointer. That's
of course possible but not the most elegant design.
its mean to be a convenient way to get a range allocated to store
via a pointer. nothing more. if you have more complex needs,then
you need to manage those needs. The ranger manages the live on
entry vectors separately from the ranges..
What I'm thinking of is actually more basic than that: an irange
class with a runtime number of subranges, one that can be either
directly stored in a container like vec:
vec
where dynamic_range is such a class, or that can be a member of
a class that's stored in it. I expect that will be the default
use case for the passes that walk the IL looking for the sizes
and offsets into the objects, accesses to which they validate.
This can be done with int_range for constant N but not with
irange because it doesn't own the memory it works with).
To illustrate what I mean here's a completely untested outline
of a plain-Jane dynamic_irange class (it won't compile because
it accesses private and protected members of irange, but it
should give you the idea):
class dynamic_irange: public irange
{
public:
dynamic_irange (unsigned num_pairs)
: irange (new tree[num_pairs], num_pairs) { }
dynamic_irange (const dynamic_irange &rhs)
: irange (new tree[rhs.m_max_ranges], rhs.m_num_ranges)
{ irange::operator= (rhs); }
dynamic_irange (dynamic_irange &&rhs)
: irange (rhs.m_base, rhs.m_max_ranges)
{ rhs.m_base = 0; }
dynamic_irange& operator= (const dynamic_irange &rhs)
{
if (this != &rhs)
{
delete[] m_base;
m_base = new tree[rhs.m_max_ranges];
m_num_ranges = rhs.m_num_ranges;
irange::operator= (rhs);
}
return *this;
}
~dynamic_irange () { delete[] m_base; }
};
A more fancy class would be parameterized on an Allocator policy
that it would allocate memory with, much like C++ standard classes
do. That would let you define an obstack-based allocator class to
use the way you need, as well and any others. (Providing
the allocator as a template argument to just the ctor as opposed
to the whole class itself would make different "instances"
interchangeable for one another.)
Martin
We had a dynamic sized irange, I told
Re: [PATCH] vect/test: Don't check for epilogue loop [PR97075]
Hi Richard,
> "Kewen.Lin" writes:
>> Hi,
>>
>> The commit r11-3230 brings a nice improvement to use full
>> vectors instead of partial vectors when available. But
>> it caused some vector with length test cases to fail on
>> Power.
>>
>> The failure on gcc.target/powerpc/p9-vec-length-epil-7.c
>> exposed one issue that: we call function
>> vect_need_peeling_or_partial_vectors_p in function
>> vect_analyze_loop_2, since it's in analysis phase, for
>> the epilogue loop, we could get the wrong information like
>> LOOP_VINFO_INT_NITERS (loop_vinfo), further get the wrong
>> answer for vect_need_peeling_or_partial_vectors_p.
>> For the epilogue loop in this failure specific, the niter
>> that we get is 58 (should be 1), vf is 2.
>>
>> For epilogue loop with partial vectors, it would use the
>> same VF as the main loop, so it won't be able to use full
>> vector, this patch is to exclude epilogue loop for the
>> check vect_need_peeling_or_partial_vectors_p in
>> vect_analyze_loop_2.
>
> Hmm. For better or worse, I think the analysis phase is actually
> operating on the assumption that the vector code needs to handle
> all scalar iterations, even in the epilogue case. We actually
> rely on that to implement VECT_COMPARE_COSTS (although it wasn't
> the original motivation for handling epilogues this way).
>
> Perhaps we should expand the functionality (and name)
> of determine_peel_for_niter so that it also computes
> LOOP_VINFO_USING_PARTIAL_VECTORS_P. We'd then recompute
> that flag once we know the final epilogue scalar iteration count,
> just like we recompute LOOP_VINFO_PEELING_FOR_NITER.
>
> As a sanity check, I think it would also be good for the
> renamed function to do the following parts of vect_analyze_loop_2:
>
> /* If epilog loop is required because of data accesses with gaps,
> one additional iteration needs to be peeled. Check if there is
> enough iterations for vectorization. */
> if (LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo)
> && LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo)
> && !LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo))
> {
> poly_uint64 vf = LOOP_VINFO_VECT_FACTOR (loop_vinfo);
> tree scalar_niters = LOOP_VINFO_NITERSM1 (loop_vinfo);
>
> if (known_lt (wi::to_widest (scalar_niters), vf))
> return opt_result::failure_at (vect_location,
> "loop has no enough iterations to"
> " support peeling for gaps.\n");
> }
>
> /* If we're vectorizing an epilogue loop, the vectorized loop either needs
> to be able to handle fewer than VF scalars, or needs to have a lower VF
> than the main loop. */
> if (LOOP_VINFO_EPILOGUE_P (loop_vinfo)
> && !LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo)
> && maybe_ge (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
> LOOP_VINFO_VECT_FACTOR (orig_loop_vinfo)))
> return opt_result::failure_at (vect_location,
> "Vectorization factor too high for"
> " epilogue loop.\n");
>
> and then assert that no failure occurs when called for epilogues
> from vect_do_peeling. So the function would be doing three things:
>
> - compute LOOP_VINFO_USING_PARTIAL_VECTORS_P, using the current code
> in vect_analyze_loop_2
>
> - perform the checks quoted above
>
> - what the function currently does
>
> That's all speculation though -- I haven't tried any of this.
>
Thanks for your comments! I'm curious that are your suggestions mainly
for future extension? IIUC, currently if the partial vector usage is 2,
we will have no epilogue loops, if the partial vector usage is 1, the
epilogue loop uses the same VF as the one of the main loop, its total
iterations count is less than VF, it has no chance to use full vector.
It looks to exclude epilogue loops is enough for now.
BR,
Kewen
[committed] wwwdocs: Replace reference to gccupc.org with the new site on Github.
Also shorten some text, call GCC that instead of GNU GCC compiler, and remove some bits and links where there appears no equivalent available on that new site. Pushed. Gerald --- htdocs/frontends.html | 2 +- htdocs/git.html | 2 +- htdocs/projects/gupc.html | 33 +++-- 3 files changed, 9 insertions(+), 28 deletions(-) diff --git a/htdocs/frontends.html b/htdocs/frontends.html index 2d996cbd..bec33b7b 100644 --- a/htdocs/frontends.html +++ b/htdocs/frontends.html @@ -64,7 +64,7 @@ Currently they only support GNU/Linux x86 systems. http://pl1gcc.sourceforge.net/";>PL/1 for GCC is a GCC front end for the PL/I language. -http://www.gccupc.org/";>GCC Unified Parallel C +https://github.com/Intrepid/GUPC";>GCC Unified Parallel C (GCC UPC) is a compilation and execution environment for Unified Parallel C. diff --git a/htdocs/git.html b/htdocs/git.html index 905ce80e..96a921df 100644 --- a/htdocs/git.html +++ b/htdocs/git.html @@ -478,7 +478,7 @@ in Git. high-performance, parallel systems with access to a single potentially large, global shared address space. Further information can be found on the - http://gccupc.org";>GNU UPC web page. + https://github.com/Intrepid/GUPC";>GNU UPC page. pph This branch implements https://gcc.gnu.org/wiki/pph";> Pre-Parsed diff --git a/htdocs/projects/gupc.html b/htdocs/projects/gupc.html index 3b822ca3..0c55c571 100644 --- a/htdocs/projects/gupc.html +++ b/htdocs/projects/gupc.html @@ -16,11 +16,10 @@ The GNU UPC project implements a compilation and execution environment for programs written in the -https://www.gccupc.org";>UPC (Unified Parallel C) language. -The GNU UPC compiler extends the capabilities of the -GNU GCC compiler. The GUPC compiler is -implemented as a C Language dialect translator, in a fashion similar to the -implementation of the GNU Objective C compiler. +https://github.com/Intrepid/GUPC";>UPC (Unified Parallel C) +language. The GNU UPC compiler extends the capabilities of GCC. +The GUPC compiler is implemented as a C Language dialect translator, in +a fashion similar to the implementation of the GNU Objective C compiler. Project Goal @@ -79,29 +78,11 @@ on a platform of interest to you, we recommend that you join the Download -The latest release of GUPC can be downloaded from https://www.gccupc.org/download";>gccupc.org. - - -Alternatively, read-only SVN access to the GUPC branch can be used to -acquire the latest development source tree: - - -svn checkout svn://gcc.gnu.org/svn/gcc/branches/gupc +The https://github.com/Intrepid/GUPC/releases";>latest +release of GUPC is available for download. -Documentation +Alternatively, you can access the GUPC branch in the GCC sources. -For a list of configuration switches that you can use to build GUPC, consult -the GUPC -http://gccupc.org/gnu-upc-info/gnu-upc-install-from-source-code";> -configuration page. - - -For a quick summary of the switches used to compile and link a UPC program, -consult the GUPC -http://gccupc.org/gnu-upc-info/gnu-upc-compile-options";> -manual page. - The GNU UPC Discussion List -- 2.28.0
Re: New modref/ipa_modref optimization passes
On Sun, 2020-09-20 at 00:32 +0200, Jan Hubicka wrote:
> Hi,
> this is cleaned up version of the patch. I removed unfinished bits,
> fixed
> propagation, cleaned it up and fixed fallout.
[...]
> While there are several areas for improvements but I think it is not
> in shape
> for mainline and rest can be dealt with incrementally.
FWIW I think you typoed:
"not in shape for mainline"
when you meant:
"now in shape for mainline"
given...
>
> Bootstrapped/regtested x86_64-linux including ada, d and go. I plan
> to commit
> it after bit more testing tomorrow.
...this, which suggests the opposite meaning.
I didn't look at the guts of the patch, but I spotted some nits.
> 2020-09-19 David Cepelik
> Jan Hubicka
>
> * Makefile.in: Add ipa-modref.c and ipa-modref-tree.c.
> * alias.c: (reference_alias_ptr_type_1): Export.
> * alias.h (reference_alias_ptr_type_1): Declare.
> * common.opt (fipa-modref): New.
> * gengtype.c (open_base_files): Add ipa-modref-tree.h and ipa-
> modref.h
> * ipa-modref-tree.c: New file.
> * ipa-modref-tree.h: New file.
> * ipa-modref.c: New file.
Should new C++ source files have a .cc suffix, rather than .c?
[...]
> + $(srcdir)/ipa-modref.h $(srcdir)/ipa-modref.c \
...which would affect this^
[...]
> diff --git a/gcc/ipa-modref-tree.c b/gcc/ipa-modref-tree.c
> new file mode 100644
> index 000..e37dee67fa3
> --- /dev/null
> +++ b/gcc/ipa-modref-tree.c
[...]
> +#if CHECKING_P
> +
> +
> +static void
> +test_insert_search_collapse ()
> +{
[...]
> +}
> +
> +static void
> +test_merge ()
> +{
[...]
> +}
> +
> +
> +void
> +modref_tree_c_tests ()
> +{
> + test_insert_search_collapse ();
> + test_merge ();
> +}
> +
> +#endif
It looks like these tests aren't being called anywhere; should they be?
The convention is to put such tests inside namespace selftest and to
call the "run all the tests in this file" function from
selftest::run_tests.
If you change this to be a .cc file, then the _c_ in the function name
should become a _cc_.
[...]
> diff --git a/gcc/ipa-modref-tree.h b/gcc/ipa-modref-tree.h
> new file mode 100644
> index 000..3bdd3058aa1
> --- /dev/null
> +++ b/gcc/ipa-modref-tree.h
[...]
> +void modref_c_tests ();
Likewise here; the convention is to declare these within
selftest.h
[...]
Hope this is constructive
Dave
[r11-3308 Regression] FAIL: gcc.target/i386/avx-vandnps-1.c execution test on Linux/x86_64 (-m64 -march=cascadelake)
On Linux/x86_64,
d119f34c952f8718fdbabc63e2f369a16e92fa07 is the first bad commit
commit d119f34c952f8718fdbabc63e2f369a16e92fa07
Author: Jan Hubicka
Date: Sun Sep 20 07:25:16 2020 +0200
New modref/ipa_modref optimization passes
caused
FAIL: gcc.target/i386/avx-vandnps-1.c execution test
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-3308/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx-vandnps-1.c
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
[r11-3308 Regression] FAIL: gcc.target/i386/sse2-andnpd-1.c execution test on Linux/x86_64 (-m64 -march=cascadelake)
On Linux/x86_64,
d119f34c952f8718fdbabc63e2f369a16e92fa07 is the first bad commit
commit d119f34c952f8718fdbabc63e2f369a16e92fa07
Author: Jan Hubicka
Date: Sun Sep 20 07:25:16 2020 +0200
New modref/ipa_modref optimization passes
caused
FAIL: gcc.target/i386/sse2-andnpd-1.c execution test
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-3308/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/sse2-andnpd-1.c
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
[r11-3308 Regression] FAIL: gcc.target/i386/sse-andnps-1.c execution test on Linux/x86_64 (-m64 -march=cascadelake)
On Linux/x86_64,
d119f34c952f8718fdbabc63e2f369a16e92fa07 is the first bad commit
commit d119f34c952f8718fdbabc63e2f369a16e92fa07
Author: Jan Hubicka
Date: Sun Sep 20 07:25:16 2020 +0200
New modref/ipa_modref optimization passes
caused
FAIL: gcc.target/i386/sse-andnps-1.c execution test
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-3308/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/sse-andnps-1.c
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
[r11-3308 Regression] FAIL: gfortran.dg/assumed_type_9.f90 -Os execution test on Linux/x86_64 (-m64 -march=cascadelake)
On Linux/x86_64,
d119f34c952f8718fdbabc63e2f369a16e92fa07 is the first bad commit
commit d119f34c952f8718fdbabc63e2f369a16e92fa07
Author: Jan Hubicka
Date: Sun Sep 20 07:25:16 2020 +0200
New modref/ipa_modref optimization passes
caused
FAIL: gfortran.dg/assumed_type_9.f90 -O2 execution test
FAIL: gfortran.dg/assumed_type_9.f90 -Os execution test
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-3308/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=gfortran.dg/assumed_type_9.f90 --target_board='unix{-m64\
-march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
[r11-3308 Regression] FAIL: gcc.target/i386/avx-vandnpd-1.c execution test on Linux/x86_64 (-m64 -march=cascadelake)
On Linux/x86_64,
d119f34c952f8718fdbabc63e2f369a16e92fa07 is the first bad commit
commit d119f34c952f8718fdbabc63e2f369a16e92fa07
Author: Jan Hubicka
Date: Sun Sep 20 07:25:16 2020 +0200
New modref/ipa_modref optimization passes
caused
FAIL: gcc.target/i386/avx-vandnpd-1.c execution test
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-3308/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx-vandnpd-1.c
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
Re: New modref/ipa_modref optimization passes
> On Sun, 2020-09-20 at 00:32 +0200, Jan Hubicka wrote:
> > Hi,
> > this is cleaned up version of the patch. I removed unfinished bits,
> > fixed
> > propagation, cleaned it up and fixed fallout.
>
> [...]
>
> > While there are several areas for improvements but I think it is not
> > in shape
> > for mainline and rest can be dealt with incrementally.
>
> FWIW I think you typoed:
> "not in shape for mainline"
> when you meant:
> "now in shape for mainline"
> given...
Yep, sorry for that :)
>
> Should new C++ source files have a .cc suffix, rather than .c?
>
> [...]
>
> > + $(srcdir)/ipa-modref.h $(srcdir)/ipa-modref.c \
>
> ...which would affect this^
I was wondering about that and decided to stay with .c since it is what
other ipa passes use. I can rename the files. We have some sources with
.c extension and others with .cc while they are now all C++. Is there
some plan to clean it up?
> > +void
> > +modref_tree_c_tests ()
> > +{
> > + test_insert_search_collapse ();
> > + test_merge ();
> > +}
> > +
> > +#endif
>
> It looks like these tests aren't being called anywhere; should they be?
>
> The convention is to put such tests inside namespace selftest and to
> call the "run all the tests in this file" function from
> selftest::run_tests.
>
> If you change this to be a .cc file, then the _c_ in the function name
> should become a _cc_.
>
> [...]
>
> > diff --git a/gcc/ipa-modref-tree.h b/gcc/ipa-modref-tree.h
> > new file mode 100644
> > index 000..3bdd3058aa1
> > --- /dev/null
> > +++ b/gcc/ipa-modref-tree.h
>
> [...]
>
> > +void modref_c_tests ();
>
> Likewise here; the convention is to declare these within
> selftest.h
>
> [...]
Thanks, indeed is seems that the self tests code was dropped at some
point which I did not noticed. I will fix that up.
>
> Hope this is constructive
It is :)
Honza
> Dave
>
[r11-3308 Regression] FAIL: gfortran.dg/assumed_type_9.f90 -Os execution test on Linux/x86_64 (-m64)
On Linux/x86_64,
d119f34c952f8718fdbabc63e2f369a16e92fa07 is the first bad commit
commit d119f34c952f8718fdbabc63e2f369a16e92fa07
Author: Jan Hubicka
Date: Sun Sep 20 07:25:16 2020 +0200
New modref/ipa_modref optimization passes
caused
FAIL: gfortran.dg/assumed_type_9.f90 -O2 execution test
FAIL: gfortran.dg/assumed_type_9.f90 -Os execution test
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-3308/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=gfortran.dg/assumed_type_9.f90 --target_board='unix{-m64}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
[r11-3308 Regression] FAIL: gcc.target/i386/sse-andnps-1.c execution test on Linux/x86_64 (-m64)
On Linux/x86_64,
d119f34c952f8718fdbabc63e2f369a16e92fa07 is the first bad commit
commit d119f34c952f8718fdbabc63e2f369a16e92fa07
Author: Jan Hubicka
Date: Sun Sep 20 07:25:16 2020 +0200
New modref/ipa_modref optimization passes
caused
FAIL: gcc.target/i386/sse-andnps-1.c execution test
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-3308/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/sse-andnps-1.c
--target_board='unix{-m64}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
[r11-3308 Regression] FAIL: gcc.target/i386/sse2-andnpd-1.c execution test on Linux/x86_64 (-m64)
On Linux/x86_64,
d119f34c952f8718fdbabc63e2f369a16e92fa07 is the first bad commit
commit d119f34c952f8718fdbabc63e2f369a16e92fa07
Author: Jan Hubicka
Date: Sun Sep 20 07:25:16 2020 +0200
New modref/ipa_modref optimization passes
caused
FAIL: gcc.target/i386/sse2-andnpd-1.c execution test
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-3308/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/sse2-andnpd-1.c
--target_board='unix{-m64}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
*PING* [PATCH] PR fortran/90903 [part2] Add runtime checking for the MVBITS intrinsic
*ping* > Gesendet: Sonntag, 13. September 2020 um 23:24 Uhr > Von: "Harald Anlauf" > An: "fortran" , "gcc-patches" > Cc: "Paul Richard Thomas" > Betreff: [PATCH] PR fortran/90903 [part2] Add runtime checking for the MVBITS > intrinsic > > Dear all, > > finally here comes the second part of runtime checks for the bit > manipulation intrinsics, this time MVBITS. This turned out to be > more elaborate than the treatment of simple function calls. > > I chose the path to inline expand MVBITS, which enables additional > optimization opportunities in some cases, such as constant arguments. > For the case of scalar arguments, this was mostly straightforward. > However, for the proper handling of MVBITS as an elemental procedure > all honors should go to Paul, as he not only lend me a hand and kindly > guided me through the swampland of the scalarizer, but he also managed > to placate the gimple part of gcc. > > Regtested on x86_64-pc-linux-gnu. > > OK for master? > > Thanks, > Harald > > > PR fortran/90903 [part2] - Add runtime checking for the MVBITS intrinsic > > Implement inline expansion of the intrinsic elemental subroutine MVBITS > with optional runtime checks for valid argument range. > > gcc/fortran/ChangeLog: > > * iresolve.c (gfc_resolve_mvbits): Remove unneeded conversion of > FROMPOS, LEN and TOPOS arguments to fit a C int. > * trans-intrinsic.c (gfc_conv_intrinsic_mvbits): Add inline > expansion of MVBITS intrinsic elemental subroutine and add code > for runtime argument checking. > (gfc_conv_intrinsic_subroutine): Recognise MVBITS intrinsic, but > defer handling to gfc_trans_call. > * trans-stmt.c (replace_ss): > (gfc_trans_call): Adjust to handle inline expansion, scalarization > of intrinsic subroutine MVBITS in gfc_conv_intrinsic_mvbits. > * trans.h (gfc_conv_intrinsic_mvbits): Add prototype for > gfc_conv_intrinsic_mvbits. > > gcc/testsuite/ChangeLog: > > * gfortran.dg/check_bits_2.f90: New test. > > Co-authored-by: Paul Thomas > >
[pushed] c++: Add test for PR90199.
Fixed by r11-2998, which fixed this ICE too.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/90199
* g++.dg/cpp1y/constexpr-90199.C: New test.
---
gcc/testsuite/g++.dg/cpp1y/constexpr-90199.C | 28
1 file changed, 28 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-90199.C
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-90199.C
b/gcc/testsuite/g++.dg/cpp1y/constexpr-90199.C
new file mode 100644
index 000..0e3f2be08d3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-90199.C
@@ -0,0 +1,28 @@
+// PR c++/90199
+// { dg-do compile { target c++14 } }
+// { dg-additional-options "-frounding-math" }
+
+template
+class complex;
+
+template constexpr complex
+operator+ (complex hd, complex qc)
+{
+ hd += qc;
+ return hd;
+}
+
+template <>
+class complex {
+public:
+ constexpr complex
+ operator+= (complex rm)
+ {
+jp += rm.jp;
+return *this;
+ }
+
+ _Complex float jp;
+};
+
+constexpr complex fl{3.3}, ka{1.1}, r0 = fl + ka;
base-commit: 9044db88d634c631920eaa9f66c0275adf18fdf5
--
2.26.2
[PATCH] hppa: Fix linkage with -nodefaultlibs option
This change fixes the spec file handling for -nodefaultlibs on hppa. This
fixes the testsuite fails for
g++.dg/abi/pure-virtual1.C. It moves the necessary library additions to
ENDFILE_SPEC defines.
On hppa64-hpux, we need to link against libgcc_stub.a in final executables
whenever the user requires
start files. The milli.a library normally should always be added with GNU ld
but we don't have a way
to do that anymore. So, we now add it when we need start files. HP ld adds it
automatically.
On hppa-linux, we need to link against libgcc.a whenever start files are needed
to provide $$dyncall
and __canonicalize_funcptr_for_compare. These are used in the start files.
Tested on hppa64-hp-hpux11.11 and hppa-unknown-linux-gnu with no observed
regressions.
Committed to trunk and gcc-10.
Dave
diff --git a/gcc/config/pa/pa-hpux11.h b/gcc/config/pa/pa-hpux11.h
index 794bf8e2964..28207202e42 100644
--- a/gcc/config/pa/pa-hpux11.h
+++ b/gcc/config/pa/pa-hpux11.h
@@ -154,11 +154,6 @@ along with GCC; see the file COPYING3. If not see
%{!mt:%{!pthread:-a shared -lc -a archive\
%{shared:%{mt|pthread:-lpthread}}"
-/* The libgcc_stub.a library needs to come last. */
-#undef LINK_GCC_C_SEQUENCE_SPEC
-#define LINK_GCC_C_SEQUENCE_SPEC \
- "%G %{!nolibc:%L} %G %{!nostdlib:%{!nodefaultlibs:%{!shared:-lgcc_stub}}}"
-
#undef STARTFILE_SPEC
#define STARTFILE_SPEC \
"%{!shared:%{pg:gcrt0%O%s}%{!pg:%{p:mcrt0%O%s}%{!p:crt0%O%s}} \
diff --git a/gcc/config/pa/pa32-linux.h b/gcc/config/pa/pa32-linux.h
index f271bbf51a2..970722ad528 100644
--- a/gcc/config/pa/pa32-linux.h
+++ b/gcc/config/pa/pa32-linux.h
@@ -57,6 +57,11 @@ call_ ## FUNC (void) \
}
#endif
+/* We need to link against libgcc.a for __canonicalize_funcptr_for_compare
+ and $$dyncall. */
+#undef ENDFILE_SPEC
+#define ENDFILE_SPEC GNU_USER_TARGET_ENDFILE_SPEC "libgcc.a%s"
+
#undef WCHAR_TYPE
#define WCHAR_TYPE "long int"
diff --git a/gcc/config/pa/pa64-hpux.h b/gcc/config/pa/pa64-hpux.h
index c7d127f76ac..096aa4bd4ee 100644
--- a/gcc/config/pa/pa64-hpux.h
+++ b/gcc/config/pa/pa64-hpux.h
@@ -103,12 +103,6 @@ along with GCC; see the file COPYING3. If not see
%{shared:%{mt|pthread:-lpthread}}"
#endif
-/* The libgcc_stub.a and milli.a libraries need to come last. */
-#undef LINK_GCC_C_SEQUENCE_SPEC
-#define LINK_GCC_C_SEQUENCE_SPEC "\
- %G %{!nolibc:%L} %G %{!nostdlib:%{!nodefaultlibs:%{!shared:-lgcc_stub}\
- milli.a%s}}"
-
/* Under hpux11, the normal location of the `ld' and `as' programs is the
/usr/ccs/bin directory. */
@@ -335,8 +329,12 @@ do {
\
%{static:crtbeginT%O%s} %{!static:%{!shared:crtbegin%O%s} \
%{shared:crtbeginS%O%s}}"
#endif
+
+/* The libgcc_stub.a and milli.a libraries must come last. We need
+ to link with these libraries whenever start files are needed. */
#undef ENDFILE_SPEC
-#define ENDFILE_SPEC "%{!shared:crtend%O%s} %{shared:crtendS%O%s}"
+#define ENDFILE_SPEC \
+ "%{!shared:crtend%O%s libgcc_stub.a%s} %{shared:crtendS%O%s} milli.a%s"
/* Since HP uses the .init and .fini sections for array initializers
and finalizers, we need different defines for INIT_SECTION_ASM_OP
Re: *PING* [PATCH] PR fortran/90903 [part2] Add runtime checking for the MVBITS intrinsic
Harold, Looks good. Thanks for the work! Jerry On 9/20/20 11:10 AM, Harald Anlauf wrote: *ping* Gesendet: Sonntag, 13. September 2020 um 23:24 Uhr Von: "Harald Anlauf" An: "fortran" , "gcc-patches" Cc: "Paul Richard Thomas" Betreff: [PATCH] PR fortran/90903 [part2] Add runtime checking for the MVBITS intrinsic Dear all, finally here comes the second part of runtime checks for the bit manipulation intrinsics, this time MVBITS. This turned out to be more elaborate than the treatment of simple function calls. I chose the path to inline expand MVBITS, which enables additional optimization opportunities in some cases, such as constant arguments. For the case of scalar arguments, this was mostly straightforward. However, for the proper handling of MVBITS as an elemental procedure all honors should go to Paul, as he not only lend me a hand and kindly guided me through the swampland of the scalarizer, but he also managed to placate the gimple part of gcc. Regtested on x86_64-pc-linux-gnu. OK for master? Thanks, Harald PR fortran/90903 [part2] - Add runtime checking for the MVBITS intrinsic Implement inline expansion of the intrinsic elemental subroutine MVBITS with optional runtime checks for valid argument range. gcc/fortran/ChangeLog: * iresolve.c (gfc_resolve_mvbits): Remove unneeded conversion of FROMPOS, LEN and TOPOS arguments to fit a C int. * trans-intrinsic.c (gfc_conv_intrinsic_mvbits): Add inline expansion of MVBITS intrinsic elemental subroutine and add code for runtime argument checking. (gfc_conv_intrinsic_subroutine): Recognise MVBITS intrinsic, but defer handling to gfc_trans_call. * trans-stmt.c (replace_ss): (gfc_trans_call): Adjust to handle inline expansion, scalarization of intrinsic subroutine MVBITS in gfc_conv_intrinsic_mvbits. * trans.h (gfc_conv_intrinsic_mvbits): Add prototype for gfc_conv_intrinsic_mvbits. gcc/testsuite/ChangeLog: * gfortran.dg/check_bits_2.f90: New test. Co-authored-by: Paul Thomas
[PATCH] c: Fix -Wduplicated-branches ICE [PR97125]
We crash here because since r11-3302 the C FE uses codes like SWITCH_STMT
in the else branches in the attached test, and inchash::add_expr in
do_warn_duplicated_branches doesn't handle these front-end codes. In
the C++ FE this works because by the time we get to do_warn_duplicated_branches
we've already cp_genericize'd the SWITCH_STMT tree into a SWITCH_EXPR.
The fix is to call do_warn_duplicated_branches_r only after loops and other
structured control constructs have been lowered.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/c-family/ChangeLog:
PR c/97125
* c-gimplify.c (c_genericize): Only call do_warn_duplicated_branches_r
after loops and other structured control constructs have been lowered.
gcc/testsuite/ChangeLog:
PR c/97125
* c-c++-common/Wduplicated-branches-15.c: New test.
---
gcc/c-family/c-gimplify.c | 8 ++---
.../c-c++-common/Wduplicated-branches-15.c| 32 +++
2 files changed, 36 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/c-c++-common/Wduplicated-branches-15.c
diff --git a/gcc/c-family/c-gimplify.c b/gcc/c-family/c-gimplify.c
index 8b326c99d48..d1e391590dd 100644
--- a/gcc/c-family/c-gimplify.c
+++ b/gcc/c-family/c-gimplify.c
@@ -533,10 +533,6 @@ c_genericize (tree fndecl)
&pset);
}
- if (warn_duplicated_branches)
-walk_tree_without_duplicates (&DECL_SAVED_TREE (fndecl),
- do_warn_duplicated_branches_r, NULL);
-
/* Genericize loops and other structured control constructs. The C++
front end has already done this in lang-specific code. */
if (!c_dialect_cxx ())
@@ -550,6 +546,10 @@ c_genericize (tree fndecl)
pop_cfun ();
}
+ if (warn_duplicated_branches)
+walk_tree_without_duplicates (&DECL_SAVED_TREE (fndecl),
+ do_warn_duplicated_branches_r, NULL);
+
/* Dump the C-specific tree IR. */
dump_orig = get_dump_info (TDI_original, &local_dump_flags);
if (dump_orig)
diff --git a/gcc/testsuite/c-c++-common/Wduplicated-branches-15.c
b/gcc/testsuite/c-c++-common/Wduplicated-branches-15.c
new file mode 100644
index 000..d4943607086
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Wduplicated-branches-15.c
@@ -0,0 +1,32 @@
+/* PR c/97125 */
+/* { dg-do compile } */
+/* { dg-options "-Wduplicated-branches" } */
+
+void foo (void);
+
+void
+fn1 (void)
+{
+ if (0)
+foo ();
+ else
+switch (0);
+}
+
+void
+fn2 (void)
+{
+ if (0)
+foo ();
+ else
+while (0);
+}
+
+void
+fn3 (void)
+{
+ if (0)
+foo ();
+ else
+for (;;);
+}
base-commit: 363e7755f227656684c8e284307ceee451503ca4
--
2.26.2
[committed] libstdc++: Fix noexcept-specifier for std::bind_front [PR 97101]
libstdc++-v3/ChangeLog:
PR libstdc++/97101
* include/std/functional (bind_front): Fix order of parameters
in is_nothrow_constructible_v specialization.
* testsuite/20_util/function_objects/bind_front/97101.cc: New test.
Tested powerpc64le-linux. Committed to trunk.
This should be backported to gcc-9 and gcc-10 too.
commit 3c755b428e188228d0bad90625c995fd25a02322
Author: Jonathan Wakely
Date: Mon Sep 21 00:17:02 2020
libstdc++: Fix noexcept-specifier for std::bind_front [PR 97101]
libstdc++-v3/ChangeLog:
PR libstdc++/97101
* include/std/functional (bind_front): Fix order of parameters
in is_nothrow_constructible_v specialization.
* testsuite/20_util/function_objects/bind_front/97101.cc: New test.
diff --git a/libstdc++-v3/include/std/functional
b/libstdc++-v3/include/std/functional
index 124bdadd4c7..407b93f3eb7 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -905,8 +905,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template
constexpr _Bind_front_t<_Fn, _Args...>
bind_front(_Fn&& __fn, _Args&&... __args)
-noexcept(is_nothrow_constructible_v,
- _Fn, _Args...>)
+noexcept(is_nothrow_constructible_v<_Bind_front_t<_Fn, _Args...>,
+ int, _Fn, _Args...>)
{
return _Bind_front_t<_Fn, _Args...>(0, std::forward<_Fn>(__fn),
std::forward<_Args>(__args)...);
diff --git
a/libstdc++-v3/testsuite/20_util/function_objects/bind_front/97101.cc
b/libstdc++-v3/testsuite/20_util/function_objects/bind_front/97101.cc
new file mode 100644
index 000..b159eb02591
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/function_objects/bind_front/97101.cc
@@ -0,0 +1,41 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: New modref/ipa_modref optimization passes
On Sun, 2020-09-20 at 19:30 +0200, Jan Hubicka wrote: > > [...] > > Should new C++ source files have a .cc suffix, rather than .c? > > > > [...] > > > > > + $(srcdir)/ipa-modref.h $(srcdir)/ipa-modref.c \ > > > > ...which would affect this^ > > I was wondering about that and decided to stay with .c since it is > what > other ipa passes use. I can rename the files. Given that they're in the source tree now, maybe better to wait until some mass renaming in the future? > We have some sources with > .c extension and others with .cc while they are now all C++. Is there > some plan to clean it up? I think we've been avoiding it, partly out of a concern of making backports harder, and also because someone has to do the work. That said, it's yet another unfinished transition, and is technical debt for the project. It's confusing to newcomers. It's been bugging me for a while, so I might take a look at doing it in this cycle. Dave
Re: [PATCH] c++: Implement -Wctad-maybe-unsupported.
On 9/19/20 5:34 PM, Marek Polacek wrote:
I noticed that clang++ has this CTAD warning and thought that it might
be useful to have it. From clang++: "Some style guides want to allow
using CTAD only on types that "opt-in"; i.e. on types that are designed
to support it and not just types that *happen* to work with it."
That's a weird name for the warning, but I guess if that's what clang
calls it then we shouldn't change it.
So this warning warns when CTAD deduced a type, but the type does not
define any deduction guides. In that case CTAD worked only because the
compiler synthesized the implicit deduction guides. That might not be
intended.
It can be suppressed by adding a deduction guide that will never be
considered:
struct allow_ctad_t;
template struct S { S(T) {} };
S(allow_ctad_t) -> S;
This warning is off by default.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/c-family/ChangeLog:
* c.opt (Wctad-maybe-unsupported): New option.
gcc/cp/ChangeLog:
* pt.c (deduction_guides_for): Add a bool parameter. Set it.
(do_class_deduction): Warn when CTAD succeeds but the type doesn't
have any explicit deduction guides.
gcc/ChangeLog:
* doc/invoke.texi: Document -Wctad-maybe-unsupported.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wctad-maybe-unsupported.C: New test.
---
gcc/c-family/c.opt| 5 ++
gcc/cp/pt.c | 22 -
gcc/doc/invoke.texi | 20 -
.../g++.dg/warn/Wctad-maybe-unsupported.C | 88 +++
4 files changed, 130 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wctad-maybe-unsupported.C
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index c1d8fd336e8..fef4f09f72e 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -467,6 +467,11 @@ Wcpp
C ObjC C++ ObjC++ CppReason(CPP_W_WARNING_DIRECTIVE)
; Documented in common.opt
+Wctad-maybe-unsupported
+C++ ObjC++ Var(warn_ctad_maybe_unsupported) Warning
+Warn when performing class template argument deduction on a type with no
+deduction guides.
+
Wctor-dtor-privacy
C++ ObjC++ Var(warn_ctor_dtor_privacy) Warning
Warn when all constructors and destructors are private.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index fe45de8d796..177b762883d 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -28830,17 +28830,19 @@ static GTY((deletable)) hash_map
*dguide_cache;
/* Return the non-aggregate deduction guides for deducible template TMPL. The
aggregate candidate is added separately because it depends on the
- initializer. */
+ initializer. Set ANY_DGUIDES_P if we find a non-implicit deduction
+ guide. */
static tree
-deduction_guides_for (tree tmpl, tsubst_flags_t complain)
+deduction_guides_for (tree tmpl, bool &any_dguides_p, tsubst_flags_t complain)
{
tree guides = NULL_TREE;
if (DECL_ALIAS_TEMPLATE_P (tmpl))
{
tree under = DECL_ORIGINAL_TYPE (DECL_TEMPLATE_RESULT (tmpl));
tree tinfo = get_template_info (under);
- guides = deduction_guides_for (TI_TEMPLATE (tinfo), complain);
+ guides = deduction_guides_for (TI_TEMPLATE (tinfo), any_dguides_p,
+complain);
}
else
{
@@ -28849,6 +28851,8 @@ deduction_guides_for (tree tmpl, tsubst_flags_t
complain)
LOOK_want::NORMAL, /*complain*/false);
if (guides == error_mark_node)
guides = NULL_TREE;
+ else
+ any_dguides_p = true;
}
/* Cache the deduction guides for a template. We also remember the result of
@@ -28974,7 +28978,8 @@ do_class_deduction (tree ptype, tree tmpl, tree init,
if (args == NULL)
return error_mark_node;
- tree cands = deduction_guides_for (tmpl, complain);
+ bool any_dguides_p = false;
+ tree cands = deduction_guides_for (tmpl, any_dguides_p, complain);
if (cands == error_mark_node)
return error_mark_node;
@@ -29063,6 +29068,15 @@ do_class_deduction (tree ptype, tree tmpl, tree init,
"for copy-initialization");
}
+ /* If CTAD succeeded but the type doesn't have any explicit deduction
+ guides, this deduction might not be what the user intended. */
+ if (call != error_mark_node
+ && !any_dguides_p
+ && warning (OPT_Wctad_maybe_unsupported,
+ "%qT may not intend to support class template argument "
+ "deduction", type))
+inform (input_location, "add a deduction guide to suppress this warning");
I think you want to avoid warning for types defined in a system header
without -Wsystem-headers.
return cp_build_qualified_type (TREE_TYPE (call), cp_type_quals (ptype));
}
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8086e27aefb..74864535f53 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -236,7 +236,8 @@ in the followin
Re: [PATCH] c++: Detect deduction guide redeclaration [PR97099]
On 9/19/20 5:34 PM, Marek Polacek wrote:
[temp.deduct.guide]p3: Two deduction guide declarations in the same
translation unit for the same class template shall not have equivalent
parameter-declaration-clauses.
So let's detect that.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
gcc/cp/ChangeLog:
PR c++/97099
* decl.c (redeclaration_error_message): Detect a redeclaration of
deduction guides.
gcc/testsuite/ChangeLog:
PR c++/97099
* g++.dg/cpp1z/class-deduction74.C: New test.
---
gcc/cp/decl.c | 20
.../g++.dg/cpp1z/class-deduction74.C | 31 +++
2 files changed, 45 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction74.C
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 13f065d5058..af796499df7 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -3003,6 +3003,10 @@ redeclaration_error_message (tree newdecl, tree olddecl)
}
}
+ if (deduction_guide_p (olddecl)
+ && deduction_guide_p (newdecl))
+ return G_("deduction guide %q+D redeclared");
+
/* [class.compare.default]: A definition of a comparison operator as
defaulted that appears in a class shall be the first declaration of
that function. */
@@ -3053,24 +3057,28 @@ redeclaration_error_message (tree newdecl, tree olddecl)
"% attribute");
else
return G_("%q+D redeclared inline without "
- "% attribute");
+ "% attribute");
}
}
- /* Core issue #226 (C++0x):
-
+ if (deduction_guide_p (olddecl)
+ && deduction_guide_p (newdecl))
+ return G_("deduction guide %q+D redeclared");
+
+ /* Core issue #226 (C++11):
+
If a friend function template declaration specifies a
default template-argument, that declaration shall be a
definition and shall be the only declaration of the
function template in the translation unit. */
- if ((cxx_dialect != cxx98)
+ if ((cxx_dialect != cxx98)
&& TREE_CODE (ot) == FUNCTION_DECL && DECL_FRIEND_P (ot)
- && !check_default_tmpl_args (nt, DECL_TEMPLATE_PARMS (newdecl),
+ && !check_default_tmpl_args (nt, DECL_TEMPLATE_PARMS (newdecl),
/*is_primary=*/true,
/*is_partial=*/false,
/*is_friend_decl=*/2))
return G_("redeclaration of friend %q#D "
- "may not have default template arguments");
+ "may not have default template arguments");
return NULL;
}
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction74.C
b/gcc/testsuite/g++.dg/cpp1z/class-deduction74.C
new file mode 100644
index 000..fe113819a95
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction74.C
@@ -0,0 +1,31 @@
+// PR c++/97099
+// { dg-do compile { target c++17 } }
+// [temp.deduct.guide]p3: Two deduction guide declarations in the same
+// translation unit for the same class template shall not have equivalent
+// parameter-declaration-clauses.
+
+template struct S { };
+template struct X { };
+
+S() -> S; // { dg-message "previously declared here|old declaration" }
+S() -> S; // { dg-error "redeclared" }
+X() -> X;
+S() -> S; // { dg-error "ambiguating new declaration of" }
+
+S(bool) -> S; // { dg-message "previously declared here" }
+explicit S(bool) -> S; // { dg-error "redeclared" }
+
+explicit S(char) -> S; // { dg-message "previously declared here" }
+S(char) -> S; // { dg-error "redeclared" }
+
+template S(T, T) -> S; // { dg-message "previously declared
here" }
+template X(T, T) -> X;
+template S(T, T) -> S; // { dg-error "redeclared" }
+
+// OK: Use SFINAE.
+template S(T) -> S;
+template S(T) -> S;
+
+// OK: Non-template wins.
+S(int) -> S;
+template S(int) -> S;
base-commit: 4a5ff2b56bfea0b3e154a15e809c5c42dc3b9e9f
Enable GCC support for Intel Key Locker extension
Hi: This patch is about to support Intel Key Locker extension. Key Locker provides a mechanism to encrypt and decrypt data with an AES key without having access to the raw key value. For more details, please refer to https://software.intel.com/content/dam/develop/external/us/en/documents/343965-intel-key-locker-specification.pdf . Bootstrap ok, regression test on i386/x86 backend is ok. OK for master? gcc/ChangeLog * common/config/i386/cpuinfo.h (get_available_features): Detect KL, AESKLE and WIDEKL features. * common/config/i386/i386-common.c (OPTION_MASK_ISA_KL_SET): New. (OPTION_MASK_ISA_WIDEKL_SET): Likewise. (OPTION_MASK_ISA_KL_UNSET): Likewise. (OPTION_MASK_ISA_WIDEKL_UNSET): Likewise. (OPTION_MASK_ISA2_AVX2_UNSET): Likewise. (OPTION_MASK_ISA2_AVX_UNSET): Likewise. (OPTION_MASK_ISA2_SSE4_2_UNSET): Likewise. (OPTION_MASK_ISA2_SSE4_1_UNSET): Likewise. (OPTION_MASK_ISA2_SSE4_UNSET): Likewise. (OPTION_MASK_ISA2_SSSE3_UNSET): Likewise. (OPTION_MASK_ISA2_SSE3_UNSET): Likewise. (OPTION_MASK_ISA2_SSE2_UNSET): Likewise. (OPTION_MASK_ISA2_SSE_UNSET): Likewise. (ix86_handle_option): Handle kl and widekl, add dependency chain for KL and SSE2. * common/config/i386/i386-cpuinfo.h (enum processor_features): (FEATURE_KL, FEATURE_AESKLE, FEATURE_WIDEKL): New. * common/config/i386/i386-isas.h: Add ISA_NAMES_TABLE_ENTRY for KL, AESKLE and WIDEKL. * config.gcc: Add keylockerintrin.h. * doc/invoke.texi: Document new option -mkl and -mwidekl. * doc/extend.texi: Document kl and widekl. * config/i386/constraints.md (Y1, Y2, Y3, Y4, Y5, Y6, Y7): New register constraints. * config/i386/cpuid.h (bit_KL, bit_AESKLE, bit_WIDEKL): New. * config/i386/i386-builtin-types.def ((UINT, UINT, V2DI, V2DI, PVOID), (UINT, UINT, V2DI, PVOID), (VOID, V2DI, V2DI, V2DI, UINT), (UINT8, PV2DI, V2DI, PCVOID), (UINT8, PV2DI, PCV2DI, PCVOID)): New function types. * config/i386/i386-builtin.def: Add __builtin_ia32_loadiwkey, __builtin_ia32_aesdec128kl_u8, __builtin_ia32_aesdec256kl_u8, __builtin_ia32_aesenc128kl_u8, __builtin_ia32_aesenc256kl_u8, __builtin_ia32_aesdecwide128kl_u8, __builtin_ia32_aesdecwide256kl_u8, __builtin_ia32_aesencwide128kl_u8, __builtin_ia32_aesencwide256kl_u8, __builtin_ia32_encodekey128_u32, __builtin_ia32_encodekey256_u32. * config/i386/i386-c.c (ix86_target_macros_internal): Handle kl and widekl. * config/i386/i386-options.c (isa2_opts): Add -mkl and -mwidekl. (ix86_option_override_internal): Handle KL and WIDEKL. (ix86_valid_target_attribute_inner_p): Add attribute for kl and widekl. * config/i386/i386-expand.c (ix86_expand_builtin): Expand Keylocker Builtins. * config/i386/i386.h (TARGET_KL): New. (TARGET_KL_P): Likewise. (TARGET_WIDEKL): Likewise. (TARGET_WIDEKL_P): Likewise. (PTA_KL): Likewise. (PTA_WIDEKL): Likewise. (enum reg_class): Add 7 new SSE register classes. (REG_CLASS_NAMES): Likewise. (REG_CLASS_CONTENTS): Likewise. * config/i386/i386.opt: Add new option mkl and mwidekl. * config/i386/keylockerintrin.h: New header file for Keylocker. * config/i386/immintrin.h: Include keylockerintrin.h. * config/i386/sse.md (UNSPECV_LOADIWKEY): New. (UNSPECV_AESDEC128KLU8): Likewise. (UNSPECV_AESENC128KLU8): Likewise. (UNSPECV_AESDEC256KLU8): Likewise. (UNSPECV_AESENC256KLU8): Likewise. (UNSPECV_AESDECWIDE128KLU8): Likewise. (UNSPECV_AESENCWIDE128KLU8): Likewise. (UNSPECV_AESDECWIDE256KLU8): Likewise. (UNSPECV_AESENCWIDE256KLU8): Likewise. (UNSPECV_ENCODEKEY128U32): Likewise. (UNSPECV_ENCODEKEY256U32): Likewise. (loadiwkey): New insn pattern. (encodekey128u32): Likewise. (encodekey256u32): Likewise. (aesu8): Likewise. (aesu8): Likewise. gcc/testsuite/ChangeLog * gcc.target/i386/keylocker-aesdec128kl.c: New test. * gcc.target/i386/keylocker-aesdec256kl.c: Likewise. * gcc.target/i386/keylocker-aesdecwide128kl.c: Likewise. * gcc.target/i386/keylocker-aesdecwide256kl.c: Likewise. * gcc.target/i386/keylocker-aesenc128kl.c: Likewise. * gcc.target/i386/keylocker-aesencwide128kl.c: Likewise. * gcc.target
Re: [PATCH] vect/test: Don't check for epilogue loop [PR97075]
"Kewen.Lin" writes:
> Hi Richard,
>> "Kewen.Lin" writes:
>>> Hi,
>>>
>>> The commit r11-3230 brings a nice improvement to use full
>>> vectors instead of partial vectors when available. But
>>> it caused some vector with length test cases to fail on
>>> Power.
>>>
>>> The failure on gcc.target/powerpc/p9-vec-length-epil-7.c
>>> exposed one issue that: we call function
>>> vect_need_peeling_or_partial_vectors_p in function
>>> vect_analyze_loop_2, since it's in analysis phase, for
>>> the epilogue loop, we could get the wrong information like
>>> LOOP_VINFO_INT_NITERS (loop_vinfo), further get the wrong
>>> answer for vect_need_peeling_or_partial_vectors_p.
>>> For the epilogue loop in this failure specific, the niter
>>> that we get is 58 (should be 1), vf is 2.
>>>
>>> For epilogue loop with partial vectors, it would use the
>>> same VF as the main loop, so it won't be able to use full
>>> vector, this patch is to exclude epilogue loop for the
>>> check vect_need_peeling_or_partial_vectors_p in
>>> vect_analyze_loop_2.
>>
>> Hmm. For better or worse, I think the analysis phase is actually
>> operating on the assumption that the vector code needs to handle
>> all scalar iterations, even in the epilogue case. We actually
>> rely on that to implement VECT_COMPARE_COSTS (although it wasn't
>> the original motivation for handling epilogues this way).
>>
>> Perhaps we should expand the functionality (and name)
>> of determine_peel_for_niter so that it also computes
>> LOOP_VINFO_USING_PARTIAL_VECTORS_P. We'd then recompute
>> that flag once we know the final epilogue scalar iteration count,
>> just like we recompute LOOP_VINFO_PEELING_FOR_NITER.
>>
>> As a sanity check, I think it would also be good for the
>> renamed function to do the following parts of vect_analyze_loop_2:
>>
>> /* If epilog loop is required because of data accesses with gaps,
>> one additional iteration needs to be peeled. Check if there is
>> enough iterations for vectorization. */
>> if (LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo)
>> && LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo)
>> && !LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo))
>> {
>> poly_uint64 vf = LOOP_VINFO_VECT_FACTOR (loop_vinfo);
>> tree scalar_niters = LOOP_VINFO_NITERSM1 (loop_vinfo);
>>
>> if (known_lt (wi::to_widest (scalar_niters), vf))
>> return opt_result::failure_at (vect_location,
>> "loop has no enough iterations to"
>> " support peeling for gaps.\n");
>> }
>>
>> /* If we're vectorizing an epilogue loop, the vectorized loop either needs
>> to be able to handle fewer than VF scalars, or needs to have a lower VF
>> than the main loop. */
>> if (LOOP_VINFO_EPILOGUE_P (loop_vinfo)
>> && !LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo)
>> && maybe_ge (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
>> LOOP_VINFO_VECT_FACTOR (orig_loop_vinfo)))
>> return opt_result::failure_at (vect_location,
>> "Vectorization factor too high for"
>> " epilogue loop.\n");
>>
>> and then assert that no failure occurs when called for epilogues
>> from vect_do_peeling. So the function would be doing three things:
>>
>> - compute LOOP_VINFO_USING_PARTIAL_VECTORS_P, using the current code
>> in vect_analyze_loop_2
>>
>> - perform the checks quoted above
>>
>> - what the function currently does
>>
>> That's all speculation though -- I haven't tried any of this.
>>
>
> Thanks for your comments! I'm curious that are your suggestions mainly
> for future extension? IIUC, currently if the partial vector usage is 2,
> we will have no epilogue loops, if the partial vector usage is 1, the
> epilogue loop uses the same VF as the one of the main loop, its total
> iterations count is less than VF, it has no chance to use full vector.
> It looks to exclude epilogue loops is enough for now.
The problem is that partial-vector-usage==2 does not guarantee that all
loops will be able to use partial vectors. It's still subject to what
the target and the vectoriser support. And on AArch64, we compare up
to 6 implementations of a loop side-by-side:
- up to 4 SVE implementations, for different levels of unpacking
- up to 2 Advanced SIMD implementations (128-bit and 64-bit)
So even today, we have some loop_vinfos that can use predication and
some loop_vinfos that can't. We can then end up analysing a loop_vinfo
once, but with two conflicting uses in mind:
(a) as an epilogue loop for a main loop that can't use predication, or
(b) as a replacement for that main loop.
If analysis succeeds, we decide based on the cost of the loop_vinfo
whether to go for (b) or (a).
To handle this correctly, we need to make the analysis for (b) as
close as possible to the analysis without (a).
There's also a conceptual objection: it seems wrong to check for
epilogue loops he
