On 6/19/19 7:38 AM, luoxhu wrote:
> Actually, the algorithm of function __gcov_one_value_profiler_body in
> libgcc/libgcov-profiler.c has functionality issue when profiling the testcase
> I provide.
It's designed to track most common value and uses only one slot for storage
place.
As mentioned
Hi Martin,
On 2019/6/18 17:34, Martin Liška wrote:
On 6/18/19 11:02 AM, luoxhu wrote:
Hi,
On 2019/6/18 13:51, Martin Liška wrote:
On 6/18/19 3:45 AM, Xiong Hu Luo wrote:
Hello.
Thank you for the interest in the area.
This patch aims to fix PR69678 caused by PGO indirect call profiling bug
This patch to the Go frontend by Cherry Zhang stack allocates a buffer
for non-escaping string operations. For string concatenation, string
to/from byte or rune slice conversion, and int to string conversion,
if the result does not escape, we can allocate a small (32-element, or
4-byte for int to
On Tue, Jun 18, 2019 at 4:53 PM Wilco Dijkstra wrote:
> > It would work if a frame pointer was initialized in the function test, but
> > it wasn't:
>
> Right, because it unwinds, it needs a valid frame pointer since we no
> longer store the stack pointer. So xtensa_frame_pointer_required
> should
On 6/14/19 2:59 PM, Jeff Law wrote:
On 6/4/19 1:40 PM, Martin Sebor wrote:
On 6/3/19 5:24 PM, Martin Sebor wrote:
On 5/31/19 2:46 PM, Jeff Law wrote:
On 5/22/19 3:34 PM, Martin Sebor wrote:
-Wreturn-local-addr detects a subset of instances of returning
the address of a local object from a fun
Let me try that again to the right list.
On 6/18/19 9:14 PM, Martin Sebor wrote:
Bug 90923 shows that even though GCC hash-table based containers
like hash_map can be instantiated on types with user-defined ctors
and dtors they invoke the dtors of such types without invoking
the corresponding ct
I will see if I can get this one.
On 6/17/19 6:37 AM, Mark Eggleston wrote:
On 12/06/2019 19:11, Steve Kargl wrote:
On Tue, Jun 11, 2019 at 11:50:40AM +0200, Jakub Jelinek wrote:
On Tue, Jun 11, 2019 at 10:30:59AM +0100, Mark Eggleston wrote:
Jim MacArthur
Mark Eggleston
Two spa
The attach patch fixes an issue where a CLASS entity
is specified with duplicate dimension. See the testcase
for an exmaple. Regression tested on x86_64-*-freebsd.
OK to commit?
2019-06-18 Steven G. Kargl
PR fortran/69398
* decl.c (attr_decl): Check for duplicate DIMENSION at
This patch to the Go frontend by Cherry Zhang avoids a copy for a
string([]byte) conversion used in string concatenation. If a
string([]byte) conversion is used immediately in a string
concatenation, we don't need to copy the backing store of the byte
slice, as the runtime function doesn't hold an
Hi Max,
> It would work if a frame pointer was initialized in the function test, but
> it wasn't:
Right, because it unwinds, it needs a valid frame pointer since we no
longer store the stack pointer. So xtensa_frame_pointer_required
should do something like:
if (cfun->machine->accesses_prev_fr
On Tue, Jun 18, 2019 at 10:07 AM Wilco Dijkstra wrote:
> > The testcase from the patch passes with the trunk xtensa-linux-gcc
> > with windowed ABI. But with the changes in this patch a lot of tests
> > that use longjmp are failing on xtensa-linux.
>
> Interesting. I looked at the _xtensa_nonlocal
Hi!
On Thu, 4 Oct 2018 14:04:13 +0100, Julian Brown wrote:
> On Sun, 23 Sep 2018 10:48:52 +0200
> Bernhard Reutner-Fischer wrote:
>
> > On Sat, 22 Sep 2018 at 00:32, Julian Brown
> > wrote:
> >
> > @@ -6218,13 +6221,20 @@ add_clause (gfc_symbol *sym, gfc_omp_map_op
> > map_op) {
> >gfc_om
On 18/06/19 19:08 +0100, Dietmar Kuehl via libstdc++ wrote:
The first release shipping the parallel algorithms is gcc-9.1.0. Specifically
std::inclusive_scan() *without* execution policy seems to be missing, though. I
guess, that’s because it was an add/renamed algorithm. The versions
taking an
Hi!
On Fri, 27 Nov 2015 12:37:23 +0100, I wrote:
> On Thu, 19 Nov 2015 10:22:16 -0600, James Norris
> wrote:
> > [...]
> Merging your trunk r230722 and r230725 with the existing Fortran OpenACC
> declare implementation present on gomp-4_0-branch, I effectively applied
> the following to gomp-4_
Hi!
On Wed, 19 Jun 2019 00:47:27 +0200, I wrote:
> I committed to trunk in r272451 a few "Test cases to verify OpenACC
> 'firstprivate' mappings"
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/goacc/firstprivate-mappings-1.c
> +static void
> +vla (int array_li)
> +{
> + _Complex double arra
On 18/06/19 22:42 +0200, François Dumont wrote:
On 6/18/19 12:54 PM, Jonathan Wakely wrote:
On 18/06/19 07:52 +0200, François Dumont wrote:
A small regression noticed while merging.
We shouldn't keep on using a moved-from key_type instance.
Ok to commit ? Feel free to do it if you prefer, I'l
Hi!
I committed to trunk in r272451 a few "Test cases to verify OpenACC
'firstprivate' mappings", see attached. More to come, later on.
Grüße
Thomas
From 2f195960a11d9eb027e4abcfc5faaca2ff5fe9e3 Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Tue, 18 Jun 2019 22:15:03 +
Subject: [PATCH]
Hi!
On Mon, 23 Nov 2015 13:37:20 +0100, I wrote:
> Hi Jim!
>
> A few things I noticed when working on merging your trunk r230275 into
> gomp-4_0-branch. Please fix these (on trunk).
> | --- include/gomp-constants.h
> | +++ include/gomp-constants.h
> | @@ -72,6 +72,11 @@ enum gomp_map_kind
> |
Hi!
On Thu, 5 Jun 2008 12:08:28 -0400, Jakub Jelinek wrote:
> This patch contains the OpenMP specific testsuite additions and fixes.
> * testsuite/libgomp.fortran/allocatable3.f90: New test.
As obvious (that is, as done for all the other test cases), I committed
to trunk in r272449 "Add m
Hi!
On Thu, 8 Jun 2017 14:40:29 -0700, Cesar Philippidis
wrote:
> This patch fixes a bug I introduced while [...]
> libgomp/
> * testsuite/libgomp.oacc-fortran/allocatable-array-1.f90: New test.
This test case actually PASSes with current trunk, committed in r272448
"Add 'libgomp.o
Hi!
On Wed, 5 Jun 2019 12:32:12 +0200, Jakub Jelinek wrote:
> On Wed, Jun 05, 2019 at 12:26:32PM +0200, Thomas Schwinge wrote:
> > On Wed, 5 Jun 2019 12:00:25 +0200, Jakub Jelinek wrote:
> > > On Wed, Jun 05, 2019 at 11:25:07AM +0200, Thomas Schwinge wrote:
> > > > + !$omp target map(to: a) map
On Mon, 2019-06-10 at 09:15 +, Andrea Corallo wrote:
> Hi all,
> I would like to propose this patch to check for the return type of
> binary operators to be a numeric type.
> Not doing so can lead the compiler into funny crashes.
>
> Does not introduce regressions running make check-jit.
>
>
Hi!
This doesn't resolve PR90861, but at least in trunk r272446 we now
"Document status quo for OpenACC 'declare' not cleaning up for VLAs", see
attached.
Grüße
Thomas
From 3f8b36838cd2aa34d59d867ed22fad054f489884 Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Tue, 18 Jun 2019 22:14:14 +
Hi!
This doesn't resolve PR90868, but at least in trunk r272445 we now
"Document status quo for duplicate OpenACC 'declare' directives for
'extern' variables", see attached.
Grüße
Thomas
From 267951437cde77a09e62d9c151002eeed3cf457c Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Tue, 18 Jun
On Tue, Jun 18, 2019 at 3:09 PM augustine.sterl...@gmail.com
wrote:
>
> On Tue, Jun 18, 2019 at 2:27 PM Max Filippov wrote:
> >
> > Stack pointer adjustment code in prologue missed a case of no
> > callee-saved registers and a stack frame size bigger than 128 bytes.
> > Handle that case.
> >
> >
Hi!
On Wed, 11 Nov 2015 19:07:58 -0600, James Norris
wrote:
> [...]
> --- a/gcc/gimple.h
> +++ b/gcc/gimple.h
> @@ -170,6 +170,7 @@ enum gf_mask {
> GF_OMP_TARGET_KIND_OACC_DATA = 7,
> GF_OMP_TARGET_KIND_OACC_UPDATE = 8,
> GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA = 9,
> +GF_OMP
On Tue, Jun 18, 2019 at 2:27 PM Max Filippov wrote:
>
> Stack pointer adjustment code in prologue missed a case of no
> callee-saved registers and a stack frame size bigger than 128 bytes.
> Handle that case.
>
> This fixes the following gcc tests with call0 ABI:
> gcc.c-torture/execute/stdarg-2
Another test that got fixed by my fix for member friend templates with
noexcept (r270005). It's short and valid, so I'll add it too.
Tested x86_64-linux, applying to trunk.
2019-06-18 Marek Polacek
PR c++/84698
* g++.dg/cpp0x/noexcept42.C: New test.
diff --git gcc/testsuite/
gcc/configure needs this to generate auto-build.h using the right C++
compiler.
2019-06-18 Michael Forney
* Makefile.tpl (HOST_EXPORTS): Add CXX_FOR_BUILD.
* Makefile.in: Regenerate.
---
I ran into this since I needed to pass some special flags to the build
C++ compiler for my
Stack pointer adjustment code in prologue missed a case of no
callee-saved registers and a stack frame size bigger than 128 bytes.
Handle that case.
This fixes the following gcc tests with call0 ABI:
gcc.c-torture/execute/stdarg-2.c
gcc.dg/torture/pr55882.c
gcc.dg/torture/pr57569.c
2019-06-
Invalid, but we used to crash here, so let's make sure the ICE doesn't
creep back in.
Tested on x86_64-linux, applying to trunk.
2019-06-18 Marek Polacek
PR c++/71548
* g++.dg/cpp0x/variadic177.C: New test.
diff --git gcc/testsuite/g++.dg/cpp0x/variadic177.C
gcc/testsuite/g+
On 6/18/19 12:54 PM, Jonathan Wakely wrote:
On 18/06/19 07:52 +0200, François Dumont wrote:
A small regression noticed while merging.
We shouldn't keep on using a moved-from key_type instance.
Ok to commit ? Feel free to do it if you prefer, I'll do so at end of
Europe day otherwise.
diff
On 3/26/19 5:40 AM, JunMa wrote:
> Hi
>
> According to gnu document of function attributes, neither weakref nor alias
> could be attached to a function defined in current translation unit.
> Although GCC checks the attributes under some circumstances, it still fails
> on some cases and even causes
On 6/6/19 1:32 AM, Claudiu Zissulescu wrote:
> Hi Andrew,
>
> This is a proposed fix for bugzilla PR89838 issue. It also needs to be
> backported to gcc9 and, eventually, gcc8 branches.
>
> Ok to apply?
> Claudiu
>
> gcc/
> -xx-xx Claudiu Zissulescu
>
> * config/arc/arc.c (arc_sym
The attach patch has been regression tested on x86_64-*-freebsd.
If the pointer is NULL, the function simply returns. It seems
that gfortran then does the Right Thing. OK to commit?
2019-06-18 Steven G. Kargl
PR fortran/87907
* resolve.c (resolve_contained_fntype): Do not d
On 12 June 2019 20:00:09 CEST, Indu Bhagat wrote:
>-gtLEVEL is used to request CTF debug information and also to specify
>how much
>CTF debug information.
The option name is way too generic IMO.
-gctfLEVEL or some such would at least indicate its intended purpose, fwiw.
thanks
>
>[Changes from
On 6/18/19 12:59 PM, Jeff Law wrote:
On 5/22/19 10:42 AM, Martin Sebor wrote:
Attached is a revised implementation of the -Wformat-diag checker
incorporating the feedback I got on the first revision.
Martin
gcc-wformat-diag-checker.diff
gcc/c-family/ChangeLog:
* c-format.c (function_
On 5/22/19 10:42 AM, Martin Sebor wrote:
> Attached is a revised implementation of the -Wformat-diag checker
> incorporating the feedback I got on the first revision.
>
> Martin
>
> gcc-wformat-diag-checker.diff
>
> gcc/c-family/ChangeLog:
>
> * c-format.c (function_format_info::format_ty
On 18/06/2019 17:20, Nick Clifton wrote:
> Hi Richard,
>
>>> OK, here is a resubmission of my patch with just the addition of the
>>> libctf patches this time.
>
> [Sorry - this one got put on a back burner].
>
>> Would it be feasible to backport this to the other maintained branches
>> so
Hi,
> > Is this test valid? Can jmp buffer be allowed on stack?
>
> Sure, the contents of the jmp buffer is only valid during the lifetime
> of the call frame anyway.
Indeed. The issue with jmp buffer being on the stack causing incorrect
restore when doing longjmp has just been fixed (PR64242)
Hello,
PING, In case this patch series slipped your attention.
Thanks
Indu
On Wed, Jun 12, 2019 at 10:50 AM Indu Bhagat wrote:
>
> Hello,
>
> Thanks for the feedback on the previous patch set.
>
> This is the second posting of the RFC patch for CTF support in GCC. This patch
> set does not rely
On Jun 18 2019, "H.J. Lu" wrote:
>> +void
>> +test (void)
>> +{
>> + void *buf[5];
>> + void *volatile q = p;
>> +
>> + if (!__builtin_setjmp (buf))
>> +broken_longjmp (buf);
>
> Is this test valid? Can jmp buffer be allowed on stack?
Sure, the contents of the jmp buffer is only valid du
On Tue, Jun 18, 2019 at 06:37:54AM -0500, Segher Boessenkool wrote:
> On Mon, Jun 17, 2019 at 05:24:37PM -0400, Michael Meissner wrote:
> > I wrote the code to generate LFIWAX and LFIWZX originally for the power7 in
> > the
> > 2010 time frame. At the time, we did not allow SImode to go into floa
On Tue, Jun 18, 2019 at 01:17:10PM -0400, Matthew Beliveau wrote:
> Hello,
>
> This patch should change the formatting, and move the test files into
> the appropriate directory!
It doesn't address my other comments, though, so please send a new version
with that fixed.
Marek
Hello,
This patch should change the formatting, and move the test files into
the appropriate directory!
Thank you
On Mon, Jun 17, 2019 at 1:45 PM Marek Polacek wrote:
>
> Thanks for the patch.
>
> On Mon, Jun 17, 2019 at 01:26:37PM -0400, Matthew Beliveau wrote:
> > --- gcc/c-family/c.opt
> > +
Hi Max,
> The testcase from the patch passes with the trunk xtensa-linux-gcc
> with windowed ABI. But with the changes in this patch a lot of tests
> that use longjmp are failing on xtensa-linux.
Interesting. I looked at the _xtensa_nonlocal_goto implementation in
libgcc/config/xtensa/lib2funcs.
On Tue, May 28, 2019 at 10:37 AM Wilco Dijkstra wrote:
>
>
> diff --git a/gcc/testsuite/gcc.c-torture/execute/pr84521.c
> b/gcc/testsuite/gcc.c-torture/execute/pr84521.c
> new file mode 100644
> index
> ..995a30223afd1401186c7eaf541f27606aed59b5
> --- /dev
2019-06-18 Uroš Bizjak
* config/i386/i386.md (@cmp_1): Rename from cmp_1.
(@add3_carry): Rename from add3_carry.
(@sub3_carry_ccc): Rename from sub3_carry_ccc.
(@sub3_carry_ccgz): Rename form sub3_carry_ccgz.
(@copysign3_const): Rename from copysign3_const.
(@copysign3_v
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01513.html
On 6/11/19 7:31 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01513.html
On 5/22/19 10:42 AM, Martin Sebor wrote:
Attached is a revised implementation of the -Wformat-diag checker
incorporating the fee
Hello,
On Mon, Jun 17, 2019 at 6:10 PM Jeff Law wrote:
> On 6/17/19 6:58 PM, Wilco Dijkstra wrote:
> >> You mention that arm, mips and xtensa are still broken. Are they worse
> >> after this patch?
The testcase from the patch passes with the trunk xtensa-linux-gcc
with windowed ABI. But with th
Hi Richard,
>> OK, here is a resubmission of my patch with just the addition of the
>> libctf patches this time.
[Sorry - this one got put on a back burner].
> Would it be feasible to backport this to the other maintained branches
> so that the option of using them with current binutils wo
>
> ICK. Can you please solve the C++ issue differently? The patch
> also seems to do many other things ...
If you refer to the fact that C++ seem to create non-ODR types that are
structurally equivalent to ODR types, i tracked it down. Testcase is
testsuite/g++.dg/lto/20080904_0.C
compiled wi
On Tue, Jun 11, 2019 at 12:28 AM Jason Merrill wrote:
>
> On Fri, Jun 7, 2019 at 5:08 PM Jason Merrill wrote:
> >
> > All expression statements and some other places express implicit conversion
> > to
> > void with a CONVERT_EXPR. There's no reason to build up a new one as part
> > of
> > cons
On Mon, Jun 3, 2019 at 3:50 PM H.J. Lu wrote:
>
> On Tue, May 21, 2019 at 8:54 AM H.J. Lu wrote:
> >
> > On Wed, May 15, 2019 at 2:29 PM Richard Sandiford
> > wrote:
> > >
> > > "H.J. Lu" writes:
> > > > On Thu, Feb 7, 2019 at 9:49 AM H.J. Lu wrote:
> > > >>
> > > >> Standard scalar operation
On Fri, May 31, 2019 at 10:38 AM H.J. Lu wrote:
>
> On Tue, May 21, 2019 at 2:43 PM H.J. Lu wrote:
> >
> > On Fri, Feb 22, 2019 at 8:25 AM H.J. Lu wrote:
> > >
> > > Hi Jan, Uros,
> > >
> > > This patch fixes the wrong code bug:
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229
> >
On Tue, Jun 11, 2019 at 8:14 AM H.J. Lu wrote:
>
> For op_by_pieces operations between two areas of memory, this patch adds
> -fminimize-op-by-pieces-run to minimize number of operations. When
> operating on LENGTH bytes of memory, it starts with the widest usable
> integer size, MAX_SIZE, for LE
Here we ICE on
template // #1
struct A {};
template void foo(A) {}
void bar() { foo(A()); }
when deducing T in the non-type template parameter, because unify didn't
expect a CONSTRUCTOR:
default:
/* An unresolved overload is a nondeduced context. */
if (is_overloaded_f
On 18/06/2019 11:37, Richard Earnshaw (lists) wrote:
> Start sentences with a capital letter. End them with a full stop.
> "inequal" isn't a word: you probably mean "unequal".
I've fixed this, the iterator is, however defined as 'fcvt_iesize'
and described in the adjacent comment in iterators.md
> >Well, me too :-) I didn't really understand the choice of the original
> >condition above. It seemed to be "return true if both access sizes are
> >variable", but the comment implied something else.
>
> Sorry,! Must_eq is obviously fine.
Thanks, good to know we are on same page :)
After som
The SVE ACLE patches need to introduce a new CC_NZC mode for the
conditions that can be tested after a PTRUE. In particular, LT needs
to map to "mi"/"first" and GE to "pl"/"nfrst", instead of the normal
CC mapping.
Another advantage of using a separate mode is that we can print the SVE
names of t
Tested on aarch64-linux-gnu (with and without SVE). Applied as r272426.
Richard
2019-06-18 Richard Sandiford
gcc/
* config/aarch64/aarch64-sve.md: Tabify file.
Index: gcc/config/aarch64/aarch64-sve.md
===
--- gcc/confi
Following on from the previous ptrue patch.
Tested on aarch64-linux-gnu (with and without SVE). Applied as r272425.
Richard
2019-06-18 Richard Sandiford
gcc/
* config/aarch64/aarch64-protos.h (aarch64_pfalse_reg): Declare.
* config/aarch64/aarch64.c (aarch64_pfalse_reg): Ne
This is the first step to canonicalising predicate constants so that
they can be reused between modes.
Tested on aarch64-linux-gnu (with and without SVE). Applied as
Richard
2019-06-18 Richard Sandiford
gcc/
* config/aarch64/aarch64-protos.h (aarch64_ptrue_reg): Declare.
*
This patch makes the binary IFN_COND patterns use the same approach
as the ternary patterns, with one pattern handling the cases in
which the "else" value isn't tied to one of the other inputs.
Tested on aarch64-linux-gnu with and without SVE, applied as r272423.
Richard
2019-06-18 Richard San
David Malcolm writes:
> Thanks for working on this; sorry for the delay in reviewing it.
>
> Overall, this looks close to being ready, but I have a few notes:
>
> [...]
Cool thanks for the review.
I'll adress your comments.
When you have time if you could take a look to the other pending patch
On Mon, 2019-06-03 at 09:51 +, Andrea Corallo wrote:
> Hi all,
> I would like to submit this patch that aims to introduce bitfields
> support into libgccjit.
>
> A new entry point gcc_jit_context_new_bitfield is added plus relative
> testcase.
>
> Checked with make check-jit does not introduc
Hi Wilco,
Combined them into one pattern. Updated the diff and the changelog is now:
gcc/ChangeLog:
2019-06-18 Sylvia Taylor
* config/aarch64/aarch64.c
(aarch64_load_symref_appropriately): Change SYMBOL_TINY_GOT.
* config/aarch64/aarch64.md
(ldr_got_tiny_): Ne
On Tue, 18 Jun 2019 at 15:07, Martin Sebor wrote:
>
> On 6/18/19 2:38 AM, Christophe Lyon wrote:
> > On Fri, 14 Jun 2019 at 03:35, Jeff Law wrote:
> >>
> >> On 6/13/19 1:10 PM, Martin Sebor wrote:
> >>> Attached is a fix for the fold_build call with inconsistent
> >>> argument types introduced in
On 6/18/19 2:38 AM, Christophe Lyon wrote:
On Fri, 14 Jun 2019 at 03:35, Jeff Law wrote:
On 6/13/19 1:10 PM, Martin Sebor wrote:
Attached is a fix for the fold_build call with inconsistent
argument types introduced in a recent commit of mine.
Tested on x86_64-linux.
Martin
gcc-90662.diff
On 18/06/19 13:58 +0200, Christophe Lyon wrote:
On Mon, 17 Jun 2019 at 15:21, Jonathan Wakely wrote:
On 13/06/19 22:41 +0200, Christophe Lyon wrote:
>Hi,
>
>
>On Wed, 12 Jun 2019 at 16:54, Jonathan Wakely wrote:
>>
>> The std::to_chars functions from C++17 can be used to implement
>> std::to_
Wilco Dijkstra writes:
> > +/* If X is a positive CONST_DOUBLE with a value that is the reciprocal of
> a
> > + power of 2 (i.e 1/2^n) return the number of float bits. e.g. for
> x==(1/2^n)
> > + return n. Otherwise return -1. */
> > +int
> > +aarch64_fpconst_pow2_recip (rtx x)
> > +{
On Mon, Jun 17, 2019 at 08:04:42PM -0400, Michael Meissner wrote:
> --- gcc/config/rs6000/rs6000.md (revision 272270)
> +++ gcc/config/rs6000/rs6000.md (working copy)
> @@ -267,7 +267,9 @@ (define_attr "cpu"
>(const (symbol_ref "(enum attr_cpu) rs6000_tune")))
>
> ;; The ISA we i
On 5/10/19 10:31 AM, Martin Jambor wrote:
> Thanks in advance for any questions, comments and suggestions,
Hi.
I have just a small note that I would appreciate a dbgcnt for the future.
I bet it will be useful for a test-case reduction.
Thank you,
Martin
On Mon, 17 Jun 2019 at 15:21, Jonathan Wakely wrote:
>
> On 13/06/19 22:41 +0200, Christophe Lyon wrote:
> >Hi,
> >
> >
> >On Wed, 12 Jun 2019 at 16:54, Jonathan Wakely wrote:
> >>
> >> The std::to_chars functions from C++17 can be used to implement
> >> std::to_string with much better performanc
On 18/06/19 12:39 +0100, Jonathan Wakely wrote:
* include/c_global/cstddef (std::byte): Perform arithmetic operations
in unsigned int to avoid promotion (LWG 2950).
Tested x86_64-linux, committed to trunk.
I don't see any great need to backport this, because I don't think the
c
* include/c_global/cstddef (std::byte): Perform arithmetic operations
in unsigned int to avoid promotion (LWG 2950).
Tested x86_64-linux, committed to trunk.
commit bfa356b2a9353d1f0b7ccc38f3787d5a4f3044ae
Author: redi
Date: Tue Jun 18 11:39:43 2019 +
Avoid undefined
On Mon, Jun 17, 2019 at 05:24:37PM -0400, Michael Meissner wrote:
> I wrote the code to generate LFIWAX and LFIWZX originally for the power7 in
> the
> 2010 time frame. At the time, we did not allow SImode to go into floating
> point and vector registers. As part of the power9 work, we now allow
Hi,
And a few more comments:
> +/* If X is a positive CONST_DOUBLE with a value that is the reciprocal of a
> + power of 2 (i.e 1/2^n) return the number of float bits. e.g. for
> x==(1/2^n)
> + return n. Otherwise return -1. */
> +int
> +aarch64_fpconst_pow2_recip (rtx x)
> +{
> +
Hi.
It's quite some time the discussion has started. Now is time for me to refresh
IPA ICF
and I would like integrate operand_equal_p with what I currently have in ICF
(::compare_operand).
I like the idea of a class that will provide both operand_equal_valueize and
hash_operand_valueize.
These
On 18/06/19 07:52 +0200, François Dumont wrote:
A small regression noticed while merging.
We shouldn't keep on using a moved-from key_type instance.
Ok to commit ? Feel free to do it if you prefer, I'll do so at end of
Europe day otherwise.
diff --git a/libstdc++-v3/include/bits/hashtable_
On 6/18/19 12:33 PM, Jakub Jelinek wrote:
> On Tue, Jun 18, 2019 at 12:27:31PM +0200, Martin Liška wrote:
>>> Oops. The problematic case is then if the STRING_CST c_getstr finds
>>> is not NUL terminated (dunno if we ever construct that) or if
>>> string_size is smaller than string_length and ther
On 07/06/2019 17:03, Szabolcs Nagy wrote:
> Move the ifunc symbol tests into a separate file with dg-require-ifunc.
> And added a base pcs ifunc symbol to the test for completeness.
>
> gcc/testsuite/ChangeLog:
>
> 2019-06-07 Szabolcs Nagy
>
> * gcc.target/aarch64/pcs_attribute-2.c: Rem
On 18/06/2019 10:11, Joel Hutton wrote:
> Hi,
>
> On 13/06/2019 18:26, Wilco Dijkstra wrote:
>> Wouldn't it be easier to just do exact_log2 (real_to_integer (&r0))
>> and then check the range is in 1..31?
> I've revised this section.
>> --- a/gcc/config/aarch64/aarch64.md
>> +++ b/gcc/config/aarch
On Tue, Jun 18, 2019 at 12:27:31PM +0200, Martin Liška wrote:
> > Oops. The problematic case is then if the STRING_CST c_getstr finds
> > is not NUL terminated (dunno if we ever construct that) or if
> > string_size is smaller than string_length and there are no NULs in that
> > size.
>
> The fun
On 6/18/19 12:16 PM, Jakub Jelinek wrote:
> On Tue, Jun 18, 2019 at 11:56:41AM +0200, Martin Liška wrote:
>> On 6/18/19 10:23 AM, Martin Liška wrote:
>>> On 6/18/19 10:11 AM, Jakub Jelinek wrote:
On Tue, Jun 18, 2019 at 10:07:50AM +0200, Martin Liška wrote:
> diff --git a/gcc/builtins.c b/
On 6/18/19 3:45 AM, Xiong Hu Luo wrote:
> 6.2. SPEC2017 peakrate:
> 523.xalancbmk_r (+4.87%); 538.imagick_r (+4.59%); 511.povray_r
> (+13.33%);
> 525.x264_r (-5.29%).
Can you please elaborate what are the key indirect call promotions that are
needed
to achieve such a signifi
On 6/18/19 12:07 PM, Segher Boessenkool wrote:
> On Tue, Jun 18, 2019 at 11:34:03AM +0200, Martin Liška wrote:
>> I've got it. So it's situation where you have distribution equal to 50% and
>> 50%. Note that it's
>> the only valid situation where both edges with be >= 50%. That's the
>> threshold
On Tue, Jun 18, 2019 at 11:56:41AM +0200, Martin Liška wrote:
> On 6/18/19 10:23 AM, Martin Liška wrote:
> > On 6/18/19 10:11 AM, Jakub Jelinek wrote:
> >> On Tue, Jun 18, 2019 at 10:07:50AM +0200, Martin Liška wrote:
> >>> diff --git a/gcc/builtins.c b/gcc/builtins.c
> >>> index 3463ffb1539..b58e1
On Tue, Jun 18, 2019 at 11:34:03AM +0200, Martin Liška wrote:
> I've got it. So it's situation where you have distribution equal to 50% and
> 50%. Note that it's
> the only valid situation where both edges with be >= 50%. That's the
> threshold for which
> we speculatively devirtualize edges.
Bu
On 6/18/19 10:23 AM, Martin Liška wrote:
> On 6/18/19 10:11 AM, Jakub Jelinek wrote:
>> On Tue, Jun 18, 2019 at 10:07:50AM +0200, Martin Liška wrote:
>>> diff --git a/gcc/builtins.c b/gcc/builtins.c
>>> index 3463ffb1539..b58e1e58d4d 100644
>>> --- a/gcc/builtins.c
>>> +++ b/gcc/builtins.c
>>> @@ -
On 6/18/19 11:02 AM, luoxhu wrote:
> Hi,
>
> On 2019/6/18 13:51, Martin Liška wrote:
>> On 6/18/19 3:45 AM, Xiong Hu Luo wrote:
>>
>> Hello.
>>
>> Thank you for the interest in the area.
>>
>>> This patch aims to fix PR69678 caused by PGO indirect call profiling bugs.
>>> Currently the default ins
[ was: Re: [nvptx] Fix missing mode warnings in nvptx.md, omp part ]
On 17-06-19 17:09, Jakub Jelinek wrote:
> On Mon, Jun 17, 2019 at 04:53:24PM +0200, Tom de Vries wrote:
>> Updated accordingly, and committed as attached.
>
> Note, current trunk allows one to define expanders that take mode as
Hi,
Atm we see:
...
libgcc/config/nvptx/crt0.c:36:1: warning: no previous prototype for \
‘__main’ [-Wmissing-prototypes]
...
Fix this by adding the prototype.
Build and reg-tested on nvptx.
Build and reg-tested on x86_64 with nvptx accelerator.
Committed to trunk.
Thanks,
- Tom
[nvptx] Fix
On Tue, Jun 18, 2019 at 10:57 AM Richard Sandiford
wrote:
>
> r272233 changed the handling of fully-masked loops so that the IV type
> can be wider than the comparison type. However, it also hard-coded the
> IV step to VF, whereas for SLP groups it needs to be VF * group size.
> This introduced e
Hi,
On 13/06/2019 18:26, Wilco Dijkstra wrote:
> Wouldn't it be easier to just do exact_log2 (real_to_integer (&r0))
> and then check the range is in 1..31?
I've revised this section.
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -6016,6 +6016,40 @@
> [(set_a
Hi,
On 2019/6/18 13:51, Martin Liška wrote:
On 6/18/19 3:45 AM, Xiong Hu Luo wrote:
Hello.
Thank you for the interest in the area.
This patch aims to fix PR69678 caused by PGO indirect call profiling bugs.
Currently the default instrument function can only find the indirect function
that cal
Hi.
The patch is quite obvious, it copies the same what we do in
another IPA passes.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-06-18 Martin Liska
PR middle-end/90899
* multiple_target.c (
r272233 changed the handling of fully-masked loops so that the IV type
can be wider than the comparison type. However, it also hard-coded the
IV step to VF, whereas for SLP groups it needs to be VF * group size.
This introduced execution failures for gcc.target/aarch64/sve/slp_*_run.c
(and over 10
For very old toolchains, the compiler generated extra symbols that mark the
start of each FDE since the linker couldn’t determine the boundaries otherwise.
We no longer need this (since xcode 3 era). Since we have detection of the
linker
version, we can use that directly to determine if support
2019-06-18 Uroš Bizjak
* gcc.target/i386/pr81563.c (dg-final): Check that no
registers are restored from %esp.
Tested on x86_64-linux-gnu {,-m32}.
Will be committed later today.
Uros.
diff --git a/gcc/testsuite/gcc.target/i386/pr81563.c
b/gcc/testsuite/gcc.target/i386/pr81563.c
inde
1 - 100 of 110 matches
Mail list logo
