Hello!
Recent go changes broke alpha bootstrap:
/bin/mkdir -p .; files=`echo
/space/homedirs/uros/gcc-svn/trunk/libgo/go/os/dir_largefile.go
/space/homedirs/uros/gcc-svn/trunk/libgo/go/os/dir.go
/space/homedirs/uros/gcc-svn/trunk/libgo/go/os/doc.go
/space/homedirs/uros/gcc-svn/trunk/libgo/go/os/e
On Thu, Oct 30, 2014 at 8:40 AM, Uros Bizjak wrote:
> Recent go changes broke alpha bootstrap:
> $files/space/homedirs/uros/gcc-svn/trunk/libgo/go/os/stat_atim.go:22:29:
> error: reference to undefined field or method ‘Mtim’
>modTime: timespecToTime(st.Mtim),
> ^
On Wed, Oct 29, 2014 at 4:35 PM, Marat Zakirov wrote:
> Hi folks!
>
> During asan performance tunning we tried to use VRP and found that it is
> path-insensitive and thus suboptimal. In example bellow "i" has VRP range
> 0..1000 across whole program but in loop body it is just 0..999.
>
> int a[10
The GNU Compiler Collection version 4.9.2 has been released.
GCC 4.9.2 is a bug-fix release from the GCC 4.9 branch
containing important fixes for regressions and serious bugs in
GCC 4.9.1 with more than 65 bugs fixed since the previous release.
This release is available from the FTP servers liste
Status
==
GCC 4.9.2 has been released, the branch is now open again
for regression and documentation fixes.
Unless some blocker bug is found, GCC 4.9.3 should be released
in March or April.
Quality Data
Priority # Change from Last Report
---
On 10/30/2014 01:27 PM, Richard Biener wrote:
Well, VRP is not path-insensitive - it is the value-ranges we are able
to retain after removing the ASSERT_EXPRs VRP inserts.
Why can't you do the ASAN optimizations in the VRP transform phase?
I think this is not Asan-specific: Marat's point was t
On Thu, Oct 30, 2014 at 02:16:04PM +0300, Yury Gribov wrote:
> On 10/30/2014 01:27 PM, Richard Biener wrote:
> >Well, VRP is not path-insensitive - it is the value-ranges we are able
> >to retain after removing the ASSERT_EXPRs VRP inserts.
> >
> >Why can't you do the ASAN optimizations in the VRP
On Thu, Oct 30, 2014 at 11:11:09AM +0100, Uros Bizjak wrote:
> On Thu, Oct 30, 2014 at 8:40 AM, Uros Bizjak wrote:
> > Recent go changes broke alpha bootstrap:
>
> > $files/space/homedirs/uros/gcc-svn/trunk/libgo/go/os/stat_atim.go:22:29:
> > error: reference to undefined field or method ‘Mtim’
>
On 10/30/2014 02:32 PM, Jakub Jelinek wrote:
On Thu, Oct 30, 2014 at 02:16:04PM +0300, Yury Gribov wrote:
On 10/30/2014 01:27 PM, Richard Biener wrote:
Well, VRP is not path-insensitive - it is the value-ranges we are able
to retain after removing the ASSERT_EXPRs VRP inserts.
Why can't you do
On 10/30/2014 04:19 PM, Marat Zakirov wrote:
On 10/30/2014 02:32 PM, Jakub Jelinek wrote:
On Thu, Oct 30, 2014 at 02:16:04PM +0300, Yury Gribov wrote:
On 10/30/2014 01:27 PM, Richard Biener wrote:
Well, VRP is not path-insensitive - it is the value-ranges we are able
to retain after removing t
On Thu, Oct 30, 2014 at 2:19 PM, Marat Zakirov wrote:
> On 10/30/2014 02:32 PM, Jakub Jelinek wrote:
>>
>> On Thu, Oct 30, 2014 at 02:16:04PM +0300, Yury Gribov wrote:
>>>
>>> On 10/30/2014 01:27 PM, Richard Biener wrote:
Well, VRP is not path-insensitive - it is the value-ranges we are
On Thu, Oct 30, 2014 at 04:19:24PM +0300, Marat Zakirov wrote:
> We didn't find reasonable performance gains to use VRP in asan. But even if
> we found we couldn't use it because it is not safe for asan. It make some
> optimistic conclusions invalid for asan.
>
> Adjusted VRP memory upper bound is
On Thu, Oct 30, 2014 at 5:46 AM, Dominik Vogt wrote:
> On Thu, Oct 30, 2014 at 11:11:09AM +0100, Uros Bizjak wrote:
>> On Thu, Oct 30, 2014 at 8:40 AM, Uros Bizjak wrote:
>> > Recent go changes broke alpha bootstrap:
>>
>> > $files/space/homedirs/uros/gcc-svn/trunk/libgo/go/os/stat_atim.go:22:29:
Now the error is gone on my nightly FreeBSD test systems,
I am getting the following:
In file included from /scratch2/tmp/gerald/gcc-HEAD/libcc1/plugin.cc:58:
In file included from /usr/include/c++/v1/string:438:
In file included from /usr/include/c++/v1/cwchar:107:
In file included from /usr/inc
Snapshot gcc-4.8-20141030 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20141030/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
We have a program like this:
A() {// hot func
...
}
B() {
A();// very hot
if (i) {
A(); // very cold
}
}
Both callsites of A will be inlined into B. In gcc func
save_inline_function_body in inline_transform stage, A's first clone
will be choosen and turned into a real func.
Something seems wrong:
in tree_function_version:
initialize_cfun (new_decl, old_decl,
old_entry_block->count);
>From the above we can see new_decl's entry BB's count will be the same
as old_decl (no scaling).
In copy_bb, new BB's profile count will also be the same as ol
On 30/10/14 21:47, Gerald Pfeifer wrote:
> Now the error is gone on my nightly FreeBSD test systems,
> I am getting the following:
>
> In file included from /scratch2/tmp/gerald/gcc-HEAD/libcc1/plugin.cc:58:
> In file included from /usr/include/c++/v1/string:438:
> In file included from /usr/inclu
18 matches
Mail list logo
