On Mon, May 31, 2010 at 12:28 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
At last, there is a very important issue when switching to C++. What is
our ideal class hierarchy?
The ideal class hierarchy is independent of the language used. The language
matters only to the extend that
For example, I think it goes without question that at this point we are
limiting ourselves to C++98 (plus long long so that we have a 64-bit
integer type);
Where does this long long requirement come from? We should only require an
ISO C++98 compiler, just like we currently require only an ISO
On Fri, May 28, 2010 at 11:32:46AM -0700, Ian Lance Taylor wrote:
Please read http://gcc.gnu.org/PR25509 .
As the compiler documentation states, warn_unused_result was intended
for cases where failing to check the return value is always a security
risk or a bug. The documentation cites the
On Mon, May 31, 2010 at 01:39:08AM -0500, Gabriel Dos Reis wrote:
On Mon, May 31, 2010 at 12:28 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
At last, there is a very important issue when switching to C++. What is
our ideal class hierarchy?
The ideal class hierarchy is
Hallo,
i would like to instrument some existing code. For example, after an ADD-EXPR:
int main() {
int a=5;
int b=5;
int c = a + b; ...
}
should become:
...
int c = a + b;
puts(ADD-EXPR);
...
I thought writing a Gimple-pass would be best, but i don't know exactly where
to start. I'm
Eric Botcazou ebotca...@adacore.com writes:
Where does this long long requirement come from? We should only require an
ISO C++98 compiler, just like we currently require only an ISO C90 compiler.
C90 does not have long long either, yet we use it as required (for HWI).
Andreas.
--
Andreas
C90 does not have long long either, yet we use it as required (for HWI).
No, we use it when present but we don't require it, see hwint.h.
--
Eric Botcazou
On 05/31/2010 11:48 AM, Eric Botcazou wrote:
C90 does not have long long either, yet we use it as required (for HWI).
No, we use it when present but we don't require it, see hwint.h.
Both of you are right, as our requirements for building a cross compiler
are stricter than for a native
Sent from my iPhone
On May 31, 2010, at 2:48 AM, Eric Botcazou ebotca...@adacore.com
wrote:
C90 does not have long long either, yet we use it as required (for
HWI).
No, we use it when present but we don't require it, see hwint.h.
Kinda. It depends on the host and target. If the
Both of you are right, as our requirements for building a cross compiler
are stricter than for a native compiler.
We do require long long for 32-64 cross compilers.
Right, only in this case, and I don't see why this should be changed with the
transition to C++, that's orthogonal.
--
Eric
Eric Botcazou ebotca...@adacore.com writes:
Right, only in this case, and I don't see why this should be changed with the
transition to C++, that's orthogonal.
It will be used as required.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7
On Mon, May 31, 2010 at 8:26 AM, Mark Mitchell m...@codesourcery.com wrote:
I am pleased to report that the GCC Steering Committee and the FSF have
approved the use of C++ in GCC itself. Of course, there's no reason for
us to use C++ features just because we can. The goal is a better
On Mon, May 31, 2010 at 5:54 PM, Andrew Pinski pins...@gmail.com wrote:
Sent from my iPhone
On May 31, 2010, at 2:48 AM, Eric Botcazou ebotca...@adacore.com wrote:
C90 does not have long long either, yet we use it as required (for HWI).
No, we use it when present but we don't require it,
徐持恒 wrote:
I have FUD on the use of advanced C++ features like template(even
standard template), namespace, exceptions. This is partly because my
favorite source code analyzer can not handle them properly. I have
tried to use my favorite source code analyzer to analyze LLVM source
code, which
On Mon, May 31, 2010 at 6:41 PM, Robert Dewar de...@adacore.com wrote:
It's a pity to exclude namespaces, the advantage of breaking the
single-big-namespace model are evident.
Yes, the advantage of namespace is obvious.
But, I think namespace is just a syntax sugar. You can name your
On Mon, May 31, 2010 at 12:41 PM, Robert Dewar de...@adacore.com wrote:
徐持恒 wrote:
I have FUD on the use of advanced C++ features like template(even
standard template), namespace, exceptions. This is partly because my
favorite source code analyzer can not handle them properly. I have
tried
徐持恒 wrote:
On Mon, May 31, 2010 at 6:41 PM, Robert Dewar de...@adacore.com wrote:
It's a pity to exclude namespaces, the advantage of breaking the
single-big-namespace model are evident.
Yes, the advantage of namespace is obvious.
But, I think namespace is just a syntax sugar. You can name
On Mon, May 31, 2010 at 12:59 PM, Robert Dewar de...@adacore.com wrote:
徐持恒 wrote:
On Mon, May 31, 2010 at 6:41 PM, Robert Dewar de...@adacore.com wrote:
It's a pity to exclude namespaces, the advantage of breaking the
single-big-namespace model are evident.
Yes, the advantage of namespace
There are several C++ features which not all compilers support well,
these features should be avoided if possible.
For example VC++ 2008 treats
struct foo{ static const int bar=1; };
As if the coder has also written (at the same spot)
const int foo::bar;
The consequence is
One interesting issue is whether it is important for gcc to be
able to be compiled with foreign compilers (other than gcc).
I know that historically this has been an important requirement,
but I wonder whether it is still relevant.
Gcc is very widespread at this point. Yes, there is the issue
On Mon, May 31, 2010 at 3:42 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Mon, May 31, 2010 at 01:39:08AM -0500, Gabriel Dos Reis wrote:
On Mon, May 31, 2010 at 12:28 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
At last, there is a very important issue when
On Mon, May 31, 2010 at 4:58 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Mon, May 31, 2010 at 3:42 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Mon, May 31, 2010 at 01:39:08AM -0500, Gabriel Dos Reis wrote:
On Mon, May 31, 2010 at 12:28 AM, Basile Starynkevitch
On Mon, May 31, 2010 at 5:03 PM, Richard Guenther
richard.guent...@gmail.com wrote:
And we definitely should not do so just because we can. I see
little value in turning our tree upside-down just because we now
can use C++ and make everything a class rather than a union.
If hiding the
On Mon, May 31, 2010 at 7:22 AM, Robert Dewar de...@adacore.com wrote:
One interesting issue is whether it is important for gcc to be
able to be compiled with foreign compilers (other than gcc).
I know that historically this has been an important requirement,
but I wonder whether it is still
On Mon, May 31, 2010 at 10:03 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, May 31, 2010 at 4:58 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Mon, May 31, 2010 at 3:42 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Mon, May 31, 2010 at 01:39:08AM
For example, I think it goes without question that at this point we are
limiting ourselves to C++98 (plus long long so that we have a 64-bit
integer type); C++0x features should not be used. Using multiple
inheritance, templates (other than when using the C++ standard library,
e.g. std::listX),
On Mon, May 31, 2010 at 5:09 PM, Steven Bosscher stevenb@gmail.com wrote:
On Mon, May 31, 2010 at 5:03 PM, Richard Guenther
richard.guent...@gmail.com wrote:
And we definitely should not do so just because we can. I see
little value in turning our tree upside-down just because we now
can
Eric Botcazou wrote:
We do require long long for 32-64 cross compilers.
Right, only in this case, and I don't see why this should be changed with the
transition to C++, that's orthogonal.
I agree.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Gabriel Dos Reis g...@integrable-solutions.net writes:
[...] I do not think so, and I would not suggest that the use of
C++ is an excuse do ditch the possibility of bootstrapping with
anything other than GCC.
Right. It would be good to enumerate any language/design constraints
that other
On Mon, May 31, 2010 at 5:29 PM, David Fang f...@csl.cornell.edu wrote:
For example, I think it goes without question that at this point we are
limiting ourselves to C++98 (plus long long so that we have a 64-bit
integer type); C++0x features should not be used. Using multiple
inheritance,
On Mon, May 31, 2010 at 10:29 AM, David Fang f...@csl.cornell.edu wrote:
For example, I think it goes without question that at this point we are
limiting ourselves to C++98 (plus long long so that we have a 64-bit
integer type); C++0x features should not be used. Using multiple
inheritance,
On Mon, May 31, 2010 at 11:09, Steven Bosscher stevenb@gmail.com wrote:
On Mon, May 31, 2010 at 5:03 PM, Richard Guenther
richard.guent...@gmail.com wrote:
And we definitely should not do so just because we can. I see
little value in turning our tree upside-down just because we now
can
Basile Starynkevitch wrote:
At last, there is a very important issue when switching to C++. What is
our ideal class hierarchy? Do we aim at a large forest, or on the
contrary at a single tree of classes, so we have a single root class,
providing common services (dump or debug printing,
On Mon, May 31, 2010 at 11:27, Richard Guenther
richard.guent...@gmail.com wrote:
Well - if somebody does the work and _completely_ converts
tree and its accessor functions and macros to use a class-based
tree then more power to him. What I do not like to see is
partial conversions to C++.
On Mon, May 31, 2010 at 11:54, Richard Guenther
richard.guent...@gmail.com wrote:
It's a lot of work (tree extends in all three Frontends, middle-end
and backends). And my fear is we'll only get a halfway transition -
something worse than no transition at all.
Yeah, that's true.
Diego.
Mark Mitchell wrote:
I am pleased to report that the GCC Steering Committee and the FSF have
approved the use of C++ in GCC itself. Of course, there's no reason for
us to use C++ features just because we can. The goal is a better
compiler for users, not a C++ code base for its own sake.
On Mon, May 31, 2010 at 5:53 PM, Diego Novillo dnovi...@google.com wrote:
On Mon, May 31, 2010 at 11:09, Steven Bosscher stevenb@gmail.com wrote:
On Mon, May 31, 2010 at 5:03 PM, Richard Guenther
richard.guent...@gmail.com wrote:
And we definitely should not do so just because we can. I
On Mon, May 31, 2010 at 12:00:21PM -0400, Vladimir Makarov wrote:
Mark Mitchell wrote:
I am pleased to report that the GCC Steering Committee and the FSF have
approved the use of C++ in GCC itself. Of course, there's no reason for
us to use C++ features just because we can. The goal is a
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++?
2- What is the cost in terms of build time?
3- What coding guidelines should we use?
4- Should we make the switch
On Mon, 2010-05-31 at 08:53 -0700, Mark Mitchell wrote:
Basile Starynkevitch wrote:
At last, there is a very important issue when switching to C++. What is
our ideal class hierarchy? Do we aim at a large forest, or on the
contrary at a single tree of classes, so we have a single root
On Sat, 2010-05-29 at 22:40 -0700, Joe Buck wrote:
On Sat, May 29, 2010 at 01:39:44AM -0700, Basile Starynkevitch wrote:
... I was told that
generating a *texi file from (GPLv3+ licensed, FSF copyrighted) source
code could be incompatible with the GFDL license of gccint.texi.
The SC is
Basile Starynkevitch wrote:
Except that perhaps these questions are important for any gengtype
enhancement. In particular, one could consider that marking a GTY-ed
data would be done by a virtual method (generated by gengtype), and then
having every GTY-ed data inheriting from an abstract
I'm not enthusiastic about that either.
FWIW neither am I.
Nor will grow the memory footprint, at least of the important data
structures, or increase maintanance costs by making the code less readable,
etc.
It's clear that we don't want blind conversions to fancy C++ style, but Mark
was
Jakub Jelinek wrote:
I just really hope we will have strict criteria that any transition will
not make compiler slower and will not increase compiler build time.
Nor will grow the memory footprint, at least of the important data
structures, or increase maintanance costs by making the code
On Mon, May 31, 2010 at 11:22 AM, Diego Novillo dnovi...@google.com 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++?
By switch, do you using a C++ compiler to
Basile Starynkevitch wrote:
To my greatest extremely positive surprise, I got today an answer from
the FSF (I really am very happy of such a quick answer)! I hope it OK to
cite here part of the reply I've got to my question [gnu.org #579118]
to licens...@fsf.org since Karl Berry replied to me
On 10-05-31 12:50 , Gabriel Dos Reis wrote:
By switch, do you using a C++ compiler to compile everything, or that some
components may be written only in C++ with sufficient care that they can be
linked with other part written in C?
Ideally, the former. If we cannot get consensus on that,
On Mon, May 31, 2010 at 09:44:08AM -0700, Mark Mitchell wrote:
I just really hope we will have strict criteria that any transition will
not make compiler slower and will not increase compiler build time.
Nor will grow the memory footprint, at least of the important data
structures, or
Richard Guenther wrote:
Oh - and we didn't yet decide to switch to C++ as implementation
language. Did we?
I'm not sure exactly what you're asking. We now have permission to
switch. The reason we wanted permission to switch was that there was a
consensus that we wanted to switch; as far as
On Mon, May 31, 2010 at 11:54 AM, Diego Novillo dnovi...@google.com wrote:
On 10-05-31 12:50 , Gabriel Dos Reis wrote:
By switch, do you using a C++ compiler to compile everything, or that some
components may be written only in C++ with sufficient care that they can
be
linked with other part
On Mon, May 31, 2010 at 11:54 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, May 31, 2010 at 09:44:08AM -0700, Mark Mitchell wrote:
I just really hope we will have strict criteria that any transition will
not make compiler slower and will not increase compiler build time.
Nor will grow
On Mon, May 31, 2010 at 12:11:14PM -0500, Gabriel Dos Reis wrote:
aren't we already doing this with the various hooks we have?
Currently hooks are used mainly for target or language hooks, that's far
different from using virtual methods say on the tree or rtl objects.
We do not need to
On Mon, May 31, 2010 at 12:02 PM, Mark Mitchell m...@codesourcery.com wrote:
Richard Guenther wrote:
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer to data objects and in uninlinable
indirect calls at run-time. Therefore, I would avoid
Gabriel Dos Reis wrote:
There are good C++ coding standards out there, and I would be reluctant
to encourage a NIH-driven design as opposed to adapting existing ones
that have been given lot of considerations:
http://www2.research.att.com/~bs/bs_faq2.html#coding-standard
Gabriel Dos Reis wrote:
On Mon, May 31, 2010 at 11:54 AM, Jakub Jelinek ja...@redhat.com wrote:
Similarly if the compiler massively starts using virtual methods everywhere,
there will be slow downs caused by the increased number of harder to predict
indirect calls.
that is why
On Mon, May 31, 2010 at 12:31 PM, Mark Mitchell m...@codesourcery.com wrote:
Gabriel Dos Reis wrote:
There are good C++ coding standards out there, and I would be reluctant
to encourage a NIH-driven design as opposed to adapting existing ones
that have been given lot of considerations:
On Mon, May 31, 2010 at 12:33 PM, Vladimir Makarov vmaka...@redhat.com wrote:
So it would be nice that people who submits such patches report changes in
compile time/footprint/build time
I thought this has been part of our usual procedure for a while now.
-- Gaby
Gabriel Dos Reis wrote:
On Mon, May 31, 2010 at 12:33 PM, Vladimir Makarov vmaka...@redhat.com wrote:
So it would be nice that people who submits such patches report changes in
compile time/footprint/build time
I thought this has been part of our usual procedure for a while now.
Mark Mitchell m...@codesourcery.com writes:
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer to data objects and in uninlinable
indirect calls at run-time. Therefore, I would avoid them in the
Is that still true given profile feedback
On Mon, May 31, 2010 at 11:22, Diego Novillo dnovi...@google.com wrote:
Now that the SC and the FSF have agreed to this.
When did this come up and why? Where can I read more about this? Was
there a thread I missed?
On Mon, May 31, 2010 at 13:21, Michael Witten mfwit...@gmail.com wrote:
On Mon, May 31, 2010 at 11:22, Diego Novillo dnovi...@google.com wrote:
Now that the SC and the FSF have agreed to this.
When did this come up and why? Where can I read more about this? Was
there a thread I missed?
Diego Novillo wrote:
By switch, do you using a C++ compiler to compile everything, or that
some
components may be written only in C++ with sufficient care that they
can be
linked with other part written in C?
Ideally, the former. If we cannot get consensus on that, then I guess
we'd
On Mon, May 31, 2010 at 1:25 PM, Mark Mitchell m...@codesourcery.com wrote:
Diego Novillo wrote:
By switch, do you using a C++ compiler to compile everything, or that
some
components may be written only in C++ with sufficient care that they
can be
linked with other part written in C?
Andi Kleen wrote:
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer to data objects and in uninlinable
indirect calls at run-time. Therefore, I would avoid them in the
Is that still true given profile feedback and the recent
Gabriel Dos Reis wrote:
Yes, this is the sort of issues I have in mind. For example, I do not see how
we can use C++ in tree.h without requiring other front-ends to use C++, at
least
for the parts that use tree.h. By components, I meant for example, is it the
case that the C++ front-end
Hi,
I am working on generating vzeroupper to avoid AVX-SSE transition
penalty.
I have generated vzeroupper on function return as well as function
call. I am working on a backend pass to eliminate those vzeroupper
instructions when I can prove that the upper 128bits of AVX registers
are dead at
Am 31.05.2010 20:50, schrieb Mark Mitchell:
Gabriel Dos Reis wrote:
Yes, this is the sort of issues I have in mind. For example, I do not see
how
we can use C++ in tree.h without requiring other front-ends to use C++, at
least
for the parts that use tree.h. By components, I meant for
On Mon, May 31, 2010 at 1:50 PM, Mark Mitchell m...@codesourcery.com wrote:
Gabriel Dos Reis wrote:
Yes, this is the sort of issues I have in mind. For example, I do not see
how
we can use C++ in tree.h without requiring other front-ends to use C++, at
least
for the parts that use
H.J. Lu wrote:
Hi,
I am working on generating vzeroupper to avoid AVX-SSE transition
penalty.
I have generated vzeroupper on function return as well as function
call. I am working on a backend pass to eliminate those vzeroupper
instructions when I can prove that the upper 128bits of AVX
On Mon, 2010-05-31 at 11:48 -0700, Mark Mitchell wrote:
Andi Kleen wrote:
Don't get me wrong; I think virtual functions are very useful. The
target hooks and language hooks we have are essentially poor man's
virtual functions, and we could naturally (and mechanically) convert
them to
Gabriel Dos Reis wrote:
OK, I will reformulate my question to you and Diego is: is this what we want,
e.g. C++ as THE common implementation language, or just ONE common
implementation language (the other being C)?
I believe that we want (a subset of) C++ to be the language used to
implement
On Mon, May 31, 2010 at 15:33, Mark Mitchell m...@codesourcery.com wrote:
I believe that we want (a subset of) C++ to be the language used to
implement all of GCC, including front-ends, back-ends, and common code.
Where we currently use C, we wish to instead use C++.
That's what I want as
On Mon, May 31, 2010 at 2:35 PM, Diego Novillo dnovi...@google.com wrote:
On Mon, May 31, 2010 at 15:33, Mark Mitchell m...@codesourcery.com wrote:
I believe that we want (a subset of) C++ to be the language used to
implement all of GCC, including front-ends, back-ends, and common code.
Basile Starynkevitch wrote:
To my greatest extremely positive surprise, I got today an answer from
the FSF (I really am very happy of such a quick answer)! I hope it OK to
cite here part of the reply I've got to my question [gnu.org #579118]
to licens...@fsf.org since Karl Berry replied to
On 05/31/2010 06: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:
H, when I voted yes on the question Requiring C++ Compiler for
GCC Builds (that was the subject
On Mon, 2010-05-31 at 12:33 -0700, Mark Mitchell wrote:
Gabriel Dos Reis wrote:
OK, I will reformulate my question to you and Diego is: is this what we
want,
e.g. C++ as THE common implementation language, or just ONE common
implementation language (the other being C)?
I believe
On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov vmaka...@redhat.com wrote:
H.J. Lu wrote:
Hi,
I am working on generating vzeroupper to avoid AVX-SSE transition
penalty.
I have generated vzeroupper on function return as well as function
call. I am working on a backend pass to eliminate
H.J. Lu wrote:
On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov vmaka...@redhat.com wrote:
H.J. Lu wrote:
Hi,
I am working on generating vzeroupper to avoid AVX-SSE transition
penalty.
I have generated vzeroupper on function return as well as function
call. I am working on a
On Mon, 2010-05-31 at 12:51 -0400, Robert Dewar wrote:
Basile Starynkevitch wrote:
To my greatest extremely positive surprise, I got today an answer from
the FSF (I really am very happy of such a quick answer)! I hope it OK to
cite here part of the reply I've got to my question [gnu.org
Because C++ is a big language, I think we should try to enumerate what
is OK, rather than what is not OK.
Is there anyone who would like to volunteer to develop the C++ coding
standards?
I hope you you don't mind my question (as I am currently not an active GCC
developer), but what is the
Thomas Neumann wrote:
Now I know that this is totally unrealistic in the context of the GCC
project, and some people here get really nervous about a potential C++
creep, but IMHO artificial limitations on a pure syntax base are not really
meaningful. One should look at the consequences and
Basile Starynkevitch wrote:
You forgot to mention plugins. In my understanding, any future GCC
plugin would necessarily be coded in C++ and be compiled by a C++
compiler. Am I right?
Not necessarily. If we felt it desirable, the interface exposed for
plug-ins could be C, not C++. However, I
Well anyone can think anything, but this view is way out of the
mainstream. I do not know of a single large real project using a
large complex language that does not have coding standards that
limit the use of the language.
I know this, but I do not understand this. I have worked in reasonably
Quoting Vladimir Makarov vmaka...@redhat.com:
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 time (at least I am going to ask this
for parts
Quoting Gabriel Dos Reis g...@integrable-solutions.net:
Definitely. That document is interesting in that it offers views
and rationale
about some of the restrictions being put forward. For example, I would not
discount easily sections 4.10, 4.11, 4.12.
I think we have grounds to modify
On 05/31/2010 04:36 PM, Thomas Neumann wrote:
Well anyone can think anything, but this view is way out of the
mainstream. I do not know of a single large real project using a
large complex language that does not have coding standards that
limit the use of the language.
I know this, but I
On Tue, Jun 1, 2010 at 1:12 AM, Joel Sherrill joel.sherr...@oarcorp.com wrote:
Another thing that has bothered me is the fear of
getting slower. If using C++ makes GCC slower, then
GCC C++ needs to get faster. This is eating our own
dog food. :)
Indeed. If we can avoid the obvious problems
On 05/31/10 14:30, Basile Starynkevitch wrote:
[snip]
I would believe that replacing a complex function like above (which
contains a switch) with a virtual function call could probably be a win
in performance, not a loose.
But perhaps my intuition is wrong. Honestly, I don't have exact
On Mon, May 31, 2010 at 6:29 PM, Larry Evans cppljev...@suddenlink.net wrote:
However, that boost devel post claims using a switch statement would
be faster.
Switching to C++ should never be excuse to bring more more brittle codes
or more obscurities. Rather, it should be opportunity to write
On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov vmaka...@redhat.com wrote:
H.J. Lu wrote:
Hi,
I am working on generating vzeroupper to avoid AVX-SSE transition
penalty.
I have generated vzeroupper on function return as well as function
call. I am working on a backend pass to eliminate
The GCC internal document says [1]:
[quote]
In the early stages of register allocation, a REG_EQUAL note is changed
into a REG_EQUIV note if op is a constant and the insn represents the
only set of its destination register.
Thus, compiler passes prior to register allocation need only check
On May 31, 2010, at 14:25, Mark Mitchell wrote:
That doesn't necessarily mean that we have to use lots of C++ features
everywhere. We can use the C (almost) subset of C++ if we want to in
some places. As an example, if the Fortran folks want to use C in the
Fortran front-end, then -- except
On 05/31/2010 08:17 PM, H.J. Lu wrote:
On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarovvmaka...@redhat.com wrote:
H.J. Lu wrote:
Hi,
I am working on generating vzeroupper to avoid AVX-SSE transition
penalty.
I have generated vzeroupper on function return as well as function
Geert Bosch wrote:
If we're just going to get some new power tools for our workshop
and let people have at it, the lessons we'll learn might end up
being more about what not to do, rather than a show case of their
effective use.
That's why we're not doing that. Instead, we're going to
On Mon, 2010-05-31 at 22:46 +0200, Basile Starynkevitch wrote:
I did wrote on http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02442.html
about the patch I intend to apply to the MELT branch (changing copyright
notice of gcc/melt/warmelt*.melt files there).
I also emailed k...@gnu.org about
Basile Starynkevitch bas...@starynkevitch.net writes:
What I am very scared of, is to make someone at FSF unhappy or angry
against me. I have a very fuzzy perception of the FSF [I'm living on a
different continent, I am not a native English speaker, etc..]. I don't
know who is an influent
christophe.ja...@ouvaton.org writes:
I browsed your html documentation at http://gcc.gnu.org/onlinedocs/
and would like to know if there is a way to obtain GCC documentation
in .info format from your website, as is proposed by almost all other
software projects from GNU (see
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-05-31 06:54
---
Please attach the gnatchop-ed file.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from mikpe at it dot uu dot se 2010-05-31 07:20 ---
The bootstrap comparison failure is gone on armv5tel-unknown-linux-gnueabi with
gcc-4.6-20100529. Thus closing as fixed.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
1 - 100 of 198 matches
Mail list logo
