On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> Here's an updated version of the analyzer patch kit.
I've rebased (to r280067) and applied various fixes to the kit; I've
pushed a v6 of the kit to the dmalcolm/analyzer branch of the git
mirror (along with various followups):
https://gcc.g
On Thu, 2020-01-09 at 11:56 +, Jonathan Wakely wrote:
> On 08/01/20 18:47 -0500, David Malcolm wrote:
> > On Wed, 2019-12-04 at 10:59 -0700, Martin Sebor wrote:
> > > On 11/15/19 6:23 PM, David Malcolm wrote:
> > > > This patch adds an ordered_hash_map template, which is similar
> > > > to
> >
On Wed, 2020-01-08 at 17:07 -0500, David Malcolm wrote:
[...]
> Here's an alterative patch to the above that replaces the
> "-fdiagnostics-nn-line-numbers" option in earlier versions of the
> analyzer patch kit, by doing it at the DejaGnu level instead.
[...]
> I'm testing this now (but it seems t
On Wed, 2019-12-11 at 13:04 -0700, Jeff Law wrote:
> On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote:
> > This patch adds exploded_graph and related classes, for managing
> > exploring paths through the user's code as a directed graph
> > of pairs.
> >
> > gcc/ChangeLog:
> > * analyzer
On Wed, 2019-12-11 at 12:23 -0700, Jeff Law wrote:
> On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote:
> > This patch adds a "state_machine" base class for describing
> > API checkers in terms of state machine transitions. Followup
> > patches use this to add specific API checkers.
> >
> >
PR analyzer/93212 reports an ICE when attempting to use -fanalyzer
on a C++ source file. That isn't supported yet, but the fix is
trivial (handling METHOD_TYPE as well as FUNCTION_TYPE).
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to the dmalcolm/analyzer branch on the G
On Tue, 7 Jan 2020 11:21:38 +0100
Tobias Burnus wrote:
> Hi Julian,
>
> please hold back the commit.
>
> Actually, it does not seem to work if one modifies the test
> case a bit. The following code compiles – but I think it
> should not:
>
> type one
>integer i, j
> end type
> type two
>
Hi,
This patch fixes a bug with mapping Fortran components (i.e. with the
manual deep-copy support) which themselves have derived types. I've
also added a couple of new tests to make sure such mappings are lowered
correctly, and to check for the case that Tobias found in the message:
https://gc
While this patch is similar in spirit to V11 #15, I lost that patch, and I
re-implemented the check. Can I check this test into the trunk?
2020-01-09 Michael Meissner
* gcc.target/powerpc/vec-extract-large-si.c: New test for
vec_extract from a vector unsigned int in memory wit
This patch is the same as:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01504.html
This patch adds some tests to validate the work in patches V12 #1-4 generate
the correct code with vec_extract is used with a vector with a PC-relative
address and -mcpu=future is used. Can I check this into the t
This patch is the same as:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01503.html
This patch adds a new test to test that -fstack-protect-strong generates the
correct code when a large stack is used and the compiler option -mcpu=future is
also used. Can I check this into the trunk?
This is a b
This patch is the same as:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01501.html
This patch adds a set of tests for each type to verify that the appropriate
PC-relative instructions are generated when -mcpu=future is used. Can I check
this patch into the trunk?
2020-01-09 Michael Meissner
This patch is the same as:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01500.html
This patch adds one test per type validating that we generate the appropriate
prefixed instructions to load/store the type when the offset if large. Can I
check this into the trunk?
2020-01-09 Michael Meissner
This patch is the same as:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01499.html
It adds a new test to make sure if we are using a prefixed load or store
instruction, the compiler does not try to use a load with update or store with
update version of the isntruction, since there are no prefixed
This patch is the same as:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01497.html
It adds a test to validate that the compiler will now generate a prefixed load
or store instead of loading up an offset that would be illegal for DS/DQ-FORM
instructions. Can I check this into the trunk?
2020-01-
This patch adds new tests for the compiler generating PLI or PADDI with large
constants when -mcpu=future is used. It renames the files as you requested
several patch generations ago so the -fident option doesn't give a false
positive result. Can I check this patch into the trunk?
2020-01-09 Mi
This patch is the same as V11, #7:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01495.html
This patch adds the necessary options to target-supports.exp to enable the
specific target supports for -mcpu=future. It contains changes that you asked
for some time ago. Can I check this into the trunk?
This patch is the same as patch V11 #6:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01494.html
Assuming patches 1-4 are applied, it fixes all of the known codegen bugs with
the -mcpu=future support, and so it is time to make -mpcrel default on the one
system that will support PC-relative address
This patch folds a PC-relative vector address that is adjusted with a constant
offset, to fold the constant into the PC-relative address. I moved this code
to be a separate function to make it clearer what the steps were. With patch
V12 #3, address_to_insn_form is now used to validate the address
On 1/9/20 4:51 PM, Segher Boessenkool wrote:
> On Thu, Jan 09, 2020 at 01:44:59PM -0600, Peter Bergner wrote:
>> The other test cases just need a slight adjustment to some of their
>> counts.
>
> What were the changes? Or, I'll just trust you looked at it and it is
> okay :-)
I did look. Most o
In the patches:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01530.html
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01533.html
Segher said the whole code was too complex. This patch is my attempt to make
it somewhat easier to understand.
One part that is an issue was there was a section of co
In https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01530.html, Seghar had some
questions about that patch.
This patch addresses some of those concerns.
Instead of limiting the vector element number in rs6000_split_vec_extract_var
so that the memory access does not go out of bounds, I decided to mov
In https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01530.html, Segher asked me to
do the gcc_asserts as early as possible.
This patch makes sure the base register temporary is not used in the other
arguments.
I have built and bootstrapped a compiler on a little endian power8 system, and
there were
This libgo patch compiles examples in _test packages. Previously if
the only names defined by _test packages were examples, the gotest
script would emit an incorrect _testmain.go file. I worked around
that by marking the example_test.go files +build ignored. This CL
changes the gotest script to
Hi!
On Thu, Jan 09, 2020 at 01:44:59PM -0600, Peter Bergner wrote:
> The other test cases just need a slight adjustment to some of their
> counts.
What were the changes? Or, I'll just trust you looked at it and it is
okay :-)
> were seeing double/triple/... counting due to using "xxland" instea
This is version 12 of my patches for PowerPC -mcpu=future. There are currently
14 patches. Note, the PCREL_OPT patches are not part of this series. I want
to concentrate on getting the other patches checked in.
Patches #1-4 reflect changes that were asked for in the previous (V11) set of
patche
On 1/9/20 4:37 PM, Jakub Jelinek wrote:
On Thu, Jan 09, 2020 at 04:27:09PM -0500, Jason Merrill wrote:
Isn't the right spot to fix this somewhere in cp_gimplify_expr?
I mean, the way gimplification works, we unshare_body first and then
gimplify, which is destructive for the GENERIC it is gimplif
On Thu, Jan 09, 2020 at 04:27:09PM -0500, Jason Merrill wrote:
> > Isn't the right spot to fix this somewhere in cp_gimplify_expr?
> > I mean, the way gimplification works, we unshare_body first and then
> > gimplify, which is destructive for the GENERIC it is gimplifying. The
> > reason why this
The equality operators for _ExtPtr_allocator are defined as non-const
member functions, which causes ambiguities in C++20 due to the
synthesized operator!= candidates. They should always have been const.
The _Pointer_adapter class template has both value_type and element_type
members, which makes
On 1/9/20 3:59 AM, Jakub Jelinek wrote:
On Thu, Jan 09, 2020 at 02:20:23PM +0800, Bin.Cheng wrote:
On December 20, 2019 2:13:47 AM GMT+01:00, "Bin.Cheng"
wrote:
On Fri, Dec 13, 2019 at 11:26 AM bin.cheng
wrote:
Hi,
As reported in PR92926, constant ctor is shared translation unit wide
bec
On 09/01/20 19:57 +, Jonathan Wakely wrote:
I'll commit the attached patch after more testing.
And this follow-up to fix some fallout.
commit 212e166cbeb4c7df38436563c3c51dbd4e0efc0d
Author: Jonathan Wakely
Date: Thu Jan 9 19:55:17 2020 +
libstdc++: Fix testsuite failures and
Hi!
Jakub, please see one question below.
On 2019-12-24T15:23:56+0100, Tobias Burnus wrote:
> OK for the trunk?
Tobias, thanks for taking over this patch. I have a few additional small
changes that I'd like to do (have WIP patches already), but what we've
got here already is OK for trunk with
Hi Tobias,
I am not completely happy about the introduction of yet another two
global variables, but I also do not see an easy way out. Hence: OK.
Actually, I wasn't too happy myself, but, like you, I didn't find
anything better.
I was playing around with the following test case – you might c
Hi Maciej,
On 1/6/20 4:25 PM, Maciej W. Rozycki wrote:
Without the patch, the compiler is found (with [find_gcc] I suppose) and
invoked as x86_64-none-linux-gnu-gcc. That works fine for us, but we do
(I think) "installed testing", which IIUC is atypical.
[…]
However before I make any definite
On 09/01/20 19:43 +, Iain Sandoe wrote:
Hi Jonathan,
thanks for the review - hopefully the attached addresses both those
and the whitespace differences we discussed off-line.
I’m attaching the header as a textfile since it’s a new one, perhaps
that will make it easier to review the whitespa
On 09/01/20 20:09 +0100, Olivier Hainque wrote:
Hi Jonathan,
Yes, this is fine in principle. Please update the docs and change
_Mt to _Cmp2 though.
Sure, will adjust, test and follow up.
Revised patch attached. Bootstrapped and regression tests
fine on x86_64-linux.
2020-01-09 Olivier Hai
On 04/12/19 17:56 -0500, JeanHeyd Meneide wrote:
Dear Jonathan,
Done! re-patched, below.
Thanks!
Some comments below.
Best,
JeanHeyd
2019-12-03 JeanHeyd "ThePhD" Meneide
* include/bits/c++config: Add new _GLIBCXX20_DEPRECATED macro.
* include/std/type_traits: Deprecate
My fix to PR92923 seems to have caused the vmx/ops.c and vsx-vector-6.p*.c
test failures. The ops.c issue is we need a new option to quiet a warning
we didn't see when we were emitting VIEW_CONVERT_EXPRs. The other test
cases just need a slight adjustment to some of their counts. However, we
wer
Hi Jonathan,
thanks for the review - hopefully the attached addresses both those
and the whitespace differences we discussed off-line.
I’m attaching the header as a textfile since it’s a new one, perhaps
that will make it easier to review the whitespace stuff.
thanks
Iain
Jonathan Wakely wrote
Hi Jonathan,
>> Yes, this is fine in principle. Please update the docs and change
>> _Mt to _Cmp2 though.
>
> Sure, will adjust, test and follow up.
Revised patch attached. Bootstrapped and regression tests
fine on x86_64-linux.
2020-01-09 Olivier Hainque
libstdc++-v3/
* doc
On Jan 9, 2020, Richard Biener wrote:
> Did I miss the actual (non-documentation) patch?
No, I didn't post it. It's kind of big, and only yesterday did I get it
to work as expected and now extensively documented, passing all of the
extensive testsuite I wrote for it.
Alas, some of the latest
Hello again,
On Fri, Jan 03 2020, Martin Jambor wrote:
> Hi,
>
> On Thu, Dec 19 2019, Jan Hubicka wrote:
>>> On 2019/12/18 23:48, Jan Hubicka wrote:
>>> >> The size_info of ipa_size_summary are created by r277424. It should be
>>> >> duplicated for cloned nodes, otherwise self_size and
>>> >> es
It helps the SVE2 ACLE support if aarch64_sve_arith_immediate_p and
aarch64_sve_sqadd_sqsub_immediate_p accept scalars as well as vectors.
Tested on aarch64-linux-gnu and applied as r280059.
Richard
2020-01-09 Richard Sandiford
gcc/
* config/aarch64/aarch64-protos.h (aarch64_sve_ari
Given the proposed intention to use non-standard refspecs for private
and vendor branches I've written some notes on how to use these.
It would be helpful if someone could do some experiments to ensure that
what I've written works properly for all versions of git, not just the
one I have insta
The deserialization functions for random number distributions fail to
check the stream state before using the extracted values. In some cases
this leads to using indeterminate values to resize a vector, and then
filling that vector with indeterminate values.
No values that affect control flow shou
This patch imposes the same sort of structure on aarch64-sve2.md
as we already have for aarch64-sve.md, before it grows a lot more
patterns.
Tested on aarch64-linux-gnu and applied as 280058.
Richard
2020-01-09 Richard Sandiford
gcc/
* config/aarch64/aarch64-sve2.md: Add banner comm
Matthew Malcomson writes:
> We take no action to ensure the SVE vector size is large enough. It is
> left to the user to check that before compiling this intrinsic or before
> running such a program on a machine.
>
> The main difference between ld1ro and ld1rq is in the allowed offsets,
> the imp
This patch changes the Go frontend to not localize names in export
data. Localizing these names causes the compiler output to change
depending on the LANG environment variable, so don't do it.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofr
On 1/9/20 4:07 PM, Richard Sandiford wrote:
> Stam Markianos-Wright writes:
>> diff --git a/gcc/testsuite/g++.target/aarch64/bfloat_cpp_typecheck.C
>> b/gcc/testsuite/g++.target/aarch64/bfloat_cpp_typecheck.C
>> new file mode 100644
>> index 000..55cbb0b0ef7
>> --- /dev/null
>> +++ b/gc
Stam Markianos-Wright writes:
> diff --git a/gcc/testsuite/g++.target/aarch64/bfloat_cpp_typecheck.C
> b/gcc/testsuite/g++.target/aarch64/bfloat_cpp_typecheck.C
> new file mode 100644
> index 000..55cbb0b0ef7
> --- /dev/null
> +++ b/gcc/testsuite/g++.target/aarch64/bfloat_cpp_typecheck.C
This patch to the Go frontend avoids adding composite literal keys to
the package bindings. Doing this gets confusing when it is combined
with dot imports. The test case showing the resulting compilation
failure is https://golang.org/cl/213899.
Fix this by adding a new expression type to hold co
Please update the names of the testsuite files to match the ones
in the bfloat16_t patch. (Same for the usdot/sudot patch -- sorry
for forgetting there.)
OK with that change, thanks.
Richard
Stam Markianos-Wright writes:
> On 12/30/19 10:29 AM, Richard Sandiford wrote:
>> Stam Markianos-Wright
We take no action to ensure the SVE vector size is large enough. It is
left to the user to check that before compiling this intrinsic or before
running such a program on a machine.
The main difference between ld1ro and ld1rq is in the allowed offsets,
the implementation difference is that ld1ro i
OK, thanks.
Richard
Stam Markianos-Wright writes:
> On 12/30/19 10:21 AM, Richard Sandiford wrote:
>> Stam Markianos-Wright writes:
>>> On 12/20/19 2:13 PM, Richard Sandiford wrote:
Stam Markianos-Wright writes:
> +**...
> +**ret
> +*/
> +int32x2_t ufoo (int32x2_t r, uint8
Thanks for the update, looks great.
Stam Markianos-Wright writes:
> diff --git a/gcc/config/aarch64/arm_bf16.h b/gcc/config/aarch64/arm_bf16.h
> new file mode 100644
> index
> ..884b6f3bc7a28c516e54c26a71b1b769f55867a7
> --- /dev/null
> +++ b/gcc/config/aa
Iain Sandoe writes:
> The coroutines implementation introduces a new operator with a
> mangling of 'aw'. This patch adds that to libiberty's demangler.
>
> Although this is presented as part of the coroutines patch series
> it could stand alone, since clang and EDG-based compilers are
> already
I'd made WHILERW and WHILEWR use separate patterns from the SVE
WHILE instructions, but they're similar enough that we can use
a single pattern. This means that we also get the flag-related
patterns "for free".
Tested on aarch64-linux-gnu and applied as r280054.
Richard
2020-01-09 Richard San
The UNSPEC_WHILE*s had an underscore before the condition code,
whereas almost all other SVE unspecs are taken directly from
the mnemonic.
Tested on aarch64-linux-gnu and applied as r280053.
Richard
2020-01-09 Richard Sandiford
gcc/
* config/aarch64/aarch64.md (UNSPEC_WHILE_LE): Ren
The SVE ACLE shape names use "_int" and "_uint" for arguments that are
signed-integer or unsigned-integer variants of the main vector type.
With SVE2 this variation also becomes common for return values,
which the main SVE2 patch handles using "_to_int" and "_to_uint".
This patch renames the existi
This patch generalises some boilerplate that becomes much more
common with SVE2 intrinsics.
Tested on aarch64-linux-gnu and applied as r280051.
Richard
2020-01-09 Richard Sandiford
gcc/
* config/aarch64/aarch64-sve-builtins-functions.h
(code_for_mode_function): New class.
The pattern:
;; q
(define_insn "aarch64_"
[(set (match_operand:VSDQ_I 0 "register_operand" "=w")
(BINQOPS:VSDQ_I (match_operand:VSDQ_I 1 "register_operand" "w")
(match_operand:VSDQ_I 2 "register_operand" "w")))]
"TARGET_SIMD"
"\\t%0, %1, %2"
[(set_attr "t
We've had skeleton support for "SRHSUB" and "URHSUB" since the initial
commit of the port, but no such instructions exist.
Tested on aarch64-linux-gnu and applied as 280049.
Richard
2020-01-09 Richard Sandiford
gcc/
* config/aarch64/iterators.md (SRHSUB, URHSUB): Delete.
(HA
On 1/7/20 5:14 PM, Richard Sandiford wrote:
> Thanks for the update. The new patch looks really good, just some
> minor comments.
>
> Stam Markianos-Wright writes:
>> [...]
>> Also I've update the filenames of all our tests to make them a bit clearer:
>>
>> C tests:
>>
>> __ bfloat16_scalar_co
On 1/7/20 3:26 PM, Richard Sandiford wrote:
> Stam Markianos-Wright writes:
>> On 12/19/19 10:08 AM, Richard Sandiford wrote:
>>> Stam Markianos-Wright writes:
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index f57469b6e23..f40f6432fd4 100644
--- a/gcc
On 12/30/19 10:29 AM, Richard Sandiford wrote:
> Stam Markianos-Wright writes:
>> diff --git a/gcc/config/aarch64/aarch64-simd.md
>> b/gcc/config/aarch64/aarch64-simd.md
>> index
>> adfda96f077075ad53d4bea2919c4d3b326e49f5..7587bc46ba1c80389ea49fa83a0e6f8a489711e9
>> 100644
>> --- a/gcc/confi
On 12/30/19 10:21 AM, Richard Sandiford wrote:
> Stam Markianos-Wright writes:
>> On 12/20/19 2:13 PM, Richard Sandiford wrote:
>>> Stam Markianos-Wright writes:
+**...
+**ret
+*/
+int32x2_t ufoo (int32x2_t r, uint8x8_t x, int8x8_t y)
+{
+ return vusdot_s32 (r, x,
Hello Jonathan,
> On 09 Jan 2020, at 14:26, Jonathan Wakely wrote:
>
> Any conflict with OS headers is treated as a libstdc++ bug. We don't
> own the entire implementation namespace, so we have to play nice and
> avoid OS names.
> We maintain a list of identifiers to avoid, but _C2 is currently
On 1/9/20 9:24 PM, Jeff Law wrote:
On Wed, 2020-01-08 at 17:23 +, Martin Sebor wrote:
A recent improvement to the vectorizer (r278334 if my bisection
is right) can transform multiple stores to adjacent struct members
into single vectorized assignments that write over all the members
in a sin
On Thu, Jan 9, 2020 at 2:35 PM Kwok Cheung Yeung wrote:
>
> Hello
>
> On 09/12/2019 8:01 am, Richard Biener wrote:
> >
> > The stream-in code has
> >
> >/* If we're recompiling LTO objects with debug stmts but
> > we're not supposed to have debug stmts, remove them now.
>
On Thu, Jan 9, 2020 at 1:38 PM Iain Sandoe wrote:
>
> Hi Richard,
>
> The SVN commit IDs that address changes to this part of the patchset are noted
> in the revised patch header below, for reference.
>
> Richard Biener wrote:
>
> > On Sun, Nov 17, 2019 at 11:27 AM Iain Sandoe wrote:
>
> >> On
Committed as obvious (r280046). I will backport to GCC 8 + 9 in the next
days.
* * *
Background – slightly more convoluted than the actual patch :-)
If the to-be-used array spec ("to") has a codimension, one needs to move
it to the right such that the shape for the regular-array dimension fit
Hello
On 09/12/2019 8:01 am, Richard Biener wrote:
The stream-in code has
/* If we're recompiling LTO objects with debug stmts but
we're not supposed to have debug stmts, remove them now.
We can't remove them earlier because this would cause uid
On 09/01/20 12:39 +, Iain Sandoe wrote:
Hi Jonathan
The SVN commit IDs that relate to the amendments are noted in the
revised patch header below.
Jonathan Wakely wrote:
On 17/11/19 10:27 +, Iain Sandoe wrote:
* include/Makefile.in: Regnerated.
"Regnerated" typo.
Fixed,
On Thu, 26 Dec 2019, Alexandre Oliva wrote:
> On Dec 25, 2019, Alexandre Oliva wrote:
>
> > 3. do not take the executable name into account when it shares the
> > basename with an input file; combine executable basename with input name
> > otherwise. this makes gcc -o foo[.exe] -g -gsplit-dwarf
On Wed, Dec 11, 2019 at 5:55 PM Wilco Dijkstra wrote:
>
> Hi Richard,
>
> >> +(match (ctz_table_index @1 @2 @3)
> >> + (rshift (mult (bit_and (negate @1) @1) INTEGER_CST@2) INTEGER_CST@3))
> >
> > You need a :c on the bit_and
>
> Fixed.
>
> > + unsigned HOST_WIDE_INT val = tree_to_uhwi (mulc);
>
On 09/01/20 14:00 +0100, Olivier Hainque wrote:
Hello,
The attached patch is a proposal to simply rename a template
type name in stl_map.h and stl_multimap.h in order to prevent
clashes with a macro name exposed by a system header on VxWorks.
The conflicting name is _C2, which in principle is "
On Tue, Jan 7, 2020 at 11:33 AM Richard Sandiford
wrote:
>
> Richard Sandiford writes:
> > Richard Biener writes:
> >> On December 14, 2019 11:43:48 AM GMT+01:00, Richard Sandiford
> >> wrote:
> >>>Richard Biener writes:
> On December 13, 2019 10:12:40 AM GMT+01:00, Richard Sandiford
> >
This prevents the vtables and RTTI from being emitted in every object
file that uses memory_resource and monotonic_buffer_resource.
Objects compiled by GCC 9.1 or 9.2 will contain inline definitions of
the destructors, vtable and RTTI, but this is harmless. The inline
definitions have identical ef
Hello,
The attached patch is a proposal to simply rename a template
type name in stl_map.h and stl_multimap.h in order to prevent
clashes with a macro name exposed by a system header on VxWorks.
The conflicting name is _C2, which in principle is "reserved"
for the system so having such a macro ex
Hi Ian,
The coroutines implementation introduces a new operator with a
mangling of 'aw'. This patch adds that to libiberty's demangler.
Although this is presented as part of the coroutines patch series
it could stand alone, since clang and EDG-based compilers are
already emitting this mangling.
Hi Jonathan
The SVN commit IDs that relate to the amendments are noted in the
revised patch header below.
Jonathan Wakely wrote:
> On 17/11/19 10:27 +, Iain Sandoe wrote:
>> * include/Makefile.in: Regnerated.
>
> "Regnerated" typo.
Fixed,
>> ${experimental_srcdir}/chrono \
>> +
Hi Richard,
The SVN commit IDs that address changes to this part of the patchset are noted
in the revised patch header below, for reference.
Richard Biener wrote:
> On Sun, Nov 17, 2019 at 11:27 AM Iain Sandoe wrote:
>> Once we have remade the connections to their correct postions, we elide
Jeff Law wrote:
> On 11/17/19 3:24 AM, Iain Sandoe wrote:
>> This part of the patch series provides the gating flag, the keywords,
>> cpp defines etc.
>>
>> gcc/ChangeLog:
>>
>> 2019-11-17 Iain Sandoe
>>
>> * doc/invoke.texi: Document the fcoroutines command line
>> switch.
>>
>>
Jeff Law wrote:
> On 11/17/19 3:24 AM, Iain Sandoe wrote:
>> This part of the patch series provides the builtin functions
>> used by the standard library code and the internal functions
>> used to implement lowering of the coroutine state machine.
>>
>> gcc/ChangeLog:
>>
>> 2019-11-17 Iain San
Nathan Sidwell wrote:
> On 11/17/19 5:23 AM, Iain Sandoe wrote:
>> This patch series is an initial implementation of a coroutine feature,
>> expected to be standardised in C++20.
This is the updated set after fixing review comments (both from folks on-list
and
some private communications) and a
On 1/9/20 12:06 PM, Jan Hubicka wrote:
2020-01-03 Martin Liska
* auto-profile.c (auto_profile): Use opt_for_fn
for a parameter.
* ipa-cp.c (ipcp_lattice::add_value): Likewise.
(propagate_vals_across_arith_jfunc): Likewise.
(hint_time_bonus): Likewise.
Ping.
Thanks,
Martin
On Mon, Dec 16 2019, Martin Jambor wrote:
> Hi,
>
> since r278669 (fix for PR ipa/91956), IPA-SRA makes sure that the clone
> it creates is put into the same same_comdat as the original cgraph_node,
> so that it can call private comdats (such as the ipa-split bits of a
> com
On Thu, Jan 9, 2020 at 11:17 AM Bin.Cheng wrote:
>
> On Wed, Jan 8, 2020 at 7:50 PM Richard Biener
> wrote:
> >
> > On Wed, Jan 8, 2020 at 12:30 PM Bin.Cheng wrote:
> > >
> > > On Wed, Jan 8, 2020 at 6:31 PM Richard Biener
> > > wrote:
> > > >
> > > > On Wed, Jan 8, 2020 at 6:01 AM bin.cheng
On 08/01/20 18:47 -0500, David Malcolm wrote:
On Wed, 2019-12-04 at 10:59 -0700, Martin Sebor wrote:
On 11/15/19 6:23 PM, David Malcolm wrote:
> This patch adds an ordered_hash_map template, which is similar to
> hash_map, but preserves insertion order.
>
> gcc/ChangeLog:
>* Makefile.in (OBJ
On 1/8/20 5:14 PM, Martin Jambor wrote:
+ int unit_growth = opt_for_fn (node->decl, param_ipcp_unit_growth);
Sorry, but I renamed you the param to param_ipa_cp_unit_growth.
Which is a name that matches name conventions of other IPA CP
related parameters.
Please rebase the patch.
Thanks,
Marti
> 2020-01-03 Martin Liska
>
> * auto-profile.c (auto_profile): Use opt_for_fn
> for a parameter.
> * ipa-cp.c (ipcp_lattice::add_value): Likewise.
> (propagate_vals_across_arith_jfunc): Likewise.
> (hint_time_bonus): Likewise.
> (incorporate_penalties): Likew
Hello,
Gentle ping for
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01398.html
I realize and certainly understand that this is
of lower importance than other matters currently being discussed
on the lists.
It's just that the end of stage 3 is imminent and I thought
we'd better at least agre
The thread on gcc@ is now so long and complicated that this proposal
back at the start has dropped off the radar. With the switch now
imminent I'd like to re-propose this change, this time more formally.
The text below draws heavily on the glibc equivalent rules in an attempt
to bring some ha
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2020-01-09 Richard Biener
PR middle-end/93054
* gimplify.c (gimplify_expr): Deal with NOP definitions.
* gcc.dg/pr93054.c: New testcase.
Index: gcc/gimplify.c
==
On 12/12/19 3:35 PM, Jan Hubicka wrote:
Hi,
this rather nasty bug makes value and mask to be exchanged during
streaming. This makes us to sometimes set bogus pointer alignments
and causes misoptimization of Firefox when built with GCC 9.
Hi.
I've just prepare and tested backport for both GCC
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Richard.
2020-01-09 Richard Biener
PR tree-optimization/93040
* gimple-ssa-store-merging.c (find_bswap_or_nop): Raise search limit.
* gcc.dg/optimize-bswaphi-1.c: Amend.
* gcc.dg/optimize-bswapsi-2.c: Like
On Wed, Jan 8, 2020 at 7:50 PM Richard Biener
wrote:
>
> On Wed, Jan 8, 2020 at 12:30 PM Bin.Cheng wrote:
> >
> > On Wed, Jan 8, 2020 at 6:31 PM Richard Biener
> > wrote:
> > >
> > > On Wed, Jan 8, 2020 at 6:01 AM bin.cheng
> > > wrote:
> > > >
> > > > Sorry, here is the patch.
> > > > ---
> On 1/8/20 3:05 PM, Jan Hubicka wrote:
> > >
> > > >
> > > > I would still preffer invalidation before streaming (which is fully
> > > > deterministic) and possibly have option
> > >
> > > Do you mean __gcov_merge_topn?
> >
> > I suggest we do the following:
> >
> > - have non-deterministic
On 1/9/20 2:25 AM, luoxhu wrote:
On 2020/1/8 22:54, Martin Liška wrote:
diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index bd44063a1ac..789564ba335 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -1148,8 +1148,7 @@ symbol_table::materialize_all_clones (void)
if
On 08/01/2020 18:18, Kwok Cheung Yeung wrote:
Is this version okay for trunk?
OK, thanks.
Andrew
1 - 100 of 106 matches
Mail list logo
