This patch addresses multiple issues with how we determine when to split
paths. The primary motivation is addressing 68541 (P1).
As I've gotten testcodes from Ajit, I've been able to look closely at
the path splitting opportunities and consistently what I've seen is that
contrary to the orig
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Finnish team of translators. The file is available at:
http://translationproject.org/latest/gcc/fi.po
(This file, 'gcc-6.1-b20160131.fi.po',
On 02/05/2016 05:32 PM, Marek Polacek wrote:
if (TREE_CODE (type) == ERROR_MARK)
return NULL_TREE;
+ /* Here, DECL may change value; purge caches. */
+ clear_fold_cache ();
+ clear_cv_cache ();
+
if (MAYBE_CLASS_TYPE_P (type))
This should happen after computing the value to be s
This issue is similar to c++/68586 -- maybe_constant_value returned stale
value for a decl from the cache. Fixed by clearing the caches when we
store init value for a decl.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2016-02-05 Marek Polacek
PR c++/69688
* typeck2.c
Marcin KoÅcielnicki wrote:
> I'll stay with checking for larl - while I can imagine someone adding a
> new conditional branch instruction, I don't see a need for another
> larl-like instruction. Besides, this way the failure mode for an
> unknown instruction would be producing an error, inste
Ping. Thanks.
On 01/27/2016 11:12 AM, Kelvin Nilsen wrote:
This patch has bootstrapped and tested on
powerpc64le-unknown-linux-gnu with no regressions. Is this ok for the
trunk?
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48344 for the
original problem report. The error resulted beca
On Fri, Feb 5, 2016 at 12:51 PM, Jason Merrill wrote:
> On 02/05/2016 09:13 AM, Jason Merrill wrote:
>>
>> On 02/05/2016 07:54 AM, Patrick Palka wrote:
>>>
>>> On Thu, 4 Feb 2016, Patrick Palka wrote:
>>>
The compiler correctly detects and diagnoses invalid constructor calls
such as C::C
On Tue, 19 Jan 2016, Patrick Palka wrote:
On Tue, Jan 19, 2016 at 9:56 AM, Jason Merrill wrote:
On 01/18/2016 10:55 PM, Patrick Palka wrote:
mark_used is wrongly diagnosing a use of a TEMPLATE_DECL (e.g. the call
to f1 in function f3 of auto-fn29.C below) for having an undeduced
'auto' retur
On 04/02/16 17:27, Ulrich Weigand wrote:
Marcin Kościelnicki wrote:
Fair enough. Here's what I'm going to implement in gold:
- any PLT relocation: call
- PC32DBL on a larl: non-call
- PC32DBL otherwise: call
- any other relocation: non-call
Does that sound right?
Hmm, I'm wondering about
On 02/05/2016 11:17 AM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, move_plus_up on
(subreg:SI (plus:DI (reg/f:DI 20 frame)
(const_int 16 [0x10])) 0)
returns
(plus:SI (plus:SI (subreg:SI (reg/f:DI 20 frame) 0)
(const_int 16 [0x10]))
(const_int 16 [0x10]))
which is wro
The problem here was that the call to convert_to_integer_nofold was
still pushing the conversion down into the multiply expression, and when
we do the multiplication in unsigned short it overflows. This patch
fixes convert_to_integer_1 to not do any truncation distribution when
!dofold. But t
On 02/05/2016 06:43 AM, Alexander Fomin wrote:
Hi!
Some kind of this patch was submitted about a year ago by Igor
Zamyatin. It's an attempt to fix PR rtl-optimization/64081 by enabling
RTL loop unrolling for duplicated exit blocks and back edges.
At the time it caused AIX bootstrap failure, but
On 02/05/2016 04:25 AM, Richard Biener wrote:
The following patch fixes the performance regression for 435.gromacs
on x86_64 with AVX2 (Haswell or bdver2) caused by
2015-12-18 Andreas Krebbel
* ira.c (ira_setup_alts): Move the scan for commutative modifier
to the first loop t
On 02/05/2016 12:31 PM, Bernd Schmidt wrote:
This patch fixes PR60410 by removing -fshort-double. Nick earlier
propsed a fix for the crash, but Richard B suggested removing the option
entirely, and I'd agree with that. It's a pointless ABI-changing option
on most targets, and if a port really nee
This patch fixes PR60410 by removing -fshort-double. Nick earlier
propsed a fix for the crash, but Richard B suggested removing the option
entirely, and I'd agree with that. It's a pointless ABI-changing option
on most targets, and if a port really needs it, it should be a -m option
that tweaks
Hi,
As reported by PR68021, there is an ivopt bug all the time. As designed, ivopt
tries to identify and reuse induction variables in the original input.
Apparently we don't need to compute such original biv because the computation
is already there. Every time an iv use is rewritten, ivopt ch
On 02/03/2016 09:05 PM, Jakub Jelinek wrote:
2016-02-03 Jakub Jelinek
PR c++/69628
* charset.c (cpp_interpret_charconst): Clear *PCHARS_SEEN
and *UNSIGNEDP if bailing out early due to errors.
* g++.dg/parse/pr69628.C: New test.
Ok.
Bernd
Ping.
On 01/29/2016 12:40 PM, Bernd Schmidt wrote:
Let's say we have
struct a {
int x[1];
int y[1];
} x = { 0, { 0 } };
^
When we reach the marked brace, we call into push_init_level, where we
notice that we have implicit initializers (for x[]) lying around that we
should deal
Enable non-executable stack mode if assembler and linker support it.
Currently the MIPS FPU emulator uses eXecute Out of Line (XOL) on the stack to
handle instructions in the delay slots of FPU branches. Because of this MIPS
cannot have a non-executable stack. While the solution on the kernel sid
Hi all,
I have slightly updated the patch now to avoid string-breaking issues
(even if it may not be a problem at all, as mentioned by Jospeh). Also
I removed the questionable part in intrinsic.c that I was not sure
about.
This version of the patch should not be too far from obvious now. Ok for t
Hi!
As mentioned in the PR, move_plus_up on
(subreg:SI (plus:DI (reg/f:DI 20 frame)
(const_int 16 [0x10])) 0)
returns
(plus:SI (plus:SI (subreg:SI (reg/f:DI 20 frame) 0)
(const_int 16 [0x10]))
(const_int 16 [0x10]))
which is wrong, the original added just 16, but the returned
r
On 02/05/2016 11:41 AM, Martin Sebor wrote:
But since GCC does allow global/static objects of structs with
flexible array members to be initialized, and (presumably) will
continue to even after the above is rejected in C++, the code
in the patch that detects overflowing such variables will contin
On 02/05/2016 09:13 AM, Jason Merrill wrote:
On 02/05/2016 07:54 AM, Patrick Palka wrote:
On Thu, 4 Feb 2016, Patrick Palka wrote:
The compiler correctly detects and diagnoses invalid constructor calls
such as C::C () in a non-template context but it fails to do so while
processing a class tem
struct A
{
int i, ar[];
};
int main()
{
int k = 24;
struct A a = { 1, 2, 3, 4 };
int j = 42;
return a.ar[1];
}
G++ accepts this testcase and happily puts k and j in the same stack
slots as elements of a.ar[], while GCC rejects it. We shouldn't accept
it. In any case, we should u
On Thu, Feb 4, 2016 at 2:21 PM, Uros Bizjak wrote:
> On Thu, Feb 4, 2016 at 1:49 PM, Andreas Schwab wrote:
>
OTOH, does this testcase even gets a chance to run?
>>>
>>> It's not a runtime check.
>>
>> But it didn't link until today:
>>
>> Running /opt/gcc/gcc-20160203/gcc/testsuite/gcc.dg/sa
This is a runtime test and requires correct runtime support.
2016-02-05 Uros Bizjak
* gcc.target/i386/pr69577.c: Require avx_runtime target.
Tested on x86_64-linux-gnu AVX target and committed to mainline SVN.
Uros.
Index: gcc.target/i386/pr69577.c
===
On Fri, Feb 5, 2016 at 1:11 AM, Uros Bizjak wrote:
> On Fri, Feb 5, 2016 at 12:04 AM, Jakub Jelinek wrote:
>> Hi!
>>
>> As mentioned in the PR, the convert_scalars_to_vector hunk is important,
>> without that we e.g. miscompile simplify-rtx.c.
>> The following patch restores that hunk and extends
Can this be approved?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69089
On Mon, Jan 04, 2016 at 12:33:21PM +0100, Dominik Vogt wrote:
> On Fri, Jan 01, 2016 at 05:53:08PM -0700, Martin Sebor wrote:
> > On 12/31/2015 04:50 AM, Dominik Vogt wrote:
> > >The attached patch fixes C++-11 handling of
The attached patch adds a testcase for PR 69625.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
ChangeLog
* gcc.target/s390/pr69625.c: Add test case.
>From 08df803a901078cabca938d0a7d0d6120b7c6132 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Fri, 5 Feb 2016 15:13:08 +0100
Sub
> "rth" == Richard Henderson writes:
rth> The user-friendly way to do this would probably be some sort of pragma
rth> that allows user-defined address spaces, and user-defined conversion
rth> between them. But that's certainly not going to happen in the
rth> near-term.
Related is https://gcc
> P.S.: if code that is missing prototypes for stdarg functions is of no
> concern,
> there is another ABI alternative that might give good code density for
> architectures like ARC that have pre-decrement addressing modes and allow
> immediates to be pushed:
>
> You could put all unnamed argumen
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: 03 February 2016 22:45
> To: Andrew Bennett
> Cc: Matthew Fortune; Steve Ellcey; gcc-patches@gcc.gnu.org;
> c...@codesourcery.com
> Subject: Re: [Patch, MIPS] Patch for PR 68400, a mips16 bug
>
> A
On Fri, Feb 05, 2016 at 10:33:51AM -0500, David Malcolm wrote:
> On Thu, 2016-02-04 at 21:00 -0500, tbsaunde+...@tbsaunde.org wrote:
> > From: Trevor Saunders
> >
> > Hi,
> >
> > We can tell git to highlight whitespace errors in diffs, and if you
> > enable the
> > default pre-commit hook git wo
On Thu, 2016-02-04 at 21:00 -0500, tbsaunde+...@tbsaunde.org wrote:
> From: Trevor Saunders
>
> Hi,
>
> We can tell git to highlight whitespace errors in diffs, and if you
> enable the
> default pre-commit hook git won't allow you to make a commit with a
> whitespace
> error violating the rules
Hi David,
On 05/02/16 15:24, David Malcolm wrote:
The attached patch adds a summary blurb to the top of the GCC 6 changes
page, emphasizing that there have been more improvements that we could
ever hope to enumerate, and providing prominent links to the porting
page, and to the general documenta
The attached patch adds a summary blurb to the top of the GCC 6 changes
page, emphasizing that there have been more improvements that we could
ever hope to enumerate, and providing prominent links to the porting
page, and to the general documentation (albeit to the "Development"
version for now, si
On Thu, Jan 14, 2016 at 4:31 PM, Jeff Law wrote:
> On 01/10/2016 08:20 PM, Patrick Palka wrote:
>>
>> On Thu, Dec 31, 2015 at 10:40 AM, Patrick Palka
>> wrote:
>>>
>>> This patch makes it so that a gimplification failure is considered to be
>>> an internal error under normal circumstances, so tha
Hi All,
Here is updated patch - I came back to move call statements also since
masked loads are presented by internal call. I also assume that for
the following simple loop
for (i = 0; i < n; i++)
if (b1[i])
a1[i] = sqrtf(a2[i] * a2[i] + a3[i] * a3[i]);
motion must be done for all vec
Hi,
This patch reverts r232560 which caused multiple failures
for Pointer Bounds Checker. Patch was bootstrapped and
regtested on x86_64-pc-linux-gnu. Applied to trunk.
Thanks,
Ilya
--
2016-02-05 Ilya Enkovich
PR target/69369
Revert r232560:
2016-01-19 Jan Hubicka
P.S.: if code that is missing prototypes for stdarg functions is of no
concern, there is another ABI
alternative that might give good code density for architectures like ARC
that have pre-decrement
addressing modes and allow immediates to be pushed:
You could put all unnamed arguments on the st
On 02/05/2016 07:54 AM, Patrick Palka wrote:
On Thu, 4 Feb 2016, Patrick Palka wrote:
The compiler correctly detects and diagnoses invalid constructor calls
such as C::C () in a non-template context but it fails to do so while
processing a class template. [ Section 3.4.3.1 of the standard is w
Hi!
Some kind of this patch was submitted about a year ago by Igor
Zamyatin. It's an attempt to fix PR rtl-optimization/64081 by enabling
RTL loop unrolling for duplicated exit blocks and back edges.
At the time it caused AIX bootstrap failure, but now it's OK according
to David's testing. I've a
On 02/04/2016 04:35 PM, Martin Sebor wrote:
On 02/04/2016 02:10 PM, Jason Merrill wrote:
On 02/04/2016 03:22 PM, Martin Sebor wrote:
+ /* Refers to the declared object that constains the subobject
referenced
+ by OPER. When the object is initialized, makes it possible to
determine
+ t
quot;aM",@progbits,4
.align 4
.LC1:
.long 3225419776
.align 4
.LC2:
.long 3204448256
.align 4
.LC3:
.long 1086324736
.align 4
.LC4:
.long 1094713344
.ident "GCC: (GNU) 6.0.0 20160205 (experimenta
On 4 February 2016 at 16:31, Ramana Radhakrishnan
wrote:
> On Sun, Jan 17, 2016 at 9:06 AM, Prathamesh Kulkarni
> wrote:
>> On 31 July 2015 at 15:04, Ramana Radhakrishnan
>> wrote:
>>>
>>>
>>> On 29/07/15 11:09, Prathamesh Kulkarni wrote:
Hi,
This patch tries to implement division with
On Fri, 5 Feb 2016, Jakub Jelinek wrote:
> On Fri, Feb 05, 2016 at 01:35:03PM +0100, Richard Biener wrote:
> > On Fri, 5 Feb 2016, Jakub Jelinek wrote:
> >
> > > On Fri, Feb 05, 2016 at 01:10:26PM +0100, Richard Biener wrote:
> > > > Otherwise bootstrap / testing went ok and a full SPEC 2k6 run d
On 02/05/2016 01:42 PM, Richard Biener wrote:
so indeed the issue is not dx dieing in insn 10 but ax dieing in insn 8...
Maybe LRA can prefer to not do that if enough free registers are
available (that is, never re-use a register)?
Maybe, but at this stage that will probably also have some unp
Hi,
Please find below a simple patch which optimizes the loading of immediate value
by using the clrw or clrb
instruction in case a 0x00 is being loaded into the register.
The patch replaces movw/mov instruction with the smaller clrw/clrb instruction.
The clrw and clrb generates only 1 byte of op
On Thu, 4 Feb 2016, Patrick Palka wrote:
The compiler correctly detects and diagnoses invalid constructor calls
such as C::C () in a non-template context but it fails to do so while
processing a class template. [ Section 3.4.3.1 of the standard is what
makes these forms of constructor calls ill
On Thu, Feb 4, 2016 at 11:35 PM, Richard Henderson wrote:
> On 02/05/2016 08:59 AM, Richard Biener wrote:
>>>
>>> This version fails to fall through to the next code block when
>>>(1) Both types are pointers,
>>>(2) Both types have the same address space,
>>> which will do the wrong thing
On Fri, Feb 05, 2016 at 01:35:03PM +0100, Richard Biener wrote:
> On Fri, 5 Feb 2016, Jakub Jelinek wrote:
>
> > On Fri, Feb 05, 2016 at 01:10:26PM +0100, Richard Biener wrote:
> > > Otherwise bootstrap / testing went ok and a full SPEC 2k6 run doesn't
> > > show any regressions.
> >
> > Any impr
On Fri, 5 Feb 2016, Bernd Schmidt wrote:
> On 02/05/2016 01:10 PM, Richard Biener wrote:
> > It fails
> >
> > FAIL: gcc.target/i386/addr-sel-1.c scan-assembler b+1
> >
> > on i?86 (or x86_64 -m32) though, generating
> >
> > f:
> > .LFB0:
> > .cfi_startproc
> > movl4(%e
This fixes a problem revealed during the split-stack work:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00322.html
Bootstrapped on s390x. No regressions.
Committed to mainline. Needs to be committed to 4.9.x and 5.x as well.
Bye,
-Andreas-
gcc/ChangeLog:
2016-02-05 Andreas Krebbel
On Fri, 5 Feb 2016, Jakub Jelinek wrote:
> On Fri, Feb 05, 2016 at 01:10:26PM +0100, Richard Biener wrote:
> > Otherwise bootstrap / testing went ok and a full SPEC 2k6 run doesn't
> > show any regressions.
>
> Any improvements there?
Noise, but I only did 1 run (I did 3 only for 435.gromacs to
On 02/05/2016 01:10 PM, Richard Biener wrote:
It fails
FAIL: gcc.target/i386/addr-sel-1.c scan-assembler b+1
on i?86 (or x86_64 -m32) though, generating
f:
.LFB0:
.cfi_startproc
movl4(%esp), %eax
leal1(%eax), %edx
movsbl a+1(%eax), %eax
On Fri, Feb 05, 2016 at 01:10:26PM +0100, Richard Biener wrote:
> Otherwise bootstrap / testing went ok and a full SPEC 2k6 run doesn't
> show any regressions.
Any improvements there?
Jakub
On Fri, 5 Feb 2016, Richard Biener wrote:
>
> The following patch fixes the performance regression for 435.gromacs
> on x86_64 with AVX2 (Haswell or bdver2) caused by
>
> 2015-12-18 Andreas Krebbel
>
> * ira.c (ira_setup_alts): Move the scan for commutative modifier
> to the firs
Hi!
On Mon, 9 Nov 2015 18:39:19 +0100, Tom de Vries wrote:
> On 09/11/15 16:35, Tom de Vries wrote:
> > this patch series for stage1 trunk adds support to:
> > - parallelize oacc kernels regions using parloops, and
> > - map the loops onto the oacc gang dimension.
> Atm, the parallelization beha
On 02/05/2016 12:50 PM, Jakub Jelinek wrote:
> On Fri, Feb 05, 2016 at 12:43:38PM +0100, Andreas Krebbel wrote:
>> Dominik just made me aware of this stupid copy and paste bug which made me
>> ending up with the very
>> same loops twice :(
>> I've committed the attached patch to fix this:
>>
>> di
On Fri, Feb 05, 2016 at 12:43:38PM +0100, Andreas Krebbel wrote:
> Dominik just made me aware of this stupid copy and paste bug which made me
> ending up with the very
> same loops twice :(
> I've committed the attached patch to fix this:
>
> diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/
On 02/04/2016 05:58 PM, Andreas Krebbel wrote:
> +static void
> +s390_register_info_set_ranges ()
> +{
> + int i, j;
> +
> + /* Find the first and the last save slot supposed to use the stack
> + to set the restore range.
> + Vararg regs might be marked as save to stack but only the
> +
> True, but the compiler bug is in the backends - it just now gets
> exposed more easily (read: w/o user intervention).
As far as I can see there are no problematic types in the source code, i.e.
it's plain ANSI C, so we shouldn't be creating types with non-canonical
alignment from that.
> Does
On 02/01/2016 02:12 PM, Dominik Vogt wrote:
> gcc/ChangeLog
>
> * doc/extend.texi: S/390: Correct some typos.
Applied. Thanks!
-Andreas-
On 02/04/2016 01:28 PM, Dominik Vogt wrote:
> gcc/testsuite/ChangeLog
>
> * gcc.dg/tree-ssa/ssa-dom-cse-2.c: Remove -march=z13 for s390 (only
> necessary on s390x).
Applied. Thanks!
-Andreas-
Hi Thomas,
please note: This is not a review. I don't have the privileges to do so.
In preventing memory clutter I like to advise the use of:
char u_name[GFC_MAX_SYMBOL_LEN + 1];
and safe us all the dynamic memory allocation/free. Furthermore, how
about switching:
strncpy (u_name, name, nle
On 02/01/2016 05:53 PM, Dominik Vogt wrote:
> The attached patch copies the existing
> libstdc++-v3/config/abi/post/s390-linux-gnu/baseline_symbols.txt
> to .../s390x-linux-gnu/32/baseline_symbols.txt. This fixes the
> abi test failure on s390x with -m31.
>
> The patch is gzip'ed because it's la
Hi all,
I've been auditing the patterns in the arm backend that were added/modified for
-mrestrict-it
and I've come up with a few runtime tests that end up generating those patterns.
This patch contains 4 tests for 4 patterns that have paths specific to
-mrestrict-it.
There were some patterns
Ping
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02309.html
Thanks,
Kyrill
On 29/01/16 14:27, Kyrill Tkachov wrote:
Hi all,
Similar to aarch64, the arm port also suffers from PR target/69161 when combine
tries to propagate a CCmode comparison into a vec_duplicate, creating invalid
RTL that I
On 04/02/16 19:35, H.J. Lu wrote:
On Thu, Feb 4, 2016 at 1:34 AM, Kyrill Tkachov
wrote:
On 04/02/16 09:13, Ramana Radhakrishnan wrote:
On Fri, Jan 22, 2016 at 9:52 AM, Kyrill Tkachov
wrote:
Hi all,
PR target/65932 is a wrong-code bug affecting arm and has manifested
itself
when compiling t
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Finnish team of translators. The file is available at:
http://translationproject.org/latest/cpplib/fi.po
(This file, 'cpplib-6.1-b20160131
The following patch fixes the performance regression for 435.gromacs
on x86_64 with AVX2 (Haswell or bdver2) caused by
2015-12-18 Andreas Krebbel
* ira.c (ira_setup_alts): Move the scan for commutative modifier
to the first loop to make it work even with disabled alternatives.
On Fri, Feb 5, 2016 at 12:04 AM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, the convert_scalars_to_vector hunk is important,
> without that we e.g. miscompile simplify-rtx.c.
> The following patch restores that hunk and extends disabling of TARGET_STV
> also for the 64-bit, but not 128
> 2016-02-04 Senthil Kumar Selvaraj
>
> * gcc/testsuite/gcc.dg/sso/p1.c: Add dg-require-effective-target int32.
> * gcc/testsuite/gcc.dg/sso/p2.c: Likewise.
> * gcc/testsuite/gcc.dg/sso/p3.c: Likewise.
> * gcc/testsuite/gcc.dg/sso/p5.c: Likewise.
> * gcc/testsuite/gcc.dg/sso/p6.c: Lik
> Anyone have a sense of how this is supposed to work and what is wrong? The
> lines appear to be the same to me. :-(
You probably need to tweak the regexps again to make it accept the ^M.
--
Eric Botcazou
Hi Sasha,
On 04 Feb 17:59, Alexander Fomin wrote:
> OK for trunk and 5-branch?
Patch is OK for main trunk and release branches.
(IMHO, pretty much obvious).
--
Thanks, K
75 matches
Mail list logo
