On Fri, Aug 30, 2013 at 9:58 PM, Teresa Johnson tejohn...@google.com wrote:
Besides, we might also want to
use the same machinery (dump_printf_loc etc) for dump file dumping.
The current behavior of using '-details' to turn on opt-info-all
messages for dump files are not desirable.
On 30 August 2013 23:23:16 Teresa Johnson tejohn...@google.com wrote:
On Fri, Aug 30, 2013 at 1:30 PM, Xinliang David Li davi...@google.com wrote:
On Fri, Aug 30, 2013 at 12:51 PM, Teresa Johnson tejohn...@google.com
wrote:
On Fri, Aug 30, 2013 at 9:27 AM, Xinliang David Li davi...@google.com
Jakub Jelinek ja...@redhat.com wrote:
On Fri, Aug 30, 2013 at 11:28:34AM -0400, Diego Novillo wrote:
Well, it was a wrong decision then. For some smaller types writing
manual
marker might be a sensible thing, or for some extra complicated
constructs. But here we're talking about the most
Diego Novillo dnovi...@google.com wrote:
On Fri, Aug 30, 2013 at 11:37 AM, Jakub Jelinek ja...@redhat.com
wrote:
Teaching the gengtype parser about
{struct,class} name : public {struct,class} someothername { ... }
as opposed to current
{struct,class} name { ... }
shouldn't be that hard.
Hi,
stephen.w...@bregmasoft.ca wrote:
Other than the test case (breaks on mingw32 target) this is looking
very sweet.
Could you please show some details?
I suppose he referred to the char/wchar_t split which I described...
Thanks!
Paolo
Bootstrapped/regtesed x86_64-linux. Martin, please can you review the
change?
* ipa-prop.c (ipa_set_jf_known_type): Check that component type
is a record type with BINFO.
(detect_type_change_ssa): Add comp_type argument.
(compute_complex_assign_jump_func): Add
Hello!
The compilation emitted following sequence for cmove with unsigned
compare, resulting in gfortran.dg/pr32533.f90 runtime failure [1]:
(insn 70 69 71 (set (reg:DI 143)
(leu:DI (reg:DI 139)
(const_int 18 [0x12]))) -1
(nil))
(insn 71 70 72 (set (reg:DF 144)
On Sat, 2013-08-31 at 11:57 +0200, Richard Biener wrote:
Diego Novillo dnovi...@google.com wrote:
Yes. Lawrence and I thought about moving gengtype inside g++. That
seemed like a promising approach.
What do you do during stage1? Have a collector that never collects?
We could imagine
On Thu, 2013-08-29 at 12:20 -0400, David Malcolm wrote:
This patch is 110KB in size, so to avoid mailing-list size limits I've
uploaded it to:
http://dmalcolm.fedorapeople.org/gcc/large-patches/a89d361b4f95dd216e1d29cb44fbaf90372c48b8-0003-Autogenerated-conversion-of-gimple-to-C.patch
The
Hi,
PPC64 lto profiledbootstrap failes because counts get negative in iteger
scalling.
Because of lost comdat samples, we end up with function called twice being
inlinined into an call happening few thousdand times. gcov_scale is then large
and apply_scale should not truncate it to 32bit.
On Fri, 2013-08-30 at 10:04 +0200, Richard Biener wrote:
On Thu, Aug 29, 2013 at 6:20 PM, David Malcolm dmalc...@redhat.com wrote:
* gimple.c (gt_ggc_mx (gimple)): New, as required by GTY((user)).
(gt_pch_nx (gimple)): Likewise.
(gt_pch_nx (gimple,
On Sat, Aug 31, 2013 at 5:57 AM, Richard Biener
richard.guent...@gmail.com wrote:
What do you do during stage1? Have a collector that never collects?
Yes. That was the pebble in the shoe. The cc1plus built for the
purposes of gengtype does not need to look at a lot of code, so
turning off
On Sat, Aug 31, 2013 at 12:26 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
On 30 August 2013 23:23:16 Teresa Johnson tejohn...@google.com wrote:
On Fri, Aug 30, 2013 at 1:30 PM, Xinliang David Li davi...@google.com
wrote:
On Fri, Aug 30, 2013 at 12:51 PM, Teresa Johnson
Hi,
this patch fixes ugly thinko when looking up reference for a speculative call.
Without LTO we can end up choosing wrong alternative for function with many
devirtualizations
(as it happens for PPC64)
Bootstrapped/regtested ppc64-linux, comitted.
Honza
Index: ChangeLog
On Fri, 2013-08-30 at 10:09 +0200, Richard Biener wrote:
On Thu, Aug 29, 2013 at 9:44 PM, Steven Bosscher stevenb@gmail.com
wrote:
On Thu, Aug 29, 2013 at 6:20 PM, David Malcolm dmalc...@redhat.com wrote:
* gimple.c (gt_ggc_mx (gimple)): New, as required by GTY((user)).
Hi,
as noticed by Martin Liska, -O0 -fprofile-generate code won't land into
__gcov_fork. This is due to early exit from expand_builtin.
Fixed and will be comitted as obvious.
Honza
* builtins.c (expand_builtin): Do not exit early for gcov
instrumented functions.
*
Hi,
On 30 Aug 2013, at 20:43, Jakub Jelinek wrote:
On Fri, Aug 30, 2013 at 09:38:01PM +0200, Dominique Dhumieres wrote:
I've just merged ubsan into trunk. Please send complaints my way.
Bootstrap is broken on x86_64-apple-darwin10:
(wonder why not
libasan_la_LIBADD =
On Sat, Aug 31, 2013 at 04:04:03PM +0100, Iain Sandoe wrote:
Hi,
On 30 Aug 2013, at 20:43, Jakub Jelinek wrote:
On Fri, Aug 30, 2013 at 09:38:01PM +0200, Dominique Dhumieres wrote:
I've just merged ubsan into trunk. Please send complaints my way.
Bootstrap is broken on
On Fri, Aug 30, 2013 at 06:58:06PM -0400, David Edelsohn wrote:
This patch / merge broke bootstrap on AIX:
In file included from ./tm.h:18:0,
from /home/dje/src/src/gcc/function.h:26,
from /home/dje/src/src/gcc/basic-block.h:25,
from
Hi,
With Martin we made script for testing the profiling failures.
First do
ld --verbose ~/script
then apply
--- /home/jh/script22013-08-31 17:59:11.0 +0200
+++ /home/jh/script 2013-08-31 17:39:40.0 +0200
@@ -1,12 +1,3 @@
-GNU ld (GNU Binutils for Debian)
Hi,
remember_with_vars walks trees that are read from file (now unique)
and looks for fields that can contain pointers to vars or functions and
if so, it records them to global hashtable for later fixup.
This is quite wasteful, because the hash is querried many times.
We can simply walk all fields
On Sat, 31 Aug 2013, Cong Hou wrote:
I don't see why it would be unsafe for logb - can you give an example
(exact float input value as hex float, and the values you believe logb
should return for float and double).
Please try the following code (you will get different results whether
Jan Hubicka hubi...@ucw.cz wrote:
Hi,
remember_with_vars walks trees that are read from file (now unique)
and looks for fields that can contain pointers to vars or functions and
if so, it records them to global hashtable for later fixup.
This is quite wasteful, because the hash is querried many
David Malcolm dmalc...@redhat.com wrote:
On Fri, 2013-08-30 at 10:09 +0200, Richard Biener wrote:
On Thu, Aug 29, 2013 at 9:44 PM, Steven Bosscher
stevenb@gmail.com wrote:
On Thu, Aug 29, 2013 at 6:20 PM, David Malcolm
dmalc...@redhat.com wrote:
* gimple.c (gt_ggc_mx (gimple)):
On 31 August 2013 19:15:46 Richard Biener rguent...@suse.de wrote:
Jan Hubicka hubi...@ucw.cz wrote:
Hi,
remember_with_vars walks trees that are read from file (now unique)
and looks for fields that can contain pointers to vars or functions and
if so, it records them to global hashtable for
On Fri, Aug 30, 2013 at 8:18 PM, Thomas Koenig tkoe...@netcologne.de wrote:
Hello world,
the attached patch documents the format for unformatted sequential
files and what is, and is not, supported with special files.
Tested with make dvi and make info. OK for trunk?
The unformatted
bootstrapped x86_64-darwin12 for c,c++ and fortran ...
Bootstrapped x86_64-apple-darwin10 for c,c++,fortran,java and
also tested asan.exp and ubsan.exp for gcc and g++.
Thanks for the patch,
Dominique
This patch fixes that by introducing GXX_LINK which is GCC_LINK except
that CXX (e.g. xg++) instead of CC (e.g. xgcc) is invoked.
Eric, are there other executables that need to be linked with GXX_LINK
too but aren't triggered yet?
Yes, all not covered executables linking with TOOLS_LIBS
Eric Botcazou ebotca...@adacore.com writes:
| This patch fixes that by introducing GXX_LINK which is GCC_LINK except
| that CXX (e.g. xg++) instead of CC (e.g. xgcc) is invoked.
|
| Eric, are there other executables that need to be linked with GXX_LINK
| too but aren't triggered yet?
|
|
Hi,
I run my script on execute testsuite and looked into few testcases. The problem
I found
was roundoff errors - i.e. when expanding switch we set 50% chage that out of
bound
value is above or bellow. Both gets rounded to 0, because switch is executed
once
and the value is bellow.
Partly
In a recent change to AIX 7, the assert.h header defines
static_assert. I presume this was intended not to avoid conflicts
with the new C++ keyword. Sigh. However, the definition is not
protected from C++, which causes problem if the header is included in
C++ code, which it is in libstdc++.
Sure. Looks fine. Please apply to all active branches.
On Sat, Aug 31, 2013 at 4:40 PM, David Edelsohn dje@gmail.com wrote:
32 matches
Mail list logo
