Hi,
I would like to banish bits and pieces of the compiler from ever
appearing again in places where they do not belong. That would be step
one towards modularization: impose boundaries of some kind. As it is,
we can't really make separate modules of parts of gcc yet, but at
least I would like to
On 05/25/2010 09:55 AM, Steven Bosscher wrote:
1) Group front end objects in Makefile.in under e.g. ALL_HOST_FRONTEND_OBJS
2) Add a new build rule that adds an extra define -DIN_GCC_FRONTEND
3) Conditionally poison symbols in system.h
For the last step, that would be e.g.:
#ifdef IN_GCC_FRONTEND
Hi all,
I compared assembly files of a function compiled by GCC4.3.4 and GCC3.4.4.
The function focuses on array computation and has no branch, or any
loop structure,
The command line is like "-march=mips32r2 -O3", and here is the
instruction statics:
total: 1879 : 1534
On Tue, May 25, 2010 at 9:56 AM, Paolo Bonzini wrote:
> On 05/25/2010 09:55 AM, Steven Bosscher wrote:
>>
>> 1) Group front end objects in Makefile.in under e.g.
>> ALL_HOST_FRONTEND_OBJS
>> 2) Add a new build rule that adds an extra define -DIN_GCC_FRONTEND
>> 3) Conditionally poison symbols in s
On 25/05/2010 09:44, Steven Bosscher wrote:
> +# This lists all host objects for the front ends. Extra defines are passed
> +# to the compiler for these objects.
> +ALL_HOST_FRONTEND_OBJS = $(C_OBJS)
> + $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS))
> +
Missing line-continuation backslash the
On Thu, 13 May 2010, Todd Rinaldo wrote:
> Your FAQ at the below URLS conflicts as to which autoconf should be
> used. one says 2.13 th other says 2.64. 2.65 is currently available.
>
> http://gcc.gnu.org/faq.html#generated_files
>
> http://gcc.gnu.org/install/prerequisites.html
Thanks for your
Steven Bosscher writes:
> But for some reason I get -DIN_GCC_FRONTEND also on some of the gen*
> files, libiberty, and gcov-io.o, like so:
Target-specific variable values are applied to all dependencies, see
(make) Target-specific:
There is one more special feature of target-specific variab
Hello,
I tried to compile the gcc-melt branch from svn, but i get the following error:
make warmelt1
make[4]: Entering directory `/home/wolfgang/gcc-melt/objects/gcc'
date +"/* empty-file-for-melt.c %c */" > empty-file-for-melt.c-tmp
/bin/bash ../../melt-branch/gcc/../move-if-change empty-fi
Hello,
I am using current mainline to compile a testcase which contains a loop.
The target I'm working on supports cmpsi pattern.
While expanding the loop condition I get that do_compare_rtx_and_jump ()
and
do_jump_by_parts_greater_rtx () call each other repeatedly.
The test I'm compiling pass
On Tue, 25 May 2010, Steven Bosscher wrote:
> I am guessing this comes in from the $C_TARGET_OBJS and other language
> target objects. In the Makefile in the build directory I have this
> dependency:
>
> Target specific, C specific object file
> C_TARGET_OBJS=i386-c.o
>
> But unfortunately I ca
On Tue, May 25, 2010 at 2:25 PM, Joseph S. Myers
wrote:
> On Tue, 25 May 2010, Steven Bosscher wrote:
>
>> I am guessing this comes in from the $C_TARGET_OBJS and other language
>> target objects. In the Makefile in the build directory I have this
>> dependency:
>>
>> Target specific, C specific
On Tue, 25 May 2010 16:28:37 +0800, "Amker.Cheng" wrote:
> Hi all,
> I compared assembly files of a function compiled by GCC4.3.4 and
> GCC3.4.4.
> The function focuses on array computation and has no branch, or any
> loop structure,
> The command line is like "-march=mips32r2 -O3", and here i
On 05/25/2010 12:13 PM, Revital1 Eres wrote:
Hello,
I am using current mainline to compile a testcase which contains a loop.
The target I'm working on supports cmpsi pattern.
While expanding the loop condition I get that do_compare_rtx_and_jump ()
and
do_jump_by_parts_greater_rtx () call eac
Hello,
Just did so... :-)
and it indeed solves this.
Thanks,
Revital
From: Paolo Bonzini
To: Revital1 Eres/Haifa/i...@ibmil
Cc: gcc@gcc.gnu.org
Date: 25/05/2010 03:57 PM
Subject:Re: Help with expanding compare
Sent by:Paolo Bonzini
On 05/25/2010 12:13
On 05/25/2010 03:01 PM, Revital1 Eres wrote:
Hello,
Just did so... :-)
and it indeed solves this.
Remember to do the same for cstore.
Most of the time it will remove more code from your target than it adds.
I think that it did so for basically all targets in GCC 4.5, sometimes
cutting up t
On Tue, 2010-05-25 at 12:03 +0200, Wolfgang wrote:
> Hello,
>
> I tried to compile the gcc-melt branch from svn,
A big thanks for testing GCC MELT! What svn revision of the MELT branch
are you testing? Did you configure gcc-melt with --enable-bootstrap?
Can you reproduce the bug inside a clean
On Tue, May 25, 2010 at 11:13 AM, Andreas Schwab wrote:
> Steven Bosscher writes:
>
>> But for some reason I get -DIN_GCC_FRONTEND also on some of the gen*
>> files, libiberty, and gcov-io.o, like so:
>
> Target-specific variable values are applied to all dependencies, see
> (make) Target-specif
Steven Bosscher wrote:
> The first thing I'd like to do now, is banish RTL from the front end.
Certainly a desirable goal!
(I did a bit of this in the C++ front-end a while back, though nothing
as formal or complete as what you are suggesting. There used to be
various places where the front end
* Steven Bosscher wrote on Tue, May 25, 2010 at 04:23:35PM CEST:
> On Tue, May 25, 2010 at 11:13 AM, Andreas Schwab wrote:
> > Target-specific variable values are applied to all dependencies, see
> > (make) Target-specific:
[...]
> That is the problem here. TM_H depends on insn-constants.h, which
>
On Tue, May 25, 2010 at 4:28 PM, Ralf Wildenhues wrote:
> * Steven Bosscher wrote on Tue, May 25, 2010 at 04:23:35PM CEST:
>> On Tue, May 25, 2010 at 11:13 AM, Andreas Schwab wrote:
>> > Target-specific variable values are applied to all dependencies, see
>> > (make) Target-specific:
> [...]
>> Th
On Tue, 2010-05-25 at 16:20 +0200, Basile Starynkevitch wrote:
>
> A dirty workaround might be to replace every -gtoggle occurrence in the
> build tree gcc/Makefile with -g.
Another slightly less dirty workaround, assuming that gcc-4.5 is
available on your machine, is to set the GCCMELT_CC envir
Steven Bosscher writes:
> So I guess this plan of mine is not going to work...
> Other ideas?
Add $(CFLAGS-$(@F)) to the .c.o rule and define CFLAGS-foo for each foo
in $(ALL_HOST_FRONTEND_OBJS). Though the latter is a bit tricky if you
want to do it automatically.
Andreas.
--
Andreas Schwab
On Tue, May 25, 2010 at 16:59, Andreas Schwab wrote:
> Steven Bosscher writes:
>
>> So I guess this plan of mine is not going to work...
>> Other ideas?
>
> Add $(CFLAGS-$(@F)) to the .c.o rule
Actually $@ is fine, since you want cp/tree.o to have different flags
from tree.o.
> and define CFLAG
Original-Nachricht
> Datum: Tue, 25 May 2010 16:20:14 +0200
> Von: Basile Starynkevitch
> An: Wolfgang
> CC: gcc@gcc.gnu.org
> Betreff: Re: Melt-building problem
> On Tue, 2010-05-25 at 12:03 +0200, Wolfgang wrote:
> > Hello,
> >
> > I tried to compile the gcc-melt branch fro
On Tue, 2010-05-25 at 17:09 +0200, Wolfgang wrote:
> Original-Nachricht
> > Datum: Tue, 25 May 2010 16:20:14 +0200
> > Von: Basile Starynkevitch
> > An: Wolfgang
> > CC: gcc@gcc.gnu.org
> > Betreff: Re: Melt-building problem
>
> > On Tue, 2010-05-25 at 12:03 +0200, Wolfgang wro
On Tue, 2010-05-25 at 17:09 +0200, Wolfgang wrote:
> Original-Nachricht
> > Datum: Tue, 25 May 2010 16:20:14 +0200
> > Von: Basile Starynkevitch
> > An: Wolfgang
> > CC: gcc@gcc.gnu.org
> > Betreff: Re: Melt-building problem
>
> > On Tue, 2010-05-25 at 12:03 +0200, Wolfgang wro
Dear All,
I am porting GCC to a 16 bit micro (with 16 bit bytes, thus
BITS_PER_UNIT=16, 16 bit ints become "QI"s etc).
The port compiles is nearly done and simple C programs, but now chokes
on a trivial line such as:
yyy(&array[4], &e, &p);
with this error:
xxx.c: In function ‘yyy’:
x
All,
the toplevel configury of gcc/gdb/binutils is very much out of sync.
If people agree, I would like to freeze commits to the toplevel
configury until they are not diverging anymore.
Also, I would like to make a new policy that from now on patches to the
toplevel cannot be committed by an
* Paolo Bonzini wrote on Tue, May 25, 2010 at 06:06:16PM CEST:
> the toplevel configury of gcc/gdb/binutils is very much out of sync.
> Unfortunately I don't have much time to devote to bringing the trees
> back in shape, and not even to chase down committers of patches
> placed only on one side.
On 05/25/2010 07:09 PM, Ralf Wildenhues wrote:
* Paolo Bonzini wrote on Tue, May 25, 2010 at 06:06:16PM CEST:
the toplevel configury of gcc/gdb/binutils is very much out of sync.
Unfortunately I don't have much time to devote to bringing the trees
back in shape, and not even to chase down com
* Paolo Bonzini wrote on Tue, May 25, 2010 at 07:10:33PM CEST:
> On 05/25/2010 07:09 PM, Ralf Wildenhues wrote:
> >>... the last date when the tree was synchronized ...
> >
> >It looked fairly good 3 months ago[1].
Toplevel and config/ went out of sync with commit 6c8aa2aa884d of the
GCC infradead
* Ralf Wildenhues wrote on Tue, May 25, 2010 at 07:33:53PM CEST:
> * Paolo Bonzini wrote on Tue, May 25, 2010 at 07:10:33PM CEST:
> > As you prefer. I'd rather see a list of commits before giving you
> > green light though. :-)
>
> commit id of infradead mirror, GCC SVN revision number:
One more
On Fri, May 21, 2010 at 10:30 AM, Xinliang David Li wrote:
>
> On Fri, May 21, 2010 at 2:24 AM, Richard Guenther
> wrote:
> > On Thu, May 20, 2010 at 11:21 PM, Xinliang David Li
> > wrote:
> >> On Thu, May 20, 2010 at 2:18 PM, Steven Bosscher
> >> wrote:
> >>> On Thu, May 20, 2010 at 11:14 PM
> Also, I would like to make a new policy that from now on patches to
> the toplevel cannot be committed by anyone who doesn't have write
> access to both gcc and src. Is there any agreement on this?
Our current policy certainly doesn't work, either we come up with
something that will, or abando
> There are no changes in intl, libiberty. The sourceware git mirror
> doesn't seem to carry libdecnumber. Which files in include/ were
> part of libiberty again?
Libiberty is kept in sync because gcc is the master and src is the
copy, so it can be mostly automated. The libiberty sync includes
On 25/05/10 06:06, Ian Lance Taylor wrote:
The official list of maintainers is stored in the gcc source code in
the file MAINTAINERS. Having said that, there is no maintainer listed
for lm32. I assume that it must be, as you suggest, Jon Beniston.
Yeah, I spotted that in SVN about five minute
Snapshot gcc-4.4-20100525 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100525/
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
Philip Pemberton writes:
>> The address is unusual:
>>
>> (subreg:SI (mem/s:DI (plus:SI (reg/v/f:SI 39 [ ctx ])
>> (const_int 64 [0x40])) [0 S8 A64]) 4)
>>
>> Why isn't that simply
>>
>> (mem/s:SI (plus:SI (reg/v/f:SI 39 [ ctx ])
>> (const_int 68 [0x40]))
In a biweekly call with the other GCC Release Managers, I was asked
today on the status of the SC/FSF discussions re. GFDL/GPL issues. In
particular, the question of whether or not we can use "literate
programming" techniques to extract documentation from code and take bits
of what is currently in
In:
http://gcc.gnu.org/ml/gcc/2010-05/msg00347.html
I indicated that I, and the other GCC RMs as available, would
participate in an interactive IRC discussion on May 27th at 9:00 AM Pacific.
As nobody has volunteered to moderate the IRC session, we'll use the
general-purpose GCC developer IRC ch
On Tue, May 25, 2010 at 4:38 PM, DJ Delorie wrote:
>
>> Also, I would like to make a new policy that from now on patches to
>> the toplevel cannot be committed by anyone who doesn't have write
>> access to both gcc and src. Is there any agreement on this?
>
> Our current policy certainly doesn't
On 25/05/2010 17:06, Paolo Bonzini wrote:
> Unfortunately I don't have much time to devote to bringing the trees
> back in shape, and not even to chase down committers of patches placed
> only on one side. Can anybody help with this?
Augh. I forgot to copy over this one:
> PR lto/427
On 25/05/2010 18:33, Ralf Wildenhues wrote:
> bcd70fb06d56d9316d49019f5c0a3109def08d39 158763
> a9ed67d000f285282e61aa9b87cc8d992a8731df 158762
I'm responsible for those two, and I'm copying them across right now; sorry
for forgetting.
cheers,
DaveK
On 26/05/2010 05:58, Dave Korn wrote:
> On 25/05/2010 18:33, Ralf Wildenhues wrote:
>
>> bcd70fb06d56d9316d49019f5c0a3109def08d39 158763
>> a9ed67d000f285282e61aa9b87cc8d992a8731df 158762
>
> I'm responsible for those two, and I'm copying them across right now; sorry
> for forgetting.
An
On 26/05/2010 06:09, Dave Korn wrote:
> On 26/05/2010 05:58, Dave Korn wrote:
>> On 25/05/2010 18:33, Ralf Wildenhues wrote:
>>
>>> bcd70fb06d56d9316d49019f5c0a3109def08d39 158763
>>> a9ed67d000f285282e61aa9b87cc8d992a8731df 158762
>> I'm responsible for those two, and I'm copying them across
On Tue, 2010-05-25 at 17:44 -0700, Mark Mitchell wrote:
> In a biweekly call with the other GCC Release Managers, I was asked
> today on the status of the SC/FSF discussions re. GFDL/GPL issues. In
> particular, the question of whether or not we can use "literate
> programming" techniques to extra
* Dave Korn wrote on Wed, May 26, 2010 at 07:36:26AM CEST:
> >>> bcd70fb06d56d9316d49019f5c0a3109def08d39 158763
> >>> a9ed67d000f285282e61aa9b87cc8d992a8731df 158762
> >> 17281d1ee17f204064cfcbcc82089aefa19e3779 159527
> >> 401f30d69e280e18a9581b819376d18786595d3b 159173
> I've synched
47 matches
Mail list logo
