Mike Stump writes:
> On Jul 25, 2016, at 5:00 AM, Senthil Kumar Selvaraj
> wrote:
>>
>> The below patch fixes tests that fail for the avr target, because they
>> assume ints are atleast 32 bits wide and pointers and longs have the
>> same size.
>>
>> I've required int32plus support for on
Hi Alan,
Thanks for the writeup.
On Tue, Jul 26, 2016 at 04:09:12PM +0930, Alan Modra wrote:
> /* If this is a scalar floating point value and we want to load it into the
> traditional Altivec registers, do it via a move via a traditional
> floating
> point register, unless we have D
2016-07-26 0:08 GMT+03:00 Jeff Law :
> On 07/25/2016 12:32 PM, Richard Biener wrote:
>>
>> On July 25, 2016 8:01:17 PM GMT+02:00, Jeff Law wrote:
>>>
>>> On 07/22/2016 05:36 AM, Richard Biener wrote:
The thing that needs work I think is re-running of if-conversion.
>>>
>>> I wonder if we
This patch improves the readability of the prolog and epilog code by moving
some
code into separate functions. There is no difference in generated code.
OK for commit?
ChangeLog:
2016-07-26 Wilco Dijkstra
gcc/
* config/aarch64/aarch64.c (aarch64_pushwb_pair_reg): Rename.
(a
avr-gcc expected to find the device specs in the search paths specified. But
it doesn't work as expected when device specs in different place than the
installed location.
Example-1:
avr-gcc wrongly assumes the device specs will be in first identified
'device-specs' folder in prefix path. avr-gcc
On Tue, Jul 26, 2016 at 03:26:55AM -0500, Segher Boessenkool wrote:
> On Tue, Jul 26, 2016 at 04:09:12PM +0930, Alan Modra wrote:
> > /* If this is a scalar floating point value and we want to load it into
> > the
> > traditional Altivec registers, do it via a move via a traditional
> > fl
The following patch fixes a bug in selecting a "better" mode to
do a vector extract from. The existing code was evidently written
without knowing what GET_MODE_WIDER_MODE does for vector modes
in the face of multiple supported vector sizes. This results in
odd code-generation choices for HImode
On Mon, Jul 25, 2016 at 9:51 PM, Bill Schmidt
wrote:
> Hi,
>
> As reported on the gcc mailing list, slsr_process_phi contains a dead call
> to gimple_bb. I looked into why this wasn't noticed before, and concluded
> that we don't actually need the call. To reach this point, the phi argument
> mu
On Mon, Jul 25, 2016 at 10:57 PM, Andrew Pinski wrote:
> On Wed, Dec 2, 2015 at 5:23 AM, Michael Matz wrote:
>> Hi,
>>
>> On Tue, 1 Dec 2015, Jeff Law wrote:
>>
>>> > So, okay for trunk?
>>> -ENOPATCH
>>
>> Sigh :)
>> Here it is.
>
>
> I found one problem with it.
> Take:
> void f(int *a, int M,
On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote:
> Many warnings for dead-calls are emitted with patch on call to
> operator new in libsupc++/eh_alloc.cc, which I am not sure are correct
> or false positives, for instance:
>
> /home/prathamesh.kulkarni/gcc-svn/trunk/libstdc++-v3/libsupc++/eh_alloc
On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote:
> Hi,
> The following test-cases broke due to the warning.
> I think however the warning is right for all the cases:
>
> a) g++.dg/tree-ssa/invalid-dom.C:
> I believe the call from main() to E::bar() is dead call ?
Can't find this testcase.
> b) l
On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote:
> The following is an interesting case which broke stor-layout.c.
> The patch warned for the following call to be dead from
> bit_field_mode_iterator::next_mode() to get_mode_alignment ():
>
> /* Stop if the mode requires too much alignment.
On Tue, Jul 26, 2016 at 5:13 AM, kugan
wrote:
> Hi,
>
> For testcase in pr71994, type of bb conditional result and the type of the
> PHI stmt are different (as om.0_1 is int and the first PHI argument is
> _bool; PHI stmt uses a constant zero that comes from edge 2). Therefore when
> we optimize f
On Tue, Jul 26, 2016 at 11:57 AM, Ilya Enkovich wrote:
> 2016-07-26 0:08 GMT+03:00 Jeff Law :
>> On 07/25/2016 12:32 PM, Richard Biener wrote:
>>>
>>> On July 25, 2016 8:01:17 PM GMT+02:00, Jeff Law wrote:
On 07/22/2016 05:36 AM, Richard Biener wrote:
>
> The thing that needs wo
On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote:
> On 25 July 2016 at 14:32, Richard Biener wrote:
> > On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote:
> >
> >> Hi Richard,
> >> The attached patch tries to fix PR70920.
> >> It adds your pattern from comment 1 in the PR
> >> (with additional gating
On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote:
> Hi,
> The attached patch tries to fix PR71078.
> I am not sure if I have got the converts right.
> I put (convert? @0) and (convert1? (abs @1))
> to match for cases when operands's types may
> be different from outermost type like in pr71078-3.c
T
The 4.9 branch is now frozen for the final GCC 4.9.4 release, I will
announce GCC 4.9.4 RC1 once it has built.
Richard.
Hi Riachard,
Thanks for the review. Here is an updated patch with comments below.
+/* Restore/Pop all the old VRs maintained in the cond_stack. */
+
+void evrp_dom_walker::finalize_dom_walker ()
+{
+ while (!cond_stack.is_empty ())
+{
+ tree var = cond_stack.last ().second;
+
On 26.07.2016 12:20, Pitchumani Sivanupandi wrote:
avr-gcc expected to find the device specs in the search paths specified. But
it doesn't work as expected when device specs in different place than the
installed location.
Example-1:
avr-gcc wrongly assumes the device specs will be in first ident
Hi Richard,
On 26/07/16 21:48, Richard Biener wrote:
On Tue, Jul 26, 2016 at 5:13 AM, kugan
wrote:
Hi,
For testcase in pr71994, type of bb conditional result and the type of the
PHI stmt are different (as om.0_1 is int and the first PHI argument is
_bool; PHI stmt uses a constant zero that co
Hello.
This is python script that utilizes bugzilla API and marks PRs as spam:
$ ./mark_spam.py --help
usage: mark_spam.py [-h] [--verbose] api_key range
Mark Bugzilla issues as spam.
positional arguments:
api_key API key
range Range of IDs, e.g. 10-23,24,25,27
optional arguments
On Tue, Jul 26, 2016 at 2:34 PM, kugan
wrote:
> Hi Richard,
>
>
> On 26/07/16 21:48, Richard Biener wrote:
>>
>> On Tue, Jul 26, 2016 at 5:13 AM, kugan
>> wrote:
>>>
>>> Hi,
>>>
>>> For testcase in pr71994, type of bb conditional result and the type of
>>> the
>>> PHI stmt are different (as om.0_
2016-07-26 14:51 GMT+03:00 Richard Biener :
> On Tue, Jul 26, 2016 at 11:57 AM, Ilya Enkovich
> wrote:
>> 2016-07-26 0:08 GMT+03:00 Jeff Law :
>>> On 07/25/2016 12:32 PM, Richard Biener wrote:
On July 25, 2016 8:01:17 PM GMT+02:00, Jeff Law wrote:
>
> On 07/22/2016 05:36 AM, Ri
On Tue, Jul 26, 2016 at 3:03 PM, Ilya Enkovich wrote:
> 2016-07-26 14:51 GMT+03:00 Richard Biener :
>> On Tue, Jul 26, 2016 at 11:57 AM, Ilya Enkovich
>> wrote:
>>> 2016-07-26 0:08 GMT+03:00 Jeff Law :
On 07/25/2016 12:32 PM, Richard Biener wrote:
>
> On July 25, 2016 8:01:17 PM GMT
On 26 July 2016 at 17:28, Richard Biener wrote:
> On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote:
>
>> On 25 July 2016 at 14:32, Richard Biener wrote:
>> > On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote:
>> >
>> >> Hi Richard,
>> >> The attached patch tries to fix PR70920.
>> >> It adds your patt
On 26 July 2016 at 17:06, Richard Biener wrote:
> On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote:
>
>> Hi,
>> The following test-cases broke due to the warning.
>> I think however the warning is right for all the cases:
>>
>> a) g++.dg/tree-ssa/invalid-dom.C:
>> I believe the call from main() to E
On 26/07/16 11:08, Wilco Dijkstra wrote:
> This patch improves the readability of the prolog and epilog code by moving
> some
> code into separate functions. There is no difference in generated code.
>
> OK for commit?
>
> ChangeLog:
> 2016-07-26 Wilco Dijkstra
>
> gcc/
> * config/aa
On 26 July 2016 at 17:07, Richard Biener wrote:
> On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote:
>
>> The following is an interesting case which broke stor-layout.c.
>> The patch warned for the following call to be dead from
>> bit_field_mode_iterator::next_mode() to get_mode_alignment ():
>>
>>
Richard Biener writes:
> On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote:
>
>> Hi,
>> The attached patch tries to fix PR71078.
>> I am not sure if I have got the converts right.
>> I put (convert? @0) and (convert1? (abs @1))
>> to match for cases when operands's types may
>> be different from oute
On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote:
> On 26 July 2016 at 17:06, Richard Biener wrote:
> > On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote:
> >
> >> Hi,
> >> The following test-cases broke due to the warning.
> >> I think however the warning is right for all the cases:
> >>
> >> a) g++.
On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote:
> On 26 July 2016 at 17:07, Richard Biener wrote:
> > On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote:
> >
> >> The following is an interesting case which broke stor-layout.c.
> >> The patch warned for the following call to be dead from
> >> bit_fiel
On Tue, Jul 26, 2016 at 2:27 PM, kugan
wrote:
>
>
> Hi Riachard,
>
> Thanks for the review. Here is an updated patch with comments below.
>
>> +/* Restore/Pop all the old VRs maintained in the cond_stack. */
>> +
>> +void evrp_dom_walker::finalize_dom_walker ()
>> +{
>> + while (!cond_stack.is_e
> So i think with the various nits I pointed out the target independent
> stuff is good to go on the trunk. Then you can just iterate with the
> target guys to get those wrapped up.
OK, I'll do a pass on the entire patch, post a second version with the
required fixes, split into 2 parts as agree
On 26 July 2016 at 3:38:59 AM, Manuel López-Ibáñez
(lopeziba...@gmail.com) wrote:
> On 25 July 2016 at 18:18, ayush goel wrote:
> > On top of the previously filed patch for importing gnulib (the link
> > isn’t available on the archive yet, however this contains some of the
> > information:
> > htt
Hi,
> On May 5, 2016, at 8:14 AM, Robert Suchanek
> wrote:
> >
> > I'm resending this patch as it has been rebased and updated. I reverted a
> change
> > to check_effective_target_vect_call_lrint procedure because it does not use
> > cached result.
>
> Ok.
>
> Please ensure that the compilati
Hi,
It looks like we've not been handling structures of 16-bit floating-point
data correctly for AArch64. For some reason we end up passing them
packed in to integer registers. That is to say, on trunk and GCC 6, for:
struct x {
__fp16 x[4];
};
__fp16
foo1 (struct x x)
{
retur
On Tue, 26 Jul 2016, Richard Sandiford wrote:
> Richard Biener writes:
> > On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote:
> >
> >> Hi,
> >> The attached patch tries to fix PR71078.
> >> I am not sure if I have got the converts right.
> >> I put (convert? @0) and (convert1? (abs @1))
> >> to matc
On 07/25/2016 09:13 PM, kugan wrote:
Hi,
For testcase in pr71994, type of bb conditional result and the type of
the PHI stmt are different (as om.0_1 is int and the first PHI argument
is _bool; PHI stmt uses a constant zero that comes from edge 2).
Therefore when we optimize final range test stm
When I originally developed the IEEE 128-bit floating point support, the
emulation routines in libgcc did not raise errors on signalling NaNs. In the
course of adding full support for IEEE 128-bit floating point, we now have
added exception signaling support in the library. This means the C99/IEE
On 07/25/2016 07:55 PM, Trevor Saunders wrote:
On Mon, Jul 25, 2016 at 11:18:07AM -0600, Jeff Law wrote:
On 07/24/2016 05:44 AM, tbsaunde+...@tbsaunde.org wrote:
From: Trevor Saunders
gcc/ChangeLog:
2016-07-24 Trevor Saunders
* bt-load.c (compute_out): Use auto_sbitmap class.
On 07/26/2016 03:57 AM, Ilya Enkovich wrote:
Ilya, what's the fundamental reason why we need to run
if-conversion again? Yes, I know you want to if-convert the
epilogue, but why?
What are the consequences of not doing if-conversion on the
epilogue? Presumably we miss a vectorization opportunity
2016-07-26 18:26 GMT+03:00 Jeff Law :
> On 07/26/2016 03:57 AM, Ilya Enkovich wrote:
>>>
>>>
>>> Ilya, what's the fundamental reason why we need to run
>>> if-conversion again? Yes, I know you want to if-convert the
>>> epilogue, but why?
>>>
>>> What are the consequences of not doing if-conversion
The attached patch fixes an out of bound write to memory allocated
with alloca() on the stack. This rarely ever happened because on
one hand -fbounds-check needs to be enabled, and on the other hand
alloca() used to allocate a few bytes extra most of the time so
most of the time the excess write d
On 07/22/16 14:49, Bernd Edlinger wrote:
>
> Hmm, cough...
>
> Boot-strap and reg-test was OK, but...
>
> I just noticed that the new built-ins do not quite work as expected.
>
> First with C++ there is no warning in this example although the
> parameters are different:
>
> cat test2.C
> extern "C"
Hi Richard,
It turned out that the patch proposed by you does not work properly
for nested loop. If we slightly change pr70729.cc to
(non-essential part is omitted
void inline Ss::foo (float w)
{
#pragma omp simd
for (int i=0; i:
> Richard,
>
> Jakub has already fixed it.
> Sorry for troubles.
>
Finally a patch that works and is simple. Bootstrapped and
regression tested on s390, s390x biarch and x86_64. The new patch
exploits the known alignment of (stack pointer +
STACK_DYNAMIC_OFFSET) as described earlier (see below). I think
that is the right way to get rid of the extra allocation.
On Jul 26, 2016, at 1:08 AM, Senthil Kumar Selvaraj
wrote:
> Is the below patch ok?
Ok. Thanks. Such changes are trivial, usual and customary.
On Tue, Jul 26, 2016 at 11:23:38AM -0400, Michael Meissner wrote:
> When I originally developed the IEEE 128-bit floating point support, the
> emulation routines in libgcc did not raise errors on signalling NaNs. In the
> course of adding full support for IEEE 128-bit floating point, we now have
>
This patch updates c-format.c to use the new class substring_loc, added
in the previous patch, replacing location_column_from_byte_offset.
Hence with this patch, Wformat can underline the precise erroneous
format string in many more cases.
The patch also introduces two new functions for emitting W
This is an updated version of:
"[PATCH] RFC: On-demand locations within string-literals"
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00441.html
Changes in v2:
- Tweaks to substring location selftests
- Many more selftests (EBCDIC, the various wide string types, etc)
- Clean up conditions i
This adds fix-it hints to c-format.c so that it can (sometimes) suggest
the format string the user should have used.
The patch adds selftests for the new code in c-format.c. These
selftests are thus lang-specific. This is the first time we've had
lang-specific selftests, and hence the patch also
On Tue, Jul 26, 2016 at 6:42 PM, Dominik Vogt wrote:
> The attached patch fixes an out of bound write to memory allocated
> with alloca() on the stack. This rarely ever happened because on
> one hand -fbounds-check needs to be enabled, and on the other hand
> alloca() used to allocate a few bytes
On 26 July 2016 at 14:51, ayush goel wrote:
> On 26 July 2016 at 3:38:59 AM, Manuel López-Ibáñez
> (lopeziba...@gmail.com) wrote:
>> Why the change from "fnmatch.h" to ?
>
> Gnulib doesn’t contain a header for fnmatch. It itself relies on
> glib’c fnmatch.h
I see two modules here:
https://www.gn
Hi,
This patch adds support for constraint flags in loop structure. Different to
existing boolean flags which are set by niter analyzer, constraint flag is
mainly set by consumers and affects certain semantics of niter analyzer APIs.
Currently niter APIs affected are number_of_iterations_exit*
Hi,
This patch vectorizes possible infinite loops by versioning. It analyzes loops
considered for vectorization using loop constraint facility which was
introduced by previous patch; then vectorizes the loop with respect to
assumptions of loop niters information; at last, it sets constraint fla
On Mon, Jul 25, 2016 at 4:35 AM, Richard Biener wrote:
>
> So I needed to fix that builtins appearing in BLOCK_VARs and the solution
> I came up with accidentially disabled streaming via the special path.
> Thus the following patch removes the special-casing completely and makes
> the BLOCK_VARs h
On 26 July 2016 at 19:21, ayush goel wrote:
> On 26 July 2016 at 3:38:59 AM, Manuel López-Ibáñez
> (lopeziba...@gmail.com) wrote:
>> On 25 July 2016 at 18:18, ayush goel wrote:
>> > On top of the previously filed patch for importing gnulib (the link
>> > isn’t available on the archive yet, however
Hi!
As described in PR 71779 and PR 70903 we have a wrong code issue on aarch64
which is triggered by a paradoxical subreg that can be created in
store_bit_field_using_insv when the target has an EP_insv bitfield instruction.
The attached patch changes this insn...
(insn 1047 1046 1048 (set (reg
On 26/07/16 18:11, David Malcolm wrote:
gcc/ChangeLog:
* gcc.c (cpp_options): Rename string to...
(cpp_options_): ...this, to avoid clashing with struct in
cpplib.h.
It seems to me that you need this because now gcc.c includes cpplib.h via
input.h, which seems wrong.
On 07/23/2016 01:18 PM, Martin Sebor wrote:
+ /* A pair of the first non-static non-empty data members following
+ either the flexible array member, if found, or the zero-length
+ array member otherwise. AFTER[1] refers to the first such data
+ member of a union that the struct cont
On July 26, 2016 7:26:46 PM GMT+02:00, "H.J. Lu" wrote:
>On Mon, Jul 25, 2016 at 4:35 AM, Richard Biener
>wrote:
>>
>> So I needed to fix that builtins appearing in BLOCK_VARs and the
>solution
>> I came up with accidentially disabled streaming via the special path.
>> Thus the following patch re
On Tue, Jul 26, 2016 at 11:05:32AM -0500, Segher Boessenkool wrote:
> > --- gcc/testsuite/gcc.target/powerpc/float128-cmp.c (revision 0)
> > +++ gcc/testsuite/gcc.target/powerpc/float128-cmp.c (revision 0)
> > @@ -0,0 +1,17 @@
> > +/* { dg-do compile { target { powerpc*-*-linux* } } } */
> > +/* {
On 07/25/2016 05:03 AM, Renlin Li wrote:
Hi Martin,
I observed the following error:
ERROR: gcc.dg/atomic/pr71675.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects : syntax error in target selector "target c11" for
" dg-do 3 compile { target c11 } "
It seems we don't have a c11 effective t
C++11 has a
static_assert (COND, MESSAGE)
which gives more readable error messages for STATIC_ASSERT than our
current implementation.
This patch makes us use it if __cplusplus >= 201103L
There's also a provisional static_assert (COND) in C++1z, but presumably
we should wait until that one is fu
On Mon, 2016-07-25 at 10:36 +0200, Richard Biener wrote:
> On Fri, Jul 22, 2016 at 4:11 PM, Jakub Jelinek
> wrote:
> > On Fri, Jul 22, 2016 at 10:33:50AM -0400, David Malcolm wrote:
> > > gcc/cp/ChangeLog:
> > > * parser.h (struct cp_token): Add a STATIC_ASSERT on the
> > > size of the
On Tue, Jul 26, 2016 at 04:09:01PM -0400, Michael Meissner wrote:
> > Could you test all five functions please? Use multiple testcases, maybe.
>
> I decided to write an executable test rather than do more assembly tests. The
> patch to rs6000.c is unchanged, and the test now tests all of the com
On Tue, Jul 26, 2016 at 06:26:19PM -0500, Segher Boessenkool wrote:
> On Tue, Jul 26, 2016 at 04:09:01PM -0400, Michael Meissner wrote:
> > > Could you test all five functions please? Use multiple testcases, maybe.
> >
> > I decided to write an executable test rather than do more assembly tests.
Hi Jeff,
Thanks for your comments.
* tree-ssa-reassoc.c (maybe_optimize_range_tests): Check type
compatibility.
I'd kind of like to see some analysis of how we've got a bool here --
ISTM it ought to have been converted it to the type of the LHS of the
PHI when propagated.
You are r
On Tue, Jul 26, 2016 at 08:04:32PM -0400, Michael Meissner wrote:
> > dg-do compile? That's not testing much then, as an executable test!
>
> Good catch. Hopefully, third time is a charm. I verified that changing the
> dg-do compile to dg-do run did run properly on a big endian power7 (both
>
Hi James,
> Would you mind taking a look at some of these techniques to see if you can
> reduce the size of the generated automata without causing too much
> trouble for code generation for Vulcan?
Thanks for the review. I will look into this.
with regards,
Virendra Pathak
On Mon, Jul 25, 201
On Tue, Jul 26, 2016 at 4:32 AM, Richard Biener
wrote:
> On Mon, Jul 25, 2016 at 10:57 PM, Andrew Pinski wrote:
>> On Wed, Dec 2, 2015 at 5:23 AM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Tue, 1 Dec 2015, Jeff Law wrote:
>>>
> So, okay for trunk?
-ENOPATCH
>>>
>>> Sigh :)
>>> Here it is.
On 2016.07.23 at 22:55 -0400, Jason Merrill wrote:
> Using build_value_init in a base initialization is wrong, because it
> calls the complete object constructor and misses protected access. So
> let's handle list-value-initialization in expand_aggr_init_1.
>
> Tested x86_64-pc-linux-gnu, applyin
72 matches
Mail list logo
