Hello,
On 31.07.2012 15:08, Andrey Belevantsev wrote:
Hello,
This PR is about wrong speculation of an insn that doesn't support storing
NaT bits done by the selective scheduler (more details in the PR audit
trail). The reason for this is the wrong one-liner patch committed last
year, the fix i
Hi Steven, Jeff,
I found a flaw in original patch, which results in inaccurate register
pressure.
Here comes the updated patches, improving code size a little bit on
Thumb2/powerpc comparing to original patches.
Please review.
Thanks
2012-10-16 Bin Cheng
* gcse.c: Update copyright dat
Hello,
On 09.08.2012 17:19, Alexander Monakov wrote:
On Thu, 9 Aug 2012, Andrey Belevantsev wrote:
Hello,
The problem in question is uncovered by the recent speculation patch, it is in
the handling of expressions blocked by bookkeeping. Those are expressions
that become unavailable due to
Ping, again
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html
--
Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
Palace Road, London SW1W 9TQ | Registered in England Number: 3977902
Hi,
I have just merged upstream gcc-4_7-branch on the aarch64-4.7-branch up to
r192444.
Thanks
Sofiane
On Tue, Oct 16, 2012 at 10:50 AM, Simon Baldwin wrote:
> Ping, again
>
> http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html
Probably you mean the revised patch here:
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html
The patch look OK to me but I can't approve it.
Technically you're fi
Hi,
I have just merged upstream trunk on the aarch64-branch up to r192445.
Thanks
Sofiane
Hi,
> 2012-09-26 J"orn Rennecke
>
> * loop-doloop.c (doloop_modify): Pass doloop_end pattern to
> gen_doloop_begin.
> * loop-doloop.c (doloop_optimize): Pass flag to indicate if loop is
> entered at top to gen_doloop_end.
> * config/arm/thumb2.md (doloop_e
On 12/9/27 6:25 AM, Janis Johnson wrote:
> On 09/26/2012 01:58 AM, Chung-Lin Tang wrote:
>
> +/* { dg-do compile } */
> +/* { dg-options "-mthumb -O1 -march=armv5te -fno-omit-frame-pointer
> -fno-forward-propagate" } */
> +/* { dg-require-effective-target arm_thumb1_ok } */
>
> This test will f
Hello,
In RTL land it's not trivial to find a CALL rtx inside a CALL_INSN,
and code to find the CALL is duplicated in a few places. The attached
patch cleans this up.
Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
P.S. question: when is XEXP(call,0) _not_ a MEM?
> As I'm not sure how to best do that I suggest we do a more proper RTL
> DSE hack by adding a 'libcall-call-escape'-set which we can add to
> instead of calling mark_addressable this late. We need to add all
> partitions of a decl here, of course, and we need to query it from
> can_escape.
That
> In RTL land it's not trivial to find a CALL rtx inside a CALL_INSN,
> and code to find the CALL is duplicated in a few places. The attached
> patch cleans this up.
>
> Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
Sure, thanks.
> P.S. question: when is XEXP(call,0) _not_ a
> I've scanned the documentation and there is no indication of any
> preprocessor predefines or anything like that.
>
> And keep in mind that __VIS__ is our very own invention.
>
> Sun's compilers never predefined this.
>
> Their makefiles do for various targets in the MediaLib sources, but that
On Mon, Oct 15, 2012 at 3:26 PM, Steven Bosscher wrote:
> On Mon, Oct 15, 2012 at 3:21 PM, Paolo Bonzini wrote:
>> Il 15/10/2012 14:53, Steven Bosscher ha scritto:
>>> I think I've shown above that we're all looking at the wrong pass...
>>
>> I think you have... so we want a patch like this?
>
> I
Hi Dominique,
Dominique Dhumieres wrote:
the test gfortran.dg/class_optional_1.f90 does not compile
...
but the code seems weird.
I concur – and believe that it is already covered by the other test
cases. Thus, I removed it.
The code gfortran.dg/class_optional_2.f90 compiles, but
the ru
On Tue, Oct 16, 2012 at 12:15 PM, Steven Bosscher wrote:
> On Mon, Oct 15, 2012 at 3:26 PM, Steven Bosscher wrote:
>> On Mon, Oct 15, 2012 at 3:21 PM, Paolo Bonzini wrote:
>>> Il 15/10/2012 14:53, Steven Bosscher ha scritto:
I think I've shown above that we're all looking at the wrong pass...
Hi Tobias,
>> + for (ref = e->ref; ref; ref = ref->next)
>> +{
>> + if (ref->type == REF_COMPONENT
>> + && ref->u.c.component->ts.type == BT_CLASS)
>> + class_ref = ref;
>> +
>> + if (ref->next == NULL)
>> + break;
>> +}
>>
>> ... I guess the last if statem
Diego Novillo writes:
> On Mon, Oct 15, 2012 at 11:55 AM, Ian Lance Taylor wrote:
>
>> In my opinion, supporting the full range of GCC testsuite annotations
>> means imposing a lot of mechanism that the Go testsuite does not
>> require. It would complicate the Go testsuite for no benefit.
>> An
On Mon, Oct 15, 2012 at 3:51 PM, Marc Glisse wrote:
> On Mon, 15 Oct 2012, Richard Biener wrote:
>
>>>else if ((code == BIT_NOT_EXPR
>>> && TYPE_PRECISION (TREE_TYPE (cond)) == 1)
>>>|| (code == BIT_XOR_EXPR
>>> - && integer_onep (gimple_ass
On 2012-10-16 07:05 , Rainer Orth wrote:
Diego Novillo writes:
On Mon, Oct 15, 2012 at 11:55 AM, Ian Lance Taylor wrote:
In my opinion, supporting the full range of GCC testsuite annotations
means imposing a lot of mechanism that the Go testsuite does not
require. It would complicate the G
Il 16/10/2012 12:35, Steven Bosscher ha scritto:
> On Tue, Oct 16, 2012 at 12:15 PM, Steven Bosscher wrote:
>> On Mon, Oct 15, 2012 at 3:26 PM, Steven Bosscher wrote:
>>> On Mon, Oct 15, 2012 at 3:21 PM, Paolo Bonzini wrote:
Il 15/10/2012 14:53, Steven Bosscher ha scritto:
> I think I've s
Hi Tobias,
I did not yet appied you latest patch to gfortran, but I ran the new tests
with gfortran patched with the previous patch and both pass (manual
testing without option, but -fcoarray=single). Note that for
class_optional_1.f90, valgrind --leak-check=full gives
==45665== 4 bytes in 1 bloc
On Tue, Oct 16, 2012 at 11:39 AM, Eric Botcazou wrote:
>> As I'm not sure how to best do that I suggest we do a more proper RTL
>> DSE hack by adding a 'libcall-call-escape'-set which we can add to
>> instead of calling mark_addressable this late. We need to add all
>> partitions of a decl here,
Quoting Zdenek Dvorak :
+ entered_at_top = loop_preheader_edge (loop)->dest == desc->in_edge->dest;
is equivalent to
+ entered_at_top = loop->header == desc->in_edge->dest;
But, I don't think it will do what you want. Loops are canonicalized so that
their latch blocks have single successor
On Tue, Oct 16, 2012 at 4:05 AM, Rainer Orth
wrote:
>
> But importing different upstream testsuites with different annotation
> systems allows them to make GCC maintainer's lives miserable? If this
> trend continues, maintainers need to cope with several different
> annoation systems with differe
Richard Earnshaw wrote:
> On 20/09/12 16:49, Ulrich Weigand wrote:
> > Richard Earnshaw wrote:
> >
> >> Hmm, this is going to cause bottlenecks on Cortex-A15: writing a Neon
> >> single-precision register and then reading it back as a double-precision
> >> value will cause scheduling problems.
[sni
Tejas Belagod wrote:
> > Ulrich Weigand wrote:
> >> The following patch implements this idea; it passes a basic regression
> >> test on arm-linux-gnueabi. (Obviously this would need a lot more
> >> testing on various platforms before getting into mainline ...)
> >>
> >> Can you have a look whether
Hi,
> The loop appears to be entered at the top, yet both my original and your test
> fail.
>
> Looking what happens with your test in more detail, I find that
>
> loop->latch == desc->in_edge->dest
>
> is true, but forwarder_block_p (loop->latch) fails:
>
> 562 if (dest->loop_fathe
Ulrich Weigand wrote:
Tejas Belagod wrote:
Ulrich Weigand wrote:
The following patch implements this idea; it passes a basic regression
test on arm-linux-gnueabi. (Obviously this would need a lot more
testing on various platforms before getting into mainline ...)
Can you have a look whether t
Quoting Zdenek Dvorak :
no -- you should also test that latch contains no active insns.
I.e., factorize
out whatever forwarder_block_p does except for the test
"(dest->loop_father->header == dest)" test,
Like this?
* basic-block.h (forwarder_block_p_1): Declare.
* cfgrtl
> Quoting Zdenek Dvorak :
>
> >no -- you should also test that latch contains no active insns.
> >I.e., factorize
> >out whatever forwarder_block_p does except for the test
> >"(dest->loop_father->header == dest)" test,
>
> Like this?
>
> * basic-block.h (forwarder_block_p_1): Declare.
>
On Tue, Oct 16, 2012 at 4:30 PM, Joern Rennecke
wrote:
> Quoting Zdenek Dvorak :
>
>> no -- you should also test that latch contains no active insns. I.e.,
>> factorize
>> out whatever forwarder_block_p does except for the test
>> "(dest->loop_father->header == dest)" test,
>
>
> Like this?
IST
On Sun, 14 Oct 2012, Manuel L?pez-Ib??ez wrote:
> 2012-10-14 Manuel L?pez-Ib??ez
>
> PR c/53063
> PR c/40989
> gcc/
> * optc-gen.awk: Handle new form of LangEnabledBy.
> * opts.c (set_Wstrict_aliasing): Declare here. Make static.
> * common.opt (Wstrict-aliasing=,
This patch shows work-in-progress (read: implementation uglyness
hopefully to vanish ...) regarding to moving LTO type merging
work from WPA to compile stage.
The patch re-organizes lto_output_tree (the write_tree streamer
hook for LTO) in a way so that we output all tree fields
in easy to discov
On Mon, 15 Oct 2012, Manuel L?pez-Ib??ez wrote:
> 2012-10-15 Manuel L?pez-Ib??ez
>
> PR c/53063
> PR c/40989
> * doc/options.texi (EnabledBy): Document new form.
> * optc-gen.awk: Handle new form of EnabledBy.
> * common.opt (Wunused-but-set-parameter): Use Enable
On Mon, 15 Oct 2012, Michael Meissner wrote:
> > I think changing the names is safer - it's immediately obvious as a build
> > failure if you missed anything. If you have MASK_* names for bits in more
> > than one flags variable, there's a risk of accidentally testing a bit in
> > the wrong va
On Tue, 16 Oct 2012, Richard Biener wrote:
>
> This patch shows work-in-progress (read: implementation uglyness
> hopefully to vanish ...) regarding to moving LTO type merging
> work from WPA to compile stage.
>
> The patch re-organizes lto_output_tree (the write_tree streamer
> hook for LTO) in
I've just committed this patch to aarch64-trunk to resolve an ICE in
aarch64_split_doubleword_move when attempting to split v->v moves.
/Marcus
2012-10-16 Marcus Shawcroft
* config/aarch64/aarch64-protos.h (aarch64_split_doubleword_move):
Rename to aarch64_split_128bit_move.
On 10/16/2012 02:44 AM, Richard Sandiford wrote:
Vladimir Makarov writes:
On 12-10-15 4:25 PM, Richard Sandiford wrote:
Richard Sandiford writes:
Vladimir Makarov writes:
After committing a patch yesterday to implement proposals from a
review, I found that GCC crashes on SPEC2000 gap.
Hi,
this patch udpates go-frontend to deifine unreachable bultin I need for loop
and LTO optimizations. I also noticed that GO ignores existence of all flags
except for CONST and thus I synchronized the flags with C FE variants.
(I plan to use set_call_expr_flags in other FEs too)
Regtested x86_
Hi,
this patch udpates Java frontend to declare __bulitin_unreachable and also
fixes flags of synchronize bulitins to match ones from C FE.
Regtested x86_64-linux, OK?
Honza
* builtins.c (define_builtin): Accept ECF flags and
use set_call_expr_flags.
(initialize_builtins)
On Mon, Oct 15, 2012 at 10:38:02AM +0200, Richard Biener wrote:
> On Fri, Oct 12, 2012 at 8:16 PM, Jakub Jelinek wrote:
> > Apparently vectorizable_load is another spot that could create vector
> > CONSTRUCTORs that wouldn't pass the new CONSTRUCTOR verification.
> >
> > Fixed thusly, bootstrapped
Hi!
Now that SIZEOF_EXPR isn't folded immediately, e.g. REAL_TYPE can
be an argument of it, and tsubst_copy* doesn't handle that, but tsubst does.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2012-10-15 Jakub Jelinek
PR c++/54844
* pt.c (t
Hi,
this patch add __buliltin_unreachable to Fortran FE and also cleans up the code
a bit
Bootstrapped/regtested x86_64-linux, OK?
Honza
* f95-lang.c (gfc_define_builtin): Use set_call_expr_flags.
(ATTR_NOTHROW_LEAF_MALLOC_LIST,
ATTR_CONST_NORETURN_NOTHROW_LEAF_LIST): New
On Mon, Oct 15, 2012 at 10:48:13PM -0700, Xinliang David Li wrote:
> Another error checking feature is to poison stack vars on entry and
> exit of the lexical scope to catch uninit variable reference and out
> of scope references:
>
> S* sp;
> {
> S s;
> sp = &s;
> }
> .. *sp ...
>
On Mon, Oct 15, 2012 at 11:39:52PM -0700, Wei Mi wrote:
> --- gcc/gcc.c (revision 192487)
> +++ gcc/gcc.c (working copy)
> @@ -679,6 +679,7 @@ proper position among the other output f
> %{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
> %(mflib) " STACK_SPLIT_SPEC "\
> %{fprofile-arcs|f
On Tue, Oct 16, 2012 at 08:40:21AM +0200, Tom de Vries wrote:
> 2012-10-16 Tom de Vries
>
> * expr.c (move_by_pieces, move_by_pieces_ninsns, can_store_by_pieces)
> (store_by_pieces_1): Don't enter loop when no more data is left.
Okay.
Jakub
Hi!
Here is an updated patch, which emits also the shadow clearing sequence
at the end of function in the right spot.
2012-10-16 Jakub Jelinek
* Makefile.in (asan.o): Depend on $(EXPR_H) $(OPTABS_H).
(cfgexpand.o): Depend on asan.h.
* asan.c: Include expr.h and optabs.
Hi!
This is a WIP patch for globals protection.
I'm not filling names yet and has_dynamic_init is always
false (wonder how to figure it has_dynamic_init out, especially
with LTO, TYPE_ADDRESSABLE (TREE_TYPE (decl)) probably isn't it,
and for more I'm afraid we need a langhook).
--- gcc/varasm.c.j
Hi,
while looking into cases where loop-iv.c still deduce useful bounds that are not
recorded by tree level I noticed that we do not duplicate the bounds when
copying
the loop.
Fixed thus.
Bootstrapped/regtested x86_64-linux, OK?
Honza
* cfgloopmanip.c (copy_loop_info): New function.
Hi,
s/imlpies/implied/
Sent with AquaMail for Android
http://www.aqua-mail.com
On 15/10/12 11:03, Marcus Shawcroft wrote:
On 11/09/12 15:02, Chris Schlumberger-Socha wrote:
This patch adds predefines for AArch64 code models. These code models are
added as an effective target for the AArch64 platform.
I've committed this patch to aarch64-trunk.
/Marcus
.. and back p
On 16/10/12 16:10, Marcus Shawcroft wrote:
I've just committed this patch to aarch64-trunk to resolve an ICE in
aarch64_split_doubleword_move when attempting to split v->v moves.
/Marcus
2012-10-16 Marcus Shawcroft
* config/aarch64/aarch64-protos.h (aarch64_split_doubleword_move):
On Mon, Oct 15, 2012 at 11:12 PM, Jakub Jelinek wrote:
> On Mon, Oct 15, 2012 at 10:48:13PM -0700, Xinliang David Li wrote:
>> Another error checking feature is to poison stack vars on entry and
>> exit of the lexical scope to catch uninit variable reference and out
>> of scope references:
>>
>> S
On Tue, Oct 16, 2012 at 09:06:22AM -0700, Xinliang David Li wrote:
> I don't get it. Clobber marks the end of lifetime of a variable so it
> is safe to emit code to really clobber its value -- otherwise how
> would clobber based slot sharing work?
If you at CLOBBER protect the var in the shadow m
From: Eric Botcazou
Date: Tue, 16 Oct 2012 12:10:51 +0200
>> I've scanned the documentation and there is no indication of any
>> preprocessor predefines or anything like that.
>>
>> And keep in mind that __VIS__ is our very own invention.
>>
>> Sun's compilers never predefined this.
>>
>> Thei
Hi,
I seem to have uncovered what seems to be a bug with handling SUBREG (MEM) with
the MEM having side-effects while testing aarch64-4.7. This bug seems to be
latent on trunk.
Here is a test case reduced from gcc.c-torture/execute/scal-to-vec1.c.
#define vector(elcount, type) \
__attribute__(
> Subject: [PATCH][AArch64] Restrict usage of SBFIZ to valid range only
>
> This fixes an issue where we were generating an SBFIZ with
> operand 3 outside of the valid range (as determined by the
> size of the destination register and the amount of shift).
>
> My patch checks that the range is va
On Tue, Oct 16, 2012 at 8:14 AM, Jan Hubicka wrote:
> this patch udpates go-frontend to deifine unreachable bultin I need for loop
> and LTO optimizations. I also noticed that GO ignores existence of all flags
> except for CONST and thus I synchronized the flags with C FE variants.
I can't see
On 16/10/12 17:34, Ian Bolton wrote:
Subject: [PATCH][AArch64] Restrict usage of SBFIZ to valid range only
This fixes an issue where we were generating an SBFIZ with
operand 3 outside of the valid range (as determined by the
size of the destination register and the amount of shift).
My patch ch
> "Jan" == Jan Hubicka writes:
Jan> this patch udpates Java frontend to declare __bulitin_unreachable
Jan> and also fixes flags of synchronize bulitins to match ones from C
Jan> FE.
Jan> Regtested x86_64-linux, OK?
The java bits are ok.
Jan> + /* Looping const or pure is imlpies by noretu
> On Tue, Oct 16, 2012 at 8:14 AM, Jan Hubicka wrote:
>
> > this patch udpates go-frontend to deifine unreachable bultin I need for loop
> > and LTO optimizations. I also noticed that GO ignores existence of all
> > flags
> > except for CONST and thus I synchronized the flags with C FE variants
The way to do this is not to use the shadow memory, but to clobber
directly the variable itself with specified byte pattern -- though
error diagnostics won't be as nice.
To use shadow memory, the scope start marker is also needed.
David
On Tue, Oct 16, 2012 at 9:12 AM, Jakub Jelinek wrote:
> On
> > "Jan" == Jan Hubicka writes:
>
> Jan> this patch udpates Java frontend to declare __bulitin_unreachable
> Jan> and also fixes flags of synchronize bulitins to match ones from C
> Jan> FE.
>
> Jan> Regtested x86_64-linux, OK?
>
> The java bits are ok.
>
> Jan> + /* Looping const or pur
I have overhauled the interface to VEC over the last few
weeks. I implemented most of the plan I outlined in
http://gcc.gnu.org/ml/gcc/2012-08/msg00268.html.
I have implemented the embedded and space-efficient vectors. The
diff for vec.[ch] is sufficiently confusing that I'm just
attaching both
On 10/16/2012 01:44 AM, Bin Cheng wrote:
Hi Steven, Jeff,
I found a flaw in original patch, which results in inaccurate register
pressure.
Here comes the updated patches, improving code size a little bit on
Thumb2/powerpc comparing to original patches.
Please review.
Thanks
2012-10-16 Bin Chen
On Tue, Oct 16, 2012 at 9:44 AM, Jan Hubicka wrote:
>
> Hmm, I was not aware of these bits (and yes, I agree it is non-sence this
> being
> duplicated everywhere). I will add UNREACHABLE there. What about rest of the
> change (i.e. adding the proper bits)?
I suppose it's basically fine but add
> On Tue, Oct 16, 2012 at 9:44 AM, Jan Hubicka wrote:
> >
> > Hmm, I was not aware of these bits (and yes, I agree it is non-sence this
> > being
> > duplicated everywhere). I will add UNREACHABLE there. What about rest of
> > the
> > change (i.e. adding the proper bits)?
>
> I suppose it's b
On Mon, Oct 15, 2012 at 5:28 AM, Aldy Hernandez wrote:
>
> Here we have a store data race because noce_can_store_speculate_p()
> incorrectly returns true. The problem is that memory_modified_in_insn_p()
> returns true if an instruction *MAY* modify a memory location, but the store
> can only be s
On Tue, Oct 16, 2012 at 10:19:54AM -0700, Ian Lance Taylor wrote:
> On Mon, Oct 15, 2012 at 5:28 AM, Aldy Hernandez wrote:
> I don't see a reason to add this new function. I would just inline it
> into noce_can_store_speculate_p, replacing the call to
> memory_modified_in_p. And I'm not sure I s
Tobias,
The previous class_optional_2.f90 runs after your commit, but it takes
~168s (so it may have run with the previous patch also, but I was not
patient enough to see it). The culprits are given by the following
profile:
+ 100.0%, start, a.out
| + 100.0%, main, a.out
| | + 100.0%, MAIN__, a.o
Hi,
here is third revised version of the complette unroling changes. While working
on the RTL variant I noticed PR54937 and the fact that I was overly aggressive
on forcing single exit of the last iteration to be taken, because loop may
terminate
otherwise (by EH or by exitting the program). Sam
On Tue, Oct 16, 2012 at 09:48:28AM -0700, Xinliang David Li wrote:
> The way to do this is not to use the shadow memory, but to clobber
> directly the variable itself with specified byte pattern -- though
> error diagnostics won't be as nice.
Clobbering the memory directly is definitely easy, but
On Tue, Oct 16, 2012 at 10:40 AM, Jakub Jelinek wrote:
> On Tue, Oct 16, 2012 at 09:48:28AM -0700, Xinliang David Li wrote:
>> The way to do this is not to use the shadow memory, but to clobber
>> directly the variable itself with specified byte pattern -- though
>> error diagnostics won't be as n
On 2012-10-16 10:43 , Richard Biener wrote:
This patch shows work-in-progress (read: implementation uglyness
hopefully to vanish ...) regarding to moving LTO type merging
work from WPA to compile stage.
You mean to LTRANS, the stage after WPA, right?
The patch re-organizes lto_output_tree (t
On 10/16/2012 08:17 AM, Jan Hubicka wrote:
> * builtins.c (define_builtin): Accept ECF flags and
> use set_call_expr_flags.
> (initialize_builtins): Update; add BULIT_IN_UNREACHALE.
>
> * calls.c (set_call_expr_flags): New.
> * tree.h (set_call_expr_flags): Declare.
Dominique,
Dominique Dhumieres wrote:
The previous class_optional_2.f90 runs after your commit, but it takes
~168s (so it may have run with the previous patch also, but I was not
patient enough to see it).
Here, it takes (current version) < 2s to compile and 0.150s to run the
program. If I lo
On Tue, Oct 16, 2012 at 03:02:47PM +, Joseph S. Myers wrote:
> That is:
>
> 1. Patch adding TARGET_FOO aliases for OPTION_FOO (small change to the awk
> scripts and associated documentation, I expect).
>
> 2. Large, mechanical, automatically generated patch to change existing
> OPTION_FOO us
> Can you confirm that the class_optional_1.f90 of the trunk works correctly?
Yes: I have regtested with
make -k check-gfortran RUNTESTFLAGS="dg.exp=class_optional*
--target_board=unix'{-m32,-m64}'"
without failures.
The profile I have posted was for the former version of class_optional_2.f90.
This patch adds the clang thread safety warning flags as recognized
warning flags that do nothing, for command-line compatibility with
clang. Enclosed patch is for branches/google/gcc-4_6, I have
identical patches for google/gcc-4_7 and google/main.
Tested on linux x86.
--
DeLesley Hutchins | S
Quoting Richard Sandiford :
Joern Rennecke writes:
2012-10-04 Joern Rennecke
* final.c (get_attr_length_1): Use direct recursion rather than
calling get_attr_length.
(get_attr_lock_length): New function.
(INSN_VARIABLE_LENGTH_P): Define.
(shorte
On Tue, Oct 16, 2012 at 3:19 PM, Delesley Hutchins wrote:
> This patch adds the clang thread safety warning flags as recognized
> warning flags that do nothing, for command-line compatibility with
> clang. Enclosed patch is for branches/google/gcc-4_6, I have
> identical patches for google/gcc-4_
Yes, but that won't happen for a while yet.
On Tue, Oct 16, 2012 at 12:43 PM, Diego Novillo wrote:
> On Tue, Oct 16, 2012 at 3:19 PM, Delesley Hutchins
> wrote:
>> This patch adds the clang thread safety warning flags as recognized
>> warning flags that do nothing, for command-line compatibilit
Attached patch applied.
2012-10-16 François Dumont
* include/debug/formatter.h (_Debug_msg_id): Add
__msg_bucket_index_oob.
* include/debug/macros.h (__glibcxx_check_bucket_index): New.
* include/debug/unordered_set (unordered_set<>::begin(size_type)):
Add check on bucket
Committed.
google/gcc-4_6: r192510.
google/gcc-4_7: r192511.
google/main: r192513.
On Tue, Oct 16, 2012 at 12:44 PM, Delesley Hutchins wrote:
> Yes, but that won't happen for a while yet.
>
> On Tue, Oct 16, 2012 at 12:43 PM, Diego Novillo wrote:
>> On Tue, Oct 16, 2012 at 3:19 PM, Delesley Hutc
On Tue, Oct 16, 2012 at 04:58:48PM +0200, Jakub Jelinek wrote:
> @@ -2022,6 +2036,12 @@ assemble_variable (tree decl, int top_le
>if (DECL_ALIGN (decl) > BITS_PER_UNIT)
> ASM_OUTPUT_ALIGN (asm_out_file, floor_log2 (DECL_ALIGN_UNIT (decl)));
>assemble_variable_contents (decl, n
ping!
2012/10/11 Janus Weil :
> Hi all,
>
> here is an OOP patch for the above PR, which has two disconnected parts:
>
> 1) It fixes a problem with ASSOCIATED, when it is fed a CLASS-valued
> function as argument (i.e. the ICE in the bug title). This is the
> trans-intrinsic part of the patch. In
Janus,
Your patch works as advertised without disturbing my pet bugs.
Just a nit pick: the double parentheses in
+ if ((CLASS_DATA (select_type_stack->selector)->attr.dimension
|| CLASS_DATA (select_type_stack->selector)->attr.codimension))
do not seem necessary.
Note for Paul: I
Looks good except for the following:
1) I am not sure if the stack slot sharing is handled correctly. If I
read the code correctly, the redzone var will be only created for the
representative variable in a partition -- will this lead to false
negatives? As I asked before, should stack slot sharing
Vladimir Makarov writes:
> On 10/16/2012 02:44 AM, Richard Sandiford wrote:
>> Vladimir Makarov writes:
>>> On 12-10-15 4:25 PM, Richard Sandiford wrote:
Richard Sandiford writes:
> Vladimir Makarov writes:
>> After committing a patch yesterday to implement proposals from a
>>
> Yes, that is true. But when you say "if this trend continues" you are
> making a slippery slope argument that I don't think applies. To date,
> the trend consists of a single example. We are discussing adding a
> second example, and we may decide against it. There are no current
> prospects o
On Tue, Oct 16, 2012 at 7:58 AM, Jakub Jelinek wrote:
> Hi!
>
> This is a WIP patch for globals protection.
> I'm not filling names yet and has_dynamic_init is always
> false (wonder how to figure it has_dynamic_init out, especially
> with LTO, TYPE_ADDRESSABLE (TREE_TYPE (decl)) probably isn't it
On Tue, Oct 16, 2012 at 01:56:46PM -0700, Xinliang David Li wrote:
> Looks good except for the following:
>
> 1) I am not sure if the stack slot sharing is handled correctly. If I
> read the code correctly, the redzone var will be only created for the
> representative variable in a partition -- wi
On Tue, Oct 16, 2012 at 02:41:42PM -0700, Xinliang David Li wrote:
> > +bool
> > +asan_protect_global (tree decl)
> > +{
> > + rtx rtl, symbol;
> > + section *sect;
> > +
> > + if (TREE_CODE (decl) != VAR_DECL
> > + || DECL_THREAD_LOCAL_P (decl)
> > + || DECL_EXTERNAL (decl)
> > +
The powerpc port is running out of switches that set bits in target_flags, and
I am in the process of changing all of the switches to use a secondary flag
word that is HOST_WIDE_INT (at least 64-bits on powerpc). One of the changes
is that the options machinery changes all of the TARGET_ names to
On Tue, 9 Oct 2012, Oleg Endo wrote:
> This documents the new thread pointer built-ins in the SH www changes
> for 4.8.
Thanks, Oleg.
I've got one change and one question:
+Added support for the built-in functions
+__builtin_thread_pointer and
+__builtin_set_thread_pointer. This ass
On Tue, Oct 16, 2012 at 2:33 PM, Eric Botcazou wrote:
>> Yes, that is true. But when you say "if this trend continues" you are
>> making a slippery slope argument that I don't think applies. To date,
>> the trend consists of a single example. We are discussing adding a
>> second example, and we
On Tue, Oct 16, 2012 at 3:03 PM, Jakub Jelinek wrote:
> On Tue, Oct 16, 2012 at 02:41:42PM -0700, Xinliang David Li wrote:
>> > +bool
>> > +asan_protect_global (tree decl)
>> > +{
>> > + rtx rtl, symbol;
>> > + section *sect;
>> > +
>> > + if (TREE_CODE (decl) != VAR_DECL
>> > + || DECL_TH
The problem is that the macro unwinder code is changing the original
diagnostic type and not restoring it, so the code detecting that we
ICE fails to abort, which triggers another ICE, and so on. But there
is no point in modifying the original diagnostic, we can simply create
a temporary copy and u
On 2012-10-16 18:50 , Ian Lance Taylor wrote:
That is fine with me as long as we acknowledge that the upstream
sources don't care about GCC and will think it is absurd that they
should modify their code to carry untested and unmaintained
GCC-specific annotations. It would be one thing if the GC
1 - 100 of 119 matches
Mail list logo
