On Tue, Jan 12, 2016 at 5:40 PM, Jim Wilson wrote:
> The info is in here
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932
> See the comments on gcc.target/arm/wmul-[123].c which no longer
> generate smulbb etc instructions, which are 16x16=32 expanding
> multiplies which are faster on some
On 01/12/2016 08:11 AM, Richard Biener wrote:
On Tue, Jan 12, 2016 at 6:10 AM, Jeff Law wrote:
On 01/11/2016 03:32 AM, Richard Biener wrote:
Yeah, reassoc is largely about canonicalization.
Plus doing it in TER is almost certainly more complex than getting it
right
in reassoc to begin with
On 01/12/2016 12:34 PM, David Malcolm wrote:
I looked at this code, and there are two near-identical blocks which
reset all these variables. You are modifying only one of them, leaving
the one inside the if { catch } thing unchanged - is this intentional?
I'm not particularly strong at Tcl, bu
tree-ssa-threadupdate.c has code to compensate for situations where
threading will produce "profile insanities". Specifically if we have
multiple jump thread paths through a common joiner to different final
targets, then we can end up increasing the counts on one path to
compensate for count
I've checked in this patch to move the section that documents spec file
formats towards the end of the invoke.texi chapter, so it isn't stuck
randomly in the middle of the discussion of unrelated command-line
options. I made no changes to the text of the section being moved here.
-Sandra
201
On 01/12/2016 04:41 PM, Yuri Rumyantsev wrote:
Here is a simple fix to exclude dg/ifcvt-5.c test from ia64 testing.
Is it OK for trunk?
Please ensure patches are attached as plain text so that reviewers don't
have to save them to be able to read them.
It looks like ia64 is making chanes in
I've applied this patch to gomp-4_0-branch which fixes an ICE when an
array declared inside a module is used inside an offloaded acc region.
Bad things happen when you try to use sym->backend_decl when it wasn't
defined.
This patch was part of an optimization that I implemented in gomp4 in an
atte
On Tue, Jan 12, 2016 at 5:10 PM, Kugan
wrote:
> Yes, making PROMOTE_MODE to work the same way as in
> promote_function_mode in arm will fix this. Can you please point me to
> the test cases that are regressing so that I can also start looking at them.
The info is in here
https://gcc.gnu.org/b
On 13/01/16 10:19, Jim Wilson wrote:
> On Mon, Jan 11, 2016 at 10:22 PM, kugan
> wrote:
>> When promote_function_mode and promote_ssa_mode changes the sign
>> differently, following is the cause for the problem in PR67714.
>
>> This is similar to PR65932 where sign change in PROMOTE_MODE cause
Hello
genattrab.c can generate if statements that have very deep bracket
nesting causing clang to produce errors (when target=arm-none-eabi) as
explained at https://gcc.gnu.org/ml/gcc/2014-05/msg00032.html
At the above link it was suggested that genattrab.c generated a switch
statement instead
This is an "extra" installment in my series to clean up the organization
of invoke.texi. When I was working on the previous installment, I
noticed that -no-canonical-prefixes would be better classified in
"Directory Options" than "Overall Options", and vice-versa for -specs=
(which seems to be
Before r229884 (aka f04790107a32653aa7adbd24967b908c8a08),
diagnostic_show_locus did not emit a newline for the line
containing the caret, whereas the new implementation in r229884
does emit a newline for the final line it emits.
PR other/69006 notes that this leads to undesired extra newlines
Hi,
Consider testcase test.c:
...
struct pgm_slist_t
{
struct pgm_slist_t *__restrict next;
};
void
fn1 (struct pgm_slist_t p1)
{
}
...
The compilation of the testcase enters into infinite recursion, due to
the more aggressive restrict support added recently.
The patch fixes this by:-
- t
On 12/16/2015 03:30 PM, Evandro Menezes wrote:
On 10/30/2015 05:24 AM, Marcus Shawcroft wrote:
On 20 October 2015 at 00:40, Evandro Menezes
wrote:
In the existing targets, it seems that it's always faster to zero up
a DF
register with "movi %d0, #0" instead of "fmov %d0, xzr".
This patch mod
On Tue, Jan 12, 2016 at 6:47 PM, Joseph Myers wrote:
> On Tue, 12 Jan 2016, Michael Meissner wrote:
>
>> On Tue, Jan 12, 2016 at 12:18:55AM +, Joseph Myers wrote:
>> > On Mon, 11 Jan 2016, Michael Meissner wrote:
>> >
>> > > I fixed the #ifdef to use __NO_FPRS__ (thanks for the heads up on tha
On Tue, 12 Jan 2016, Michael Meissner wrote:
> On Tue, Jan 12, 2016 at 12:18:55AM +, Joseph Myers wrote:
> > On Mon, 11 Jan 2016, Michael Meissner wrote:
> >
> > > I fixed the #ifdef to use __NO_FPRS__ (thanks for the heads up on that).
> > > I
> > > also believe I fixed the various formatt
On 26/12/15 00:06 -0500, Ed Smith-Rowland wrote:
I can't get CVS to commit.
Could someone do this for me?
Done.
Index: ./htdocs/svn.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving revision 1.206
diff -r1.206 svn
On 07/01/16 14:43 +0100, Rainer Orth wrote:
Ok for mainline?
OK, thanks.
On 07/01/16 11:50 -0500, Ed Smith-Rowland wrote:
This patch is a clean up of the patch submitted by Jonathan in stage 1.
I am much less ambitious here than I was in previous patches.
OK. We can be more adventurous when stage 1 re-opens, so that the
improvements you and Florian want can go into
On Mon, Jan 11, 2016 at 10:22 PM, kugan
wrote:
> When promote_function_mode and promote_ssa_mode changes the sign
> differently, following is the cause for the problem in PR67714.
> This is similar to PR65932 where sign change in PROMOTE_MODE causes problem
> for parameter. But need a different
While working on 67755, I kept getting annoyed by the formatting goofs
and typos. So, without further delay, whitespace & typo fixes.
Bootstrapped on x86_64 for completeness & installed on the trunk.
Jeff
commit 5203c463e3a1c99634cb83a6ef22200ee68d0dcd
Author: Jeff Law
Date: Tue Jan 12 15
On 12 January 2016 at 20:38, Daniel Krügler wrote:
> Ping - this is a tentative reminder for this patch proposal.
I was just about to commit it an hour ago and my machine crashed. It's done now.
On 23/12/15 22:15 +0100, Daniel Krügler wrote:
PR libstdc++/68877
* include/std/type_traits: Following N4511, reimplement __is_swappable and
__is_nothrow_swappable. Move __is_swappable to namespace std, adjust
callers. Use __is_nothrow_swappable in swap.
* include/bits/move.h: Use
On Tue, Jan 12, 2016 at 11:53 AM, Richard Henderson wrote:
> The problem in this PR is that we never got around to flushing out the vector
> support for transactions for anything but x86. My goal here is to make this
> as
> generic as possible, so that it should Just Work with existing vector su
Ping - this is a tentative reminder for this patch proposal.
2015-12-23 22:15 GMT+01:00 Daniel Krügler :
> This is a second try for a patch for libstdc++ bug 68877. See below
> for responses.
>
> 2015-12-22 22:42 GMT+01:00 Jonathan Wakely :
>> On 21/12/15 12:45 +0100, Daniel Krügler wrote:
>>>
>>>
On Tue, Jan 12, 2016 at 5:45 AM, Uros Bizjak wrote:
> On Tue, Jan 12, 2016 at 2:42 PM, Jakub Jelinek wrote:
>> On Tue, Jan 12, 2016 at 05:39:29AM -0800, H.J. Lu wrote:
>>> GCC 5 has the same issue. This patch should be backported to GCC 5
>>> with
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2016-
On 21/12/15 13:02 +, Jonathan Wakely wrote:
Two patches to add missing std:: qualification to prevent ADL
problems. Both are regressions, 68276 only on trunk, but 68995 has
been broken since 4.8.0 (but only affects people mixing TR1 with
C++11, and I was already rude about them in Bugzilla so
On Sat, 2016-01-09 at 03:07 +0100, Bernd Schmidt wrote:
> On 01/09/2016 01:51 AM, David Malcolm wrote:
> > The root cause here is that the logic to reset the list of expected
> > multiline outputs was being run from:
> >handle-multiline-outputs, called by
> > prune.exp's prune_gcc_output
>
Hi,
Backported:
2016-01-12 James Norris
* libgomp.texi: Updates for OpenACC.
from trunk.
Thanks,
Jim
Index: ChangeLog.gomp
===
--- ChangeLog.gomp (revision 232292)
+++ ChangeLog.gomp (working copy)
@@ -1,3 +1,9 @@
+201
Hi,
On Tue, Jan 12, 2016 at 02:38:15PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 12, 2016 at 02:29:06PM +0100, Martin Jambor wrote:
> > GOMP_kernel_launch_attributes should not be there (it is a
> > reminiscence from before the device-specific target arguments) and
> > should be moved just to the
On Tue, Jan 12, 2016 at 12:18:55AM +, Joseph Myers wrote:
> On Mon, 11 Jan 2016, Michael Meissner wrote:
>
> > I fixed the #ifdef to use __NO_FPRS__ (thanks for the heads up on that). I
> > also believe I fixed the various formatting issues. These two patches
> > build on
> > a big endian p
On 12/01/16 14:04, Richard Biener wrote:
On Tue, 12 Jan 2016, Tom de Vries wrote:
On 12/01/16 12:22, Richard Biener wrote:
Doesnt' the same issue apply to
unsigned int *p;
static void __attribute__((noinline, noclone))
foo (void)
{
unsigned int z;
for (z = 0; z < N; ++z)
++(*p);
On Tue, 12 Jan 2016, Uros Bizjak wrote:
> I think that following definition describes -msse -mfpmath=sse
> situation in the most elegant way. We can just declare that the
> precision is not known in this case:
>
> #define TARGET_FLT_EVAL_METHOD\
> (TARGET_MIX_SSE_I387 ?
On Tue, Jan 12, 2016 at 06:51:31PM +0100, Martin Jambor wrote:
> On Tue, Jan 12, 2016 at 06:36:21PM +0100, Martin Jambor wrote:
> > > remap_decl (old_var, id);
> > > }
> > > - phase 2 - do the full remap_decls, but during that arrange that
> > > remap_decl for non-zero id->remapping_type_de
On 01/11/2016 10:20 PM, Jason Merrill wrote:
On 12/22/2015 09:32 PM, Martin Sebor wrote:
+ if (is_attribute_p ("aligned", name)
+ || is_attribute_p ("vector_size", name))
+{
+ /* Attribute argument may be a dependent indentifier. */
+ if (tree t = args ? TREE_VALUE (args) :
On Tue, Jan 12, 2016 at 06:36:21PM +0100, Martin Jambor wrote:
> > remap_decl (old_var, id);
> > }
> > - phase 2 - do the full remap_decls, but during that arrange that
> > remap_decl for non-zero id->remapping_type_depth if (!n) just returns
> > decl
>
> ...they would not be copied he
I've checked in the first installment of my planned reorganization of
the invoke.texi chapter. Here I've deleted the section placed randomly
in the middle of option descriptions that contained only a paragraph
about the name of the gcc executable, and incorporated that information
into the cha
The patch contains the changes in the macros fixed_registers and
call_used_registers.
Earlier the register r21 is marked as fixed and also marked as 1 for call_used
registers.
On top of that r21 is not assigned to any of the temporaries in rtl insns.
This makes the usage of registers r21 in the
On 01/12/2016 09:16 AM, Richard Earnshaw (lists) wrote:
> For normal core attributes you can use .object_arch to force the .arch
> entry recorded in the attributes to a specific value, but I'm not sure
> if you can override the .fpu directive in this way. You might have to
> experiment a bit. Alt
Hi,
On Mon, Jan 11, 2016 at 05:38:47PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 11, 2016 at 09:41:31AM +0100, Richard Biener wrote:
> > Hum. Can't you check id->remapping_type_depth?
For some reason, last week I reached the conclusion that no. But I
must have done something wrong because I hav
On 12/01/16 17:16, Richard Earnshaw (lists) wrote:
> On 12/01/16 16:53, Richard Henderson wrote:
>> The problem in this PR is that we never got around to flushing out the vector
>> support for transactions for anything but x86. My goal here is to make this
>> as
>> generic as possible, so that it
On 12/01/16 16:53, Richard Henderson wrote:
> The problem in this PR is that we never got around to flushing out the vector
> support for transactions for anything but x86. My goal here is to make this
> as
> generic as possible, so that it should Just Work with existing vector support
> in the b
Hi!
On 01/11/2016 11:35 AM, Jakub Jelinek wrote:
On Tue, Jan 05, 2016 at 09:47:59AM -0600, James Norris wrote:
I've updated the original patch after some very helpful
comments from Sandra (thank you, thank you).
I'd prefer if OpenMP
* Enabling OpenMP::How to enable OpenMP for your
Hello,
Although the following patch does not fix a regression, I believe it
fixes a bug visible from a debugger, so I think it’s a valid candidate
at this stage.
This change tracks from which abstract lexical block concrete ones come
from in DWARF so that debuggers can inherit the former fro
The problem in this PR is that we never got around to flushing out the vector
support for transactions for anything but x86. My goal here is to make this as
generic as possible, so that it should Just Work with existing vector support
in the backend.
In addition, if I encounter other unexpected r
> On 12 Jan 2016, at 17:14, Bernd Schmidt wrote:
>
> I think you can do without the outer braces. Ok with those removed.
Great! Thanks for the review and comments.
With Kind Regards,
Olivier
OK.
Jason
On 12/01/16 15:31, Renlin Li wrote:
> Hi all,
>
> Here I backport r227129 to branch 4.9 to fix exactly the same issue
> reported in PR69082.
> It's been already committed on trunk and backportted to branch 5.
>
>
> I have quoted the original message for the explanation.
> The patch applies to br
diff --git a/ChangeLog b/ChangeLog
index 1c5330a..4821c1f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2016-01-12 H.J. Lu
+
+ Sync with binutils-gdb:
+ 2015-10-21 Nick Clifton
+
+ PR gas/19109
+ * configure.ac: Note the 'none' is an acceptable argument to
+
On 01/12/2016 05:11 PM, Olivier Hainque wrote:
+ /* Decide if undefined variable references are allowed in specs. */
+ {
+/* --version and --help alone or together are safe. Note that -v would
+ make them unsafe, as they'd then be run for subprocesses as well, the
+ location
Hello Bernd,
Thanks for your feedback on this :-)
> On 11 Jan 2016, at 17:09, Bernd Schmidt wrote:
>
> On 01/08/2016 02:23 PM, Olivier Hainque wrote:
>> + /* Undefined variable references in specs are harmless if
>> + we're running for --help or --version alone, or together. */
>> + spec
On Jan 11, 2016, at 11:20 PM, Kaushik M Phatak wrote:
> Kindly review the updated patch and let me know if it is OK.
My review comment is still outstanding.
Hi All,
Here is a simple fix to exclude dg/ifcvt-5.c test from ia64 testing.
Is it OK for trunk?
testsuite/ChangeLog:
2016-01-12 Yuri Rumyantsev
PR rtl-optimization/68920
gcc/testsuite/ChangeLog
* gcc.dg/ifcvt-5.c: Exclude it from ia64 testing.
2016-01-12 17:01 GMT+03:00 Andreas Schwab :
> Y
Hi all,
Here I backport r227129 to branch 4.9 to fix exactly the same issue reported in
PR69082.
It's been already committed on trunk and backportted to branch 5.
I have quoted the original message for the explanation.
The patch applies to branch 4.9 without any modifications.
Test case is not
Bernd,
On 01/11/2016 11:23 AM, Bernd Schmidt wrote:
On 01/05/2016 04:47 PM, James Norris wrote:
I've updated the original patch after some very helpful
comments from Sandra (thank you, thank you).
OK to commit to trunk?
I'm probably not fully qualified to review the contents either, but few
On Tue, Jan 12, 2016 at 6:10 AM, Jeff Law wrote:
> On 01/11/2016 03:32 AM, Richard Biener wrote:
>
>>
>> Yeah, reassoc is largely about canonicalization.
>>
>>> Plus doing it in TER is almost certainly more complex than getting it
>>> right
>>> in reassoc to begin with.
>>
>>
>> I guess canonicali
On Mon, Jan 11, 2016 at 11:54 PM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> this hardly counts as a bug fix, but going through open bugs I saw PR54809,
> and
> realized we don't actually need this attribute any more, so we might as well
> just remove it.
>
> bootstrapped + regtested on x86_64-
This removes code and data members that have not been used for quite a
while now. The user-visible benefit is 8MB less space overhead if
libitm is used.
Tested on x86_64-linux and committed as r232275.
2016-01-12 Torvald Riegel
* libitm_i.h (gtm_mask_stack): Remove.
* begine
This fixes PR 69222 and PR 69005 for gcc-5-branch, by ensuring we
don't try to determine the result of invoking the function(Functor)
constructor argument when the type is incomplete (because that might
require instantiating the constructor again, which recurses).
Jason fixed 69005 on trunk by ma
Hi
The code below it looks like we always call “vect_permute_load_chain” to load
non-unit strides of size powers of 2.
(---snip---)
/* If reassociation width for vector type is 2 or greater target machine can
execute 2 or more vector instructions in parallel. Otherwise try to
get ch
On Tue, Jan 12, 2016 at 02:46:52PM +0100, Martin Jambor wrote:
> diff --git a/libgomp/task.c b/libgomp/task.c
> index ab5df51..828c1fb 100644
> --- a/libgomp/task.c
> +++ b/libgomp/task.c
> @@ -584,8 +592,34 @@ GOMP_PLUGIN_target_task_completion (void *data)
>gomp_mutex_unlock (&team->task_
2016-01-11 20:13 GMT+03:00 Jakub Jelinek :
> Hi!
>
> Based on discussions on IRC, I'm submitting following fix for a regression
> on aarch64 - partial reversion (the case where VCE works too, just I thought
> using NOP_EXPR would be nicer) and change in the assert - op better be
> some integral val
The following fixes PR69077.
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-01-12 Richard Biener
lto/
PR lto/69077
* lto-symtab.c (lto_symtab_prevailing_virtual_decl): Properly
merge TREE_ADDRESSABLE and DECL_POSSIBLY_INLINED
On Tue, Jan 12, 2016 at 09:09:38AM -0500, Jason Merrill wrote:
> In that case, we need to return (!flag_permissive || ctx->quiet).
Thanks. So is this one ok once it passes testing?
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2016-01-12 Marek Polacek
PR c++/68979
*
This patch fixes an ICE encountered with the Houston's testsuite when kernel
optimizations are enabled.
The reduction is implemented via a cmp&swap loop, but later than the omp code
usually does that lowering. At the point it happens for kernels, loops must
have simple latches, which this pa
On 01/12/2016 09:05 AM, Marek Polacek wrote:
On Tue, Jan 12, 2016 at 08:27:47AM -0500, Jason Merrill wrote:
Changing the diagnostic is OK, but cxx_eval_check_shift_p should return true
regardless of flag_permissive, so that SFINAE results follow the standard.
There's a complication, because if
On Tue, Jan 12, 2016 at 08:27:47AM -0500, Jason Merrill wrote:
> Changing the diagnostic is OK, but cxx_eval_check_shift_p should return true
> regardless of flag_permissive, so that SFINAE results follow the standard.
There's a complication, because if I keep returning true, we'll give a
compile-
Yuri Rumyantsev writes:
> Is it OK for you if we exclude dg/ifcvt-5.c from ia64 testing
Sure, go ahead.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Hi,
On Fri, Dec 11, 2015 at 07:05:29PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 10, 2015 at 06:52:23PM +0100, Martin Jambor wrote:
> > > > --- a/libgomp/task.c
> > > > +++ b/libgomp/task.c
> > > > @@ -581,6 +581,7 @@ GOMP_PLUGIN_target_task_completion (void *data)
> > > >gomp_mutex_unlock
On Tue, Jan 12, 2016 at 2:42 PM, Jakub Jelinek wrote:
> On Tue, Jan 12, 2016 at 05:39:29AM -0800, H.J. Lu wrote:
>> GCC 5 has the same issue. This patch should be backported to GCC 5
>> with
>>
>> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00528.html
>>
>> which supersedes:
>>
>> https://gcc.g
On Tue, Jan 12, 2016 at 05:39:29AM -0800, H.J. Lu wrote:
> GCC 5 has the same issue. This patch should be backported to GCC 5
> with
>
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00528.html
>
> which supersedes:
>
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=231269
>
> OK to ba
On Tue, Jan 12, 2016 at 5:12 AM, Kirill Yukhin wrote:
> Hello Jakub
> On 08 Jan 21:20, Jakub Jelinek wrote:
>> Hi!
>>
>> This patch fixes
>> FAIL: gcc.target/i386/avx512vl-vmovapd-1.c scan-assembler-times vmovapd[
>> t]+[^{\\n]*%xmm[0-9]+[^\\n]*){%k[1-7]}(?:\\n|[ t]+#) 1
>> FAIL: gcc.
On Tue, Jan 12, 2016 at 02:29:06PM +0100, Martin Jambor wrote:
> GOMP_kernel_launch_attributes should not be there (it is a
> reminiscence from before the device-specific target arguments) and
> should be moved just to the HSA plugin. I'll prepare a patch today.
>
> While we do not have to share
OK.
Jason
Changing the diagnostic is OK, but cxx_eval_check_shift_p should return
true regardless of flag_permissive, so that SFINAE results follow the
standard.
Jason
Define STDINT_LONG32 to 0, add SIZE_TYPE, PTRDIFF_TYPE and WCHAR_TYPE
for IAMCU to make integer types compatible with i386 Linux.
Checked into trunk.
H.J.
PR target/68456
PR target/69226
* config/i386/iamcu.h (SIZE_TYPE): New macro.
(PTRDIFF_TYPE): Likewise.
Hello Jakub
On 08 Jan 21:20, Jakub Jelinek wrote:
> Hi!
>
> This patch fixes
> FAIL: gcc.target/i386/avx512vl-vmovapd-1.c scan-assembler-times vmovapd[
> t]+[^{\\n]*%xmm[0-9]+[^\\n]*){%k[1-7]}(?:\\n|[ t]+#) 1
> FAIL: gcc.target/i386/avx512vl-vmovapd-1.c scan-assembler-times vmovapd[
Andreas,
Is it OK for you if we exclude dg/ifcvt-5.c from ia64 testing since
predication must be used instead of conditional move's.
2016-01-12 13:07 GMT+03:00 Andreas Schwab :
> gcc.dg/ifcvt-5.c fails on ia64:
>
> From ifcvt-5.c.223r.ce1:
>
> == Pass 2 ==
>
>
> == no more
On Tue, Jan 12, 2016 at 02:02:16PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 12, 2016 at 01:52:01PM +0100, Marek Polacek wrote:
> > --- gcc/testsuite/g++.dg/warn/permissive-1.C
> > +++ gcc/testsuite/g++.dg/warn/permissive-1.C
> > @@ -0,0 +1,8 @@
> > +// PR c++/68979
> > +// { dg-do compile }
> > +/
On Tue, Jan 12, 2016 at 1:43 PM, Jakub Jelinek wrote:
> On Tue, Jan 12, 2016 at 01:32:05PM +0100, Uros Bizjak wrote:
>> Using this patch, SSE math won't be emitted for a simple testcase
>> using " -O2 -msse -m32 -std=c99 -mfpmath=sse" compile flags:
>>
>> float test (float a, float b)
>> {
>> re
On Tue, Jan 12, 2016 at 04:00:11PM +0300, Alexander Monakov wrote:
> Hello, Martin, Jakub, community,
>
> This part of the patch:
>
> On Mon, 7 Dec 2015, Martin Jambor wrote:
> > include/
> > * gomp-constants.h (GOMP_DEVICE_HSA): New macro.
> [snip]
> > (GOMP_kernel_launch_attributes): Ne
On Tue, 12 Jan 2016, Tom de Vries wrote:
> On 12/01/16 12:22, Richard Biener wrote:
> > Doesnt' the same issue apply to
> >
> > > >unsigned int *p;
> > > >
> > > >static void __attribute__((noinline, noclone))
> > > >foo (void)
> > > >{
> > > > unsigned int z;
> > > >
> > > > for (z = 0; z <
On Tue, Jan 12, 2016 at 01:52:01PM +0100, Marek Polacek wrote:
> --- gcc/testsuite/g++.dg/warn/permissive-1.C
> +++ gcc/testsuite/g++.dg/warn/permissive-1.C
> @@ -0,0 +1,8 @@
> +// PR c++/68979
> +// { dg-do compile }
> +// { dg-options "-fpermissive -Wno-shift-overflow -Wno-shift-count-overflow
>
Hello, Martin, Jakub, community,
This part of the patch:
On Mon, 7 Dec 2015, Martin Jambor wrote:
> include/
> * gomp-constants.h (GOMP_DEVICE_HSA): New macro.
[snip]
> (GOMP_kernel_launch_attributes): New type.
> (GOMP_hsa_kernel_dispatch): New type.
is going to break build of
Seems that people find compile-time error on the following testcase overly
pedantic. I.e. that "enum A { X = -1 << 1 };" should compile, at least with
-fpermissive. So I've changed the error_at into permerror and the return value
of cxx_eval_check_shift_p now depends on flag_permissive. Luckily,
On 12/01/16 12:22, Richard Biener wrote:
Doesnt' the same issue apply to
>unsigned int *p;
>
>static void __attribute__((noinline, noclone))
>foo (void)
>{
> unsigned int z;
>
> for (z = 0; z < N; ++z)
> ++(*p);
>}
thus when we have a MEM_REF[p_1]? SCEV will not analyze
its evolution
On Tue, Jan 12, 2016 at 01:32:05PM +0100, Uros Bizjak wrote:
> Using this patch, SSE math won't be emitted for a simple testcase
> using " -O2 -msse -m32 -std=c99 -mfpmath=sse" compile flags:
>
> float test (float a, float b)
> {
> return a + b;
> }
>
> since we start with:
>
> test (float a,
On Tue, Jan 12, 2016 at 12:30:20PM +, James Greenhalgh wrote:
> > 2015-04-08 Jakub Jelinek
> >
> > PR target/65689
> > * genpreds.c (struct constraint_data): Add maybe_allows_reg and
> > maybe_allows_mem bitfields.
> > (maybe_allows_none_start, maybe_allows_none_end,
> >
On Tue, Jan 12, 2016 at 1:12 PM, Uros Bizjak wrote:
> On Tue, Jan 12, 2016 at 12:18 PM, Jakub Jelinek wrote:
>> On Tue, Jan 12, 2016 at 12:10:20PM +0100, Uros Bizjak wrote:
>>> On Tue, Jan 12, 2016 at 1:15 AM, Joseph Myers
>>> wrote:
>>> > On Mon, 11 Jan 2016, H.J. Lu wrote:
>>> >
>>> >> Here i
On Wed, Apr 08, 2015 at 11:00:59PM +0200, Jakub Jelinek wrote:
> Hi!
>
> Right now, stmt.c on constraints not hardcoded in it, and not
> define_{register,address,memory}_constraint just assumes the
> constraint might allow both reg and mem. Unfortunately, on some
> constraints which clearly can't
On 01/12/2016 11:17 AM, Jakub Jelinek wrote:
PR target/69175
* ifcvt.c (cond_exec_process_if_block): When removing the last
insn from then_bb, remove also any possible barriers that follow it.
* g++.dg/opt/pr69175.C: New test.
Ok.
Bernd
Hi Kaushik,
+/* Structure for G13 MDUC registers. */
+struct mduc_reg_type
+{
+ unsigned int address;
+ enum machine_mode mode;
+ bool is_volatile;
+};
+
+struct mduc_reg_type mduc_regs[NUM_OF_MDUC_REGS] =
+ {{0xf00e8, QImode, true},
+ {0x0, HImode, true},
+ {0x2, HImode, true}
On Tue, Jan 12, 2016 at 12:18 PM, Jakub Jelinek wrote:
> On Tue, Jan 12, 2016 at 12:10:20PM +0100, Uros Bizjak wrote:
>> On Tue, Jan 12, 2016 at 1:15 AM, Joseph Myers
>> wrote:
>> > On Mon, 11 Jan 2016, H.J. Lu wrote:
>> >
>> >> Here is the updated patch. Joseph, is this OK?
>> >
>> > I have no
On 12/01/16 12:08, Jakub Jelinek wrote:
On Tue, Jan 12, 2016 at 12:04:22PM +, Kyrill Tkachov wrote:
2016-01-12 Kugan Vivekanandarajah
* expr.c (expand_expr_real_1): Fix promoted sign in SUBREG_PRMOTED
I'd like to just point at the ChangeLog typo - PRMOTED instead of PROMOTED.
Sin
On Tue, Jan 12, 2016 at 12:04:22PM +, Kyrill Tkachov wrote:
> >2016-01-12 Kugan Vivekanandarajah
> >
> >* expr.c (expand_expr_real_1): Fix promoted sign in SUBREG_PRMOTED
I'd like to just point at the ChangeLog typo - PRMOTED instead of PROMOTED.
Jakub
Hi Kugan,
On 12/01/16 06:22, kugan wrote:
When promote_function_mode and promote_ssa_mode changes the sign differently,
following is the cause for the problem in PR67714.
_8 = fn1D.5055 ();
f_13 = _8;
function returns -15 and in _8 it is sign extended. In the second statement, we say tha
This patch addresses PR target/69228. Expanding non-mask builtins
for prefetch gather/scatter insns results in using default mask.
Although Intel ISA Extensions Programming Reference statement about
EVEX.aaa field in prefetch gather/scatter insns encoding is a bit
opaque, no default mask is allowed
On Tue, Jan 12, 2016 at 05:53:21AM +, Kumar, Venkataramanan wrote:
> Hi James,
>
> > -Original Message-
> > From: James Greenhalgh [mailto:james.greenha...@arm.com]
> > Sent: Monday, January 11, 2016 5:24 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: n...@arm.com; marcus.shawcr...@arm.com
On 11/01/16 17:46, Richard Biener wrote:
On January 11, 2016 5:36:33 PM GMT+01:00, Bernd Schmidt
wrote:
On 01/11/2016 05:33 PM, Matthew Wahab wrote:
The case I'm trying to fix has (short)abs((int)short_var). I'd
thought
that if
abs(short_var) was undefined because the result couldn't be
r
On Jan 12, 2016, at 12:48 AM, Thomas Preud'homme
wrote:
> This patch solve this problem by replacing the static pass number in the
> output by a star, allowing for a stable output while retaining easy copy/
> pasting in shell.
> Is this ok for stage3?
Ok.
1 - 100 of 122 matches
Mail list logo
