2010/6/2 Ian Lance Taylor :
>> Ian, do you have an idea on how to avoid _M_impl dependency in
>> gengtype or what else to do about it?
>>
>> Because we can trivially make gengtype mark the vector itself and mark
>> whatever was put into vector, but not _M_impl.
>
> I don't think I understand the qu
Laurynas Biveinis writes:
> 2010/6/2 Ian Lance Taylor :
>> As you say, gengtype includes specific support for VEC. Using
>> std::vector instead will require some work in gengtype, but not too
>> much. Currently gengtype generates code like this for a VEC:
>>
>> size_t l0 = (size_t)(((*x)
2010/6/2 Ian Lance Taylor :
> As you say, gengtype includes specific support for VEC. Using
> std::vector instead will require some work in gengtype, but not too
> much. Currently gengtype generates code like this for a VEC:
>
> size_t l0 = (size_t)(((*x).base).num);
> for (i0 = 0;
2010/6/2 Basile Starynkevitch :
> I am not entirely convinced of that. VEC is supported not only by
> infamous vec.h macros (which we surely want to replace by some template,
> possibly std::vec) but also by gengtype (and the Gcc Garbage Collector).
>
> I strongly believe we will need a garbage col
Basile Starynkevitch writes:
> On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote:
>> (2) we should prefer standard solution over home-grown hacks, unless
>> there is a clear demonstration of value. For example, it would be
>> unwise to prefer our current VEC_xxx ove
Hello all -
All the patches from gc-improv merge have been approved. Due to the
scope of the changes, the merge will need trunk freeze. Thus I am
planning to do it next Tuesday, at 7am CEST. The freeze should last
about 2-3 hours.
Alternatively I could also do the merge tomorrow at the same time,
Hi,
Try using gcc-vcg-plugin to browse tree and cfg during debug gcc. It's
just an initial version for now. Any suggestions will be appreciated.
:-)
http://code.google.com/p/gcc-vcg-plugin/
Thanks,
Eric Fisher
> But C/C++ may have an another advantage, it can use ADT(Abstract Data
> Type) to extend its set of "primitive type", e.g., string.
>
But C++ may have an another advantage, it can use ADT(Abstract Data
Type) to extend its set of "primitive type", e.g., string.
--
徐持恒(Chiheng Xu)
Wuhan,China
On Tue, 2010-06-01 at 19:43 -0500, Gabriel Dos Reis wrote:
> On Tue, Jun 1, 2010 at 7:03 PM, DJ Delorie wrote:
>
> > Maybe you and I have completely different ideas about how the whole
> > class heirarchy works. I'm not a firm believer that the base-most
> > class should be an empty shell of a c
On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote:
> (2) we should prefer standard solution over home-grown hacks, unless
> there is a clear demonstration of value. For example, it would be
> unwise to prefer our current VEC_xxx over std::vector. Conversely,
>
On Wed, Jun 2, 2010 at 9:55 AM, 徐持恒 wrote:
> On Wed, Jun 2, 2010 at 8:38 AM, DJ Delorie wrote:
>>
>> "Hargett, Matt" writes:
As noted earlier I think we do want to use some STL classes.
>>>
>>> I agree with Mark's earlier declaration that it is relatively
>>> straight-forward, low-hanging f
On Jun 1, 2010, at 17:41, DJ Delorie wrote:
> It assumes your editor can do block-reformatting while preserving the
> comment syntax. I've had too many // cases of Emacs guessing wrong //
> and putting // throughout a reformatted // block.
With Ada we have no choice, and only have -- comments.
On Wed, Jun 2, 2010 at 8:38 AM, DJ Delorie wrote:
>
> "Hargett, Matt" writes:
>>> As noted earlier I think we do want to use some STL classes.
>>
>> I agree with Mark's earlier declaration that it is relatively
>> straight-forward, low-hanging fruit to replace VEC_*
>
> I do not object to simple
DJ Delorie writes:
>> 2) The parent class does not consist only of pure virtual methods.
>> In that case I am arguing that all virtual methods should be
>> protected.
>
> What about the case where the parent provides default implementations
> of methods that are infrequently overridden by childre
On Tue, Jun 1, 2010 at 8:41 PM, Ian Lance Taylor wrote:
> Gabriel Dos Reis writes:
>
>> As I matter of fact, I have comments about the conventions being put forward,
>> I do not know the proper way to get them reflected in the proposal.
>
> As I said earlier, send e-mail here, or update the wiki
Gabriel Dos Reis writes:
> As I matter of fact, I have comments about the conventions being put forward,
> I do not know the proper way to get them reflected in the proposal.
As I said earlier, send e-mail here, or update the wiki page. When
updating the wiki page, please put your name on all c
Bernd Schmidt writes:
> On 06/02/2010 01:42 AM, Ian Lance Taylor wrote:
>>> The 'this->' is needed when the current class and base class are both
>>> templates and the name is declared in the base class, and not if it's
>>> declared in the current class. That is not likely to happen in a
>>> hur
> > Right, but it may happen some day. Also there is the issue of
> > clarity. I think it is clearer to see this->get() rather than get().
>
> this->put_size (this->get_bounds (this->get_x(), this->get_y()),
> this->get_variance (this->default_variance ()))
I think clarity can b
On Tue, Jun 1, 2010 at 8:03 PM, DJ Delorie wrote:
>
>> I think that would be most unproductive and misguided.
>
> Maybe I should step back and restate my original desires.
>
> I don't want us to move *too quickly* towards an all-STL
> implementation, and end up with a hairy mess that's hard to
> u
> I think that would be most unproductive and misguided.
Maybe I should step back and restate my original desires.
I don't want us to move *too quickly* towards an all-STL
implementation, and end up with a hairy mess that's hard to
understand. I've had to debug our STL implementation before, it
Quoting Mark Mitchell :
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02255.html
OK, I see what that is doing. Why did you choose to use a .def file
rather than something more like Doxygen to generate the documentation?
It is not only used to generate documenation, but also to generate
initi
On Tue, Jun 1, 2010 at 7:47 PM, DJ Delorie wrote:
>
> Can we make a point of not using "Cpp" as a normalization of "C++" ?
strongly seconded.
> I keep thinking it's referring to the C preprocessor.
Same here.
> "Cxx" is less
> misleading (and kinda looks the same), when "C++" cannot be used fo
On Tue, Jun 1, 2010 at 7:38 PM, DJ Delorie wrote:
>
> "Hargett, Matt" writes:
>>> As noted earlier I think we do want to use some STL classes.
>>
>> I agree with Mark's earlier declaration that it is relatively
>> straight-forward, low-hanging fruit to replace VEC_*
>
> I do not object to simple
Can we make a point of not using "Cpp" as a normalization of "C++" ?
I keep thinking it's referring to the C preprocessor. "Cxx" is less
misleading (and kinda looks the same), when "C++" cannot be used for
character set reasons.
On 06/01/10 17:42, Ian Lance Taylor wrote:
The biggest need for this-> is when calling methods in the current
class if the current class happens to be in a template.
The 'this->' is needed when the current class and base class are both
templates and the name is declared in the base cl
On Tue, Jun 1, 2010 at 7:03 PM, DJ Delorie wrote:
> Maybe you and I have completely different ideas about how the whole
> class heirarchy works. I'm not a firm believer that the base-most
> class should be an empty shell of a class that does nothing but
> provide a placeholder for umpteen direct
On Tue, Jun 1, 2010 at 7:05 PM, DJ Delorie wrote:
>
>> Right, but it may happen some day. Also there is the issue of
>> clarity. I think it is clearer to see this->get() rather than get().
>
> this->put_size (this->get_bounds (this->get_x(), this->get_y()),
> this->get_variance (t
Mark Mitchell writes:
> So, my question is this: is the permission above sufficient for what
> people want to do at this point?
This permission exactly covers what libiberty does for its
documentation, you can use that as an example to RMS.
"Hargett, Matt" writes:
>> As noted earlier I think we do want to use some STL classes.
>
> I agree with Mark's earlier declaration that it is relatively
> straight-forward, low-hanging fruit to replace VEC_*
I do not object to simple and obvious uses of STL to replace equivalent
functionality,
On Tue, Jun 1, 2010 at 7:00 PM, Bernd Schmidt wrote:
> On 06/02/2010 01:42 AM, Ian Lance Taylor wrote:
>>> The 'this->' is needed when the current class and base class are both
>>> templates and the name is declared in the base class, and not if it's
>>> declared in the current class. That is not
Joern Rennecke wrote:
>> And if we need
>> more (as I suspect), can we be specific about what toolflow we want to
>> follow and what content will be generated? It would help if I could
>> show RMS inputs and outputs, not just with some random example, but with
>> GCC itself. Is someone willing t
Quoting Mark Mitchell :
At this point, RMS has said, answered this question from me:
"Can we take comments (not code) from FSF-owned GPL'd code and process
them in some way that results in them being included in a GFDL'd manual?"
We also need struct member declarations.
I.e type and name. In
> gold is using this convention, isn't it?
I find the gold sources harder to read than the rest of binutils, and
would like to avoid propogating that style elsewhere. This from
someone who's been writing C++ code for twenty years now.
Also, gold was added to binutils without this type of discus
> Right, but it may happen some day. Also there is the issue of
> clarity. I think it is clearer to see this->get() rather than get().
this->put_size (this->get_bounds (this->get_x(), this->get_y()),
this->get_variance (this->default_variance ()))
I'd like to avoid needing to a
> 2) The parent class does not consist only of pure virtual methods.
> In that case I am arguing that all virtual methods should be
> protected.
What about the case where the parent provides default implementations
of methods that are infrequently overridden by children? Otherwise,
you end up wi
On 06/02/2010 01:42 AM, Ian Lance Taylor wrote:
>> The 'this->' is needed when the current class and base class are both
>> templates and the name is declared in the base class, and not if it's
>> declared in the current class. That is not likely to happen in a
>> hurry while the convention is to
Jonathan Wakely writes:
> Nothing in C++ prevents a "struct" from having member functions,
> constructors, base classes, virtual functions, private members etc.
> If the intention is to impose a distinction between structs and
> classes, based on which keyword is used to define the type, the
> co
On Jun 1, 2010, Hariharan wrote:
> I have not had any response from Alexandre on this yet
Sorry, been on vacations, started looking into it last night, I think I
know why it fails and how to fix it. Expect a patch soon.
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You mu
DJ Delorie writes:
>> I did mean that all virtual functions should be protected.
>
> This forbids the most useful thing about virtual functions - letting
> child classes implement a public ABI defined by the base class.
There are really two cases to consider, and actually the coding
standard sho
As I mentioned last week, I've been talking to the SC and RMS about the
issue of automatically generating GFDL'd documentation from GPL'd code.
I will state explicitly up front a few topics I am not raising, because
I do not think they are either necessary, or likely to be productive:
* Whether o
On 4/25/10, Ian Lance Taylor wrote:
> Martin Guy writes:
>
> > now that stage3 is over I'm thinking of updating the
> > MaverickCrunch FPU fixes (currently for 4.3) and merging them but
> > would appreciate some guidance.
> >
> > There are 26 patches in all and I can't expect anyone to under
A suggestion about:
"Method bodies may only appear in the class definition if they are very short,
no more than five lines. Otherwise the method body should be defined outside of
the class definition."
To avoid dependency explosions that increase compile times and allow for
link-time substitut
> In a project with as many globals as we have, it's kinda handy to
> know at a glance whether a member function is accessing a data
> member or a global.
Add a globals-in-namespaces rule, or a ::global syntax, and you have
even more overkill.
IMHO we should make it easy to implement a clean d
On 01/06/2010 22:13, Ian Lance Taylor wrote:
>> * When a method refers to a non-static data member, it should always
>>qualify the reference with this->.
>>
>> I'm very opposed to this. To me, it makes the code less readable
>> because it lets the author write code that's hard to understand
Snapshot gcc-4.4-20100601 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100601/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> > My suggestions:
> >
> > * When it is appropriate to use a child class with virtual
> functions,
> >the virtual functions should all be declared as protected in the
> >parent class.
> >
> > At first reading, I thought you meant "all virtual functions should
> be
> > protected", but I th
On 1 June 2010 22:13, Ian Lance Taylor wrote:
> DJ Delorie writes:
>
>> My suggestions:
>>
>> * When it is appropriate to use a child class with virtual functions,
>> the virtual functions should all be declared as protected in the
>> parent class.
>>
>> At first reading, I thought you meant
> I did mean that all virtual functions should be protected.
This forbids the most useful thing about virtual functions - letting
child classes implement a public ABI defined by the base class.
> > * All data members should be private.
> > * All data members should have names which end with an
DJ Delorie writes:
> My suggestions:
>
> * When it is appropriate to use a child class with virtual functions,
>the virtual functions should all be declared as protected in the
>parent class.
>
> At first reading, I thought you meant "all virtual functions should be
> protected", but I t
Diego Novillo writes:
> 4- Should we make the switch during the 4.6 stage 1?
My suggestion: put something in one common file that requires C++, just
to force the use of C++ compilers, but with a comment that says "If you
can't build this file, comment out the following and file a bug report
with
On 06/01/2010 02:06 PM, Ralf Wildenhues wrote:
> [ moving from autoconf@ to -patches ]
>
> * Richard Guenther wrote on Tue, Jun 01, 2010 at 01:52:07PM CEST:
>>
>> Any progress here? If we want to switch on --enable-build-with-cxx
>> by default then this has to be addressed.
>
> Proposed patches
My suggestions:
* When it is appropriate to use a child class with virtual functions,
the virtual functions should all be declared as protected in the
parent class.
At first reading, I thought you meant "all virtual functions should be
protected", but I think you meant "if a child ADDS a
On 06/01/2010 02:06 PM, Ralf Wildenhues wrote:
> Any other issues with it?
> Subject: [PATCH 1/2] Generalize AC_CHECK_DECL for C++: allow optional
> arguments.
>
> * general.m4 (_AC_CHECK_DECL_BODY): Process trailing function
> argument types as arguments to use for C++.
> (_AC_CHECK_DECLS): Fil
[ moving from autoconf@ to -patches ]
* Richard Guenther wrote on Tue, Jun 01, 2010 at 01:52:07PM CEST:
>
> Any progress here? If we want to switch on --enable-build-with-cxx
> by default then this has to be addressed.
Proposed patches for Autoconf. Tested with CC=g++ in TESTSUITEFLAGS and
wit
This is a reworked patch of Andrew Pinski "Subscripting on vector
types" in terms of GSoC 2010 [Artjoms Sinkarovs].
This patch allows to index individual elements of vector type in C.
For example: vec[i], where vec is a vector with a base type T and i is
an integer type.
If i is a constant then we
* Joern Rennecke wrote on Tue, Jun 01, 2010 at 09:11:03PM CEST:
> Quoting Ralf Wildenhues:
> >* Toon Moene wrote on Tue, Jun 01, 2010 at 08:36:53PM CEST:
> >>
> >> In file included from ../../gcc/libcpp/system.h:341,
> >> from ../../gcc/libcpp/expr.c:21:
> >>../../gcc/libcpp/../incl
Quoting Ralf Wildenhues :
* Toon Moene wrote on Tue, Jun 01, 2010 at 08:36:53PM CEST:
In file included from ../../gcc/libcpp/system.h:341,
from ../../gcc/libcpp/expr.c:21:
../../gcc/libcpp/../include/libiberty.h:106: error: new declaration
‘char* basename(const char*)’
/usr/i
* Toon Moene wrote on Tue, Jun 01, 2010 at 08:36:53PM CEST:
>
> In file included from ../../gcc/libcpp/system.h:341,
> from ../../gcc/libcpp/expr.c:21:
> ../../gcc/libcpp/../include/libiberty.h:106: error: new declaration
> ‘char* basename(const char*)’
> /usr/include/string.h:60
On 06/01/2010 08:02 PM, Diego Novillo wrote:
On Tue, Jun 1, 2010 at 14:00, Toon Moene wrote:
On 06/01/2010 06:07 PM, Richard Guenther wrote:
After fixing build locally I now have
Are you planning to commit the fixes - I don't mind being a guinea pig in
this - I have been recompiling gcc/
Basile Starynkevitch writes:
> On Tue, 2010-06-01 at 10:33 -0700, Ian Lance Taylor wrote:
>> Here are the slides from my presentation on the topic at the 2008 GCC
>> Summit: http://airs.com/ian/cxx-slides.pdf .
>
>
> Ian, what is that status of your GCC in C++ branch? What should be
> re-usable f
On Tue, Jun 1, 2010 at 14:00, Toon Moene wrote:
> On 06/01/2010 06:07 PM, Richard Guenther wrote:
>
>> After fixing build locally I now have
>
> Are you planning to commit the fixes - I don't mind being a guinea pig in
> this - I have been recompiling gcc/gfortran and rebuilding our weather
> fore
On 06/01/2010 06:07 PM, Richard Guenther wrote:
After fixing build locally I now have
Are you planning to commit the fixes - I don't mind being a guinea pig
in this - I have been recompiling gcc/gfortran and rebuilding our
weather forecasting code now for a few weeks (almost) daily.
I alre
On Tue, 2010-06-01 at 10:33 -0700, Ian Lance Taylor wrote:
> Here are the slides from my presentation on the topic at the 2008 GCC
> Summit: http://airs.com/ian/cxx-slides.pdf .
Ian, what is that status of your GCC in C++ branch? What should be
re-usable from it? Do you think it makes sense to re
Rich Wallick writes:
> I hope you don't mind my comment as I an not a project member, just a
> long term multi-platform GCC user. With all due respect, I fail to
> understand the decision to switch to C++ without being able to elucidate
> the specific features of C++ that will benefit the GCC
Dongsheng Song writes:
> When I cross build gcc on linux-amd64 box, I got a include files
> search order error:
This question is not appropriate for the mailing list
g...@gcc.gnu.org. It would be appropriate for gcc-h...@gcc.gnu.org.
Please take any followups to gcc-help. Thanks.
> /root/obj/
Richard Guenther writes:
> Overall the wiki document looks good. I'd like to disallow
>
> * Operators may only be overloaded for types which implement numeric
> values, where the overloaded operators implement the usual numeric
> semantics.
>
> though.
My thinking here is that it would be reaso
Richard Guenther wrote:
On Tue, Jun 1, 2010 at 12:00 PM, Richard Guenther
wrote:
On Mon, May 31, 2010 at 6:22 PM, Diego Novillo wrote:
Now that the SC and the FSF have agreed to this, we should decide whether we
switch and how. So, I would like comments on the following questions:
1
Mark Mitchell writes:
> Richard Guenther wrote:
>
>> Btw - can we intially just link with libsup++ omitting libstdc++ so
>> that we do not get the expected flood of convert-to-STL patches?
>> Or is the idea of an STL free gcc bad?
>
> I view STL as one of the bits of low-hanging C++ fruit. I thi
Richard Guenther wrote:
On Tue, Jun 1, 2010 at 4:48 PM, Mark Mitchell wrote:
Ian Lance Taylor wrote:
I have written a proposed set of C++ coding conventions on the wiki at
http://gcc.gnu.org/wiki/CppConventions
This is only a preliminary proposal. It requires fleshing out and
discussion
Hi,
I hope you don't mind my comment as I an not a project member, just a
long term multi-platform GCC user. With all due respect, I fail to
understand the decision to switch to C++ without being able to elucidate
the specific features of C++ that will benefit the GCC team and the GCC
compiler
On Tue, Jun 1, 2010 at 12:00 PM, Richard Guenther
wrote:
> On Mon, May 31, 2010 at 6:22 PM, Diego Novillo wrote:
>>
>> Now that the SC and the FSF have agreed to this, we should decide whether we
>> switch and how. So, I would like comments on the following questions:
>>
>> 1- Should we switch t
Richard Guenther wrote:
> Btw - can we intially just link with libsup++ omitting libstdc++ so
> that we do not get the expected flood of convert-to-STL patches?
> Or is the idea of an STL free gcc bad?
I view STL as one of the bits of low-hanging C++ fruit. I think we're
all vaguely confused by
Hi,
When I cross build gcc on linux-amd64 box, I got a include files
search order error:
...
/root/obj/gcc-4.2/./gcc/xgcc -B/root/obj/gcc-4.2/./gcc/
-L/root/obj/gcc-4.2/i686-pc-mingw32/winsup/mingw
-L/root/obj/gcc-4.2/i686-pc-mingw32/winsup/w32api/lib -isystem
/root/src/gcc-4.2.4/winsup/mingw/in
Mark Mitchell writes:
> Ian Lance Taylor wrote:
>
>> I have written a proposed set of C++ coding conventions on the wiki at
>> http://gcc.gnu.org/wiki/CppConventions
>>
>> This is only a preliminary proposal. It requires fleshing out and
>> discussion.
>
> Thank you for volunteering to do t
On Tue, Jun 1, 2010 at 4:48 PM, Mark Mitchell wrote:
> Ian Lance Taylor wrote:
>
>> I have written a proposed set of C++ coding conventions on the wiki at
>> http://gcc.gnu.org/wiki/CppConventions
>>
>> This is only a preliminary proposal. It requires fleshing out and
>> discussion.
>
> Thank
Ian Lance Taylor wrote:
> I have written a proposed set of C++ coding conventions on the wiki at
> http://gcc.gnu.org/wiki/CppConventions
>
> This is only a preliminary proposal. It requires fleshing out and
> discussion.
Thank you for volunteering to do this. How would you like to receive
I fat-fingered what I thought was a git local command, and committed
revision 160105 with bogus changes. If you have rev 160105 checked out,
please update your tree.
Apologies for the mix up. I'll go hide now.
Diego.
I would highly suggest looking at google guidelines.
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
They are aimed at taking some of the landlines out of c++ and give pros and
cons for each argument.
There are many places in the gcc source where we are already doing C++ thing
Paolo Bonzini writes:
> Also, in general compiler IRs are used in so many places that a
> "pattern matching" style (similar to ML) actually works better than a
> "class hierarchy" style. In other words, I doubt that C++ would
> remove many of the switch statements we have in the code. With
> re
On Thu, Feb 18, 2010 at 1:26 AM, Paolo Bonzini wrote:
>>> Maybe we can use this in AC_CHECK_DECLS instead of having a new
>>> separate macro. If there is a parenthesis in the name call the new
>>> version, if there is none, call the old one.
>>
>> You shouldn't need to keep the old version around
On Mon, May 31, 2010 at 6:22 PM, Diego Novillo wrote:
>
> Now that the SC and the FSF have agreed to this, we should decide whether we
> switch and how. So, I would like comments on the following questions:
>
> 1- Should we switch to C++?
Yes.
> 2- What is the cost in terms of build time?
I wa
Hi Jakub,
I have not had any response from Alexandre on this yet and i haven't had
much luck in mailing list either
(http://gcc.gnu.org/ml/gcc/2010-04/msg00917.html). Is there anyone else
who is familiar with VTA who could help?
Thanks
Hari
jakub at gcc dot gnu dot org wrote:
Ira,
Thanks for the answer.
> The loop that got vectorized in the older revision is another loop
> associated with the same source code line:
Upon further investigation this loops is likely related to a temporary that
have been removed in recent versions. Using the older revision with
-Warray-te
Hello
On 01.06.10, you wrote:
> making
>> it take a hundred times more specifically in the changed places would
>> magnify the 0.1% overall change to a measurable delta of 10%.
> Your argument is applicable to any changes in GCC, not just to C to C++
> conversions. Do patches that slow down the
On 05/31/2010 06:26 PM, Basile Starynkevitch wrote:
On Mon, 2010-05-31 at 08:53 -0700, Mark Mitchell wrote:
There's no reason to get into these kinds of questions at this point.
The goal is not to reimplement GCC from the ground up using modern
OO/C++ techniques. The goal is simply to permit ou
On Tue, Jun 1, 2010 at 10:22 AM, Duncan Sands wrote:
> [*] It is possible to choose which targets to build when configuring LLVM.
> If only one is chosen then of course that's the only one that can be chosen
> at run-time.
This should eventually be made possible in GCC too. It's what all the
targ
On 01/06/10 10:03, Paolo Bonzini wrote:
On 05/31/2010 12:30 PM, 徐持恒 wrote:
I think compiler can and should be host independent, like LLVM.
It is. Changes to code generation depending on the host are considered
to be serious bugs, and have been long before LLVM existed.
Perhaps 徐持恒 meant targ
On Mon, 31 May 2010 18:24:00 -0400, Joern Rennecke wrote:
> Quoting Vladimir Makarov :
>> Reviewers are frequently busy. I bet not a lot of reviewers apply
>> patches and play with it.
>>
>> So it would be nice that people who submits such patches report changes
>> in compile time/footprint/build
On 05/31/2010 12:30 PM, 徐持恒 wrote:
I think compiler can and should be host independent, like LLVM.
It is. Changes to code generation depending on the host are considered
to be serious bugs, and have been long before LLVM existed.
Paolo
89 matches
Mail list logo
