On Tue, Oct 16, 2012 at 11:51 PM, Jakub Jelinek wrote:
> On Tue, Oct 16, 2012 at 04:19:09PM -0700, Xinliang David Li wrote:
>> I am not sure -- fasan is an error detecting feature -- the goal is to
>> find bugs -- missing handling of commons etc. are not desirable.
>> Besides if ABI changes consi
Hello,
iq2000 build is broken since at least r162089 (July 2010). I'm going
to commit this patch to fix this part of the build problem. It still
fails later one, but I don't care about that, I just want to make sure
my patch to make call_used_regs a function looking at
call_used_reg_set break thin
On Tue, 16 Oct 2012, Diego Novillo wrote:
> 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
On Tue, Oct 16, 2012 at 9:35 PM, Joern Rennecke
wrote:
> 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_
Hi Steven,
iq2000 build is broken since at least r162089 (July 2010). I'm going
to commit this patch to fix this part of the build problem.
Thanks.
It still
fails later one, but I don't care about that
FYI I have this patch installed in my local sources that allows the
iq2000 port to buil
On Tue, 16 Oct 2012, Michael Meissner wrote:
> It occurs to me that now that we've committed to GCC being done in C++, we
> could just make global_options{,_set} be a class instead of a structure. So
> you could say:
>
> global_options.set_FOO (value)
>
> Or:
>
> global_options.set
On Tue, Oct 16, 2012 at 03:56:31PM -0700, Xinliang David Li wrote:
> >> 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
> >> negati
Hello Manuel,
Let's CC Gaby on this one as well.
Manuel López-Ibáñez writes:
> 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 n
> Does this still happen after my patch from yesterday to use DF_LIVE in IRA?
Yes, it even fails at -O2.
> Maybe add a cost-free dependency on the clobber, so that it's moved
> with the insn?
Maybe. But I'm a little worried about (1) extending the lifetime of the hard
register and (2) simply m
In GCC 4.8, module variables/procedures are marked as TREE_PUBLIC() if
they are PRIVATE and not publicly visible used in PUBLIC procedures; the
latter happens either via generic interfaces or via specification
expressions. (The bug is old [early 4.8] but due to a recent follow up
patch, the cha
On Tue, 16 Oct 2012, Jan Hubicka wrote:
> 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?
Ok.
Than
Ping!
Thanks,
Greta
-Original Message-
From: Greta Yorsh [mailto:greta.yo...@arm.com]
Sent: 10 October 2012 16:14
To: GCC Patches
Cc: Ramana Radhakrishnan; Richard Earnshaw; ni...@redhat.com;
p...@codesourcery.com
Subject: [Patch, ARM] cleanup prologue_use pattern
The pattern prologue_u
On 17/10/12 11:08, Greta Yorsh wrote:
Ping!
I've been pondering why this was being asked for. As far as I can tell
it's just a naming issue (mention of the epilogue in the prologue).
The right thing to do is to rename the pattern to reflect the dual use
rather than add additional patterns
On Tue, 16 Oct 2012, Diego Novillo wrote:
> 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]
This changes how we stream DECL_ARGUMENTS because the way we do it
now (recursing over TREE_CHAIN of the PARM_DECLs) puts quite a burden
on stack use for limits-fndefn.c. The following changes streaming
that chain to how we stream all other chains (apart from TREE_LISTs
which we arguably should c
On Tue, 16 Oct 2012, Jan Hubicka wrote:
> 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
> termin
All,
Ulrich posted the following patch in July:
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01123.html
Richard E requested that it be left in testing on trunk for a couple of days
before being backported to 4.7. Three months seems to satisfy the 'couple of
days' requirement :-).
Is this O
On Tue, Oct 16, 2012 at 02:41:42PM -0700, Xinliang David Li wrote:
> On Tue, Oct 16, 2012 at 7:58 AM, Jakub Jelinek wrote:
> Why the above two condition? If the linker picks the larger size one,
> it is ok to do the instrumentation.
Added more comments, creation of local aliases when needed, and
Thanks for all the updates.
Vladimir Makarov writes:
>>> + /* index * scale + disp => new base + index * scale */
>>> + enum reg_class cl = base_reg_class (mode, as, SCRATCH, SCRATCH);
>>> +
>>> + lra_assert (INDEX_REG_CLASS != NO_REGS);
>>> + new_reg = lra_create_new_reg (Pmode,
On 17 October 2012 11:55, Dodji Seketeli wrote:
> Hello Manuel,
>
> Let's CC Gaby on this one as well.
>
> Manuel López-Ibáñez writes:
>
>> 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 a
On Wed, Oct 17, 2012 at 11:55 AM, Eric Botcazou wrote:
>> Maybe add a cost-free dependency on the clobber, so that it's moved
>> with the insn?
>
> Maybe. But I'm a little worried about (1) extending the lifetime of the hard
> register and (2) simply moving around a clobber of a hard register.
AF
Vladimir Makarov writes:
> On 12-10-16 5:21 PM, Richard Sandiford wrote:
>> I realise you probably have patches pending as well, so I'm happy to
>> wait until those have gone in and update.
>>
> You can commit it into the branch. You have to do some work for
> conflict resolution (I added new he
insns are split.
OK.
R.
20121017-split-insns-noflow.txt
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 35b73c5..3796a80 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -13337,6 +13337,13 @@ arm_reorg (void)
if (TARGET_THUMB2)
thumb2_reorg ();
+ /*
avr_extra_arch_macro is not really needed, it just holds
avr_current_device->macro.
Thus, this tiny tidy up.
Ok for trunk?
Johann
* config/avr/avr-arch.h (avr_extra_arch_macro): Remove prototype.
* config/avr/avr.c (avr_extra_arch_macro): Remove variable.
(avr_option_o
I am attaching a new version of the patch, addressing Richard's comments.
This patch renames the exiting pattern prologue_use to force_register_use,
because the pattern is used in both prologue and epilogue.
No regression on qemu for arm-none-eabi.
Ok for trunk?
Thanks,
Greta
ChangeLog
gcc/
2012/10/17 Georg-Johann Lay :
> avr_extra_arch_macro is not really needed, it just holds
> avr_current_device->macro.
>
> Thus, this tiny tidy up.
>
> Ok for trunk?
>
> Johann
>
>
> * config/avr/avr-arch.h (avr_extra_arch_macro): Remove prototype.
> * config/avr/avr.c (avr_extra_ar
On 17/10/12 13:37, Greta Yorsh wrote:
I am attaching a new version of the patch, addressing Richard's comments.
This patch renames the exiting pattern prologue_use to force_register_use,
because the pattern is used in both prologue and epilogue.
No regression on qemu for arm-none-eabi.
Ok for
Jan Hubicka wrote:
this patch add __buliltin_unreachable to Fortran FE and also cleans up the code
a bit
Bootstrapped/regtested x86_64-linux, OK?
The Fortran part looks okay.
* f95-lang.c (gfc_define_builtin): Use set_call_expr_flags.
(ATTR_NOTHROW_LEAF_MALLOC_LIST,
On 10/16/2012 04:30 AM, Vladimir Makarov wrote:
> In insn:
>
> (define_insn_and_split "*lea_general_1"
> [(set (match_operand 0 "register_operand" "=r")
> (plus (plus (match_operand 1 "index_register_operand" "l")
> (match_operand 2 "register_operand" "r"))
> (match_ope
Hi,
I've just committed the attached patch on ARM/AArch64 branch.
It fixes a constraint and a scheduling attribute for the3
pattern.
Thanks
Sofiane
aarch64-update-logical-imm.patch
Description: Binary data
On 2012-10-17 06:14 , Richard Biener wrote:
Can't we implement vec_e as vec by
means of a partial specialization?
Ah, yes, that's certainly possible and prevents renaming the types in
the future.
I have not yet implemented the "fast" vectors from my proposal.
Those would be useful for free
Hi,
I've just committed the attached patch on ARM/AArch64-4.7 branch.
It fixes a constraint and a scheduling attribute for the3
pattern.
Thanks
Sofiane
aarch64-update-logical-imm.patch
Description: Binary data
> I don't understand what you mean with extending the life of the hard
> register in this case. If you move the clobber with the instruction,
> the hard reg is dead before the clobber and after the insn that uses
> it, just like when the insn is not hoisted from the loop. So you don't
> extend the
Bernd Schmidt writes:
> On 10/16/2012 04:30 AM, Vladimir Makarov wrote:
>> In insn:
>>
>> (define_insn_and_split "*lea_general_1"
>> [(set (match_operand 0 "register_operand" "=r")
>> (plus (plus (match_operand 1 "index_register_operand" "l")
>> (match_operand 2 "register_operan
On 10/08/12 17:46:03, Easwaran Raman wrote:
> I have attached a revised patch. The updated ChangeLog is given below
> and I have responded to your comments inline:
>
> 2012-10-08 Easwaran Raman
> * optabs.c (emit_cmp_and_jump_insn_1): Add a new parameter to
> specificy the probability of takin
Hi,
for this kind of code, using the GNU zero-size array extension:
int a[][0] = {0};
we end up looping forever in the reshape_init_array_1 loop because it
calls reshape_init_r -> reshape_init_array -> reshape_init_array_1 which
returns early a CONSTRUCTOR with no error. Having considered v
... oh well, I just realized that zero-size VECTORs don't make much
sense and are early rejected, thus I can improve my earlier patch.
Now I'm happier: essentially I'm only *moving* code around ;)
Thanks,
Paolo.
//
/cp
2012-10-17 Paolo Carlini
PR c++/54501
Hi,
This patch changes most trivial cases to use the new (Lang)EnabledBy.
Bootstrapped and regression tested on x86_64-linux-gnu. OK?
2012-10-17 Manuel López-Ibáñez
PR c/53063
PR c/40989
c-family/
* c.opt (Waddress,Wchar-subscripts,Wsign-conversion,Wimplicit,
Looks ok to me for the branch.
thanks,
David
On Wed, Oct 17, 2012 at 2:35 AM, Jakub Jelinek wrote:
> On Tue, Oct 16, 2012 at 03:56:31PM -0700, Xinliang David Li wrote:
>> >> 1) I am not sure if the stack slot sharing is handled correctly. If I
>> >> read the code correctly, the redzone var will
Yes, I think it is good for the branch.
thanks,
David
On Wed, Oct 17, 2012 at 4:11 AM, Jakub Jelinek wrote:
> On Tue, Oct 16, 2012 at 02:41:42PM -0700, Xinliang David Li wrote:
>> On Tue, Oct 16, 2012 at 7:58 AM, Jakub Jelinek wrote:
>> Why the above two condition? If the linker picks the larg
Mike,
This patch is okay with the appropriate changes to adapt to the common
infrastructure improvements.
We will continue to iterate on this.
Are there any testcases that would be useful? A lot of other testcases
use target flags, so those probably will point out problems.
Thanks, David
On Tu
google/integration: r192542.
On Tue, Oct 16, 2012 at 1:00 PM, Delesley Hutchins wrote:
> 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 Wed, Oct 17, 2012 at 12:26:42AM +, Joseph S. Myers wrote:
> On Tue, 16 Oct 2012, Michael Meissner wrote:
>
> > It occurs to me that now that we've committed to GCC being done in C++, we
> > could just make global_options{,_set} be a class instead of a structure. So
> > you could say:
> >
The following patch implements most proposals of Richard's review of
lra.c and lra-int.h.
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 192544.
2012-10-17 Vladimir Makarov
* Makefile.in (LRA_INT_H): Add $(BITMAP_H) $(RECOG_H)
$(INSN_ATTR_H) ins
On 12-10-15 12:49 PM, Richard Sandiford wrote:
Hi Vlad,
Some comments about the rest of LRA. Nothing major here...
Vladimir Makarov writes:
+/* Info about register in an insn. */
+struct lra_insn_reg
+{
+ /* The biggest mode through which the insn refers to the register
+ (remember the
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 provided by the target. There are also many
The attached patch eliminates the failures in
g++.dg/other/darwin-cfstring1.C
and obj-c++.dg/strings/const-cfstring-2.mm by adding -ftrack-macro-expansion=0
to dg-options which partially eliminates the remaining failures in PR
target/54404.
These changes eliminate the failures...
FAIL: g++.
On Wed, Oct 17, 2012 at 9:53 PM, Vladimir Makarov wrote:
> On 12-10-15 12:49 PM, Richard Sandiford wrote:
>> Getting rid of reload always seemed like a pipe dream, and if the only
>> known drawback of this replacement is that it takes a while on extreme
>> testcases, that's an amazing achievement.
> The patch is probably quite hard to review, sorry. I've made the changelog
> a bit more detailed than usual in order to list the individual points.
You meant scary, didn't you? :-)
> * expmed.c (store_bit_field_1): Remove unit, offset, bitpos and
> byte_offset from the outermost sc
Hi,
This patch fixes bugs introduced by my previous patch to propagate
profiles during switch expansion. Bootstrap and profiledbootstrap
successful on x86_64. Confirmed that it fixes the crashes reported in
PR middle-end/54957. OK for trunk?
- Easwaran
2012-10-17 Easwaran Raman
PR t
On 2012-10-17 07:11 , Jakub Jelinek wrote:
2012-10-17 Jakub Jelinek
* varasm.c: Include asan.h.
(assemble_noswitch_variable): Grow size by asan_red_zone_size
if decl is asan protected.
(place_block_symbol): Likewise.
(assemble_variable): If decl is asa
On 2012-10-17 05:35 , Jakub Jelinek wrote:
2012-10-17 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.h.
(asan_shadow_set): New variable.
(asan_shadow_cst, asan
> Eric, Rainer, what do you think of the other two options I outlined in
> my earlier message?
>
> 1- Copy the upstream testsuite into gcc/testsuite/asan. This gives us
> the flexibility of adding new tests as the GCC implementation matures.
>
> 2- Deal with libasan as we deal with zlib/boehm-gc
On 10/16/12 23:21, Jeff Law wrote:
On 10/16/2012 07:51 PM, Richard Henderson wrote:
On 2012-10-17 09:53, Aldy Hernandez wrote:
+/* Like memory_modified_in_insn_p, but return TRUE if INSN will
+ *SURELY* modify the memory contents of MEM. */
+bool
+memory_surely_modified_in_insn_p (const_rtx
Bootstrapped and regression tested on x86_64-linux-gnu. Since Wformat
didn't have Var() associated, its corresponding entry was set to -1,
which is what warning(OPT_Wformat) checks for. Therefore, any such
warnings which were not guarded by if(warn_format), were enabled by
default. I only found one
On Wed, Oct 17, 2012 at 6:26 AM, Manuel López-Ibáñez
wrote:
> On 17 October 2012 11:55, Dodji Seketeli wrote:
>> Hello Manuel,
>>
>> Let's CC Gaby on this one as well.
>>
>> Manuel López-Ibáñez writes:
>>
>>> The problem is that the macro unwinder code is changing the original
>>> diagnostic typ
On Oct 17, 2012, at 12:59 PM, Jack Howarth wrote:
> The attached patch eliminates the failures in
> g++.dg/other/darwin-cfstring1.C
> and obj-c++.dg/strings/const-cfstring-2.mm by adding
> -ftrack-macro-expansion=0
> Okay for gcc trunk?
Ok.
http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html claims the search
path for C++ headers starts with /usr/include/g++-v3 which hasn't been
true for many years.
2012-10-18 Jonathan Wakely
* doc/cpp.texi (Search Path): Fix outdated C++ path.
Tested with "make doc html" - OK for trunk a
On 10/17/2012 12:56 PM, Marc Glisse wrote:
+ if (!COMPARISON_CLASS_P (arg1))
+ {
+ if (TYPE_UNSIGNED (TREE_TYPE (arg1_type)))
+ {
+ arg1_type = signed_type_for (arg1_type);
+ arg1 = convert (arg1_type, arg1);
+ }
+ arg1 = buil
Hmm, I thought I fixed a very similar bug recently.
I'm concerned that this change will cause problems with brace-elision
situations. But then again, can we have a zero-length array followed by
anything else?
Jason
Fixed 16-bit widening multiplies by a constant by limiting constant
matches to 16 bit constants. Applied.
PR target/54950
* config/m32c/predicates.md (m32c_const_u16_operand): New.
* config/m32c/muldiv.md: Use it.
Index: config/m32c/predicates.md
These two tests currently fail if using gold, in the first instance
because powerpc64 gold doesn't support mixing old dot-sym objects
with new objects, and in the second instance because gold doesn't have
a --no-toc-sort option. Both macros ought to be defined for gold.
Tested etc. OK to apply ev
On Wed, 17 Oct 2012, Jason Merrill wrote:
On 10/17/2012 12:56 PM, Marc Glisse wrote:
+ if (!COMPARISON_CLASS_P (arg1))
+ {
+ if (TYPE_UNSIGNED (TREE_TYPE (arg1_type)))
+ {
+ arg1_type = signed_type_for (arg1_type);
+ arg1 = convert (arg1_type
On 10/17/2012 10:30 PM, Marc Glisse wrote:
For each component of a vector type,
result[i] = if MSB of c[i] is set ? b[i] : a[i].
Curious. Do you know why they produce and expect -1 for true? It
certainly seems to be a deliberate design choice, so I wonder what
motivated it.
I think people
On 18 Oct 2012, at 02:50, DJ Delorie wrote:
>
> Fixed 16-bit widening multiplies by a constant by limiting constant
> matches to 16 bit constants. Applied.
>
>PR target/54950
>* config/m32c/predicates.md (m32c_const_u16_operand): New.
>* config/m32c/muldiv.md: Use it.
>
> Index:
> Are you sure you meant to have an fprintf in a match_test ?
I definitely did not. Removed. Thanks!
On Wed, 17 Oct 2012, Jason Merrill wrote:
On 10/17/2012 10:30 PM, Marc Glisse wrote:
For each component of a vector type,
result[i] = if MSB of c[i] is set ? b[i] : a[i].
Curious. Do you know why they produce and expect -1 for true? It certainly
seems to be a deliberate design choice, so I
On 10/17/2012 11:15 PM, Marc Glisse wrote:
In the middle-end, VEC_COND_EXPR is documented to take a vector of 0 and
-1, and at expansion time, it gives vcond(x<0,y,z) to the target if its
first argument is not a comparison.
Maybe we should leave the first argument alone and let the middle end
68 matches
Mail list logo
