Paul Schlie wrote:
the target ports are in gcc/config/...
Sure, I mean which target should I be looking at?
Ned.
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or
With today's mainline I get
stage1/xgcc -Bstage1/
-B/export/users/lucier/local/gcc-mainline/sparc-sun-solaris2.9/bin/ -c
-g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Werror -fno-common
On Thu, 3 Mar 2005 07:33:06 -0500, Bradley Lucier
<[EMAIL PROTECTED]> wrote:
> With today's mainline I get
>
> stage1/xgcc -Bstage1/
> -B/export/users/lucier/local/gcc-mainline/sparc-sun-solaris2.9/bin/ -c
> -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -pe
On Wed, Mar 02, 2005 at 04:36:26PM -0500, Jesus Christ wrote:
> Hello,
> My name is Caleb Statser and I have recently checked out the book "C++
> For Dummies", fourth edition. It is supposed to come with a CD that
> contains all of the source code from the book along with a copy of
> "GNU C++", b
Original Message
>From: Jonathan Wakely
>Sent: 03 March 2005 13:00
> On Wed, Mar 02, 2005 at 04:36:26PM -0500, Jesus Christ wrote:
>
>> Hello,
>> My name is Caleb Statser and I have recently checked out the book "C++
>> For Dummies"
>> I would
>> greatly appreciate it if you would send m
On Thu, 3 Mar 2005 13:37:07 +0100, Christian Joensson
<[EMAIL PROTECTED]> wrote:
> On Thu, 3 Mar 2005 07:33:06 -0500, Bradley Lucier
> <[EMAIL PROTECTED]> wrote:
> > With today's mainline I get
> >
> > stage1/xgcc -Bstage1/
> > -B/export/users/lucier/local/gcc-mainline/sparc-sun-solaris2.9/bin/ -c
Paul Schlie wrote:
If the program's address space pointer is more accurately implemented
as a 16-bit pointer combined with an 8-bit segment address; wonder if
it may be worth your while to take a look at how the old segmented x86
GCC targets treat segmented addresses?
>>>
>
On Wed, 2005-03-02 at 14:55 -0800, Janis Johnson wrote:
> On Wed, Mar 02, 2005 at 11:41:13AM -0700, Jeffrey A Law wrote:
> > On Tue, 2005-03-01 at 14:09 -0500, Diego Novillo wrote:
> > > Janis Johnson wrote:
> > >
> > > > I also find it annoying that the dump files aren't cleaned up. Should
> > >
> also on 4.0 branch, LAST_UPDATED: Thu Mar 3 12:00:26 UTC 2005
Sure? The suspected patch is not present on that branch.
--
Eric Botcazou
On 2005-03-02, Thomas Gill <[EMAIL PROTECTED]> wrote:
> Paul Schlie wrote:
>
>> With the arguable exception of function pointers (which need not be literal
>> address) all pointers are presumed to point to data, not code; therefore
>> may be simplest to define pointers as being 16-bits, and call fu
On Mar 3, 2005, at 12:36 PM, Eric Botcazou wrote:
also on 4.0 branch, LAST_UPDATED: Thu Mar 3 12:00:26 UTC 2005
Sure? The suspected patch is not present on that branch.
Was this fixed with my/Roger's patch which went in this morning (EST)?
Thanks,
Andrew Pinski
> >> also on 4.0 branch, LAST_UPDATED: Thu Mar 3 12:00:26 UTC 2005
> >
> > Sure? The suspected patch is not present on that branch.
>
> Was this fixed with my/Roger's patch which went in this morning (EST)?
I'm not convinced this has ever failed on the 4.0 branch, and I don't see any
patch from
On Thu, 3 Mar 2005 23:35:28 +0100, Eric Botcazou
<[EMAIL PROTECTED]> wrote:
> > >> also on 4.0 branch, LAST_UPDATED: Thu Mar 3 12:00:26 UTC 2005
> > >
> > > Sure? The suspected patch is not present on that branch.
> >
> > Was this fixed with my/Roger's patch which went in this morning (EST)?
>
>
On Mar 3, 2005, at 5:35 PM, Eric Botcazou wrote:
Was this fixed with my/Roger's patch which went in this morning (EST)?
I'm not convinced this has ever failed on the 4.0 branch, and I don't
see any
patch from you or Roger there, so I presume you're confusing with
mainline.
I had meant for the mai
I'm new to the gcc community. I've been asked to modify gcc to allow it
to inject various kinds of instrumentation during compilation. My current
plan is to capture the tree being generated by the front end, augment it,
and pass it on to the back end. It seems like a reasonable approach but I
ca
On Mar 3, 2005, at 6:12 PM, [EMAIL PROTECTED] wrote:
I'm new to the gcc community. I've been asked to modify gcc to allow
it
to inject various kinds of instrumentation during compilation. My
current
plan is to capture the tree being generated by the front end, augment
it,
and pass it on to the
% ./config.guess
powerpc-ibm-aix5.1.0.0
% ./gcc -v
Reading specs from
/air1/users/stever/gcc/gccinst/lib/gcc/powerpc-ibm-aix5.1.0.0/3.4.3/specs
Configured with: /air1/users/stever/gcc/gcc-3.4.3/configure
--prefix=/air1/users/stever/gcc/gccinst --enable-threads=aix
--enable-languages=c,c++ --dis
Am Mittwoch, 02.03.05 um 03:52 Uhr schrieb Mike Stump:
On Feb 28, 2005, at 3:41 AM, Lars Sonchocky-Helldorf wrote:
I'd like to know what the 'official' position regarding ObjC++ is now.
Anybody willing to clear up?
Sure, why not... Either, someone will submit a clean, safe patch and
it will be r
Mike Stump wrote:
If such a patch
were submitted, it would have to go into mainline first anyway, if it
proves safe there and people want to propose a version of it for 4.0.x,
then I think the RM would have to reevaluate it on its merits and risks
and the timing. I don't see the need for the R
Zdenek Dvorak <[EMAIL PROTECTED]>:
> Hello,
>
> > Giv optimizations are just features which not
> > implemented yet in the new loop unroller, so I
think
> > put it in bugzilla is not appropriate.
>
> it most definitely is appropriate. This is a
performance
> regression. Even if it would not be
On Mar 3, 2005, at 5:11 PM, Lars Sonchocky-Helldorf wrote:
Sure, why not... Either, someone will submit a clean, safe patch
and it will be reviewed and OKed and it will be checked in, or
that's won't happen.
can I asume that this is a political change by Apple in this regard?
I tried to describ
> Bernardo Innocenti wrote:
>> Joseph S. Myers wrote:
>>> On Wed, 2 Mar 2005, Bernardo Innocenti wrote:
>>> To move strings into program memory, there's a macro like this:
>>>
>>> #define PSTR(s) ({ static const char __c[] PROGMEM = (s); &__c[0]; })
>>>
>>> But this wouldn't work because __func__ d
> "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
Joseph> in general tree codes which are not used in GCC CVS have been
Joseph> removed and those specific to a language have been made
Joseph> language-specific and are lowered to GENERIC tree codes (those
Joseph> in tree.def) in gimplifi
On Mar 3, 2005, at 3:13 PM, Andrew Pinski wrote:
Was this fixed with my/Roger's patch which went in this morning (EST)?
No:
stage1/xgcc -Bstage1/
-B/export/users/lucier/local/gcc-mainline/sparc-sun-solaris2.9/bin/ -c
-g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prot
On Mar 3, 2005, at 10:12 PM, Tom Tromey wrote:
Speaking of which -- is there any reason FILE_TYPE is still in
tree.def?
I think this is just an over look from people who have not removed it
yet.
I am really talking about myself but there are other people who have
removed
unused tree codes before
Hi,
These days, I am reorganizing fold. One of my goals is to provide a
function like
fold_ternary (code, type, op0, op1, op2)
without taking a tree that would be obtained by
build3 (code, type, op0, op1, op2)
So we need to eliminate a reference to the original tree, that
ie, the result o
I am making a back-end compiler to use a gcc front-end
I want to translate gcc intermediate representation to our IR
gcc's IR is tree
so i want to view gcc IR
but i can't find view gcc IR option
-fdump-translation-unit-all make a .tu file , Is this gcc's IR?
but .tu file doesn't have date to
Kazu Hirata <[EMAIL PROTECTED]> writes:
> It turns out that the CALL_EXPR case of fold_ternary needs the
> original tree like so. (Notice a reference to t.)
...
> If we want to change fold_builtin to take operands like op0, op1, and
> op2, I would have to change so many things that depend on
> fo
On Thu, 3 Mar 2005, Kazu Hirata wrote:
> If we want to change fold_builtin to take operands like op0, op1, and
> op2, I would have to change so many things that depend on
> fold_builtin. (Note that the subroutines of fold_builtin also depends
> on fold_builtin in a sense that they need the origin
There is no option that does what you want. This is a deliberate,
albeit controversial, design decision which we are not presently
interested in debating.
If you are writing a back end, consider using the existing, well-
understood machinery for porting GCC to a new architecture. If you go
that
(I and likely others would also be grateful for further insight)
As to enable the efficient use of non-Von-Newman memory architectures
typical of many vector/signal processors, and smaller microcontrollers;
it seems imperative that target specific attributes assigned to an object
remain correct th
Given the following,
static char const rcsid[] =
"$Id: f.c,v 5.4 1993/11/09 17:40:15 eggert Exp $";
int main() {}
When compiled with GCC 3.4.3, at -O2, the ident string above will _not_
appear in the executable. This is apparently expected behavior.
However, interestingly,
gcc -fkeep-static-
32 matches
Mail list logo
