Hello
I would like to use -fstack-protector in mips.
But mips stack protector seems not to be supported.
I think that the macro FRAME_GROWS_DOWNWARD should be defined for stack
protector working. And mips does'nt define this macro.
To define this macro, the addresses of local variable slots are
On Tue, 2009-02-03 at 01:59 -0500, Sean Callanan wrote:
> Our plugins do not break when switching compiler binaries. In fact, I
> have had plug-in binaries that perform very simple tasks work fine
> when switching (minor!) compiler releases.
Thinking about this made me realise that the plugi
On Wed, Feb 4, 2009 at 11:05 PM, Zoltán Kócsi wrote:
[cut]
>
> If I compile the above with -O2 or -Os, then if the target is AVR or
> x86_64 then the result is what I expected, func() just loads 3 or 12345
> then returns and that's all. There is no .rodata generated.
>
> However, compiling for th
On Thu, 5 Feb 2009 10:58:40 -0200
Alexandre Pereira Nunes wrote:
> On Wed, Feb 4, 2009 at 11:05 PM, Zoltán Kócsi
> wrote: [cut]
> >
> > If I compile the above with -O2 or -Os, then if the target is AVR or
> > x86_64 then the result is what I expected, func() just loads 3 or
> > 12345 then return
> For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH
> to zero. Inlining at -Os should already only happen if it decreases
> (overall!) code-size. Thus, inlining a function that is called once and
> that does not need to be emitted will always be an overall code-size
> win.
>
> > A side
On Thu, 5 Feb 2009, Paul Brook wrote:
> > For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH
> > to zero. Inlining at -Os should already only happen if it decreases
> > (overall!) code-size. Thus, inlining a function that is called once and
> > that does not need to be emitted will alwa
> > On Thumb-2 we found that the overhead of a function call was often
> > smaller than the cost of lengthening branches in the caller.
> > It turns out that, over a fair selection of applications, programmers
> > tend to write "nice" sized functions. After inlining we have big nasty
> > blocks of
On Thu, Feb 5, 2009 at 3:04 PM, Paul Brook wrote:
>> Hmm, we should be able to model this counting the number of edges
>> bypassing the call, right?
>
> Something like that, yes.
>
> Ideally you'd want to factor in the size of the function, and the current
> length of those edges, at which point y
On Fri, Feb 06, 2009 at 12:30:13AM +1100, Zoltán Kócsi wrote:
> Almost the same:
>
> x86_64: 4.0.2
> AVR:4.0.1
> ARM:4.0.2
>
> So, at least the Intel and the ARM are the same yet the Intel version
> omits the .rodata, the ARM keeps it. I'll check it with the newer
> version next wee
On Thu, Feb 5, 2009 at 5:59 AM, Ben Elliston wrote:
> On Tue, 2009-02-03 at 01:59 -0500, Sean Callanan wrote:
>
>> Our plugins do not break when switching compiler binaries. In fact, I
>> have had plug-in binaries that perform very simple tasks work fine
>> when switching (minor!) compiler releas
Yoriko Komatsuzaki writes:
> Could you tell me why it doesn't work well around FRAME_GROWS_DOWNWARD
> on mips ?
I have a WIP patch for this but was holding back mostly because of stage3/4
and that I was trying to make FRAME_GROWS_DOWNWARD the default and I was
running into performance issues.
Th
On Sun, 2009-02-01 at 22:45 +0100, Laurent GUERBY wrote:
> Thanks for the link!
>
> This confirms that all pch test fail on mipsel, from the first
> to the last log available on your site:
>
> http://people.debian.org/~doko/tmp/gcc-mips/gcc-snapshot_20080523-1_mipsel.bz2
> http://people.debian.or
Dear all,
I'm currently working on removing the constant folding and constant
propagation because, on the architecture I'm working on, it is highly
costly to move a constant into a register if the number is big (we can
say over 16 bits).
Currently, I've been looking into this and it seems that I
On Thu, Feb 05, 2009 at 12:34:14PM -0800, Jean Christophe Beyler wrote:
> I'm currently working on removing the constant folding and constant
> propagation because, on the architecture I'm working on, it is highly
> costly to move a constant into a register if the number is big (we can
> say over 1
On Thu, Feb 05, 2009 at 12:46:01PM -0800, Joe Buck wrote:
> On Thu, Feb 05, 2009 at 12:34:14PM -0800, Jean Christophe Beyler wrote:
> > I'm currently working on removing the constant folding and constant
> > propagation because, on the architecture I'm working on, it is highly
> > costly to move a
True but what I've noticed with GCC 4.3.2 is that with this code:
#include
#include
int main(void)
{
long a = 0xcafecafe;
printf("Final: %lx %lx %lx\n", a, a+5, a+15);
return EXIT_SUCCESS;
}
Whether I compile it with a big number like here or a smaller number,
I'll get something l
Jean Christophe Beyler writes:
> I'm currently working on removing the constant folding and constant
> propagation because, on the architecture I'm working on, it is highly
> costly to move a constant into a register if the number is big (we can
> say over 16 bits).
>
> Currently, I've been looki
Snapshot gcc-4.3-20090205 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090205/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Le-Chun Wu wrote:
Hi Sean,
It's great that you updated the wiki page with the latest and more
detailed API design.
We (at Google) also started to look at the GCC plugin support a couple
of weeks ago. We had a quick prototype implemented based on the
original APIs that Taras put together in the
Attached please find the patch of our initial prototype of GCC plugin
support based on the APIs described in the (old) wiki page. I also
attached a sample plugin program (dumb-example.c) that shows how a
plugin uses the APIs.
Sean and Taras (and others),
Diego will be creating a branch for the pl
20 matches
Mail list logo
