On 2012.09.20 at 19:51 -0700, Dehao Chen wrote:
> As expected, since this patch was checked in yesterday, there are 4
> bugs exposed (1 fixed, 1 patch ready, 2 TBD):
It also causes: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54655
--
Markus
Hi,
On Thu, 20 Sep 2012, Dehao Chen wrote:
> 4. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54650 Failed one
> regression test in libgomp (I didn't know that there are regression
> tests for libraries before...) This error should be a bug exposed by
> this patch. I'll try to provide a patch as
Hi Dehao,
You wrote:
> 4. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54650
> Failed one regression test in libgomp (I didn't know that there are
> regression tests for libraries before...)
> This error should be a bug exposed by this patch. I'll try to provide
> a patch as soon as possible.
See
Hi,
As expected, since this patch was checked in yesterday, there are 4
bugs exposed (1 fixed, 1 patch ready, 2 TBD):
1. http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01413.html
Failed targets such as arm and mips. Fixed by r191510
2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54649
Failed Go bo
I can reproduce the problem now. After some investigation, this error
should be a bug exposed by this patch.
The root cause is, in expand_omp_taskreg, it calls
move_sese_region_to_fn with gimple_block(entry_stmt) as the root of
the block tree. However, there is an edge inside the region that has
t
> This problem will be fixed by
> http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01491.html
Sorry, but its not (see pr54645 c#3).
Dominique
On Thu, Sep 20, 2012 at 6:04 PM, Dominique Dhumieres wrote:
> A lot of failures in the test suite have appeared between revisions
> 191485 and 191494 see
> http://gcc.gnu.org/ml/gcc-regression/2012-09/msg00327.html ).
> I have looked at the failure of libgomp.fortran/reduction1.f90:
>
> [macbook]
The PCH related failures are caused by this patch. The patch I posted
earlier http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01491.html solved
another problem, but not this one.
The issue here is: when reading PCH data, the line_table is also read
from PCH files. But the location_adhoc_data_map is n
Sorry for breaking these tests.
This problem is very hard to reproduce. However, I had a patch to fix
another compile-time problem which may be related to this one.
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01491.html
After applying the patch, the PCH related bugs are not showing any
more on m
Hi, Paolo,
I'll look into the ICE problems now.
Thanks,
Dehao
On Thu, Sep 20, 2012 at 9:04 PM, Paolo Carlini wrote:
> Hi,
>
>
> On 09/19/2012 09:59 PM, Dehao Chen wrote:
>>
>> This patch was commited as r191494.
>
> I'm afraid I can't help *much* with the debugging, but on my x86_64-linux
> mac
> On Thu, Sep 20, 2012 at 03:26:29PM +0200, Paolo Carlini wrote:
> > On 09/20/2012 03:04 PM, Paolo Carlini wrote:
> > >are all ICEs like the below. Apparently PCHs are required, I can't
> > >reproduce outside the testsuite, without the library PCHs.
> > Take this only as a vague hint: I'm seeing ma
On 09/20/2012 04:05 PM, Martin Jambor wrote:
On Thu, Sep 20, 2012 at 03:26:29PM +0200, Paolo Carlini wrote:
On 09/20/2012 03:04 PM, Paolo Carlini wrote:
are all ICEs like the below. Apparently PCHs are required, I can't
reproduce outside the testsuite, without the library PCHs.
Take this only
On Thu, Sep 20, 2012 at 03:26:29PM +0200, Paolo Carlini wrote:
> On 09/20/2012 03:04 PM, Paolo Carlini wrote:
> >are all ICEs like the below. Apparently PCHs are required, I can't
> >reproduce outside the testsuite, without the library PCHs.
> Take this only as a vague hint: I'm seeing many pch-rel
On 09/20/2012 03:04 PM, Paolo Carlini wrote:
are all ICEs like the below. Apparently PCHs are required, I can't
reproduce outside the testsuite, without the library PCHs.
Take this only as a vague hint: I'm seeing many pch-related regressions
here, between r191490 and r191501:
http://gcc.g
Hi,
On 09/19/2012 09:59 PM, Dehao Chen wrote:
This patch was commited as r191494.
I'm afraid I can't help *much* with the debugging, but on my
x86_64-linux machine and a very straightforward configuration
(--enable-languages=c++ --disable-multilib) after r191494 I'm seeing the
following libst
A lot of failures in the test suite have appeared between revisions
191485 and 191494 see
http://gcc.gnu.org/ml/gcc-regression/2012-09/msg00327.html ).
I have looked at the failure of libgomp.fortran/reduction1.f90:
[macbook] f90/bug% gfc -O3 -g -fopenmp
/opt/gcc/work/libgomp/testsuite/libgomp.f
The patch to fix this problem is attached. As I don't have machines
other than x86, I cannot test it. But this patch seemed
straightforward. I'll check it in in a couple of hours if no objection
is received.
Thanks,
Dehao
gcc/ChangeLog:
2012-09-19 Dehao Chen
* config/s390/s390.c (s39
Thanks for reporting. I'll fix them now.
Dehao
On Thu, Sep 20, 2012 at 6:29 AM, Michael Meissner
wrote:
> On Fri, Sep 14, 2012 at 11:03:34AM +0800, Dehao Chen wrote:
>> Hi,
>>
>> I've integrated all the reviews from this thread (Thank you guys for
>> helping refine this patch).
>>
>> Now the pat
On Fri, Sep 14, 2012 at 11:03:34AM +0800, Dehao Chen wrote:
> Hi,
>
> I've integrated all the reviews from this thread (Thank you guys for
> helping refine this patch).
>
> Now the patch can pass all gcc testsuite as well as all spec2006
> benchmarks (with LTO). Concerning memory consumption, for
This patch was commited as r191494.
Thank all for the reviews and helping test.
Dehao
Hi,
On Wed, 19 Sep 2012, Martin Jambor wrote:
> (The patch does not introduce any of the asserts Michael's patch had
> because, as far as I my grep told me, IS_UNKNOWN_LOCATION is not in
> trunk yet and I suppose the pre-approval does not cover introducing
> things like that.)
Dehaos patch con
Hi,
On Wed, Sep 12, 2012 at 04:17:45PM +0200, Michael Matz wrote:
> Hi,
>
> On Wed, 12 Sep 2012, Michael Matz wrote:
>
> > > Hm, but we shouldn't end up streaming any BLOCKs at this point (nor
> > > local TYPE_DECLs). Those are supposed to be in the local function
> > > sections only where no
On Wed, Sep 19, 2012 at 10:48 AM, Jan Hubicka wrote:
>> Hi,
>>
>> I've integrated all the reviews from this thread (Thank you guys for
>> helping refine this patch).
>>
>> Now the patch can pass all gcc testsuite as well as all spec2006
>> benchmarks (with LTO). Concerning memory consumption, for
> Hi,
>
> I've integrated all the reviews from this thread (Thank you guys for
> helping refine this patch).
>
> Now the patch can pass all gcc testsuite as well as all spec2006
> benchmarks (with LTO). Concerning memory consumption, for extreme
> benchmarks like tramp3d, this patch incurs around
On 2012-09-14 04:59 , Eric Botcazou wrote:
I think it's going to make GCC harder to maintain if we drop the -g0
vs. -g no-code-difference requirement for just some optimization
levels.
Seconded, this is surely going to open yet another can of worms.
Agreed.
Diego.
> I think it's going to make GCC harder to maintain if we drop the -g0
> vs. -g no-code-difference requirement for just some optimization
> levels.
Seconded, this is surely going to open yet another can of worms.
--
Eric Botcazou
On Thu, Sep 13, 2012 at 7:37 PM, Mike Stump wrote:
> On Sep 13, 2012, at 6:52 AM, Robert Dewar wrote:
>> Sure, it is obvious that you don't want -g to affect -O1 or -O2 code,
>> but I think if you have -Og (if and when we have that), it would not
>> be a bad thing for -g to affect that.
>
> No, i
On Fri, Sep 14, 2012 at 12:49 AM, Tom Tromey wrote:
>> "Dehao" == Dehao Chen writes:
>
> Dehao> + static htab_t location_adhoc_data_htab;
> Dehao> + static source_location curr_adhoc_loc;
> Dehao> + static struct location_adhoc_data *location_adhoc_data;
> Dehao> + static unsigned int allocat
On Thu, Sep 13, 2012 at 8:00 PM, Richard Guenther
wrote:
> On Wed, Sep 12, 2012 at 7:20 PM, Dehao Chen wrote:
>> There is another bug in the patch (not covered by unittests,
>> discovered through spec benchmarks).
>>
>> When we remove unused locals, we do not mark the block as used for
>> debug s
On Sep 13, 2012, at 9:51 AM, Robert Dewar wrote:
> I routinely debugged code at -O1, but then the
> compiler got better at optimization, and things deteriorated so much
> at -O1 that now I don't even attempt it.
An example of a non-feature for me would be the reordering of instructions by
schedu
On Sep 13, 2012, at 6:52 AM, Robert Dewar wrote:
> Sure, it is obvious that you don't want -g to affect -O1 or -O2 code,
> but I think if you have -Og (if and when we have that), it would not
> be a bad thing for -g to affect that.
No, instead think of -Og as affecting the -g output itself. If i
On 9/13/2012 12:46 PM, Tom Tromey wrote:
"Robert" == Robert Dewar writes:
Robert> Sometimes I wonder whether the insistence on -g not changing code
Robert> generation is warranted. In practice, gdb for me is so weak in handling
Robert> -O1 or -O2, that if I want to debug something I have to re
> "Dehao" == Dehao Chen writes:
Dehao> + static htab_t location_adhoc_data_htab;
Dehao> + static source_location curr_adhoc_loc;
Dehao> + static struct location_adhoc_data *location_adhoc_data;
Dehao> + static unsigned int allocated_location_adhoc_data;
libcpp was written to allow multiple p
> "Robert" == Robert Dewar writes:
Robert> Sometimes I wonder whether the insistence on -g not changing code
Robert> generation is warranted. In practice, gdb for me is so weak in handling
Robert> -O1 or -O2, that if I want to debug something I have to recompile
Robert> with -O0 -g, which cau
On 9/13/2012 12:07 PM, Xinliang David Li wrote:
It is very important to make sure -g does not affect code gen ---
people do release build with -g with optimization, and strip the
binary before sending it to production machines ..
Yes, of course, and for sure -g cannot affect optimized code, see
On Thu, Sep 13, 2012 at 8:02 PM, Richard Guenther
wrote:
> On Wed, Sep 12, 2012 at 6:39 PM, Xinliang David Li wrote:
>> On Wed, Sep 12, 2012 at 2:13 AM, Richard Guenther
>> wrote:
>>> On Wed, Sep 12, 2012 at 7:06 AM, Dehao Chen wrote:
Now I think we are facing a more complex problem. The d
It is very important to make sure -g does not affect code gen ---
people do release build with -g with optimization, and strip the
binary before sending it to production machines ..
David
On Thu, Sep 13, 2012 at 6:33 AM, Robert Dewar wrote:
> On 9/13/2012 8:00 AM, Richard Guenther wrote:
>
>> Be
On 9/13/2012 9:38 AM, Jakub Jelinek wrote:
On Thu, Sep 13, 2012 at 09:33:20AM -0400, Robert Dewar wrote:
On 9/13/2012 8:00 AM, Richard Guenther wrote:
Because doing so would create code generation differences -g vs. -g0.
Sometimes I wonder whether the insistence on -g not changing code
gener
On Thu, Sep 13, 2012 at 09:33:20AM -0400, Robert Dewar wrote:
> On 9/13/2012 8:00 AM, Richard Guenther wrote:
>
> >Because doing so would create code generation differences -g vs. -g0.
>
> Sometimes I wonder whether the insistence on -g not changing code
> generation is warranted. In practice, gd
On 9/13/2012 8:00 AM, Richard Guenther wrote:
Because doing so would create code generation differences -g vs. -g0.
Sometimes I wonder whether the insistence on -g not changing code
generation is warranted. In practice, gdb for me is so weak in handling
-O1 or -O2, that if I want to debug some
On Wed, Sep 12, 2012 at 10:44 PM, Dehao Chen wrote:
> Attached is the memory consumption report for a very large source
> file. Looks like this patch actually reduced the memory consumption by
> 2%.
Please make sure to test large C++ expression template users. Large
regular programs do not stres
On Wed, Sep 12, 2012 at 6:39 PM, Xinliang David Li wrote:
> On Wed, Sep 12, 2012 at 2:13 AM, Richard Guenther
> wrote:
>> On Wed, Sep 12, 2012 at 7:06 AM, Dehao Chen wrote:
>>> Now I think we are facing a more complex problem. The data structure
>>> we use to store the location_adhoc_data are fi
On Wed, Sep 12, 2012 at 7:20 PM, Dehao Chen wrote:
> There is another bug in the patch (not covered by unittests,
> discovered through spec benchmarks).
>
> When we remove unused locals, we do not mark the block as used for
> debug stmt, but gimple-streamer-out will still stream out blocks for
> d
> Hi,
>
> On Wed, Sep 12, 2012 at 04:17:45PM +0200, Michael Matz wrote:
> > Hi,
> >
> > On Wed, 12 Sep 2012, Michael Matz wrote:
> >
> > > > Hm, but we shouldn't end up streaming any BLOCKs at this point (nor
> > > > local TYPE_DECLs). Those are supposed to be in the local function
> > > > se
I can reproduce the error. For large applications, the 32bit integer
will overflow (not enough to encode the locations). The following
patch can fix the problem. I'm still doing integration tests, and will
send out a integral patch tomorrow.
Thanks,
Dehao
diff --git a/libcpp/line-map.c b/libcpp/l
This bug is exposed by this patch.
On Thu, Sep 13, 2012 at 1:20 AM, Dehao Chen wrote:
> There is another bug in the patch (not covered by unittests,
> discovered through spec benchmarks).
>
> When we remove unused locals, we do not mark the block as used for
> debug stmt, but gimple-streamer-out
For the largest bucket (size==80), the size reduction is 20%. Not bad.
David
On Wed, Sep 12, 2012 at 1:44 PM, Dehao Chen wrote:
> Attached is the memory consumption report for a very large source
> file. Looks like this patch actually reduced the memory consumption by
> 2%.
>
> Dehao
>
> On Thu,
Attached is the memory consumption report for a very large source
file. Looks like this patch actually reduced the memory consumption by
2%.
Dehao
On Thu, Sep 13, 2012 at 1:18 AM, Xinliang David Li wrote:
> On Wed, Sep 12, 2012 at 10:05 AM, Dehao Chen wrote:
>> There are two parts that needs me
There is another bug in the patch (not covered by unittests,
discovered through spec benchmarks).
When we remove unused locals, we do not mark the block as used for
debug stmt, but gimple-streamer-out will still stream out blocks for
debug stmt. There can be 2 fixes:
1.
--- a/gcc/gimple-streamer-
On Wed, Sep 12, 2012 at 10:05 AM, Dehao Chen wrote:
> There are two parts that needs memory management:
>
> 1. The BLOCK structure. This is managed by GC. I originally thought
> that removing blocks from tree.gsbase would paralyze GC. This turned
> out not to be a concern because DECL_INITIAL will
There are two parts that needs memory management:
1. The BLOCK structure. This is managed by GC. I originally thought
that removing blocks from tree.gsbase would paralyze GC. This turned
out not to be a concern because DECL_INITIAL will still mark those
used tree nodes. This patch may decrease the
On Wed, Sep 12, 2012 at 2:13 AM, Richard Guenther
wrote:
> On Wed, Sep 12, 2012 at 7:06 AM, Dehao Chen wrote:
>> Now I think we are facing a more complex problem. The data structure
>> we use to store the location_adhoc_data are file-static in linemap.c
>> in libcpp. These data structures are not
Hi,
On Wed, Sep 12, 2012 at 04:47:11PM +0200, Richard Guenther wrote:
> On Wed, Sep 12, 2012 at 4:37 PM, Martin Jambor wrote:
> > On Wed, Sep 12, 2012 at 04:17:45PM +0200, Michael Matz wrote:
> >> On Wed, 12 Sep 2012, Michael Matz wrote:
> >>
> >> > > Hm, but we shouldn't end up streaming any BLO
On Wed, Sep 12, 2012 at 4:37 PM, Martin Jambor wrote:
> Hi,
>
> On Wed, Sep 12, 2012 at 04:17:45PM +0200, Michael Matz wrote:
>> Hi,
>>
>> On Wed, 12 Sep 2012, Michael Matz wrote:
>>
>> > > Hm, but we shouldn't end up streaming any BLOCKs at this point (nor
>> > > local TYPE_DECLs). Those are sup
Hi,
On Wed, Sep 12, 2012 at 04:17:45PM +0200, Michael Matz wrote:
> Hi,
>
> On Wed, 12 Sep 2012, Michael Matz wrote:
>
> > > Hm, but we shouldn't end up streaming any BLOCKs at this point (nor
> > > local TYPE_DECLs). Those are supposed to be in the local function
> > > sections only where no
Hi,
On Wed, 12 Sep 2012, Michael Matz wrote:
> > Hm, but we shouldn't end up streaming any BLOCKs at this point (nor
> > local TYPE_DECLs). Those are supposed to be in the local function
> > sections only where no fixup for prevailing decls happens.
>
> That's true, something is fishy with th
Hi,
On Wed, 12 Sep 2012, Richard Guenther wrote:
> >> It hides a bug. If we replace anything in BLOCK_VARS then the risk
> >> is that you generate an infinite chain in some BLOCK_VARS list and
> >> thus get infinite loops somewhere in the compiler.
> >
> > That's what I said for using SET_PREV
On Wed, Sep 12, 2012 at 2:14 PM, Michael Matz wrote:
> Hi,
>
> On Wed, 12 Sep 2012, Richard Guenther wrote:
>
>> > This will actually not work correctly in some cases. The problem is,
>> > if the prevailing decl is already part of another chain (say in
>> > another block_var list) you would break
Hi,
On Wed, 12 Sep 2012, Richard Guenther wrote:
> > This will actually not work correctly in some cases. The problem is,
> > if the prevailing decl is already part of another chain (say in
> > another block_var list) you would break the current chain. Hence
> > block vars need special handl
On Wed, Sep 12, 2012 at 7:06 AM, Dehao Chen wrote:
> Now I think we are facing a more complex problem. The data structure
> we use to store the location_adhoc_data are file-static in linemap.c
> in libcpp. These data structures are not guarded by GTY(()).
> Meanwhile, as we have removed the block
On Tue, Sep 11, 2012 at 5:32 PM, Michael Matz wrote:
> Hi,
>
> On Tue, 11 Sep 2012, Dehao Chen wrote:
>
>> Looks like we have two choices:
>>
>> 1. Stream out block info, and use LTO_SET_PREVAIL for TREE_CHAIN(t)
>
> This will actually not work correctly in some cases. The problem is, if
> the pr
Can you make definition of location_adhoc_data available in both
libcpp and gcc? In gcc side, the data structure will be annotated
with GTY(). The root global variables should also be visible in gcc
side.
David
On Tue, Sep 11, 2012 at 10:06 PM, Dehao Chen wrote:
> Now I think we are facing a mo
Now I think we are facing a more complex problem. The data structure
we use to store the location_adhoc_data are file-static in linemap.c
in libcpp. These data structures are not guarded by GTY(()).
Meanwhile, as we have removed the block data structure from
gimple.gsbase as well as tree.exp (encod
I saw comments in tree-streamer-out.c:
/* Do not stream BLOCK_SOURCE_LOCATION. We cannot handle debug information
for early inlining so drop it on the floor instead of ICEing in
dwarf2out.c. */
streamer_write_chain (ob, BLOCK_VARS (expr), ref_p);
However, what the code is doing se
Hi,
On Tue, 11 Sep 2012, Dehao Chen wrote:
> Looks like we have two choices:
>
> 1. Stream out block info, and use LTO_SET_PREVAIL for TREE_CHAIN(t)
This will actually not work correctly in some cases. The problem is, if
the prevailing decl is already part of another chain (say in another
bl
On Tue, Sep 11, 2012 at 3:30 PM, Michael Matz wrote:
> Hi,
>
> On Tue, 11 Sep 2012, Richard Guenther wrote:
>
>> >>> +++ gcc/lto/lto.c (working copy)
>> >>> @@ -1559,8 +1559,6 @@ lto_fixup_prevailing_decls (tree t)
>> >>> {
>> >>>enum tree_code code = TREE_CODE (t);
>> >>>LTO_NO_PRE
Hi,
On Tue, 11 Sep 2012, Richard Guenther wrote:
> >>> +++ gcc/lto/lto.c (working copy)
> >>> @@ -1559,8 +1559,6 @@ lto_fixup_prevailing_decls (tree t)
> >>> {
> >>>enum tree_code code = TREE_CODE (t);
> >>>LTO_NO_PREVAIL (TREE_TYPE (t));
> >>> - if (CODE_CONTAINS_STRUCT (code, TS
On Mon, Sep 10, 2012 at 5:27 PM, Dehao Chen wrote:
> On Mon, Sep 10, 2012 at 3:01 AM, Richard Guenther
> wrote:
>> On Sun, Sep 9, 2012 at 12:26 AM, Dehao Chen wrote:
>>> Hi, Diego,
>>>
>>> Thanks a lot for the review. I've updated the patch.
>>>
>>> This patch is large and may easily break build
Thanks for helping test this. I'll try to build mozzila to check the
memory consumption as well as find new bugs.
Dehao
On Tue, Sep 11, 2012 at 12:41 AM, Jan Hubicka wrote:
> Hi,
> I was curious how the patch behaves memory wise on compilling Mozilla. It
> actually crashes on:
> (gdb) bt
> #0
Hi,
I was curious how the patch behaves memory wise on compilling Mozilla. It
actually crashes on:
(gdb) bt
#0 0x7fab8cd70945 in raise () from /lib64/libc.so.6
#1 0x7fab8cd71f21 in abort () from /lib64/libc.so.6
#2 0x00b52330 in linemap_location_from_macro_expansion_p (set=0x78
On Mon, Sep 10, 2012 at 3:01 AM, Richard Guenther
wrote:
> On Sun, Sep 9, 2012 at 12:26 AM, Dehao Chen wrote:
>> Hi, Diego,
>>
>> Thanks a lot for the review. I've updated the patch.
>>
>> This patch is large and may easily break builds because it reserves
>> more complete information for TREE_BL
On Sun, Sep 9, 2012 at 12:26 AM, Dehao Chen wrote:
> Hi, Diego,
>
> Thanks a lot for the review. I've updated the patch.
>
> This patch is large and may easily break builds because it reserves
> more complete information for TREE_BLOCK as well as gimple_block (may
> trigger bugs that was hided whe
On 2012-09-07 10:55 , Dehao Chen wrote:
gcc/ChangeLog:
2012-08-01 Dehao Chen
* toplev.c (general_init): Init block_locations.
* tree.c (tree_set_block): New.
(tree_block): Change to use LOCATION_BLOCK.
* tree.h (TREE_SET_BLOCK): New.
* final.c (reemit_
On 2012-09-06 05:46 , Richard Guenther wrote:
On Wed, Aug 22, 2012 at 1:54 AM, Dehao Chen wrote:
On Tue, Aug 21, 2012 at 6:25 AM, Richard Guenther
wrote:
On Mon, Aug 20, 2012 at 3:18 AM, Dehao Chen wrote:
ping
Conceptually I like the change. Can a libcpp maintainer please have a 2nd
On Wed, Aug 22, 2012 at 1:54 AM, Dehao Chen wrote:
> On Tue, Aug 21, 2012 at 6:25 AM, Richard Guenther
> wrote:
>> On Mon, Aug 20, 2012 at 3:18 AM, Dehao Chen wrote:
>>> ping
>>
>> Conceptually I like the change. Can a libcpp maintainer please have a 2nd
>> look?
>>
>> Dehao, did you do any
ping...
Thanks,
Dehao
On Tue, Aug 21, 2012 at 4:54 PM, Dehao Chen wrote:
> On Tue, Aug 21, 2012 at 6:25 AM, Richard Guenther
> wrote:
>> On Mon, Aug 20, 2012 at 3:18 AM, Dehao Chen wrote:
>>> ping
>>
>> Conceptually I like the change. Can a libcpp maintainer please have a 2nd
>> look?
>>
On Tue, Aug 21, 2012 at 6:25 AM, Richard Guenther
wrote:
> On Mon, Aug 20, 2012 at 3:18 AM, Dehao Chen wrote:
>> ping
>
> Conceptually I like the change. Can a libcpp maintainer please have a 2nd
> look?
>
> Dehao, did you do any compile-time and memory-usage benchmarks?
I don't have a memo
On Mon, Aug 20, 2012 at 3:18 AM, Dehao Chen wrote:
> ping
Conceptually I like the change. Can a libcpp maintainer please have a 2nd
look?
Dehao, did you do any compile-time and memory-usage benchmarks?
Thanks,
Richard.
> Thanks,
> Dehao
>
> On Tue, Aug 14, 2012 at 10:13 AM, Dehao Chen wr
ping
Thanks,
Dehao
On Tue, Aug 14, 2012 at 10:13 AM, Dehao Chen wrote:
> Hi, Dodji,
>
> Thanks for the review. I've fixed all the addressed issues. I'm
> attaching the related changes:
>
> Thanks,
> Dehao
>
> libcpp/ChangeLog:
> 2012-08-01 Dehao Chen
>
> * include/line-map.h (MAX_
Hi, Dodji,
Thanks for the review. I've fixed all the addressed issues. I'm
attaching the related changes:
Thanks,
Dehao
libcpp/ChangeLog:
2012-08-01 Dehao Chen
* include/line-map.h (MAX_SOURCE_LOCATION): New value.
(location_adhoc_data_init): New.
(location_adhoc_data
Dehao Chen writes:
> Index: libcpp/line-map.c
[...]
> + /* Data structure to associate an arbitrary data to a source location. */
> + struct location_adhoc_data {
> + source_location locus;
> + void *data;
> + };
> +
> + /* The following data structure encodes a location with some adhoc da
Hello Dehao,
I have mostly cosmetic comments to make about the libcpp parts.
Dehao Chen writes:
> Index: libcpp/include/line-map.h
> ===
> *** libcpp/include/line-map.h (revision 189835)
> --- libcpp/include/line-map.h (working cop
82 matches
Mail list logo
