What you described is the 'transitional model' right? but I don't see
any of those in the C++ standard working paper:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf
David
On Tue, Nov 27, 2012 at 11:07 PM, Chris Lattner wrote:
>
> On Nov 27, 2012, at 11:05 PM, Xinliang David Li
On Nov 27, 2012, at 11:05 PM, Xinliang David Li wrote:
> On Tue, Nov 27, 2012 at 10:40 PM, Chris Lattner wrote:
>>
>> On Nov 27, 2012, at 9:08 PM, Miles Bader wrote:
>>
>>> Chris Lattner writes:
Clang has fantastic support for PCH... and soon modules. We don't
plan to drop PCH su
On Tue, Nov 27, 2012 at 10:40 PM, Chris Lattner wrote:
>
> On Nov 27, 2012, at 9:08 PM, Miles Bader wrote:
>
>> Chris Lattner writes:
>>> Clang has fantastic support for PCH... and soon modules. We don't
>>> plan to drop PCH support when modules is implemented.
>>
>> Do you have a pointer to th
On Nov 27, 2012, at 9:08 PM, Miles Bader wrote:
> Chris Lattner writes:
>> Clang has fantastic support for PCH... and soon modules. We don't
>> plan to drop PCH support when modules is implemented.
>
> Do you have a pointer to the modules proposal clang will implement?
Most of it is implemen
Chris Lattner writes:
> Clang has fantastic support for PCH... and soon modules. We don't
> plan to drop PCH support when modules is implemented.
Do you have a pointer to the modules proposal clang will implement?
Thanks,
-miles
--
「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]
On Nov 27, 2012, at 5:16 PM, Xinliang David Li wrote:
Removing PCH will give us more implementation freedom for the memory
management project
(http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives).
>>>
>>> One of the arguments put forward to advocate the transition to C++ was the
On Tue, 27 Nov 2012, Mike Stump wrote:
> You failed to state a single case where a violation is caught.
It's not about catching violations of law, it's about catching cases where
the source tree is in an inconsistent state. And a not uncommon cause of
that is that someone didn't know about the
On Nov 27, 2012, at 4:50 PM, "Joseph S. Myers" wrote:
> On Tue, 27 Nov 2012, Mike Stump wrote:
>
>> A review of the change and approval of the change should be enough to
>> catch issues going into the FSF tree. The build should just copy the
>> generated file to the source tree, if changed. T
On Tue, Nov 27, 2012 at 4:11 PM, Chris Lattner wrote:
>
> On Nov 27, 2012, at 3:32 PM, Eric Botcazou wrote:
>
>>> I admit that I'm partly fishing here, but my proposal is based on the
>>> following:
>>>
>>> * The implementation of PCH in GCC is atrocious and hard to maintain.
>>> * The next C++ s
On Tue, 27 Nov 2012, Mike Stump wrote:
> A review of the change and approval of the change should be enough to
> catch issues going into the FSF tree. The build should just copy the
> generated file to the source tree, if changed. The build failed for me,
The rule from the FSF is that tm.tex
On Nov 27, 2012, at 1:22 PM, Andrew Pinski wrote:
> On Tue, Nov 27, 2012 at 12:55 PM, Mike Stump wrote:
>> This:
>>
>> Verify that you have permission to grant a GFDL license for all
>> new text in tm.texi, then copy it to ../../gcc/gcc/doc/tm.texi.
>> make[3]: *** [s-tm-texi] Error 1
>> make[3]
On Nov 27, 2012, at 3:32 PM, Eric Botcazou wrote:
>> I admit that I'm partly fishing here, but my proposal is based on the
>> following:
>>
>> * The implementation of PCH in GCC is atrocious and hard to maintain.
>> * The next C++ standard is likely to define modules
>> (http://www.open-std.org
On Tue, Nov 27, 2012 at 6:32 PM, Eric Botcazou wrote:
> One of the arguments put forward to advocate the transition to C++ was the
> competition. Where do the other compilers stand when it comes to PCHs?
Note that although we are doing this in the umbrella of the C++
transition, this is actuall
On Tue, Nov 27, 2012 at 6:20 PM, Jeff Law wrote:
> On 11/27/2012 03:51 PM, Diego Novillo wrote:
>>>
>>> * Start implementing memory pools for data structures that do not need
>>
>> to be in PCH images. It is still not clear what types of memory pools
>> we will need, but at a minimum we are think
> I admit that I'm partly fishing here, but my proposal is based on the
> following:
>
> * The implementation of PCH in GCC is atrocious and hard to maintain.
> * The next C++ standard is likely to define modules
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf)
> * The user-ba
On 11/27/2012 03:51 PM, Diego Novillo wrote:
* Start implementing memory pools for data structures that do not need
to be in PCH images. It is still not clear what types of memory pools
we will need, but at a minimum we are thinking of a permanent pool,
per-pass pools and at least one or two st
On Tue, Nov 27, 2012 at 8:54 AM, Tom Tromey wrote:
>> "Gaby" == Gabriel Dos Reis writes:
>
> Richard> Just to add another case which seems to be not covered in the thread.
> Richard> When dumping from inside a gdb session in many cases I cut&paste
> Richard> addresses literally. For overload
On Tue, Nov 27, 2012 at 2:20 PM, Chris Lattner wrote:
> On Nov 27, 2012, at 8:00 AM, Diego Novillo wrote:
>> I admit that I'm partly fishing here, but my proposal is based on the
>> following:
>>
>> * The implementation of PCH in GCC is atrocious and hard to maintain.
>> * The next C++ standard
As a follow up to our proposal to improve memory management in the
compiler, we plan to proceed in two parts:
* A transition plan to quickly remove gengtype out of the picture.
This has become the main blocker for several C++ cleanups. The
transition here is to move all the GTY() structures to us
On Tue, Nov 27, 2012 at 1:22 PM, Diego Novillo wrote:
> On Tue, Nov 27, 2012 at 2:48 PM, Paolo Carlini
> wrote:
>
>> Assuming that the new implementation will be available in time for 4.9, my
>> primary concern is that in the meanwhile running the libstdc++ testsuite
>> will be quite noticeably
On Tue, Nov 27, 2012 at 12:55 PM, Mike Stump wrote:
> This:
>
> Verify that you have permission to grant a GFDL license for all
> new text in tm.texi, then copy it to ../../gcc/gcc/doc/tm.texi.
> make[3]: *** [s-tm-texi] Error 1
> make[3]: *** Waiting for unfinished jobs….
>
> is one of the stupid
On Tue, Nov 27, 2012 at 2:48 PM, Paolo Carlini wrote:
> Assuming that the new implementation will be available in time for 4.9, my
> primary concern is that in the meanwhile running the libstdc++ testsuite
> will be quite noticeably slower. Do you have some numbers?
No, but I can get them. How
This:
Verify that you have permission to grant a GFDL license for all
new text in tm.texi, then copy it to ../../gcc/gcc/doc/tm.texi.
make[3]: *** [s-tm-texi] Error 1
make[3]: *** Waiting for unfinished jobs….
is one of the stupidest build errors I've seen all decade. Can someone fix it
please?
Hi,
>Thoughts?
Assuming that the new implementation will be available in time for 4.9, my
primary concern is that in the meanwhile running the libstdc++ testsuite will
be quite noticeably slower. Do you have some numbers?
Thanks,
Paolo
On Nov 27, 2012, at 8:00 AM, Diego Novillo wrote:
> I admit that I'm partly fishing here, but my proposal is based on the
> following:
>
> * The implementation of PCH in GCC is atrocious and hard to maintain.
> * The next C++ standard is likely to define modules
> (http://www.open-std.org/jtc1/s
I admit that I'm partly fishing here, but my proposal is based on the following:
* The implementation of PCH in GCC is atrocious and hard to maintain.
* The next C++ standard is likely to define modules
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf)
* The user-base for PCH is
On Tue, Nov 27, 2012 at 10:23 AM, Richard Biener
wrote:
> me too, just when you do debug_tree ($1) you then don't have $nn for
> all of the trees referenced from the output ;)
True that :)
On Tue, Nov 27, 2012 at 4:06 PM, Diego Novillo wrote:
> On Sun, Nov 25, 2012 at 8:45 AM, Richard Biener
> wrote:
>
>> Just to add another case which seems to be not covered in the thread.
>> When dumping from inside a gdb session in many cases I cut&paste
>> addresses literally. For overloading
On Tue, Nov 27, 2012 at 10:15 AM, Paolo Bonzini wrote:
> Lots of errors like the following:
>
> -o build/genrecog.o ../../gcc/genrecog.c
> In file included from ../../gcc/rtl.h:29,
Oops, I forgot to re-test detailed-memory stats. I'll fix.
Diego.
Lots of errors like the following:
-o build/genrecog.o ../../gcc/genrecog.c
In file included from ../../gcc/rtl.h:29,
from ../../gcc/genoutput.c:92:
../../gcc/vec.h:654: error: default argument missing for parameter 4 of
‘template bool vec_safe_reserve(vec*&,
unsig
On Sun, Nov 25, 2012 at 8:45 AM, Richard Biener
wrote:
> Just to add another case which seems to be not covered in the thread.
> When dumping from inside a gdb session in many cases I cut&paste
> addresses literally. For overloading to work I'd need to write casts
> in front of the inferior call
Hello All,
I need some clarification regarding the target hook "TARGET_INIT_LIBFUNCS".
I wanted to replace all the instances of 'memcpy' with '__memcpy'. For
that, i have used the above mentioned target hook with the code as
shown below:
memcpy_libfunc = init_one_libfunc ("__memcpy");
I can see
> "Gaby" == Gabriel Dos Reis writes:
Richard> Just to add another case which seems to be not covered in the thread.
Richard> When dumping from inside a gdb session in many cases I cut&paste
Richard> addresses literally. For overloading to work I'd need to write casts
Richard> in front of the
i will discuss this with mike when he wakes up.he lives on the west
pole so that will not be until after you go to bed.
the one point that i will take exception to is that the copying
operation is, in practice, any more time expensive than the pointer
copy. I never bother to initialize t
On Tue, Nov 27, 2012 at 1:06 AM, Kenneth Zadeck
wrote:
> Richard,
>
> I spent a good part of the afternoon talking to Mike about this. He is on
> the c++ standards committee and is a much more seasoned c++ programmer than
> I am.
>
> He convinced me that with a large amount of engineering and c++
On Mon, Nov 26, 2012 at 9:57 PM, Lawrence Crowl wrote:
> On 11/23/12, Andrew MacLeod wrote:
>> On 11/22/2012 01:18 PM, Lawrence Crowl wrote:
>> > I have found that tree-flow.h implements iteration over htab_t,
>> > while there is no current facility to do that with hash_table.
>> > Unfortunately,
36 matches
Mail list logo
