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-
(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
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
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
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
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
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
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
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
> "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
> 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
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
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
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
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
% ./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
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
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 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
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)?
>
>
> >> 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 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
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
> 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 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
> > >
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 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
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 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
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
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
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
32 matches
Mail list logo
