On 14/11/15 00:35, Jeff Law wrote:
Anyway, bootstrapped and regression tested on x86_64-linux-gnu.
Installed on the trunk.
[Patch,tree-optimization]: Add new path Splitting pass on tree ssa
representation
* Makefile.in (OBJS): Add gimple-ssa-split-paths.o
* common.op
Attached patch adds new Atmel devices to avr-gcc.
If Ok, could someone commit please? I do not have commit access.
Regards,
Pitchumani
gcc/ChangeLog
2015-11-18 Pitchumani Sivanupandi
* config/avr/avr-mcus.def: Add new avr4 devices atmega48pb and
atmega88pb. Add new avr5 devic
On 11/17/2015 08:05 AM, Steve Kargl wrote:
> The attached patch fixes an issue with SPREAD and the PARAMETER
> attribute when an array constructor is too large for expansion.
> gfortran now issues an error message and points to the
> -fmax-array-constructor.
>
> Patch built on i386-*-freebsd and
On Tue, Nov 17, 2015 at 07:53:18PM -0500, Michael Meissner wrote:
> Here is the temporary patch I'm using to get past rs6000.c. But I suspect the
> TOC alignment should never be 256.
Yes, it should be. Recent GNU ld aligns .TOC. to a 256 byte boundary.
I have this patch in my tree.
diff --git a
On Tue, Nov 17, 2015 at 04:36:01PM -0800, Steve Kargl wrote:
> On Wed, Nov 18, 2015 at 12:24:29AM +0100, Dominique d'Humières wrote:
> > > ??? but I suspect gfc_reduce_init_expr()
> > > may be useful for PARAMETER statements as well (need to
> > > check this!).
> >
> > As in the following test
>
On Wed, Nov 18, 2015 at 09:52:41AM +1030, Alan Modra wrote:
> David noticed that gcc112 was generating gcc/auto-host.h with
> #define POWERPC64_TOC_POINTER_ALIGNMENT 32768
>
> This is not the correct value of either 8 or 256 depending on how old
> ld is. On investigating I found the cause is Fedo
On Wed, Nov 18, 2015 at 12:24:29AM +0100, Dominique d'Humières wrote:
> > ??? but I suspect gfc_reduce_init_expr()
> > may be useful for PARAMETER statements as well (need to
> > check this!).
>
> As in the following test
>
> module m
> implicit none
> type t
> integer :: i
>
> Hi Ramana,
>
> Thanks for the review. I have opened a gcc bug-report for this. I tested
> the attached patch for arm-none-linux-gnueabihf and
> arm-none-linux-gnueabi with no new regressions. Is this OK?
>
>
> Thanks,
> Kugan
>
> gcc/ChangeLog:
>
> 2015-11-18 Kugan Vivekanandarajah
>
>
On Nov 17, 2015, at 8:50 AM, David Edelsohn wrote:
>
> Thanks for the pointer. How about the following?
Ok.
sizeof (*wfoo) or sizeof (wchar_t) or some such might be even more portable.
>
> Thanks, David
>
>
> Index: pr58708.C
> ==
> … but I suspect gfc_reduce_init_expr()
> may be useful for PARAMETER statements as well (need to
> check this!).
As in the following test
module m
implicit none
type t
integer :: i
end type t
type(t), dimension(2), parameter :: a1 = (/ t(1), t(2) /)
type(t), dimens
David noticed that gcc112 was generating gcc/auto-host.h with
#define POWERPC64_TOC_POINTER_ALIGNMENT 32768
This is not the correct value of either 8 or 256 depending on how old
ld is. On investigating I found the cause is Fedora 21 modifying the
toolchain to default to -z relro. ld -z relro put
On 11/17/2015 02:03 PM, Kyrill Tkachov wrote:
+ || !reg_overlap_mentioned_p (tmp_reg, SET_SRC (PATTERN (cand->insn
return false;
Well, I think the statement we want to make is
"return false from this function if the two expressions contain the same
register number".
I loo
invoke.texi needs updating for thunderxt88pass1 support.
--
Joseph S. Myers
jos...@codesourcery.com
[ was: Re: [PATCH, 10/16] Add pass_oacc_kernels pass group in passes.def ]
Hi,
Consider test-case test.c, with a use of the final value of the
iteration variable (return i):
...
unsigned int
foo (int *a, unsigned int n)
{
unsigned int i;
for (i = 0; i < n; ++i)
a[i] = 1;
return i;
}
On 11/13/2015 05:02 PM, Wilco Dijkstra wrote:
* gcc/ccmp.c (expand_ccmp_expr): Extract cmp_code from return value
of
expand_ccmp_expr_1.
I was trying to review this part of the patch in isolation and got very
confused because the patch also changes the return values of the ccmp
The way the current code was written assumes all cores have an unique part
num which is not true. What they have is an unique pair of implementer and
part num. This changes the code to look up that pair after the parsing
of the two is done.
Someone should test this on a big.little target too ju
This moves the #undef from the header files to the .def files like was done
for builtins.def (https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00662.html).
OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
Thanks,
Andrew Pinski
* config/aarch64/aarch64-arches.def (AARCH64_ARC
Since ThunderX T88 pass 1 (variant 0) is a ARMv8 part while pass 2 (variant 1)
is an ARMv8.1 part, I needed to add detecting of the variant also for this
difference. Also I simplify a little bit and combined the single core and
arch detecting cases so it would be easier to add variant.
OK? Bootst
Because the imp and parts are really integer rather than strings, this patch
moves the comparisons to be integer. Also allows saving around integers are
easier than doing string comparisons. This allows for the next change.
The way I store BIG.little is (big<<12)|little as each part num is only
To Add support for -mcpu=thunderxt88pass1, I needed to fix up a few
things in the support for -mcpu=native. First was I wanted to do the same
cleanup that was done for some of the other .def files and move the
#undef into the .def files instead of the .h files.
Second to make it easier to underst
Just to make it easier to see which cores blong to which company and
the order clearier, add a comment in front of the cores sections.
OK?
Thanks,
Andrew Pinski
* config/aarch64/aarch64-cores.def: add a comment before each set
of cores.
---
gcc/config/aarch64/aarch64-cores.def | 9 +
1
On 17/11/15 12:41, Richard Biener wrote:
On Tue, 17 Nov 2015, Tom de Vries wrote:
Hi,
this no-functional-changes patch improves comments in
pass_tree_loop_init::execute.
For the discussion related to the comment for scev_initialize, see:
- https://gcc.gnu.org/ml/gcc-patches/2013-02/msg01127.h
On 11/17/2015 01:15 PM, Jason Merrill wrote:
A couple of bootstrap issues on some targets:
68346: My earlier change to avoid folding the arguments to
warn_tautological_cmp wasn't quite right, either. This patch folds
within the function, at the place where we are interested in a constant
value.
I've checked in this patch which fixes another long-standing
documentation issue in bugzilla. Here there was a missing entry for
__attribute__((visibility ("protected"))) (or whatever) in the section
on variable attributes, although there was an example showing its use on
a variable in the fun
Here's what looks like a fairly simple patch, but it leads
to a question. Why does gfortran not try to reduce the
components in a structure constructor in general? I've
hidden the gfc_reduce_init_expr() behind a check for a
DATA statement, but I suspect gfc_reduce_init_expr()
may be useful for
On Tue, 2015-11-17 at 16:24 +0100, Bernd Schmidt wrote:
> On 11/17/2015 04:13 PM, David Malcolm wrote:
> > On Mon, 2015-11-16 at 22:34 +0100, Bernd Schmidt wrote:
> >>
> >> Should c_expr perhaps acquire a constructor so that this problem is
> >> avoided in the future? The whole thing seems somewhat
On 11/17/2015 06:24 AM, Rainer Orth wrote:
I'm still investigating what causes those timeouts, it seems to be a
scalability issue in libc.
While I realize that we are past stage1, maybe the fact that this patch
is for an off-by-default feature and well localized still could allow it
into mainli
On 17/11/15 21:05, Ramana Radhakrishnan wrote:
> Hi Kugan,
>
> It does look like an issue.
>
> Please open a bug report.
>
>>
>>
>> On 17/11/15 12:00, Charles Baylis wrote:
>>> On 16 November 2015 at 22:24, Kugan
>>> wrote:
>>>
Please note that we have a sibcall from "broken" to "indire
I've been talking about a compiler built-in to implement
make_integer_sequence since before the proposal even made it into the
standard, so I tried to implement one that would allow:
template
using make_integer_sequence = integer_sequence< __intseq(_Tp, _Num) >;
But I don't know the front-end w
On Mon, Nov 16, 2015 at 10:02:15AM +0100, Richard Biener wrote:
> On Sat, 14 Nov 2015, Senthil Kumar Selvaraj wrote:
>
> > On Sat, Nov 14, 2015 at 09:57:40AM +0100, Richard Biener wrote:
> > > On November 14, 2015 9:49:28 AM GMT+01:00, Senthil Kumar Selvaraj
> > > wrote:
> > > >On Sat, Nov 14, 2
For the record, I committed the following:
2015-11-17 Steven G. Kargl
* primary.c (gfc_match_structure_constructor): Fix whitespace.
--
Steve
Index: primary.c
===
--- primary.c (revision 230494)
+++ primary.c (workin
On 16/11/2015 11:29, Jonathan Wakely wrote:
> On 15/11/15 22:12 +0100, François Dumont wrote:
>> Here is a last version I think.
>>
>>I completed the debug light mode by adding some check on iterator
>> ranges.
>>
>>Even if check are light I made some changes to make sure that
>> internally
On 11/17/2015 09:39 AM, Richard Biener wrote:
On Tue, Nov 17, 2015 at 3:09 PM, Jason Merrill wrote:
While I was looking at the interaction of delayed folding with GGC, I
noticed that ggc_handle_finalizers currently runs no finalizers if
G.context_depth != 0. So any GC objects in a greater dept
On Mon, Nov 09, 2015 at 02:09:31PM +0100, Andreas Krebbel wrote:
> On 11/02/2015 09:44 AM, Dominik Vogt wrote:
> > (@Uli: I'd like to hear your opinion on this issue.
> > Original message:
> > https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03403.html).
> >
> > On Fri, Oct 30, 2015 at 03:09:39PM +01
Nothing uses these macros and removing them makes it more likely
that future code will use CASE_CFN_* instead.
Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabi.
Applied as obvious.
Thanks,
Richard
gcc/
* tree.h (BUILTIN_EXP10_P, BUILTIN_EXPONENT_P, BUILTIN_SQRT_P)
I've checked in this patch to fix PR53587, which is about missing
documentation for the -mms-bitfields command-line option for x86. It
turns out there *was* documentation, but it was buried in the discussion
of the corresponding variable attributes with no pointers in the option
summary or ind
A couple of bootstrap issues on some targets:
68346: My earlier change to avoid folding the arguments to
warn_tautological_cmp wasn't quite right, either. This patch folds
within the function, at the place where we are interested in a constant
value.
68361: The way we were trying to suppres
On 11/17/2015 05:51 AM, Bernd Schmidt wrote:
On 11/17/2015 02:53 AM, Mike Stump wrote:
On Nov 16, 2015, at 3:12 PM, Jeff Law wrote:
So I'd tend to want them either at the end of the file with a
single #if CHECKING_P or as a separate foo-tests file.
Hum… I kinda don’t want the main files muc
Attached is a patch fixing the ICE caused by a prior change of mine:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=230081
Tested on x86_64, committing to trunk as per Jason via IRC.
Martin
gcc/ChangeLog:
2015-11-17 Martin Sebor
PR c++/68308
* cp/init.c (build_new
On Tue, Nov 17, 2015 at 12:23:51PM -0500, Nathan Sidwell wrote:
> On 11/17/15 12:23, Nathan Sidwell wrote:
> >On 11/17/15 12:16, Cesar Philippidis wrote:
> >>This patch adds an empty priority_queues.c in libgomp for nvptx targets.
> >>Nvptx targets don't have sufficient support for a complete libgo
On 11/17/2015 09:23 AM, Nathan Sidwell wrote:
> On 11/17/15 12:23, Nathan Sidwell wrote:
>> On 11/17/15 12:16, Cesar Philippidis wrote:
>>> This patch adds an empty priority_queues.c in libgomp for nvptx targets.
>>> Nvptx targets don't have sufficient support for a complete libgomp
>>> library, so
On 11/17/15 12:23, Nathan Sidwell wrote:
On 11/17/15 12:16, Cesar Philippidis wrote:
This patch adds an empty priority_queues.c in libgomp for nvptx targets.
Nvptx targets don't have sufficient support for a complete libgomp
library, so we're only building a subset of it. And without that empty
On 11/17/15 12:16, Cesar Philippidis wrote:
This patch adds an empty priority_queues.c in libgomp for nvptx targets.
Nvptx targets don't have sufficient support for a complete libgomp
library, so we're only building a subset of it. And without that empty
file, I was seeing an error message that l
On Tue, 17 Nov 2015, Paolo Bonzini wrote:
> On 17/11/2015 17:02, Joseph Myers wrote:
> > On Tue, 17 Nov 2015, Paolo Bonzini wrote:
> >
> >> * it doesn't promise that GCC will never rely on undefined behavior
> >> rules for signed left shifts
> >
> > I think we should remove the ", but this is su
On Tue, Nov 17, 2015 at 09:16:05AM -0800, Cesar Philippidis wrote:
> This patch adds an empty priority_queues.c in libgomp for nvptx targets.
> Nvptx targets don't have sufficient support for a complete libgomp
> library, so we're only building a subset of it. And without that empty
> file, I was s
This patch adds an empty priority_queues.c in libgomp for nvptx targets.
Nvptx targets don't have sufficient support for a complete libgomp
library, so we're only building a subset of it. And without that empty
file, I was seeing an error message that looked like this:
libgomp/libgomp.h:122:17: fa
On 17/11/2015 17:02, Joseph Myers wrote:
> On Tue, 17 Nov 2015, Paolo Bonzini wrote:
>
>> * it doesn't promise that GCC will never rely on undefined behavior
>> rules for signed left shifts
>
> I think we should remove the ", but this is subject to change" in
> implement-c.texi (while replacin
On 17/11/2015 17:02, Joseph Myers wrote:
> On Tue, 17 Nov 2015, Paolo Bonzini wrote:
>
>> * it doesn't promise that GCC will never rely on undefined behavior
>> rules for signed left shifts
>
> I think we should remove the ", but this is subject to change" in
> implement-c.texi (while replacin
On Tue, Nov 17, 2015 at 11:22 AM, Jonathan Wakely wrote:
> On 17 November 2015 at 16:04, David Edelsohn wrote:
>> The testcase in the GCC testsuite assumes that wchar_t is 32 bits,
>> which is not correct on AIX. 32 bit AIX maintains 16 bit wchar_t for
>> backward compatibility (64 bit AIX uses 3
On 16/11/15 14:42, Christophe Lyon wrote:
Hi Alan,
I've noticed that this new test (gcc.dg/vect/bb-slp-subgroups-3.c)
fails for armeb targets.
I haven't had time to look at more details yet, but I guess you can
reproduce it quickly enough.
Thanks - yes I see it now.
-fdump-tree-optimized lo
On 17/11/15 12:29, Bernd Schmidt wrote:
On 11/16/2015 04:48 PM, Andre Vieira wrote:
On 16/11/15 15:34, Joern Wolfgang Rennecke wrote:
I just happened to stumble on this problem with another port.
The volatile & test solution doesn't work, though.
What does work, however, is:
__asm__ ("" : : "
On 11/16/15 17:07, Nathan Sidwell wrote:
I've committed this patch to the gomp4 branch. It adds support for worker and
gang level complex double reductions.
I was unsatisfied with that approach, so I've separated the two mechanisms into
different functions with the attached patch. The lockin
On 17 November 2015 at 16:04, David Edelsohn wrote:
> The testcase in the GCC testsuite assumes that wchar_t is 32 bits,
> which is not correct on AIX. 32 bit AIX maintains 16 bit wchar_t for
> backward compatibility (64 bit AIX uses 32 bit wchar_t).
>
> What is the preferred method to make the te
Kirill,
* c-c++-common/attr-simd.c
and
* c-c++-common/attr-simd-3.c
fail on 32 bit systems, e.g., see powerpc64-linux tested in 32 bit mode.
- David
The attached patch fixes an issue with SPREAD and the PARAMETER
attribute when an array constructor is too large for expansion.
gfortran now issues an error message and points to the
-fmax-array-constructor.
Patch built on i386-*-freebsd and x86_64-*-freebsd. There are
no regressions. OK to com
The testcase in the GCC testsuite assumes that wchar_t is 32 bits,
which is not correct on AIX. 32 bit AIX maintains 16 bit wchar_t for
backward compatibility (64 bit AIX uses 32 bit wchar_t).
What is the preferred method to make the testcase safe for smaller wchar_t?
The following patch works f
On Tue, 17 Nov 2015, Paolo Bonzini wrote:
> * it doesn't promise that GCC will never rely on undefined behavior
> rules for signed left shifts
I think we should remove the ", but this is subject to change" in
implement-c.texi (while replacing it with noting that ubsan will still
diagnose such c
On 17/11/2015 16:27, Joseph Myers wrote:
> > Can you suggest a wording for "if the GNU C language definition changes
> > [which, no matter how unlikely, is explicitly not ruled out by the
> > manual] -fwrapv will be extended to signed shifts, and shifts of
> > negative numbers would return A*2^B
On 17/11/15 16:18, Richard Biener wrote:
IMHO autopar needs to handle induction itself.
>
>I'm not sure what you mean. Could you elaborate? Autopar handles induction
>variables, but it doesn't handle exit phis reading the final value of the
>induction variable. Is that what you want fixed? How?
On Tue, 17 Nov 2015, Tom de Vries wrote:
> On 17/11/15 11:05, Richard Biener wrote:
> > On Tue, Nov 17, 2015 at 12:20 AM, Tom de Vries
> > wrote:
> > > On 16/11/15 13:45, Richard Biener wrote:
> > > > > >
> > > > > > + NEXT_PASS (pass_scev_cprop);
> > > > > > > >
> > > > > > > > Wha
On Tue, 17 Nov 2015, Paolo Bonzini wrote:
> Can you suggest a wording for "if the GNU C language definition changes
> [which, no matter how unlikely, is explicitly not ruled out by the
> manual] -fwrapv will be extended to signed shifts, and shifts of
> negative numbers would return A*2^B whenever
On 11/17/2015 04:13 PM, David Malcolm wrote:
On Mon, 2015-11-16 at 22:34 +0100, Bernd Schmidt wrote:
Should c_expr perhaps acquire a constructor so that this problem is
avoided in the future? The whole thing seems somewhat error-prone.
I agree that it's error prone, and the ctor approach is w
Ping:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01192.html
> gcc/cp/ChangeLog:
>
> * cp-gimplify.c (genericize_cp_loop): Change LOOP_EXPR's location
> to start of loop body instead of start of loop.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/guality/pr67192.C: New tes
On Mon, 2015-11-16 at 22:34 +0100, Bernd Schmidt wrote:
> On 11/16/2015 09:50 PM, David Malcolm wrote:
> > The root cause is uninitialized data. Specifically, the C parser's
> > struct c_expr gained a "src_range" field, and it turns out there are a
> > few places where I wasn't initializing this w
On Mon, Nov 16, 2015 at 10:47 PM, Jason Merrill wrote:
> On 11/16/2015 09:39 PM, David Edelsohn wrote:
>>
>> The PPC port seems to be bootstrapping again, but I'm not sure why.
>> Mike Meissner's patch only should have affected long double.
>
>
>> It's hard to know if there is a latent bug that ha
On Tue, Nov 17, 2015 at 10:53:52AM +0100, Dominique d'Humi??res wrote:
> Is the following patch OK for trunk and 5.3?
OK.
>
> I have used the legalese found in my draft for Fortran 2015.
> Would it be acceptable to replace
> "with the BIND attribute or the SEQUENCE attribute"
> with
> "with t
On 17/11/15 11:05, Richard Biener wrote:
On Tue, Nov 17, 2015 at 12:20 AM, Tom de Vries wrote:
On 16/11/15 13:45, Richard Biener wrote:
+ NEXT_PASS (pass_scev_cprop);
What's that for? It's supposed to help removing loops - I don't
expect kernels to vanish.
I'm using pass_sc
On Tue, Nov 17, 2015 at 3:09 PM, Jason Merrill wrote:
> While I was looking at the interaction of delayed folding with GGC, I
> noticed that ggc_handle_finalizers currently runs no finalizers if
> G.context_depth != 0. So any GC objects in a greater depth will still be
> collected, but they won't
On Tue, Nov 17, 2015 at 10:55 AM, Richard Sandiford
wrote:
> Richard Sandiford writes:
>> Richard Biener writes:
>>> On Tue, Nov 10, 2015 at 10:24 PM, Richard Sandiford
>>> wrote:
Richard Biener writes:
> On Sat, Nov 7, 2015 at 2:31 PM, Richard Sandiford
> wrote:
>> This patc
On Tue, Nov 17, 2015 at 10:30 AM, Richard Sandiford
wrote:
> Thanks for all the reviews for this series. I think the patch below
> is the only target-independent one that hasn't had any comments.
This patch is ok.
Thanks,
Richard.
> Richard
>
> Richard Sandiford writes:
>> This patch tries to
On Tue, Nov 17, 2015 at 10:23 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On November 10, 2015 9:13:25 PM GMT+01:00, Richard Sandiford
>> wrote:
>>>Richard Biener writes:
On Sat, Nov 7, 2015 at 2:23 PM, Richard Sandiford
wrote:
> diff --git a/gcc/genmatch.c b/gcc/gen
On Tue, Nov 17, 2015 at 10:19 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Fri, Nov 13, 2015 at 2:12 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Mon, Nov 9, 2015 at 10:03 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 9 Nov 2015, Richard Sandiford w
On Tue, Nov 17, 2015 at 9:52 AM, Richard Sandiford
wrote:
> Richard Sandiford writes:
>> This patch makes genmatch match calls based on combined_fn rather
>> than built_in_function and extends the matching to internal functions.
>> It also uses fold_const_call to fold the calls to a constant, rat
On 14/11/15 00:07, Jason Merrill wrote:
And here's the final patch integrating the delayed folding branch. The general
idea is to mostly avoid folding until the end of the function, at which point we
fold everything as part of genericization. Since many warnings rely on looking
at folded trees,
While I was looking at the interaction of delayed folding with GGC, I
noticed that ggc_handle_finalizers currently runs no finalizers if
G.context_depth != 0. So any GC objects in a greater depth will still
be collected, but they won't have their finalizers run. This
specifically affects comp
Jason Merrill writes:
> On 11/17/2015 04:09 AM, Andreas Schwab wrote:
>> Can we please get trunk back to bootstrap land?
>
> Which target isn't bootstrapping for you?
PR68346, PR68361
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4
On 11/17/2015 04:09 AM, Andreas Schwab wrote:
Can we please get trunk back to bootstrap land?
Which target isn't bootstrapping for you?
Jason
Left shifts into the sign bit is a kind of overflow, and the
standard chooses to treat left shifts of negative values the
same way.
However, the -fwrapv option modifies the language to one where
integers are defined as two's complement---which also defines
entirely the behavior of shifts. Disable
Now that init priority support on Solaris is on mainline, porting libvtv
proved to be relatively easy, though it discovered a couple of quirks on
a non-gld non-x86 platform.
A considerable part of the patch lives in Solaris-specific files and
thus doesn't need approval, though some changes require
On 17/11/15 12:58, Kyrill Tkachov wrote:
Hi Ramana,
On 17/11/15 12:02, Ramana Radhakrishnan wrote:
On 06/11/15 10:46, Kyrill Tkachov wrote:
Hi all,
In this wrong-code PR the vector setmem expansion and
arm_block_set_aligned_vect in particular
use the wrong offset when calling adjust_automo
On Tue, Oct 27, 2015 at 11:33:21AM +, James Greenhalgh wrote:
> On Fri, Oct 23, 2015 at 01:22:16PM +0100, Matthew Wahab wrote:
> > The ARMv8.1 architecture extension adds two Adv.SIMD instructions,
> > sqrdmlah and sqrdmlsh. This patch adds the feature macro
> > __ARM_FEATURE_QRDMX to indicate
2015-11-17 15:26 GMT+03:00 Bernd Schmidt :
> On 11/17/2015 12:49 PM, Ilya Enkovich wrote:
>>
>> Default hook for get_mask_mode is supposed to return integer vector
>> modes. This means it should reject calar modes returned by
>> mode_for_vector. Bootstrapped and regtested on
>> x86_64-unknown-lin
On 17/11/2015 13:58, Joseph Myers wrote:
>> > GCC's -fwrapv option does not affect code generation for shifts
>> > because currently GCC does not rely on the fact that certain
>> > signed shifts trigger undefined behavior. However, the definition
>> > of signed arithmetic overflow does extend to
On 17/11/15 12:10, Bernd Schmidt wrote:
On 11/17/2015 10:08 AM, Kyrill Tkachov wrote:
Yes, I had considered that as well. It should be equivalent. I didn't
use !reg_used_between_p because I thought
it'd be more expensive than checking reg_overlap_mentioned_p since we
must iterate over a number
On Tue, 17 Nov 2015, Paolo Bonzini wrote:
> GCC's -fwrapv option does not affect code generation for shifts
> because currently GCC does not rely on the fact that certain
> signed shifts trigger undefined behavior. However, the definition
> of signed arithmetic overflow does extend to shifts; it
Hi Ramana,
On 17/11/15 12:02, Ramana Radhakrishnan wrote:
On 06/11/15 10:46, Kyrill Tkachov wrote:
Hi all,
In this wrong-code PR the vector setmem expansion and
arm_block_set_aligned_vect in particular
use the wrong offset when calling adjust_automodify_address. In the attached
testcase dur
On 11/17/2015 02:53 AM, Mike Stump wrote:
On Nov 16, 2015, at 3:12 PM, Jeff Law wrote:
So I'd tend to want them either at the end of the file with a
single #if CHECKING_P or as a separate foo-tests file.
Hum… I kinda don’t want the main files mucked up with tests. I
think I’d rather have
#
On 17/11/15 02:00, Ed Smith-Rowland wrote:
On 11/16/2015 07:28 PM, Florian Goth wrote:
Any particular pointers how I can help in improving the implementation?
Immediately: I have a good patch with xfails where #include should
inject into namespace std. That's
probably a one liner in the ma
On 05/11/15 16:22, Daniel Gutson wrote:
On Wed, Nov 4, 2015 at 3:20 AM, Jonathan Wakely wrote:
>On 4 November 2015 at 02:11, Daniel Gutson wrote:
>>Since this is a nothrow new, we thought that probably the system
>>might not be exceptions-friendly (such as certain embedded systems),
>>so we
Solaris 12 recently introduced the C++11 overloads, which
caused bootstrap to be broken on both mainline and the gcc-5 branch:
In file included from
/vol/gcc/src/hg/trunk/local/libstdc++-v3/include/precompiled/stdc++.h:41:0:
/var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/libstdc++-v3
GCC's -fwrapv option does not affect code generation for shifts
because currently GCC does not rely on the fact that certain
signed shifts trigger undefined behavior. However, the definition
of signed arithmetic overflow does extend to shifts; it is only
code generation that is limited to addition
On 11/16/2015 04:48 PM, Andre Vieira wrote:
On 16/11/15 15:34, Joern Wolfgang Rennecke wrote:
I just happened to stumble on this problem with another port.
The volatile & test solution doesn't work, though.
What does work, however, is:
__asm__ ("" : : "" (dummy));
I can confirm that Joern's
On 11/17/2015 12:49 PM, Ilya Enkovich wrote:
Default hook for get_mask_mode is supposed to return integer vector
modes. This means it should reject calar modes returned by
mode_for_vector. Bootstrapped and regtested on
x86_64-unknown-linux-gnu, regtested on aarch64-unknown-linux-gnu. OK
for tr
On Tue, Nov 17, 2015 at 12:49 PM, Ilya Enkovich wrote:
> Hi,
>
> Default hook for get_mask_mode is supposed to return integer vector modes.
> This means it should reject calar modes returned by mode_for_vector.
> Bootstrapped and regtested on x86_64-unknown-linux-gnu, regtested on
> aarch64-u
On Tue, Nov 17, 2015 at 12:01 PM, H.J. Lu wrote:
> Empty record should be returned and passed the same way in C and C++.
> This patch adds LANG_HOOKS_EMPTY_RECORD_P for C++ empty class, which
> defaults to return false. For C++, LANG_HOOKS_EMPTY_RECORD_P is defined
> to is_really_empty_class, whi
On 11/17/2015 10:08 AM, Kyrill Tkachov wrote:
Yes, I had considered that as well. It should be equivalent. I didn't
use !reg_used_between_p because I thought
it'd be more expensive than checking reg_overlap_mentioned_p since we
must iterate over a number of instructions
and call reg_overlap_menti
On 06/11/15 10:46, Kyrill Tkachov wrote:
> Hi all,
>
> In this wrong-code PR the vector setmem expansion and
> arm_block_set_aligned_vect in particular
> use the wrong offset when calling adjust_automodify_address. In the attached
> testcase during the
> initial zeroing out we get two V16QI st
Hi,
Default hook for get_mask_mode is supposed to return integer vector modes.
This means it should reject calar modes returned by mode_for_vector.
Bootstrapped and regtested on x86_64-unknown-linux-gnu, regtested on
aarch64-unknown-linux-gnu. OK for trunk?
Thanks,
Ilya
--
gcc/
2015-11-17
On Tue, 17 Nov 2015, Tom de Vries wrote:
> Hi,
>
> this no-functional-changes patch improves comments in
> pass_tree_loop_init::execute.
>
> For the discussion related to the comment for scev_initialize, see:
> - https://gcc.gnu.org/ml/gcc-patches/2013-02/msg01127.html
> - https://gcc.gnu.org/bu
On Tue, 17 Nov 2015, Richard Biener wrote:
> On Mon, 16 Nov 2015, Alan Lawrence wrote:
>
> > On 09/11/15 12:55, Richard Biener wrote:
> > >
> > > Currently BB vectorization computes all dependences inside a BB
> > > region and fails all vectorization if it cannot handle some of them.
> > >
> >
1 - 100 of 130 matches
Mail list logo
