On Mon, Sep 5, 2016 at 6:11 PM, Tom de Vries wrote:
> On 05/09/16 09:49, Richard Biener wrote:
>>
>> On Sun, Sep 4, 2016 at 11:30 PM, Tom de Vries
>> wrote:
>>>
>>> > On 04/09/16 16:08, Richard Biener wrote:
>>
>> On September 4,
On 09/06/2016 12:51 PM, Bin Cheng wrote:
Hi,
This patch checks if loop has enough niters for peeling for data access gaps in
vect_analyze_loop_2, while now this check is in vect_transform_loop stage. The
problem is vectorizer may vectorize loops without enough iterations and
generate false
On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge wrote:
> Hi!
>
> I trimmed the CC list -- I'm looking for advice about debugging a lto1
> ICE.
>
> On Fri, 19 Aug 2016 11:05:59 +, Joseph Myers
> wrote:
>> On Fri, 19 Aug 2016, Richard Biener
Hi all,
The duplicate mode check in synth can just be deleted IMO. It was introduced as
part of r139821 that was
a much larger change introducing size/speed differentiation to the RTL midend.
So I think it's just a typo/copy-pasto.
Tested on aarch64-none-elf.
Ok?
Thanks,
Kyrill
2016-09-07
On 09/06/2016 12:49 PM, Bin Cheng wrote:
Hi,
This is a patch set generating new control flow graph for vectorized loop and
its peeling loops. At the moment, CFG for vecorized loop is complicated and
sub-optimal. Major issues are like:
A) For both prologue and vectorized loop, it generates
On 09/06/2016 12:52 PM, Bin Cheng wrote:
Hi,
This simple patch changes slpeel_tree_duplicate_loop_edge_cfg by putting copied
loop after its new preheader and after the original loop's latch in basic
block's linked list. It doesn't change CFG at all, but makes the dump cfg a
little bit easier
On Wed, Sep 07, 2016 at 11:15:34AM +0200, Florian Weimer wrote:
> On 09/06/2016 11:31 PM, Paul Eggert wrote:
> >On 09/06/2016 01:40 PM, Joseph Myers wrote:
> >>Sounds like a defect in C11 to me - none of the examples of flexible
> >>array
> >>members anticipate needing to add to the size to allow
On 09/06/2016 12:50 PM, Bin Cheng wrote:
Hi,
This simple patch adds interface reseting original copy table in cfg.c. This
will be used in rewriting vect_do_peeling_* functions in vectorizer so that we
don't need to release/allocate tables between prolog and epilog peeling.
Thanks,
bin
On 09/06/2016 12:53 PM, Bin Cheng wrote:
Hi,
After CFG changes in vectorizer, the epilog loop now can be completely peeled,
resulting in changes in the number of instructions that these tests check.
This patch adjusts related checking strings.
Thanks,
bin
gcc/testsuite/ChangeLog
2016-09-01
On 09/07/2016 02:19 AM, Richard Biener wrote:
On Tue, 6 Sep 2016, Jakub Jelinek wrote:
On Tue, Sep 06, 2016 at 04:59:23PM +0100, Kyrill Tkachov wrote:
On 06/09/16 16:32, Jakub Jelinek wrote:
On Tue, Sep 06, 2016 at 04:14:47PM +0100, Kyrill Tkachov wrote:
The v3 of this patch addresses
Hi Fritz,
please note: I do not have official review privileges. So my vote here
is rather an advise to you and the official reviewers. Often such a
inofficial review helps to speed things up, because the official ones
are pointed to the nics and nacs and don't have to bother with the
minor
On 09/07/2016 10:19 AM, Richard Biener wrote:
On Tue, 6 Sep 2016, Jakub Jelinek wrote:
If you want a 64-bit store, you'd need to merge the two, and that would be
even more expensive. It is a matter of say:
movl $0x12345678, (%rsp)
movl $0x09abcdef, 4(%rsp)
vs.
Hi!
I trimmed the CC list -- I'm looking for advice about debugging a lto1
ICE.
On Fri, 19 Aug 2016 11:05:59 +, Joseph Myers
wrote:
> On Fri, 19 Aug 2016, Richard Biener wrote:
> > Can you quickly verify if LTO works with the new types? I don't see
> > anything
>
On 09/06/2016 12:51 PM, Bin Cheng wrote:
Hi,
Current implementation requires that variables live outside of vect-loop
satisfying LCSSA form, this patch relaxes the restriction. It keeps the old
behavior for LCSSA PHI node by replacing use of live var with result of that
PHI; for other uses
On 09/06/2016 12:53 PM, Bin Cheng wrote:
Hi,
For loops which are bounded to iterate only 1 time (thus loop's latch doesn't
roll), there is nothing to predictive common, this patch detects/skips these
cases. A test is also added in
gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f for
On 06/09/16 14:14, Wilco Dijkstra wrote:
> Improve aarch64_legitimize_address - avoid splitting the offset if it is
> supported. When we do split, take the mode size into account. BLKmode
> falls into the unaligned case but should be treated like LDP/STP.
> This improves codesize slightly due to
On Wed, Sep 7, 2016 at 1:10 AM, kugan wrote:
> Hi Bin,
>
>
> On 07/09/16 04:54, Bin Cheng wrote:
>>
>> Hi,
>> LOOP_VINFO_NITERS is computed as LOOP_VINFO_NITERSM1 + 1, which could
>> overflow in loop niters' type. Vectorizer needs to generate more code
>>
On 09/06/2016 11:31 PM, Paul Eggert wrote:
On 09/06/2016 01:40 PM, Joseph Myers wrote:
Sounds like a defect in C11 to me - none of the examples of flexible
array
members anticipate needing to add to the size to allow for tail padding
with unknown alignment requirements.
Yes, I would prefer
On 08/18/2016 06:06 PM, Richard Biener wrote:
> On August 18, 2016 5:54:49 PM GMT+02:00, Jakub Jelinek
> wrote:
>> On Thu, Aug 18, 2016 at 08:51:31AM -0700, Andi Kleen wrote:
I'd prefer to make updates atomic in multi-threaded applications.
The best proxy we have for
On Wed, 7 Sep 2016, Yvan Roux wrote:
> Hi Richard,
>
> On 6 September 2016 at 14:41, Richard Biener wrote:
> >
> > The following fixes PR77450.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
> >
> > Richard.
> >
> > 2016-09-06 Richard Biener
On Tue, Sep 6, 2016 at 10:43 AM, Pierre-Marie de Rodat
wrote:
> Hello,
>
> On 08/29/2016 11:03 AM, Pierre-Marie de Rodat wrote:
>>
>> Here is another attempt to solve the original issue. This time, with a
>> proper testcase. ;-)
>>
>> Rebased against trunk, boostrapped and
On 09/07/2016 09:45 AM, Christophe Lyon wrote:
> On 6 September 2016 at 15:45, Martin Liška wrote:
>> On 09/06/2016 03:31 PM, Jakub Jelinek wrote:
>>> sizeof (gcov_type) talks about the host gcov type, you want instead the
>>> target gcov type. So
>>> TYPE_SIZE (gcov_type_node)
On 06/09/16 22:17, Jeff Law wrote:
> On 09/06/2016 03:08 AM, Jakub Jelinek wrote:
>> On Tue, Sep 06, 2016 at 11:06:36AM +0200, Richard Biener wrote:
>>> On Mon, Sep 5, 2016 at 6:17 PM, Andrew Haley wrote:
On 05/09/16 17:15, Richard Biener wrote:
> On September 5, 2016
I am not sure about the process, but it may also be nice/useful to add your new
macro to ForEachMacros in contrib/clang-format.
Dominik
> On 07 Sep 2016, at 02:21, Kugan Vivekanandarajah
> wrote:
>
> Hi Richard,
>
> On 6 September 2016 at 19:08, Richard
On Tue, 6 Sep 2016, Jakub Jelinek wrote:
> On Tue, Sep 06, 2016 at 04:59:23PM +0100, Kyrill Tkachov wrote:
> > On 06/09/16 16:32, Jakub Jelinek wrote:
> > >On Tue, Sep 06, 2016 at 04:14:47PM +0100, Kyrill Tkachov wrote:
> > >>The v3 of this patch addresses feedback I received on the version
On 09/06/2016 10:40 PM, Joseph Myers wrote:
On Tue, 6 Sep 2016, Paul Eggert wrote:
One way to correct the code is to increase malloc's argument up to a multiple
of alignof(max_align_t). (One cannot portably use alignof(struct s) due to
Sounds like a defect in C11 to me - none of the examples
Various places in GCC use negate, bit-and and compare to test whether
an integer is a power of 2, but I think it would be clearer for this
test to be wrapped in a function.
OK for trunk?
commit e2ca9914ce46d56775854f50c21506b220fd50b6
Author: Jason Merrill
Date: Wed Sep 7
On Wed, Aug 31, 2016 at 12:29 PM, Uros Bizjak wrote:
>> the new STV pass generates SSE instructions in 32-bit mode very late in the
>> pipeline and doesn't bother about realigning the stack, so it wreaks havoc on
>> OSes where you need to realign the stack, e.g. Windows, but I
Ping this patch:
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02099.html
Peter
On Tue, Sep 6, 2016 at 8:06 PM, Eric Gallager wrote:
> On 9/6/16, Uros Bizjak wrote:
>> On Tue, Sep 6, 2016 at 5:33 PM, Eric Gallager wrote:
>>> Ping? CC-ing an i386 maintainer since the patch mostly touches
>>> i386-specific files.
On 7 September 2016 at 11:34, Martin Liška wrote:
> On 09/07/2016 09:45 AM, Christophe Lyon wrote:
>> On 6 September 2016 at 15:45, Martin Liška wrote:
>>> On 09/06/2016 03:31 PM, Jakub Jelinek wrote:
sizeof (gcov_type) talks about the host gcov type, you
Hi,
This patch arranges for half-precision complex multiply and divide
routines to be built if __LIBGCC_HAS_HF_MODE__. This will be true
if the target supports the _Float16 type.
OK?
Thanks,
James
---
libgcc/
2016-09-07 James Greenhalgh
* Makefile.in
On September 6, 2016 5:14:47 PM GMT+02:00, Kyrill Tkachov
wrote:
>Hi all,
s/contigous/contiguous/
s/ where where/ where/
+struct merged_store_group
+{
+ HOST_WIDE_INT start;
+ HOST_WIDE_INT width;
+ unsigned char *val;
+ unsigned int align;
+ auto_vec stores;
On Wed, Sep 07, 2016 at 10:19:11AM +0200, Richard Biener wrote:
> > If you want a 64-bit store, you'd need to merge the two, and that would be
> > even more expensive. It is a matter of say:
> > movl $0x12345678, (%rsp)
> > movl $0x09abcdef, 4(%rsp)
> > vs.
> > movabsq
On 09/07/16 22:04, Joseph Myers wrote:
> On Wed, 7 Sep 2016, Bernd Edlinger wrote:
>
>> interesting. I just tried the test case from PR 77330 with _Decimal128.
>> result: _Decimal128 did *not* trap with gcc4.8.4, but it does trap with
>> gcc-7.0.0.
>
> I checked with GCC 4.3; __alignof__
Dear all,
the attached patch supports failed images also when -fcoarray=single is used.
Built and regtested on x86_64-pc-linux-gnu.
Cheers,
Alessandro
2016-08-09 5:22 GMT-06:00 Paul Richard Thomas :
> Hi Sandro,
>
> As far as I can see, this is OK barring a couple
On Wed, Sep 7, 2016 at 9:31 AM, Andre Vehreschild wrote:
> Hi Fritz,
>
> please note: I do not have official review privileges. So my vote here
> is rather an advise to you and the official reviewers. Often such a
> inofficial review helps to speed things up, because the official
On Wed, Sep 07, 2016 at 09:07:45AM +0200, Richard Biener wrote:
> > @@ -493,6 +504,8 @@ instrument_builtin_call (gimple_stmt_ite
> > if (!tree_fits_uhwi_p (last_arg)
> > || memmodel_base (tree_to_uhwi (last_arg)) >= MEMMODEL_LAST)
> > return;
> > + if
On Wed, 7 Sep 2016, Joseph Myers wrote:
> How about instead having more than one target macro / hook. One would
> indicate that excess precision is used by insn patterns (and be set only
> for i386 and m68k). Another would indicate the API-level excess precision
Or, maybe there would be a
On Wed, 7 Sep 2016, Bernd Edlinger wrote:
> Apparently the different -msse default setting made the situation worse.
> I think that will not run on a pentium4 any more.
I think that's x86_64-* defaulting to an x86_64 processor (which implies
SSE2 support) even with -m32 (unless a
On 6 September 2016 at 12:41, Christophe Lyon
wrote:
> On 6 September 2016 at 12:12, Jakub Jelinek wrote:
>> On Tue, Sep 06, 2016 at 12:07:47PM +0200, Christophe Lyon wrote:
>>> On 5 September 2016 at 19:20, Jakub Jelinek wrote:
libgcc complex multiply is meant to eliminate excess
precision from certain internal values by forcing them to memory in
exactly those cases where the type has excess precision. But in
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01894.html I
accidentally inverted the logic so that values get
On 09/07/2016 06:05 PM, James Greenhalgh wrote:
Hi,
This patch arranges for half-precision complex multiply and divide
routines to be built if __LIBGCC_HAS_HF_MODE__. This will be true
if the target supports the _Float16 type.
OK?
Ok, but please see Joseph's patch from today: I think you
On 09/07/2016 11:48 PM, Joseph Myers wrote:
libgcc complex multiply is meant to eliminate excess
precision from certain internal values by forcing them to memory in
exactly those cases where the type has excess precision. But in
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01894.html I
On 09/07/2016 04:52 AM, Mark Wielaard wrote:
If valgrind believes the
memory isn't in valid memory then it will complain about an invalid access.
But if the memory is accessible but uninitialised then it will just track
the undefinedness complain later if such a value is used.
I think the
On Sat, 2016-09-03 at 10:13 +0100, Manuel López-Ibáñez wrote:
> On 02/09/16 23:55, Martin Sebor wrote:
> > > diff --git a/gcc/substring-locations.h b/gcc/substring
> > > -locations.h
> > > index f839c74..bb0de4f 100644
> > > --- a/gcc/substring-locations.h
> > > +++ b/gcc/substring-locations.h
> >
On Wed, Sep 7, 2016 at 2:21 AM, Kugan Vivekanandarajah
wrote:
> Hi Richard,
>
> On 6 September 2016 at 19:08, Richard Biener
> wrote:
>> On Tue, Sep 6, 2016 at 2:24 AM, Kugan Vivekanandarajah
>>
On Wed, 7 Sep 2016, Florian Weimer wrote:
> The existence of such a cut-off constant appears useful, but it's not clear if
> it should be tied to the fundamental alignment (especially, as this discussion
> shows, the fundamental alignment will be somewhat in flux).
I don't think it's in flux. I
Hi Bin,
On 07/09/16 17:52, Bin.Cheng wrote:
On Wed, Sep 7, 2016 at 1:10 AM, kugan wrote:
Hi Bin,
On 07/09/16 04:54, Bin Cheng wrote:
Hi,
LOOP_VINFO_NITERS is computed as LOOP_VINFO_NITERSM1 + 1, which could
overflow in loop niters' type. Vectorizer
Hi Richard,
On 7 September 2016 at 19:35, Richard Biener wrote:
> On Wed, Sep 7, 2016 at 2:21 AM, Kugan Vivekanandarajah
> wrote:
>> Hi Richard,
>>
>> On 6 September 2016 at 19:08, Richard Biener
>>
This patch fixes handling header.gcc in subdirectories when command line option -remap has been
used. Current version finds header.gcc in directories from GCC include directory search path but
fails to find them in subdirectories due to missing directory separator.
Andris
2016-09-07 Andris
Hi Richard,
On 6 September 2016 at 14:41, Richard Biener wrote:
>
> The following fixes PR77450.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
>
> Richard.
>
> 2016-09-06 Richard Biener
>
> PR c/77450
>
On 09/05/2016 09:42 AM, Eric Botcazou wrote:
Attached output is from last test build (r239639 with DJGPP related patches
applied, last version of patches for Ada).
Very strange error, line 28 of gtype-ada.h is supposed to have a guard for
nodes containing the 'common' structure. Can you post
On Wed, 7 Sep 2016, James Greenhalgh wrote:
> 2016-09-07 James Greenhalgh
>
I'd think this should say
PR target/63250
as being part of fixing that bug (although not a fix by itself).
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 6 Sep 2016, James Greenhalgh wrote:
> In c-family/c-cppbuiltin.c I've updated cpp_iec_559_value such that also
> allow setting __GEC_IEC_559 if FLT_EVAL_METHOD=16, and I've updated
> c_cpp_builtins to handle the new value, and use the new enum names.
I think the special cases in this
On Wed, 7 Sep 2016, Joseph Myers wrote:
> On Wed, 7 Sep 2016, Florian Weimer wrote:
>
> > The existence of such a cut-off constant appears useful, but it's
not clear if
> > it should be tied to the fundamental alignment (especially, as this
discussion
> > shows, the fundamental alignment
On Tue, 6 Sep 2016, Jakub Jelinek wrote:
> Hi!
>
> As the PRs show, -fsanitize=thread hasn't been instrumenting __atomic_clear
> and __atomic_test_and_set builtins (i.e. those that operate on bool always),
> so we reported a data race on the testcase even when there wasn't one.
> And, as the
On Tue, 6 Sep 2016, Markus Trippelsdorf wrote:
> On 2016.09.06 at 14:26 +0200, Richard Biener wrote:
> > On Tue, 6 Sep 2016, Markus Trippelsdorf wrote:
> >
> > > On 2016.09.06 at 13:17 +0200, Richard Biener wrote:
> > > >
> > > > The following is an updated patch, mainly stripped out old
On 09/06/2016 11:23 AM, Richard Biener wrote:
The question then is, how can we make max_align_t more useful? If it is
supposed to reflect a malloc property, it cannot be a compile-time constant
because we don't know at compile time which malloc is going to be used
(malloc has to remain
On 6 September 2016 at 15:45, Martin Liška wrote:
> On 09/06/2016 03:31 PM, Jakub Jelinek wrote:
>> sizeof (gcov_type) talks about the host gcov type, you want instead the
>> target gcov type. So
>> TYPE_SIZE (gcov_type_node) == 32 vs. 64 (or TYPE_SIZE_UNIT (gcov_type_node)
>> ==
Hi Wilco,
On 7 September 2016 at 14:43, Richard Earnshaw (lists)
wrote:
> On 06/09/16 14:14, Wilco Dijkstra wrote:
>> Improve aarch64_legitimize_address - avoid splitting the offset if it is
>> supported. When we do split, take the mode size into account. BLKmode
>>
On Wed, 7 Sep 2016, Bernd Edlinger wrote:
> interesting. I just tried the test case from PR 77330 with _Decimal128.
> result: _Decimal128 did *not* trap with gcc4.8.4, but it does trap with
> gcc-7.0.0.
I checked with GCC 4.3; __alignof__ (_Decimal128) was 16 back then.
Whether particular
Hi,
The attached patch is a first part to solve PR 67591: it removes
several occurrences of "IT blocks containing 32-bit Thumb
instructions are deprecated in ARMv8" messages in the
gcc/g++/libstdc++/fortran testsuites.
It does not remove them all yet. This patch only modifies the
*cmp_and,
63 matches
Mail list logo