On Wed, Feb 3, 2016 at 9:11 PM, Jakub Jelinek wrote:
> Hi!
>
> On Tue, Feb 02, 2016 at 05:09:34PM +0300, Ilya Enkovich wrote:
>> And it's too late to do it after STV pass and therefore we disable it
>> when stack is not properly aligned. I think this argumentation goes in
>> a loop.
>
> This is a
On 01/04/2016 07:32 AM, Ajit Kumar Agarwal wrote:
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Wednesday, December 23, 2015 12:06 PM
To: Ajit Kumar Agarwal; Richard Biener
Cc: GCC Patches; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida;
Nagaraju Mekala
Subj
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 caused by a chain of events. The first is that
> the relatively new eipa_sra pass creates fake parameters that behave
> slightly d
On Fri, Jan 22, 2016 at 9:52 AM, Kyrill Tkachov
wrote:
> Hi all,
>
> As part of investigating the codegen effects of a fix for PR 65932 I found
> we assign
> too high a cost for the sign-extending multiply instruction SMULBB.
> This is because we add the cost of a multiply-extend but then also rec
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 the Linux kernel, so it's something that we really
> ought to fix. The problem stems from the fact that PROMOTE_MODE and
> TARGET_PROMOT
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 the Linux kernel, so it's something that we really
ought to fix. The problem stems from the
On 03/02/16 10:07, Kyrill Tkachov wrote:
On 03/02/16 09:51, Jakub Jelinek wrote:
On Wed, Feb 03, 2016 at 09:46:31AM +, Kyrill Tkachov wrote:
Hi Nick,
On 03/02/16 08:35, Nick Clifton wrote:
Hi Kyrill,
I would like to approve this patch, but cannot, since it is not ARM
specific. I
On Wed, Feb 03, 2016 at 11:41:02AM +, Alan Lawrence wrote:
> On 26/01/16 12:23, Dominik Vogt wrote:
> >On Mon, Dec 21, 2015 at 01:13:28PM +, Alan Lawrence wrote:
> >>...the test passes with --param sra-max-scalarization-size-Ospeed.
> >>
> >>Verified on aarch64 and with stage1 compiler for
On Thu, Feb 04, 2016 at 05:01:36PM +1100, Richard Henderson wrote:
> While attempting to write some code that uses the new x86 named address
> space support in gcc 6, I found that __typeof is very unhelpful. In
> particular, given
>
> int __seg_fs *ptr;
> __typeof(*ptr) obj;
>
> OBJ
Hi,
There is a performance regression caused by my previous change to
aarch64_legitimize_address, in which I forced constant offset out of memory ref
if the address expr is in the form of "reg1 + reg2 << scale + const". The
intention is to reveal as many loop-invariant opportunities as possible
On Thu, Feb 04, 2016 at 10:11:53AM +, Bin Cheng wrote:
> Hi,
> There is a performance regression caused by my previous change to
> aarch64_legitimize_address, in which I forced constant offset out of memory
> ref if the address expr is in the form of "reg1 + reg2 << scale + const".
> The intent
On 02/04/2016 06:01 AM, Richard Henderson wrote:
> While attempting to write some code that uses the new x86 named address space
> support in gcc 6, I found that __typeof is very unhelpful. In particular,
> given
>
> int __seg_fs *ptr;
> __typeof(*ptr) obj;
>
> OBJ will not be type
On Tue, Dec 15, 2015 at 10:59 AM, Wilco Dijkstra wrote:
> ping
>
>> -Original Message-
>> From: Wilco Dijkstra [mailto:wilco.dijks...@arm.com]
>> Sent: 19 November 2015 18:12
>> To: gcc-patches@gcc.gnu.org
>> Subject: [PATCH][ARM] Enable fusion of AES instructions
>>
>> Enable instruction
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 multiplication by
>>> reciprocal using vrecpe/vrecps
>>> with -funsa
On Thu, Feb 04, 2016 at 10:52:28AM +, Pedro Alves wrote:
> On 02/04/2016 06:01 AM, Richard Henderson wrote:
> > While attempting to write some code that uses the new x86 named address
> > space
> > support in gcc 6, I found that __typeof is very unhelpful. In particular,
> > given
> >
> >
On Mon, Jan 18, 2016 at 12:14 PM, Alan Lawrence wrote:
> This cleans up the neon_reinterpret code on ARM in a similar way to AArch64.
> Rather than a builtin backing onto an expander that emits a mov insn, we can
> just use a cast, because GCC defines casts of vector types as keeping the same
> bi
On Tue, Feb 02, 2016 at 06:21:04PM -0700, Martin Sebor wrote:
> gcc/cp/ChangeLog:
> 2016-02-02 Martin Sebor
>
> PR c++/69251
> PR c++/69253
> PR c++/69290
> PR c++/69277
> PR c++/69349
> * class.c (walk_subobject_offsets): Avoid testing the upper bound
>
On Wed, Feb 3, 2016 at 10:44 PM, Richard Henderson wrote:
> On 02/04/2016 07:30 AM, Richard Henderson wrote:
>>
>> On 02/04/2016 12:46 AM, Richard Biener wrote:
>>>
>>> As for a patch I'd repeatedly pondered on not stripping int <-> pointer
>>> conversions at all, similar to what STRIP_SIGN_NOPS d
> So this doesn’t fix aarch64, c6x, epiphany, ia64, iq2000, rs6000, rx, sparc,
> tilegx, tilepro or xtensa.
> :-( That’s one of the problems by having each port copy and paste swaths of
> :code from other ports to express the same thing instead of ports sharing
> :just one copy of code. My port i
return 0; }
>>> -} "-fsanitize=address"]
>>> +}]
>>> }
>>>
>>
>> This is just weird. What if fsanitize_address effective target is used
>> outside of asan/ (i.e. without asan_init first) ?
>
> It won't work, you als
On 04/02/16 11:04, Ramana Radhakrishnan wrote:
> On Mon, Jan 18, 2016 at 12:14 PM, Alan Lawrence wrote:
>> This cleans up the neon_reinterpret code on ARM in a similar way to AArch64.
>> Rather than a builtin backing onto an expander that emits a mov insn, we can
>> just use a cast, because GCC de
On Wed, Feb 03, 2016 at 05:34:17PM -0500, David Edelsohn wrote:
> On Wed, Feb 3, 2016 at 5:28 PM, Jakub Jelinek wrote:
> > Hi!
> >
> > rs6000_expand_atomic_compare_and_swap uses oldval directly in
> > a comparison instruction, but oldval might be a CONST_INT not suitable
> > for the instruction (s
On 04/02/16 09:53, Dominik Vogt wrote:
On Wed, Feb 03, 2016 at 11:41:02AM +, Alan Lawrence wrote:
On 26/01/16 12:23, Dominik Vogt wrote:
On Mon, Dec 21, 2015 at 01:13:28PM +, Alan Lawrence wrote:
...the test passes with --param sra-max-scalarization-size-Ospeed.
Verified on aarch64 an
tize_address effective target is used
>>> outside of asan/ (i.e. without asan_init first) ?
>>
>> It won't work, you also need various link flags that are part of
>> TEST_ALWAYS_FLAGS.
>
> That breaks gcc.dg/sancov/asan.c.
>
> Running /usr/local/gcc/gcc-20160204
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 German team of translators. The file is available at:
http://translationproject.org/latest/cpplib/de.po
(This file, 'cpplib-6.1-b20160131.
> +}]
>>>>> }
>>>>>
>>>>
>>>> This is just weird. What if fsanitize_address effective target is used
>>>> outside of asan/ (i.e. without asan_init first) ?
>>>
>>> It won't work, you also need various lin
A previous patch required -march=z13 in ssa-dom-cse-2.c for s390
and s390x, but actually only s390x really needs it. The attached
patch removes the extra option on s390 (and fixes comment
formatting).
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
gcc/testsuite/ChangeLog
* gcc.dg/
I spotted these two issues in real-world code when doing Fedora mass
rebuild. It's C++ and so I don't really know what I'm talking about;
Jon, could you please look at this?
Thanks,
Index: porting_to.html
===
RCS file: /cvs/gcc/wwwd
On 03/02/16 18:27, Ulrich Weigand wrote:
Marcin Kościelnicki wrote:
libgcc/ChangeLog:
* config.host: Use t-stack and t-stack-s390 for s390*-*-linux.
* config/s390/morestack.S: New file.
* config/s390/t-stack-s390: New file.
* generic-morestack.c (__splitstack_f
Uros Bizjak writes:
> OTOH, does this testcase even gets a chance to run?
It's not a runtime check.
Running /opt/gcc/gcc-20160204/gcc/testsuite/gcc.dg/sancov/sancov.exp ...
Executing on host: /opt/gcc/gcc-20160204/Build/gcc/xgcc
-B/opt/gcc/gcc-20160204/Build/gcc/ fsanitize_addres
On Thu, Feb 4, 2016 at 12:09 PM, Eric Botcazou wrote:
>> So this doesn’t fix aarch64, c6x, epiphany, ia64, iq2000, rs6000, rx, sparc,
>> tilegx, tilepro or xtensa.
>> :-( That’s one of the problems by having each port copy and paste swaths of
>> :code from other ports to express the same thing in
Andreas Schwab writes:
> Uros Bizjak writes:
>
>> 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/sancov/sancov.exp ...
Executing on host: /opt/gcc/gcc-20160203/Build/gcc/xgcc
On Thu, Feb 4, 2016 at 12:53 PM, Alan Lawrence
wrote:
> On 04/02/16 09:53, Dominik Vogt wrote:
>>
>> On Wed, Feb 03, 2016 at 11:41:02AM +, Alan Lawrence wrote:
>>>
>>> On 26/01/16 12:23, Dominik Vogt wrote:
On Mon, Dec 21, 2015 at 01:13:28PM +, Alan Lawrence wrote:
>
> ..
On Thu, Feb 4, 2016 at 1:49 PM, Richard Biener
wrote:
> On Thu, Feb 4, 2016 at 12:09 PM, Eric Botcazou wrote:
>>> So this doesn’t fix aarch64, c6x, epiphany, ia64, iq2000, rs6000, rx, sparc,
>>> tilegx, tilepro or xtensa.
>>> :-( That’s one of the problems by having each port copy and paste swat
On 04/02/16 13:37 +0100, Marek Polacek wrote:
I spotted these two issues in real-world code when doing Fedora mass
rebuild. It's C++ and so I don't really know what I'm talking about;
Jon, could you please look at this?
Thanks,
Index: porting_to.html
On Thu, Feb 04, 2016 at 01:01:10PM +, Jonathan Wakely wrote:
[...]
> After you mentioned this on IRC I wrote the following. I think yours
> is probably a bit simpler to read and so better, but is it worth
> taking the "unless a base class or member variable has a destructor
> that is noexcept(f
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/sancov/sancov.exp ...
> Executing on host: /opt/gcc/gcc-20160203
On Thu, Feb 4, 2016 at 6:33 AM, Alan Modra wrote:
> On Wed, Feb 03, 2016 at 05:34:17PM -0500, David Edelsohn wrote:
>> On Wed, Feb 3, 2016 at 5:28 PM, Jakub Jelinek wrote:
>> > Hi!
>> >
>> > rs6000_expand_atomic_compare_and_swap uses oldval directly in
>> > a comparison instruction, but oldval mi
On Thu, Feb 04, 2016 at 08:40:22AM -0500, David Edelsohn wrote:
> On Thu, Feb 4, 2016 at 6:33 AM, Alan Modra wrote:
> > On Wed, Feb 03, 2016 at 05:34:17PM -0500, David Edelsohn wrote:
> >> On Wed, Feb 3, 2016 at 5:28 PM, Jakub Jelinek wrote:
> >> > Hi!
> >> >
> >> > rs6000_expand_atomic_compare_a
Hi,
When running the regression testsuite for the AVR target, I noticed a
bunch of sso tests failing - turns out they assume sizeof(int) == 4.
This patch marks them UNSUPPORTED for targets that don't match that
assumption, by requiring effective-target int32.
A few tests still run and
On Fri, Jan 29, 2016 at 02:27:34PM +, Kyrill Tkachov wrote:
> Hi all,
>
> In this PR we ICE during combine when trying to propagate a comparison into a
> vec_duplicate,
> that is we end up creating the rtx:
> (vec_duplicate:V4SI (eq:CC_NZ (reg:CC_NZ 66 cc)
> (const_int 0 [0])))
>
> T
Hi all,
As part of the target attributes and pragmas support for GCC 6 I changed the
aarch64 port
to emit a .arch assembly directive for each function that describes the
architectural features
used by that function. This is a change from GCC 5 behaviour where we output a
single .arch directiv
On Thu, Feb 04, 2016 at 02:42:38PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 04, 2016 at 08:40:22AM -0500, David Edelsohn wrote:
> > On Thu, Feb 4, 2016 at 6:33 AM, Alan Modra wrote:
> > > On Wed, Feb 03, 2016 at 05:34:17PM -0500, David Edelsohn wrote:
> > >> On Wed, Feb 3, 2016 at 5:28 PM, Jakub
Should the libgo version number be updated?
On 02/03/2016 03:58 PM, Ian Lance Taylor wrote:
I've committed a patch to the libgo library to update it to Go 1.6rc1,
the first release candidate for the Go 1.6 release. As usual with
major libgo updates, the change is too large to include here. I'v
On 02/03/2016 10:07 PM, Patrick Palka wrote:
It just occurred to me that issuing this warning during template
instantiation may be undesirable if the dynamic_cast being built was
originally dependent (for the same reasons it is undesirable to issue
-Wuseless-cast warnings during instantiation, wh
On 02/03/2016 12:51 PM, Patrick Palka wrote:
+ && (integer_minus_onep (lhs)
+ || integer_minus_onep (rhs)))
Let's use null_member_pointer_value_p here.
Please add pointers to member functions to the testcase.
Jason
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The attached patch corrects some errors in documentation of the --param
option to gcc. Mostly they are corrections to the names of options,
but two parameters are documented which do not exist in trunk.
gcc/ChangeLog:
* doc/invoke.texi (Optim
Hi All,
Here is a patch that cures the issues with non-correct vuse for scalar
statements during code motion, i.e. if vuse of scalar statement is
vdef of masked store which has been sunk to new basic block, we must
fix it up. The patch also fixed almost all remarks pointed out by
Jacub.
Bootstra
Hi!
On Fri, 22 Jan 2016 14:31:35 +0100, Bernd Schmidt wrote:
> On 01/22/2016 02:25 PM, Jakub Jelinek wrote:
>
> > What about #pragma oacc parallel? That would never do that?
>
> It shouldn't, no (IMO).
Correct.
Here is the patch re-worked for trunk. Instead of passing
-foffload-force in th
On Feb 4, 2016, at 5:46 AM, Senthil Kumar Selvaraj
wrote:
> When running the regression testsuite for the AVR target, I noticed a
> bunch of sso tests failing
> If this patch is ok, could someone commit please?
The patch is Ok.
I don’t recall a target supports for I/O. So, I/O is incredible
Marcin KoÅcielnicki wrote:
> Ugh. I take that back. For -fPIC, the load-address sequence is:
>
> larl%r1,f@GOTENT
> lg %r2,0(%r1)
> br %r14
This is correct.
> And (sibling) call sequence is:
>
> larl%r1,f@GOTENT
> lg %r1,0(%
The jit testsuite was showing numerous segfaults and fatal
errors for trunk on aarch64; typically on the 2nd iteration of each
test, with errors like:
test-volatile.c.exe: fatal error: pass ‘rnreg’ not found but is referenced by
new pass ‘whole-program’
where the new pass' name varies, and can be
On 04/02/16 16:06, Ulrich Weigand wrote:
Marcin Kościelnicki wrote:
Ugh. I take that back. For -fPIC, the load-address sequence is:
larl%r1,f@GOTENT
lg %r2,0(%r1)
br %r14
This is correct.
And (sibling) call sequence is:
larl%r1,f
On 02/04/2016 04:05 AM, Jakub Jelinek wrote:
On Tue, Feb 02, 2016 at 06:21:04PM -0700, Martin Sebor wrote:
gcc/cp/ChangeLog:
2016-02-02 Martin Sebor
PR c++/69251
PR c++/69253
PR c++/69290
PR c++/69277
PR c++/69349
* class.c (walk_subobject_offs
On Thu, Feb 4, 2016 at 9:24 AM, Jason Merrill wrote:
> On 02/03/2016 12:51 PM, Patrick Palka wrote:
>>
>> + && (integer_minus_onep (lhs)
>> + || integer_minus_onep (rhs)))
>
>
> Let's use null_member_pointer_value_p here.
Done.
>
> Please add pointers to member functions to t
On Thu, Feb 04, 2016 at 10:31:27AM -0500, David Malcolm wrote:
> The jit testsuite was showing numerous segfaults and fatal
> errors for trunk on aarch64; typically on the 2nd iteration of each
> test, with errors like:
> test-volatile.c.exe: fatal error: pass ‘rnreg’ not found but is referenced
On 02/04/2016 10:02 PM, Marek Polacek wrote:
Do we need matching __auto_type variants?
I think at present __auto_type removes the qualifiers from atomic types only,
but I'd hope we can just adjust __auto_type to always strip the qualifiers,
not introduce __auto_type_noqual...
Exactly what I w
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 the PC32DBL choices. There a
On 02/04/2016 09:09 PM, Marek Polacek wrote:
We've already been asked to add something like __typeof_noqual, e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985#c3 . In a similar PR,
I wanted to modify __typeof to drop all qualifiers, but Joseph suggested
instead to add a new typeof variant:
On 02/04/2016 10:32 AM, Martin Sebor wrote:
FWIW, I keep having trouble with the repository. Git doesn't
work to check things in at all
The instructions here aren't working for you?
https://gcc.gnu.org/wiki/GitMirror#Commit_upstream_.28git-svn.29
and I have only one svn repository
that does
On 02/04/2016 10:32 AM, Patrick Palka wrote:
On Thu, Feb 4, 2016 at 9:24 AM, Jason Merrill wrote:
On 02/03/2016 12:51 PM, Patrick Palka wrote:
+ && (integer_minus_onep (lhs)
+ || integer_minus_onep (rhs)))
Let's use null_member_pointer_value_p here.
Done.
Please ad
This patch fixes a problem introduced with the GPR into FPR slot save
feature for leaf functions.
r6 is argument register as well as call-saved. Currently we might
decide that it will be a candidate for being saved into an FPR. If it
turns out later that r6 also needs to be saved due to being re
On 02/04/2016 09:38 AM, Jason Merrill wrote:
On 02/04/2016 10:32 AM, Martin Sebor wrote:
FWIW, I keep having trouble with the repository. Git doesn't
work to check things in at all
The instructions here aren't working for you?
https://gcc.gnu.org/wiki/GitMirror#Commit_upstream_.28git-svn.29
On Thu, Feb 04, 2016 at 05:46:27PM +0300, Yuri Rumyantsev wrote:
> Here is a patch that cures the issues with non-correct vuse for scalar
> statements during code motion, i.e. if vuse of scalar statement is
> vdef of masked store which has been sunk to new basic block, we must
> fix it up. The pat
On 02/04/2016 04:14 PM, Richard Henderson wrote:
> On 02/04/2016 10:02 PM, Marek Polacek wrote:
>>> Do we need matching __auto_type variants?
>>
>> I think at present __auto_type removes the qualifiers from atomic types only,
>> but I'd hope we can just adjust __auto_type to always strip the qualif
On Thu, Feb 4, 2016 at 5:50 AM, Kyrill Tkachov
wrote:
> Hi all,
>
> As part of the target attributes and pragmas support for GCC 6 I changed the
> aarch64 port
> to emit a .arch assembly directive for each function that describes the
> architectural features
> used by that function. This is a cha
On 04/02/16 17:12, Andrew Pinski wrote:
On Thu, Feb 4, 2016 at 5:50 AM, Kyrill Tkachov
wrote:
Hi all,
As part of the target attributes and pragmas support for GCC 6 I changed the
aarch64 port
to emit a .arch assembly directive for each function that describes the
architectural features
used b
In this PR, we have, at an intermediate stage during LRA (before
create_cands):
(insn 420 (set (reg:HI 276 [orig:132 g.2_118 ] [132])
(reg:HI 132 [ g.2_118 ])) 88 {*movhi_internal}
(nil))
[]
(insn 436 (set (reg/v:HI 290 [orig:87 g ] [87])
(reg/v:HI 87 [ g ]))
(insn 14 (
On Thu, Feb 4, 2016 at 11:57 AM, Jason Merrill wrote:
> On 02/04/2016 10:32 AM, Patrick Palka wrote:
>>
>> On Thu, Feb 4, 2016 at 9:24 AM, Jason Merrill wrote:
>>>
>>> On 02/03/2016 12:51 PM, Patrick Palka wrote:
+ && (integer_minus_onep (lhs)
+ || integer_
On Thu, Feb 4, 2016 at 12:24 PM, Patrick Palka wrote:
> On Thu, Feb 4, 2016 at 11:57 AM, Jason Merrill wrote:
>> On 02/04/2016 10:32 AM, Patrick Palka wrote:
>>>
>>> On Thu, Feb 4, 2016 at 9:24 AM, Jason Merrill wrote:
On 02/03/2016 12:51 PM, Patrick Palka wrote:
>
>
> +
On Feb 4, 2016, at 7:32 AM, Martin Sebor wrote:
> FWIW, I keep having trouble with the repository.
> $ svn switch --relocate svn://gcc.gnu.org/svn/gcc
> svn+ssh://mse...@gcc.gnu.org/svn/gcc
> svn: E170013: Unable to connect to a repository at URL
> 'svn+ssh://mse...@gcc.gnu.org/svn/gcc/trunk'
>
On 02/04/2016 10:39 AM, Mike Stump wrote:
On Feb 4, 2016, at 7:32 AM, Martin Sebor wrote:
FWIW, I keep having trouble with the repository.
$ svn switch --relocate svn://gcc.gnu.org/svn/gcc
svn+ssh://mse...@gcc.gnu.org/svn/gcc
svn: E170013: Unable to connect to a repository at URL
'svn+ssh:
On Thu, 2016-02-04 at 12:09 +0100, Eric Botcazou wrote:
> > So this doesn’t fix aarch64, c6x, epiphany, ia64, iq2000, rs6000, rx, sparc,
> > tilegx, tilepro or xtensa.
> > :-( That’s one of the problems by having each port copy and paste swaths of
> > :code from other ports to express the same thi
On 02/04/2016 12:24 PM, Patrick Palka wrote:
On Thu, Feb 4, 2016 at 11:57 AM, Jason Merrill wrote:
On 02/04/2016 10:32 AM, Patrick Palka wrote:
On Thu, Feb 4, 2016 at 9:24 AM, Jason Merrill wrote:
On 02/03/2016 12:51 PM, Patrick Palka wrote:
+ && (integer_minus_onep (lhs)
+
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 the L
On Feb 4, 2016, at 10:23 AM, Martin Sebor wrote:
> Yes, I sure did! (But no, it wasn't obvious to me. I recently
> upgraded this machine and did it differently than I normally do,
> so things are, well, different than I expected. FWIW, it would
> be nice to mention this as the first step at the
On Thu, Feb 4, 2016 at 12:02 AM, Uros Bizjak wrote:
> On Wed, Feb 3, 2016 at 9:11 PM, Jakub Jelinek wrote:
>> Hi!
>>
>> On Tue, Feb 02, 2016 at 05:09:34PM +0300, Ilya Enkovich wrote:
>>> And it's too late to do it after STV pass and therefore we disable it
>>> when stack is not properly aligned.
Hello!
After PR rtl-optimization/69577 fix went in, it looks that we can
remove various kludges involving SSE and MMX register classes from
ix86_cannot_change_mode_class.
2016-02-04 Uros Bizjak
PR rtl-optimization/69577
Revert:
2015-10-29 Richard Henderson
PR target/68124
Hi!
As discussed on IRC and in the PR, get_ref_base_and_extent has
a big while (1) which can be only left with goto done;, so code
in between the end of that loop and the done: label is unreachable.
If the base is *MEM_REF, we already set maxsize to -1, and for decls
it really shouldn't be needed,
Hi!
If an enum has mode attribute, then finish_enum uses the precision
from its mode (and complains if the enumerators don't fit into that
precision), but will use TYPE_{MIN,MAX}_VALUE from int's precision instead.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
Hi!
As mentioned in the PR, it seems reshape_init isn't prepared to be called
on the result of earlier reshape_init call, but since the recent Paolo's
changes expand_default_init can call it the second time.
The following patch attempts to narrow it down to the case where it
has not been called y
Adding forgotten CCs...
On Thu, Feb 4, 2016 at 8:49 PM, Uros Bizjak wrote:
> Hello!
>
> After PR rtl-optimization/69577 fix went in, it looks that we can
> remove various kludges involving SSE and MMX register classes from
> ix86_cannot_change_mode_class.
>
> 2016-02-04 Uros Bizjak
>
> PR
On Wed, Feb 03, 2016 at 10:13:21PM -0500, Vladimir Makarov wrote:
> Thanks, Mike. I found it when trying to fix numerous LRA failures
> on power8. Reload pass when can not figure out what to do with
> illegitimate address does nothing. LRA tried still to do something.
> I've made LRA working as
The attached patch implements the changes to the warning we
discussed in IRC yesterday.
With the patch GCC is by default silent about the test case in
bug 69662 and diagnoses it only with -Wplacement-new=2. Arrays
of other sizes and statically allocated objects are diagnosed
as before.
Tested o
On 02/04/2016 12:17 PM, Bernd Schmidt wrote:
In this PR, we have, at an intermediate stage during LRA (before
create_cands):
(insn 420 (set (reg:HI 276 [orig:132 g.2_118 ] [132])
(reg:HI 132 [ g.2_118 ])) 88 {*movhi_internal}
(nil))
[]
(insn 436 (set (reg/v:HI 290 [orig:87 g ]
Richard Biener writes:
> On Thu, Feb 4, 2016 at 12:09 PM, Eric Botcazou wrote:
>>> So this doesn’t fix aarch64, c6x, epiphany, ia64, iq2000, rs6000, rx, sparc,
>>> tilegx, tilepro or xtensa.
>>> :-( That’s one of the problems by having each port copy and paste swaths of
>>> :code from other port
This patch fixes a bug where LRA would abort when compiling a C++ program with
-mlra. I tracked this down to using the "ws" constraint for TFmode, TDmode,
and IFmode, but those types are limited to just the traditional floating point
registers (ws on power8 targets all of the VSX registers).
With
On 02/05/2016 07:07 AM, Uros Bizjak wrote:
Adding forgotten CCs...
On Thu, Feb 4, 2016 at 8:49 PM, Uros Bizjak wrote:
Hello!
After PR rtl-optimization/69577 fix went in, it looks that we can
remove various kludges involving SSE and MMX register classes from
ix86_cannot_change_mode_class.
201
On Thu, Feb 4, 2016 at 3:39 PM, Michael Meissner
wrote:
> This patch fixes a bug where LRA would abort when compiling a C++ program with
> -mlra. I tracked this down to using the "ws" constraint for TFmode, TDmode,
> and IFmode, but those types are limited to just the traditional floating point
>
On 02/04/2016 10:07 PM, Richard Biener wrote:
On Wed, Feb 3, 2016 at 10:44 PM, Richard Henderson wrote:
On 02/04/2016 07:30 AM, Richard Henderson wrote:
On 02/04/2016 12:46 AM, Richard Biener wrote:
As for a patch I'd repeatedly pondered on not stripping int <-> pointer
conversions at all,
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
+ the actual size of a flexible array member used as the buffer passed
+ as OPER to placem
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
+ the actual size of a flexible array member use
On Thu, 4 Feb 2016, Jakub Jelinek wrote:
> Hi!
>
> If an enum has mode attribute, then finish_enum uses the precision
> from its mode (and complains if the enumerators don't fit into that
> precision), but will use TYPE_{MIN,MAX}_VALUE from int's precision instead.
>
> Fixed thusly, bootstrapped
Some minor doc updates.
Committed to trunk.
commit e7a4324d0f8bb8bd622e1412b7daf8b8a2d91430
Author: Jonathan Wakely
Date: Thu Feb 4 21:41:31 2016 +
Update copyright years in libstdc++ manual and add link
* doc/xml/manual/containers.xml: Add cross-reference to Dual ABI.
On February 4, 2016 8:50:58 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>As discussed on IRC and in the PR, get_ref_base_and_extent has
>a big while (1) which can be only left with goto done;, so code
>in between the end of that loop and the done: label is unreachable.
>If the base is *MEM_REF, we
On February 4, 2016 10:04:47 PM GMT+01:00, Richard Henderson
wrote:
>On 02/04/2016 10:07 PM, Richard Biener wrote:
>> On Wed, Feb 3, 2016 at 10:44 PM, Richard Henderson
>wrote:
>>> On 02/04/2016 07:30 AM, Richard Henderson wrote:
On 02/04/2016 12:46 AM, Richard Biener wrote:
>
Hello world,
For a type 'foo', we use a symtree 'Foo'. This led to accept-invalid
when a variable name was already declared as a type. This rather
self-explanatory patch fixes that.
Regression-tested. OK for trunk and 5? (Do we still care about 4.9?)
Regards
Thomas
2016-02-03 Tho
On February 4, 2016 9:28:22 PM GMT+01:00, Richard Sandiford
wrote:
>Richard Biener writes:
>> On Thu, Feb 4, 2016 at 12:09 PM, Eric Botcazou
> wrote:
So this doesn’t fix aarch64, c6x, epiphany, ia64, iq2000, rs6000,
>rx, sparc,
tilegx, tilepro or xtensa.
:-( That’s one of the pro
On Thu, 28 Jan 2016, Jonathan Wakely wrote:
> On 27/01/16 19:49 -0500, John David Anglin wrote:
>> The attached patch fixes a stage1 build error compiling genautomata.c
>> on hpux. We need to test for obsolete XOPEN declarations of isinf and
>> isnan on hpux. Further, we need to check individua
On 02/04/2016 07:42 AM, Jeremy Bennett wrote:
The attached patch corrects some errors in documentation of the --param
option to gcc. Mostly they are corrections to the names of options,
but two parameters are documented which do not exist in trunk.
gcc/ChangeLog:
* doc/invoke.texi (Opt
1 - 100 of 116 matches
Mail list logo
