Hi,
yesterday I noticed these and I regression tested the change together
with my fix for 83204. Can definitely wait, but seems very safe...
Cheers, Paolo.
///
2018-02-08 Paolo Carlini
* constexpr.c (cxx_eval_component_reference): Use INDIRECT_REF_P.
* lam
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Richard.
2018-02-08 Richard Biener
PR tree-optimization/84233
* tree-ssa-phiprop.c (propagate_with_phi): Use separate
changed flag instead of boguously re-using phi_inserted.
* g++.dg/torture/pr84233.C: New
Noticed while (still...) working on PR84038. The vectorizer happily
tries to construct a V4SFmode from two V2SFmode vectors because
there's an optab handler for it. But it failed to check whether
that mode is supported and RTL expansion later uses TYPE_MODE
to get at the element mode which ends
Jakub Jelinek writes:
> On Wed, Feb 07, 2018 at 03:23:25PM -0500, Jason Merrill wrote:
>> On Wed, Feb 7, 2018 at 2:48 PM, Jakub Jelinek wrote:
>> > On Wed, Feb 07, 2018 at 08:36:31PM +0100, Marek Polacek wrote:
>> >> > > That was my first patch, but it was rejected:
>> >> > > https://gcc.gnu.org/
On Thu, Feb 1, 2018 at 6:42 PM, Aldy Hernandez wrote:
> Since my patch isn't the easy one liner I wanted it to be, perhaps we
> should concentrate on Martin's patch, which is more robust, and has
> testcases to boot! His patch from last week also fixes a couple other
> PRs.
>
> Richard, would thi
On Sat, Feb 3, 2018 at 12:30 AM, Bill Schmidt
wrote:
> Hi,
>
> The test g++.dg/vect/slp-pr56812.cc is somewhat fragile and is currently
> failing
> on several targets. PR81038 notes that this began with r248678, which stopped
> some inferior peeling solutions from preventing vectorization that c
Hi David,
>> + /* PR 84195: Replace control characters in the message with their
>> + escaped equivalents. Allow newlines if -fmessage-length has
>> + been set to a non-zero value.
>
> I'm not quite sure why we allow newlines in this case, sorry.
Because the documentation
On 02/07/2018 11:38 PM, Jeff Law wrote:
On 02/06/2018 02:38 AM, Aldy Hernandez wrote:
The -Walloca pass can receive a malformed alloca, courtesy of someone
providing a faulty prototype. This was causing an ICE because we
assumed alloca calls had at least one argument, which the testcase does
Hi,
this one should be rather straightforward. As noticed by Jakub, we
started emitting the spurious warning with the fix for c++/69257, which,
among other things, fixed decay_conversion wrt mark_rvalue_use and
mark_lvalue_use calls. In particular it removed the mark_rvalue_use call
at the ve
On Mon, Feb 5, 2018 at 1:09 PM, Janne Blomqvist
wrote:
> On Sun, Feb 4, 2018 at 9:49 PM, Thomas Koenig wrote:
>> Hello world,
>>
>> in the attached patch, I have used flexible array members for
>> using the different descriptor types (following Richi's advice).
>> This does not change the binary
On Wed, Feb 7, 2018 at 1:01 PM, Andreas Krebbel
wrote:
> This patch implements GCC support for mitigating vulnerability
> CVE-2017-5715 known as Spectre #2 on IBM Z.
>
> In order to disable prediction of indirect branches the implementation
> makes use of an IBM Z specific feature - the execute in
In this PR, the reporter is complaining that forcing -static-libstdc++
and -static-libgcc during stage1 will also force it down to all
subdirectories (gdb for instance).
There is some back and forth in the PR whether this is good or not. I'm
indifferent, but an alternative is to provide a fla
On Fri, Feb 2, 2018 at 3:12 PM, Richard Sandiford
wrote:
> This patch is part 2 of the fix for PR 81635. It means that
> split_constant_offset can handle loops like:
>
> for (unsigned int i = 0; i < n; i += 4)
> {
> a[i] = ...;
> a[i + 1] = ...;
> }
>
> CCP records that "i"
Hi,
This patch contain cost model change for SKX and closes PR target/83008
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008)
It provides following performance scores in geomean:
SPEC CPU2017 intrate +0.6%
SPEC CPU2017 fprate +1.5%
SPEC 2006 [int|fp] no changes out of noise
I found a regressi
Hi Luis,
On 06/02/18 15:04, Luis Machado wrote:
Thanks for the feedback Kyrill. I've adjusted the v2 patch based on your
suggestions and re-tested the changes. Everything is still sane.
Thanks! This looks pretty good to me.
Since this is ARM-specific and fairly specific, i wonder if it would
On Thu, Feb 08, 2018 at 10:15:45AM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Wed, Feb 07, 2018 at 03:23:25PM -0500, Jason Merrill wrote:
> >> On Wed, Feb 7, 2018 at 2:48 PM, Jakub Jelinek wrote:
> >> > On Wed, Feb 07, 2018 at 08:36:31PM +0100, Marek Polacek wrote:
> >> >> > >
tlsdesc calls are guaranteed to preserve all Advanced SIMD registers,
but are not guaranteed to preserve the SVE extension of them.
The calls also don't preserve the SVE predicate registers.
The long-term plan for handling the SVE vector registers is CLOBBER_HIGH,
which adds a clobber equivalent o
Uros,
I provided a patch for cost model tuning here
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00405.html
Current patch fixes a regression in a test that caused my cost model tuning
patch.
Sergey
-Original Message-
From: Uros Bizjak [mailto:ubiz...@gmail.com]
Sent: Wednesday, Februar
Richard Biener writes:
> On Fri, Feb 2, 2018 at 3:12 PM, Richard Sandiford
> wrote:
>> Index: gcc/tree-data-ref.c
>> ===
>> --- gcc/tree-data-ref.c 2018-02-02 14:03:53.964530009 +
>> +++ gcc/tree-data-ref.c 2018-02-02 14:03:54.18
On 02/08/2018 12:33 PM, Richard Biener wrote:
> On Wed, Feb 7, 2018 at 1:01 PM, Andreas Krebbel
> wrote:
>> This patch implements GCC support for mitigating vulnerability
>> CVE-2017-5715 known as Spectre #2 on IBM Z.
>>
>> In order to disable prediction of indirect branches the implementation
>>
On Thu, Feb 08, 2018 at 12:55:10PM +0100, Jakub Jelinek wrote:
> On Wed, Feb 07, 2018 at 04:21:43PM -0500, Jason Merrill wrote:
> > On Wed, Feb 7, 2018 at 4:14 PM, Jakub Jelinek wrote:
> > > On Wed, Feb 07, 2018 at 03:52:39PM -0500, Jason Merrill wrote:
> > >> > E.g. the constexpr function uses
>
Hi Kyrill,
On 02/08/2018 09:48 AM, Kyrill Tkachov wrote:
Hi Luis,
On 06/02/18 15:04, Luis Machado wrote:
Thanks for the feedback Kyrill. I've adjusted the v2 patch based on your
suggestions and re-tested the changes. Everything is still sane.
Thanks! This looks pretty good to me.
Since thi
On Feb 7, 2018, Jason Merrill wrote:
> OK, that makes sense. But I'm still uncomfortable with choosing an
> existing opcode for that purpose, which previously would have been
> chosen just for reasons of encoding complexity and size.
Well, there's a good reason we didn't used to output this op
Hi,
it has been brought to my attention that libgomp.c/target-28.c
testcase fails to finalize because the static variable s has illegal
hsa allocation. Fixed by the patch below, which I am about to commit
to trunk (and will commit to the gcc-7-branch after testing there).
Thanks,
Martin
2018-0
Hi,
the PR82416 was not actually being compiled into HSAIL because the
function with target region had noclone attribute, which was the
outline function for the region inherited and then the ipa-hsa pass
that clones hitherto shared functions (for both the host and an
hsa accelerator) refused to cl
Hi,
it turns out that I have hit bit of can of worms here, so I spent most of
yesterday looking into minimal fix. There are multiple issues remaining - we
forget to output symbols that have only DECL_EXTERNAL flag set; we behave funny
to builtins (in some cases it makes sense in others it does not
Hi,
this is patch I comitted yesterday (but failed to send email) which removes
forgotten sanity check from original fix. The check tries to catch cases where
we do merge definitions and declarations to see if resolution merging logic is
live. It is.
Honza
* lto.c (register_resolution): R
PR83753 was about a case in which we ended up trying to "vectorise"
a group of loads ore stores using single-element vectors. The problem
was that we were classifying the load or store as VMAT_CONTIGUOUS_PERMUTE
rather than VMAT_CONTIGUOUS, even though it doesn't make sense to permute
a single-ele
One advantage of the new permute handling compared to the old way is
that we can now easily take advantage of the vectoriser's divmod patterns
for SVE.
I realise we're in stage 4, but this is entirely SVE-specific.
Tested on aarch64-linux-gnu and aarch64_be-elf. OK to install?
Richard
2018-02
On Thu, Feb 8, 2018 at 4:08 AM, Martin Sebor wrote:
> I went ahead and changed all the options on the list below
> to include LTO and tested the attached patch by configuring
> with --with-build-config=bootstrap-lto --disable-werror and
> making profiledbootstrap. Attached, besides the patch, is
> On Feb 8, 2018, at 4:52 AM, Richard Biener wrote:
>
> On Sat, Feb 3, 2018 at 12:30 AM, Bill Schmidt
> wrote:
>> Hi,
>>
>> The test g++.dg/vect/slp-pr56812.cc is somewhat fragile and is currently
>> failing
>> on several targets. PR81038 notes that this began with r248678, which
>> stopped
On Thu, Feb 8, 2018 at 6:04 AM, Jeff Law wrote:
> On 02/02/2018 02:35 PM, David Malcolm wrote:
>> On Thu, 2018-02-01 at 12:05 +0100, Richard Biener wrote:
>>> On Wed, Jan 31, 2018 at 4:39 PM, David Malcolm
>>> wrote:
PR 84136 reports an ICE within sccvn_dom_walker when handling a
C/C++
On Thu, Feb 8, 2018 at 6:35 AM, Jeff Law wrote:
> On 02/06/2018 05:57 AM, Jakub Jelinek wrote:
>> On Tue, Feb 06, 2018 at 01:46:21PM +0100, Marek Polacek wrote:
>>> --- gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
>>> +++ gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
>>> @@ -0,0 +1,20
On Thu, Feb 8, 2018 at 6:55 AM, Jakub Jelinek wrote:
> On Wed, Feb 07, 2018 at 04:21:43PM -0500, Jason Merrill wrote:
>> On Wed, Feb 7, 2018 at 4:14 PM, Jakub Jelinek wrote:
>> > On Wed, Feb 07, 2018 at 03:52:39PM -0500, Jason Merrill wrote:
>> >> > E.g. the constexpr function uses
>> >> > same_
On Thu, Feb 8, 2018 at 1:09 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Fri, Feb 2, 2018 at 3:12 PM, Richard Sandiford
>> wrote:
>>> Index: gcc/tree-data-ref.c
>>> ===
>>> --- gcc/tree-data-ref.c 2018-02-02 14:03:53.
On Thu, Feb 8, 2018 at 2:29 PM, Richard Sandiford
wrote:
> PR83753 was about a case in which we ended up trying to "vectorise"
> a group of loads ore stores using single-element vectors. The problem
> was that we were classifying the load or store as VMAT_CONTIGUOUS_PERMUTE
> rather than VMAT_CON
I committed a patch to update libgo to 1.10rc2. This includes a fix
for a security problem in `go get` based on GCC and linker plugins.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
On Wed, Feb 07 2018, Franz Sirl wrote:
> Hi,
>
> this is the result of an attempt to minimize the differences between the
> compile results of a Linux-based and a Cygwin64-based powerpc-eabi cross
> toolchain.
> The method used was:
>
> - find the -fverbose-asm assembler files that differ
>
I have committed this patch to gotools to add compiler options to
allow the compilers under test to pick up the C++ library. This
permits tests to use C++ (linked into Go programs) which I used for a
test that I will commit shortly. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Commi
This libgo patch changes the traceback code to get missing function
name from the symbol table. If we trace back through code that has no
debug info, as when calling through C code compiled with -g0, we won't
have a function name. Try to fetch the function name using the symbol
table.
Adding the
Hi Segher,
OK, here is an official submission of my patch to fix PR 68028.
I should note that Richard Guenther feels that there is a better way
to solve the problem - by only initializing the values once - but I
still like my solution, so I am offering it here.
OK to apply ?
Cheers
On Thu, Feb 8, 2018 at 7:56 AM, Alexandre Oliva wrote:
> On Feb 7, 2018, Jason Merrill wrote:
>
>> OK, that makes sense. But I'm still uncomfortable with choosing an
>> existing opcode for that purpose, which previously would have been
>> chosen just for reasons of encoding complexity and size.
when working on 84263 I noticed this initializer_list diagnostic wasn't
correctly formatted. Fixing thusly.
nathan
--
Nathan Sidwell
2018-02-08 Nathan Sidwell
* class.c (finish_struct): Fix std:initializer_list diagnostic
formatting.
* g++.dg/cpp0x/initlist93.C: Adjust diagnostic.
Inde
This patch fixes 84263, a GC breakage entirely unconnected with the
patch of mine that exposed it. I guess I perturbed the memory layout
sufficiently to tickle it -- on a 32bit host.
The underlying problem is that decltype parsing has to squirrel away
some data in the same manner to template-
On 02/08/2018 04:04 AM, Nick Clifton wrote:
Hi David,
+ /* PR 84195: Replace control characters in the message with their
+escaped equivalents. Allow newlines if -fmessage-length has
+been set to a non-zero value.
I'm not quite sure why we allow newlines in th
On Wed, Feb 07, 2018 at 04:21:43PM -0500, Jason Merrill wrote:
> On Wed, Feb 7, 2018 at 4:14 PM, Jakub Jelinek wrote:
> > On Wed, Feb 07, 2018 at 03:52:39PM -0500, Jason Merrill wrote:
> >> > E.g. the constexpr function uses
> >> > same_type_ignoring_top_level_qualifiers_p
> >> > instead of == ty
On Tue, Feb 06, 2018 at 05:14:16PM +0100, Marek Polacek wrote:
> Here we ICE because get_range_strlen's result might not be an array of
> two integer constants -- for a VLA the array might contain a non-constant.
> So beef up the check before converting to wide_int.
>
> Bootstrapped/regtested on x
On 2/6/18 10:36 AM, Peter Bergner wrote:
> On 2/6/18 10:20 AM, David Edelsohn wrote:
>> Do the gen_XXXdi3 calls work if you use SDI iterator instead of GPR
>> iterator, as Segher suggested?
>
> Well it works _if_ we use the first patch that changes the gen_*
> patterns. If we go this route, I agr
ping x1
Complex Partial Integers are unimplemented, resulting in an ICE when
attempting to use them. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79242
This results in GCC7/8 for msp430-elf failing to build.
typedef _Complex __int20 C;
C
foo (C x, C y)
{
return x + y;
}
(Thanks Jakub - https:
Hi Nick,
On Thu, Feb 08, 2018 at 03:49:38PM +, Nick Clifton wrote:
> I should note that Richard Guenther feels that there is a better way
> to solve the problem - by only initializing the values once - but I
> still like my solution, so I am offering it here.
I thought you were going to
gcc/ChangeLog:
2018-02-08 Andreas Krebbel
Backport from mainline
2018-02-08 Andreas Krebbel
* config/s390/s390-opts.h (enum indirect_branch): Define.
* config/s390/s390-protos.h (s390_return_addr_from_memory)
(s390_indirect_branch_via_thunk)
Hi all,
This is a followup to the other PR target/84164 patch [1] that fixes the
testsuite regression
gcc.target/aarch64/bfxil_1.c.
The regression is that with the new subreg+masking simplification we no longer
match the
pattern for BFXIL that has the form:
(set (zero_extract:DI (reg/v:DI 76 [
On 06/02/18 11:32, Richard Earnshaw (lists) wrote:
On 02/02/18 15:43, Kyrill Tkachov wrote:
Hi Richard,
On 02/02/18 15:25, Richard Earnshaw (lists) wrote:
On 02/02/18 15:10, Kyrill Tkachov wrote:
Hi all,
In this [8 Regression] PR we ICE because we can't recognise the insn:
(insn 59 58 43 7
Hi all,
This patch fixes some fallout in the i386 testsuite that occurs after the
simplification in patch [1/3] [1].
The gcc.target/i386/extract-2.c FAILs because it expects to match:
(set (reg:CC 17 flags)
(compare:CC (subreg:QI (zero_extract:SI (reg:HI 98)
(const_int 8 [0x8
On Wed, 7 Feb 2018, David Malcolm wrote:
> gcc/c-family/ChangeLog:
> PR c/84258
> * c-format.c (struct format_check_results): Add field
> "number_non_char".
> (check_format_info): Initialize it, and warn if encountered.
> (check_format_arg): Distinguish between wide c
On Wed, 7 Feb 2018, Jeff Law wrote:
> Ideally we'd tighten the extension's language so that we could issue an
> error out of the front-end.
It seems to me to be the sort of thing that's only undefined at execution
time - it's perfectly valid to store the address of a label in a global,
and late
OK.
On Thu, Feb 8, 2018 at 4:19 AM, Paolo Carlini wrote:
> Hi,
>
> yesterday I noticed these and I regression tested the change together with
> my fix for 83204. Can definitely wait, but seems very safe...
>
> Cheers, Paolo.
>
> ///
>
On Thu, Feb 8, 2018 at 6:22 AM, Paolo Carlini wrote:
> Hi,
>
> this one should be rather straightforward. As noticed by Jakub, we started
> emitting the spurious warning with the fix for c++/69257, which, among other
> things, fixed decay_conversion wrt mark_rvalue_use and mark_lvalue_use
> calls.
> Does this resolve all of PR84113? If so, I can push the bug along
Yep, as I wrote in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113#c35
> What PR was the attachment url from?
It took me about one minute to figure out and find the bug with patch
mentioned by Segher in https://gcc.gnu.org/b
On Sun, Jan 28, 2018 at 11:56 AM, H.J. Lu wrote:
> On Sat, Jan 27, 2018 at 2:12 PM, H.J. Lu wrote:
>> For
>>
>> ---
>> struct C {
>> virtual ~C();
>> virtual void f();
>> };
>>
>> void
>> f (C *p)
>> {
>> p->f();
>> p->f();
>> }
>> ---
>>
>> -mindirect-branch=thunk-extern -O2 on x86-64 GN
On Fri, Feb 2, 2018 at 8:54 AM, H.J. Lu wrote:
> nocf_check attribute can be used with -fcf-protection -mcet to disable
> control-flow check by adding NOTRACK prefix before indirect branch.
> When -mindirect-branch=thunk-extern -mindirect-branch-register is added,
> indirect branch via register, "
On 02/08/2018 07:39 AM, Richard Biener wrote:
On Thu, Feb 8, 2018 at 6:35 AM, Jeff Law wrote:
On 02/06/2018 05:57 AM, Jakub Jelinek wrote:
On Tue, Feb 06, 2018 at 01:46:21PM +0100, Marek Polacek wrote:
--- gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
+++ gcc/testsuite/c-c++-common/Wstr
Hi,
On 08/02/2018 18:38, Jason Merrill wrote:
On Thu, Feb 8, 2018 at 6:22 AM, Paolo Carlini wrote:
Hi,
this one should be rather straightforward. As noticed by Jakub, we started
emitting the spurious warning with the fix for c++/69257, which, among other
things, fixed decay_conversion wrt mar
On 2/8/18 10:38 AM, Peter Bergner wrote:
> * gcc.target/powerpc/builtins-1-be.c: Filter out gimple folding disabled
> message. Fix test for running in 32-bit mode.
As we talked about offline, here's a bigger change to builtins-1-be.c that
cleans up the test a little more, since we gen
I merged trunk revision 257495 to the gccgo branch.
Ian
On Thu, 2018-02-08 at 17:18 +, Joseph Myers wrote:
> On Wed, 7 Feb 2018, David Malcolm wrote:
>
> > gcc/c-family/ChangeLog:
> > PR c/84258
> > * c-format.c (struct format_check_results): Add field
> > "number_non_char".
> > (check_format_info): Initialize it, and warn if encoun
The msp43-specific parts look OK to me, but obviously they're kinda
useless without the core changes :-)
On Thu, Feb 8, 2018 at 4:17 AM, Andreas Krebbel
wrote:
> On 02/08/2018 12:33 PM, Richard Biener wrote:
>> On Wed, Feb 7, 2018 at 1:01 PM, Andreas Krebbel
>> wrote:
>>> This patch implements GCC support for mitigating vulnerability
>>> CVE-2017-5715 known as Spectre #2 on IBM Z.
>>>
>>> In order t
On 02/07/2018 02:36 AM, Alexandre Oliva wrote:
+/* Output symbol LAB1 as an unsigned LEB128 quantity. */
Let's mention here that the value of LAB1 must be an assemble-time
constant (such as a view counter), since we can't have LEB128 relocations.
With that, the patch looks OK.
Jason
On Thu, Feb 8, 2018 at 11:57 AM, H.J. Lu wrote:
> On Thu, Feb 8, 2018 at 4:17 AM, Andreas Krebbel
> wrote:
>> On 02/08/2018 12:33 PM, Richard Biener wrote:
>>> On Wed, Feb 7, 2018 at 1:01 PM, Andreas Krebbel
>>> wrote:
This patch implements GCC support for mitigating vulnerability
CVE-
Thanks for doing this.
Kyrill Tkachov writes:
> diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
> index
> 2e7aa5c12952ab1a9b49b5adaf23710327e577d3..af06d7502cebac03cefc689b2646874b8397e767
> 100644
> --- a/gcc/simplify-rtx.c
> +++ b/gcc/simplify-rtx.c
> @@ -6474,6 +6474,18 @@ simplify_sub
On Wed, Feb 07, 2018 at 03:52:27PM -0800, Mike Stump wrote:
> I dusted the pointed to patch off and check it in. Let us know how it goes.
I wanted to test this on the primary and secondary powerpc targets as
well, but okay.
> Does this resolve all of PR84113? If so, I can push the bug along.
I
On Thu, Feb 8, 2018 at 1:21 PM, Paolo Carlini wrote:
> Hi,
>
> On 08/02/2018 18:38, Jason Merrill wrote:
>>
>> On Thu, Feb 8, 2018 at 6:22 AM, Paolo Carlini
>> wrote:
>>>
>>> Hi,
>>>
>>> this one should be rather straightforward. As noticed by Jakub, we
>>> started
>>> emitting the spurious warni
I have committed the following obvious testsuite patch to fix PR81143.
The "bug" is that __ORDER_LITTLE_ENDIAN__ is always defined for both
little and big endian compiles. I checked and this is the only use
of this in the gcc.target/powerpc/ directory.
Peter
PR target/81143
* gcc
On 02/08/2018 03:38 AM, Richard Biener wrote:
On Thu, Feb 1, 2018 at 6:42 PM, Aldy Hernandez wrote:
Since my patch isn't the easy one liner I wanted it to be, perhaps we
should concentrate on Martin's patch, which is more robust, and has
testcases to boot! His patch from last week also fixes a
__attribute__ ((nothrow))? The patch includes a test case with
wrong-code due to inheriting the attribute. With exception
specifications having to match between the primary and its
specializations it's the only way to make them different.
I've left this unchanged but let me know if I'm missing
s
PR tree-optimization/84178 reports a couple of source files that ICE inside
ifcvt when compiled with -03 -fno-tree-forwprop (trunk and gcc 7).
Both cases involve problems with ifcvt's per-BB gimplified predicates.
Testcase 1 fails this assertion within release_bb_predicate during cleanup:
283
On Thu, Feb 8, 2018 at 12:48 PM, Shalnov, Sergey
wrote:
> Hi,
> This patch contain cost model change for SKX and closes PR target/83008
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008)
>
> It provides following performance scores in geomean:
> SPEC CPU2017 intrate +0.6%
> SPEC CPU2017 fprat
On Thu, Feb 8, 2018 at 6:11 PM, Kyrill Tkachov
wrote:
> Hi all,
>
> This patch fixes some fallout in the i386 testsuite that occurs after the
> simplification in patch [1/3] [1].
> The gcc.target/i386/extract-2.c FAILs because it expects to match:
> (set (reg:CC 17 flags)
> (compare:CC (subre
On 02/08/2018 04:42 AM, Aldy Hernandez wrote:
> In this PR, the reporter is complaining that forcing -static-libstdc++
> and -static-libgcc during stage1 will also force it down to all
> subdirectories (gdb for instance).
>
> There is some back and forth in the PR whether this is good or not. I'm
On Wed, 7 Feb 2018, Segher Boessenkool wrote:
> Hi Mike,
>
> On Tue, Feb 06, 2018 at 04:34:08PM -0500, Michael Meissner wrote:
> > Here is the patch reworked. It bootstraps on both little/big endian power8,
> > and all of the tests run. Can I install this into trunk now, and into GCC 7
> > after
On 02/06/2018 01:44 PM, Jakub Jelinek wrote:
> Hi!
>
> The last year's bss_initializer_p change apparently broke xen. While it is
> reasonable not to put const variables into .bss* sections by default,
> refusing to put them when the user asks for it through using section
> attribute seems unnece
On 02/07/2018 03:43 PM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, the vt_get_decl_and_offset function verifies
> incoming PARALLEL is usable for tracking, but if it fails, we retry
> vt_get_decl_and_offset on DECL_RTL and there we check only that a memory
> isn't larger than 16 bytes
Hi!
On Wed, Feb 07, 2018 at 09:14:59AM -0600, Will Schmidt wrote:
> Our VEC_SLD definitions were mistakenly allowing the third argument to be
> of an invalid type, triggering an ICE (on invalid code) later in the build
> process. This fixes those definitions. The nearby VEC_SLDW definitions ha
On Thu, Feb 08, 2018 at 06:10:31PM -0500, Hans-Peter Nilsson wrote:
> On Wed, 7 Feb 2018, Segher Boessenkool wrote:
> > Hi Mike,
> >
> > On Tue, Feb 06, 2018 at 04:34:08PM -0500, Michael Meissner wrote:
> > > Here is the patch reworked. It bootstraps on both little/big endian
> > > power8,
> > >
On Feb 8, 2018, at 12:36 PM, Segher Boessenkool
wrote:
>
> On Wed, Feb 07, 2018 at 03:52:27PM -0800, Mike Stump wrote:
>> I dusted the pointed to patch off and check it in. Let us know how it goes.
>
> I wanted to test this on the primary and secondary powerpc targets as
> well, but okay.
I r
A non-type-dependent COND_EXPR within a template is reconstructed with
the original operands, after one with non-dependent proxies is built to
determine its result type. This is problematic because the operands of
a COND_EXPR determined to be an rvalue may have been converted to denote
their rvalu
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00076.html
On 02/01/2018 04:45 PM, Martin Sebor wrote:
The previous patch didn't resolve all the false positives
in the Linux kernel. The attached is an update that fixes
the remaining one having to do with multidimensional array
members:
s
On Feb 8, 2018, Jason Merrill wrote:
> On 02/07/2018 02:36 AM, Alexandre Oliva wrote:
>> +/* Output symbol LAB1 as an unsigned LEB128 quantity. */
> Let's mention here that the value of LAB1 must be an assemble-time
> constant (such as a view counter), since we can't have LEB128
> relocations.
On Jan 25, 2018, Alexandre Oliva wrote:
> On Jan 24, 2018, Jakub Jelinek wrote:
>> I think this asks for
>> if (flag_checking)
>> gcc_assert (block_within_block_p (block,
>> DECL_INITIAL (current_function_decl),
>> true));
> 'k, changed.
>> Otherwise the patch looks reasonable to me, but I thi
On Feb 8, 2018, Jason Merrill wrote:
> On Thu, Feb 8, 2018 at 7:56 AM, Alexandre Oliva wrote:
>> On Feb 7, 2018, Jason Merrill wrote:
>>
>>> OK, that makes sense. But I'm still uncomfortable with choosing an
>>> existing opcode for that purpose, which previously would have been
>>> chosen j
On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote:
> Here's what I checked in, right after the LVU patch.
>
> [IEPM] Introduce inline entry point markers
One of these two patches breaks ppc64le bootstrap with the assembler
complaining "Error: view number mismatch" when compiling
lib
On 02/08/2018 08:53 PM, Alan Modra wrote:
> On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote:
>> Here's what I checked in, right after the LVU patch.
>>
>> [IEPM] Introduce inline entry point markers
>
> One of these two patches breaks ppc64le bootstrap with the assembler
> complain
This PR is one of those with a really obvious cause, and fix. There's
nothing in the unspec rtl to say the insn needs lr!
Bootstrapped and regression tested powerpc64le-linux. OK?
PR target/84300
gcc/
* config/rs6000/rs6000.md (split_stack_return): Use LR.
gcc/testsuite/
Hi!
When placing a variable length field into a structure, we need to update
rli->offset_align for the next field. We do:
rli->offset_align = MIN (rli->offset_align, desired_align);
which updates it according to the start of that VLA field, the problem is
that if the field doesn't have a size tha
Hi!
When linking with -static-lib{a,t,l,ub}san -fsanitize=whatever, we link
-l{a,t,l,ub}san statically into the binary and add the set of libraries
needed by the lib{a,t,l,ub}san.a afterwards (-lpthread, -ldl etc.).
When doing -static -fsanitize=whatever link, we link the sanitizer library
statica
Hi!
As mentioned in the PR, DOM/SLP can only handle the case when the stores
of the vector are in the same chunks as the reads from it, so the testcase
has lots of xfails for targets where this doesn't happen.
On x86 in the generic and many other tunings the vector is stored in the
same chunks as
On February 9, 2018 7:31:33 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>As mentioned in the PR, DOM/SLP can only handle the case when the
>stores
>of the vector are in the same chunks as the reads from it, so the
>testcase
>has lots of xfails for targets where this doesn't happen.
>On x86 in the g
On February 9, 2018 7:27:57 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>When linking with -static-lib{a,t,l,ub}san -fsanitize=whatever, we link
>-l{a,t,l,ub}san statically into the binary and add the set of libraries
>needed by the lib{a,t,l,ub}san.a afterwards (-lpthread, -ldl etc.).
>When doing
Hi!
BSWAP is documented as:
@item (bswap:@var{m} @var{x})
Represents the value @var{x} with the order of bytes reversed, carried out
in mode @var{m}, which must be a fixed-point machine mode.
The mode of @var{x} must be @var{m} or @code{VOIDmode}.
The fixed-point is something used widely in rtl.
1 - 100 of 102 matches
Mail list logo