On Wed, Jan 17, 2018 at 11:06:23PM +0100, Harald Anlauf wrote:
>
> Changelog:
>
> 2018-01-17 Harald Anlauf
>
> PR fortran/83864
> * expr.c (add_init_expr_to_sym): Do not dereference NULL pointer.
>
> Testcase:
>
> 2018-01-17 Harald Anlauf
>
> PR fortran/83864
> *
On Wed, Jan 17, 2018 at 7:29 PM, Woodhouse, David wrote:
> I'm not sure I understand the concern. When compiling a large project for
> -m32 vs. -m64, there must be a million times the compiler has to decide
> whether to emit "r" or "e" before a register name. HJ's patch already does
> this for the
From: Siddhesh Poyarekar
* MAINTAINERS (write after approval): Add myself.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@256836
138bc75d-0d04-0410-961f-82ee72b054a4
---
ChangeLog | 4
MAINTAINERS | 1 +
2 files changed, 5 insertions(+)
diff --git a/ChangeLog b/ChangeLog
index aaa218
Sorry, fixed a couple of typos that prevented the patch from actually
working. Here's the updated version. I'll be building on
ADDR_QUERY_STR for identifying and preventing pre/post incrementing
addresses for stores for falkor.
Siddhesh
2018-xx-xx Jim Wilson
Kugan Vivenakandaraja
On Thu, Jan 11, 2018 at 1:46 AM, Rainer Orth
wrote:
>
>> On Wed, Jan 10, 2018 at 5:42 AM, Ian Lance Taylor wrote:
>>>
>>> Whoops, there's a bug on big-endian 32-bit systems. I'm testing
>>> https://golang.org/cl/87135.
>>
>> Committed as follows.
>
> thanks, that fixed quite a lot of the failure
On targets where the callee may make a copy of incoming aggregates DSE
would trigger in both functions -- prior to inlining of course.
This patch tightens the test to look for DSE triggering in the spot
where we really wanted to check for it. It's not strictly a regression
fix, but given it's a
> From: DJ Delorie
> Cc: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Wed, 17 Jan 2018 15:47:49 -0500
>
> Eli Zaretskii writes:
>
> > DJ, would the following semi-kludgey workaround be acceptable?
>
> It would be no worse than what we have now, if the only
In PR83920, I encountered a nvptx bug where live predicate variables
were clobbered before their value was broadcasted. Apparently, there
were problems in certain version of the CUDA driver where the JIT would
generate wrong code for shfl broadcasts. The attached patch teaches
nvptx_single not to a
On Wed, Jan 17, 2018 at 04:09:57PM -0600, Segher Boessenkool wrote:
> On Tue, Jan 16, 2018 at 10:55:43PM -0500, Michael Meissner wrote:
> > PR target/83862 pointed out a problem I put into the 128-bit floating point
> > type signbit optimization. The issue is we want to avoid doing a load to a
> >
On Fri, Jan 12, 2018 at 11:21:04AM -0600, Segher Boessenkool wrote:
> On Thu, Jan 11, 2018 at 01:11:05PM -0500, Michael Meissner wrote:
> > In working on the transition of PowerPC long double from using the IBM
> > extended
> > double format to IEEE 128-bit floating point, I noticed that the long
Hi folks,
(I wanted to get this to the list before my EOD..) :-)
This is a simplified test that is failing for me on Power8, BE, when
gimple-folding is disabled.
I noticed this while working testcase patches for the mergehl folding,
but this is a pre-existing issue.
The majority of the built
On 01/17/2018 06:29 PM, Cesar Philippidis wrote:
Is this patch OK for trunk?
You haven't made the changes I've asked for, this is the same patch as
before.
Thanks,
- Tom
On Tue, Jan 16, 2018 at 10:55:43PM -0500, Michael Meissner wrote:
> PR target/83862 pointed out a problem I put into the 128-bit floating point
> type signbit optimization. The issue is we want to avoid doing a load to a
> floating point/vector register and then a direct move to do signbit, so we
The following obvious patch fixes a NULL pointer dereference:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 256671)
+++ gcc/fortran/expr.c (working copy)
@@ -4267,7 +4269,7 @@
gfc_set_constant_character_len
On 2018-01-17 3:07 PM, Jakub Jelinek wrote:
John, do you think you could test this on hppa without the callee copies
default change?
Or should we not care anymore if there aren't any similar targets left?
I'll test, probably starting build this evening.
I only changed the linux target. The hp
On Tue, Jan 16, 2018 at 08:08:57PM -0600, Bill Schmidt wrote:
> This patch supercedes and extends
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01479.html,
> adding the remaining big-endian support for -mno-speculate-indirect-jumps.
> This includes 32-bit support for indirect calls and sibling c
On Wed, Jan 17, 2018 at 3:46 PM, Paolo Carlini wrote:
> Hi Jason,
>
> On 17/01/2018 00:04, Jason Merrill wrote:
>>
>> Like my recent patch for 83186, we were missing a
>> build_non_dependent_expr.
>>
>> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> Lately I'm seeing (H.J. Lu too) a regression
This patch to the Go frontend by Cherry Zhang enables escape analysis
for the runtime package in the Go frontend. The runtime package was
hard-coded non-escape, and the escape analysis was not run for the
runtime package. This patch removes the hard-code, and lets the
escape analysis decide. It
On Wed, Jan 17, 2018 at 10:10:29PM +0100, Harald Anlauf wrote:
>
> Whoever wants to take it, please commit to 8-trunk.
>
I take it from the above that you do not have write
access to svn. If you think that you will be taking
on additional bugs, write access can be arranged.
--
Steve
On Wed, Jan 17, 2018 at 4:07 PM, Jakub Jelinek wrote:
> On Wed, Jan 17, 2018 at 02:31:29PM -0500, Jason Merrill wrote:
>> > First, thanks for your messages. Personally, at this late time for 8, I
>> > vote for something like my most recent grokdeclarator fix and yours above
>> > for 83824. Then,
The following obvious patch fixes a NULL pointer dereference:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 256671)
+++ gcc/fortran/decl.c (working copy)
@@ -1718,7 +1718,7 @@
}
On Wed, Jan 17, 2018 at 02:31:29PM -0500, Jason Merrill wrote:
> > First, thanks for your messages. Personally, at this late time for 8, I
> > vote for something like my most recent grokdeclarator fix and yours above
> > for 83824. Then, for 9, or even 8.2, the more encompassing change for all
>
Eli Zaretskii writes:
> DJ, would the following semi-kludgey workaround be acceptable?
It would be no worse than what we have now, if the only purpose is to
avoid a warning.
Ideally, we would check to see if we're discarding non-zero values from
that offset, and not call the callback with known
Hi Jason,
On 17/01/2018 00:04, Jason Merrill wrote:
Like my recent patch for 83186, we were missing a build_non_dependent_expr.
Tested x86_64-pc-linux-gnu, applying to trunk.
Lately I'm seeing (H.J. Lu too) a regression:
FAIL: g++.dg/template/inherit4.C -std=c++11 (test for excess errors)
FAI
Hi,
this patch fixes ICE where we manage to lose the CIF_FINAL failure on inlining.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
PR ipa/83051
* ipa-inline.c (flatten_function): Do not overwrite final inlining
failure.
* gcc.c-torture/compile/pr83051-2.c: N
On Thursday 18 January 2018 01:11 AM, Jim Wilson wrote:
> This is the only solution I found that worked.
I tried a few things and ended up with pretty much the same fix you have
except with the check in a slightly different place. That is, I used
aarch64_classify_address to gate the change becaus
Hi!
POINTER_DIFF_EXPR returns a signed integer, but sadly POINTER_PLUS_EXPR
second arguments are unsigned integers, so if we are adding negative numbers
to pointers, those are very large numbers and we get TREE_OVERFLOW which the
C FE then during c_fully_fold diagnoses.
We want to treat the numbe
OK.
On Wed, Jan 17, 2018 at 3:10 PM, Jakub Jelinek wrote:
> Hi!
>
> I've noticed several testcases recently that have a dead
> __builtin_unreachable call in functions right after return stmt.
> They are optimized away after a while (typically in the cfg pass), but we
> don't really need to genera
Hi!
I've noticed several testcases recently that have a dead
__builtin_unreachable call in functions right after return stmt.
They are optimized away after a while (typically in the cfg pass), but we
don't really need to generate them when there is the return.
The reason we don't find it is becaus
Hi!
PR83882 complains that PR81715 testcase fails on callee copies parameter
targets. The following patch ought to fix that, but I have only
bootstrapped/regtested it on x86_64-linux and i686-linux + on the testcase
with hppa.
John, do you think you could test this on hppa without the callee cop
On 01/17/2018 05:37 AM, Wilco Dijkstra wrote:
In general I think the best way to achieve this would be to use the
existing cost models which are there for exactly this purpose. If
this doesn't work well enough then we should fix those.
I tried using cost models, and this didn't work, because t
As described in the PR, older versions of Mac OS X don't reliably
support undefined weak symbols, leading to hundreds of testsuite
failures for the sanitizers. The following patch has been approved
upstream (https://reviews.llvm.org/D41346), but not been applied yet.
To fit into the gcc tree, it h
On Sat, Jan 13, 2018 at 7:59 AM, Paolo Carlini wrote:
> Hi Jakub, all,
>
>> On 13 Jan 2018, at 12:32, Jakub Jelinek wrote:
>>
>>> On Sat, Jan 13, 2018 at 12:12:02PM +0100, Jakub Jelinek wrote:
>>> Or we could not add those error_mark_nodes and
>>> gcc_assert (seen_error () || cp_parser_error_occ
On Wed, 2018-01-17 at 11:31 -0600, Segher Boessenkool wrote:
> On Wed, Jan 17, 2018 at 09:51:54AM -0600, Will Schmidt wrote:
> > On Tue, 2018-01-16 at 16:34 -0600, Segher Boessenkool wrote:
> > > Hi!
> > > On Tue, Jan 16, 2018 at 01:39:28PM -0600, Will Schmidt wrote:
> > > > --- /dev/null
> > > > +
Hi all,
These -mcpu=xscale tests are ARM-only tests and they go to great pains to reject
explicit overriding options, but they're missing the -marm in their dg-options,
which means
they will still give that nasty Thumb1 hard-float error when testing an
implicit --with-mode=thumb
toolchain (--wi
We support architecture/ABI combinations where the ABI uses smaller FP sizes
than the hardware supports. To avoid corruption of the call-saved FP
registers, fs0 through fs11, we only allow values in them that are smaller or
equal in size to the ABI FP size. This means that for soft-float, we neve
On Fri, Jan 12, 2018 at 2:11 PM, Nathan Sidwell wrote:
> Jason,
> this fixes 83160, where we complain about not having an lvalue in things
> like:
>
> void foo () {
> const int a = 0;
> [&a] () {
> const int &b = a; // here
> };
> }
>
> The problem is that we in convert_like_real we hav
This patch by Tony Reix adds support for stat and device numbers on
AIX. Bootstrapped and ran Go tests on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision
I'm not sure I understand the concern. When compiling a large project for -m32
vs. -m64, there must be a million times the compiler has to decide whether to
emit "r" or "e" before a register name. HJ's patch already does this for the
thunk symbol. What is the future requirement that I am not und
This fixes the other problem in 83287, another case where a lookup was
not marked for keeping. I checked other build4 (& build3) calls, and it
looks like this is the only one where this could happen. Also, retested
using the original testcase and no further issues discovered.
nathan
--
Natha
PING
On Fri, Dec 29, 2017 at 8:28 PM, Janne Blomqvist
wrote:
> On Fri, Dec 29, 2017 at 7:17 PM, Thomas Koenig wrote:
>> Hi Janne,
>>
>>> Using pointer sized variables (e.g. size_t / ptrdiff_t) when the
>>> variables are used as array indices allows accessing larger arrays,
>>> and can be a sligh
On Wednesday 17 January 2018 11:13 PM, Wilco Dijkstra wrote:
> Are you saying the same issue exists for all stores with writeback? If so then
> your patch would need to address that too.
Yes, I'll be posting a separate patch for that because the condition set
is slightly different for it. It will
Hi,
+ return targetm.speculation_safe_load (mode, target, mem, lower, upper,
+ cmpptr, true);
So portable programming will use this builtin when available,
but for the majority of the targets the default will be wrong,
For instance why should a PDP port be t
On Tue, Jan 16, 2018 at 06:50:07AM -0600, Segher Boessenkool wrote:
> On Mon, Jan 15, 2018 at 09:21:07AM +0100, Richard Biener wrote:
> > We're still in pretty bad shape regression-wise. Please also take
> > the opportunity to check the state of your favorite host/target
> > combination to make su
On Wed, Jan 17, 2018 at 06:42:33PM +0100, Tom de Vries wrote:
> +static rtx
> +expand_builtin_goacc_parlevel_id_size (tree exp, rtx target, int ignore)
> +{
> + tree fndecl = get_callee_fndecl (exp);
> +
> + const char *name;
> + switch (DECL_FUNCTION_CODE (fndecl))
> +{
> +case BUILT_IN
Siddhesh Poyarekar wrote:
On Wednesday 17 January 2018 08:31 PM, Wilco Dijkstra wrote:
> Why is that a bad thing? With the patch as is, the testcase generates:
>
> .L4:
> ldr q0, [x2, x3]
> add x5, x1, x3
> add x3, x3, 16
> cmp x3, x4
> str q
OK.
On Wed, Jan 17, 2018 at 12:27 PM, David Malcolm wrote:
> On Wed, 2018-01-17 at 09:28 -0500, Jason Merrill wrote:
>> On Wed, Jan 17, 2018 at 5:34 AM, Jakub Jelinek
>> wrote:
>> > On Fri, Jan 12, 2018 at 05:09:24PM -0500, David Malcolm wrote:
>> > > PR c++/83814 reports an ICE introduced by th
On 01/15/2018 12:25 PM, Jakub Jelinek wrote:
On Mon, Jan 15, 2018 at 12:12:10PM +0100, Tom de Vries wrote:
It can be just number of course. parlevel is fine for me.
So, in summary, I propose as interface:
- int __builtin_goacc_parlevel_id (int);
- int __builtin_goacc_parlevel_size (int);
wit
Hi,
+ if (mode == TImode || TARGET_THUMB1)
+return default_speculation_safe_load (mode, result, mem, lower_bound,
+ upper_bound, cmpptr, warn);
TImode is impossible to happen right, so you could as well let that one
run into the gcc_unreachable below,
My patch for 72801 added in enclosing template arguments, but then as
a result we wrongly tried to deduce them.
Tested x86_64-pc-linux-gnu, applying to trunk and 7.
commit 7b299d41c412665a03c5bcdb088d3a39dc86d9c2
Author: Jason Merrill
Date: Wed Jan 17 11:12:23 2018 -0500
PR c++/818
On Wed, Jan 17, 2018 at 09:51:54AM -0600, Will Schmidt wrote:
> On Tue, 2018-01-16 at 16:34 -0600, Segher Boessenkool wrote:
> > Hi!
> > On Tue, Jan 16, 2018 at 01:39:28PM -0600, Will Schmidt wrote:
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/powerpc/builtins-1-be-folded.c
> > > @@ -0,
On 12/27/2017 01:16 AM, Tom de Vries wrote:
> On 12/21/2017 06:19 PM, Cesar Philippidis wrote:
>> My test results are somewhat inconsistent. On MG's build servers, there
>> are no regressions in CUDA 8.
>
> Ack.
>
>> On my laptop, there are fewer regressions
>> in CUDA 9, than CUDA 8.
>
> If th
On Wed, 2018-01-17 at 09:28 -0500, Jason Merrill wrote:
> On Wed, Jan 17, 2018 at 5:34 AM, Jakub Jelinek
> wrote:
> > On Fri, Jan 12, 2018 at 05:09:24PM -0500, David Malcolm wrote:
> > > PR c++/83814 reports an ICE introduced by the location wrapper
> > > patch
> > > (r256448), affecting certain m
On Wed, Jan 17, 2018 at 05:17:29PM +, Joseph Myers wrote:
> On Wed, 17 Jan 2018, Richard Earnshaw wrote:
>
> > + if (TREE_CODE (type) == ARRAY_TYPE)
> > +{
> > + /* Force array-to-pointer decay for c++. */
> > + gcc_assert (c_dialect_cxx ());
>
> What's the basis for the asser
On Wed, 17 Jan 2018, Richard Earnshaw wrote:
> + if (TREE_CODE (type) == ARRAY_TYPE)
> +{
> + /* Force array-to-pointer decay for c++. */
> + gcc_assert (c_dialect_cxx ());
What's the basis for the assertion? Why can't you have a pointer-to-array
passed in C?
--
Joseph S. Myer
This patch series seems to be missing testcases (generic and
architecture-specific). Generic ones should include testing the error
cases that are diagnosed.
--
Joseph S. Myers
jos...@codesourcery.com
My June 9 patch to remove the call to scalar_constant_value from
convert_like_real wrongly also removed the NULL handling that avoids
repeated warnings. This patch restores that code.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 6d452cf34a321c16b6777c2e20a72b39fbf77a24
Author: Jason Merr
Hi!
I'd like to ping this patch.
As I wrote, it isn't a full solution for all the __VA_OPT__ issues,
but it isn't even clear to me how exactly it should behave, but fixes
some ICEs and a couple of most important issues and shouldn't make things
worse, at least on the gcc and clang __VA_OPT__ testc
OK.
On Wed, Jan 17, 2018 at 11:16 AM, Paolo Carlini
wrote:
> Hi,
>
> On 17/01/2018 15:58, Jason Merrill wrote:
>>
>> On Tue, Jan 16, 2018 at 4:40 PM, Paolo Carlini
>> wrote:
>>>
>>> On 16/01/2018 22:35, Jason Merrill wrote:
On Tue, Jan 16, 2018 at 3:32 PM, Paolo Carlini
wrot
Hi all,
There is a typo in the armv8.1-a and armv8.2-a effective target check
generators.
They are not actually used anywhere in the testsuite as far as I can tell, but
the fix is obvious.
Committing to trunk.
Thanks,
Kyrill
2018-01-17 Kyrylo Tkachov
* lib/target-supports.exp: Fix -ma
James Greenhalgh wrote:
> - /* Do not allow wide int constants - this requires support in movti. */
> + /* Only allow simple 128-bit immediates. */
> if (CONST_WIDE_INT_P (x))
> - return false;
> + return aarch64_mov128_immediate (x);
> I can see why this could be correct, but it is
Hi,
On 17/01/2018 15:58, Jason Merrill wrote:
On Tue, Jan 16, 2018 at 4:40 PM, Paolo Carlini wrote:
On 16/01/2018 22:35, Jason Merrill wrote:
On Tue, Jan 16, 2018 at 3:32 PM, Paolo Carlini
wrote:
thus I figured out what was badly wrong in my first try: I misread
ensure_literal_type_for_cons
We can use const reference of struct ix86_frame to avoid making a local
copy of ix86_frame. ix86_expand_epilogue makes a local copy of struct
ix86_frame and uses the reg_save_offset field as a local variable. This
patch uses a separate local variable for reg_save_offset.
Tested on x86-64 with ad
On Fri, 2018-01-12 at 12:37 -0500, David Malcolm wrote:
> On Fri, 2018-01-12 at 09:07 +0100, Markus Trippelsdorf wrote:
> > On 2018.01.11 at 18:21 -0500, David Malcolm wrote:
[...snip...]
> > Thanks for the fix. Minor nit:
> > Please make TargetLoweringBase and TargetLoweringBase a struct
> > ins
On Tue, 2018-01-16 at 16:34 -0600, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Jan 16, 2018 at 01:39:28PM -0600, Will Schmidt wrote:
> > Sniff-tests of the target tests on a single system look OK. Full regtests
> > are
> > currently running across assorted power systems.
> > OK for trunk, pendin
On Wednesday 17 January 2018 08:31 PM, Wilco Dijkstra wrote:
> Why is that a bad thing? With the patch as is, the testcase generates:
>
> .L4:
> ldr q0, [x2, x3]
> add x5, x1, x3
> add x3, x3, 16
> cmp x3, x4
> str q0, [x5]
> bne .L4
>
>
When a generic lambda contains a range_for, and we're instantiating the
containing function, we must rebuild a range_for. We should only
convert to a regular for when tsubsting the resulting generic lambda itself.
This patch looks at processing_template_decl to determine that.
Applying to tru
> From: Andreas Schwab
> Cc: Eli Zaretskii , gcc-patches@gcc.gnu.org,
> gdb-patc...@sourceware.org
> Date: Tue, 16 Jan 2018 23:00:55 +0100
>
> On Jan 16 2018, DJ Delorie wrote:
>
> > And it's not the host's bit size that counts; there are usually ways to
> > get 64-bit file operations on 32-
On Mon, Jan 15, 2018 at 5:09 AM, Florian Weimer wrote:
> * Martin Sebor:
>
>> +the virtual table. Modifying the representation of such objects may violate
>^vtable pointer?
>
> The vtable itself is not corrupted, I assume.
Indeed.
Jason
Siddhesh Poyarekar wrote:
> The current cost model will disable reg offset for loads as well as
> stores, which doesn't work well since loads with reg offset are faster
> for falkor.
Why is that a bad thing? With the patch as is, the testcase generates:
.L4:
ldr q0, [x2, x3]
On Tue, Jan 16, 2018 at 4:40 PM, Paolo Carlini wrote:
> On 16/01/2018 22:35, Jason Merrill wrote:
>> On Tue, Jan 16, 2018 at 3:32 PM, Paolo Carlini
>> wrote:
>>>
>>> thus I figured out what was badly wrong in my first try: I misread
>>> ensure_literal_type_for_constexpr_object and missed that it
This patch implements despeculation on ARM. We only support it when
generating ARM or Thumb2 code (we need conditional execution); and we
only support it for sizes up to DImode. For unsupported cases we
fall back to the generic code generation sequence so that a suitable
failure warning is emitt
This patch adds generic support for the new builtin
__builtin_speculation_safe_load. It provides the overloading of the
different access sizes and a default fall-back expansion for targets
that do not support a mechanism for inhibiting speculation.
* builtin-types.def (BT_FN_I1_CONST_VPT
This patch implements support for __builtin_speculation_safe_load on
AArch64. On this architecture we inhibit speclation by emitting a
combination of CSEL and a hint instruction that ensures the CSEL is
full resolved when the operands to the CSEL may involve a speculative
load.
* config/
This patch series is version 2 for a patch to protect against
speculative use of a load instruction. It's based on a roll-up of the
feedback from the first version.
What's changed since v1?
First, and foremost, the API has changed to make it possible to reduce
the amount of code that needs to b
This fixes PR83887 where current GRAPHITE SESE region merging sometimes
finds non-SESE regions as a result.
It re-implements SESE region merging by searching for the entry/exit
with a worklist based algorithm seeded by the entry/exit block of
the to be merged regions, walking predecessors and suc
On Wed, Jan 17, 2018 at 5:34 AM, Jakub Jelinek wrote:
> On Fri, Jan 12, 2018 at 05:09:24PM -0500, David Malcolm wrote:
>> PR c++/83814 reports an ICE introduced by the location wrapper patch
>> (r256448), affecting certain memset calls within templates.
>
> Note, I think this issue sadly affects a
This patch updates libgo to the Go1.10beta2 release. The complete
patch is too large to include in this e-mail message, mainly due to
some test changes. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
patch.txt.bz2
Description: BZip2 compressed data
On Wednesday 17 January 2018 07:07 PM, Wilco Dijkstra wrote:
> (finished version this time, somehow Outlook loves to send emails early...)
>
> Hi,
>
> In general I think the best way to achieve this would be to use the
> existing cost models which are there for exactly this purpose. If
> this doe
(finished version this time, somehow Outlook loves to send emails early...)
Hi,
In general I think the best way to achieve this would be to use the
existing cost models which are there for exactly this purpose. If
this doesn't work well enough then we should fix those. As is,
this patch disables
Hi,
In general I think the best way to achieve this would be to use the
existing cost models which are there for exactly this purpose. If
this doesn't work well enough then we should fix those. As is,
this patch disables a whole class of instructions for a specific
target rather than simply tellin
The GCC 7 branch is now frozen in preparation for GCC 7.3 RC1. All
changes from this point to the final release of GCC 7.3 now require
release manager approval.
As said I'm happily taking adjustments/enhancements to the spectre
mitigation patches (as well as rs6000 backports).
Richard.
On Wed, 17 Jan 2018, Jakub Jelinek wrote:
> On Tue, Jan 16, 2018 at 02:19:16PM +0100, Christophe Lyon wrote:
> > I've noticed that this new test fails on arm, eg:
> > arm-none-linux-gnueabihf
> > --with-mode arm
> > --with-cpu cortex-a9
> > --with-fpu neon-fp16
> > FAIL: gcc.dg/store_merging_18.c
Hi all,
On 15/01/18 11:23, Kyrill Tkachov wrote:
Hi all,
In this wrong-code bug we combine a VSUB.I8 and a VABS.S8
into a VABD.S8 instruction . This combination is not valid
for integer operands because in the VABD instruction the semantics
are that the difference is computed in notionally infi
This adds --param inline-unit-growth=20 to the set of options passed to the
testcase, which is the default setting but makes it possible for the test to
pass on targets which changes the default, like Visium.
Tested on visium-elf & x86_64-suse-linux, applied on the mainline as obvious.
2018-01
On Mon, Jan 15, 2018 at 7:02 AM, H.J. Lu wrote:
> On Mon, Jan 15, 2018 at 1:42 AM, Jakub Jelinek wrote:
>> On Sun, Jan 14, 2018 at 06:29:54AM -0800, H.J. Lu wrote:
>>> + if (TREE_CODE (field) == FIELD_DECL && DECL_PACKED (field))
>>> + {
>>> + tree field_type = TREE_TYPE (
Hello.
Another 4 patches that I've just tests and bootsrapped.
Martin
>From af6233cb16c9dc174ef4e45da06c43bfd5442d4e Mon Sep 17 00:00:00 2001
From: jakub
Date: Thu, 4 Jan 2018 21:13:17 +
Subject: Backport r256266
gcc/testsuite/ChangeLog:
2018-01-04 Jakub Jelinek
PR ipa/82352
* g++.dg
Hi all,
This is an awkward testsuite failure. The original bug was that we were failing
to put out
the conditional code in the conditional form of the STL instruction (oops!).
So we wanted to output STLNE, but instead output STL.
The testacase relies on if-conversion to conditionalise the insn f
From: Siddhesh Poyarekar
Hi,
Jim Wilson posted a patch for this in September[1] and it appears
following discussions that the patch was an acceptable fix for falkor.
Kugan followed up[2] with a test case since that was requested during
initial review. Jim has moved on from Linaro, so I'm pingin
On Tue, Jan 16, 2018 at 02:19:16PM +0100, Christophe Lyon wrote:
> I've noticed that this new test fails on arm, eg:
> arm-none-linux-gnueabihf
> --with-mode arm
> --with-cpu cortex-a9
> --with-fpu neon-fp16
> FAIL: gcc.dg/store_merging_18.c scan-tree-dump-times store-merging
> "Merging successful"
Hi all,
This patch converts gcc.target/arm/pr40887.c to use the proper effective target
check and dg-add-options for armv5te
so that we avoid situations where we end up trying to compile the test with a
Thumb1 hard-float ABI, which makes the
compiler complain.
This allows the test to pass grac
Hi all,
This test is naughty because it doesn't use the proper effective target checks
and add-options mechanisms for setting a Thumb1 target, which leads to Thumb1
hard-float errors
when testing a toolchain configured with --with-cpu=cortex-a15
--with-fpu=neon-vfpv4 --with-float=hard --with-mo
Hi!
This testcase got fixed with Honza's PR middle-end/83575 fix
r256479, so I've just added a testcase after testing it on x86_64/i686-linux
and committed as obvious, so we can close the PR.
2018-01-17 Jakub Jelinek
PR rtl-optimization/83771
* gcc.dg/pr83771.c: New test.
---
On Wed, Jan 17, 2018 at 11:37 AM, Eric Botcazou wrote:
> Hi,
>
> as suggested by Jakub in the audit trail, this simply adjusts the dg-final
> line according to whether it's for a logical_op_short_circuit target or not.
>
> Tested on visium-elf and x86_64-suse-linux, OK for the mainline?
Ok.
Rich
Hi,
as suggested by Jakub in the audit trail, this simply adjusts the dg-final
line according to whether it's for a logical_op_short_circuit target or not.
Tested on visium-elf and x86_64-suse-linux, OK for the mainline?
2018-01-17 Eric Botcazou
PR tree-optimization/81184
*
On Fri, Jan 12, 2018 at 05:09:24PM -0500, David Malcolm wrote:
> PR c++/83814 reports an ICE introduced by the location wrapper patch
> (r256448), affecting certain memset calls within templates.
Note, I think this issue sadly affects a lot of code, so it is quite urgent.
That said, wonder if we
On Wed, Jan 17, 2018 at 9:56 AM, Koval, Julia wrote:
> Fix bug, when rdpid intrinsic used eax instead of rax in 64bit mode. Ok for
> trunk?
>
> gcc/
> * config/i386/i386.c (ix86_expand_builtin): Handle IX86_BUILTIN_RDPID.
> * config/i386/i386.md (rdpid_rex64) New.
> (rdpid
> There should be just one warning per call, and (as it is) -Wrestrict
> should suppress -Wstringop-overflow. This suppression was a recent
> change (r256683).
Sorry, the changes indeed crossed, I'm going to revert mine.
--
Eric Botcazou
Fix bug, when rdpid intrinsic used eax instead of rax in 64bit mode. Ok for
trunk?
gcc/
* config/i386/i386.c (ix86_expand_builtin): Handle IX86_BUILTIN_RDPID.
* config/i386/i386.md (rdpid_rex64) New.
(rdpid): Make 32bit only.
gcc/testsuite/
* gcc.target/i386/rdpid
On Wed, Jan 17, 2018 at 3:00 AM, John David Anglin wrote:
> The callee copies ABI used for 32-bit hppa causes no end of optimization
> issues and problems with
> OpenMP. The hppa target is only in Debian unstable and gentoo. In both
> cases, packages are
> rebuilt often. So, Helge and I decided
100 matches
Mail list logo
