On Wed, Jul 2, 2008 at 2:30 PM, Hendrik Boom <[EMAIL PROTECTED]> wrote:
> On Wed, 25 Jun 2008 20:11:56 -0700, Ian Lance Taylor wrote:
>
>> Ivan Levashew <[EMAIL PROTECTED]> writes:
>>
Your comment makes little sense in context. Nobody could claim that
the existing gengtype code is simple
Snapshot gcc-4.2-20080702 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080702/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Wed, Jul 02, 2008 at 08:55:54PM +0100, Richard Sandiford wrote:
> The size of the header and first 0x1 stubs would be the same.
> I think it would also preserve the resolver interface while removing
> the need for the extra-large .plts. The only incompatibility I can
> see would be that obj
Thanks to everyone for their kind messages. I won't drag this out
for non-MIPS folk by replying publicly to each one.
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> the GOT cleanups in particular look very useful.
Thanks. To be clear: the withdrawal was simply for the patches in this
message.
John Freeman <[EMAIL PROTECTED]> writes:
>> You need to configure with --disable-bootstrap if you want the C++
>> frontend built in "stage1". Also try make all-gcc instead (or just make
>> to also build the runtime).
>>
>
> I think this method is different in ways that will increase the build
> t
Ian Lance Taylor wrote:
John Freeman <[EMAIL PROTECTED]> writes:
This is something I look into periodically, and each time I find a
solution that's slightly better, but not what I want. I've looked at
the wiki (http://gcc.gnu.org/wiki/DebuggingGCC) many times, so no need
to refer me there.
On Wed, 25 Jun 2008 20:11:56 -0700, Ian Lance Taylor wrote:
> Ivan Levashew <[EMAIL PROTECTED]> writes:
>
>>> Your comment makes little sense in context. Nobody could claim that
>>> the existing gengtype code is simple. Not many people understand how
>>> it works at all. In order to support ST
Jaroslav Sýkora wrote:
Hello,
I am working on a research project in which I want to export a whole
syntax/semantic tree of a c++ program from the compiler. My current
solution is to use the -fdump-tree-all option and take the *.t00.tu
files (translation unit dump). I've hacked the gcc/tree-dump.c
John Freeman <[EMAIL PROTECTED]> writes:
> This is something I look into periodically, and each time I find a
> solution that's slightly better, but not what I want. I've looked at
> the wiki (http://gcc.gnu.org/wiki/DebuggingGCC) many times, so no need
> to refer me there. I am trying to debug
On Wed, Jul 2, 2008 at 1:13 PM, Bingfeng Mei <[EMAIL PROTECTED]> wrote:
> Hello,
> I am looking at GCC's loop unrolling and find it quite inefficient
> compared with manually unrolled loop even for very simple loop. The
> followings are a simple loop and its manually unrolled version. I didn't
> ap
Vincent Lefevre:
[ Charset ISO-8859-1 converted... ]
> On 2008-07-01 11:11:42 -0700, Ian Lance Taylor wrote:
> > __GNUC__ is indeed defined by the compiler proper, not by the
> > preprocessor.
>
> What do you mean here?
>
> Even when calling the preprocessor directly, __GNUC__ is defined:
>
> vi
On Wed, Jul 2, 2008 at 5:16 PM, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> On 2008-07-02 10:10:32 -0400, Jack Lloyd wrote:
>> Not really, it just doesn't understand it needs to treat an empty
>> file as C... instead you have to tell it so with -x c
>
> But is there any reason why cpp assumes C as
On 2008-07-02 10:10:32 -0400, Jack Lloyd wrote:
> Not really, it just doesn't understand it needs to treat an empty
> file as C... instead you have to tell it so with -x c
But is there any reason why cpp assumes C as a fallback, but not gcc
(at least with the -E option)? IMHO, this is a bit incons
Howdy,
This is something I look into periodically, and each time I find a
solution that's slightly better, but not what I want. I've looked at
the wiki (http://gcc.gnu.org/wiki/DebuggingGCC) many times, so no need
to refer me there. I am trying to debug the C++ front-end, and I took
the wik
Vincent Lefevre <[EMAIL PROTECTED]> writes:
>> But that in turn does not matter, as if any non-gcc compiler *did* use
>> the gcc preprocessor, it would do so via gcc -E. In gcc, the
>> preprocessor is not a separate program.
>
> But in any case, there's a separate preprocessor: cpp. And perhaps c
Hello all,
I am involved in porting a 16bit target in gcc 4.1.2
The target that i am porting to has a minor flaw. Comparison of signed
variables will go wrong. So i have to use a different approach to do
comparison of signed operands. This obviously takes more cycles and
instructions. But the comp
Vincent Lefevre <[EMAIL PROTECTED]> writes:
> On 2008-07-02 00:12:33 +, Joseph S. Myers wrote:
>> This internal binary no longer exists. Instead, there is a "cpp"
>> binary installed in the user binary directory, which calls the "cc1"
>> binary to do the same preprocessing as it does when comp
On Wed, Jul 02, 2008 at 03:47:49PM +0200, Vincent Lefevre wrote:
> On 2008-07-02 00:12:33 +, Joseph S. Myers wrote:
> > This internal binary no longer exists. Instead, there is a "cpp"
> > binary installed in the user binary directory, which calls the "cc1"
> > binary to do the same preprocessi
On 2008-07-02 00:12:33 +, Joseph S. Myers wrote:
> This internal binary no longer exists. Instead, there is a "cpp"
> binary installed in the user binary directory, which calls the "cc1"
> binary to do the same preprocessing as it does when compiling; that
> is, it has the same effect as "gcc -
On 2008-07-01 11:11:42 -0700, Ian Lance Taylor wrote:
> __GNUC__ is indeed defined by the compiler proper, not by the
> preprocessor.
What do you mean here?
Even when calling the preprocessor directly, __GNUC__ is defined:
vin% gcc -dM -E -xc /dev/null | grep __GNUC__
#define __GNUC__ 4
vin% cpp
The loop unrolling is often a big deal for embedded processors. It makes
10 times of performance difference for our VLIW processor in many loops.
I will look into partial loop unrolling at tree-level. If possible, I
would like to make some contributions to GCC. I just learned my company
(Broadcom)
On Tue, Jul 01, 2008 at 09:43:30PM +0100, Richard Sandiford wrote:
> I suppose I still support the trade-off between the 5-insn MIPS I stubs
> (with extra-long variation for large PLT indices) and the absolute
> .got.plt address I used. And I still think it's shame we're treating
> STO_MIPS_PLT an
On Wed, Jul 2, 2008 at 1:13 PM, Bingfeng Mei <[EMAIL PROTECTED]> wrote:
> Hello,
> I am looking at GCC's loop unrolling and find it quite inefficient
> compared with manually unrolled loop even for very simple loop. The
> followings are a simple loop and its manually unrolled version. I didn't
> ap
Hello,
I am looking at GCC's loop unrolling and find it quite inefficient
compared with manually unrolled loop even for very simple loop. The
followings are a simple loop and its manually unrolled version. I didn't
apply any trick on manually unrolled one as it is exact replications of
original loo
Richard Sandiford wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> > We've shipped our version. Richard's version has presumably also
> > shipped.
>
> Right.
>
> > We did negotiate the ABI changes with MTI; this is not quite
> > as good as doing it in full view, but it was the best we co
Jim Wilson wrote:
> If the Intel compiler correctly implements the GNU C language,
> then it shouldn't matter if the code is being compiled by GCC or ICC.
> Unless maybe you ran into a GCC bug, and want to enable a workaround
> only for GCC.
I think you'd want to conditionalize such a test on the
Richard Sandiford writes:
> However, IMO, your argument about MTI being the central authority
> is a killer one. The purpose of the GNU tools should be to follow
> appropriate standards where applicable (and extend them where it
> seems wise). So from that point of view, I agree that the GNU tool
27 matches
Mail list logo
