Hi,
I committed the attached patch as obvious to trunk after the RM
considered it OK in the PR.
Index: runtime/main.c
===
--- runtime/main.c (revision 183089)
+++ runtime/main.c (working copy)
@@ -116,8 +116,10 @@ store_exe
Ping 3? It's been months with no feedback...
> Ping 2 ?
>
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02555.html
This patch to the Go frontend changes it to use the backend interface to
determine type size and alignment information. This is a preliminary to
a patch adjusting the handling of struct comparison, which will follow.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainl
Here build_base_path expects that the binfo argument will designate a
subobject of the expression argument, but that isn't the case here
because the base is ambiguous. So let's complain about that instead of
aborting.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 640c9c1f2824490323a8d
On Jan 10, 2012, at 14:28, Eric Botcazou wrote:
> 2012-01-10 Eric Botcazou
>
> * gimple.h (gimplify_body): Remove first argument.
> * gimplify.c (copy_if_shared): Add DATA argument. Do not create the
> pointer set here, instead just pass DATA to walk_tree.
The new void *da
On Tue, Jan 10, 2012 at 8:33 AM, Jason Merrill wrote:
> Sometimes an expression that is non-constant at one point in the translation
> unit can become constant later, when a constexpr function is defined. So
> let's not cache failure.
>
> Tested x86_64-pc-linux-gnu, applying to trunk. This isn't
http://codereview.appspot.com/5535046/diff/1/gcc/config/i386/i386.c
File gcc/config/i386/i386.c (right):
http://codereview.appspot.com/5535046/diff/1/gcc/config/i386/i386.c#newcode26032
gcc/config/i386/i386.c:26032: +M_AMDFAM15,
Maybe better to change 10 to 10H, and 15 to 15H in the name as
On 01/11/2012 06:28 AM, Eric Botcazou wrote:
> 2012-01-10 Eric Botcazou
>
> * gimple.h (gimplify_body): Remove first argument.
> * gimplify.c (copy_if_shared): Add DATA argument. Do not create the
> pointer set here, instead just pass DATA to walk_tree.
> (unshare_body)
On Tue, Jan 10, 2012 at 09:19:54PM +0100, Eric Botcazou wrote:
> > 2012-01-10 Jakub Jelinek
> >
> > PR bootstrap/51796
> > * combine.c (distribute_notes): If i3 is a noreturn call,
> > allow old_size to be equal to args_size.
>
> Wouldn't all the (potential) callers of fixup_args_si
On Tue, Jan 10, 2012 at 3:33 PM, Andrew Pinski wrote:
> On Tue, Jan 10, 2012 at 3:31 PM, Diego Novillo wrote:
>> On 12-01-10 17:11 , Sriraman Tallam wrote:
>>>
>>> This patch adds a new target builtin, __builtin_cpu_is_amdfam15, to check
>>> for AMD Family 15h processors.
>>>
>>> * i386-cp
On 12-01-10 18:33 , Andrew Pinski wrote:
On Tue, Jan 10, 2012 at 3:31 PM, Diego Novillo wrote:
On 12-01-10 17:11 , Sriraman Tallam wrote:
This patch adds a new target builtin, __builtin_cpu_is_amdfam15, to check
for AMD Family 15h processors.
* i386-cpuinfo.c (__cpu_is_amdfam15): New
On Tue, Jan 10, 2012 at 3:31 PM, Diego Novillo wrote:
> On 12-01-10 17:11 , Sriraman Tallam wrote:
>>
>> This patch adds a new target builtin, __builtin_cpu_is_amdfam15, to check
>> for AMD Family 15h processors.
>>
>> * i386-cpuinfo.c (__cpu_is_amdfam15): New member in __cpu_model
>> struc
On 12-01-10 17:11 , Sriraman Tallam wrote:
This patch adds a new target builtin, __builtin_cpu_is_amdfam15, to check for
AMD Family 15h processors.
* i386-cpuinfo.c (__cpu_is_amdfam15): New member in __cpu_model struct.
(get_amd_cpu): Check for family 15h processors.
(cp
On 01/10/2012 11:55 PM, Jayant R. Sonar wrote:
> PING 9: For reviewing the modified CR16 port.
>
> Hello,
>
> Can some one please review the updated patch and let me know if any more
> changes are required to be done in it?
>
> Rainer had suggested few important changes last time. After making
On Tue, 2012-01-10 at 09:42 -0600, William J. Schmidt wrote:
>
> On Tue, 2012-01-10 at 14:53 +0100, Richard Guenther wrote:
> >
> > Btw, this will also disqualify any point below
> >
> > if (__builtin_constant_p (...))
> >{
> > ...
> >}
> >
> > because after the if join all BBs ar
This patch adds a new target builtin, __builtin_cpu_is_amdfam15, to check for
AMD Family 15h processors.
* i386-cpuinfo.c (__cpu_is_amdfam15): New member in __cpu_model struct.
(get_amd_cpu): Check for family 15h processors.
(cpu_indicator_init): Adjust model and family fo
On 01/11/2012 12:43 AM, Torvald Riegel wrote:
>> One could steal code from bohem-gc for this.
>> See GC_get_stack_base in os_dep.c.
>
> Thanks for the pointer. I looked at this code, and it seems fairly
> complex given the dependencies on OS/libc and OS/libc behavior. From a
> maintenance point-
> 2012-01-10 Jakub Jelinek
>
> PR bootstrap/51796
> * combine.c (distribute_notes): If i3 is a noreturn call,
> allow old_size to be equal to args_size.
Wouldn't all the (potential) callers of fixup_args_size_notes need to do the
same kind of scanning? IOW, shouldn't this be
On Tuesday 10 January 2012 15:40:15 Richard Guenther wrote:
> On Tue, Jan 10, 2012 at 3:38 PM, Richard Guenther
> wrote:
>> On Tue, Jan 10, 2012 at 3:14 PM, Tijl Coosemans wrote:
>>> On targets where libc implements stack protector functions (GNU libc,
>>> FreeBSD libc), and where gcc (as an opti
This is a regression present on the mainline. The compiler crashes during the
function unnesting pass because of an out-of-context temporary, but the root
cause of the problem is incorrect sharing of a tree node. The problem has
probably been latent since gimplification was devised: while the
This is a couple of regressions present on the mainline. For the first
testcase at O2 -gnatn:
+===GNAT BUG DETECTED==+
| 4.7.0 20120102 (experimental) [trunk revision 182780] (i586-suse-linux) GCC
error:|
| in assign_stack_temp_for_type, at fun
Hi!
My recent patch which adds REG_ARGS_SIZE note to all
!ACCUMULATE_OUTGOING_ARGS noreturn calls introduced a regression,
the checking code in distribute_notes can ICE if something
is combned with the noreturn call and the noreturn call has
the same REG_ARGS_SIZE value as before.
Fixed thusly, bo
On 01/03/2012 04:25 AM, Revital1 Eres wrote:
Attached is an updated version with the two changes mentioned above taken
from the previous patch.
Tested and bootstrap with the other patch in the series on
ppc64-redhat-linux, enabling SMS on loops with SC 1.
Thanks again,
Revital
IRA changes a
On 12/29/2011 06:41 AM, Igor Zamyatin wrote:
Ilya is on vacation so I'll make the answer.
Overall score became worse on 0.3%.
Ok, thanks. It is in the range of measure error for some processors.
But Intel processors range is pretty small.
Did you use Atom for measuring?
I'll try to find a
of course your new version.
thanks,
David
On Tue, Jan 10, 2012 at 1:31 AM, Richard Guenther wrote:
> On Mon, 9 Jan 2012, Xinliang David Li wrote:
>
>> It looks non-ambiguous to me.
>
> The new proposed version or the old?
>
> Richard.
>
>> David
>>
>> On Mon, Jan 9, 2012 at 1:05 AM, Richard Gue
Keith pointed out that my demangler changes changed the demangling of
overloaded operator delete; this patch corrects that.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit ee8af40f38391d44549cf96b159dcb00821c2074
Author: Jason Merrill
Date: Tue Jan 10 11:16:46 2012 -0500
* cp-dem
On Jan 4, 2012, Jakub Jelinek wrote:
> Unfortunately from time to time we do generate them, I hope Alex will
> look at how to prevent that from happening at var-tracking time, but
> still this isn't something we should assert on.
I've spent some time looking into this. I could avoid the huge
e
On 01/09/2012 07:45 AM, Bernd Schmidt wrote:
On 12/23/2011 12:46 PM, Richard Sandiford wrote:
In the end I tried an ad-hoc approach in an attempt to do something
about (2), (3) and (4b). The idea was to construct a preliminary
"model" schedule in which the only objective is to keep register
pre
On 12/28/2011 08:51 AM, Richard Sandiford wrote:
Vladimir Makarov writes:
In the end I tried an ad-hoc approach in an attempt to do something
about (2), (3) and (4b). The idea was to construct a preliminary
"model" schedule in which the only objective is to keep register
pressure to a minimum.
On Tue, 10 Jan 2012, Richard Guenther wrote:
> There is none :/ STRICT_ALIGNMENT would need to get a mode argument,
The version of STRICT_ALIGNMENT with a mode argument is
SLOW_UNALIGNED_ACCESS (from GCC's perspective, there isn't much difference
between "unaligned accesses don't work at all"
On Tue, 10 Jan 2012, Jayant R. Sonar wrote:
> PING 9: For reviewing the modified CR16 port.
>
> Hello,
>
> Can some one please review the updated patch and let me know if any more
> changes are required to be done in it?
>
> Rainer had suggested few important changes last time. After making th
On Tue, 10 Jan 2012, Richard Guenther wrote:
> This fixes LTO not honoring -Werror (similar for all other
> non-C-family frontends), despite handling -Werror= just fine.
> The issue is that the diagnostic context is only adjusted from
> the c-family handle-options routine, not from the common
> on
On Tue, 2012-01-10 at 14:53 +0100, Richard Guenther wrote:
> On Tue, Jan 10, 2012 at 2:43 PM, William J. Schmidt
> wrote:
> > Greetings,
> >
> > This patch follows Richard Guenther's suggestion of 2011-07-05 in
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49642 to fix the problem in
> > gcc 4
This fixes a typo in the atomic_compare_and_swap_1 pattern.
Tested on m68k-linux.
Andreas.
2012-01-10 Andreas Schwab
* config/m68k/sync.md ("atomic_compare_and_swap_1"): Fix
operand number.
Index: gcc/config/m68k/sync.md
===
On Tue, Jan 10, 2012 at 3:38 PM, Richard Guenther
wrote:
> On Tue, Jan 10, 2012 at 3:14 PM, Tijl Coosemans wrote:
>> On targets where libc implements stack protector functions (GNU libc,
>> FreeBSD libc), and where gcc (as an optimisation) generates calls to
>> a locally defined __stack_chk_fail_
On Tue, Jan 10, 2012 at 3:14 PM, Tijl Coosemans wrote:
> On targets where libc implements stack protector functions (GNU libc,
> FreeBSD libc), and where gcc (as an optimisation) generates calls to
> a locally defined __stack_chk_fail_local instead of directly calling
> the global function __stack
Sometimes an expression that is non-constant at one point in the
translation unit can become constant later, when a constexpr function is
defined. So let's not cache failure.
Tested x86_64-pc-linux-gnu, applying to trunk. This isn't a regression,
but as before, since C++11 support is still e
On Tue, 2012-01-10 at 16:35 +1100, Richard Henderson wrote:
> On 01/09/2012 06:26 AM, Torvald Riegel wrote:
> > libitm: Filter out undo writes that overlap with the libitm stack.
> >
> > libitm/
> > * config/generic/tls.h (GTM::mask_stack_top,
> > GTM::m
bkoz pointed out that I forgot to update invoke.texi about
-fabi-version=6. Applying to trunk
commit f94b7ea86ad3146e81a46a141ac23b10048b7fbf
Author: Jason Merrill
Date: Mon Jan 9 23:03:15 2012 -0500
* doc/invoke.texi (C++ Dialect Options): Update -fabi-version=6
information.
diff
On targets where libc implements stack protector functions (GNU libc,
FreeBSD libc), and where gcc (as an optimisation) generates calls to
a locally defined __stack_chk_fail_local instead of directly calling
the global function __stack_chk_fail (e.g. -fpic code on i386), one
must explicitly specify
On Tue, Jan 10, 2012 at 2:43 PM, William J. Schmidt
wrote:
> Greetings,
>
> This patch follows Richard Guenther's suggestion of 2011-07-05 in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49642 to fix the problem in
> gcc 4.6. It prevents choosing a function split point that is dominated
> by a b
Greetings,
This patch follows Richard Guenther's suggestion of 2011-07-05 in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49642 to fix the problem in
gcc 4.6. It prevents choosing a function split point that is dominated
by a builtin call to __builtin_constant_p.
The bug was marked fixed in 4.7 s
Committed.
Richard.
2012-01-10 Richard Guenther
PR tree-optimization/51801
* gcc.dg/torture/pr51801.c: New testcase.
Index: gcc/testsuite/gcc.dg/torture/pr51801.c
===
--- gcc/testsuite/gcc.dg/torture/pr51801.c
On Fri, 6 Jan 2012, Martin Jambor wrote:
> Hi,
>
> I'm trying to teach our expander how to deal with misaligned MEM_REFs
> on strict alignment targets. We currently generate code which leads
> to bus error signals due to misaligned accesses.
>
> I admit my motivation is not any target in partic
On 01/10/2012 10:14 AM, Richard Guenther wrote:
On Mon, 9 Jan 2012, Tobias Grosser wrote:
On 01/09/2012 04:34 PM, Richard Guenther wrote:
This fixes the 2nd P1 ICE.
There is a disconnect on how we analyze data-references during SCOP
detection
(outermost_loop is the root of the loop tree) and
PING 9: For reviewing the modified CR16 port.
Hello,
Can some one please review the updated patch and let me know if any more
changes are required to be done in it?
Rainer had suggested few important changes last time. After making those
changes, the modified patch was posted at following URL:
This fixes LTO not honoring -Werror (similar for all other
non-C-family frontends), despite handling -Werror= just fine.
The issue is that the diagnostic context is only adjusted from
the c-family handle-options routine, not from the common
one (which does process -Werror= though).
Bootstrapped a
Hi Gerald,
On 01/10/2012 12:31 PM, Gerald Pfeifer wrote:
@item Generic interface name, which have the same name as derived types,
"interface names", perhaps?
Well spotted - and corrected with the patched patch (Rev. 183062).
Thanks,
Tobias
Index: gcc/fortran/gfortran.texi
==
On Mon, 9 Jan 2012, Steve Kargl wrote:
> @item Generic interface name, which have the same name as derived types,
"interface names", perhaps?
Gerald
2012/1/10 Richard Guenther :
> On Tue, Jan 10, 2012 at 10:58 AM, Kai Tietz wrote:
>> Ping
>>
>> 2012/1/8 Kai Tietz :
>>> Hi,
>>>
>>> this patch makes sure that for increment of
>>> postfix-increment/decrement we use also orignal lvalue instead of tmp
>>> lhs value for increment. This fixes report
Dear All,
Sorry for breaking the thread on this one.
The patch below is OK for trunk, minus the fragment in
'get_declared_from_expr' from one of my patches :-)
Cheers
Paul
---
Rather simple patch.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
The parameter type for Shift_Left (etc.) intrinsics is required to have 'Size =
8, 16, 32, or 64 bits, but the compiler failed to check this rule. This patch
checks the rule.
The following test should get a compile-time error.
gnatmake -f -q shift_test.adb
shift_test.adb:4:27: first argument for
Hello,
The patch below fixes ICE reported in PR51794.
It avoids creating DDG edges for register uses of class DF_REF_ARTIFICIAL
as
the latter does not have real instructions for them and thus calling
BLOCK_FOR_INSN fails.
Tested and bootstrap on ppc64-redhat-linux, enabling SMS on loops with SC
On Tue, Jan 10, 2012 at 10:58 AM, Kai Tietz wrote:
> Ping
>
> 2012/1/8 Kai Tietz :
>> Hi,
>>
>> this patch makes sure that for increment of
>> postfix-increment/decrement we use also orignal lvalue instead of tmp
>> lhs value for increment. This fixes reported issue about sequence
>> point in PR/
Ping
2012/1/8 Kai Tietz :
> Hi,
>
> this patch makes sure that for increment of
> postfix-increment/decrement we use also orignal lvalue instead of tmp
> lhs value for increment. This fixes reported issue about sequence
> point in PR/48814
>
> ChangeLog
>
> 2012-01-08 Kai Tietz
>
> PR
Denis Chertykov wrote:
> Hi Georg.
>
> I have found that conversion AVR port to using hard_frame_pointer have
> resolved PR 50925 .
> I have tested the patch without regressions, but I'm worry about it.
> Can you test it with your testsuite for regressions ?
> May be you have your own special diff
On Mon, 9 Jan 2012, Xinliang David Li wrote:
> It looks non-ambiguous to me.
The new proposed version or the old?
Richard.
> David
>
> On Mon, Jan 9, 2012 at 1:05 AM, Richard Guenther wrote:
> >
> > Since GCC 4.4 applying the malloc attribute to realloc-like
> > functions does not work under
On Mon, 9 Jan 2012, Tobias Grosser wrote:
> On 01/09/2012 04:34 PM, Richard Guenther wrote:
> >
> > This fixes the 2nd P1 ICE.
> >
> > There is a disconnect on how we analyze data-references during SCOP
> > detection
> > (outermost_loop is the root of the loop tree) and during SESE-to-poly
> > w
On Mon, 9 Jan 2012, Uros Bizjak wrote:
> Hello!
>
> Attached patch fixes oversight with AND pattern and 0x
> immediate. While ANDs with 0xff and 0x are converted to equivalent
> zero_extend pattern, AND with 0x isn't. This problem leaves
> important optimization that would sub
On 01/09/2012 05:58 PM, Ramana Radhakrishnan wrote:
On 9 January 2012 08:49, Sebastian Huber
wrote:
What is missing to get this ported back to the GCC 4.6 branch?
I ran a sanity check again today and backported them to the 4.6
branch. Sorry about the delay.
Thanks.
I prefer to do the sam
60 matches
Mail list logo
