On Thu, 13 Mar 2014, Cong Hou wrote:
> On Thu, Mar 13, 2014 at 2:27 AM, Richard Biener wrote:
> > On Wed, 12 Mar 2014, Cong Hou wrote:
> >
> >> Thank you for pointing it out. I didn't realized that alias analysis
> >> has influences on this issue.
> >>
> >> The current problem is that the epilogu
On Fri, Mar 14, 2014 at 08:52:07AM +0100, Richard Biener wrote:
> > Consider this fact and if there are alias checks, we can safely remove
> > the epilogue if the maximum trip count of the loop is less than or
> > equal to the calculated threshold.
>
> You have to consider n % vf != 0, so an argum
On Fri, 14 Mar 2014, Jakub Jelinek wrote:
> On Fri, Mar 14, 2014 at 08:52:07AM +0100, Richard Biener wrote:
> > > Consider this fact and if there are alias checks, we can safely remove
> > > the epilogue if the maximum trip count of the loop is less than or
> > > equal to the calculated threshold.
The following fixes PR60518 where split_block does not fixup
all loops that the block was a latch of (without simple latches
a latch need not belong to its loop but can be an exit block
of a nested loop).
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2014-03-14 Richard Bi
On Thu, 13 Mar 2014, Cesar Philippidis wrote:
> On 3/13/14, 2:52 AM, Richard Biener wrote:
> > On Thu, Mar 13, 2014 at 10:31 AM, Richard Biener
> > wrote:
> >> On Thu, Mar 13, 2014 at 1:10 AM, Cesar Philippidis
> >> wrote:
> >>> I noticed that the lto-wrapper is a little noisy without the -v opt
> This would suggest that you can use the pattern also for performing a normal
> add in case the condition code is not needed afterwards but this isn't
> correct for s390 31 bit where an address calculation is actually something
> different.
Then you should document that by stating that the patter
Hi!
Ping.
On Fri, 07 Mar 2014 21:21:48 +0100, I wrote:
> On Fri, 15 Nov 2013 14:44:45 -0700, Aldy Hernandez wrote:
> > I fixed a few nits Jason pointed out off-line, and both him and Jakub
> > have approved the patch for trunk.
> >
> > In running the final round of tests I noticed a few proble
Hi!
$ ../configure --enable-foo='--enable-a=1 --enable-b=2 --enable-c=3'
[...]
$ make configure-zlib
config.status: creating Makefile
config.status: executing default-1 commands
../../zlib/../config-ml.in: eval: line 142: unexpected EOF while looking
for matching `''
.
On 14/03/14 11:02, Eric Botcazou wrote:
>> This would suggest that you can use the pattern also for performing a normal
>> add in case the condition code is not needed afterwards but this isn't
>> correct for s390 31 bit where an address calculation is actually something
>> different.
>
> Then you
On Fri, Mar 14, 2014 at 6:36 AM, Ryan Hill wrote:
> On Mon, 18 Nov 2013 19:04:59 +0100
> Jan Hubicka wrote:
>
>> Hi,
>> this patch switches the default for fat-lto-objects as was documented for a
>> while. -ffat-lto-objects doubles compilation time and often makes users to
>> not notice that LTO
On Fri, Mar 14, 2014 at 4:05 AM, Andrew Pinski wrote:
> On Wed, Feb 5, 2014 at 2:29 AM, Venkataramanan Kumar
> wrote:
>> Hi Marcus,
>>
>>> + "ldr\\t%x2, %1\;str\\t%x2, %0\;mov\t%x2,0"
>>> + [(set_attr "length" "12")])
>>>
>>> This pattern emits an opaque sequence of instructions that cannot be
Hi Venkat
On 5 February 2014 10:29, Venkataramanan Kumar
wrote:
> Hi Marcus,
>
>> + "ldr\\t%x2, %1\;str\\t%x2, %0\;mov\t%x2,0"
>> + [(set_attr "length" "12")])
>>
>> This pattern emits an opaque sequence of instructions that cannot be
>> scheduled, is that necessary? Can we not expand individua
Index: steering.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/steering.html,v
retrieving revision 1.37
diff -c -p -r1.37 steering.html
*** steering.html 8 Dec 2013 21:04:17 - 1.37
--- steering.html 14 Mar 2014 14:33:
On Fri, Mar 14, 2014 at 10:40:22AM -0400, David Edelsohn wrote:
> ! Joseph Myers (CodeSourcery / Mentor Graphics) [co-Release Maanger]
s/Maanger/Manager/
Marek
Applied, thanks.
Jason
Rainer Orth writes:
>>> > For this particular case at least.
>>> >
>>> > Note that I'm not against linking against static libgcc_s for
>>> > lto-plugin. The -static-libstdc++ we use is just because during
>>> > bootstrap picking up the correct libstdc++ was deemed too hard
>>> > to implement and
Hi,
This patch adds vdup intrinsic testcases for AArch64. those testcases
are nice to have, as it allows to reason about vdup consistency for
both LE and BE compiler flavors.
This patch covers following intrinsics:
vdup_lane_f32
vdup_lane_s[8,16]
vdup_lane_s[32,64]
vdup_n_[p,s,u][8,16]
vdup_n_[s
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60508
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 208570.
2014-03-14 Vladimir Makarov
PR rtl-optimization/60508
* lra-constraints.c (get_reload_reg): Add new parame
On Fri, 14 Mar 2014, Rainer Orth wrote:
> Rainer Orth writes:
>
> >>> > For this particular case at least.
> >>> >
> >>> > Note that I'm not against linking against static libgcc_s for
> >>> > lto-plugin. The -static-libstdc++ we use is just because during
> >>> > bootstrap picking up the corre
This patch makes sure that we set the directory prefix of
dump_base_name only once, otherwise we'd end up with invalid path,
resulting in error: could not open dump file ...
This happened because finish_options is called for every optimize
attribute and once more for command line options and every
Committed to branch dmalcolm/jit:
gcc/jit/
* libgccjit.c (is_valid_cast): Permit casts between pointer types.
* internal-api.c (convert): Report more information if this ever
occurs, and make the error occur on the playback context, so that
it makes the gcc_jit_res
On Fri, 14 Mar 2014, Marek Polacek wrote:
> This patch makes sure that we set the directory prefix of
> dump_base_name only once, otherwise we'd end up with invalid path,
> resulting in error: could not open dump file ...
> This happened because finish_options is called for every optimize
> attrib
This removes the _ZNSt12system_errorC* pattern from the GLIBCXX_3.4.11
version, because it doesn't seem to be used at the moment, but inlining
changes being tested for PR ipa/58721 cause some new symbols to be
added to the library and exported with version GLIBCXX_3.4.11, which
obviously shouldn't
Fix some inaccurate comments, especially the asymptotic complexity
mark: o() => \Omega().
Thanks!
--
Regards,
Tim Shen
commit 7db473c494866d071087f3e7465e36cc96a918b1
Author: tim
Date: Fri Mar 14 14:50:12 2014 -0400
2014-03-14 Tim Shen
* include/bits/regex_compiler.h: Ad
Honza suggested that if the destructor for an abstract class can't ever
be called through the vtable, the front end could avoid referring to it
from the vtable. This patch replaces such a destructor with
__cxa_pure_virtual in the vtable.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3
On 14/03/14 14:55 -0400, Tim Shen wrote:
Fix some inaccurate comments, especially the asymptotic complexity
mark: o() => \Omega().
If all the tests pass this is OK for trunk, thanks.
N.B. the patch is fine but I don't think we usually say
@brief Class FooBar. Does some Foo and some Bar.
ju
Hi all,
attached is a patch which implicitly sets the SAVE attribute for all
variables in the main program, as demanded by the Fortran 2008
standard. This fixes an ICE with pointer initialization (see
pointer_init_9.f90). Also a few exisiting test cases had to be changed
to accomodate for the modi
Janus Weil wrote:
Regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk or wait for
next stage1?
Looks good to me - and simple enough for the 4.9 trunk.
Tobias
Hi all,
I have committed the attached patch to the Fortran-CAF branch. It paves
the road to CAF sending support by declaring caf_send - and implementing
it in libcaf_single.c (as memmove). Additionally, I cleaned up the
library by handling the token in a better way (more readable - and
permit
I forgot to attach the patch.
Tobias Burnus wrote:
Hi all,
I have committed the attached patch to the Fortran-CAF branch. It
paves the road to CAF sending support by declaring caf_send - and
implementing it in libcaf_single.c (as memmove). Additionally, I
cleaned up the library by handling t
Hi
I just realized that when I committed this:
2014-01-20 François Dumont
* scripts/create_testsuite_files: Add testsuite/experimental in
the list of folders to search for tests.
* include/experimental/string_view
(basic_string_view<>::operator[]): Comment
On 14/03/14 22:26 +0100, François Dumont wrote:
I forgot to commit the create_testsuite_files script. Is it still ok
to do so now ?
Yes, since this was meant to be commited earlier it's OK to commit
now (assuming it doesn't introduce any new failures) - thanks.
By the way is there an info abo
On Fri, Mar 14, 2014 at 12:58 AM, Richard Biener wrote:
> On Fri, 14 Mar 2014, Jakub Jelinek wrote:
>
>> On Fri, Mar 14, 2014 at 08:52:07AM +0100, Richard Biener wrote:
>> > > Consider this fact and if there are alias checks, we can safely remove
>> > > the epilogue if the maximum trip count of th
Oops, need to make sure dtor is non-null before looking at it...
We also might as well handle this after the dfs is done.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 142f595d2474a05c59991e8ea7a5f6712d9982ff
Author: Jason Merrill
Date: Fri Mar 14 20:38:10 2014 -0400
PR c++/6053
The attached patch fixes this problem by first reading the next available char
to see if EOF is encountered. If so, issue the EOF error. If not use eat_line
to find the end of the line. If the end of the line is at the end of the file,
it will be caught on any subsequent attempt to read.
The pro
This bug report had various testcases that had to do with full loop
unrolling with non-automatic iterators and fixed boundaries, which
resulted in duplicating debug stmts in the loop for each iteration. In
some cases, the resulting executable code is none, but the debug stmts
add up to millions.
This PR is fallout from my patch from yesterday, which adjusted some of the
i386 float->int conversion patterns. In the gcc-patches message for that
change, I opined that in stage1 we should clean up all of these patterns.
Except that the existing state of affairs appears to have been too complex
On Mar 14, 2014, at 7:45 PM, Alexandre Oliva wrote:
> In some cases, the resulting executable code is none, but the debug stmts
> add up to millions.
I’d like to think there is a better theoretic answer to the specific problem…
trimming random debug info I think just invites a bad experience wh
Hi,
You are receiving this message because you are in top 50 contributors to GCC
[1]. Congratulations!
Since you are a top contributor to GCC project it is important for you to rate
the incoming student GSOC applications. Go and register at
https://www.google-melange.com/gsoc/homepage/google
39 matches
Mail list logo
