On Fri, Oct 12, 2012 at 11:13 PM, Ramana Radhakrishnan
wrote:
> On Tue, Sep 25, 2012 at 5:32 PM, Dinar Temirbulatov
> wrote:
>> Hi Ramana,
>> Here is obvious fix for PR49423, I just added pool range for
>
> Sorry for the late response - I've been on vacation.
>
> No it's not ok. These were remove
I'm having to correct my own comments again, sorry.
Richard Sandiford writes:
>> + /* If this is post-increment, first copy the location to the reload reg.
>> */
>> + if (post && real_in != result)
>> +emit_insn (gen_move_insn (result, real_in));
>
> Nit, but real_in != result can never b
Hello,
this patch provides an alternate pattern to let combine recognize scalar
operations that preserve the high part of a vector. If the strategy is all
right, I could do the same for more operations (mul, div, ...). Something
similar is also possible for V4SF (different pattern though), but
On Fri, 12 Oct 2012, Marc Glisse wrote:
Hello,
apparently, in the optimization that recognizes that {v[1],v[0]} is a
VEC_PERM_EXPR, I forgot to check that v is a 2-element vector... (not that
there aren't things that could be done if v has a different size, just not
directly a VEC_PERM_EXPR,
On 2012/10/12 06:55 AM, Oleg Endo wrote:
> This broke the recently added thread pointer built-ins on SH, but I was
> prepared for that, so no problem here. The attached patch is a straight
> forward fix.
>
> However, with the patch applied I get an ICE on one of the SH thread
> pointer tests: gc
On Sat, 2012-10-13 at 17:33 +0800, Chung-Lin Tang wrote:
> On 2012/10/12 06:55 AM, Oleg Endo wrote:
> > This broke the recently added thread pointer built-ins on SH, but I was
> > prepared for that, so no problem here. The attached patch is a straight
> > forward fix.
> >
> > However, with the pa
Hello,
I hadn't realized that dead registers can still reach EQ-notes. Fixed
with the attached patch.
Bootstrapped&tested with normal and release checking on
x86_64-unknown-linux-gnu and powerpc64-unknown-linux-gnu. OK for
trunk?
Ciao!
Steven
df_rd_lr_eq.diff
Description: Binary data
Hi,
first a question also to non-gfortraners: if I want to use std::map,
where do I "#include "? In system.h?
Now to the patch-specific part: in this PR, module files are produced
with random changes because the order in which symbols are written can
depend on the memory layout. This patc
ps I forgot to mention that I also changed write_generic to traverse the
tree in defined order, this is the same in the C++ and the C-only patch.
Cheers,
- Tobi
On 2012-10-13 15:26, Tobias Schlüter wrote:
Hi,
first a question also to non-gfortraners: if I want to use std::map,
where do I "
Hello,
This fixes the long-standing enhancement request to use DF_LIVE in
IRA. To quote the first comment in the PR:
IRA should be using the DF-LIVE sets, which are smaller than the DF-LR
sets when they are available (typically at O2 and above). The proper
sets can be conveniently accessed using
> The trouble area, and where I need help from either Rainer or Eric,
> is the Solaris2 bits.
>
> I think we need to move the Solaris assembler stuff over to a model
> where it passes:
>
> -m{32,64} -xarch=sparcFOO
>
> instead of using the v8plusX stuff to indicate 32bit. And that's
> the
On 12-10-13 9:40 AM, Steven Bosscher wrote:
Hello,
This fixes the long-standing enhancement request to use DF_LIVE in
IRA. To quote the first comment in the PR:
IRA should be using the DF-LIVE sets, which are smaller than the DF-LR
sets when they are available (typically at O2 and above). The p
On Sat, Oct 13, 2012 at 5:12 PM, Vladimir Makarov wrote:
> On 12-10-13 9:40 AM, Steven Bosscher wrote:
>>
>> Hello,
>>
>> This fixes the long-standing enhancement request to use DF_LIVE in
>> IRA. To quote the first comment in the PR:
>>
>> IRA should be using the DF-LIVE sets, which are smaller th
On Thu, 2012-10-11 at 23:53 -0400, Vladimir Makarov wrote:
> My biggest problem is ESL. I should use simpler phrases.
Heh, I'm not sure compiler speak qualifies as English. :)
> Is the following comment better?
>
> Presence of any pseudo in CALL_INSN_FUNCTION_USAGE does not affect value
> of
PR gcov-profile/44728
* gcov.c (create_file_names): When stripping extension only look
at base name.
---
gcc/gcov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gcov.c b/gcc/gcov.c
index cf26ce1..09831c2 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@
> Hello,
>
> I hadn't realized that dead registers can still reach EQ-notes. Fixed
> with the attached patch.
Hi,
thanks for working on this! I already comitted the testcase as
gcc.dg/webizer.c so there is no need to commit it again.
Honza
>
> Bootstrapped&tested with normal and release checki
Hi,
while proofreading loop-iv for possible cause of the miscompilation that turned
out to be webizer bug I noticed two minor problems.
1) determine_max_iter has path dealing with AND that is bogus, because
constant argument is always canonized to be second. Enabling the path
however somethim
On Sat, Oct 13, 2012 at 6:54 PM, Jan Hubicka wrote:
> 2) bounds are recorded as signed values intead of unsigned. This means
>that values with upper bit set gets promoted to almost infinity for
>double int.
Could you check and see if this change fixes PR54919?
Ciao!
Steven
On 10/12/12, Richard Biener wrote:
> On Oct 11, 2012 Xinliang David Li wrote:
>> On Oct 11, 2012 Lawrence Crowl wrote:
>>> On 10/10/12, Xinliang David Li wrote:
In a different thread, I proposed the following alternative to
'try_xxx':
template T* symbol::cast_to(symbol* p) {
On Sat, Oct 13, 2012 at 8:51 AM, Andreas Schwab wrote:
> PR gcov-profile/44728
> * gcov.c (create_file_names): When stripping extension only look
> at base name.
> diff --git a/gcc/gcov.c b/gcc/gcov.c
> index cf26ce1..09831c2 100644
> --- a/gcc/gcov.c
> +++ b/gcc/gcov.c
>
On Sat, Oct 13, 2012 at 12:44 PM, Lawrence Crowl wrote:
>> Thus, please re-use or follow existing concepts.
>
> Both are existing concepts. What I proposed is a common technique
> for avoiding the cost of dynamic_cast when down casting in a class
> hierarchy. Both concepts will work. I propose
On 2012-10-13 09:26 , Tobias Schlüter wrote:
Hi,
first a question also to non-gfortraners: if I want to use std::map,
where do I "#include "? In system.h?
No. Ada includes system.h in pure C code. Why not include it exactly
where you need it?
Diego.
On 2012-10-13 20:00, Diego Novillo wrote:
On 2012-10-13 09:26 , Tobias Schlüter wrote:
first a question also to non-gfortraners: if I want to use std::map,
where do I "#include "? In system.h?
No. Ada includes system.h in pure C code. Why not include it exactly
where you need it?
Ok, I wa
On 2012-10-13 14:04 , Tobias Schlüter wrote:
On 2012-10-13 20:00, Diego Novillo wrote:
On 2012-10-13 09:26 , Tobias Schlüter wrote:
first a question also to non-gfortraners: if I want to use std::map,
where do I "#include "? In system.h?
No. Ada includes system.h in pure C code. Why not in
Ian Lance Taylor writes:
> Why do you need the CONST_CAST? strrchr is a standard function and it
> takes const char * as the first argument. There is other code in gcc
> that calls strrchr with a const char * argument.
strrchr is overloaded as const and non-const in C++. We need the
non-const
On Fri, Oct 12, 2012 at 7:57 PM, Ulrich Weigand wrote:
> Hello,
>
> I was running a couple of tests on various platforms in preparation
> of getting the find_reload_subreg_address patch needed by aarch64 upstream:
> http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01421.html
>
> This unfortunately unc
On 12 October 2012 17:18, Joseph S. Myers wrote:
> On Fri, 12 Oct 2012, Manuel López-Ibáñez wrote:
>
>> I am trying to encode the relationship between Wstrict-aliasing and
>> Wstrict-aliasing= in the .opt files, and the same for Wstrict-overflow
>> and Wstrict-overflow=. However, the parameters of
On 10/12/12, Diego Novillo wrote:
> Add usage documentation for hash_table.
>
> Andrew, does this help?
>
> Lawrence, I think I've gotten the details right, but please confirm.
The patch merges the descriptor class with the element class,
which we do not currently do and which I don't think we sh
On Fri, Oct 12, 2012 at 10:59 AM, Paolo Carlini
wrote:
> On 10/12/2012 04:20 PM, Pavel Chupin wrote:
>>
>> Please see attached patch (applicable after revert).
>> I've moved libgcc libstdc++ common configure thread header chunk into
>> separate gthr.m4.
>> Could you please try it on AIX?
>>
>> Is
On Sat, Oct 13, 2012 at 11:23 AM, Andreas Schwab wrote:
> Ian Lance Taylor writes:
>
>> Why do you need the CONST_CAST? strrchr is a standard function and it
>> takes const char * as the first argument. There is other code in gcc
>> that calls strrchr with a const char * argument.
>
> strrchr i
On Sat, Oct 13, 2012 at 11:33 AM, Manuel López-Ibáñez
wrote:
>
> 1) Are references allowed now that C++ is the default?
I'm not sure we addressed those in the coding conventions. I would like to say:
1) const references are always fine;
2) non-const references as local variables are always fine
On 2012-10-13 14:40 , Lawrence Crowl wrote:
On 10/12/12, Diego Novillo wrote:
Add usage documentation for hash_table.
Andrew, does this help?
Lawrence, I think I've gotten the details right, but please confirm.
The patch merges the descriptor class with the element class,
which we do not cu
Ian Lance Taylor writes:
> Suppose you drop this into include/libiberty.h:
>
> #ifdef __cplusplus
> inline char *lbasename(char *s) { return const_cast(lbasename (s)); }
> #endif
That doesn't work:
../../gcc/libcpp/../include/libiberty.h: In function ‘char* lbasename(char*)’:
../../gcc/libcpp/.
This is the execution failure of gfortran.dg/vector_subscript_1.f90 on
SPARC/Solaris at -O3 -funroll-loops. The loop2_unroll dump of the reduced
testcase reads:
Loop 3 is simple:
simple exit 10 -> 12
number of iterations: (const_int -1 [0x])
upper bound: 1073741823
realist
> IRA should be using the DF-LIVE sets, which are smaller than the DF-LR
> sets when they are available (typically at O2 and above). The proper
> sets can be conveniently accessed using the df_get_live_[in,out]
> functions which use DF-LIVE if it is available and fall back to DF-LR
> if it is not.
On Sat, Oct 13, 2012 at 10:38 PM, Eric Botcazou wrote:
> So, in the end, does the patch enable DF_LIVE at -O1 or not? There seems to
> be a contradiction between the subject and the body of the message. If yes,
> perhaps an acceptable compromise would be to keep things unchanged at -O1.
Eh, rig
> On Fri, 12 Oct 2012, Jan Hubicka wrote:
>
> > > > * f95-lang.c (gfc_init_builtin_functions): Build
> > > > __builtin_unreachable.
> > >
> > > I wonder if other languages need similar adjustment?
> >
> > I also wondered ;) Only Fortran triggered, I will take a look.
> > >
> > > + /*
> I think it would be a good idea to keep things unchanged at -O1. For
> that, the patch needs a few minor modifications (remove calls to
> df_live_add_problem and make some code to update DF_LIVE_{IN,OUT}
> conditional). I can prepare an updated patch for that, if you think
> that's best.
That wa
On 12-10-13 11:37 AM, Steven Bosscher wrote:
On Sat, Oct 13, 2012 at 5:12 PM, Vladimir Makarov wrote:
On 12-10-13 9:40 AM, Steven Bosscher wrote:
Hello,
This fixes the long-standing enhancement request to use DF_LIVE in
IRA. To quote the first comment in the PR:
IRA should be using the DF-LIV
On Sat, Oct 13, 2012 at 11:05 PM, Eric Botcazou wrote:
>> I think it would be a good idea to keep things unchanged at -O1. For
>> that, the patch needs a few minor modifications (remove calls to
>> df_live_add_problem and make some code to update DF_LIVE_{IN,OUT}
>> conditional). I can prepare an u
Hello!
2012-10-13 Uros Bizjak
* config/alpha/alpha.md (I24MODE): New mode iterator.
(any_divmod): New code iterator.
(si3): Macroize expander from {div,mod,udiv,umod}si3 using
any_divmod code iterator.
(si3): Macroize expander from {div,mod,udiv,umod}di3
From: Eric Botcazou
Date: Sat, 13 Oct 2012 15:47:11 +0200
>> The trouble area, and where I need help from either Rainer or Eric,
>> is the Solaris2 bits.
>>
>> I think we need to move the Solaris assembler stuff over to a model
>> where it passes:
>>
>> -m{32,64} -xarch=sparcFOO
>>
>> ins
Hello,
Today appears to be RTL loop optimizer patch day, because here's
another patch...
The problem here is that variable expansion does not update REG_EQUAL
notes when it performs replacement of the renamed register.
I fixed this by using validate_replace_rtx_group(). There is already
code in
From: David Miller
Date: Sat, 13 Oct 2012 17:52:42 -0400 (EDT)
> The current assembler in Solaris Studio (called 'fbe') calls this
> stuff "sparc4" which I guess means "SPARC-T4 and later".
BTW, for reference, see:
http://docs.oracle.com/cd/E24457_01/html/E22003/fbe.1.html
On Sat, 13 Oct 2012, Diego Novillo wrote:
> On 2012-10-13 14:04 , Tobias Schlüter wrote:
> > On 2012-10-13 20:00, Diego Novillo wrote:
> > > On 2012-10-13 09:26 , Tobias Schlüter wrote:
> > > > first a question also to non-gfortraners: if I want to use std::map,
> > > > where do I "#include "? In
On Sat, 13 Oct 2012, Manuel L?pez-Ib??ez wrote:
> OK. The attached patch implements this. Does the approach look ok? I
> will write changelog and more comments if it seems reasonable. One
Without the comments explaining the semantics of the new functions and
their parameters, I'm not going to at
Hello,
This patch adds a short notice about some speed-ups in GCC 4.8 for
extremely large functions (coming from the work done on PR54146 by
several people).
OK for the wwwdocs?
Ciao!
Steven
Index: htdocs/gcc-4.8/changes.html
===
Ping.
On Mon, Oct 8, 2012 at 5:46 PM, 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 pr
Hi,
back in 2005 Alexandre worked on this issue up to the point that Mark
approved a patch conditional to a couple of straightforward changes (see
audit trail). Then nothing happened ;)
Today I resurrected the patch, implemented the requests and in the
process noticed that it wasn't really h
49 matches
Mail list logo
