Reference(s):
1. Mail: James E Wilson <[EMAIL PROTECTED]>, "Re: How to get m/c dependent
attributes from RTL (expressions, not a variable)?", 10-Feb-2005.
2. Mail: James E Wilson <[EMAIL PROTECTED]>, "Re: How to get m/c dependent
attributes from RTL (expressions, not a variable)?", 12-Feb-2005.
H
On Thu, 3 Mar 2005, Frank Heckenbach wrote:
> Well, I haven't looked closely at the Ada code. Perhaps it's an
> option for gpc, but I'd imagine it would be a significant initial
> effort at least (converting the current code which works rather
> closely with backend data structures).
It would be
Hi,
On Wed, 2 Mar 2005, Rajkishore Barik wrote:
> Checked out a version of new-regalloc code and patched some of my code. It
> crashes in the bootstrapping
> part where "xgcc" runs some of my code on __dtor* modules. Is there a way
> to avoid this
> bootstrapping? I do not really care about th
Joseph S. Myers wrote:
> On Thu, 3 Mar 2005, Waldek Hebisch wrote:
>
> > 1) With current GPC I can work out a new feature and test it using old
> > backend. Such feature relatively quickly can go out in a development
> > snapshot which is usable by ordinary users (the development snapshot
> > use
Bernd Trog wrote:
Hello,
according to the gnat ref. manual
http://gcc.gnu.org/onlinedocs/gnat_rm/Implementation-Defined-Characteristics.html
Standard.Interger'Size is 32 bit for the compilation target.
I'd like to know if the Ada frontend (not the runtime
sys
On Thu, 3 Mar 2005, Waldek Hebisch wrote:
> 1) With current GPC I can work out a new feature and test it using old
> backend. Such feature relatively quickly can go out in a development
> snapshot which is usable by ordinary users (the development snapshot
> uses old, tested backend which shields
Some random notes.
Mark Mitchell wrote:
> Personally, I'm not necessarily convinced that adding Pascal to
> GCC is a good idea. I like Pascal just fine, but because every new
> language adds to the load on everyone. (In my ideal world, we'd
> have stable enough interfaces that it was easy to main
> On Wed, 2 Mar 2005, Waldek Hebisch wrote:
>
> > > If GPC developers are interested in having GPC integrated in GCC 4.1 and
> > > are willing to have it play by the same rules as the rest of GCC - note
> > > that the Ada maintainers made substantial changes to how they contributed
> > > patches t
Checked out a version of new-regalloc code and patched some of my code. It
crashes in the bootstrapping
part where "xgcc" runs some of my code on __dtor* modules. Is there a way
to avoid this
bootstrapping? I do not really care about these errors.
Snapshot gcc-3.3-20050302 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050302/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.3 CVS branch
with the following options: -rgcc-ss-3_3-20050302
You'll
I'll be offline until March 13th.
Ich werde bis 13. Maerz offline sein.
I will process this and any further messages as soon as possible.
Ich werde diese und etwaige weitere Nachrichten so rasch wie
moeglich bearbeiten.
Gerald Pfeifer
--
Gerald Pfeifer (Jerry) [EMAIL PROTECTED] http:
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
> > > the dump files for failing tests be left, or would it be OK to re
Hello,
according to the gnat ref. manual
http://gcc.gnu.org/onlinedocs/gnat_rm/Implementation-Defined-Characteristics.html
Standard.Interger'Size is 32 bit for the compilation target.
I'd like to know if the Ada frontend (not the runtime
system) depends on t
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++", but alas, the CD was no where to be found, at least not in
the book that I
Øyvind Harboe wrote:
What I'm wondering about is whether it is possible, in the code that
gets invoked in a "define_insn" to generate the actual assembly, to find
out the difference between the SP and the frame address.
You shoul have asked this the first time.
I'll try to be more spe
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__ does not work like
a string literal:
#define TRACEMSG(ms
> >What I'm wondering about is whether it is possible, in the code that
> >gets invoked in a "define_insn" to generate the actual assembly, to find
> >out the difference between the SP and the frame address.
> >
> >
> You shoul have asked this the first time.
I'll try to be more specific next
Hello,
last comparison is here: http://gcc.gnu.org/ml/gcc/2005-01/msg01714.html
First of all, who has been this brave man/woman who fixed ir.cc
regressions? I would like to thank him/her! :-)
Well, the results are excelent and regressions (results worser than 5%)
are only those:
-O1: static.cc
Øyvind Harboe wrote:
Does something along the lines of a "FINAL_ELIMINATION_OFFSET()" exist,
that can be called from code-generation in the back-end?
Sorry, I don't understand what you mean saying "code-generation in the
back-end". As I wrote there is no "FINAL_ELIMINATION_OFFSET" before
Hi,
Does anyone know how to obtain the overall spill cost for the old reg
alloc of GCC (global.c)?
I would like to know the spill cost before reload and after the reload
(assuming reload changes the allocation).
Are there any interface already available?
By spill cost I mean:
for each reg i, i
Andrew Pinski dixit:
>> which seems to work, but I'm really concerned about the manuals
>> warning of the input and output operads being in seperate places.
> static __inline__ void atomic_inc(atomic_t *v)
> {
> __asm__ __volatile__("addql #1,%0" : "+m" (*v));
> }
Hi, I have got the same p
The problem with leaving failed dump files behind is that they can
interfere with a following run of the testsuite (particularly if a pass
is added/subtracted). I would vote strongly that the dump files for
failing tests be removed.
Likewise. I've run into this problem more than
On Tue, 2005-03-01 at 10:25 -0800, Janis Johnson wrote:
> On Mon, Feb 28, 2005 at 10:23:56AM -0700, Jeffrey A Law wrote:
> > On Mon, 2005-02-28 at 17:08 +0100, Richard Guenther wrote:
> > > Hi!
> > >
> > > It seems the current dg infrastructure does not support scanning
> > > tree-dumps dumped via
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
> > the dump files for failing tests be left, or would it be OK to remove
> > all of them?
> >
> Much as I don't use the failing executables
On Mon, Feb 21, 2005 at 09:14:22PM -0800, James E Wilson wrote:
> Jonathan Wakely wrote:
> >$ gcc4x -c bug.c -pedantic -save-temps
> >bug.c: In function 'main':
> >bug.c:1: error: floating constant exceeds range of 'long double'
>
> This is easy enough to explain. Grepping for the message shows
> >Does something along the lines of a "FINAL_ELIMINATION_OFFSET()" exist,
> >that can be called from code-generation in the back-end?
> >
> >
> >
> Sorry, I don't understand what you mean saying "code-generation in the
> back-end". As I wrote there is no "FINAL_ELIMINATION_OFFSET" before
> re
Øyvind Harboe wrote:
On Wed, 2005-03-02 at 10:03 -0500, Vladimir Makarov wrote:
Øyvind Harboe wrote:
Is there an existing technique to figure out the difference between
the frame address and the stack pointer during code generation of
arbitary instructions?
You can get the current
On Wed, 2005-03-02 at 10:03 -0500, Vladimir Makarov wrote:
> Øyvind Harboe wrote:
>
> >Is there an existing technique to figure out the difference between
> >the frame address and the stack pointer during code generation of
> >arbitary instructions?
> >
> >
> You can get the current offset thro
Joseph S. Myers wrote:
> Patches need testing - but presumably GPC patches are already tested (and
> bootstrap isn't required for non-C-front-end changes).
>
> Patches need testcases in the testsuite if possible - but GPC already
> seems to have a thorough testsuite, though I don't know if every
> From: "E. Weddington" <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>> More specifically, there seem to be two predominant motivating reasons
>> why it may be desired to attach a target specified attributes to compiler
>> generated static constant objects:
>>
>> 1 - To enable their identification so
Roger Sayle wrote:
Hopefully everyone should find this satisfactory. Mark, are you
OK with this single source file exception/tweak to the current
plan/rules? I'd expect few, if any, of the development branches
contain any changes to fold, and they're welcome to maintain those
changes locally unti
Helge Bahmann wrote:
On Tue, 1 Mar 2005 Mark Mitchell wrote:
Helge Bahmann wrote:
void (A::*function2)(void) throw()=&A::function2;
(a.*function2)();
however for the call through pointer function2 gcc will always generate an
indirect call, i386 assembly for example looks like:
Yes, it should
On Wednesday 02 March 2005 02:37, Marcin Dalecki wrote:
> After trying to build the fortran compiler I'm convinced that at a cut
> down version of the multi precision libraries it requires should be
> included
> in to the compiler tree. The reasons are as follows:
>
> 1. They should be there for re
Paul Schlie wrote:
More specifically, there seem to be two predominant motivating reasons
why it may be desired to attach a target specified attributes to compiler
generated static constant objects:
1 - To enable their identification so that their compile/link time storage
location/type may be i
I should probably also add that if any of the branches scheduled for
merge prior to 4.1 contain/require changes to "fold", perhaps for
additional transformations they need, I'll be glad to review/approve
those specific changes now, ahead of their branch's planned merge dates
to allow them to synch
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 functions
indirectly through a lookup table constructed at link time
> From: "Joseph S. Myers" <[EMAIL PROTECTED]>
>> - and used following the above referenced ""Attribute Syntax", as
>> either a variable, or function parameter declaration/implementation:
>>
>> int ROM x = 3;
>>
>> int foo (int ROM y)
>>
>> where the parameter's attribute is
Øyvind Harboe wrote:
Is there an existing technique to figure out the difference between
the frame address and the stack pointer during code generation of
arbitary instructions?
You can get the current offset through INITIAL_ELIMINATION_OFFSET. But
this offset is not final until reload pass i
Apparently largely unnoticed by compilation with a C compiler the
tree-mudflap.c and
tree-nomudflap.c files are used both at the same time on my system
(powerpc-apple-darwin7.8.0):
c++ -O2 -fsigned-char -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -fno-common
On Tue, 1 Mar 2005 Mark Mitchell wrote:
> Helge Bahmann wrote:
> > void (A::*function2)(void) throw()=&A::function2;
> > (a.*function2)();
>
> > however for the call through pointer function2 gcc will always generate an
> > indirect call, i386 assembly for example looks like:
>
> Yes, it sh
On Tue, 1 Mar 2005, Paul Schlie wrote:
> - an attribute may be defined, such as:
>
> #define ROM __attribute__("ROM");
>
> - and used following the above referenced ""Attribute Syntax", as
> either a variable, or function parameter declaration/implementation:
>
> int ROM x = 3
On Wed, 2 Mar 2005, Waldek Hebisch wrote:
> > If GPC developers are interested in having GPC integrated in GCC 4.1 and
> > are willing to have it play by the same rules as the rest of GCC - note
> > that the Ada maintainers made substantial changes to how they contributed
> > patches to GCC in ord
Is there an existing technique to figure out the difference between
the frame address and the stack pointer during code generation of
arbitary instructions?
This is kinda related to frame pointer -> stack pointer elimination, but
available during code generation.
I'm not quite sure, but I think
On Wednesday 02 March 2005 03:36, Andrew Pinski wrote:
> I don't know why I replied to this thread but I did. Well I think we
> should have
> no more on this thread unless it is about technical reasons why GPC
> cannot be
> included, or political (FSF/SC decides it is not a good thing).
GCC sour
44 matches
Mail list logo
