On Thu, 20 Oct 2011, Basile Starynkevitch wrote:
On Wed, 19 Oct 2011 21:17:47 -0700
Lawrence Crowl wrote:
Basile Starynkevitch
I would like to add destroyable objects into Ggc (the GCC garbage
collector, see files gcc/ggc*.[ch]).
The main motivation is to permit C++ objects to be garbage c
On Thu, Oct 20, 2011 at 09:11:02AM +0200, Marc Glisse wrote:
> On Thu, 20 Oct 2011, Basile Starynkevitch wrote:
> >>Basile Starynkevitch
> >>>I would like to add destroyable objects into Ggc (the GCC garbage
> >>>collector, see files gcc/ggc*.[ch]).
>
> >PPL [Parma Polyhedra Library] data, like e.
Basile -
2011/10/19 Basile Starynkevitch :
> On Wed, Oct 19, 2011 at 04:31:48PM +0300, Laurynas Biveinis wrote:
>> In the end I believe that it is the patches that talk. Whatever
>> patches are going to be submitted, reviewed and accepted, that is
>> going to be GCC's future, be it memory manageme
On Thu, Oct 20, 2011 at 10:21:27AM +0200, Richard Guenther wrote:
> I'd rather have a way to make dump-files more structured (so, following
> some standard reporting scheme) than introducing yet another way
> of output. [after making dump-files more consistent it will be easy
> to revisit patches
On Thu, 20 Oct 2011, Basile Starynkevitch wrote:
On Thu, Oct 20, 2011 at 09:11:02AM +0200, Marc Glisse wrote:
On Thu, 20 Oct 2011, Basile Starynkevitch wrote:
PPL [Parma Polyhedra Library] data, like e.g. ppl_Constraint_t
[from header that is, using a C API] comes to mind. If
you want to shar
On Thu, Oct 20, 2011 at 10:36 AM, Basile Starynkevitch
wrote:
> On Thu, Oct 20, 2011 at 10:21:27AM +0200, Richard Guenther wrote:
>
>> I'd rather have a way to make dump-files more structured (so, following
>> some standard reporting scheme) than introducing yet another way
>> of output. [after m
On Thu, Oct 20, 2011 at 10:38:04AM +0200, Marc Glisse wrote:
> On Thu, 20 Oct 2011, Basile Starynkevitch wrote
[...]
> >Yes, but that precisely is the finalization machinery we are talking about.
>
> Er, if there is a leak, it means that memory is not referenced
> anymore, so it is up to the garba
On Thu, Oct 20, 2011 at 11:28:40AM +0300, Laurynas Biveinis wrote:
> 2011/10/19 Basile Starynkevitch :
> > On Wed, Oct 19, 2011 at 04:31:48PM +0300, Laurynas Biveinis wrote:
> >> In the end I believe that it is the patches that talk. Whatever
> >> patches are going to be submitted, reviewed and ac
On 19/10/11 00:10, Richard Henderson wrote:
The thing that's almost certainly missing is that the NAND pattern
must SET your flags register, not simply clobber it. Otherwise the
dependency between the ADDC and the NAND will never be created properly.
I understand that there's a missing SET o
On 10/20/2011 12:56 PM, Basile Starynkevitch wrote:
> So, I am trying to add finalized objects in Ggc not for MELT (it does not
> need them, and it already has some finalization tricks which I could use
> when some GCC begins to use C++ objects), but for general use
For what general use? Surely y
Hi Basile,
But I don't understand how Ggc could be avoided (and I am not sure to
understand how even LLVM can avoid any kind of garbage collection in the
long run).
I doubt LLVM will ever need garbage collection, because the way it is designed
makes memory management easy. I already mentioned
Hello All,
On my GNU/Linux/x86-64 Debian/Sid system, I am not able to build trunk svn
revision 180248 when it is configuresd with
'/usr/src/Lang/gcc-trunk-bstarynk/configure' '--enable-maintainer-mode'
'--enable-checks=tree,gc' '--enable-bootstrap' '--disable-multilib'
'--enable-plugin' '
On Thu, Oct 20, 2011 at 01:09:56PM +0100, Andrew Haley wrote:
> On 10/20/2011 12:56 PM, Basile Starynkevitch wrote:
> > So, I am trying to add finalized objects in Ggc not for MELT (it does not
> > need them, and it already has some finalization tricks which I could use
> > when some GCC begins to
On 2011-10-20 AM 6:05, Bob Breuer wrote:
We probably have a difference in build or run environment. I've
double-checked with another machine and can get the same crash in
longjmp when running the test executable on both WinXP and Win2k, but
not on Win7. So it looks like Microsoft may have chan
Hi Ian,
What I want to do is to look at certain function calls and mark them
with a special label and then create a table with a specialized section with
contains the label name, the function name (as ascii string) and then the dwarf
code of the register (assuming the parameters can be
Hi,
I have recently switched to using GCC 4.6.1 (from 4.5.1) for AVR
target which supports only DWARF2 format. Now I notice a change in
.debug_line section format in 4.6.1. A quick look at the assembly
shows that '.loc' directives are emitted with discriminators.
Firstly, aren't discriminators
On Thu, 2011-10-20 at 14:27 +0200, Duncan Sands wrote:
> And that's it. The price you pay for this simplicity is the need to keep
> track
> of uses - and this does cost compilation time (clear to anyone who does some
> profiling of LLVM) but it isn't that big. The big advantage is that memory
>
Hi,
And by rules of the game, I mean the semantics of the insn chain.
In comes in the sequence of a previous post where I am splitting a neghi
operation like this:
op0 = negHI(op1)
expands to:
op0 = op1
op0_HIGH = xorQI(op0_HIGH, -1)
parallel(
op0_LOW = negQI(op0_LOW)
op0_HIGH = add(op
2011/10/20 xunxun :
> Hi, all
>
> I think this issue causes the gdb crash on XP.
> You can see the thread: http://sourceware.org/ml/gdb/2011-10/msg00056.html
>
> My many friends and I can reproduce this crash issue, but no problem on Win7.
>
> On Thu, Oct 20, 2011 at 5:05 AM, Bob Breuer wrote:
>>
On 20 October 2011 12:56, Basile Starynkevitch wrote:
>
> (amongst those advocating C++ smart or whatever _ptr-s)
Please stop saying "smart or whatever _ptr-s" - the term "smart
pointer" has a commonly accepted meaning and is well understood. It's
a generic term, it doesn't refer to a particular
On 20/10/11 15:06, Anitha Boyapati wrote:
Firstly, aren't discriminators introduced in DWARF 4? Little more
digging shows that the following fix is missing in 4.6.1 release. It
breaks the current dwarf2 parsers/readers. I think it is worth filing
a bug.
Anitha, if you only want dwarf2 produce
On Thu, Oct 20, 2011 at 4:52 PM, Jonathan Wakely wrote:
> On 20 October 2011 12:56, Basile Starynkevitch wrote:
>>
>> (amongst those advocating C++ smart or whatever _ptr-s)
>
> Please stop saying "smart or whatever _ptr-s" - the term "smart
> pointer" has a commonly accepted meaning and is well u
On Thu, 20 Oct 2011, Basile Starynkevitch wrote:
Suppose someone is coding a new plugin, which adds several passes to GCC (so
need the data to be managed by Ggc, because it is not internal to one single
pass.). Suppose the plugin is coded in C++, and that it uses some standard
C++ collection (e.
Basile Starynkevitch a écrit:
> libbackend.a(ggc-zone.o): In function `ggc_internal_alloc_zone_stat':
> /usr/src/Lang/gcc-trunk-bstarynk/gcc/ggc-zone.c:1105: undefined reference to
> `ggc_alloced_size_for_request'
This is my fault. I have tested and committed the below as per the
obvious rule.
Paulo J. Matos wrote:
> (define_insn_and_split "neghi_internal"
> [(set (match_operand:QI 0 "register_operand" "=c")
> (neg:QI (match_dup 0)))
> (set (match_operand:QI 1 "register_operand" "=c")
> (plus:QI
> (plus:QI
> (ltu:QI (neg:QI (match_d
Hi,
For trunk-version I have a tentative patch for this issue. On 4.6.x
and older branches this doesn't work, as here we can't differenciate
that easy between ms- and sysv-abi.
But could somebody give this patch a try?
Regards,
Kai
ChangeLog
* config/i386/i386.c (ix86_frame_pointer_re
On Thu, 20 Oct 2011 15:52:25 +0100
Jonathan Wakely wrote:
>
> Well you haven't showed concrete examples of your C++-friendly Ggc
> either (your suggested code wasn't valid C++).
>From the C++ side, it probably will be just an operator new, perhaps something
>as simple
as (untested code):
On 20 October 2011 20:27, Paulo J. Matos wrote:
> On 20/10/11 15:06, Anitha Boyapati wrote:
>>
>> Firstly, aren't discriminators introduced in DWARF 4? Little more
>> digging shows that the following fix is missing in 4.6.1 release. It
>> breaks the current dwarf2 parsers/readers. I think it is wo
Quoting Ulrich Weigand :
Paulo J. Matos wrote:
(define_insn_and_split "neghi_internal"
[(set (match_operand:QI 0 "register_operand" "=c")
(neg:QI (match_dup 0)))
(set (match_operand:QI 1 "register_operand" "=c")
(plus:QI
(plus:QI
(ltu:QI (
> "Cary" == Cary Coutant writes:
Cary> At Google, we've found that the cost of linking applications with
Cary> debug info is much too high.
[...]
Cary> * .debug_macinfo - Macro information, unaffected by this design.
There is also the new .debug_macro section. This section refers to
.debug
On 20/10/11 16:25, Ulrich Weigand wrote:
When reload looks at the above pattern, it will see just
two operands, both of which are output-only. So when it
decides to reload one of the operands, it will only provide
an output reload, no input reload.
For operands that are actually used for both
On 20/10/11 18:12, Joern Rennecke wrote:
Or just change the constraint to "+c" .
After trying Ulrichs suggestion and getting it to work I decided to give
yours a try since it looked cleaner using +c and dups elsewhere.
However, it failed to compile libgcc with:
../../../../../../../devHost
On 20 October 2011 16:41, Basile Starynkevitch wrote:
>
> Does the above description answers your question?
I didn't ask a question. I pointed out that your criticism of "no
concrete examples" applies to your proposal too. It still does.
> (I'm not sure to have time implement that, and I'm not
On 10/20/2011 06:53 AM, Iyer, Balaji V wrote:
So, I need the equivalent dwarf code (in hex) for DW_OP_REG1, DW_OP_REG2 and
DW_OP_REG3, so that a dwarf decoder can decode it correctly.
It's not clear what you mean by the dwarf code for DW_OP_REG1, etc.
Encoding for DW_OP_REG1, etc., is describ
"Iyer, Balaji V" writes:
> What I want to do is to look at certain function calls and mark them
> with a special label and then create a table with a specialized section with
> contains the label name, the function name (as ascii string) and then the
> dwarf code of the register (assumi
Please see my comments embedded with "BVI>"
-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com]
Sent: Thursday, October 20, 2011 2:18 PM
To: Iyer, Balaji V
Cc: 'gcc@gcc.gnu.org'
Subject: Re: Getting DWARF codes from RTX
"Iyer, Balaji V" writes:
> What I want to do
"Iyer, Balaji V" writes:
> BVI> Actually what I want is to have a way to go from the rtx value e.g (REG:
> SI 1 di) to 0x51
That's just DW_OP_reg0 + DWARF_FRAME_REGNUM (REGNO (rtx)). Assuming
REGNO (rtx) <= 31.
Ian
> Firstly, aren't discriminators introduced in DWARF 4? Little more
> digging shows that the following fix is missing in 4.6.1 release. It
> breaks the current dwarf2 parsers/readers. I think it is worth filing
> a bug.
>
> http://gcc.gnu.org/viewcvs/trunk/gcc/dwarf2out.c?r1=171846&r2=171852&diff_f
Snapshot gcc-4.5-20111020 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20111020/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, 20 Oct 2011 17:13:46 +0200 (CEST)
Marc Glisse wrote:
> Can't you use GTY-ed memory in PPL? Sorry for the naive question, but
> std::vector can take an allocator parameter, gmp lets you specify an
> allocation function...
I believe that the PPL C++ code don't have any kind of allocator
On Fri, 21 Oct 2011, Basile Starynkevitch wrote:
[explanations about the limitations of ggc]
Or did I not understood something about your question?
No, it is just that I didn't know the limitations of ggc and was thinking
of more general garbage collectors, where this is not an issue. Thanks
41 matches
Mail list logo
