I've recently come across a couple of issues trying to compile Firefox
trunk with 4.5 (I have a very simple plugin that I need to run on
mozilla-central). I've posted two bugs here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42139 and here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42171
I''m not
Hi Derrick,
As Yuri pointed out we needed some similar instrumentation
for our function cloning work. It may not be exactly
what you need but could be useful.
By the way, it seems that you are interested to use GCC as a research
platform. In this case, sorry for a small advertisement, but I wou
Snapshot gcc-4.4-20091124 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091124/
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
Hello All,
http://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins mention a plugin
directory which can be queried with
gcc-trunk -print-file-name=plugin
Notice that we are calling that plugin, not plugin-header! In my opinion, this
is significant.
on my system, after installation of gcc
Hi Paolo,
Just saw your email.
Do you mind to send the forms to Yuanjie (huangyuan...@ict.ac.cn)
and Liang (pengli...@ict.ac.cn) so that they could add their GSoC'09
developments
to the mainline with the help of Joern, please?!
I send an offline email to David and Sebastian but if you already
On 11/24/2009 09:12 AM, Andrew Haley wrote:
>>
>> If we're changing gcc anyway, then let's add the option of intercepting
>> the function at the point where the machine state is well-defined by
>> ABI, which is before the function stack frame is set up.
>
> Hmm. On the x86 I suppose we could just
"Kaveh R. Ghazi" writes:
> Agreed. I guess my remaining questions are for AIX and mipsisa64-elf.
>
> Can someone please confirm that mipsisa64-elf is a cross-compile-only target
> and therefore not relevant for host-based MPC portability testing?
Yes, that's right.
I'm sure it's technically po
On Tue, 2009-11-24 at 17:12 +, Andrew Haley wrote:
> H. Peter Anvin wrote:
> > If we're changing gcc anyway, then let's add the option of intercepting
> > the function at the point where the machine state is well-defined by
> > ABI, which is before the function stack frame is set up.
>
> Hmm.
H. Peter Anvin wrote:
> On 11/24/2009 07:46 AM, Andrew Haley wrote:
>>> Yes, a lot. The difference is that -maccumulate-outgoing-args allocates
>>> space for arguments of the callee with most arguments in the prologue, using
>>> subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) et
Ross Ridge wrote:
> Andrew Haley writes:
>> Alright. So, it is possible in theory for gcc to generate code that
>> only uses -maccumulate-outgoing-args when it needs to realign SP.
>> And, therefore, we could have a nice option for the kernel: one with
>> (mostly) good code density and never gener
On 11/23/2009 05:58 PM, yunfeng zhang wrote:
next:
pop %ebx //<< A.
...
movl new_offset(%ebx), %eax //<< B. load global variable foo to eax.
...
.global foo //<< C.
OK!, to ld, offsetof(C - A) is const...
Your premise is wrong right there. C-A is *not* a constant.
Andrew Haley writes:
>Alright. So, it is possible in theory for gcc to generate code that
>only uses -maccumulate-outgoing-args when it needs to realign SP.
>And, therefore, we could have a nice option for the kernel: one with
>(mostly) good code density and never generates the bizarre code
>seque
Hi!
I totally agree with Basille. Actually pretty similar thing was
implemented by Liang Peng (ICT) as GCC GSoC'09 project -
http://ctuning.org/wiki/index.php/CTools:ICI:Projects:GSOC09:Function_cloning_and_program_instrumentation
So, probably you should take a look at the code in the
instrument
On 11/24/2009 07:46 AM, Andrew Haley wrote:
>>
>> Yes, a lot. The difference is that -maccumulate-outgoing-args allocates
>> space for arguments of the callee with most arguments in the prologue, using
>> subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) etc.
>> and the stack poin
Mark Mitchell wrote:
Derrick Coetzee wrote:
1. We have a C/C++ source-to-source translation framework. We could
translate each function call "f(a,b,c)" to something like "({ _asm {
... }; typeof(f(a,b,c)) result = f(a,b,c); _asm { ... }; result; })"
2. We could modify the code generation of gcc
Derrick Coetzee wrote:
> 1. We have a C/C++ source-to-source translation framework. We could
> translate each function call "f(a,b,c)" to something like "({ _asm {
> ... }; typeof(f(a,b,c)) result = f(a,b,c); _asm { ... }; result; })"
> 2. We could modify the code generation of gcc in a private fo
Jakub Jelinek wrote:
> On Tue, Nov 24, 2009 at 03:32:20PM +, Andrew Haley wrote:
>> Jakub Jelinek wrote:
>>> On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> you should compile your code with -maccumulate-outgoing-args, and there's
> no need to use -mtune=generic. Is
On Tue, Nov 24, 2009 at 03:32:20PM +, Andrew Haley wrote:
> Jakub Jelinek wrote:
> > On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> >>> you should compile your code with -maccumulate-outgoing-args, and there's
> >>> no need to use -mtune=generic. Is that right?
> >> Seems t
Jakub Jelinek wrote:
> On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
>>> you should compile your code with -maccumulate-outgoing-args, and there's
>>> no need to use -mtune=generic. Is that right?
>> Seems to work. What other side effects has that ?
>
> Faster code, significant
On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> > you should compile your code with -maccumulate-outgoing-args, and there's
> > no need to use -mtune=generic. Is that right?
>
> Seems to work. What other side effects has that ?
Faster code, significant increase in code size th
> Hi Rafael,
>
> I'm sorry I cannot try the patch until next weekend.
> However, from a first look, it should work but I wonder: if the first
> maybe_unlink_file fails the others are never reached, leaving some
> temporary files in place. Is this ok?
>
Yes, I talked with Diego and he thinks that t
On Tue, 24 Nov 2009, Andrew Haley wrote:
> H.J. Lu wrote:
> > On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley wrote:
> >> H.J. Lu wrote:
> >>> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote:
> Steven Rostedt wrote:
> > Ingo, Thomas and Linus,
> >
> > I know Thomas did a patch
H.J. Lu wrote:
> On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley wrote:
>> H.J. Lu wrote:
>>> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote:
Steven Rostedt wrote:
> Ingo, Thomas and Linus,
>
> I know Thomas did a patch to force the -mtune=generic, but just in case
> gcc
I can see one significant change: the GCC middle-end now no
longer supports base-16 floating point at all. The old i370
port was the only user of this feature, and some time after
the port was removed, the middle-end support was removed as
well in order to simplify floating-point handling code.
A change on November 23 is causing every C++ testcase to fail on AIX
because of _ZNSsD1Ev not being exported. c++filt reports the symbol
corresponds to
std::basic_string, std::allocator
>::~basic_string [in-charge]()
David
Paul Edwards wrote:
> So, given the scope below, can someone please explain what
> 4.4 changes are affecting me and what I need to do to overcome
> them? Note that I have never had to do the machine changes
> myself - in the past I simply waiting for Dave Pitts to do the
> upgrade to the new vers
yunfeng zhang wrote:
> The idea I got is about removing .got section in ELF format totally.
>
> Before we go, let's see the limitation on the idea
> 1) It must be deployed on aligned segment model, such as Linux, which cs.start
> = ds.start.
> 2) Currently, I only know how to do on x86 ELF.
>
> H
27 matches
Mail list logo
