This patch adds support for C++17 allocation of types with alignment
greater than max_align_t using 'new'. This is on by default in C++17
and can also be enabled for other -std= with -falign-new.
If a user wants to use a different boundary than alignof(max_align_t),
perhaps because their malloc p
> Is there a testcase to show the problem with -mincoming-stack-boundary=
> on Linux?
I don't know, 'svn annotate' will probably tell you.
--
Eric Botcazou
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 16:22:32 2016 -0400
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
>> wrote:
>>> On Tue, Sep 6, 2016 at 2:24 AM, Kugan Vivekanandarajah
>>> wrote:
Hi Richard,
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 needs to generate more code
computing ve
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 forme
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 pr
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
accident
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 for
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 --with-arch-32=
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 of minor wrinkles and
> a quest
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 si
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__ (_Decimal
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 $0x09abcdef12345
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;
+ /* We record the first and
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 (lookup_stm
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:
>>> > Hi!
>>> >
>>> > While it would be perhaps nice to pass explic
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 ones
> are pointe
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, *cmp_i
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 code
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
>> falls into the unaligned cas
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 wil
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 patc
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 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 an
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
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 Pav
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
> >
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 (lib2funcs): Build _mulhc3
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 want instead the
target gcov ty
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. Also, to clarify, I say "warnings/errors" because
>>> they star
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 guess Solaris
>> is
Ping this patch:
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02099.html
Peter
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 things
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.
movabs
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 K
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 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 feedba
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 thi
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 of
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 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 gu
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 wrote:
>> > Can you quickly verify if LTO works with
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
2016-0
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 gua
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
> > that would prevent it b
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 f
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 5:13:06 PM GMT+02:00
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 that is -pthread.
>
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
>> wrote:
>>> Hi Richard,
>>>
>>> On 5 September 2016 at 17:57, Richard Biener
>>> wrote:
On Mon
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) == 32 vs. 64 (or T
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 regtested on x86_64-linu
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, 2016 12:33:02 PM GMT+02:00, Tom de Vries
>> wr
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 cal
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
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 posted
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
> >
> > PR
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 Biener
> wrote:
>> On Tue, Sep 6, 20
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
>> computing vectorized niters if overflow d
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)
>> == 4 vs. 8).
>> As
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 interpos
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 unneces
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 othe
64 matches
Mail list logo
