On 9/27/19 12:03 PM, Marek Polacek wrote:
We reject this well-formed test because the following error was triggering
even in a SFINAE context, while it should not:
https://en.cppreference.com/w/cpp/language/sfinae says that
"attempting to give an invalid type to a non-type template parameter" is
On 9/26/19 9:46 PM, Marek Polacek wrote:
if (base_fndecl)
{
/* Here we know it is a hider, and no overrider exists. */
- warning_at (location_of (base_fndecl),
- OPT_Woverloaded_virtual,
- "%qD was
On 9/26/19 9:45 PM, Marek Polacek wrote:
Jason, you remarked that adding a ck_qual under the ck_ref_bind might be
too much trouble, but it seems it's actually fairly simple. The comments
hopefully explain my thinking. Is this what you had in mind?
Yes, I'm glad to hear it was simpler than I
On 9/26/19 3:39 PM, Paolo Carlini wrote:
+template void foo( // { dg-error "15:template-id .foo. used as a
declarator" }
That's a strange diagnostic message; there's nothing wrong with using a
template-id as a declarator. Why are we even calling grokdeclarator
when we hit EOF in the
This patch to the Go frontend by Than McIntosh resolves an importing
ambiguity for more complex function calls. It tweaks the exporter for
inlinable function bodies to work around a problem with importing of
function calls whose function expressions are not simple function
names. In the bug in
On Wed, Sep 18, 2019 at 07:58:46PM -0400, Michael Meissner wrote:
> In doing the patches, I noticed that mov_64bit_dm had two alternatives
> combined together. This patch fixes the problem, before the next patch that
> will need to modify mov_64bit_dm for prefixed addressing.
This is okay for
Hi!
On Tue, Sep 24, 2019 at 02:10:10AM -0400, Michael Meissner wrote:
> +/* Return true if the address is a prefixed instruction that can be directly
> + used in a memory instruction (i.e. using numeric offset or a PC-relative
> + reference to a local symbol).
This could use a bit of a
Hi!
On Tue, Sep 24, 2019 at 01:59:07AM -0400, Michael Meissner wrote:
> +;; Return true if the operand is a PC-relative address to a local symbol or a
> +;; label that can be used directly in a memory operation.
"address of", not "address to"?
> +/* Different PowerPC instruction formats that
Hi,
On Thu, Sep 26 2019, Richard Biener wrote:
> On Wed, 25 Sep 2019, Martin Jambor wrote:
>
>> Hi,
>>
>> PR 91853 and its duplicate PR 91894 show that IPA-SRA can stumble when
>> presented with code with mismatched types, whether because it is a K C
>> or happening through an originally
A change made with r275564 ("[ARM/FDPIC v6 02/24] [ARM] FDPIC: Handle
arm*-*-uclinuxfdpiceabi in configure scripts") to libtool.m4 has not
regenerated all the `configure' scripts affected. Fix it.
gcc/
* configure: Regenerate.
libatomic/
* configure:
On 9/27/19 2:28 PM, Jonathan Wakely wrote:
On 09/09/19 20:34 +0200, François Dumont wrote:
Hi
This patch improves stl_algobase.h
copy/copy_backward/fill/fill_n/equal implementations. The
improvements are:
- activation of algo specialization for __gnu_debug::_Safe_iterator
(w/o
On 2019-09-25 12:20 p.m., Richard Sandiford wrote:
[This follows on from:
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00778.html]
If we support multiple ABIs in the same translation unit, it can
sometimes be the case that a callee clobbers more registers than
its caller is allowed to. We
Hi,
GCC cannot compile the following small testing case:
[qinzhao@localhost]$ cat t1.c
extern void boo (void *addr);
#define foo(addr) \
boo (addr)
#define bar(instr, addr) \
(instr) (addr)
void check (void *addr)
{
bar(foo, addr);
}
[qinzhao@localhost]$ sh t
On Thu, Sep 26, 2019 at 08:46:56PM +, Joseph Myers wrote:
> On Thu, 26 Sep 2019, Lewis Hyatt wrote:
>
> > A couple notes:
> > - In order to avoid any portability problems with wchar_t, the
> > equivalent of wcwidth() from libc is implemented in-house.
>
> I'm uneasy about
Hi!
The following patch attempts to implement P0784R7, which includes constexpr
destructors and constexpr new/delete/new[]/delete[].
::operator new is allowed during constexpr evaluation and returns address of
an artificial VAR_DECL with special name. At this point we don't really
know the type
Hi!
In GCC 8 and older, we were implementing the OpenMP 3.1 rule that const vars
without mutable members are predetermined shared, but in GCC 9 and later we
follow the unfortunate OpenMP 4.0 change where they need to be listed
explicitly if default(none). This isn't very conventient for
Hi!
The DECL_IN_CONSTANT_POOL variables are artificial vars that need to be
predetermined shared, they aren't user visible and user has no control about
those. In C/C++, we predetermine artificial variables shared, but only if
they have integral types.
Fixed thusly, bootstrapped/regtested on
Hi Joel,
I've noticed that SPEC has been failing to build on trunk since the
below commit, do you have access to SPEC?
None of the gfortran maintainers has access to SPEC.
do you know if this is due to
a bug in the patch or a bug in SPEC?
The SPEC suite has quite a few bugs, which SPEC
On Fri, Sep 27, 2019 at 02:54:35PM +0200, Tobias Burnus wrote:
> Committed as Rev. 276179. Thanks for the janitorial fixes!
>
> Tobias
>
> On 9/25/19 12:51 AM, Manfred Schwarb wrote:
> > Hi,
> >
> > here is another round of mitigating glitches in dg directives,
> > this time I can offer:
> >
>
Drop the expander and use a mode expander on the define_insn
for macho_correct_pic instead. Update callers.
tested on powerpc-darwin9, powerpc64-linux-gnu
applied to mainline,
thanks
Iain
gcc/ChangeLog:
2019-09-27 Iain Sandoe
* config/rs6000/darwin.md (@macho_correct_pic_): New,
GCC declares bcmp, bcopy, and bzero without the nonnull attribute.
This was a deliberate decision as is reflected in the comment in
builtins.def:
/* bcmp, bcopy and bzero have traditionally accepted NULL pointers
when the length parameter is zero, so don't apply attribute
"nonnull". */
Obvious const-correctness fixes; I need these for a patch kit
I'm working on.
Successfully bootstrapped on x86_64-pc-linux-gnu.
Committed to trunk (r276193) under the "obvious" rule.
gcc/ChangeLog:
* fibonacci_heap.h (fibonacci_heap::empty): Make const.
(fibonacci_heap::nodes):
This is the third piece of my effort to improve inline expansion of memmove. The
first two parts I posted back in June fixed the names of the optab entries
involved so that optab cpymem is used for memcpy() and optab movmem is used for
memmove(). This piece adds support for actually attempting to
Merging the similar_type_p change to the concepts branch broke a cmcstl2
testcase; investigating led me to this small testcase which has always
failed on trunk.
Tested x86_64-pc-linux-gnu, applying to trunk.
(cxx_eval_indirect_ref): Likewise. Improve error location.
---
We didn't already have an RAII sentinel for input_location, and while
temp_override would work, it would also happily set input_location to 0,
which breaks things that try to look up the associated filename.
Tested x86_64-pc-linux-gnu, applying to trunk.
* decl.c (grokdeclarator,
(This is a revised patch proposal. I am revising both the description
and the code itself.)
Even on recent processors, integer division is relatively expensive.
The current implementation of std::uniform_int_distribution typically
requires two divisions by invocation:
// downscaling
Obvious const-correctness fix; I need this for a patch kit
I'm working on.
Successfully bootstrapped on x86_64-pc-linux-gnu.
Committed to trunk (r276190) under the "obvious" rule.
gcc/ChangeLog:
* cgraph.c (cgraph_node::get_fun): Make const.
* cgraph.h (cgraph_node::get_fun):
Ping https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00808.html
with one more potential reviewer in Cc.
On Wed, 11 Sep 2019, Marc Glisse wrote:
Ping
On Tue, 3 Sep 2019, Marc Glisse wrote:
On Fri, 2 Aug 2019, Marc Glisse wrote:
Ping
On Tue, 16 Jul 2019, Marc Glisse wrote:
Adding a C++
With the current Go export format, if we already know the type, we
don't have to read and parse the definition. This patch to the Go
frontend implements that.
Also, we only use the finalizer in Import::finalize_methods, so make
it a local variable. And to match Finalize_methods::type, only put
This patch changes the Go frontend escape analysis test for a big type
to only fetch the size if it might matter. Fetching the size of a
type typically involves a hash table lookup, and is generally
non-trivial. The escape analysis code calls is_big more than one
might expect. So only fetch the
This trivial patch fixes some brace formatting in the Go frontend.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision
On 9/23/19 8:12 PM, Jerry DeLisle wrote:
On 9/23/19 8:52 AM, Bernhard Reutner-Fischer wrote:
On 22 September 2019 22:51:46 CEST, Jerry DeLisle wrote:
Hi all,
The attached patch eliminates several warnings by adjusting which
enumerator is
used in the subject offending code. I fixed this by
On 27/09/19 18:24 +0200, François Dumont wrote:
On 9/27/19 2:11 PM, Jonathan Wakely wrote:
On 19/09/19 22:27 +0200, François Dumont wrote:
Hi
I start working on making recently added constexpr tests to
work in Debug mode.
The attached patch seems to be necessary for that, right?
On
On 9/27/19 2:11 PM, Jonathan Wakely wrote:
On 19/09/19 22:27 +0200, François Dumont wrote:
Hi
I start working on making recently added constexpr tests to work
in Debug mode.
The attached patch seems to be necessary for that, right?
On my side I had done this, almost the same.
For
On 27/09/19 18:07 +0200, François Dumont wrote:
On 9/26/19 3:20 PM, Jonathan Wakely wrote:
Fix data race when _Safe_iterator_base::_M_detach() runs
concurrently with
the _Safe_container_base destructor.
PR libstdc++/91910
* src/c++11/debug.cc (_Safe_iterator_base::_M_detach()): Load
On Fri, Sep 27, 2019 at 04:52:30PM +0800, Kewen.Lin wrote:
> > (Maybe one of the gen* tools complains any_fix needs a mode? :QI will do
> > if so, or :P if you like that better).
>
> I didn't encounter any errors, it sounds it's allowable now?
Ah, that particular warning (from genrecog.c) only
On 9/26/19 3:20 PM, Jonathan Wakely wrote:
Fix data race when _Safe_iterator_base::_M_detach() runs concurrently
with
the _Safe_container_base destructor.
PR libstdc++/91910
* src/c++11/debug.cc (_Safe_iterator_base::_M_detach()): Load pointer
atomically and lock the mutex before
We reject this well-formed test because the following error was triggering
even in a SFINAE context, while it should not:
https://en.cppreference.com/w/cpp/language/sfinae says that
"attempting to give an invalid type to a non-type template parameter" is
a SFINAE error.
I wonder if the tf_error
On Fri, Sep 27, 2019 at 10:08:46AM +0200, Jakub Jelinek wrote:
> On Thu, Sep 26, 2019 at 05:34:25PM -0500, Segher Boessenkool wrote:
> > > Are you sure?
> > > "The UMLAL instruction interprets the values from Rn and Rm as unsigned
> > > integers. It multiplies these integers, and adds the 64-bit
Hi Thomas,
I've noticed that SPEC has been failing to build on trunk since the below
commit, do you have access to SPEC? do you know if this is due to a bug in the
patch or a bug in SPEC?
> commit ddeea2110539a432b302401a617ceb5bde191094 (HEAD, refs/bisect/bad)
> Author: tkoenig
> Date:
On 9/27/19 4:17 PM, Richard Earnshaw (lists) wrote:
On 26/09/2019 07:49, Jakub Jelinek wrote:
> On Wed, Sep 25, 2019 at 10:06:13PM -0600, Jeff Law wrote:
>> (insn 13 12 14 2 (set (reg:SI 124)
>> (const_int -939524096 [0xc800])) "j.c":10:54 161
>> {*arm_movsi_insn}
>>
On 26/09/2019 07:49, Jakub Jelinek wrote:
On Wed, Sep 25, 2019 at 10:06:13PM -0600, Jeff Law wrote:
(insn 13 12 14 2 (set (reg:SI 124)
(const_int -939524096 [0xc800])) "j.c":10:54 161
{*arm_movsi_insn}
(nil))
(insn 14 13 16 2 (parallel [
(set (reg:SI
Hi all,
using
!$omp target data map(A) use_device_ptr(A)
call foo(c_loc(A))
!$omp end target data
fails on trunk if "A" is not a simple pointer but an array with descriptor.
For the use_device_ptr clause, one needs to replace the host pointer
address by the address on the device (done by
Committed as Rev. 276179. Thanks for the janitorial fixes!
Tobias
On 9/25/19 12:51 AM, Manfred Schwarb wrote:
Hi,
here is another round of mitigating glitches in dg directives,
this time I can offer:
./lto/pr87689_0.f:! { dg-lto-run }
./associate_48.f90:! { dg=do run }
On 09/09/19 20:34 +0200, François Dumont wrote:
Hi
This patch improves stl_algobase.h
copy/copy_backward/fill/fill_n/equal implementations. The improvements
are:
- activation of algo specialization for __gnu_debug::_Safe_iterator
(w/o _GLIBCXX_DEBUG mode)
- activation of algo
On 19/09/19 22:27 +0200, François Dumont wrote:
Hi
I start working on making recently added constexpr tests to work
in Debug mode.
The attached patch seems to be necessary for that, right?
commit c47326afadb0c330c19b872d5969d2f656499d0a
Author: Jonathan Wakely
Date: Thu Sep 26
On 16/09/19 22:31 +0200, François Dumont wrote:
Here is the patch to improve _Safe_iterator<>::_M_get_distance_to
implementation.
I introduced a new _Distance_precision __sp_sign_max_size for
occasions where we can't find out the exact size of a range but still
get the max size of it.
On 20/09/19 07:08 +0200, François Dumont wrote:
I already realized that previous patch will be too controversial to be
accepted.
In this new version I just implement a real memmove in __memmove so
A real memmove doesn't just work backwards, it needs to detect any
overlaps and work forwards
This patch isolates vect_create_epilog_for_reduction from
vectorizable_reduction state so that there is the possiblity
to call it from elsewhere (I'd like to do that when visiting
the loop-closed PHI node). The next patch in the open-end series
will try to achieve that.
Bootstrap and regtest
On 19/07/19 23:37 +0200, François Dumont wrote:
It sounds reasonable to overload std::copy_n for istreambuf_iterator.
* include/bits/stl_algo.h (copy_n(istreambuf_iterator<>, _Size,
_OIte)):
New declaration.
* include/bits/streambuf_iterator.h (istreambuf_iterator<>): Declare
Thanks for the corrections, updated.
Regards
Yuliang
(no ChangeLog updates)
-Original Message-
From: Richard Sandiford
Sent: 27 September 2019 11:20
To: Yuliang Wang
Cc: gcc-patches@gcc.gnu.org; nd
Subject: Re: [AArch64][SVE] Utilize ASRD instruction for division and remainder
On Thu, Sep 26, 2019 at 09:38:44AM +0200, Martin Liška wrote:
> >> 2019-09-25 Martin Liska
> >>
> >> PR tree-optimization/91885
> >> * tree-vectorizer.c (try_vectorize_loop_1):
> >> Add TODO_update_ssa similarly to what slp
> >> pass does.
> >>
> >>
Yuliang Wang writes:
> +;; Unpredicated arithmetic right shift for division by power-of-2.
> +(define_expand "sdiv_pow23"
> + [(set (match_operand:SVE_I 0 "register_operand" "")
> + (unspec:SVE_I
> + [(match_dup 3)
> +(unspec:SVE_I
> + [(match_operand:SVE_I 1
Apologies for the accidental change, and added the underscore.
Regards
Yuliang
gcc/ChangeLog:
2019-09-27 Yuliang Wang
* config/aarch64/aarch64-sve.md (sdiv_pow23):
New pattern for ASRD.
* config/aarch64/iterators.md (UNSPEC_ASRD): New unspec.
*
Hi Richard,
I have renamed the optabs and associated identifiers as per your suggestion.
Thanks.
Regards
Yuliang
gcc/ChangeLog:
2019-09-27 Yuliang Wang
* config/aarch64/aarch64-sve.md (sdiv_pow23):
New pattern for ASRD.
* config/aarch64/iterators.md (UNSPEC_ASRD):
Dimitar Dimitrov writes:
> On Wed, 11 Sep 2019, 22:02:26 EEST Richard Sandiford wrote:
>> The reason for the PRU differences is that the port defines
>> targetm.hard_regno_call_part_clobbered, but uses it to test whether
>> a multi-register value contains a mixture of fully-clobbered and
>>
Hi Segher,
on 2019/9/27 下午3:27, Segher Boessenkool wrote:
> Hi Kewen,
>
>> +;; Support signed/unsigned long long to float conversion vectorization.
>> +(define_expand "vec_pack_float_v2di"
>> + [(match_operand:V4SF 0 "vfloat_operand")
>> + (any_float:V4SF (parallel [(match_operand:V2DI 1
James Greenhalgh writes:
> On Wed, Aug 07, 2019 at 08:28:50PM +0100, Richard Sandiford wrote:
>> It was easier to add the SVE ACLE support without enumerating every
>> function at build time. This in turn meant that it was easier if the
>> SVE builtins occupied a distinct numberspace from the
The then/else order of the VEC_COND_EXPRs created by
vect_create_epilog_for_reduction meeds to line up with the
main VEC_COND_EXPR.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and armeb-eabi.
Approved by Richi in the PR, applied as r276175.
Richard
2019-09-27 Richard Sandiford
gcc/
Yuliang Wang writes:
> Hi,
>
> This patch adds combining support for SVE2's shift-right accumulate
> instructions.
>
> Example snippet:
>
> #define IMM ...
>
> void foo (TYPE a, TYPE b, int n)
> {
> for (int i = 0; i < n; i++)
> a[i] += b[i] >> IMM;
> }
>
> Signed:
>
> beforeasr
On Thu, Sep 26, 2019 at 05:34:25PM -0500, Segher Boessenkool wrote:
> > Are you sure?
> > "The UMLAL instruction interprets the values from Rn and Rm as unsigned
> > integers. It multiplies these integers, and adds the 64-bit result to the
> > 64-bit unsigned integer contained in RdHi and RdLo."
Hi Kewen,
On Fri, Sep 27, 2019 at 10:33:01AM +0800, Kewen.Lin wrote:
> This patch is to add the support for float from/to long conversion
> vectorization. ISA 2.06 supports the vector version instructions
> for conversion between float and long long (both signed and unsigned),
> but vectorizer
> Shall I amend the change description anyhow then? I know it has not (as
> yet, as discussed at the GNU Tools Cauldron recently) been enforced for
> the GCC project (unlike with e.g. glibc), however I mean to use it whole
> as the commit message, which is what I have been doing for quite a
> > Unfortunately the Make-lang.in part is still needed when using the
> > --disable-libada configure switch so a more elaborate change is needed.
>
> Hmm, I've experimented a bit and AFAICT if `--disable-libada' is given
> without my proposed change applied, then the gnatlib stuff doesn't get
Hi Martin,
Thanks for your time of so many round of reviews.
It really helped me a lot.
Updated with your comments and attached for Honza's review and approve. :)
Xiong Hu
BR
On 2019/9/26 16:36, Martin Liška wrote:
On 9/26/19 7:23 AM, luoxhu wrote:
Thanks Martin,
On 2019/9/25 18:57,
65 matches
Mail list logo
