Hi,
I am converting my StarCore port of the gcc version 3.2 to the current version
4.1.1.
The following program ( part of the gcc's testsuite )
void bar(int *pc) {
static const void *l[] = {&&lab0, &&end};
foo(0);
goto *l[*pc];
lab0:
foo(0);
pc++;
goto *l[*pc];
end:
return;
}
success
Hello,
[EMAIL PROTECTED] /cygdrive/x
$ cat tmp.c
typedef unsigned size_t;
char *strncpy (char *pDest, const char *pSrc, size_t n)
{
return pDest;
}
[EMAIL PROTECTED] /cygdrive/x
$ powerpc-eabi-gcc -v
Using built-in specs.
Target: powerpc-eabi
Configured with: ../gcc-4.1.1/configure --ta
Sorry please ignore, not enough coffee...
Etienne.
___
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expér
> In general, I am agree with this. I am just opposing to the strong
> words "not allowed". I think it should be decided in each concrete case.
I agree that "not allowed" was a poor choice of words in a project
such as GCC and, although we, as a project, do tend to normally make
decisions one a
Vladimir N. Makarov wrote:
>> Vlad,
>> I think that different people can have different perspectives.
>> You have been working on improving the register allocation for several
>> years, but very little has come of it because the reload
>> infrastructure does not suit itself to being integrated wit
> Regs_ever_live is the poster child of this. In theory regs_ever_live is
> easy, it is just the set of hard registers that are used. In practice
> this is a disaster to keep track of because it was only updated
> occasionally and its values are "randomly" changed by the backends in
> totally und
David Livshin <[EMAIL PROTECTED]> writes:
> x.c: In function bar:
> x.c:13: error: unrecognizable insn:
> (jump_insn 26 25 27 2 (set (pc)
> (reg:SI 52)) -1 (nil)
> (nil))
> x.c:13: internal compiler error: in extract_insn, at recog.c:2084
>
>
> The .md file defines ( mandatory ) "i
Etienne Lorrain <[EMAIL PROTECTED]> writes:
> Is there a magic flag? I want to test the source for null pointer...
This question would be appropriate on the mailing list
[EMAIL PROTECTED], not on [EMAIL PROTECTED] Please take any
followups gcc-help. Thanks.
I don't actually understand the que
Richard Kenner wrote:
>> Regs_ever_live is the poster child of this. In theory regs_ever_live is
>> easy, it is just the set of hard registers that are used. In practice
>> this is a disaster to keep track of because it was only updated
>> occasionally and its values are "randomly" changed by the
--- Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> I don't actually understand the question. gcc is compiling the
> function as you wrote it. What do you want it to do differently?
This has been resolved today by:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30785
I was adding code to test a
Wow, I got so many emails. I'll try to answer them in one email in
order not to repeat.
Mark Mitchell wrote:
I was not trying to suggest that DF is necessarily as sweeping a change
as TREE-SSA. Certainly, it's not a completely change to the
representation.
It is not sweeping change as Tree
> Let us look at major RTL optimizations: combiner, scheduler, RA. Do
> we need a global analysis for building def-use use-def chains? We
> don't need it for combiner (only in bb scope),
Combine would work *far better* if it had some uniform data structure. For
one thing, that means it could
Do you realize how confrontational your emails sound? Have you
considered asking about the technical reasoning and justification instead
of making unfounded assertions? Do you want everyone to refute your
incorrect facts point by point?
David
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Wow, I got so many emails. I'll try to answer them in one email in
Let us look at major RTL optimizations: combiner, scheduler, RA.
...PRE, CPROP,SEE, RTL loop optimizers, if-conversion, ... It is easy
to make your arguments look valid
David Edelsohn wrote:
Do you realize how confrontational your emails sound? Have you
considered asking about the technical reasoning and justification instead
of making unfounded assertions? Do you want everyone to refute your
incorrect facts point by point?
David, I am sorry if yo
Ian Lance Taylor wrote:
David Livshin <[EMAIL PROTECTED]> writes:
x.c: In function bar:
x.c:13: error: unrecognizable insn:
(jump_insn 26 25 27 2 (set (pc)
(reg:SI 52)) -1 (nil)
(nil))
x.c:13: internal compiler error: in extract_insn, at recog.c:2084
The .md file defines ( ma
On Tue, 2007-02-13 at 12:14 -0500, Vladimir Makarov wrote:
> David Edelsohn wrote:
>
> > Do you realize how confrontational your emails sound? Have you
> >considered asking about the technical reasoning and justification instead
> >of making unfounded assertions? Do you want everyone to refu
David Livshin <[EMAIL PROTECTED]> writes:
> >> x.c: In function bar:
> >> x.c:13: error: unrecognizable insn:
> >> (jump_insn 26 25 27 2 (set (pc)
> >> (reg:SI 52)) -1 (nil)
> >> (nil))
> >> x.c:13: internal compiler error: in extract_insn, at recog.c:2084
> >>
> >>
> >> The .md file
what happens with the data previously loaded by a previous pch include file?
I can't figure out why every GTY()-ed global data (extern or static) should
be overwritten at each PCH inclusion, but then maybe I am wrong.
Couple of big limiations of GCC PCH :
- Only one PCH can be loaded during one
> Jeffrey Law writes:
Jeff> I think everyone would be best served if they realized none of this is
Jeff> personal -- it's about technical decisions in an effort to improve GCC.
GCC development is far from perfect. The recent model generally
seems to be effective, although there is pl
Steven Bosscher wrote:
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Wow, I got so many emails. I'll try to answer them in one email in
Let us look at major RTL optimizations: combiner, scheduler, RA.
...PRE, CPROP,SEE, RTL loop optimizers, if-conversion, ... It is easy
to make
> Vladimir Makarov writes:
Vlad> I am just trying to convince that the proposed df infrastructure is not
Vlad> ready and might create serious problems for this release and future
Vlad> development because it is slow. Danny is saying that the beauty of the
Vlad> infrastracture is just in im
I even have own tool for
this NONA http://cocom.sf.net . Although it might be a good research to
make it work on insns from diffrent BBs.
Of course instruction selection is usually done intra-BB. However, some
analyses that combine performs, such as nonzero_bits and
num_sign_bit_copies, ma
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
I am just trying to convince that the proposed df infrastructure is not
ready and might create serious problems for this release and future
development because it is slow. Danny is saying that the beauty of the
infrastracture is just in imp
David Edelsohn wrote:
Vladimir Makarov writes:
Vlad> I am just trying to convince that the proposed df infrastructure is not
Vlad> ready and might create serious problems for this release and future
Vlad> development because it is slow. Danny is saying that the beauty of the
V
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> Why is it unacceptable for it to mature further on mainline like
>Tree-SSA?
>
>
Two releases one after another to avoid. No one real experiment to try
to rewrite an RTL optimization to figure out how def-use chain will work.
Vlad,
Paolo Bonzini wrote:
The problem is that to use the modern approach you need another
description of insns (with one pattern - one machine insn relation)
in tree representation with given cost for the tree. And it is a
huge work to rewrite current machine descriptions even only for this.
Th
> Vladimir Makarov writes:
Vlad> I did investigate the current status of the infrastructure on future
Vlad> mainstream processor Core2 (> 11% slower compiler, worse code and bigger
Vlad> code size). That is the reason why I started this.
You do not believe that this is a concern of
Steven Bosscher wrote:
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> Why is it unacceptable for it to mature further on mainline like
>Tree-SSA?
>
>
Two releases one after another to avoid. No one real experiment to try
to rewrite an RTL optimization to figure out how def-us
David Edelsohn wrote:
Vladimir Makarov writes:
Vlad> I did investigate the current status of the infrastructure on future
Vlad> mainstream processor Core2 (> 11% slower compiler, worse code and bigger
Vlad> code size). That is the reason why I started this.
You do not
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
...
I am only affraid that solution for faster infrastructure
(e.g. another slimmer data representation) might change the interface
considerably. I am not sure that I can convinince in this. But I am
more worried about 4.3 release and I r
Sorry for the long email, i find that i need to provide a whole lot of
history as to why i am doing things the way i am so people understand
what i am trying to ask...
If you want to know why i was doing things read on, otherwise i have
some simple questions at the end since i have discovered that
On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Getting 0.5% and 11.5% slowness
(308sec vs 275sec for compiling SPECINT2000) does not seems reasonable
Just to be sure: Did you build with --disable-checking for both
compilers? I often find myself comparing compilers with checking
enable
On Feb 13, 2007, at 1:34 PM, Brendon Costa wrote:
Sorry for the long email
Complex questions are better long, as that allows for better answers,
which should be more useful to you.
This was based on an idea from Mike in Nov 2006 when i needed to
ensure that the FUNCTION_DECL nodes were no
Thanks for the response.
>> * Is it possible to explicitly free garbage collected memory if i know i
>> will not be needing it any more
>
> Yes, ggc_free.[1]
>
> 1 - Some people think that all the savings you'd get from this aren't
> work the pain of doing it, if you have to track down any over
On Feb 13, 2007, at 3:16 PM, Brendon Costa wrote:
There is no "additional" pain in doing this as I have already
developed my code using manual malloc/free in such a way that i am
reasonably sure there are no leaks, or double free calls or the like.
No, the pain would be a dangling pointer.
Mike Stump wrote:
> On Feb 13, 2007, at 3:16 PM, Brendon Costa wrote:
>> There is no "additional" pain in doing this as I have already
>> developed my code using manual malloc/free in such a way that i am
>> reasonably sure there are no leaks, or double free calls or the like.
>
> No, the pain wou
On Feb 12, 2007, at 10:42 PM, Basile STARYNKEVITCH wrote:
A big thanks for the explanation, which is something I partly
guessed, but which leaves me in a deep trouble :-)
Glad to turn on the flashlight so that you may see the hole. I hope
you know which way to dig now. :-)
I can't figure
On Mon, 12 Feb 2007, Mark Mitchell wrote:
> Given that we're not going to mess about further with DECL_REPLACEABLE_P
> (since the case that Kaveh raised involving PIC compilation of functions
> using exceptions is a non-bug), I don't think we need to do RC3.
>
> The only changes that we've had sin
Should __attribute__ ((gnu_inline)) be treated the same as a gnu89
extern inline definition? Or should the extern part be optional?
That is, should there be a difference between these two definitions?
extern __attribute__ ((gnu_inline)) inline int foo () { return 0; }
__attribute__ ((gnu_inli
Kaveh R. GHAZI wrote:
> What I need to work out is what combinations of target and flags this
> problem occurs under. E.g. is this problem sparc-solaris only or does it
> occur on any target using pic? Or is it some subset of all platforms?
> What about targets that default to pic without any ex
The problem is that to use the modern approach you need another
description of insns (with one pattern - one machine insn relation)
in tree representation with given cost for the tree. And it is a
huge work to rewrite current machine descriptions even only for this.
This is not really necessa
42 matches
Mail list logo
