On 11/15/2016 05:42 AM, Richard Sandiford wrote:
LOAD_EXTEND_OP only applies to scalar integer modes that are narrower
than a word. However, callers weren't consistent about which of these
checks they made beforehand, and also weren't consistent about whether
"smaller" was based on (bit)size or
On 11/11/16 19:38, Jakub Jelinek wrote:
On Fri, Nov 11, 2016 at 06:21:48PM +, Jiong Wang wrote:
This patch introduces three AARCH64 private DWARF operations in vendor extension
space.
DW_OP_AARCH64_pauth 0xea
===
Takes one unsigned LEB 128 Pointer Authentication Description. Bits [3:0]
On 11/14/2016 11:22 PM, Thomas Koenig wrote:
Hi Jerry,
With these changes, OK for trunk?
Just going over this with a fine comb...
One thing just struck me: The loop variables should be index_type, so
const index_type m = xcount, n = ycount, k = count;
[...]
index_type a_dim1,
Richard Biener writes:
> On Tue, Nov 15, 2016 at 1:44 PM, Richard Sandiford
> wrote:
>> We previously stored the number of loop iterations rather
>> than the number of latch iterations.
>
> So ->nb_iterations was unused without SVE?
OK.
On Tue, Nov 15, 2016 at 9:39 AM, Jakub Jelinek wrote:
> On Thu, Nov 10, 2016 at 10:50:27PM +0100, Jakub Jelinek wrote:
>> > + self(); // error: use of 'decltype(auto)
>> > fix_type::operator()() [with Functor =
>> > main()::]' before deduction of
On 11/15/2016 03:55 AM, Matthias Klose wrote:
This patch removes some references to gcj in the top level and config
directories and in the gcc documentation. The change to the config directory
requires regenerating aclocal.m4 and configure in each sub directory.
Ok for the trunk?
Matthias
> Is there a reason that instruction should be uppercase?
>
> This otherwise looks fine to me.
>
Committed r242428.
Thank you for your review,
Claudiu
On 11/15/2016 07:03 AM, Jakub Jelinek wrote:
Hi!
On Mon, Nov 14, 2016 at 10:58:51AM +0100, Jakub Jelinek wrote:
Working virtually out of Samoa.
The following patch is an attempt to handle -fsanitize=undefined
for vectors. We already diagnose out of bounds accesses for vector
subscripts, this
PING! Once the new options are in, we need also to update the tests.
Andrew, please can you check it,
Claudiu
> -Original Message-
> From: Claudiu Zissulescu
> Sent: Monday, May 30, 2016 2:33 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Claudiu Zissulescu ;
On Mon, Nov 14, 2016 at 3:39 PM, Mark Wielaard wrote:
> When construction a :? or fold expression that requires a third
> expression only the first and second were explicitly checked to
> not be NULL. Since the third expression is also required in these
> constructs it needs to be
On Tue, Nov 15, 2016 at 1:57 PM, Richard Sandiford
wrote:
> vect_transform_loop has to reduce three iteration counts by
> the vectorisation factor: nb_iterations_upper_bound,
> nb_iterations_likely_upper_bound and nb_iterations_estimate.
> All three are latch execution
On Tue, Nov 15, 2016 at 1:19 PM, Eric Botcazou wrote:
>> Yes, I know -fno-strict-aliasing is globally set, but will all
>> -fstrict-aliasing optimization attributes on functions be "overwritten"?
>> That is, are you sure that when optimizing a function originally compiled
Hi!
I've fixed this PR already in r240198 as part of the PR77482
fix, thus I've just added the testcase for it. Tested on x86_64-linux,
committed to trunk as obvious.
2016-11-15 Jakub Jelinek
PR c++/71988
* g++.dg/cpp0x/constexpr-71988.C: New test.
---
On Tue, Nov 15, 2016 at 1:44 PM, Richard Sandiford
wrote:
> We previously stored the number of loop iterations rather
> than the number of latch iterations.
So ->nb_iterations was unused without SVE? Otherwise can you please
add a testcase?
Thanks,
Richard.
> Tested
> This looks fine. Thanks for all your effort revising this patch.
>
> Andrew
>
Committed r242425.
Thank you for your review,
Claudiu
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Toma Tabacu
> Sent: 15 November 2016 14:00
> To: gcc-patches@gcc.gnu.org
> Cc: Matthew Fortune; catherine_mo...@mentor.com
> Subject: [PATCH,testsuite] MIPS: Downgrade from R6 to R5 to prevent
> redundant
Appearantly for some unknown reason we refuse to inline anything into
functions calling cilk_spawn. That breaks fortified headers and
all other always-inline function calls (intrinsics come to my mind as
well).
Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?
Thanks,
On 11/15/2016 05:55 AM, Andrew Senkevich wrote:
2016-11-11 14:16 GMT+03:00 Uros Bizjak :
--- a/gcc/genmodes.c
+++ b/gcc/genmodes.c
--- a/gcc/init-regs.c
+++ b/gcc/init-regs.c
--- a/gcc/machmode.h
+++ b/gcc/machmode.h
These are middle-end changes, you will need a separate
On Tue, Nov 15, 2016 at 4:32 AM, Jakub Jelinek wrote:
> So, is there a way to treat references the similarly? I.e. only "fold"
> reference vars to what they refer (DECL_INITIAL) in constexpr.c evaluation,
> or gimplification where a langhook or omp_notice_variable etc. has the
On 15/11/16 14:36 +, Jonathan Wakely wrote:
There are 138 test files that says "a moved_to of the GNU General
Public License", presumably from a find& replace that then got copied
to new tests.
Fixed as obvious, as shown by this patch (the full patch is too big
for the mailing list).
Hi All,
Here is patch for non-masked epilogue vectoriziation.
Bootstrap and regression testing did not show any new failures.
Is it OK for trunk?
Thanks.
Changelog:
2016-11-15 Yuri Rumyantsev
* params.def (PARAM_VECT_EPILOGUES_NOMASK): New.
* tree-if-conv.c
On Thu, Nov 10, 2016 at 10:50:27PM +0100, Jakub Jelinek wrote:
> > + self(); // error: use of 'decltype(auto)
> > fix_type::operator()() [with Functor = main()::]'
> > before deduction of 'auto'
>
> Wouldn't it be clearer to turn that // error: line into
> // { dg-bogus
There are 138 test files that says "a moved_to of the GNU General
Public License", presumably from a find& replace that then got copied
to new tests.
Fixed as obvious, as shown by this patch (the full patch is too big
for the mailing list).
commit 4ae2edc3c515f76e02712f744a0e3081de94be18
This is another issue resolution for C++17 features that was approved
at the recent meeting. I think this resolution is wrong too, but in
this case the fix is obvious so I've gone ahead and done it.
* doc/xml/manual/intro.xml: Document LWG 2742 status.
* doc/html/*: Regenerate.
This implements the resolution to LWG 2748 which was approved the
other day at the WG21 meeting. I think the resolution is wrong,
because as the test shows it means that optional is
swappable in some cases. I've raised that with the LWG and will
probably create a new issue for it, but in the
Hi!
This patch adds 3 new tests. Tested on x86_64-linux, ok for trunk?
2016-11-15 Jakub Jelinek
* g++.dg/cpp1z/decomp13.C: New test.
* g++.dg/cpp1z/decomp14.C: New test.
* g++.dg/cpp1z/decomp15.C: New test.
---
Hi!
On the following testcase we ICE, because the underlying artificial decls
have NULL DECL_NAME (intentional), thus mangling is not able to figure out
what to do. This patch attempts to follow the
http://sourcerytools.com/pipermail/cxx-abi-dev/2016-August/002951.html
proposal (and for error
On Tue, Nov 15, 2016 at 6:48 AM, Segher Boessenkool
wrote:
> If we use ABI_V4 and we have a big stack frame, we end the epilogue
> with a "mr 1,11" (or similar) instruction. This instruction however
> has no dependencies on the earlier restores from stack (done via
Hi!
On Mon, Nov 14, 2016 at 10:58:51AM +0100, Jakub Jelinek wrote:
> Working virtually out of Samoa.
>
> The following patch is an attempt to handle -fsanitize=undefined
> for vectors. We already diagnose out of bounds accesses for vector
> subscripts, this patch adds expansion for vector
Hi,
The branch-cost-1.c test uses the isa>=4 option to ensure the existence of the
MOVN/MOVZ instructions. This, however, does not take into account R6 targets,
which are accepted by the isa>=4 option but do not support MOVN/MOVZ.
This particular test does not fail on R6, because it is checking
Hi!
This test fails on i686-linux (and perhaps on powerpc* too) due to -Wpsabi
warnings. Fixed thusly, committed as obvious to trunk.
2016-11-15 Jakub Jelinek
PR middle-end/78295
* gcc.dg/uninit-pr78295.c: Add -Wno-psabi to dg-options.
---
On Tue, Nov 15, 2016 at 12:33:06PM +, Richard Sandiford wrote:
> The transformations made by make_compound_operation apply
> only to scalar integer modes. The fix for PR70944 had enforced
> that by returning early for vector modes at the top of the
> function. However, the function is
vect_transform_loop has to reduce three iteration counts by
the vectorisation factor: nb_iterations_upper_bound,
nb_iterations_likely_upper_bound and nb_iterations_estimate.
All three are latch execution counts rather than loop body
execution counts. The calculations were taking that into
account
2016-11-11 14:16 GMT+03:00 Uros Bizjak :
> --- a/gcc/genmodes.c
> +++ b/gcc/genmodes.c
> --- a/gcc/init-regs.c
> +++ b/gcc/init-regs.c
> --- a/gcc/machmode.h
> +++ b/gcc/machmode.h
>
> These are middle-end changes, you will need a separate review for these.
Who could review
We previously stored the number of loop iterations rather
than the number of latch iterations.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
Thanks,
Richard
[ This patch is part of the SVE series posted here:
https://gcc.gnu.org/ml/gcc/2016-11/msg00030.html ]
gcc/
LOAD_EXTEND_OP only applies to scalar integer modes that are narrower
than a word. However, callers weren't consistent about which of these
checks they made beforehand, and also weren't consistent about whether
"smaller" was based on (bit)size or precision (IMO it's the latter).
This patch adds a
The transformations made by make_compound_operation apply
only to scalar integer modes. The fix for PR70944 had enforced
that by returning early for vector modes at the top of the
function. However, the function is supposed to be recursive,
so we should continue to look at integer suboperands
Hi Andrew,
Thanks for the patch and looking into this.
On Mon, Nov 14, 2016 at 04:57:58PM +, Andrew Stubbs wrote:
> The testcase powerpc/fusion3.c causes an ICE when compiled with
> -msoft-float.
> Basically, the problem is that the peephole optimization tries to create
> a Power9 Fusion
Bernd Edlinger writes:
> Hi!
>
> The genattrtab build-tool uses way too much memory in general.
> I think there is no other build step that uses more memory.
>
> On the currently trunk it takes around 700MB to build the
> ARM latency tab files. I debugged that
> Yes, I know -fno-strict-aliasing is globally set, but will all
> -fstrict-aliasing optimization attributes on functions be "overwritten"?
> That is, are you sure that when optimizing a function originally compiled
> with -fstrict-aliasing that -fno-strict-aliasing is in effect?
Do you mean
On 12/11/16 12:11 -0800, Tim Shen wrote:
At Issaquah we decided to remove the supports above.
OK with a suitable ChangeLog, thanks.
Hi Richard,
On Tue, Nov 15, 2016 at 10:49:26AM +, Richard Sandiford wrote:
> simplify_shift_const_1 handles both shifts of scalars by scalars
> and shifts of vectors by scalars. For vectors this means that
> each element is shifted by the same amount.
>
> However:
>
> (a) the two cases
On Tue, Nov 15, 2016 at 10:47 AM, Eric Botcazou wrote:
>> Can you verify that a TU compiled with -fstrict-aliasing will link as
>> if -fno-strict-aliasing if -fno-strict-aliasing is specified at link time?
>
> Yes, it does:
>
> eric@polaris:~/build/gcc/native>
On 14/11/16 14:32 +0100, Christophe Lyon wrote:
On 20 October 2016 at 19:40, Jonathan Wakely wrote:
On 20/10/16 10:33 -0700, Mike Stump wrote:
On Oct 20, 2016, at 9:34 AM, Jonathan Wakely wrote:
On 20/10/16 09:26 -0700, Mike Stump wrote:
On Oct
If we use ABI_V4 and we have a big stack frame, we end the epilogue
with a "mr 1,11" (or similar) instruction. This instruction however
has no dependencies on the earlier restores from stack (done via r11),
so sched2 can end up reordering the insns, which is bad because we
have no red zone so
Hi!
On Mon, Nov 14, 2016 at 04:43:35PM -0700, Kelvin Nilsen wrote:
> * config/rs6000/altivec.md (UNSPEC_CMPRB): New unspec value.
> (UNSPEC_CMPRB2): New unspec value.
I wonder if you really need both? The number of arguments will tell
which is which, anyway?
> (cmprb_p): New
Seen while cleaning up the GCJ references. The last section of the gcj install
docs doesn't belong there, but into the cross install section. The change is
not necessary on the trunk once the gcj docs are removed. Fixed this on the 5
and 6 branches by moving the section.
Committed as obvious.
...it should have been checking the size instead.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. Committed as obvious.
Thanks,
Richard
[ This patch is part of the SVE series posted here:
https://gcc.gnu.org/ml/gcc/2016-11/msg00030.html ]
gcc/
2016-11-15 Richard Sandiford
Hi!
The genattrtab build-tool uses way too much memory in general.
I think there is no other build step that uses more memory.
On the currently trunk it takes around 700MB to build the
ARM latency tab files. I debugged that yesterday
and found that this can be reduced to 8MB (!). Yes, really.
This patch removes some references to gcj in the top level and config
directories and in the gcc documentation. The change to the config directory
requires regenerating aclocal.m4 and configure in each sub directory.
Ok for the trunk?
Matthias
2016-11-14 Matthias Klose
[ This patch is part of the SVE series posted here:
https://gcc.gnu.org/ml/gcc/2016-11/msg00030.html ]
simplify_shift_const_1 handles both shifts of scalars by scalars
and shifts of vectors by scalars. For vectors this means that
each element is shifted by the same amount.
However:
(a) the
So far all target implementations of the separate shrink-wrapping hooks
use the DF LIVE info to figure out around which basic blocks the non-
volatile registers need to be saved. This is done by looking at the
IN+GEN+KILL sets of the basic blocks. However, that doesn't work for
registers that DF
> 2016-11-15 Richard Sandiford
> Alan Hayward
> David Sherwood
>
> * rtlanal.c (num_sign_bit_copies1): Calculate bitwidth after
> handling VOIDmode.
OK, thanks, but please change
[ This patch is part of the SVE series posted here:
https://gcc.gnu.org/ml/gcc/2016-11/msg00030.html ]
The old assignment to bitwidth was before we handled VOIDmode with:
if (mode == VOIDmode)
mode = GET_MODE (x);
so when VOIDmode was specified we would always use:
if (bitwidth <
On Mon, Nov 14, 2016 at 7:28 PM, Andrew Senkevich
wrote:
> 2016-11-11 14:16 GMT+03:00 Uros Bizjak :
>> The x86 part of the patch is OK with the above changes and additional
>> target attribute test for flags2 ISA features..
>
> Fixed according your
> Can you verify that a TU compiled with -fstrict-aliasing will link as
> if -fno-strict-aliasing if -fno-strict-aliasing is specified at link time?
Yes, it does:
eric@polaris:~/build/gcc/native> ~/install/gcc/bin/gcc -c t.c -O2 -flto
eric@polaris:~/build/gcc/native> ~/install/gcc/bin/gcc -o t
On Fri, Nov 11, 2016 at 02:17:58PM -0600, Segher Boessenkool wrote:
> On Fri, Nov 11, 2016 at 09:58:21AM +0100, Dominik Vogt wrote:
> > > You say it needs more testing -- what testing?
> >
> > Regression testing on AIX (David has done this in reply to the
> > original message), possibly also on
Please find attached the revised patch as requested.
Ok to apply?
Claudiu
gcc/
2016-05-09 Claudiu Zissulescu
* config/arc/arc-arch.h: New file.
* config/arc/arc-arches.def: Likewise.
* config/arc/arc-cpus.def: Likewise.
*
On Mon, Nov 14, 2016 at 11:53:55PM -0500, Jason Merrill wrote:
> The standard says that references that refer to a constant address can
> be used in a constant-expression, but we haven't allowed that. This
> patch implements it, but without the parser.c hunk it broke
> libgomp.c++/target-14.C.
On 14 November 2016 at 22:51, Ville Voutilainen
wrote:
> On 14 November 2016 at 22:49, Ville Voutilainen
> wrote:
>> I needed to do some minor tweaks in
>> testsuite/20_util/in_place/requirements.cc. I committed the attached
>> after
> Thanks for the patch. I'm a bit concerned about the interaction this
> will have with microMIPS which can (albeit not implemented today) use
> 2-byte alignment on function entry points.
>
> Is the solution for other targets to mandate 4-byte alignment when
> using function descriptors?
Yes,
On 14 November 2016 at 21:31, Ramana Radhakrishnan
wrote:
>
> On Mon, 14 Nov 2016 at 19:59, Christophe Lyon
> wrote:
>>
>> On 14 November 2016 at 18:54, Mike Stump wrote:
>> > On Oct 21, 2016, at 1:00 AM, Christophe
On Mon, Nov 14, 2016 at 11:13 PM, Jerry DeLisle wrote:
> On 11/13/2016 11:03 PM, Thomas Koenig wrote:
>>
>> Hi Jerry,
>>
>> I think this
>>
>> + /* Parameter adjustments */
>> + c_dim1 = m;
>> + c_offset = 1 + c_dim1;
>>
>> should be
>>
>> + /* Parameter
On Mon, Nov 14, 2016 at 11:56 PM, kugan
wrote:
> Hi Richard,
>
> On 08/11/16 23:45, Richard Biener wrote:
>>
>> On Tue, Nov 8, 2016 at 3:32 AM, kugan
>> wrote:
>>>
>>> Hi,
>>>
>>> In tree-ssa-coalesce, register_ssa_partition )
101 - 164 of 164 matches
Mail list logo