On Thu, 14 Jan 2016, Ryan Burn wrote:
Also caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69091
Thanks for the heads up, I was not aware I had caused this regression.
On Thu, 14 Jan 2016, Jeff Law wrote:
On 01/10/2016 08:55 PM, Patrick Palka wrote:
On Mon, Jan 4, 2016 at 1:35 PM, Jeff Law wrote:
On 01/02/2016 04:26 PM, Patrick Palka wrote:
On Sat, Jan 2, 2016 at 3:21 AM, Jakub Jelinek wrote:
On Fri, Jan 01, 2016 at 10:06:34PM -0700, Jeff Law wrote:
This patch adds support for __builtin_cpu_init(), __builtin_cpu_is() and
__builtin_cpu_supports() builtins for PowerPC. We use the same API as the
x86* builtins of the same name. These builtins uses the new GLIBC 2.23
feature where we store the AT_PLATFORM, AT_HWCAP and AT_HWCAP2 values in the
Th
On 01/14/2016 07:52 PM, Jeff Law wrote:
On 01/14/2016 05:02 PM, Martin Sebor wrote:
On 01/14/2016 03:51 PM, Jakub Jelinek wrote:
On Thu, Jan 14, 2016 at 03:46:26PM -0700, Martin Sebor wrote:
c++/69277 reports an ICE when mangling a template specialization
involving flexible array member. Debu
On 01/14/2016 05:02 PM, Martin Sebor wrote:
On 01/14/2016 03:51 PM, Jakub Jelinek wrote:
On Thu, Jan 14, 2016 at 03:46:26PM -0700, Martin Sebor wrote:
c++/69277 reports an ICE when mangling a template specialization
involving flexible array member. Debugging the problem revealed
that GCC (prio
On 01/14/2016 11:27 AM, Jeff Law wrote:
Apart from what Jakub said we have constant_boolean_node for this,
true_val = constant_boolean_node (true, TREE_TYPE (op0));
Will update. Thanks.
Here's the patch which uses constant_boolean_node and verifies the type
is unsigned when it has a sing
This patch consolidates the documentation of GCC options that add runtime
profiling, error checking, or other instrumentation into a single section.
Currently these are scattered all over, variously classified as debugging
options, code generation options, optimization options, etc.
Here is
Part 4 of this series was originally intended to move the section "Using
Precompiled Headers" from invoke.texi to extend.texi. But, as I started
to dig around to decide exactly where its should go, I didn't see a good
place to put it there, either -- extend.texi is still very disorganized.
I'
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48344 for the original
problem report. The error resulted because gcc's processing of
command-line options within gcc initialization code originally preceded
the processing of target-specific configuration hooks.
In the unpatched gcc implementa
On Jan 14, 2016, at 4:54 PM, Zachary T Welch wrote:
> This patch fixes a small problem when running 'make check' from a path
> that includes "++". When such paths get used as a regular expression,
> that sequence would cause a runtime error. That is prevented here by
> escaping that character.
Jakub Jelinek writes:
> On Wed, Jan 13, 2016 at 06:39:33PM +0100, Martin Jambor wrote:
>> the following patch adds a BRIG (binary representation of HSAIL)
>> representation description. It is within a single header file
>> describing the binary structures and constants of the format.
>>
>> The
This patch fixes a small problem when running 'make check' from a path
that includes "++". When such paths get used as a regular expression,
that sequence would cause a runtime error. That is prevented here by
escaping that character.
gcc/testsuite/lib/
* prune.exp (prune_file_pa
Also caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69091
On Wed, Dec 16, 2015 at 4:46 PM, Markus Trippelsdorf
wrote:
> On 2015.12.14 at 19:34 -0500, Jason Merrill wrote:
>> OK.
>
> This patch caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68936
>
> --
> Markus
On 01/14/2016 03:51 PM, Jakub Jelinek wrote:
On Thu, Jan 14, 2016 at 03:46:26PM -0700, Martin Sebor wrote:
c++/69277 reports an ICE when mangling a template specialization
involving flexible array member. Debugging the problem revealed
that GCC (prior to the ICE), due to treating flexible array
Among the bugs fixed by the flexible array patch (r231665) was
c++/68490. I forgot to include a test for this bug in the commit
so I'm adding it via the attached patch.
(Please let me know if adding new passing tests is considered
trivial and I don't need to request approval for such things.)
T
The test case gets mis-compiled on arm, because cse1 unifies a comparison
across an extended basic block, then the doloop_end pattern clobbers the shared
comparison.
Fixing this is relatively easy -- notice if the doloop_end pattern that gets
emitted clobbers anything that's live at the end of
On Thu, Jan 14, 2016 at 03:02:28PM -0800, Cesar Philippidis wrote:
> > Is this a case of the Fortran FE OpenACC bits not annotating some
> > artificial object correctly?
>
> I don't think it's specific to fortran. You can have reference types in
> c++ too. Actually, Jakub's comment reminded me to
On 01/14/2016 06:18 AM, Nathan Sidwell wrote:
> On 01/13/16 17:44, Jakub Jelinek wrote:
>> On Wed, Jan 13, 2016 at 11:35:08PM +0100, Marek Polacek wrote:
>>> On Wed, Jan 13, 2016 at 02:29:21PM -0800, Cesar Philippidis wrote:
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -5994,6 +5994,
On Thu, Jan 14, 2016 at 05:41:25PM -0500, Ryan Burn wrote:
> > The
> > /* The statement containing the spawn expression might create temporaries
> > with
> > line is (1 char) too long, so you want to reformat that comment.
> >
> > Jakub
>
> Are you sure? It passed the check_GNU_style.sh
On Thu, Jan 14, 2016 at 03:46:26PM -0700, Martin Sebor wrote:
> c++/69277 reports an ICE when mangling a template specialization
> involving flexible array member. Debugging the problem revealed
> that GCC (prior to the ICE), due to treating flexible array
> members the same as zero-length arrays,
On 01/14/2016 03:34 PM, Jakub Jelinek wrote:
On Thu, Jan 14, 2016 at 02:57:06PM -0700, Jeff Law wrote:
On 01/14/2016 02:19 PM, Ryan Burn wrote:
This patch adds a missing cleanup point to cilk_spawn expressions to
prevent an ICE when calling functions that return types with
non-trivial destructo
c++/69277 reports an ICE when mangling a template specialization
involving flexible array member. Debugging the problem revealed
that GCC (prior to the ICE), due to treating flexible array
members the same as zero-length arrays, produced the wrong mangling
for the former.
The attached patch fixe
On Thu, Jan 14, 2016 at 5:34 PM, Jakub Jelinek wrote:
> On Thu, Jan 14, 2016 at 02:57:06PM -0700, Jeff Law wrote:
>> On 01/14/2016 02:19 PM, Ryan Burn wrote:
>> >This patch adds a missing cleanup point to cilk_spawn expressions to
>> >prevent an ICE when calling functions that return types with
>>
On 01/12/2016 03:01 AM, Jan Beulich wrote:
On 10.12.15 at 08:21, wrote:
Just like gas, which has recently learned to reject such initializers,
gcc shouldn't accept such either.
---
The only question really is whether the new test case should be limited
to certain targets - I haven't been able t
On Thu, Jan 14, 2016 at 02:57:06PM -0700, Jeff Law wrote:
> On 01/14/2016 02:19 PM, Ryan Burn wrote:
> >This patch adds a missing cleanup point to cilk_spawn expressions to
> >prevent an ICE when calling functions that return types with
> >non-trivial destructors.
> >
> >Bootstrapped and regression
On 01/14/2016 03:14 PM, Ryan Burn wrote:
Could you push please? I don't have write access. Thanks - Ryan.
Will do.
Do you *want* write access? It's pretty easy to set up.
jeff
Could you push please? I don't have write access. Thanks - Ryan.
On Thu, Jan 14, 2016 at 4:57 PM, Jeff Law wrote:
> On 01/14/2016 02:19 PM, Ryan Burn wrote:
>>
>> This patch adds a missing cleanup point to cilk_spawn expressions to
>> prevent an ICE when calling functions that return types with
>
On 01/14/16 16:57, Joseph Myers wrote:
On Thu, 14 Jan 2016, Prathamesh Kulkarni wrote:
g++ rejects it during parsing. I tried similarly in C FE by adding a
check for decl with incomplete struct/union type in finish_decl(),
however that fails to compile the following case:
typedef struct foo fo
On Tue, Jan 12, 2016 at 06:48:58PM -0500, David Edelsohn wrote:
> On Tue, Jan 12, 2016 at 6:47 PM, Joseph Myers wrote:
> > On Tue, 12 Jan 2016, Michael Meissner wrote:
> >
> >> On Tue, Jan 12, 2016 at 12:18:55AM +, Joseph Myers wrote:
> >> > On Mon, 11 Jan 2016, Michael Meissner wrote:
> >> >
On 01/14/2016 02:19 PM, Ryan Burn wrote:
This patch adds a missing cleanup point to cilk_spawn expressions to
prevent an ICE when calling functions that return types with
non-trivial destructors.
Bootstrapped and regression tested on x86_64-linux.
2015-01-14 Ryan Burn
PR c++/69048
On Thu, 14 Jan 2016, Prathamesh Kulkarni wrote:
> Hi,
> For test-case containing only the following declaration:
> static struct undefined_struct object;
> gcc rejects it at -O0 in assemble_variable() with error "storage size
> of is unknown",
> however no error is reported when compiled with -O2
Predictably, I must have tweaked the patch after testing on x86.
Re-tested and committed.
r~
PR c/69272
PR tree-opt/68964
* trans-mem.c (tm_log_emit_stmt): Fix unit size to bit size.
* tree.c (build_tm_vector_builtins): Use builtin_decl_explicit_p
instead
Hi!
Here is my attempt to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68463
This patch does 2 things:
I) lto-plugin doesn't claim files which contain offload sections, but don't
contain LTO sections. Instead, it writes names of files with offloading to the
temporary file and passes it to l
On 01/10/2016 08:20 PM, Patrick Palka wrote:
On Thu, Dec 31, 2015 at 10:40 AM, Patrick Palka wrote:
This patch makes it so that a gimplification failure is considered to be
an internal error under normal circumstances, so that we otherwise avoid
silently generating wrong code if e.g. a buggy fr
On 14/01/16 20:41 +, Jonathan Wakely wrote:
On 14/01/16 20:57 +0100, Marc Glisse wrote:
Once you constrain, you could even use 'std' as the associated
namespace ;-)
True! And std is already an associated namespace of the standard
distributions, so we wouldn't be making ADL look anywhere ad
This patch adds a missing cleanup point to cilk_spawn expressions to
prevent an ICE when calling functions that return types with
non-trivial destructors.
Bootstrapped and regression tested on x86_64-linux.
2015-01-14 Ryan Burn
PR c++/69048
* cilk.c (create_cilk_wrapper_body): Call
With this patch the substitution patterns added earlier are used for
the logical right shift and all the left shift patterns.
2016-01-14 Andreas Krebbel
* config/s390/s390.md ("*di3_31", "*3")
("*di3_31_and", "*3_and"): Merge into single
pattern definition ...
(
On 01/10/2016 08:55 PM, Patrick Palka wrote:
On Mon, Jan 4, 2016 at 1:35 PM, Jeff Law wrote:
On 01/02/2016 04:26 PM, Patrick Palka wrote:
On Sat, Jan 2, 2016 at 3:21 AM, Jakub Jelinek wrote:
On Fri, Jan 01, 2016 at 10:06:34PM -0700, Jeff Law wrote:
gcc/cp/ChangeLog:
* cp-array-not
On 01/10/2016 06:24 AM, Nicklas Bo Jensen wrote:
Hi,
In the GCC Internals documentation the loop depth is documented
incorrectly. From git commit 9e3536f4f it is accessed through a
function, not a field.
Please install this patch to reflect this.
Best,
Nicklas
2017-01-10 Nicklas Bo Jensen
On 14/01/16 20:46 +, Jonathan Wakely wrote:
On 14/01/16 20:43 +, Jonathan Wakely wrote:
On 14/01/16 21:22 +0100, Daniel Krügler wrote:
If there were an __is_direct_base_of intrinsic (or is there?), it
seems to me that there would be no need for all these specializations
(each one nearly
On 13.01.16 18:39, Bernd Schmidt wrote:
On 01/11/2016 07:37 PM, Andreas Tobler wrote:
+# Do a configure time check for -ldl
+AC_CHECK_LIB(dl, dlsym,
+ [link_sanitizer_common="-lrt $link_sanitizer_common"])
+
I'll give it a test run.
If that works (with -ldl instead of -lrt) it's ok.
It do
On 14/01/16 20:43 +, Jonathan Wakely wrote:
On 14/01/16 21:22 +0100, Daniel Krügler wrote:
If there were an __is_direct_base_of intrinsic (or is there?), it
seems to me that there would be no need for all these specializations
(each one nearly taking as much space as the explicit inline
defi
While trying to get rid of the Y constraint in the setmem patterns I
noticed that for these patterns it isn't even a problem since these
always only use the constraint with a Pmode match_operand. But while
being at it I've tried to fold some of the patterns a bit.
gcc/ChangeLog:
2016-01-14 Andr
On 14/01/16 21:22 +0100, Daniel Krügler wrote:
If there were an __is_direct_base_of intrinsic (or is there?), it
seems to me that there would be no need for all these specializations
(each one nearly taking as much space as the explicit inline
definition of operator!) and there could be a single
On 14/01/16 20:57 +0100, Marc Glisse wrote:
Once you constrain, you could even use 'std' as the associated
namespace ;-)
True! And std is already an associated namespace of the standard
distributions, so we wouldn't be making ADL look anywhere additional.
2016-01-14 20:21 GMT+01:00 Jonathan Wakely :
> We could constrain the generic operator== and operator!= to only match
> types that we want it to match, e.g. by having a type trait that is
> true for all our distributions and their parameter types. That would
> mean adding a specialization of it for
On Thu, 14 Jan 2016, Jonathan Wakely wrote:
On 14/01/16 20:13 +0100, Marc Glisse wrote:
I didn't think about it much, but I am worried that __random_not_eq will
accidentally become an associated namespace for more classes than we would
expect.
Yes, it would be an associated namespace for typ
While trying to get rid of the Y constraint in the setmem patterns I
noticed that for these patterns it isn't even a problem since these
always only use the constraint with a Pmode match_operand. But while
being at it I've tried to fold some of the patterns a bit.
gcc/ChangeLog:
2016-01-14 Andr
With this patch the substitution patterns added earlier are used for
the logical right shift and all the left shift patterns.
2016-01-14 Andreas Krebbel
* config/s390/s390.md ("*di3_31", "*3")
("*di3_31_and", "*3_and"): Merge into single
pattern definition ...
(
On 14/01/16 20:13 +0100, Marc Glisse wrote:
I didn't think about it much, but I am worried that __random_not_eq
will accidentally become an associated namespace for more classes than
we would expect.
Yes, it would be an associated namespace for types that derive from
the distributions, or clas
On Thu, 14 Jan 2016, Jonathan Wakely wrote:
How do people feel about this approach to solving PR 69240?
The bug is that we don't define operator!= for RND::param_type, where
RND is any of random number distributions in or .
Rather than tediously defining it for every param_type I've added
this
How do people feel about this approach to solving PR 69240?
The bug is that we don't define operator!= for RND::param_type, where
RND is any of random number distributions in or .
Rather than tediously defining it for every param_type I've added
this:
namespace __random_not_eq
{
// Derive
On 01/08/2016 02:40 PM, David Malcolm wrote:
Jakub had some concern about the use of sorry, so here's a revised
version of the patch, with the following changes:
- fixed the comment issues noted above.
- changed from a "sorry" to an "inform" (as per Jakub), passing
in the pertinent l
On 01/13/2016 01:35 AM, Jakub Jelinek wrote:
Hi!
This patch fixes two issues (that could be committed separately, but the
testcase depends on both of them fixed).
The first one is in LRA, where my recent fix to move_plus_up fixed ICE on
the testcase, but actually turned it into a wrong-debug -
On 01/14/2016 11:23 AM, Segher Boessenkool wrote:
In r230167 I made this testcase be tested on 64-bit as well, since it
now works. That was a tad optimistic for powerpc64le though. For now,
XFAIL it there.
Is this okay for trunk? Tested the testcase manually on powerpc64-linux
and powerpc64le
On 01/14/2016 02:47 AM, Richard Biener wrote:
On Thu, Jan 14, 2016 at 8:38 AM, Jeff Law wrote:
As noted in the BZ, DOM does not exploit VRP information to create
additional equivalences in the arms of conditionals.
This can cause DOM to miss relatively simple optimizations that show up in
the
In r230167 I made this testcase be tested on 64-bit as well, since it
now works. That was a tad optimistic for powerpc64le though. For now,
XFAIL it there.
Is this okay for trunk? Tested the testcase manually on powerpc64-linux
and powerpc64le-linux (that is, I ran "make check-gcc-c -k
RUNTESTF
On 01/14/2016 12:49 AM, Jakub Jelinek wrote:
On Thu, Jan 14, 2016 at 08:46:43AM +0100, Jakub Jelinek wrote:
On Thu, Jan 14, 2016 at 12:38:52AM -0700, Jeff Law wrote:
+ /* An integral type with more precision, but the object
+ only takes on values [0..1] as determined by VRP
+ analysis.
Dear Jakub,
Thanks for that. OK by me too.
Paul
On 14 January 2016 at 18:36, Jeff Law wrote:
> On 01/14/2016 07:35 AM, Jakub Jelinek wrote:
>>
>> Hi!
>>
>> I've bootstrapped/regtested on x86_64-linux and i686-linux the following
>> fix
>> from Francois that has been sitting in the PR for a few
OK.
Jason
On 07/01/16 17:47 +0100, Torvald Riegel wrote:
The attached patch makes some exceptions transaction-safe, as require by
the Transactional Memory TS. I believe I addressed all feedback for the
previous version of this patch (in particular, there are now more safety
checks for preconditions for th
On 01/14/2016 03:29 AM, Marek Polacek wrote:
This PR is a request for better array bounds diagnostics. The C++ FE says
"multidimensional array must have bounds for all dimensions except the first",
and we can do something similar in the C FE.
Bootstrapped/regtested on x86_64-linux, ok for trunk
On 01/14/2016 07:35 AM, Jakub Jelinek wrote:
Hi!
I've bootstrapped/regtested on x86_64-linux and i686-linux the following fix
from Francois that has been sitting in the PR for a few months.
The problem is that the testcase assumed that the last real_kind
has maximum precision and maximum range.
With my fix for PR c++/21802 I changed build_min_non_dep_call_vec() to
additionally retain the KOENIG_LOOKUP_P flag of the non-dependent
expression that's been built. This change was a little too general
though, since retaining the KOENIG_LOOKUP_P flag is only necessary for
build_min_non_dep_op_ov
On 01/14/2016 07:45 AM, Uros Bizjak wrote:
2016-01-14 Uros Bizjak
* lib/target-supports.exp (check_effective_target_issignaling):
New procedure.
* gcc.dg/pr61441.c: Require issignaling effective target.
Tested on x86_64-linux-gnu, CentOS 5.11 and Fedora 23.
OK for mainline?
Hi all,
This the 4.9 backport of
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00708.html.
The gcc change is the same, but the testcase is put into gcc.dg/torture rather
than gcc.c-torture/execute.
This is because the testcase actually requires a -std=gnu99, and adding a
dg-options in execute.
The arithmetic shift patterns set also the condition code. This adds
more substitution potential. Depending on whether the actual result
or the CC output will be used 3 different variants of each of these
patterns are needed. This multiplied with the PLUS and the AND
operands from the earlier su
When processing substitutions the operands are renumbered. To find a
free operand number the array used_operands_numbers is used to record
the operand numbers already in use. Currently this array is used to
assign new numbers *before* all the RTXes in the vector have been
processed.
I did run in
After Y is never used anymore with SImode operands we can finally
disallow SImode (if != Pmode) in s390_decompose_address. In fact that
was the whole point of the patch series.
gcc/ChangeLog:
2016-01-14 Andreas Krebbel
* config/s390/s390.c (s390_decompose_address): Don't accept SImod
This finally removes the Y constraint from the vector patterns while
folding some of them using a code iterator.
gcc/ChangeLog:
2016-01-14 Andreas Krebbel
* config/s390/subst.md (SUBST mode iterator): Add ashiftrt.
(DSI_VI): New mode iterator.
("addr_style_op_subst"):
This removes the Y constraint from the tabort pattern definition. In
this case it is easier without using substitutions.
gcc/ChangeLog:
2016-01-14 Andreas Krebbel
* config/s390/s390.md ("*tabort_1"): Change predicate to
addrreg_or_constint_operand. Add a second alternative t
This patch introduces substitution patterns to add PLUS const_int, and
AND operands to patterns and uses this to rewrite the existing rotate
pattern.
gcc/ChangeLog:
2016-01-14 Andreas Krebbel
* config/s390/predicates.md (addrreg_or_constint_operand)
(const_int_6bitset_operand)
So far whenever we wanted to disable an alternative we have used mode
attributes emitting constraints matching an earlier alternative
assuming that due to this the later alternative will never be chosen.
With this patch a `disabled' attribute is defined which can be used to
explicitly disable an a
Hi,
For test-case containing only the following declaration:
static struct undefined_struct object;
gcc rejects it at -O0 in assemble_variable() with error "storage size
of is unknown",
however no error is reported when compiled with -O2.
AFAIU that happens because at -O2, analyze_function() remov
On S/390 we have address style shift counts. So it is possible to
have a reg + const_int shift count. To address this it appeared to be
convenient to really handle this as address operand. For that reason
the "Y" constraint used for shift counts is an extra memory
constraint. Unfortunately a sh
On 14/01/16 12:22, Richard Biener wrote:
On Thu, Jan 14, 2016 at 11:26 AM, Alan Lawrence wrote:
If/when mips-ps-3d.md is moved from reduc_* to reduc_*_scal optabs (patch here:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00311.html ), there will be no
uses of the old reduc_* optabs remaining.
Hi,
This patch removes an attribute which was not required
and replaces the previous checks with an alternative
function call.
Regtested with x86_64 and committed to gomp4.
Jim
Index: gcc/c/ChangeLog.gomp
===
--- gcc/c/ChangeLog
On Thu, Jan 14, 2016 at 07:08:23PM +0300, Alexander Monakov wrote:
> On Thu, 14 Jan 2016, Jakub Jelinek wrote:
> > That is weird, because c is also a firstprivate var in target and
> > (implicitly) shared in teams, so if omp lowering/expansion is not buggy,
> > you should see the exactly same probl
On Thu, 14 Jan 2016, Jakub Jelinek wrote:
> That is weird, because c is also a firstprivate var in target and
> (implicitly) shared in teams, so if omp lowering/expansion is not buggy,
> you should see the exactly same problem with that.
> Wonder if we use GOMP_MAP_FIRSTPRIVATE_INT when we shouldn'
On 14/01/16 15:02, Andre Vieira (lists) wrote:
Unfortunately c99_functions is a very wide net. For instance, newlib supports
the ceill, but doesn't support
wscanf_s nor any bounds checking function I think.
wscanf_s is not c99
(it is in the optional annex k of c11, which is
likely to be remov
PING.
On Tue, Jan 5, 2016 at 8:07 AM, H.J. Lu wrote:
> On Mon, Dec 14, 2015 at 2:08 PM, H.J. Lu wrote:
>> On Mon, Dec 14, 2015 at 12:43 PM, Jason Merrill wrote:
>>> On 12/14/2015 03:39 PM, H.J. Lu wrote:
On Mon, Dec 14, 2015 at 12:16 PM, Jason Merrill wrote:
>
> On 12/12/2015
I am currently testing the following patch to fix PR69117 where
during value-numbering we end up using SSA name info (points-to info
in this case but also range-info in general) from the value leader
which may be defined under different conditions than the use is.
The only fix I can think of appr
> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Thursday, January 14, 2016 5:49 AM
> To: Alan Lawrence; Moore, Catherine
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH][MIPS] Migrate reduction optabs in mips-ps-3d.md
>
> Alan Lawrence writes
Hi Christian,
On 14/01/16 12:37, Christian Bruel wrote:
Here is the rebased patch after the #pragma GCC target warning fixes.
I also disabled the builtins initialisations when float-abi is solft as you suggested
This is ok with a couple of nits below addressed:
+/* Set up all the NEON builti
On Thu, 14 Jan 2016, Jakub Jelinek wrote:
> Hi!
>
> During complex lowering, we were walking bbs in bb index # order, which
> means sometimes we could visit SSA_NAME uses before visiting definitions.
> Also, even if we walk in rpo order as the following patch does, sometimes
> we need to first us
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-01-14 Richard Biener
PR tree-optimization/68060
* tree-vect-loop.c (vect_is_simple_reduction): Check the
outer loop reduction is only used in the inner loop before
detecting a double r
Hello Sasha,
On 14 Jan 15:08, Alexander Fomin wrote:
> Now bootstrapped and regtested against GCC v5.
> OK for 5-branch thus?
Your patch is OK for gcc-5 branch.
--
Thanks, K
>
> Regards,
> Alexander
In my fix for 67104 I knew that I wasn't handling RANGE_EXPRs, but
thought that it wasn't necessary, and left an assert to make sure.
Apparently I was wrong, so this patch implements the necessary range
splitting when the constexpr code wants to store to a single element of
a range.
Tested x8
Hi Christian,
That works in my local tests. Are you OK with it ?
yeah, I checked that it tests the attribute in my configuration as well.
just to make things less obfuscated, What about /* {
dg-additional-options "-mfpu=fp-armv8 } */ instead, eventually with a
selector for armv7-a.
just an id
On 11/01/16 16:39, Jakub Jelinek wrote:
On Mon, Jan 11, 2016 at 05:11:21PM +0100, Christophe Lyon wrote:
I tested a similar version on my side. It just makes the test become
UNSUPPORTED for arm/aarch64 + newlib. They used to pass, though.
Is anything bad on that? The test tests functions that
On Wed, Jan 13, 2016 at 09:05:47PM +0300, Alexander Monakov wrote:
> I'm testing 'target teams' implementation for gomp-nvptx branch, and I'm
> seeing test failures that, I think, are caused by faulty tests (unlike NVPTX,
> MIC offloading uses 1 team similar to native execution, so the issues are n
On 01/14/2016 03:31 PM, Jakub Jelinek wrote:
PR target/68269
* combine.c (expand_field_assignment): Punt if compute_mode is
unsupported scalar mode.
Ok.
Bernd
This applies some refactoring to vect_build_slp_tree to make a fix for
PR66856 easier (where I need to add some reference counting code to
stmts in SLP tree). Doing this w/o refactoring turned out to be
a "bit" unwieldly.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2
2016-01-14 Uros Bizjak
* lib/target-supports.exp (check_effective_target_issignaling):
New procedure.
* gcc.dg/pr61441.c: Require issignaling effective target.
Tested on x86_64-linux-gnu, CentOS 5.11 and Fedora 23.
OK for mainline?
Uros.
diff --git a/gcc/testsuite/gcc.dg/pr61441.
On Wed, Jan 13, 2016 at 06:39:35PM +0100, Martin Jambor wrote:
> +for (phi = hbb->m_first_phi;
> + phi;
> + phi = phi->m_next ? as_a (phi->m_next): NULL)
Space before :
Ok with that change.
Jakub
Hi!
I've bootstrapped/regtested on x86_64-linux and i686-linux the following fix
from Francois that has been sitting in the PR for a few months.
The problem is that the testcase assumed that the last real_kind
has maximum precision and maximum range. That is usually the case,
but is not the case
Hi!
This PR is an ICE while expand_field_assignment attempts to "simplify"
some (zero_extract:DI (subreg:DI (reg:OI ...) 0) (const_int 32) (const_int 0))
or what on ia64. The problem is that ia64 and various other backends add
various very large integral modes (OI in this case, but x86_64 even XI
Hi!
During complex lowering, we were walking bbs in bb index # order, which
means sometimes we could visit SSA_NAME uses before visiting definitions.
Also, even if we walk in rpo order as the following patch does, sometimes
we need to first use SSA_NAMEs before their definitions are lowered at lea
Hi Martin,
while addressing Jakub's feedback can you also fix the typos below?
(noticed because I needed to reuse those hunks in gomp-nvptx)
On Wed, 13 Jan 2016, Martin Jambor wrote:
> +/* Return a target argument consisiting of DEVICE identifier, value
> identifier
> + ID, and the actual VALU
On 01/13/16 17:44, Jakub Jelinek wrote:
On Wed, Jan 13, 2016 at 11:35:08PM +0100, Marek Polacek wrote:
On Wed, Jan 13, 2016 at 02:29:21PM -0800, Cesar Philippidis wrote:
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -5994,6 +5994,11 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx, tree
dec
1 - 100 of 125 matches
Mail list logo
