>> you can define a hard register HARD_FRAME_POINTER_REGNUM. Either
>> way, it should not be a fixed register. In the latter case, have
>> an elimination from FRAME_POINTER_REGNUM to HARD_FRAME_POINTER_REGNUM.
Hi Ian,
Thanks a lot for the useful suggestion.
The "HARD_FRAME_POINTER_REGNUM"
Quoting Kaz Kojima :
but in general the maintenance of
hand crafted assembly codes will be hard.
If you have a fixed feature set and pipeline, and have made sure the code
is correct, no further maintenance should be required - which is more
than can be said of the target port code generator, wh
Дмитрий Дьяченко writes:
> Trunk g++/x86/160655 with -O0 compile test w/o errors, but with
> -O[123] generates undefined symbol
> Need i file a PR?
It certainly looks like a bug. Please do open a bug report. Thanks.
Ian
David Brown writes:
> After doing a bit more reading and thinking, it seems to me that
> -fwhole-program will be used in most cases where LTO is used. You use
> -flto when compiling each source file, then link them with gcc with
> -flto and -fwhole-program. Except in the case of libraries or ot
"Naveen H. S" wrote:
> Software floating point(libgcc) routines were implemented for SH in the
> following links:-
> http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00063.html
> http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00614.html
> http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00624.html
>
> Ther
Dave Korn wrote:
On 13/06/2010 23:22, David Brown wrote:
I agree that banning common symbols is not a complete solution. But
perhaps it may be a partial solution until some more complete solution
is found and implemented?
How about having a warning flag -Wcommon-lto
Incidentally, the orig
On 13 June 2010 23:56, Gerald Pfeifer wrote:
> On Mon, 14 Jun 2010, Gerald Pfeifer wrote:
Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
>> The script places up-to-date .html.gz files in the web infrastructure,
>> alas we do have older .html there -- and our web server is hap
On 14 June 2010 00:23, Jonathan Wakely wrote:
> On 13 June 2010 23:22, Gerald Pfeifer wrote:
>> On Mon, 7 Jun 2010, Jonathan Wakely wrote:
>>> Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
>>
>> I ran this script, and verified that it runs daily, 55 minutes after
>> midnight UTC.
On Mon, 14 Jun 2010, Dave Korn wrote:
> On 13/06/2010 23:20, Joseph S. Myers wrote:
> > On Sun, 13 Jun 2010, Dave Korn wrote:
> >
> >> On 13/06/2010 20:55, Ian Lance Taylor wrote:
> >>> David Brown writes:
> >>>
> If -flto were to activate the -fno-common flag, would that then catch
>
On 13 June 2010 23:22, Gerald Pfeifer wrote:
> On Mon, 7 Jun 2010, Jonathan Wakely wrote:
>> Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
>
> I ran this script, and verified that it runs daily, 55 minutes after
> midnight UTC. Alas, it seems the script does not lead to the desi
On 13/06/2010 23:20, Joseph S. Myers wrote:
> On Sun, 13 Jun 2010, Dave Korn wrote:
>
>> On 13/06/2010 20:55, Ian Lance Taylor wrote:
>>> David Brown writes:
>>>
If -flto were to activate the -fno-common flag, would that then catch
these potential problems with a linker error?
>>> We c
On Mon, 14 Jun 2010, Gerald Pfeifer wrote:
>>> Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
> The script places up-to-date .html.gz files in the web infrastructure,
> alas we do have older .html there -- and our web server is happy to
> serve those over the compressed ones.
>
>
On 13/06/2010 23:22, David Brown wrote:
> I agree that banning common symbols is not a complete solution. But
> perhaps it may be a partial solution until some more complete solution
> is found and implemented?
>
> How about having a warning flag -Wcommon-lto
> Incidentally, the original poste
Snapshot gcc-4.3-20100613 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100613/
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
On Mon, 14 Jun 2010, Gerald Pfeifer wrote:
>> Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
> I ran this script, and verified that it runs daily, 55 minutes after
> midnight UTC. Alas, it seems the script does not lead to the desired
> result -- the libstdc++ onlinedocs/ pages a
Dave Korn wrote:
On 13/06/2010 20:55, Ian Lance Taylor wrote:
David Brown writes:
If -flto were to activate the -fno-common flag, would that then catch
these potential problems with a linker error?
We could perhaps do that for C/C++ code, but Fortran relies on common
symbols.
Well we shoul
On Mon, 7 Jun 2010, Jonathan Wakely wrote:
> Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
I ran this script, and verified that it runs daily, 55 minutes after
midnight UTC. Alas, it seems the script does not lead to the desired
result -- the libstdc++ onlinedocs/ pages appear
On Sun, 13 Jun 2010, Dave Korn wrote:
> On 13/06/2010 20:55, Ian Lance Taylor wrote:
> > David Brown writes:
> >
> >> If -flto were to activate the -fno-common flag, would that then catch
> >> these potential problems with a linker error?
> >
> > We could perhaps do that for C/C++ code, but Fo
On 13/06/2010 20:57, Ian Lance Taylor wrote:
> Ilya K writes:
>
>> My main aim is to build platform-dependent optimization based on the
>> minimizing of hamming distance between the instructions.
>
> Take a look at http://code.google.com/p/mao/ .
Or in binutils, LD's relaxation infrastructure
On 13/06/2010 20:55, Ian Lance Taylor wrote:
> David Brown writes:
>
>> If -flto were to activate the -fno-common flag, would that then catch
>> these potential problems with a linker error?
>
> We could perhaps do that for C/C++ code, but Fortran relies on common
> symbols.
Well we shouldn't
On Sun, 2010-06-13 at 18:29 +0400, Ilya K wrote:
> Hi all.
> (I have never used these maillists before. Sorry if something wrong here.)
>
> I am newbie in gcc and I need some help.
>
> I am performing some research work in theme of code optimization.
> Now I have to write my own optimization pass
On Sat, Jun 12, 2010 at 8:15 AM, H.J. Lu wrote:
> On Fri, Jun 11, 2010 at 3:42 PM, Quentin Neill
> wrote:
>> On Thu, Jun 10, 2010 at 5:23 PM, H.J. Lu wrote:
>>> [snip]
>>> x86 assembler isn't an optimizing assembler. -mtune only does
>>> instruction selection. What you are proposing sounds like
Ilya K writes:
> My main aim is to build platform-dependent optimization based on the
> minimizing of hamming distance between the instructions.
Take a look at http://code.google.com/p/mao/ .
Ian
David Brown writes:
> If -flto were to activate the -fno-common flag, would that then catch
> these potential problems with a linker error?
We could perhaps do that for C/C++ code, but Fortran relies on common
symbols.
Ian
Trunk g++/x86/160655 with -O0 compile test w/o errors, but with
-O[123] generates undefined symbol
--> cat 2010_06_13.cpp
namespace FOO {
template
class A
{
public:
A(char *pMemMgr = 0);
void Enum();
virtual void OnProv() = 0;
virtual ~A() { }
};
typedef A B;
template
inline A::
On Jun 13, 2010, at 7:35 AM, Joern Rennecke wrote:
> An even if you have a suitable text for the assembler, to link the compiler
> with the assembler requires to merge to two complex build systems, and
> resolve symbol name clash issues.
Not trying to be inflammatory, but if you guys are really se
On Sun, Jun 13, 2010 at 7:38 PM, Dave Korn wrote:
...
> What exact use would it be to you having the opcode bytes known during an
> optimisation pass? There may be a better/easier way to do whatever it is
> you're trying to do.
>
> cheers,
> DaveK
>
My main aim is to build platform-depe
Andi Kleen writes:
> [...]
> Yes but you can't easily pass data back, like accurate instruction lengths.
Wouldn't it be too late by then? Or are you imagining having the
compiler pass trial data to the assembler to create a feedback loop?
- FChE
On 13/06/2010 16:01, Ilya K wrote:
> And who is generating the binary file from the asm file? Does gcc call
> the external program? What the name of this program? Or the sources I
> need can be found inside the gcc directory?
Gcc calls out to the assembler that it detects (or is instructed to u
-- Forwarded Message --
Subject: gcc-4.5.0 Success Story with Freecell Solver
Date: Sunday 13 Jun 2010, 17:21:00
From: Shlomi Fish
To: Freecell Solving Discussions
Executive summary: I have built installed gcc-4.5.0 and after Freecell Solver
ran faster, after I compiled it
On Sun, Jun 13, 2010 at 6:38 PM, Richard Guenther
wrote:
> On Sun, Jun 13, 2010 at 4:29 PM, Ilya K wrote:
>> Hi all.
>> (I have never used these maillists before. Sorry if something wrong here.)
>>
>> I am newbie in gcc and I need some help.
>>
>> I am performing some research work in theme of co
On Sun, Jun 13, 2010 at 4:29 PM, Ilya K wrote:
> Hi all.
> (I have never used these maillists before. Sorry if something wrong here.)
>
> I am newbie in gcc and I need some help.
>
> I am performing some research work in theme of code optimization.
> Now I have to write my own optimization pass fo
Quoting Andi Kleen :
On Sun, Jun 13, 2010 at 07:14:03AM -0400, Joern Rennecke wrote:
Quoting Andi Kleen :
I admit I haven't looked into gas code, but naively it can't
be all that difficult to e.g. run gas as a thread and
pass the text input through some shared memory buffer?
If you are gener
Hi all.
(I have never used these maillists before. Sorry if something wrong here.)
I am newbie in gcc and I need some help.
I am performing some research work in theme of code optimization.
Now I have to write my own optimization pass for gcc. And in this pass
I need to get the instruction codes
On Sun, Jun 13, 2010 at 07:14:03AM -0400, Joern Rennecke wrote:
> Quoting Andi Kleen :
>> I admit I haven't looked into gas code, but naively it can't
>> be all that difficult to e.g. run gas as a thread and
>> pass the text input through some shared memory buffer?
>
> If you are generating text an
On Mon, 7 Jun 2010, Tobias Burnus wrote:
>> It has been reported via the FSF that 'gfortran.info' is copyrighted by
>> the FSF '1999-2008', although it should be under the form '1999, 2000,
>> [other years], 2008'.
> Fixed in Rev. 160390 using the attached patch.
Thanks, Tobias!
Any chance you
On 12/06/2010 16:52, Richard Guenther wrote:
On Sat, Jun 12, 2010 at 3:32 PM, David Brown wrote:
Ian Lance Taylor wrote:
Manuel López-Ibáñez writes:
This also means that linking your program with non-LTO+whole-program
code may lead to miscompilations without any warning, which is really
ba
Quoting Andi Kleen :
I admit I haven't looked into gas code, but naively it can't
be all that difficult to e.g. run gas as a thread and
pass the text input through some shared memory buffer?
If you are generating text anyway, there should be little difference to
the existing -pipe option - at l
> It would help compilation time a little bit, but generating the
> assembly code and running the entire assembler is a fairly small
> percentage of the overall compilation time--e.g., 3%. It's worth
> doing a fair amount of work to speed up compilation by 3%, but linking
> the assembler into gcc
39 matches
Mail list logo
