On 02/16/2016 02:02 PM, Jakub Jelinek wrote:
On Tue, Feb 16, 2016 at 02:00:45PM -0500, Jason Merrill wrote:
On 02/10/2016 10:31 AM, Jason Merrill wrote:
On 02/09/2016 03:29 PM, Rainer Orth wrote:
This patch broke Solaris bootstrap (seen on i386-pc-solaris2.12):
Fixed by pruning hidden names
On Tue, Feb 16, 2016 at 06:04:48PM -0700, Martin Sebor wrote:
> >Formatting. = needs to be on the next line.
>
> There are literally dozens of examples of this style in this file
> alone. In one of the two instances of this style in this patch,
> moving the equals sign to the next line would for
On 02/14/2016 11:38 AM, Richard Biener wrote:
On February 14, 2016 5:35:13 PM GMT+01:00, Jeff Law wrote:
On 02/12/2016 10:21 AM, Jeff Law wrote:
But really we simply need a better DSE algorithm.
So the way to fix DSE is to keep the existing algorithm and track the
hunks of Complex/aggregates
On 16/02/16 16:24, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, %{ftree-parallelize-loops=*} expands to
all -ftree-parallelize-loops= options, not just the last one.
So greater_than_spec_func is actually called say for
-ftree-parallelize-loops=0 -ftree-parallelize-loops=2 with
- ftree-parall
On 02/16/2016 05:38 AM, Markus Trippelsdorf wrote:
Here is another testcase that every compiler I've tested (clang, icc,
microsoft) accepts, but is rejected by gcc-6:
class A {
public:
template void m_fn1();
};
A *fn1(int *);
template class B : A {
static int *m_fn2() { fn1(m_fn2())->m_f
On Tue, Feb 16, 2016 at 4:44 PM, Bill Schmidt
wrote:
> On Tue, 2016-02-16 at 11:40 -0800, David Edelsohn wrote:
>> This is okay, but how about starting with a testcase for this?
>
> Fair enough. Here's the revised patch with a test, which I've verified
> on powerpc64-unknown-linux-gnu. Ok to pro
See patch to fix this below.
On 02/16/2016 11:38 AM, Dominique d'Humières wrote:
> With the following reduced test
>
> program test
> implicit none
> integer :: i, j, k, ios
> integer, parameter :: big = 600
> character(kind=4,len=big) :: str1, str2
>
> do i=1,big, 10
> do j = 0, 9
On 02/15/2016 01:29 AM, Jakub Jelinek wrote:
On Sun, Feb 14, 2016 at 07:16:13PM -0700, Martin Sebor wrote:
+case BUILT_IN_ALLOCA_WITH_ALIGN:
+ {
+ /* Get the requested alignment (in bits) if it's a constant
+ integer expression. */
+ HOST_WIDE_INT align =
+
Clearly the DR 141 change is requiring much larger adjustments in the
rest of the compiler than I'm comfortable making at this point in the
GCC 6 schedule, so I'm backing out my earlier changes for 10200 and
69753 and replacing them with a more modest fix for 10200: Now we will
still find membe
Functions __muldf3_aux, __divdf3_aux, __mulsf3_aux and __divsf3_aux
don't start with leaf_entry, so they need explicit .literal_position,
otherwise libgcc build fails in the presence of --text-section-literals.
2016-02-17 Max Filippov
libgcc/
* config/xtensa/ieee754-df.S (__muldf3_aux,
On Tue, Feb 16, 2016 at 11:35:24PM +, Joseph Myers wrote:
> What's right is:
>
> * In cases where it should return an integer constant (you've said that's
> when the argument is not a VLA, as for sizeof), there should be no
> diagnostic.
Right.
> * In cases where it should not return an in
On Tue, 16 Feb 2016, Stuart Brady wrote:
> On Tue, Feb 16, 2016 at 11:10:08PM +, Joseph Myers wrote:
> > It sets it to be null - but does it diagnose conversion from integer to
> > pointer without a cast (it should do so if __array_size is not evaluating
> > to an integer constant expression
On Tue, Feb 16, 2016 at 11:10:08PM +, Joseph Myers wrote:
> It sets it to be null - but does it diagnose conversion from integer to
> pointer without a cast (it should do so if __array_size is not evaluating
> to an integer constant expression, but not if it is evaluating to an
> integer con
On Tue, 16 Feb 2016, Stuart Brady wrote:
> > For whether arguments are evaluated, you need __array_size with arguments
> > that have side effects, and then test whether those side effects occurred.
> > For whether results are integer constant expressions, you can test e.g.
> > whether __array_
... and I managed to confuse myself about which LRA issue I had
approval for on gcc-5-branch, and checked it in. Sorry. If I don't
hear back until tomorrow I'll revert it.
Sorry, Bernd. I should be more clear too. The patch is ok for any GCC
version with lra-remat.c (it includes gcc-5 and comi
On 02/16/2016 04:20 PM, Bernd Schmidt wrote:
On 02/15/2016 02:13 PM, Bernd Schmidt wrote:
On 02/04/2016 09:27 PM, Vladimir Makarov wrote:
After a few false starts, I came up with the patch below, which keeps
track of not just the candidate insn, but also an activation insn, and
chooses candid
On Tue, 16 Feb 2016, Martin Sebor wrote:
> > Presumably the C++ liaison people considered compatibility as part of the
> > WG14 discussions. In any case, I see no sign that (beyond the
> > "fundamental type" terminology issue) the wording in C++ is any better
> > thought out than the pre-DR#445 C
On Tue, 2016-02-16 at 11:40 -0800, David Edelsohn wrote:
> This is okay, but how about starting with a testcase for this?
Fair enough. Here's the revised patch with a test, which I've verified
on powerpc64-unknown-linux-gnu. Ok to proceed?
Thanks!
Bill
[gcc]
2016-02-16 Bill Schmidt
On 02/14/2016 11:38 AM, Richard Biener wrote:
On February 14, 2016 5:35:13 PM GMT+01:00, Jeff Law wrote:
On 02/12/2016 10:21 AM, Jeff Law wrote:
But really we simply need a better DSE algorithm.
So the way to fix DSE is to keep the existing algorithm and track the
hunks of Complex/aggregates
On 02/15/2016 02:13 PM, Bernd Schmidt wrote:
On 02/04/2016 09:27 PM, Vladimir Makarov wrote:
After a few false starts, I came up with the patch below, which keeps
track of not just the candidate insn, but also an activation insn, and
chooses candidates only if they are both available and activ
Hello world,
the attached patch fixes PR 69742 (a regression) by simply not
attempting to do function elimination in an assoc list.
Committed as obvious and simple to trunk, the other affected
branches will follow shortly.
Regards
Thomas
2015-02-16 Thomas Koenig
PR fortran
On 12/08/15 15:35, Evandro Menezes wrote:
Emit square root using the Newton series
2015-12-03 Evandro Menezes
gcc/
* config/aarch64/aarch64-protos.h (aarch64_emit_swsqrt):
Declare new
function.
* config/aarch64/aarch64-simd.md (sqrt2): New
expa
On 16/02/16 17:54, Jakub Jelinek wrote:
On Tue, Feb 16, 2016 at 05:52:55PM +0100, Tom de Vries wrote:
Committed both patches to 4.9 and 5 branches.
In order to run testsuite/libgomp.fortran/declare-simd-4.f90 with the 4.9
branch build, I needed in addition:
- r212268
https://gcc.gnu.org/view
On Tue, 2016-02-16 at 11:40 -0800, David Edelsohn wrote:
> This is okay, but how about starting with a testcase for this?
That's fine. I'll make it generic enough that we can add to it later,
then.
Bill
>
> Thanks David
>
> On Feb 16, 2016 11:37 AM, "Bill Schmidt"
> wrote:
> Hi,
>
On 02/16/16 04:28, James Greenhalgh wrote:
On Mon, Feb 15, 2016 at 11:24:53AM -0600, Evandro Menezes wrote:
James,
There seem to be SPEC CPU2000fp validation issues on A57 when this
flag is present too. Though I evaluated the algorithm with a huge
random set of values, always delivering accura
On 02/16/2016 01:01 PM, Jakub Jelinek wrote:
On Tue, Feb 16, 2016 at 07:21:49PM +0100, Jakub Jelinek wrote:
I'm already bootstrapping/regtesting following variant.
2016-02-16 Jakub Jelinek
PR c/69835
* common.opt (Wnonnull-compare): New warning.
* doc/invoke.texi (-W
On 16.02.2016 15:03, Jan Hubicka wrote:
>> @example
>> -/* Note that this code will not compile with -masm=intel */
>> -#define DebugBreak() asm("int $3")
>> +/* Define macro at file scope with basic asm. */
>> +/* Add macro parameter p to eax. */
>> +asm(".macro test p\n\t"
>> +"addl $\\p, %
On Tue, Feb 16, 2016 at 07:21:49PM +0100, Jakub Jelinek wrote:
> I'm already bootstrapping/regtesting following variant.
>
> 2016-02-16 Jakub Jelinek
>
> PR c/69835
> * common.opt (Wnonnull-compare): New warning.
> * doc/invoke.texi (-Wnonnull): Remove text about comparison
>
With the following reduced test
program test
implicit none
integer :: i, j, k, ios
integer, parameter :: big = 600
character(kind=4,len=big) :: str1, str2
do i=1,big, 10
do j = 0, 9
k = i + j
str2(k:k) = char(65+j)
end do
end do
open(15, status='scratch', encodin
Hi,
During the little-endian vector modification work in 2014, I
accidentally introduced an error that Uli Weigand noticed this week.
This results in wrong code being generated for the
__builtin_altivec_lvxl and vec_lvxl interfaces; an "lvx" instruction is
generated instead of an "lvxl" instructio
On Tue, Feb 16, 2016 at 02:00:45PM -0500, Jason Merrill wrote:
> On 02/10/2016 10:31 AM, Jason Merrill wrote:
> >On 02/09/2016 03:29 PM, Rainer Orth wrote:
> >>This patch broke Solaris bootstrap (seen on i386-pc-solaris2.12):
> >
> >Fixed by pruning hidden names from the lookup result in more place
On 02/10/2016 10:31 AM, Jason Merrill wrote:
On 02/09/2016 03:29 PM, Rainer Orth wrote:
This patch broke Solaris bootstrap (seen on i386-pc-solaris2.12):
Fixed by pruning hidden names from the lookup result in more places.
...and this broke some dubious code in LLVM. Fixed thus.
Tested x86
Presumably the C++ liaison people considered compatibility as part of the
WG14 discussions. In any case, I see no sign that (beyond the
"fundamental type" terminology issue) the wording in C++ is any better
thought out than the pre-DR#445 C wording.
The C++ wording matches the pre-DR 445 C word
From: Jeff Law
Sent: 11 February 2016 23:26
To: Bin.Cheng
Cc: Bin Cheng; gcc-patches@gcc.gnu.org; nd
Subject: Re: [PATCH PR69052]Check if loop inv can be propagated into mem ref
with additional addr expr canonicalization
>> On 02/11/2016 10:59 AM, Bin.Che
On 02/16/2016 11:21 AM, Jakub Jelinek wrote:
On Tue, Feb 16, 2016 at 11:12:27AM -0700, Jeff Law wrote:
Not sure if it matters but wouldn't walking over function parameters
and their default def SSA names immediate uses be cheaper than
matching all conditions? Esp. as nonnull_arg_p walks over al
On 02/16/2016 09:32 AM, Patrick Palka wrote:
clang also rejects the case where A::FromWebContents is overloaded
with a static member function and non-static one, and gcc now accepts
this case.
This is a clang bug.
Jason
On Tue, Feb 16, 2016 at 11:12:27AM -0700, Jeff Law wrote:
> >Not sure if it matters but wouldn't walking over function parameters
> >and their default def SSA names immediate uses be cheaper than
> >matching all conditions? Esp. as nonnull_arg_p walks over all
> >DECL_ARGUMENTS (up to the searched
On 02/16/2016 08:36 AM, Richard Biener wrote:
On Tue, 16 Feb 2016, Jakub Jelinek wrote:
Hi!
As has been reported today on gcc@, the new -Wnonnull warning addition
warns even about nonnull parameters that were changed (or could be changed)
in the function. IMHO the nonnull attribute only talks
This is another regression in the debug info, this time introduced on the
mainline by my patch toggling the signedness of Character in Ada.
Tested on x86_64-suse-linux, applied on the mainline.
2016-02-16 Eric Botcazou
* gcc-interface/gigi.h (maybe_debug_type): New inline function.
On 02/16/2016 05:17 AM, Dominique d'Humières wrote:
> Hi Jerry,
>
>> Thanks for review. Committed to trunk r233436.
>
> The test gfortran.dg/read_bang4.f90 fails on x86_64-apple-darwin15:
>
> a.out(15552,0x7fff7b2e3000) malloc: *** error for object 0x7fb472804c00:
> pointer being freed was not
The fix for PR debug/16063 slightly disturbed the debug info in Ada by adding
bogus base types to enumeration types; the latter are base types in Ada.
Tested on x86_64-suse-linux, applied on the mainline and 5 branch.
2016-02-16 Eric Botcazou
* gcc-interface/misc.c (gnat_enum_underl
On 02/16/2016 12:06 AM, Christophe Lyon wrote:
> On 15 February 2016 at 23:16, Janne Blomqvist
> wrote:
>> On Mon, Feb 15, 2016 at 11:45 PM, Jerry DeLisle
>> wrote:
>>> The title of the PR should be "Mishandling of namelist comments" or
>>> "Interpreting '!' as a comment in non-namelist reads".
On Tue, Feb 16, 2016 at 09:39:10AM -0800, H.J. Lu wrote:
> Index: gcc/testsuite/gcc.dg/pr69801.c
> > ===
> > *** gcc/testsuite/gcc.dg/pr69801.c (revision 0)
> > --- gcc/testsuite/gcc.dg/pr69801.c (working copy)
> > *
On Tue, Feb 16, 2016 at 12:35 AM, Richard Biener wrote:
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
> 2016-02-16 Richard Biener
>
> PR middle-end/69801
> * fold-const.c (operand_equal_p): For COND_EXPR zero operand
> mask OEP_ADDRESS_
Hi Richard, Hi Ramana,
The ARM backend has some problems compiling for the old ARMv3
architecture. See:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254
for an example of this. v3 is very old now, and I am not sure how
much interest there is in continuing to support it, but I am
On Tue, 16 Feb 2016, Martin Sebor wrote:
> On 02/16/2016 08:54 AM, Joseph Myers wrote:
> > On Tue, 16 Feb 2016, Martin Sebor wrote:
> >
> > > Max_align_t need not impact efficiency. In C, the malloc alignment
> > > also need not have an impact on the type since aligned_alloc returns
> > > storag
On 02/16/2016 07:55 AM, Martin Liška wrote:
Hello.
As I finally hunted issue in Firefox that was responsible for start-up
segfault, I would like
to describe a new behavior of the compiler that emits clobbers to class
constructors (w/ -flifetime-dse).
As also Richi spotted quite similar issue i
On Tue, Feb 16, 2016 at 05:52:55PM +0100, Tom de Vries wrote:
> Committed both patches to 4.9 and 5 branches.
>
> In order to run testsuite/libgomp.fortran/declare-simd-4.f90 with the 4.9
> branch build, I needed in addition:
> - r212268
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=2
On 16/02/16 12:11, Jakub Jelinek wrote:
On Tue, Feb 16, 2016 at 12:10:29PM +0100, Tom de Vries wrote:
>On 16/02/16 11:04, Jakub Jelinek wrote:
> >On Tue, Feb 16, 2016 at 10:56:58AM +0100, Tom de Vries wrote:
> >>>AFAIU, it's not a release regression given that:
> >>>- this has failed since 4.9
On 02/16/2016 08:54 AM, Joseph Myers wrote:
On Tue, 16 Feb 2016, Martin Sebor wrote:
Max_align_t need not impact efficiency. In C, the malloc alignment
also need not have an impact on the type since aligned_alloc returns
storage that is (or can be) more strictly aligned.
As per the DR#445 re
Hi,
The attached patch is a backport of the fix for PR64748.
Thanks,
Jim
ChangeLog entries
Backport from trunk:
PR c/64748
gcc/cp/
* parser.c (cp_parser_oacc_data_clause_deviceptr): Remove checking.
* semantics.c (finish_omp_clauses): Add dev
On Tue, 16 Feb 2016, Martin Sebor wrote:
> Max_align_t need not impact efficiency. In C, the malloc alignment
> also need not have an impact on the type since aligned_alloc returns
> storage that is (or can be) more strictly aligned.
As per the DR#445 resolution, malloc must return memory "whose
On 02/14/2016 11:38 AM, Richard Biener wrote:
On February 14, 2016 5:35:13 PM GMT+01:00, Jeff Law
wrote:
On 02/12/2016 10:21 AM, Jeff Law wrote:
But really we simply need a better DSE algorithm.
So the way to fix DSE is to keep the existing algorithm and track
the hunks of Complex/aggregates
On 02/16/2016 06:44 AM, Joseph Myers wrote:
On Tue, 16 Feb 2016, Martin Sebor wrote:
That said, I think it's worth pointing out that max_align_t has
nothing to do with standard C types. The intent of the type is
to expose a type with the strictest alignment supported by
an implementation for a
On 02/16/2016 07:21 AM, Bernd Schmidt wrote:
On 02/08/2016 05:30 PM, Jeff Law wrote:
On 01/29/2016 04:40 AM, Bernd Schmidt wrote:
c/
PR c/69522
* c-parser.c (c_parser_braced_init): New arg outer_obstack. All
callers changed. If nested_p is true, use it to call
finish_implicit_
On Tue, Feb 16, 2016 at 09:35:25AM +0100, Richard Biener wrote:
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
> 2016-02-16 Richard Biener
>
> PR middle-end/69801
> * fold-const.c (operand_equal_p): For COND_EXPR zero operand
> mask OEP_ADD
On Tue, 16 Feb 2016, Jakub Jelinek wrote:
> Hi!
>
> As has been reported today on gcc@, the new -Wnonnull warning addition
> warns even about nonnull parameters that were changed (or could be changed)
> in the function. IMHO the nonnull attribute only talks about the value of
> the parameter upo
Hi!
As has been reported today on gcc@, the new -Wnonnull warning addition
warns even about nonnull parameters that were changed (or could be changed)
in the function. IMHO the nonnull attribute only talks about the value of
the parameter upon entry to the function, if you assign something else
t
On Mon, Feb 15, 2016 at 03:51:43PM +, Stuart Brady wrote:
> On Mon, Feb 15, 2016 at 03:05:36PM +0100, Marek Polacek wrote:
> > On Sat, Feb 13, 2016 at 03:16:49AM +, Stuart Brady wrote:
> > > For a hypothetical change to the C standard itself, I think one might use
> > > the name "_ArraySize
Hi!
As mentioned in the PR, %{ftree-parallelize-loops=*} expands to
all -ftree-parallelize-loops= options, not just the last one.
So greater_than_spec_func is actually called say for
-ftree-parallelize-loops=0 -ftree-parallelize-loops=2 with
- ftree-parallelize-loops=0 - ftree-parallelize-loops=2
On Mon, Feb 15, 2016 at 11:11:54PM +, Joseph Myers wrote:
> On Sat, 13 Feb 2016, Stuart Brady wrote:
>
> > So in other words, adapting all of the sizeof tests would be appropriate,
> > and sizeof tests for non-array types would change from expected passes to
> > expected failures?
>
> It's no
On 16/02/16 14:55, Martin Liška wrote:
Hello.
As I finally hunted issue in Firefox that was responsible for start-up
segfault, I would like
to describe a new behavior of the compiler that emits clobbers to class
constructors (w/ -flifetime-dse).
As also Richi spotted quite similar issue in op
So there's the same issue left in DOM and an "optimization" in
the alias machinery fails to honor the overridden alias-sets.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-02-16 Richard Biener
PR tree-optimization/69776
* tree-ssa-alias.c (indire
Hello.
As I finally hunted issue in Firefox that was responsible for start-up
segfault, I would like
to describe a new behavior of the compiler that emits clobbers to class
constructors (w/ -flifetime-dse).
As also Richi spotted quite similar issue in openjade package, I think it worth
for ment
On Tue, Feb 16, 2016 at 5:38 AM, Markus Trippelsdorf
wrote:
> On 2016.02.15 at 16:13 -0500, Jason Merrill wrote:
>> When we stopped finding function templates with unqualified lookup due to
>> the DR141 fix, that exposed bugs in our lookup within the object expression
>> scope; an object-expressio
On 16 February 2016 at 10:53, James Greenhalgh wrote:
> On Tue, Feb 16, 2016 at 09:27:00AM +, Kyrill Tkachov wrote:
>> Hi all,
>>
>> As Christophe reported at:
>> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00784.html
>>
>> The test gcc.target/aarch64/assembler_arch_1.c fails to assemble on
On 02/08/2016 05:30 PM, Jeff Law wrote:
On 01/29/2016 04:40 AM, Bernd Schmidt wrote:
c/
PR c/69522
* c-parser.c (c_parser_braced_init): New arg outer_obstack. All
callers changed. If nested_p is true, use it to call
finish_implicit_inits.
* c-tree.h (finish_implicit_inits):
Thanks Joern,
Committed: r233451
> -Original Message-
> From: Joern Wolfgang Rennecke [mailto:g...@amylaar.uk]
> Sent: Saturday, February 13, 2016 12:42 AM
> To: Claudiu Zissulescu; gcc-patches@gcc.gnu.org
> Cc: francois.bed...@synopsys.com; jeremy.benn...@embecosm.com
> Subject: Re: [PAT
> @example
> -/* Note that this code will not compile with -masm=intel */
> -#define DebugBreak() asm("int $3")
> +/* Define macro at file scope with basic asm. */
> +/* Add macro parameter p to eax. */
> +asm(".macro test p\n\t"
> +"addl $\\p, %eax\n\t"
> +".endm");
> +
> +/* Use macro in
On Tue, 16 Feb 2016, Martin Sebor wrote:
> That said, I think it's worth pointing out that max_align_t has
> nothing to do with standard C types. The intent of the type is
> to expose a type with the strictest alignment supported by
> an implementation for an object of any type and with any stora
On Tue, Feb 16, 2016 at 07:00:58PM +1030, Alan Modra wrote:
> What's wrong is the rs6000 backend asserting that (gtu (reg:CC)) can't
> happen, because obviously it does. Rather than trying to fix combine,
> (where the ICE happens on attempting to validate the insn!), I think
> the rs6000 backend s
Hi Jerry,
> Thanks for review. Committed to trunk r233436.
The test gfortran.dg/read_bang4.f90 fails on x86_64-apple-darwin15:
a.out(15552,0x7fff7b2e3000) malloc: *** error for object 0x7fb472804c00:
pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Prog
On Tue, Feb 16, 2016 at 11:47 AM, David Sherwood wrote:
> Hi,
>
> I have a fix for bugzilla defect 69532, which is a simple change to
> a couple of arm tests to check for effective target arm_v8_neon_hw
> instead of arm_v8_neon_ok.
>
> Tested:
> arm-none-eabi: No regressions in arm.exp testsuite.
Hi,
I have a fix for bugzilla defect 69532, which is a simple change to
a couple of arm tests to check for effective target arm_v8_neon_hw
instead of arm_v8_neon_ok.
Tested:
arm-none-eabi: No regressions in arm.exp testsuite.
Good to go?
David Sherwood.
ChangeLog:
2016-02-16 David Sherwood
On Tue, Feb 16, 2016 at 12:10:29PM +0100, Tom de Vries wrote:
> On 16/02/16 11:04, Jakub Jelinek wrote:
> >On Tue, Feb 16, 2016 at 10:56:58AM +0100, Tom de Vries wrote:
> >>>AFAIU, it's not a release regression given that:
> >>>- this has failed since 4.9.0, and
> >>>- the test-case is not supporte
On 16/02/16 11:04, Jakub Jelinek wrote:
On Tue, Feb 16, 2016 at 10:56:58AM +0100, Tom de Vries wrote:
>AFAIU, it's not a release regression given that:
>- this has failed since 4.9.0, and
>- the test-case is not supported in 4.8,
>so we're not required to fix it in 4.9 and 5 branches.
>
>But, th
On Tue, 16 Feb 2016, Jakub Jelinek wrote:
> On Tue, Feb 16, 2016 at 11:06:53AM +0100, Richard Biener wrote:
> > Hmm, I think it works in general, but I suspect that the pattern has
> > to use the original def but for out analysis we have to look at the
> > pattern.
> >
> > So another fix would be
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-02-16 Richard Biener
PR rtl-optimization/69291
* ifcvt.c (noce_try_store_flag_constants): Re-instantiate
noce_operand_ok check.
Index: gcc/ifcvt.c
On Mon, Feb 15, 2016 at 11:32 AM, Kyrill Tkachov
wrote:
>
> On 04/02/16 08:58, Ramana Radhakrishnan wrote:
>>
>> On Tue, Jun 30, 2015 at 2:15 AM, Jim Wilson wrote:
>>>
>>> This is my suggested fix for PR 65932, which is a linux kernel
>>> miscompile with gcc-5.1.
>>>
>>> The problem here is cause
On 2016.02.15 at 16:13 -0500, Jason Merrill wrote:
> When we stopped finding function templates with unqualified lookup due to
> the DR141 fix, that exposed bugs in our lookup within the object expression
> scope; an object-expression of the current instantiation does not make the
> expression depe
On Tue, Feb 16, 2016 at 11:06:53AM +0100, Richard Biener wrote:
> Hmm, I think it works in general, but I suspect that the pattern has
> to use the original def but for out analysis we have to look at the
> pattern.
>
> So another fix would be to simply fail if there was a pattern detected.
That
On Mon, Feb 15, 2016 at 11:24:53AM -0600, Evandro Menezes wrote:
> On 02/15/16 04:50, James Greenhalgh wrote:
> >On Mon, Feb 08, 2016 at 10:57:10AM +, James Greenhalgh wrote:
> >>On Mon, Feb 01, 2016 at 02:00:01PM +, James Greenhalgh wrote:
> >>>On Mon, Jan 25, 2016 at 11:20:46AM +, Jam
On 15/02/16 20:41 -0800, Tim Shen wrote:
PR libstdc++/69794
* include/bits/regex_scanner.h: Add different special character
sets for grep and egrep regex.
* include/bits/regex_scanner.tcc: Use _M_spec_char more unifiedly.
s/unifiedly/uniformly/
OK for trunk and
On Tue, 16 Feb 2016, Jakub Jelinek wrote:
> On Tue, Feb 16, 2016 at 09:58:37AM +0100, Richard Biener wrote:
> > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> > Hmm, most places calling type_conversion_p already check for the
> > pattern case and only accept a very s
On Tue, Feb 16, 2016 at 10:56:58AM +0100, Tom de Vries wrote:
> AFAIU, it's not a release regression given that:
> - this has failed since 4.9.0, and
> - the test-case is not supported in 4.8,
> so we're not required to fix it in 4.9 and 5 branches.
>
> But, the test-case does fail in 5 and 4.9 br
On 16/02/16 03:22, Jan Hubicka wrote:
On 08/02/16 13:54, Jakub Jelinek wrote:
On Mon, Feb 08, 2016 at 01:46:44PM +0100, Tom de Vries wrote:
[ The pass before pass_omp_simd_clone is pass_dispatcher_calls. It has a
function create_target_clone, similar to simd_clone_create, with a
node.defition a
On Tue, Feb 16, 2016 at 09:27:00AM +, Kyrill Tkachov wrote:
> Hi all,
>
> As Christophe reported at:
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00784.html
>
> The test gcc.target/aarch64/assembler_arch_1.c fails to assemble on older
> assemblers that don't support the LSE architecture ex
Hi all,
As Christophe reported at:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00784.html
The test gcc.target/aarch64/assembler_arch_1.c fails to assemble on older
assemblers that
don't support the LSE architecture extension.
I'd really like to keep the test an assemble test rather than just
On Tue, Feb 16, 2016 at 09:58:37AM +0100, Richard Biener wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> Hmm, most places calling type_conversion_p already check for the
> pattern case and only accept a very specific or fail.
>
> Only widen_mul/sum don't do tha
On Mon, 15 Feb 2016, Jakub Jelinek wrote:
> Hi!
>
> The following patch fixes an ICE where one of the range tests
> is SSA_NAME_DEF_STMT of a bool/_Bool or unsigned : 1 bitfield.
> In that case, we don't know where to put the adjusted range test.
> The patch for this uncommon case gives up, unles
On Tue, Feb 16, 2016 at 10:05:55AM +0100, Richard Biener wrote:
> On Tue, 16 Feb 2016, Jakub Jelinek wrote:
>
> > On Mon, Feb 15, 2016 at 08:43:22PM +0100, Richard Biener wrote:
> > > On February 15, 2016 7:15:35 PM GMT+01:00, Jakub Jelinek
> > > wrote:
> > > >On Mon, Feb 15, 2016 at 06:58:45PM
On Tue, 16 Feb 2016, Jakub Jelinek wrote:
> On Mon, Feb 15, 2016 at 08:43:22PM +0100, Richard Biener wrote:
> > On February 15, 2016 7:15:35 PM GMT+01:00, Jakub Jelinek
> > wrote:
> > >On Mon, Feb 15, 2016 at 06:58:45PM +0100, Richard Biener wrote:
> > >> We could also force_reg those at expansi
While investigating PR69586 I noticed we fail to register asserts for
the seen condition. This is fixed by the below patch. I'm still
thinking on how to improve BIT_AND_EXPR handling to catch the missed
jump-threading.
Boootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
20
On Mon, 15 Feb 2016, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because we first
> create a pattern stmt for _5 = (int) _3; where _3 is bool,
> but then recognize the following multiply as widening multiply, ignore
> there the previous pattern stmt and thus instead of e
On 11 January 2016 at 12:04, James Greenhalgh wrote:
> 2015-12-11 James Greenhalgh
>
> * config/aarch64/aarch64.c (cortexa57_tunings): Remove
> AARCH64_EXTRA_TUNE_RECIP_SQRT.
>
OK /Marcus
On 26 January 2016 at 16:04, James Greenhalgh wrote:
> 2016-01-25 James Greenhalgh
>
> * config/aarch64/aarch64.md
> (arch64_sqrdmlh_lane): Fix register
> constraints for operand 3.
> (aarch64_sqrdmlh_laneq): Likewise.
>
OK /Marcus
On 20 January 2016 at 15:22, James Greenhalgh wrote:
> gcc/
>
> 2016-01-20 James Greenhalgh
> Ramana Radhakrishnan
>
> * config/aarch64/aarch64.c (aarch64_expand_vector_init): Refactor,
> always use lane loads to construct non-constant vectors.
>
> gcc/testsuite/
On 11 January 2016 at 11:53, James Greenhalgh wrote:
>
> ---
> 2015-12-10 James Greenhalgh
>
> * config/aarch64/aarch64.c (use_rsqrt_p): Always use software
> reciprocal sqrt for -mlow-precision-recip-sqrt.
>
OK /Marcus
On Mon, 15 Feb 2016, Richard Sandiford wrote:
> Richard Biener writes:
> > On Wed, 10 Feb 2016, Bernd Schmidt wrote:
> >
> >> On 02/10/2016 02:50 PM, Richard Biener wrote:
> >> > On Wed, 10 Feb 2016, Bernd Schmidt wrote:
> >> >
> >> > > On 02/10/2016 02:35 PM, Richard Biener wrote:
> >> > >
> >
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-02-16 Richard Biener
PR middle-end/69801
* fold-const.c (operand_equal_p): For COND_EXPR zero operand
mask OEP_ADDRESS_OF.
* gcc.dg/pr69801.c: New testcase.
Index: gcc/fold-const.c
=
1 - 100 of 102 matches
Mail list logo
