Ralf Corsepius wrote:
> I would like to apply the patch below to trunk and gcc-4.7 branch.
> GCC doesn't build for sh-rtems* without it.
OK. Please go ahead.
Regards,
kaz
On 10/25/2012 09:36 AM, Kaz Kojima wrote:
Ralf Corsepius wrote:
I would like to apply the patch below to trunk and gcc-4.7 branch.
GCC doesn't build for sh-rtems* without it.
OK. Please go ahead.
Thanks, patch applied to trunk and gcc-4.7-branch.
Ralf
Hi,
I would like to apply the following patch to trunk and gcc-4_7-branch.
GCC doesn't build for sparc64-rtems* without it.
Ralf
2012-07-05 Ralf Corsépius
* config.host (sparc64-*-rtems*): Remove sparc/t-elf.
diff --git a/libgcc/config.host b/libgcc/config.host
index 2259d47..bbf21a9 10064
Hello Alan,
thanks for looking at this issue.
On 10/24/2012 04:50 PM, Alan Modra wrote:
On Tue, Oct 23, 2012 at 06:25:43PM +0200, Sebastian Huber wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033
This patch fixes my problem, but I am absolutely not sure if this is the
right way.
[snip
I was curious why LRA needed to handle noncanonical rtl in addresses:
if (CONSTANT_P (arg0)
|| code1 == PLUS || code1 == MULT || code1 == ASHIFT)
{
tloc = arg1_loc;
arg1_loc = arg0_loc;
arg0_loc = tloc;
arg0 = *arg0_loc;
On Wed, 17 Oct 2012, Marc Glisse wrote:
Hello,
this patch adds support for vector conditions to the C++ front-end. Note that
the testcase currently only applies to x86. This is because there is work
remaining in the middle-end for the case where vector selection for this
vector mode is not p
Hi Vlad,
When testing other patches, I was misled by:
/* Addresses were legitimate before LRA. So if the address has
two registers than it can have two of them. We should also
not worry about scale for the same reason. */
which I took to mean that process_address only handles pre-
Hi Vlad,
This patch splits out the code to verify an address, so that it's
easier to experiment with different approaches. See the next patch
for one example where this might be useful in future.
Tested on x86_64-linux-gnu. OK to install?
Richard
gcc/
* lra-constraints.c (valid_addre
Ian Lance Taylor writes:
> There is a decent change that this will break something on non-x86
> systems. I will do what testing I am able to do after the commit.
As expected, it did break the Solaris libgo build:
* udpsock_posix.go lacked definitions of joinIPv4Group, joinIPv6Group,
setIPv6M
Hi Vlad,
As discussed in the reviews, one of the things that worried me was the
combination of:
1) the displacement fixup code in process_address assumes that the address
is exactly equal to BASE_LOC + INDEX_LOC + DISP (with null values
being equivalent to 0).
2) extract_address_regs allow
Hi Vlad,
As promised a while ago, here's a patch to make process_address
create canonical rtl. It also fixes the base_reg_class for the
index + disp => base + index case.
Tested on x86_64-linux-gnu. Also tested by making sure that there
were no changes in assembly output for a set of gcc .ii fi
On Wed, 24 Oct 2012, Steven Bosscher wrote:
> On Wed, Oct 24, 2012 at 4:25 PM, Richard Biener wrote:
> > Comments? Should find_many_sub_basic_blocks really do what
> > it does here? Or is the CFG in fact "invalid" (but we don't
> > check that in verification)?
>
> If a "noreturn" function is i
On Thu, 25 Oct 2012, Jan Hubicka wrote:
> > > * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Add
> > > edge_to_cancel
> > > parameter and use it to estimate code optimized out in the final
> > > iteration.
> > > (loop_edge_to_cancel): New function.
> > > (tr
On Wed, Oct 24, 2012 at 7:23 PM, Mike Stump wrote:
> On Oct 24, 2012, at 2:43 AM, Richard Biener
> wrote:
>> On Tue, Oct 23, 2012 at 6:12 PM, Kenneth Zadeck
>> wrote:
>>>
>>> On 10/23/2012 10:12 AM, Richard Biener wrote:
+ HOST_WIDE_INT val[2 * MAX_BITSIZE_MODE_ANY_INT /
HOST_BI
On Wed, Oct 24, 2012 at 10:41 PM, Marc Glisse wrote:
> On Wed, 24 Oct 2012, Mike Stump wrote:
>
>> Well, I suspect the OpenCL community had a ton of people sweat over the
>> details and take into consideration the realities and the needs of people.
>> I'd like to believe they had more people in on
> I would like to apply the following patch to trunk and gcc-4_7-branch.
> GCC doesn't build for sparc64-rtems* without it.
Sure, thanks.
--
Eric Botcazou
On 10/25/2012 06:42 AM, Richard Biener wrote:
On Wed, Oct 24, 2012 at 7:23 PM, Mike Stump wrote:
On Oct 24, 2012, at 2:43 AM, Richard Biener wrote:
On Tue, Oct 23, 2012 at 6:12 PM, Kenneth Zadeck
wrote:
On 10/23/2012 10:12 AM, Richard Biener wrote:
+ HOST_WIDE_INT val[2 * MAX_BITSIZE_MOD
On Thu, Oct 25, 2012 at 12:31 PM, Richard Biener wrote:
>> But, really, why inline noreturn functions at all?
>
> That's a good question. The question then is, why not?
Because noreturn functions are usually on error paths. To inline a
called noreturn function is to drag overhead into the caller
On Thu, 25 Oct 2012, Steven Bosscher wrote:
> On Thu, Oct 25, 2012 at 12:31 PM, Richard Biener wrote:
> >> But, really, why inline noreturn functions at all?
> >
> > That's a good question. The question then is, why not?
>
> Because noreturn functions are usually on error paths. To inline a
> c
This fixes PR54902, cfgcleanup may create / release SSA names which
is something the VN machinery does not like. Thus avoid calling
cfgcleanup before we finish it. Tail-merging requires dominators
thus at least remove unreachable blocks before computing them.
Bootstrapped and tested on x86_64-u
On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
wrote:
>
> On 10/25/2012 06:42 AM, Richard Biener wrote:
>>
>> On Wed, Oct 24, 2012 at 7:23 PM, Mike Stump wrote:
>>>
>>> On Oct 24, 2012, at 2:43 AM, Richard Biener
>>> wrote:
On Tue, Oct 23, 2012 at 6:12 PM, Kenneth Zadeck
wrote:
> On Thu, 25 Oct 2012, Jan Hubicka wrote:
>
> > > > * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Add
> > > > edge_to_cancel
> > > > parameter and use it to estimate code optimized out in the
> > > > final iteration.
> > > > (loop_edge_to_cancel): New function.
> >
Hi,
while looking into cunroll issues I noticed that we miss quite lot of important
unrolling
at -O2 for EON because we think it will increase code size. This is because we
do not
account the fact that making array index constant is good thing.
This tracks back to the fact that estimate_num_ins
On 10/25/2012 12:53 PM, Eric Botcazou wrote:
I would like to apply the following patch to trunk and gcc-4_7-branch.
GCC doesn't build for sparc64-rtems* without it.
Sure, thanks.
Thanks, patch applied to trunk and gcc-4_7-branch.
Ralf
On Thu, Oct 25, 2012 at 12:58:26PM +0200, Richard Biener wrote:
> So the bug here is really in find_many_sub_basic_blocks then
> and your patch would certainly avoid triggering its bug
> (or its wrong expectations). I'll give it testing.
I'd say we should insert the __builtin_unreachable already
On Thu, 25 Oct 2012, Jan Hubicka wrote:
> > On Thu, 25 Oct 2012, Jan Hubicka wrote:
> >
> > > > > * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Add
> > > > > edge_to_cancel
> > > > > parameter and use it to estimate code optimized out in the
> > > > > final iteration.
> >
Hi,
recursive inliner is confusing the cost of inlining function to itself with
cost of inlining the master clone. After first recursive inlining happened
those are no longer equivalent.
Fixed thus.
Bootstrapped/regtested x86_64-linux, committed.
Honza
* ipa-inline.c (recursive_inlining):
On Thu, 25 Oct 2012, Jan Hubicka wrote:
> Hi,
> while looking into cunroll issues I noticed that we miss quite lot of
> important unrolling
> at -O2 for EON because we think it will increase code size. This is because
> we do not
> account the fact that making array index constant is good thing
> > We can also patch in __builtin_unreachable but that will make bugs with
> > out overflows/ out of bound accesses hard in loops to debug at -O levels
> > (as seen by do-1.f90 testcase and the new PR with integer overflow), so
> > perhaps we could do that at -Ofast or only or with
> > -funsaf
On Thu, 25 Oct 2012, Jakub Jelinek wrote:
> On Thu, Oct 25, 2012 at 12:58:26PM +0200, Richard Biener wrote:
> > So the bug here is really in find_many_sub_basic_blocks then
> > and your patch would certainly avoid triggering its bug
> > (or its wrong expectations). I'll give it testing.
>
> I'd
OK.
Jason
> > +/* For operands of load/stores estimate cost of the address computations
> > + involved. */
> > +
> > +static int
> > +estimate_operand_cost (tree op)
> > +{
> > + int cost = 0;
> > + while (handled_component_p (op))
> > +{
> > + cost += estimate_ref_cost (op);
> > + op = TR
> Hmm, also in ASM/call/return? It will definitely make quite a fuzz into the
> cost metric
> by making a=b+c to have cost of 3 instead of 1 as it have now. I am not 100%
> sure if
> a+b should be more expensive than a+1.
> I can give that a try and we will see after re-tunning how well it work
On Thu, 25 Oct 2012, Jan Hubicka wrote:
> > > +/* For operands of load/stores estimate cost of the address computations
> > > + involved. */
> > > +
> > > +static int
> > > +estimate_operand_cost (tree op)
> > > +{
> > > + int cost = 0;
> > > + while (handled_component_p (op))
> > > +{
>
On Thu, 25 Oct 2012, Jan Hubicka wrote:
> > Hmm, also in ASM/call/return? It will definitely make quite a fuzz into
> > the cost metric
> > by making a=b+c to have cost of 3 instead of 1 as it have now. I am not
> > 100% sure if
> > a+b should be more expensive than a+1.
> > I can give that a
On Thu, 25 Oct 2012, Jan Hubicka wrote:
> Hi,
> while looking into cunroll issues I noticed that we miss quite lot of
> important unrolling
> at -O2 for EON because we think it will increase code size. This is because
> we do not
> account the fact that making array index constant is good thing
On Thu, 25 Oct 2012, Richard Biener wrote:
> On Thu, 25 Oct 2012, Jakub Jelinek wrote:
>
> > On Thu, Oct 25, 2012 at 12:58:26PM +0200, Richard Biener wrote:
> > > So the bug here is really in find_many_sub_basic_blocks then
> > > and your patch would certainly avoid triggering its bug
> > > (or i
On Thu, Oct 25, 2012 at 3:34 PM, Richard Biener wrote:
> +
> + /* If we have a basic-block with no successors that does not
> +end with a control statement or a noreturn call connect it
> +to itself. This situation can occur when inlining a noreturn
> +call that does
Hi,
And another RTEMS-patch, I'd like to apply to GCC trunk and
GCC-4_7-branch: Adding microblaze*-rtems* target.
This patch has been in use as part of the RTEMS gcc-4.7 patches for ca.
1/2 a year.
Ralf
2012-04-19 Ralf Corsépius
* config.gcc (microblaze*-*-rtems*): New target.
* confi
> + /* If we have a basic-block with no successors that does not
> + end with a control statement or a noreturn call connect it
> + to itself. This situation can occur when inlining a noreturn
> + call that does in fact return. */
The '-' is superfluous in basic-block. And
On 10/24/2012 04:47 PM, Paolo Carlini wrote:
Essentially, what really matters is that the first field must be a pointer.
In this case, yes. Let's just say what the issue is: the type of the
first field has a different ABI from the class overall.
Jason
On 10/25/2012 06:49 AM, Ralf Corsepius wrote:
Hi,
And another RTEMS-patch, I'd like to apply to GCC trunk and GCC-4_7-branch:
Adding
microblaze*-rtems* target.
This patch has been in use as part of the RTEMS gcc-4.7 patches for ca. 1/2 a
year.
OK to apply.
--
Michael Eagerea...@eagerc
Andreas Schwab wrote:
> Gunther Nikl writes:
>
>> While working with GCC 4.7, I noticed that the -m68020-40 and -m68020-60
>> options are broken.
>
> Broken in which way?
These compound options are supposed to cause m68k.c/m68k_option_override
to set m68k_cpu_entry and m68k_tune_entry. However
David Miller writes:
> From: David Miller
> Date: Tue, 23 Oct 2012 22:06:55 -0400 (EDT)
>
>> From: David Miller
>> Date: Tue, 23 Oct 2012 21:44:05 -0400 (EDT)
>>
>>> The first issue sparc runs into is that it does not define it's
>>> extra constraints properly. In particular 'T' and 'W' must u
In Portland we decided that we should allow defaulted move ctors/op=
even if they could throw or might move a virtual base more than once,
and that overload resolution should ignore an implicitly deleted move
ctor/op=. This patch implements that resolution.
Tested x86_64-pc-linux-gnu, applyin
Threadprivate was complaining about a template-id being an incomplete
type, because we weren't calling complete_type to instantiate it.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 055a6956282763467ce0b84776dbb49e89c5a347
Author: Jason Merrill
Date: Mon Oct 15 11:06:25 2012 -0700
The specification of C++11 inheriting constructors doesn't seem to
handle C-style variadic functions, so we just drop the ... when
declaring the constructor in the derived class. This patch adds a
warning about that, on by default.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit e38315
To accommodate tsan (and msan in the future), the directory structure
needs to be changed. The top level directory can be called something
like librt with the following subdirs: asan, tsan, sanitizer_common,
and interception. Also the libasan should be linked in statically by
default.
thanks,
Da
On Thu, Oct 25, 2012 at 09:24:51AM -0700, Xinliang David Li wrote:
> To accommodate tsan (and msan in the future), the directory structure
> needs to be changed. The top level directory can be called something
> like librt with the following subdirs: asan, tsan, sanitizer_common,
> and interception
On Thu, Oct 25, 2012 at 9:39 AM, Jakub Jelinek wrote:
> On Thu, Oct 25, 2012 at 09:24:51AM -0700, Xinliang David Li wrote:
>> To accommodate tsan (and msan in the future), the directory structure
>> needs to be changed. The top level directory can be called something
>> like librt with the followi
On 10/25/2012 04:38 PM, Michael Eager wrote:
On 10/25/2012 06:49 AM, Ralf Corsepius wrote:
Hi,
And another RTEMS-patch, I'd like to apply to GCC trunk and
GCC-4_7-branch: Adding
microblaze*-rtems* target.
This patch has been in use as part of the RTEMS gcc-4.7 patches for
ca. 1/2 a year.
OK
On Thu, Oct 25, 2012 at 12:48 PM, Xinliang David Li wrote:
> On Thu, Oct 25, 2012 at 9:39 AM, Jakub Jelinek wrote:
>>
>> librt is a very bad name, that clashes with glibc librt, would only create
>> confusion.
>
> Ok, then we should pick something that is not confusing but reflect
> the fact the
On Thu, Oct 25, 2012 at 9:52 AM, Diego Novillo wrote:
> On Thu, Oct 25, 2012 at 12:48 PM, Xinliang David Li
> wrote:
>> On Thu, Oct 25, 2012 at 9:39 AM, Jakub Jelinek wrote:
>>>
>>> librt is a very bad name, that clashes with glibc librt, would only create
>>> confusion.
>>
>> Ok, then we shoul
The following patch fixes a crash in lra.c::check_rtl on a big
spec2000 test. Unfortunately, I can not extract a small test. The
crash occurs exactly in complicated processing of a big function. The
reason for the crash was in ignoring insn for reload processing after a
hard reg assignment
On Thu, Oct 25, 2012 at 09:48:54AM -0700, Xinliang David Li wrote:
> > Why should be libasan linked statically by default?
> There are a couple of reasons:
>
> 1) it makes running sanitized binary on remote machines which does not
> have libasan installed easier;
> 2) There is no guarantee that l
On 10/23/2012 07:38 AM, Yuri Rumyantsev wrote:
Hi All,
This fix is aimed to remove stability issues with using pre-reload
scheduler for x86 targets caused by cross-block motion of function
arguments passed in likely-spilled HW registers. We found one more
issue in a process of more detail testin
On Thu, Oct 25, 2012 at 9:55 AM, Jakub Jelinek wrote:
> On Thu, Oct 25, 2012 at 09:48:54AM -0700, Xinliang David Li wrote:
>> > Why should be libasan linked statically by default?
>
>> There are a couple of reasons:
>>
>> 1) it makes running sanitized binary on remote machines which does not
>> ha
Hi,
This patch fixes debug info for expr and jump stmt.
Bootstrapped and passed gcc regression tests.
Is it okay for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2012-10-25 Dehao Chen
* tree-eh.c (do_return_redirection): Set location for jump statement.
(do_goto_redirection): Likewise.
(frob_into_b
Hi,
this patch adds several sanity checks that inline summaries are up to date and
makes sense; it also fixes several minor updating bugs and two perhaps important
integer overflows.
Bootstrapped/regtested x86_64-linux, will commit it shortly.
Honza
* ipa-cp.c (ipcp_discover_new_direct_e
On Thu, Oct 25, 2012 at 10:00:03AM -0700, Xinliang David Li wrote:
> How about statically linking just for executables, not shared library buid?
That is IMHO still a bad idea.
Jakub
On Thu, Oct 25, 2012 at 10:19 AM, Jakub Jelinek wrote:
> On Thu, Oct 25, 2012 at 10:00:03AM -0700, Xinliang David Li wrote:
>> How about statically linking just for executables, not shared library buid?
>
> That is IMHO still a bad idea.
I don't know why you think so (It seems that the points men
On Thu, Oct 25, 2012 at 1:24 PM, Xinliang David Li wrote:
> I don't know why you think so (It seems that the points mentioned in
> http://www.akkadia.org/drepper/no_static_linking.html mainly apply to
> release binaries, not sanitized ones), but for now let's drop the
> static link request.
Yeah
> This patch fixes debug info for expr and jump stmt.
It would be nice to have testcases...
> * cfgexpand.c (set_expr_location_r): New callback function.
> (gimple_assign_rhs_to_tree): Walk the expr recursively.
> (expand_call_stmt): Likewise.
> (expand_gimple_stmt_1): Likewise.
This cannot be r
> "Dehao" == Dehao Chen writes:
Dehao> This patch fixes debug info for expr and jump stmt.
Dehao> Bootstrapped and passed gcc regression tests.
Dehao> Is it okay for trunk?
I wonder whether this affects the gdb test suite results.
I'm not trying to pick on you specifically, but there's been
From: Richard Sandiford
Date: Thu, 25 Oct 2012 16:34:00 +0100
> David Miller writes:
>> I'll add the straightforward check to sparc's legitimate_address_p,
>> but I'm really surprised you never hit this case in your testing.
>
> Adding the check sounds like the right thing to do. And remember
From: David Miller
Date: Mon, 22 Oct 2012 23:39:23 -0400 (EDT)
> Eric and Rainer, I think that functionally this patch is fully ready
> to go into the tree except for the Solaris aspects which I do not have
> the means to work on. Have either of you made any progress in this
> area?
Just wonder
On Thu, Oct 25, 2012 at 2:36 AM, Rainer Orth
wrote:
> Ian Lance Taylor writes:
>
>> There is a decent change that this will break something on non-x86
>> systems. I will do what testing I am able to do after the commit.
>
> As expected, it did break the Solaris libgo build:
>
> * udpsock_posix.g
On 10/24/12 21:02, Vladimir Makarov wrote:
The following patch fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55055
In this case, operand was an address containing subreg. LRA before
the patch processed only operands which are subregs of regs.
The patch was successfully bootstrapp
I've committed the following fix for PR 55063:
-cary
2012-10-25 Cary Coutant
PR debug/55063
* dwarf2out.c (prune_unused_types_prune): Check whether DIE is
already a declaration.
Index: dwarf2out.c
===
-
On Thu, Oct 25, 2012 at 11:06 AM, Eric Botcazou wrote:
>> This patch fixes debug info for expr and jump stmt.
>
> It would be nice to have testcases...
Sure, I'll try to forge some testcases for this.
>
>> * cfgexpand.c (set_expr_location_r): New callback function.
>> (gimple_assign_rhs_to_tree)
On Thu, Oct 25, 2012 at 11:11 AM, Tom Tromey wrote:
>> "Dehao" == Dehao Chen writes:
>
> Dehao> This patch fixes debug info for expr and jump stmt.
> Dehao> Bootstrapped and passed gcc regression tests.
> Dehao> Is it okay for trunk?
>
> I wonder whether this affects the gdb test suite result
On 10/25/2012 05:18 AM, Richard Sandiford wrote:
Hi Vlad,
When testing other patches, I was misled by:
/* Addresses were legitimate before LRA. So if the address has
two registers than it can have two of them. We should also
not worry about scale for the same reason. */
On 10/25/2012 05:21 AM, Richard Sandiford wrote:
Hi Vlad,
This patch splits out the code to verify an address, so that it's
easier to experiment with different approaches. See the next patch
for one example where this might be useful in future.
Tested on x86_64-linux-gnu. OK to install?
Yes
On 10/25/2012 05:45 AM, Richard Sandiford wrote:
Hi Vlad,
As discussed in the reviews, one of the things that worried me was the
combination of:
1) the displacement fixup code in process_address assumes that the address
is exactly equal to BASE_LOC + INDEX_LOC + DISP (with null values
b
On 10/25/2012 05:50 AM, Richard Sandiford wrote:
Hi Vlad,
As promised a while ago, here's a patch to make process_address
create canonical rtl. It also fixes the base_reg_class for the
index + disp => base + index case.
Tested on x86_64-linux-gnu. Also tested by making sure that there
were no
This patch is an attempt at the routine sketched here:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01016.html
for decomposing addresses into constituent parts. It applies
on top of the patches I sent out earlier today. To summarise
that message, the main point is to have an address descrip
Vladimir Makarov writes:
> On 10/25/2012 05:45 AM, Richard Sandiford wrote:
>> Hi Vlad,
>>
>> As discussed in the reviews, one of the things that worried me was the
>> combination of:
>>
>> 1) the displacement fixup code in process_address assumes that the address
>> is exactly equal to BASE_L
On 10/25/2012 04:06 PM, Richard Sandiford wrote:
Vladimir Makarov writes:
On 10/25/2012 05:45 AM, Richard Sandiford wrote:
I see a potential bug here. We should not reject new equiv values for
base and index here. After we decided to use equiv it should be changed
everywhere as we remove ini
From: Richard Sandiford
Date: Thu, 25 Oct 2012 20:57:05 +0100
> I'm hoping this will help with the x32 problems that HJ is seeing.
> Like Vlad, I don't have a set-up to try for certain, but I tried
> compiling a set of non-x32 gcc .ii files with -mx32 -maddress-mode=long
> and it fixed all but on
Vladimir Makarov writes:
> On 10/25/2012 05:18 AM, Richard Sandiford wrote:
>> Hi Vlad,
>>
>> When testing other patches, I was misled by:
>>
>>/* Addresses were legitimate before LRA. So if the address has
>> two registers than it can have two of them. We should also
>> not worr
This seems to fix it, is it correct? (Untested as I'm still waiting
for a bootstrap to finish)
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 4b35726..827fd4d 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -1216,11 +1216,13 @@ check_and_process_move (bool *cha
ping.
Teresa
On Thu, Oct 18, 2012 at 8:21 AM, Teresa Johnson wrote:
>
> The attached patch implements avoids conservative behavior in REE by allowing
> removal of redundant extends when the def feeds another extend with a
> different
> mode. This works because in merge_def_and_ext only calls com
On Thu, Oct 25, 2012 at 10:24 PM, Jonathan Wakely wrote:
> This seems to fix it, is it correct? (Untested as I'm still waiting
> for a bootstrap to finish)
I'd do it the other way around:
--- lra-constraints.c 2012-10-24 13:39:19.830019609 -0700
+++ lra-constraints.c 2012-10-25 13:32:39.99001
Hi,
On Tue, Oct 23, 2012 at 3:03 AM, Jan Hubicka wrote:
>> Ping.
>>
>>
>> On Wed, Oct 17, 2012 at 1:48 PM, Easwaran Raman wrote:
>> > Hi,
>> > This patch fixes bugs introduced by my previous patch to propagate
>> > profiles during switch expansion. Bootstrap and profiledbootstrap
>> > successfu
On Thu, Oct 25, 2012 at 01:28:32PM -0700, Teresa Johnson wrote:
> > 2012-10-18 Teresa Johnson
> >
> > * ree.c (add_removable_extension): Remove unnecessary
> > mode check with other extension.
> >
> > 2012-10-18 Teresa Johnson
> >
> > * gcc.c-torture/execute/20111227-2
Change hash_table to support a comparator type different from the
value type stored in the hash table. The 'find' functions now may
take a different type from the value type. This requires introducing
a second typedef into the Descriptor conceptual type. Change the
Descriptor concept to use type
On Thu, Oct 25, 2012 at 5:03 PM, Lawrence Crowl wrote:
> Change hash_table to support a comparator type different from the
> value type stored in the hash table. The 'find' functions now may
> take a different type from the value type. This requires introducing
> a second typedef into the Descri
Hi,
A small patch to remove the bogus error reports exposed in the
spec2000 testing. In varasm.c, asan_protected should be equivalent
with asan_protect_global (decl) all the time, or else compiler will
not insert redzones for some globals planned to be protected.
gcc/ChangeLog:
2012-10-25 Wei M
Jakub Jelinek writes:
> case BUILT_IN_ATOMIC_ALWAYS_LOCK_FREE:
> case BUILT_IN_ATOMIC_IS_LOCK_FREE:
> I think don't touch the memory at all (or not necessarily),
> and IMHO you don't want to handle the BUILT_IN_*_N variants either,
> those are just FE builtins that are lowered to the corr
Should the alignment check be moved into 'asan_protect_global' method?
David
On Thu, Oct 25, 2012 at 2:32 PM, Wei Mi wrote:
> Hi,
>
> A small patch to remove the bogus error reports exposed in the
> spec2000 testing. In varasm.c, asan_protected should be equivalent
> with asan_protect_global (d
On Thu, Oct 25, 2012 at 5:32 PM, Wei Mi wrote:
> Hi,
>
> A small patch to remove the bogus error reports exposed in the
> spec2000 testing. In varasm.c, asan_protected should be equivalent
> with asan_protect_global (decl) all the time, or else compiler will
> not insert redzones for some globals
On Thu, Oct 25, 2012 at 02:32:33PM -0700, Wei Mi wrote:
> A small patch to remove the bogus error reports exposed in the
> spec2000 testing. In varasm.c, asan_protected should be equivalent
> with asan_protect_global (decl) all the time, or else compiler will
> not insert redzones for some globals
On Thu, Oct 25, 2012 at 05:46:47PM -0400, Diego Novillo wrote:
> The change looks fine to me, but why not just move the alignment check
> into asan_protect_global? I'll defer to David or Jakub in this.
asan_protect_global has
|| DECL_ALIGN_UNIT (decl) > 2 * ASAN_RED_ZONE_SIZE
check among other th
Why not relaxing the check even more to allow for instance 128 byte
alignment which may be common?
David
On Thu, Oct 25, 2012 at 2:51 PM, Jakub Jelinek wrote:
> On Thu, Oct 25, 2012 at 05:46:47PM -0400, Diego Novillo wrote:
>> The change looks fine to me, but why not just move the alignment chec
On Thu, Oct 25, 2012 at 11:32:58PM +0200, Dodji Seketeli wrote:
> + tree source0 = NULL_TREE, source1 = NULL_TREE,
> +dest = NULL_TREE, len = NULL_TREE;
> + bool is_store = true;
...
nothing sets is_store here.
...
> +
> + instrument_derefs (iter, dest, location, is_store);
BUILTIN_ATOMI
On Thu, Oct 25, 2012 at 12:57 PM, Richard Sandiford
wrote:
> This patch is an attempt at the routine sketched here:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01016.html
>
> for decomposing addresses into constituent parts. It applies
> on top of the patches I sent out earlier today. T
"H.J. Lu" writes:
> On Thu, Oct 25, 2012 at 12:57 PM, Richard Sandiford
> wrote:
>> This patch is an attempt at the routine sketched here:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01016.html
>>
>> for decomposing addresses into constituent parts. It applies
>> on top of the patches
This was discovered while playing around with LRA, but of course
I regstrapped this using the existing reload pass.
Constraint "U" is a register constraint, that accepts either a
pseudo or an even numbered hard register. But it is bogus, and
in fact unnecessary.
First, it isn't marked as a "def
Jakub Jelinek writes:
>> +instrument_derefs (iter, dest, location, is_store);
>
> BUILTIN_ATOMIC_LOAD* are just loads and so should clear is_store.
Done.
>
>> + if (len != NULL_TREE)
>> +{
>> + is_store = (dest != NULL_TREE);
>> +
>> + if (source0 != NULL_TREE)
>> +instru
On Thu, Oct 25, 2012 at 3:13 PM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> On Thu, Oct 25, 2012 at 12:57 PM, Richard Sandiford
>> wrote:
>>> This patch is an attempt at the routine sketched here:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01016.html
>>>
>>> for decomposing ad
1 - 100 of 133 matches
Mail list logo
