Steven Bosscher wrote:
This reduces peak memory usage for the small test case of PR54146
Bootstrapped&tested on x86_64-unknown-linux-gnu. OK for trunk?
I think it's your patch which breaks bootstrapping here:
Checking multilib configuration for libgcc...
...
checking for suffix of object files
On Fri, Aug 17, 2012 at 9:11 PM, Gabriel Dos Reis
wrote:
> On Fri, Aug 17, 2012 at 1:03 PM, Mike Stump wrote:
>> On Aug 17, 2012, at 6:58 AM, Paolo Carlini wrote:
>>> On 08/17/2012 01:26 PM, Richard Guenther wrote:
This gets rid of this field, pushing it into a short int in tree_base
(h
On Sat, Aug 18, 2012 at 3:36 AM, Gary Funck wrote:
>
> Paul Hargrove noted the following build failure on
> an older x86-32 Linux (Redhat 8.0) system.
>
> g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall
> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common
> -DHAVE_CO
On Sat, Aug 18, 2012 at 6:17 AM, Andrew Pinski wrote:
> Hi,
> I implemented this patch almost 6 years ago when the df branch was
> being worked on. It adds valgrind support to alloc-pool.c to catch
> cases of using memory after free the memory.
>
> OK? Bootstrapped and tested on x86_64-linux-
Hello!
After discussion with Oleg, it looks that it is enough to prevent
wrong registers in the output of the (multi-output) insn pattern. As
far as inputs are concerned, combine already handles limited reload
classes in the right way. The problem with x86 is, that reload tried
to fix output opera
> +{
> + cs_prg->num = cs_tprg->num;
> + /* Allocate the working set array for the merged summary.
> */
> + if (ws_cnt)
> +{
> + cs_prg->working_set_count = ws_cnt;
> +
On Sat, Aug 18, 2012 at 10:14 AM, Uros Bizjak wrote:
> After discussion with Oleg, it looks that it is enough to prevent
> wrong registers in the output of the (multi-output) insn pattern. As
> far as inputs are concerned, combine already handles limited reload
> classes in the right way. The pro
Gabriel Dos Reis ha scritto:
>C++11 says that an implementation should be able to handle at least
>2^10
>template parameters, 2^12 members declared in a single class.
Thanks a lot Gaby for pointing out this, I overlooked it.
Paolo
On Sat, Aug 18, 2012 at 9:01 AM, Tobias Burnus wrote:
> Steven Bosscher wrote:
>>
>> This reduces peak memory usage for the small test case of PR54146
>> Bootstrapped&tested on x86_64-unknown-linux-gnu. OK for trunk?
>
>
> I think it's your patch which breaks bootstrapping here:
>
> Checking multi
Hello,
here is a new patch (passes bootstrap+regtest), which only combines
permutations if the result is the identity. I'll file a PR about more general
combinations to link to this conversation and the cost hook proposition.
Ok?
2012-08-18 Marc Glisse
gcc/
* fold-const.c (fold_ter
Steven Bosscher wrote:
On Sat, Aug 18, 2012 at 9:01 AM, Tobias Burnus wrote:
I think it's your patch which breaks bootstrapping here:
Program received signal SIGSEGV, Segmentation fault.
0x005bfa40 in bitmap_obstack_free (map=0x18693a0) at
/projects/tob/gcc-git/gcc/gcc/bitmap.c:388
388
On Sat, Aug 18, 2012 at 12:21 PM, Tobias Burnus wrote:
> I filled a small bug report at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54313
Yup, thanks.
* dse.c (dse_step7): Don't free kill_on_calls bitmap, it is
freed when its obstack is release.
Index: dse.c
==
On Sat, Aug 18, 2012 at 12:28 PM, Steven Bosscher wrote:
> On Sat, Aug 18, 2012 at 12:21 PM, Tobias Burnus wrote:
>> I filled a small bug report at
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54313
>
> Yup, thanks.
>
> * dse.c (dse_step7): Don't free kill_on_calls bitmap, it is
> freed
On Sat, Aug 18, 2012 at 12:39 PM, Richard Guenther
wrote:
> On Sat, Aug 18, 2012 at 12:28 PM, Steven Bosscher
> wrote:
>> On Sat, Aug 18, 2012 at 12:21 PM, Tobias Burnus wrote:
>>> I filled a small bug report at
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54313
>>
>> Yup, thanks.
>>
>>
On Sat, 18 Aug 2012, Ian Lance Taylor wrote:
> Looking at the #if just before this one, it looks like you've omitted
> the checks for a version of glibc before 2.2.2. Also I'm not sure how
> this will play out with uClibc: it seems like it might always turn on
> USE_PT_GNU_EH_FRAME, which might o
On Thu, Aug 16, 2012 at 12:06 PM, Richard Guenther
wrote:
> On Thu, Aug 16, 2012 at 1:11 AM, Steven Bosscher
> wrote:
>> On Mon, Aug 6, 2012 at 1:27 PM, Paolo Bonzini wrote:
2. sparseset has the same problem of memory clearing (for valgrind,
see sparseset_alloc).
>>>
>>> ... only the
Hello list,
for the following couple of days I'll be posting under this thread my
collection of patches.
Unless otherwise mentioned they've been bootstrapped and tested on x86,
but with a three-weeks old snapshot, that is pre-C++ conversion. I plan to
test again next week with a latest snaps
On 17/08/2012 23:32, Tobias Schlüter wrote:
>
> Following up on myself:
>
> On 2012-08-16 14:59, Tobias Schlüter wrote:
>> A place where C++ inheritance is a trivial improvement is the red-black
>> tree used for storing various objects (gfc_symtree, gfc_gsymbol,
>> gfc_st_label, I think). This i
2012-08-18 Dimitrios Apostolou
* dwarf2out.c (output_indirect_string): Use
ASM_OUTPUT_INTERNAL_LABEL instead of slower ASM_OUTPUT_LABEL.
* varasm.c (assemble_string): Don't break string in chunks, this
is assembler specific and already done in most versions of
On Thu, Aug 16, 2012 at 10:26:48AM -0700, H.J. Lu wrote:
> GCC on Linux/x86-64 may be configured for x32:
> https://sites.google.com/site/x32abi/
> by default and the Linux/x32 target should be x86_64-VENDOR-linux-gnux32.
> This patch adds x32 support to config.guess. OK to install?
> + eval
On Fri, Aug 17, 2012 at 9:51 PM, Richard Guenther
wrote:
> On Sat, Aug 18, 2012 at 3:36 AM, Gary Funck wrote:
>>
>> Paul Hargrove noted the following build failure on
>> an older x86-32 Linux (Redhat 8.0) system.
>>
>> g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall
>> -Wwrite-strin
On Sat, Aug 18, 2012 at 5:49 AM, Ben Elliston wrote:
> On Thu, Aug 16, 2012 at 10:26:48AM -0700, H.J. Lu wrote:
>
>> GCC on Linux/x86-64 may be configured for x32:
>> https://sites.google.com/site/x32abi/
>> by default and the Linux/x32 target should be x86_64-VENDOR-linux-gnux32.
>> This patch ad
On Sat, Aug 18, 2012 at 1:23 AM, Uros Bizjak wrote:
> On Sat, Aug 18, 2012 at 10:14 AM, Uros Bizjak wrote:
>
>> After discussion with Oleg, it looks that it is enough to prevent
>> wrong registers in the output of the (multi-output) insn pattern. As
>> far as inputs are concerned, combine already
Hello,
I've been investigating a bug in gcc I came across recently and after some
difficulties, I have produced a patch that actually fixes that behavior.
However, I don't think the patch is very good and I would really
appreciate your help in making it better.
The problem is that when a
On Fri, 17 Aug 2012, Jakub Jelinek wrote:
On Fri, Aug 03, 2012 at 10:47:25PM +0200, Marc Glisse wrote:
Hello,
this is a follow up to the patch applied after this discussion:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00504.html
It handles the -mavx __builtin_shuffle case mentioned there.
I
Hi, these are the type-safe obstack macros that I use in other patches. As
requested, I also changed XOBFINISH to return (T *) and changed all
callers, felt a little strange to change (char *) to char. I also replaced
all _obstack_begin() calls in libcpp with obstack_init() which is the
documen
On 08/18/12 09:51:43, Richard Guenther wrote:
> The code is clearly buggy and should use CONST_CAST - well, or now,
> finally, const_cast to cast const char * to char *.
It is interesting that an old version of g++ caught this
but a newer version didn't?
- Gary
On Sat, Aug 18, 2012 at 3:50 AM, Joseph S. Myers
wrote:
>
> 2012-08-18 Joseph Myers
>
> * crtstuff.c (USE_PT_GNU_EH_FRAME): Define for systems using glibc
> even if inhibit_libc.
This is OK.
Thanks.
Ian
Dear Mikael,
On 2012-08-18 13:41, Mikael Morin wrote:
On 17/08/2012 23:32, Tobias Schlüter wrote:
The problem is that the initialization of format_asterisk is not allowed
in the C++ standard
So it's not valid ;-)
Sure, that's why I tried to work around it. My question was: is the
workaro
On Aug 18, 2012, at 6:52 AM, "H.J. Lu" wrote:
> In case of x32, the only difference between x32 and x86-64 is
> the default output of CC. What do you recommend how to
> detect x32?
So, is there a cpp symbol that is defined for code-gen? If so, something like
If [ $(gcc -x c /dev/null -dM -E
On Saturday 18 August 2012 13:32:59 Mike Stump wrote:
> On Aug 18, 2012, at 6:52 AM, "H.J. Lu" wrote:
> > In case of x32, the only difference between x32 and x86-64 is
> > the default output of CC. What do you recommend how to
> > detect x32?
>
> So, is there a cpp symbol that is defined for cod
On Sat, Aug 18, 2012 at 10:40 AM, Mike Frysinger wrote:
> On Saturday 18 August 2012 13:32:59 Mike Stump wrote:
>> On Aug 18, 2012, at 6:52 AM, "H.J. Lu" wrote:
>> > In case of x32, the only difference between x32 and x86-64 is
>> > the default output of CC. What do you recommend how to
>> > det
Initially I had one obstack per struct graph, which was better than using
XNEW for every edge, but still obstack_init() called from new_graph() was
too frequent.
So in this iteration of the patch the obstack is static global,
initialised once and never freed. Please advise on whether this is
Il 17/08/2012 22:00, Jakub Jelinek ha scritto:
> Hi!
>
> As discussed in the PR, this patch, originally posted for PR42728,
> makes sure the shortcut in all_uses_available_at is used on the same insns
> in between -g and -g0, it is the second time a -fcompare-debug failure
> resulted from NEXT_INS
On Saturday 18 August 2012 14:01:57 H.J. Lu wrote:
> On Sat, Aug 18, 2012 at 10:40 AM, Mike Frysinger wrote:
> > On Saturday 18 August 2012 13:32:59 Mike Stump wrote:
> >> On Aug 18, 2012, at 6:52 AM, "H.J. Lu" wrote:
> >> > In case of x32, the only difference between x32 and x86-64 is
> >> > the
Hi,
2012-08-18 Dimitrios Apostolou
* gcc/tree-ssa-sccvn.c (struct vn_tables_s): Add obstack_start to
mark the first allocated object on the obstack.
(process_scc, allocate_vn_table): Use it.
(init_scc_vn): Don't truncate shared_lookup_references vector.
Hello,
the reported case in PR fortran/29290 is now rejected as expected.
I have dejagnu-fied it and committed as obvious.
Mikael
PS: the PR can't be closed as the runtime behaviour mandated by the
standard isn't respected (the wrong procedure is called).
Index: gfortran.dg/interface_37.f90
==
This change fixes PR middle-end/53823. The negative variant of
synth_mult doesn't handle modes larger than a host wide int.
Approved by rth in PR.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
Nation
Hello,
This is what has been done so far on the SH side for 4.8.
I hope it's OK.
Cheers,
Oleg
Index: htdocs/gcc-4.8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.10
diff -u -r1.10 cha
Oleg Endo wrote:
> This is what has been done so far on the SH side for 4.8.
> I hope it's OK.
Looks fine to me.
Regards,
kaz
Hi,
this patch implements infrastructure for inline hints. They provide way to pass
info
down from inline-analysis to the inline heuristic implementation that does not
fit the
current size/time model. Inline hints are simple bitmask of individual hints
that are
interprested by the heuristics as
2012/8/18 Jan-Benedict Glaw :
> Hi!
>
> I see these warnings/errors right now:
>
> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing
> -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variad
42 matches
Mail list logo
