Ping.
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On
> Behalf Of Bin Cheng
> Sent: Tuesday, September 25, 2012 4:00 PM
> To: 'Richard Sandiford'
> Cc: Ramana Radhakrishnan; Richard Earnshaw; gcc-patches@gcc.gnu.org
> Subject: RE: [Updat
On Sun, Oct 7, 2012 at 7:05 AM, Andreas Schwab wrote:
> Ian Lance Taylor writes:
>
>> +/* Set *VAL to the value of the symbol for PC. */
>> +
>> +static _Bool
>> +__go_symbol_value (uintptr_t pc, uintptr_t *val)
>> +{
>> + *val = 0;
>> + backtrace_syminfo (__go_get_backtrace_state (), pc, symi
Hi Jeff,
Thanks for reviewing and sorry for this delayed message.
>
> > + /* Only decrease distance if bb has high register pressure or
EXPR
> > +is const expr, otherwise EXPR can be hoisted through bb without
> > +cost. */
> ?!? This comment makes no sense to me. To accurately kn
Hi Steven,
Thanks for the comments and sorry for the delay with this message.
> -Original Message-
>
> Hello,
>
> Thanks for the update. The first look wasn't a very thorough review, so I
have
> more comments now. Sorry for that, I should have taken the time for this
the
> first time rou
Attached is the updated patch. Yes, if we add a VRP pass before
profile pass, this patch would be unnecessary. Should we add a VRP
pass?
Thanks,
Dehao
On Sat, Oct 6, 2012 at 9:38 AM, Jan Hubicka wrote:
>> ping^2
>>
>> Honza, do you think this patch can make into 4.8 stage 1?
>
> + if (check
Oleg Endo wrote:
> I've just checked this against current trunk (rev 192193). The problem
> seems to be gone. There's also a total decrease of 152 bytes on this
> file without the patch. So it seems it was a different issue. The diff
> is now:
Thanks for looking into it quickly. The patch is
On Mon, 2012-10-08 at 03:53 +0200, Oleg Endo wrote:
> On Mon, 2012-10-08 at 09:45 +0900, Kaz Kojima wrote:
> > Oleg Endo wrote:
> > > The attached patch improves comparisons such as
> > > 'unsigned int <= 0x7FFF' on SH.
> > > As mentioned in the PR, for some reason, those comparisons do not go
On Mon, 2012-10-08 at 09:45 +0900, Kaz Kojima wrote:
> Oleg Endo wrote:
> > The attached patch improves comparisons such as
> > 'unsigned int <= 0x7FFF' on SH.
> > As mentioned in the PR, for some reason, those comparisons do not go
> > through the cstore expander. As a consequence the compar
On 7 October 2012 21:31, Manuel López-Ibáñez wrote:
> On 7 October 2012 22:13, Jonathan Wakely wrote:
>>
>> On Oct 7, 2012 12:00 AM, "NightStrike" wrote:
>>>
>>> On Sat, Oct 6, 2012 at 7:30 AM, Manuel López-Ibáñez
>>> wrote:
>>> > Hi,
>>> >
>>> > GCC now requires ISL and a very new CLOOG but dow
Oleg Endo wrote:
> The attached patch improves comparisons such as
> 'unsigned int <= 0x7FFF' on SH.
> As mentioned in the PR, for some reason, those comparisons do not go
> through the cstore expander. As a consequence the comparison doesn't
> get the chance to be canonicalized by the target
Hi,
R191338 did not completely fix the location for deallocator. This
patch covers more cases for deallocator.
Bootstrapped and passed gcc regression test on x86.
Okay for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2012-10-07 Dehao Chen
* tree-eh.c (lower_try_finally_onedest): Set correct locati
Fixing this bug, which effectively caused 0 to be emitted instead of
constants requiring more than one actual insn to generate (through the
base-plus-offset support, kind-of macro insns), i.e. like "LDA
$2,#0lx" instead of "LDA $2,#ff", gets rid of 193 of the
regressions from (some-early-ti
Jim,
This version of the VLE support patch is an improvement, although I
still am troubled by the number of changes to rs6000.md.
And can you suggest any way to re-factor rs6000_rtx_costs()?
Andrew suggested placing all of the patterns in vle.md independently
and without my prompting. VLE reall
Hello,
This patch changes the worklist-like bitmap in lra_eliminate() to an
sbitmap. Effect on compile time:
lra r192183: LRA virtuals elimination: 51.56 ( 6%)
with patch: LRA virtuals elimination: 14.02 ( 2%)
OK for the branch after bootstrap&test on x86_64-unknown-linux-gnu?
Ciao!
Steven
Oleg Endo wrote:
> Attached patch adds the GBR addressing mode stuff. I've added the
> '!NONJUMP_INSN_P (i)' check which should fix the crash. Could you
> please test again?
No new failures with the top level "make -k check" on cross
sh4-unknown-linux-gnu. OK for trunk.
Regards,
kaz
The --enable-libstdcxx-time=yes configure option fails to validate the
presence of a usable nanosleep() call on darwin. The fix is the trivial
change to the test used so that tp is declared as a struct for _POSIX_TIMERS <=
0.
Regression tested on x86_64-apple-darwin12. Okay for gcc trunk as we
On Sun, Oct 7, 2012 at 5:59 PM, Vladimir Makarov wrote:
> The following patch speeds LRA up more on PR54146. Below times for
> compilation of the test on gcc17.fsffrance.org (an AMD machine):
>
> Before:
> real=1214.71 user=1192.05 system=22.48
> After:
> real=1144.37 user=1124.31 system=20.11
Hi
On 7 October 2012 22:38, Steven Bosscher wrote:
> On Sun, Oct 7, 2012 at 10:31 PM, Manuel López-Ibáñez
> wrote:
>> Since isl and cloog need to be
>> configured/build in a special way to work with gcc
>
> They do?? I built isl and cloog on a few compile farm machines without
> any special configur
OK.
Jason
OK.
Jason
OK.
Jason
On Sun, Oct 7, 2012 at 10:31 PM, Manuel López-Ibáñez
wrote:
> Since isl and cloog need to be
> configured/build in a special way to work with gcc
They do?? I built isl and cloog on a few compile farm machines without
any special configure magic. What problems did you encounter?
Ciao!
Steven
On 7 October 2012 22:13, Jonathan Wakely wrote:
>
> On Oct 7, 2012 12:00 AM, "NightStrike" wrote:
>>
>> On Sat, Oct 6, 2012 at 7:30 AM, Manuel López-Ibáñez
>> wrote:
>> > Hi,
>> >
>> > GCC now requires ISL and a very new CLOOG but download_prerequisites
>> > does not download those. Also, there
Resending as plain text so the list doesn't reject it ...
On Oct 7, 2012 12:00 AM, "NightStrike" wrote:
>
> On Sat, Oct 6, 2012 at 7:30 AM, Manuel López-Ibáñez
> wrote:
> > Hi,
> >
> > GCC now requires ISL and a very new CLOOG but download_prerequisites
> > does not download those. Also, there i
Joerg Wunsch wrote:
As Oleg Endo wrote:
I think it's more user friendly to
first warn and then do.
The problem is that this option would better not have existed straight
from the beginning. When using it, the compiler is at the risk of
generating code that fails to link later, because the re
As Oleg Endo wrote:
> I think it's more user friendly to
> first warn and then do.
The problem is that this option would better not have existed straight
from the beginning. When using it, the compiler is at the risk of
generating code that fails to link later, because the relative calls
used co
On Sun, 2012-10-07 at 21:37 +0200, Georg-Johann Lay wrote:
> Oleg Endo wrote:
> > Maybe would be better to first make the option a no-op that prints a
> > warning in GCC, remove it from all documentations and mention the
> > deprecation in the wwwdocs changes. Then, in the next GCC release,
> > re
Oleg Endo wrote:
Weddington, Eric wrote:
Georg-Johann Lay wrote:
As already discussed, this patch removes the -mshort-calls command option
from avr-gcc.
Ok to apply?
Ok to apply, but...
If the change is on order, changes to wwwdocs will follow, i.e. deprecate
the option in 4.7 and tell it
Hi,
estimate_edge_time was originally derrived from estimate_edge_growth.
estimate_edge_growth returns estimated function body growth by inlining.
That is size_of_inlined_body-size_of_call_stmt.
For estimate_edge_time it is kind of confusing and led me to double
account time of call stmt in the bad
On Sat, Oct 6, 2012 at 4:52 AM, Vladimir Makarov wrote:
>> Without this patch:
>> Compressing live ranges: from 700458 to 391665 - 55%, pre_count
>> 40730653, post_count 34363983
>> max per-reg pre_count 12978 (228090, 2 defs, 2 uses) (reg/f:DI 228090
>> [ SR.25009 ])
>> max per-reg post_count 1096
On Sun, 2012-10-07 at 18:01 +, Weddington, Eric wrote:
>
> > -Original Message-
> > From: Georg-Johann Lay []
> > Sent: Friday, October 05, 2012 9:55 AM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Denis Chertykov; Weddington, Eric; Joerg Wunsch
> > Subject: [Patch,avr]: Remove -mshort-call
> -Original Message-
> From: Georg-Johann Lay []
> Sent: Friday, October 05, 2012 9:55 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Denis Chertykov; Weddington, Eric; Joerg Wunsch
> Subject: [Patch,avr]: Remove -mshort-calls option
>
> As already discussed, this patch removes the -mshort-calls
> On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka wrote:
> > Hi,
> > I added a santy check that after fixup all types that lost in the merging
> > are
> > really dead. And it turns out we have some zombies around.
> >
> > INTEGER_CST needs special care because it is special cased by the streamer.
>
Hello,
The attached patch adds a DF changeable flag to compute a subset of
reaching definitions that are also live at the program points they
reach. This is an idea I discussed with Paolo many years ago already,
but until today it hadn't really ever been close to the top of my todo
list, but tryin
Hi Vlad,
Thanks for working on this!
> - EXECUTE_IF_SET_IN_BITMAP (reg_live_out, 0, j, bi)
> -if (j >= FIRST_PSEUDO_REGISTER)
> - mark_pseudo_live (j);
> + EXECUTE_IF_SET_IN_BITMAP (reg_live_out, FIRST_PSEUDO_REGISTER, j, bi)
> +mark_pseudo_live (j);
FWIW, the above is optimized b
On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka wrote:
> Hi,
> I added a santy check that after fixup all types that lost in the merging are
> really dead. And it turns out we have some zombies around.
>
> INTEGER_CST needs special care because it is special cased by the streamer.
> We also
> do no
The following patch speeds LRA up more on PR54146. Below times for
compilation of the test on gcc17.fsffrance.org (an AMD machine):
Before:
real=1214.71 user=1192.05 system=22.48
After:
real=1144.37 user=1124.31 system=20.11
The patch should not change the generated code. About 2/3 of speed u
Hi,
I added a santy check that after fixup all types that lost in the merging are
really dead. And it turns out we have some zombies around.
INTEGER_CST needs special care because it is special cased by the streamer. We
also
do not want to do inplace modificaitons on it because that would corru
On 10/07/2012 09:19 AM, Richard Guenther wrote:
>In fact, you could argue that the tree level did it wrong (not that i am
>suggesting to change this). But it makes me think what was going on when
>the decision to make TYPE_PRECISION be an INT_CST rather than just a HWI was
>made. For that th
Ian Lance Taylor writes:
> +/* Set *VAL to the value of the symbol for PC. */
> +
> +static _Bool
> +__go_symbol_value (uintptr_t pc, uintptr_t *val)
> +{
> + *val = 0;
> + backtrace_syminfo (__go_get_backtrace_state (), pc, syminfo_callback,
> + error_callback, &val);
> + re
On Sun, Oct 7, 2012 at 3:11 PM, Kenneth Zadeck wrote:
>
> On 10/07/2012 08:47 AM, Richard Guenther wrote:
len seems redundant unless you want to optimize encoding.
>>len == (precision + HOST_BITS_PER_WIDE_INT - 1) /
>> HOST_BITS_PER_WIDE_INT.
>>>
>>> >
>>> >that is exactly what
On 10/07/2012 08:47 AM, Richard Guenther wrote:
len seems redundant unless you want to optimize encoding.
>>len == (precision + HOST_BITS_PER_WIDE_INT - 1) / HOST_BITS_PER_WIDE_INT.
>
>that is exactly what we do. However, we are optimizing time, not space.
>the value is always stored in compr
On Fri, Oct 5, 2012 at 6:34 PM, Kenneth Zadeck wrote:
> richard s,
> there are two comments that i deferred to you. that have the word richard
> in them,
>
> richi,
> thank, i will start doing this now.
>
> kenny
>
> On 10/05/2012 09:49 AM, Richard Guenther wrote:
>>
>> On Fri, Oct 5, 2012 at 2:
> Yeah, in hindsight, the patch was definitely lacking commentary.
> How about the patch below? It also fixes the partial int case
> and gets rid of the errant NOT hunk. Tested in the same way as before.
>
> Richard
>
>
> gcc/
> * machmode.h (GET_MODE_UNIT_PRECISION): New macro.
>
On 07.10.2012 12:01, Matthias Klose wrote:
> On 06.10.2012 22:46, Ian Lance Taylor wrote:
>> On Sat, Oct 6, 2012 at 8:09 AM, Matthias Klose wrote:
>>> current trunk fails to build on arm-linux with:
>>>
>>> In file included from ../../../../src/libbacktrace/backtrace.c:35:0:
>>> ../libgcc/unwind.h
Hi,
I believe that, as a general rule, a function taking a tsubst_flags_t
complain parameter should propagate it, thus, in particular, call the
*_sfinae variant of various helper functions we have got. The below
fixes a few places where we weren't doing that (+ a couple of minor
unrelated twe
Hi,
On 10/06/2012 03:52 PM, Jason Merrill wrote:
On 09/27/2012 07:08 AM, Paolo Carlini wrote:
Then checking error_operand_p (decl) in is_capture_proxy solves the
problem but now the question is: do we have reasons to believe that such
VAR_DECLs should never ever reach is_normal_capture_proxy?
Richard,
attached patch checks that unlinked uses do not contain ssa-names when renaming.
This assert triggers when compiling (without the fix) the PR54735 example.
AFAIU, it was due to chance that we caught the PR54735 bug by hitting the
verification failure, because the new vdef introduced by
Hi Tobias,
I have tested your patch, mostly the added test cases.
I think the test gfortran.dg/class_optional_2.f90 should be split:
it has too much tests lumped together. In addition
the test gfortran.dg/class_optional_1.f90 does not compile
because "symbol 'i' at (1) has no IMPLICIT type" (three
On 06.10.2012 22:46, Ian Lance Taylor wrote:
> On Sat, Oct 6, 2012 at 8:09 AM, Matthias Klose wrote:
>> current trunk fails to build on arm-linux with:
>>
>> In file included from ../../../../src/libbacktrace/backtrace.c:35:0:
>> ../libgcc/unwind.h: In function '_Unwind_decode_typeinfo_ptr':
>> ..
Eric Botcazou writes:
>> I think modelling it as a TRUNCATE operation is correct for
>> !TRULY_NOOP_TRUNCATION (it's the bug that Andrew pointed out).
>> And we shouldn't generate an actual TRUNCATE rtx for
>> TRULY_NOOP_TRUNCATION (the thing about making
>> simplify_gen_unary (TRUNCATE, ...) no w
"Maciej W. Rozycki" writes:
> On Tue, 25 Sep 2012, Richard Sandiford wrote:
>> Although I see the 4kp with its 32-cycle MULTs and MADDs is one where
>> MULT $0,$0 would be a really bad choice. Sigh. The amount of effort
>> required for this optimisation is getting a bit ridiculous.
>
> I have d
As Georg-Johann Lay wrote:
> As already discussed, this patch removes the -mshort-calls command
> option from avr-gcc.
> Ok to apply?
I'm more than happy with removing it.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: J
53 matches
Mail list logo
