On 02/18/2016 08:39 PM, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00809.html
On 02/11/2016 02:58 PM, Martin Sebor wrote:
The more than decennnial rtl-optimization/19705 - -fno-branch-count-reg
doesn't prevent decrement and branch instructions on a count register
p
On 02/17/2016 10:18 AM, Jakub Jelinek wrote:
Hi!
The following testcase works unless -save-temps or ccache is used
(or manually performing -E and compilation separately). The problem
is that #pragma cilk grainsize is supposed to have macro expansion
(except for the grainsize keyword), but we we
PR 49095 requested the following optimization:
- movl-120(%rax), %ecx
- leal-1(%rcx), %edx
- movl%edx, -120(%rax)
- testl %edx, %edx
+ subl$1, -120(%rax)
jne .L92
The PR was fixed by adding a peephole, but it doesn't actually trigger
f
On 02/17/2016 09:06 AM, Kyrill Tkachov wrote:
Hi all,
I've thought about this check a bit more and I think we can compactly
auto-generate checks
for any aarch64 architecture extension support in the assembler.
This is done in a similar way we autogenerate the arm_arch_*_ok checks
for arm.
So in
On Mon, Nov 16, 2015 at 3:56 PM, Pedro Alves wrote:
> On 11/10/2015 01:10 PM, Jonathan Wakely wrote:
>> On 06/11/15 09:59 +, Pedro Alves wrote:
>>> On 11/06/2015 01:56 AM, Jonathan Wakely wrote:
On 5 November 2015 at 23:31, Daniel Gutson
>>>
> The issue is, as I understand it, to do t
In this PR, we generate unnecessarily bad code for code that declares a
global register var. Since global regs get added to fixed_regs, IRA
never considers them as candidates. However, we do seem to have proper
data flow information for them. In the testcase, the global reg dies,
some operation
On 02/17/2016 07:24 AM, Nick Clifton wrote:
Hi Guys,
Redefining a previously defined static function as both public and
weak triggers an ICE in ipa-visibility.c:
internal compiler error: in function_and_variable_visibility, at
ipa-visibility.c:518
This bug has been discussed and patc
On 02/16/2016 08:24 AM, 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-p
On 02/16/2016 11:43 AM, Bin Cheng wrote:
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 canonical
On Fri, 19 Feb 2016, Martin Sebor wrote:
> > ... Here I'd like to get my updated patch reviewed so that I
> > can move on to my other GCC 6 tasks.
>
> I integrated the documentation update into the coding patch for bug
> 69780 - [4.9/5/6 Regression] ICE on __builtin_alloca_with_align, to
> keep t
On 2/13/2016 8:00 PM, David Wohlferd wrote:
Fair enough. Committing what we can right now sounds like a good plan.
Attached is the doc patch, minus the proposed warning.
ChangeLog:
2016-02-19 David Wohlferd
Bernd Schmidt
* doc/extend.texi: Doc basic asm behavior re clobbers
Keith Seitz reported we were missing debug information for cdtors.
E.g., we emit a specification for the unified ctor and dtor, but then,
if we emit one of the in-charge and not-in-charge versions as an alias
to the other, from the debug info PoV it's as if one of them didn't
exist. If we emit dec
My change to tsubst_pack_expansion to handle the special case of T...
revealed a latent bug whereby we were considering the trailing "void"
when comparing two variadic templates. When we then try to deduce one
from the other we get a parameter of type "void", which results in
substitution fail
Hi,
as almost expected r233572 needs to be back-ported to gcc-5 and gcc-4.9
branches in order to be built by gcc-6. It applies cleanly to both
branches. But unfortunately PR 69881 prevents boot-strapping gcc-4.9
in the moment.
Boot-strap and regression-test of gcc-5 on x86_64-pc-linux-gnu.
OK f
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 Vietnamese team of translators. The file is available at:
http://translationproject.org/latest/gcc/vi.po
(This file, 'gcc-6.1-b20160131.vi.po
101 - 115 of 115 matches
Mail list logo
