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
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
> 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 l
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 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 Schwab, sch...@redh
> 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 compi
Sent from my iPhone
On May 31, 2010, at 2: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.
Kinda. It depends on the host and target. If the target requires 64bit
hos
> 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.
--
Er
Eric Botcazou 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 45C6 250E 6F00 984E
"A
On Mon, May 31, 2010 at 8:26 AM, 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
On Mon, May 31, 2010 at 5:54 PM, Andrew Pinski wrote:
>
>
> Sent from my iPhone
>
> On May 31, 2010, at 2: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.
>
> Kinda. 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 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
variables, functions,
On Mon, May 31, 2010 at 12:41 PM, Robert Dewar 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 to use
徐持恒 wrote:
On Mon, May 31, 2010 at 6:41 PM, Robert Dewar 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
variables, fu
On Mon, May 31, 2010 at 12:59 PM, Robert Dewar wrote:
> 徐持恒 wrote:
>>
>> On Mon, May 31, 2010 at 6:41 PM, Robert Dewar 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.
>>
>>
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 multip
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
of
On Mon, May 31, 2010 at 3:42 AM, Basile Starynkevitch
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
>> wrote:
>>
>> > At last, there is a very important issue when switching to C++. What is
>> > our "ideal" cla
On Mon, May 31, 2010 at 4:58 PM, Gabriel Dos Reis
wrote:
> On Mon, May 31, 2010 at 3:42 AM, Basile Starynkevitch
> 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
>>> wrote:
>>>
>>> > At last, there is a very
On Mon, May 31, 2010 at 5:03 PM, Richard Guenther
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 structure of the data types mat
On Mon, May 31, 2010 at 7:22 AM, Robert Dewar 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 relevant.
>
>
On Mon, May 31, 2010 at 10:03 AM, Richard Guenther
wrote:
> On Mon, May 31, 2010 at 4:58 PM, Gabriel Dos Reis
> wrote:
>> On Mon, May 31, 2010 at 3:42 AM, Basile Starynkevitch
>> wrote:
>>> On Mon, May 31, 2010 at 01:39:08AM -0500, Gabriel Dos Reis wrote:
On Mon, May 31, 2010 at 12:28 AM, B
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::list),
On Mon, May 31, 2010 at 5:09 PM, Steven Bosscher wrote:
> On Mon, May 31, 2010 at 5:03 PM, Richard Guenther
> 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 rat
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 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 noteworthy C++ compilers woul
On Mon, May 31, 2010 at 5:29 PM, David Fang 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, templates (ot
On Mon, May 31, 2010 at 10:29 AM, David Fang 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, templates (o
On Mon, May 31, 2010 at 11:09, Steven Bosscher wrote:
> On Mon, May 31, 2010 at 5:03 PM, Richard Guenther
> 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 rathe
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
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++.
OK, that's reasonable.
On Mon, May 31, 2010 at 11:54, Richard Guenther
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.
Per
On Mon, May 31, 2010 at 5:53 PM, Diego Novillo wrote:
> On Mon, May 31, 2010 at 11:09, Steven Bosscher wrote:
>> On Mon, May 31, 2010 at 5:03 PM, Richard Guenther
>> wrote:
>>> And we definitely should not do so just because we can. I see
>>> little value in turning our tree upside-down just be
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
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 dur
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
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
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 th
On Mon, May 31, 2010 at 11:22 AM, 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++?
By switch, do you using a C++ compiler to compile everyt
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, then
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
> > str
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 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 written i
On Mon, May 31, 2010 at 11:54 AM, Jakub Jelinek 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 t
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 genera
On Mon, May 31, 2010 at 12:02 PM, Mark Mitchell 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 them in the
> in
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
>http://
Gabriel Dos Reis wrote:
On Mon, May 31, 2010 at 11:54 AM, Jakub Jelinek 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 reviewers will use thei
On Mon, May 31, 2010 at 12:31 PM, Mark Mitchell 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:
>>
>> http://www2
On Mon, May 31, 2010 at 12:33 PM, Vladimir Makarov 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 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.
Well then a lot of
Mark Mitchell 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 and the recent
devir
On Mon, May 31, 2010 at 11:22, Diego Novillo 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 wrote:
> On Mon, May 31, 2010 at 11:22, Diego Novillo 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?
Nevermind! It's a fairly recent threa
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 gues
On Mon, May 31, 2010 at 1:25 PM, Mark Mitchell 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?
>>
>> Ideal
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
> de
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-
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
On Mon, May 31, 2010 at 1:50 PM, Mark Mitchell 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 tree.h. By comp
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 regis
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
> th
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 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 well.
Diego.
On Mon, May 31, 2010 at 2:35 PM, Diego Novillo wrote:
> On Mon, May 31, 2010 at 15:33, Mark Mitchell 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
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
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 subje
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
On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov 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 t
H.J. Lu wrote:
On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov 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 eliminat
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
> 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 not
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,
> 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 reasona
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 time (at least I am going to ask this
for parts which I review even if s
Quoting Gabriel Dos Reis :
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 4.11 .
: AV Rule 98:
:Eve
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 d
On Tue, Jun 1, 2010 at 1:12 AM, Joel Sherrill 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 (vtables, etc.) there
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 f
On Mon, May 31, 2010 at 6:29 PM, Larry Evans 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 simpler and
better code
On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov 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 t
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 fo
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 -- exc
On 05/31/2010 08:17 PM, H.J. Lu wrote:
On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov 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
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 de
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 abo
Basile Starynkevitch 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 member of FSF and did me
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
> http://www.g
Mark Mitchell writes:
> 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
96 matches
Mail list logo
