On 13 December 2016 at 17:54, Jakub Jelinek wrote:
> On Tue, Dec 13, 2016 at 05:41:09PM +0530, Prathamesh Kulkarni wrote:
>> --- a/gcc/tree-ssa-strlen.c
>> +++ b/gcc/tree-ssa-strlen.c
>> @@ -,6 +,90 @@ handle_char_store (gimple_stmt_iterator *gsi)
>>return true;
>> }
>>
>> +/* Try to
On 12/09/2016 03:40 AM, Martin Liška wrote:
On 12/09/2016 11:02 AM, Martin Liška wrote:
Following patch enhances scripts and fixed various small issues.
Ready to be installed?
Martin
I forgot to squash commits, this is the right patch.
M.
0001-Enhance-analyze_brprob-script.patch
From c6
On 12/07/2016 08:24 PM, Martin Sebor wrote:
You're right! Good chatch! I missed that there are two ways to
represent the same thing. For example, these two declarations
void __attribute ((nonnull (1, 2)))
f (void);
void __attribute ((nonnull (1))) __attribute ((nonnull (2)))
f (void
On 12/07/2016 04:21 PM, Eric Botcazou wrote:
Presumably the MEM isn't a valid memory address, but it's allowed
through due to the use of an "X" constraint?
Yes (that was supposed to be more or less clear given the description :-).
ISTM that LRA has to be prepared to handle an arbitrary RTX, s
On 12/02/2016 05:36 PM, Martin Sebor wrote:
Bug 78608 - gimple-ssa-sprintf.c:570:17: runtime error: negation
of -9223372036854775808 cannot be represented in type 'long int'
points out an integer overflow bug in the pass caught by ubsan.
The bug was due to negating a number without checking for e
On 12/13/2016 09:07 PM, Martin Sebor wrote:
In a discussion of my patch for bug 78696 I mentioned I had found
a bug/limitation in MPFR that causes GCC to allocate excessive
amounts of memory on some corner cases (very large precision).
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01098.html
On 12/12/2016 05:40 PM, Kelvin Nilsen wrote:
@@ -15105,6 +15109,24 @@ If all of the enabled test conditions are false, t
The @code{scalar_test_neg} built-in functions return a non-zero value
if their @code{source} argument holds a negative value.
+The @code{__builtin_byte_in_set} function r
In a discussion of my patch for bug 78696 I mentioned I had found
a bug/limitation in MPFR that causes GCC to allocate excessive
amounts of memory on some corner cases (very large precision).
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01098.html
I've since raised GCC bug 78786 for the GCC p
On Tue, Dec 13, 2016 at 05:25:52PM -0700, Kelvin Nilsen wrote:
> Regarding the two test cases that are missing the scan-assembler
> directive (byte-in-set-1.c and byte-in-set-2.c), those tests are both
> expected to fail. They are checking that the compiler rejects those
> programs with appropriat
On Tue, Dec 13, 2016 at 06:17:17PM -0500, Michael Meissner wrote:
> > > + else if (mode == V8HImode)
> > > + {
> > > + rtx tmp_gpr_si = (GET_CODE (tmp_gpr) == SCRATCH
> > > + ? dest_si
> > > + : gen_rtx_REG (SImode, REGNO (tmp_gpr)));
> >
Thanks for your quick feedback.
I'll update the comments regarding possible future enhancement to
support QImode for operands[1] as well.
Regarding the two test cases that are missing the scan-assembler
directive (byte-in-set-1.c and byte-in-set-2.c), those tests are both
expected to fail. They
On 12/13/2016 04:49 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00262.html
(I would have almost forgotten about this if it weren't for bug
78786. While working on a fix for it I keep thinking that some
of the changes I'm making look like they should have already
Ping: https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00262.html
(I would have almost forgotten about this if it weren't for bug
78786. While working on a fix for it I keep thinking that some
of the changes I'm making look like they should have already been
made.)
Thanks
Martin
On 12/02/2016 05:
On Tue, Dec 13, 2016 at 04:40:20PM -0600, Segher Boessenkool wrote:
> > + /* If we got invalid arguments bail out before generating bad rtl.
> > */
>
> If what is invalid? Just remove the first comment?
I had copied the code from DST before, and it returns (const_int 0). However,
normal
On Tue, Dec 13, 2016 at 04:29:36PM -0600, Segher Boessenkool wrote:
> On Tue, Dec 13, 2016 at 10:15:02AM -0500, Michael Meissner wrote:
> > This patch should address the comments in the last patch.
> >
> > I have tested this patch with bootstrap builds and make check regression
> > tests
> > on a
Hi Mike,
On Tue, Dec 13, 2016 at 01:16:56PM -0500, Michael Meissner wrote:
> I have done bootstrap builds on a 64-bit power8 little endian system and a
> 32/64-bit power7 big endian system. There were no regressions. Can I check
> this into the GCC trunk?
Yes, please apply. One remark below.
On Tue, Dec 13, 2016 at 10:15:02AM -0500, Michael Meissner wrote:
> This patch should address the comments in the last patch.
>
> I have tested this patch with bootstrap builds and make check regression tests
> on a little endian Power8 64-bit system and a big endian Power7 32/64-bit
> system with
Hi Kelvin,
On Mon, Dec 12, 2016 at 05:40:05PM -0700, Kelvin Nilsen wrote:
> The patch has been bootstrapped and tested on
> powerpc64le-unknown-linux and powerpc-unknown-linux (big-endian, with
> both -m32 and -m64 target options) with no regressions.
>
> Is this ok for the trunk?
Yes it is, muc
debpoo.s
+===GNAT BUG DETECTED==+
| 7.0.0 20161213 (experimental) [trunk revision 243595] (sparc-sun-
solaris2.10) GCC error:|
| in lra_set_insn_recog_data, at lra.c:965 |
| Error detected around g-debpoo.adb:1896:8
Hi
I have been reported privately by Christophe in copy a regression
resulting from my recent changes to _Rb_tree. I removed a constructor
still necessary in C++03 mode or before. Tests would have shown it if I
had run them in C++03.
* include/bits/stl_tree.h
(_Rb_tree_impl(const
On 12/13/2016 02:32 PM, Jason Merrill wrote:
On 12/13/2016 03:25 PM, Martin Sebor wrote:
On 12/13/2016 12:06 PM, Jason Merrill wrote:
On 12/09/2016 07:46 PM, Martin Sebor wrote:
On 12/09/2016 02:49 PM, Jason Merrill wrote:
On Fri, Dec 9, 2016 at 11:33 AM, Martin Sebor
wrote:
For flexible ar
On 12/13/2016 03:25 PM, Martin Sebor wrote:
On 12/13/2016 12:06 PM, Jason Merrill wrote:
On 12/09/2016 07:46 PM, Martin Sebor wrote:
On 12/09/2016 02:49 PM, Jason Merrill wrote:
On Fri, Dec 9, 2016 at 11:33 AM, Martin Sebor wrote:
For flexible array members, because they're not in C++, we ge
Le 11/12/2016 à 23:21, Thomas Koenig a écrit :
Hello world,
the attached patch fixes a 5/6/7 regression with -fimplicit-none.
Regression-tested. OK for all affected branches?
OK. Thanks
Mikael
Use the boolean_type_node setup by the middle-end instead of
redefining it. boolean_type_node is not used in GFortran for any
ABI-visible stuff, only internally as the type of boolean
expressions. There appears to be one exception to this, namely the
caf_get* and caf_send* calls which have boolean_
On 12/13/2016 03:43 PM, Nathan Sidwell wrote:
On 12/13/2016 02:03 PM, Jason Merrill wrote:
OK with those changes.
Done.
+/* Template information for an alias template type. */
+#define TYPE_ALIAS_TEMPLATE_INFO(NODE) \
+ (DECL_LANG_SPECIFIC (TYPE_NAME (NODE
On 12/13/2016 12:06 PM, Jason Merrill wrote:
On 12/09/2016 07:46 PM, Martin Sebor wrote:
On 12/09/2016 02:49 PM, Jason Merrill wrote:
On Fri, Dec 9, 2016 at 11:33 AM, Martin Sebor wrote:
For flexible array members, because they're not in C++, we get to
make up the rules that make the most sen
On Mon, Dec 12, 2016 at 9:39 PM, Janne Blomqvist
wrote:
> On Mon, Dec 12, 2016 at 7:39 PM, Andre Vehreschild wrote:
>> Hi Janne,
>>
>> I found that you are favoring build_int_cst (size_type_node, 0) over
>> size_zero_node. Is there a reason to this?
>
> Yes. AFAIU size_zero_node is a zero constan
On 12/09/2016 07:46 PM, Martin Sebor wrote:
On 12/09/2016 02:49 PM, Jason Merrill wrote:
On Fri, Dec 9, 2016 at 11:33 AM, Martin Sebor wrote:
For flexible array members, because they're not in C++, we get to
make up the rules that make the most sense to us. IMO, they should
fit in well with t
On 12/13/2016 12:49 PM, Nathan Sidwell wrote:
+/* Template information for an alias template type. */
+#define TYPE_ALIAS_TEMPLATE_INFO(NODE) \
+ (DECL_LANG_SPECIFIC (TYPE_NAME (NODE)) \
+ ? DECL_TEMPLATE_INFO (TYPE_NAME (NODE))
2016-12-13 19:19 GMT+01:00 Janne Blomqvist :
> On Tue, Dec 13, 2016 at 8:13 PM, Janus Weil wrote:
>> Hi all,
>>
>> here is a straightforward cleanup patch that makes a few functions
>> return a bool instead of an int. Regtests cleanly on x86_64-linux-gnu.
>> Ok for trunk?
>
> Ok, thanks.
Thanks,
On Tue, Dec 13, 2016 at 07:32:33PM +0100, Andre Vehreschild wrote:
>
> attached patch fixes the issue by improving the check whether a call of the
> caf-runtime-routines needs to be generated instead of a regular assignment.
>
> Bootstraps and regtests ok on x86_64-linux/f23. Ok for trunk?
>
>
Hi all,
attached patch fixes the issue by improving the check whether a call of the
caf-runtime-routines needs to be generated instead of a regular assignment.
Bootstraps and regtests ok on x86_64-linux/f23. Ok for trunk?
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/testsuite
Hi Bill,
On Tue, Dec 13, 2016 at 11:13:08AM -0600, Bill Schmidt wrote:
> This patch makes a slight adjustment to the vectorization cost model that
> was previously overlooked.
>
> Bootstrapped and tested on powerpc64le-unknown-linux gnu with no regressions.
> Ok for trunk?
Sure, thanks!
> 2016
On Tue, Dec 13, 2016 at 8:13 PM, Janus Weil wrote:
> Hi all,
>
> here is a straightforward cleanup patch that makes a few functions
> return a bool instead of an int. Regtests cleanly on x86_64-linux-gnu.
> Ok for trunk?
Ok, thanks.
--
Janne Blomqvist
This patch adds support for the vec_vinsert4b and vec_vextract4b built-in
functions that generate the ISA 3.0 XXINSERTW and XXEXTRACTUW/VEXTUW{L,R}X
instructions. These functions are part of the PowerOpen 64-bit ELF V2 abi.
In doing the work, I noticed the P9V built-in ternary functions incorrect
Hi all,
here is a straightforward cleanup patch that makes a few functions
return a bool instead of an int. Regtests cleanly on x86_64-linux-gnu.
Ok for trunk?
Cheers,
Janus
2016-12-13 Janus Weil
PR fortran/78798
* gfortran.h (gfc_is_constant_expr, gfc_is_formal_arg,
gfc_is_com
On Fri, Dec 9, 2016 at 1:37 AM, Rainer Orth
wrote:
>
> 2016-12-09 Rainer Orth
>
> * configure.ac: Call GCC_CHECK_LINKER_HWCAP.
> * Makefile.am (AM_LDFLAGS): Initialize to HWCAP_LDFLAGS.
> [USING_SPLIT_STACK]: Add to AM_LDFLAGS.
> * aclocal.m4: Regenerate.
>
On 12/12/2016 10:28 PM, Jason Merrill wrote:
I suspect that most uses don't need to change.
Indeed. This addresses the ones I could find. Both by grepping pt.c and
fixing subsequent test fall out.
took the opportunity to make the control flow in get_underlying_template
somewhat clearer.
2016-12-13 13:36 GMT+04:00 Georg-Johann Lay :
> Ping #1
>
> As I explained below, the solution taken be arm (pruning output)
> does not work here.
Approved.
Please apply your patch.
>
> Johann
>
> On 02.12.2016 11:21, Georg-Johann Lay wrote:
>>
>> On 01.12.2016 17:40, Mike Stump wrote:
>>>
>>> On
Hi,
We have decided to apply the following patch to the embedded-6-branch to enable
ARMv8-M Security Extensions to ARM Cortex-M23 and ARM Cortex-M33.
ChangeLog entry is as follows:
*** gcc/ChangeLog ***
2016-12-13 Thomas Preud'homme
* config/arm/arm-cores.def (cortex-m23): Add FL
Hello!
Attached patch fixes STV cost function to better model gains of pandn
insn on non-BMI targets. As explained in the PR, STV converts four
scalar arithmetic insns (2 * not and 2 * and) to one (pandn). The
patch increases gain for non-BMI targets for 2 * ix86_cost->add to a
total of 3 * ix86_c
Hi,
This patch makes a slight adjustment to the vectorization cost model that
was previously overlooked.
Bootstrapped and tested on powerpc64le-unknown-linux gnu with no regressions.
Ok for trunk?
Thanks,
Bill
2016-12-13 Bill Schmidt
* config/rs6000/rs600.c (rs6000_builtin_vectoriz
Hi Janus,
thanks for the review. Committed as r243614.
- Andre
On Tue, 13 Dec 2016 16:08:59 +0100
Janus Weil wrote:
> Hi Andre,
>
> > thanks for the input on the missing testcase, Janus (btw, when you know
> > where to get a new crystal ball, let me know; I am missing mine, too). The
> > new
On 12/13/2016 03:52 AM, Marek Polacek wrote:
On Mon, Dec 12, 2016 at 06:36:16PM -0700, Martin Sebor wrote:
+/* Return true if the type of OP is signed, looking through any casts
+ to an unsigned type. */
+
+static bool
+operand_signed_p (tree op)
+{
+ bitmap visited = NULL;
+ bool ret = ope
On Thu, 2016-12-08 at 21:03 -0600, Segher Boessenkool wrote:
> On Thu, Dec 08, 2016 at 08:28:22AM -0800, Carl E. Love wrote:
> > The following patch adds two more built-ins that are missing.
> > Specifically:
> >
> > vector floatvec_packvector doublevector double
> > ve
On Tue, Dec 13, 2016 at 04:21:56PM +0100, Martin Liška wrote:
> gcc/ChangeLog:
>
> 2016-12-12 Martin Liska
>
> * sanopt.c (sanopt_optimize_walker): Set contains_asan_mark.
> (sanopt_optimize): Add new argument.
> (sanitize_asan_mark_unpoison): New function.
> (maybe_con
On 12/13/2016 01:29 PM, Jakub Jelinek wrote:
> On Tue, Dec 13, 2016 at 01:12:34PM +0100, Martin Liška wrote:
+ gimple_stmt_iterator gsi;
+ bool finish = false;
+ for (gsi = gsi_last_bb (bb); !gsi_end_p (gsi); gsi_prev (&gsi))
+ {
+gimple *stmt = gsi_stmt
This patch should address the comments in the last patch.
I have tested this patch with bootstrap builds and make check regression tests
on a little endian Power8 64-bit system and a big endian Power7 32/64-bit
system with no regressions. Can I check this into the trunk?
[gcc]
2016-12-13 Michae
Hi Andre,
> thanks for the input on the missing testcase, Janus (btw, when you know where
> to
> get a new crystal ball, let me know; I am missing mine, too). The new version
> of the patch adds a new testcase coarray_41.f90 to test that the compiler
> compiles correctly and the test runs ok.
>
>
I've found this useful several times. Note that currently
number_of_loops returns loops plus freed ones, the patch prepares
to change that, adjusting number_of_loops callers to use
vec_safe_length if they really want the maximum allocated loop
number.
Bootstrapped on x86_64-unknown-linux-gnu, te
On 13 December 2016 at 16:52, Richard Biener wrote:
> On Tue, Dec 13, 2016 at 3:45 PM, Ville Voutilainen
> wrote:
>> On 13 December 2016 at 16:42, Richard Biener
>> wrote:
>>> Also maybe N should be the number of exception objects rather
>>> than bytes? Otherwise a target independent N is hard
The following patch fixes PR78788.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2016-12-13 Richard Biener
PR tree-optimization/78788
* tree-vrp.c (set_value_range): Allow [-INF(OVF), +INF(OVF)].
(set_and_canonicalize_value_range): Do not dr
On Tue, Dec 13, 2016 at 3:45 PM, Ville Voutilainen
wrote:
> On 13 December 2016 at 16:42, Richard Biener
> wrote:
>> Also maybe N should be the number of exception objects rather
>> than bytes? Otherwise a target independent N is hard to specify
>> for say, a distribution that wants either a di
On 12/13/2016 04:42 AM, Martin Jambor wrote:
>> And this as well. But omp-grid.c is fine too.
>
> ...I prefer omp-grid.c because I plan to use gridification also for
> GCN targets, though hopefully only as an optimization rather than a
> hard requirement ...and in fact I still think it is a good
On 13 December 2016 at 16:42, Richard Biener wrote:
> Also maybe N should be the number of exception objects rather
> than bytes? Otherwise a target independent N is hard to specify
> for say, a distribution that wants either a different default or a
> static buffer.
But how to specify the numb
Hi Paul,
> We got there! OK for trunk.
thanks. Unfortunately there was a problem with my latest patch, so
what I now committed as r243609 is basically your fixed version of my
draft patch (with some very minor adjustments).
Phew, we finally nailed it!
(My dtio_13 fix had seemed to work at some
On Tue, Dec 13, 2016 at 2:50 PM, Jonathan Wakely wrote:
> This patch allows the size of the emergency buffer for exception
> handling to be controlled by a build-time macro (to avoid dynamic
> allocation) or by a run-time environment variable (to allocate a
> larger or smaller buffer).
>
> This wi
On Tue, Dec 13, 2016 at 10:05 AM, Martin Liška wrote:
> On 12/12/2016 12:10 PM, Eric Botcazou wrote:
>>> Ok. I'm sending a patch that put gcc_unreachable to places where either size
>>> or (and) offset is a non-constant. This survives regression tests
>>> (including ada) on x86_64-linux-gnu. Apart
On Mon, Dec 12, 2016 at 8:57 AM, kugan
wrote:
> Hi Richard,
>
>>> I am fine with the new patch but you'll need an approval from Honza
>>> or Richi.
>>>
>>> I find it a bit saddening that we cannot really rely on
>>> gimple_call_fntype but at least I do not see any other way.
>>
>>
>> The patch loo
On Thu, Dec 8, 2016 at 1:51 PM, Martin Liška wrote:
> On 12/02/2016 01:29 PM, Richard Biener wrote:
>> On Thu, Dec 1, 2016 at 5:30 PM, Martin Liška wrote:
>>> On 11/23/2016 03:13 PM, Jakub Jelinek wrote:
On Wed, Nov 23, 2016 at 02:57:07PM +0100, Martin Liška wrote:
> I started review pro
On Wed, Dec 7, 2016 at 5:14 PM, Robin Dapp wrote:
>> So we have (uint64_t)(uint32 + -1U) + 1 and using TYPE_SIGN (inner_type)
>> produces (uint64_t)uint32 + -1U + 1. This simply means that we cannot ignore
>> overflow of the inner operation and for some reason your change
>> to extract_range_from
Hi Janus, hi all,
thanks for the input on the missing testcase, Janus (btw, when you know where to
get a new crystal ball, let me know; I am missing mine, too). The new version
of the patch adds a new testcase coarray_41.f90 to test that the compiler
compiles correctly and the test runs ok.
Boots
This patch allows the size of the emergency buffer for exception
handling to be controlled by a build-time macro (to avoid dynamic
allocation) or by a run-time environment variable (to allocate a
larger or smaller buffer).
This will have to wait for the next stage 1 now, as it's too late for
GCC
Toma Tabacu writes:
> >
> > It's a shame this is the only way to deal with this but I see aarch64
> > have to resort to the same thing for error checking tests.
> >
>
> I have looked into this some more and I 've found that the solution I
> proposed is incomplete.
>
> The problem is that if no l
On Tue, 13 Dec 2016, Martin Jambor wrote:
> I have bootstrapped the two patches on aarch64-linux and bootstrapped
> and tested them on x86_64-linux. What do you think?
Sorry for my 'false alarm' about cp/parser.c conflict in the previous mail -- I
thought I was applying your patch to trunk, but n
Hi,
On Tue, Dec 13, 2016 at 12:43:16PM +0100, Jakub Jelinek wrote:
> On Tue, Dec 13, 2016 at 12:39:01PM +0100, Thomas Schwinge wrote:
> > On Fri, 9 Dec 2016 14:08:21 +0100, Martin Jambor wrote:
> > > this is the promised attempt at splitting omp-low.c [...]
> >
> > Yay! \o/
> >
> > I have not
On Tue, Dec 13, 2016 at 01:14:00PM +0100, Martin Liška wrote:
> On 12/13/2016 10:05 AM, Jakub Jelinek wrote:
> > Ok. But the builtins should be renamed too (incrementally),
> > BUILT_IN_ASAN_CLOBBER_N, "__asan_poison_stack_memory",
> > should really be BUILT_IN_ASAN_POISON_STACK_MEMORY etc.
> >
>
On Tue, Dec 13, 2016 at 01:12:34PM +0100, Martin Liška wrote:
> >> + gimple_stmt_iterator gsi;
> >> + bool finish = false;
> >> + for (gsi = gsi_last_bb (bb); !gsi_end_p (gsi); gsi_prev (&gsi))
> >> + {
> >> +gimple *stmt = gsi_stmt (gsi);
> >> +if (maybe_contains_asan_check
On Tue, Dec 13, 2016 at 05:41:09PM +0530, Prathamesh Kulkarni wrote:
> --- a/gcc/tree-ssa-strlen.c
> +++ b/gcc/tree-ssa-strlen.c
> @@ -,6 +,90 @@ handle_char_store (gimple_stmt_iterator *gsi)
>return true;
> }
>
> +/* Try to fold strstr (s, t) eq/ne s to memcmp (s, t, strlen (t)) eq/
On 12/13/2016 10:05 AM, Jakub Jelinek wrote:
> Ok. But the builtins should be renamed too (incrementally),
> BUILT_IN_ASAN_CLOBBER_N, "__asan_poison_stack_memory",
> should really be BUILT_IN_ASAN_POISON_STACK_MEMORY etc.
>
> Jakub
This is follow-up that I've just tested and reg-bootstrapp
On 12/13/2016 10:17 AM, Jakub Jelinek wrote:
> On Tue, Dec 13, 2016 at 09:56:00AM +0100, Martin Liška wrote:
>> @@ -671,18 +678,203 @@ public:
>>
>> }; // class pass_sanopt
>>
>
> Please add a short function comment here...
>
>> +static void
>> +sanitize_asan_mark_unpoison (void)
>> +{
>> +
On 13 December 2016 at 15:27, Jakub Jelinek wrote:
> On Tue, Dec 13, 2016 at 03:08:17PM +0530, Prathamesh Kulkarni wrote:
>> Thanks for the suggestions. It didn't occur to me to check for gimple_cond.
>> I have tried to do the changes in the attached version.
>> I am not sure if I have handled con
Hi Naveen,
On 13/12/16 11:51, Hurugalawadi, Naveen wrote:
Hi Kyrill,
Thanks for reviewing the patch and your useful comments.
looks good to me if it has gone through the normal required
bootstrap and testing, but I can't approve.
Bootstrapped and Regression Tested on aarch64-thunderx-linux.
Hi Kyrill,
Thanks for reviewing the patch and your useful comments.
>> looks good to me if it has gone through the normal required
>> bootstrap and testing, but I can't approve.
Bootstrapped and Regression Tested on aarch64-thunderx-linux.
>> The rest of the MD file uses the term AdvSIMD. Also,
Hi Janus,
no sorry. I mixed up the context. I thought your question was on pr78534. Sorry
for getting those two PRs mixed up. Just void my answer below. It is wrong. I
will see what I can do about a better testcase for the trans-array part. The
code responsible for the error unfortunately does not
Sorry, ignore the first attachment (2_combine_profile_multilib.patch). i always
miss that Thunderbird selects the first file in the in-review folder upfront.
Best regards,
Thomas
On 13/12/16 11:43, Thomas Preudhomme wrote:
Hi,
Fix in r242869 for PR77673 (bswap loads after end of object) appl
Hi,
Fix in r242869 for PR77673 was accompanied with r242870 which updated the
description of the struct symbolic_number modified by the previous patch. It did
so by rewriting the comment completely but I believe this patch should be still
backported to make the comment match the code.
Change
Hi,
Fix in r242869 for PR77673 (bswap loads after end of object) applies cleanly on
GCC 6 and with trivial fix for GCC 5 (gimple * in GCC 6 -> gimple in GCC 5). The
backports also bootstrap fine on x86_64-linux-gnu and testsuite shows no regression.
ChangeLog entries are as follow:
*** gcc/
On Tue, Dec 13, 2016 at 12:39:01PM +0100, Thomas Schwinge wrote:
> On Fri, 9 Dec 2016 14:08:21 +0100, Martin Jambor wrote:
> > this is the promised attempt at splitting omp-low.c [...]
>
> Yay! \o/
>
> I have not yet had a chance to review/test this patch, but I plan to.
>
> A few initial comm
Hi!
On Fri, 9 Dec 2016 14:08:21 +0100, Martin Jambor wrote:
> this is the promised attempt at splitting omp-low.c [...]
Yay! \o/
I have not yet had a chance to review/test this patch, but I plan to.
A few initial comments from the "bike shed departement"; I understand in
GCC sources it will n
Hi!
Sorry for not getting to this earlier.
On Mon, Nov 28, 2016 at 10:50:26AM +0100, Richard Biener wrote:
> > + else if (gimple_call_builtin_p (defstmt, BUILT_IN_MEMSET)
> > + && TREE_CODE (gimple_call_arg (defstmt, 0)) == ADDR_EXPR
> > + && TREE_CODE (gimple_call_arg (defstmt, 1)) ==
On 13 December 2016 at 12:18, Thomas Preudhomme
wrote:
> On 13/12/16 10:11, Christophe Lyon wrote:
>>
>> On 13 December 2016 at 10:54, Thomas Preudhomme
>> wrote:
>>>
>>> On 12/12/16 21:17, Christophe Lyon wrote:
Hi Thomas,
Thanks for working on this,
On 12
On 13/12/16 10:11, Christophe Lyon wrote:
On 13 December 2016 at 10:54, Thomas Preudhomme
wrote:
On 12/12/16 21:17, Christophe Lyon wrote:
Hi Thomas,
Thanks for working on this,
On 12 December 2016 at 18:52, Thomas Preudhomme
wrote:
Hi,
The logic to make -mthumb optional for Thumb-only
Hi Sandra,
> On 12/11/2016 01:28 PM, Rainer Orth wrote:
>> Hi Sandra,
>>
>>> PR 16519 notes that -pthread has only ever been documented as an RS6000 and
>>> Solaris 2 option. In fact it's supported by most/all(?) POSIX-flavored
>>> targets, including GNU/Linux, BSD variants, Darwin, etc. It's pro
Hi Andre,
> all the sanitizer issues I fixed occur during compiling the testsuite. So I
> would say, that when with the patch these errors do not occur anymore while
> processing the testsuite, then those are tested for, right?
aah, so you're saying that hunk is not actually related to the PR in
On Mon, Dec 12, 2016 at 06:36:16PM -0700, Martin Sebor wrote:
> +/* Return true if the type of OP is signed, looking through any casts
> + to an unsigned type. */
> +
> +static bool
> +operand_signed_p (tree op)
> +{
> + bitmap visited = NULL;
> + bool ret = operand_signed_p (op, &visited);
>
On Tue, Dec 13, 2016 at 11:18:31AM +0100, Dominik Vogt wrote:
> > IMHO you want something like x86 avx_runtime effective target
> > (z13_runtime?), which would stand for running on z13 capable hw and
> > with z13 assembler support.
>
> Something like that, yes, but it's not so easy because the ker
On Tue, Dec 13, 2016 at 11:15:43AM +0100, Martin Jambor wrote:
> I have bootstrapped the two patches on aarch64-linux and bootstrapped
> and tested them on x86_64-linux. What do you think?
Thanks a lot for the work. If you wouldn't mind doing a couple of further
changes (see below), I'd apprecia
On Tue, Dec 13, 2016 at 2:36 AM, Martin Sebor wrote:
> The attached patch avoids infinite recursion when traversing phi
> nodes in maybe_warn_alloc_args_overflow by using a bitmap to keep
> track of those already visited and breaking out.
It looks somewhat excessive (the whole PHI node walk looks
Dear Janus,
We got there! OK for trunk.
This was a demonstration of the corollary of the "bon mot" from Barack
Obama at the end of the message :-)
Many thanks for finding the right path.
Paul
On 13 December 2016 at 10:23, Janus Weil wrote:
> 2016-12-13 10:58 GMT+01:00 Janus Weil :
>> 2016-12-
Hi,
On Fri, Dec 09, 2016 at 07:18:54PM +0300, Alexander Monakov wrote:
> On Fri, 9 Dec 2016, Jakub Jelinek wrote:
> > Can you post an incremental patch fixing those issues?
>
> A few small nits I found while reading the patch.
>
> First of all, please use 'git diff --patience' (or --histogram) w
On Tue, Dec 13, 2016 at 10:42:37AM +0100, Jakub Jelinek wrote:
> On Tue, Dec 13, 2016 at 10:28:29AM +0100, Dominik Vogt wrote:
> > The attached patch fixes an md test execution problem on S/390.
> > The tests would be built with -march=z13 but executed even on
> > older machines. Build with -march
On 13 December 2016 at 10:54, Thomas Preudhomme
wrote:
> On 12/12/16 21:17, Christophe Lyon wrote:
>>
>> Hi Thomas,
>>
>> Thanks for working on this,
>>
>>
>> On 12 December 2016 at 18:52, Thomas Preudhomme
>> wrote:
>>>
>>> Hi,
>>>
>>> The logic to make -mthumb optional for Thumb-only devices is
On Tue, Dec 13, 2016 at 03:08:17PM +0530, Prathamesh Kulkarni wrote:
> Thanks for the suggestions. It didn't occur to me to check for gimple_cond.
> I have tried to do the changes in the attached version.
> I am not sure if I have handled cond_expr correctly.
> IIUC, if gimple_assign has code cond_
On 12/12/16 21:17, Christophe Lyon wrote:
Hi Thomas,
Thanks for working on this,
On 12 December 2016 at 18:52, Thomas Preudhomme
wrote:
Hi,
The logic to make -mthumb optional for Thumb-only devices is only executed
when no -marm or -mthumb is given on the command-line. This includes
configu
On Tue, Dec 13, 2016 at 09:52:40AM +0100, Richard Biener wrote:
> On Sun, Dec 11, 2016 at 5:16 PM, Uros Bizjak wrote:
> > On Fri, Dec 9, 2016 at 11:09 AM, Richard Biener
> > wrote:
> >> On Thu, Dec 8, 2016 at 10:44 PM, Uros Bizjak wrote:
> >>> Hello!
> >>>
> >>> Attached patch fixes fall-out fro
On Tue, Dec 13, 2016 at 10:28:29AM +0100, Dominik Vogt wrote:
> The attached patch fixes an md test execution problem on S/390.
> The tests would be built with -march=z13 but executed even on
> older machines. Build with -march=native instead, so executing
> the tests should work on any machine ge
On 09/12/16 15:27, Thomas Preudhomme wrote:
On 09/12/16 14:30, Kyrill Tkachov wrote:
On 09/12/16 14:24, Thomas Preudhomme wrote:
[Seeing as an RC for GCC 6.3 was suggested on IRC for mid next week]
Ping?
backport for 6 bootstraps on Thumb-1 and testsuite shows no regression for
either 5
On 9 December 2016 at 17:59, Jakub Jelinek wrote:
> On Fri, Dec 09, 2016 at 05:36:41PM +0530, Prathamesh Kulkarni wrote:
>> --- a/gcc/tree-ssa-strlen.c
>> +++ b/gcc/tree-ssa-strlen.c
>> @@ -2302,7 +2302,81 @@ strlen_optimize_stmt (gimple_stmt_iterator *gsi)
>> else if (gimple_assign_rhs_co
Ping #1
As I explained below, the solution taken be arm (pruning output)
does not work here.
Johann
On 02.12.2016 11:21, Georg-Johann Lay wrote:
On 01.12.2016 17:40, Mike Stump wrote:
On Dec 1, 2016, at 3:54 AM, Georg-Johann Lay wrote:
This patch moves the compile tests that have a hard co
1 - 100 of 112 matches
Mail list logo
