> How many of such platforms are available and known to work in the FSF
> tree?
Strange question. The answer is all the platforms currently known to
work with Ada (too many to be listed here).
> One alternative is to have an s-auxdec-empty and use that
> on platforms where s-auxdec is known to po
Romain Failliot writes:
> 2005/11/13, Florian Weimer <[EMAIL PROTECTED]>:
> > There is a GCC front end, but it has zero chance of being integrated
> > into FSF GCC at this stage. The run-time library license contains
> > this little gem:
> >
> > * (ii) Any derived versions of t
I've received several requests to remove the '-branch' suffix from the IA64
improvements branch.
Since the branch is brand new, this shouldn't affect too many folks, so I
renamed the branch to 'ia64-improvements' and updated the web page.
On Tuesday 15 November 2005 21:17, Branko Čibej wrote:
> Now that GCC has switched to SVN, and tag and branch names are for all
> practical purposes in different namespaces, you could drop the "-branch"
> suffix from new branch names.
>
Sure. Done.
> (You could also rename old branches, but then
On Wed, 16 Nov 2005, Diego Novillo wrote:
> On Tuesday 15 November 2005 21:17, Branko Äibej wrote:
>
> > Now that GCC has switched to SVN, and tag and branch names are for all
> > practical purposes in different namespaces, you could drop the "-branch"
> > suffix from new branch names.
> >
> Sure
On Wednesday 16 November 2005 08:35, Osku Salerma wrote:
> Not sure what you mean by "have the branches locally" (SVK?), but a
> plain rename of a branch doesn't force new check-outs, people can use
> svn switch to point their working copies at the new branch name.
Same thing. It forces people t
On Nov 16, 2005 02:35 PM, Osku Salerma <[EMAIL PROTECTED]> wrote:
> Not sure what you mean by "have the branches locally" (SVK?), but a
> plain rename of a branch doesn't force new check-outs, people can use
> svn switch to point their working copies at the new branch name.
But some people have th
Date: Wed, 16 Nov 2005 03:20:54 -0500
From: "Doug Graham" <[EMAIL PROTECTED]>
To: "Frank Ch. Eigler" <[EMAIL PROTECTED]>
Subject: Question about mudflap
Hi,
Not sure whether I should report this as a bug or not, because there
might be something going on that I don't understand.
What I'm wonderin
Hi -
> What I'm wondering is whether or not mudflap should instrument accesses
> to globals that it doesn't know the size of. In the following code:
> [...]
> printf("%d\n", global[3]);
> [...] Mudflap does not emit any __mf_check calls.
It is probably kicking in an optimization that says t
On 11/16/05, Frank Ch. Eigler <[EMAIL PROTECTED]> wrote:
> Hi -
>
> > What I'm wondering is whether or not mudflap should instrument accesses
> > to globals that it doesn't know the size of. In the following code:
> > [...]
> > printf("%d\n", global[3]);
> > [...] Mudflap does not emit any __
We're going to commit to autovect-branch vectorization support for
non-unit-stride accesses.
We'd like to suggest a few new tree-codes/optabs in order to express the
extraction and merging of elements from/to vectors.
Here are the suggested tree-codes/optabs; an example on how they are going
t
Arnaud Charlet wrote:
How many of such platforms are available and known to work in the FSF
tree?
Strange question. The answer is all the platforms currently known to
work with Ada (too many to be listed here).
One alternative is to have an s-auxdec-empty and use that
on platforms where s-a
On Wed, Nov 16, 2005 at 08:48:43AM -0500, Frank Ch. Eigler wrote:
> Hi -
>
> > What I'm wondering is whether or not mudflap should instrument accesses
> > to globals that it doesn't know the size of. In the following code:
> > [...]
> > printf("%d\n", global[3]);
> > [...] Mudflap does not e
"Balaji V. Iyer" <[EMAIL PROTECTED]> writes:
> I have a question about finding register names from the instruction.
> I am porting GCC for a propriatery architecture and the thing is that,
> I want to group instructions whose destination registers are between
> 0-15 into one cluster and 16-31
On Wednesday 16 November 2005 14:35, Dorit Naishlos wrote:
> We're going to commit to autovect-branch vectorization support for
> non-unit-stride accesses.
> We'd like to suggest a few new tree-codes/optabs in order to express the
> extraction and merging of elements from/to vectors.
> Background:
Hi,
I'm using gcc-4.0.1 on both a UltraSparc3 and UltraSparc3cu systems. When
I compile code on the UltraSparc3 system using -mcpu=ultrasparc3 and run
the file command on the executable I get
hello: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
Required, UltraSPARC1 Extensions Re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.1.0 20051112 (experimental)
Platform: x86_64-unknown-linux-gnu
configure flags:
- --prefix=/SCRATCH/gcc-build/Linux/x86_64-unknown-linux-gnu/install
- --with-gnu-as
- --with-as=/SCRATCH/gcc-build/Linux/x86_64-unknown-linux-gnu/insta
On 11/16/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm using gcc-4.0.1 on both a UltraSparc3 and UltraSparc3cu systems. When
> I compile code on the UltraSparc3 system using -mcpu=ultrasparc3 and run
> the file command on the executable I get
>
> hello: ELF 32-bit MSB exe
> Hi,
>
> I'm using gcc-4.0.1 on both a UltraSparc3 and UltraSparc3cu systems.
When
> I compile code on the UltraSparc3 system using -mcpu=ultrasparc3 and run
> the file command on the executable I get
>
> hello: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
> Required, UltraSPARC1
> First, this question is more suited to gcc-help mailinglist. Second, the
> switch you want to use is -march=ultrasparc3 which changes the used
> instruction-set. -mcpu only tunes for ultrasparc3 without using
> instructions that are not available for the default cpu used.
No, you're thinking in
> I'm using gcc-4.0.1 on both a UltraSparc3 and UltraSparc3cu systems. When
> I compile code on the UltraSparc3 system using -mcpu=ultrasparc3 and run
> the file command on the executable I get
>
> hello: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
> Required, UltraSPARC1 Extensi
A while back I asked whether gcc provided a cross-reference utility and the
answer was "NO" so I
prototyped my own cross-referencing program using gcc and tcl/tk. I'd like to
get some feedback--for
example, usability of the program relative to other cross-referencing
programs--so I have
cross-re
On Tue, 2005-11-15 at 13:31 -0800, Joe Buck wrote:
> On Tue, Nov 15, 2005 at 02:15:44PM -0700, Jeffrey A Law wrote:
> >
> > So, is it just me or does execute/930529-1.c invoke undefined or
> > implementation defined behavior due to its reliance upon overflow
> > behavior for signed types?
> >
>
On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
> I meant exactly this, gcc supports -fno-stack-protector (although gcc
> defaults to no-ssp), so -fno-stack-protector-all should be there too
Why? What option would it perform?
r~
On Wed, Nov 09, 2005 at 07:19:45PM +0100, mathieu lacage wrote:
> Since the cvs version of gas supports extensions for the dwarf2
> basic_block location information, I thought I could try to add support
> to gcc for this feature.
I had been working on this, but got distracted. I hope to get
bac
On Wed, 16 Nov 2005, Richard Henderson wrote:
> On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
> > I meant exactly this, gcc supports -fno-stack-protector (although gcc
> > defaults to no-ssp), so -fno-stack-protector-all should be there too
>
> Why? What option would it per
On Sat, Nov 12, 2005 at 09:57:10PM +0100, Gabriel Dos Reis wrote:
> | http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01463.html
>
> That simply means GCC got it wrong.
The world is not all C++, Gaby.
r~
On Sun, Nov 13, 2005 at 02:26:31PM -0700, Jeffrey A Law wrote:
> On Sun, 2005-11-13 at 22:20 +0100, Steven Bosscher wrote:
> > On Sunday 13 November 2005 22:02, Jeffrey A Law wrote:
> > > No great insights on how to make dbr_schedule CFG aware -- just
> > > remember that a filled delay slot can rep
Richard Henderson <[EMAIL PROTECTED]> writes:
| On Sat, Nov 12, 2005 at 09:57:10PM +0100, Gabriel Dos Reis wrote:
| > | http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01463.html
| >
| > That simply means GCC got it wrong.
|
| The world is not all C++, Gaby.
But that wasn't the point.
-- Gaby
On Wed, Nov 16, 2005 at 08:40:11PM +0100, Peter S. Mazinger wrote:
> On Wed, 16 Nov 2005, Richard Henderson wrote:
>
> > On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
> > > I meant exactly this, gcc supports -fno-stack-protector (although gcc
> > > defaults to no-ssp), so -fn
On Wed, Nov 16, 2005 at 09:15:33PM +0100, Gabriel Dos Reis wrote:
> Richard Henderson <[EMAIL PROTECTED]> writes:
>
> | On Sat, Nov 12, 2005 at 09:57:10PM +0100, Gabriel Dos Reis wrote:
> | > | http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01463.html
> | >
> | > That simply means GCC got it wrong.
On Wednesday 16 November 2005 15:35, Dorit Naishlos wrote:
> We'd like to suggest a few new tree-codes/optabs in order to express the
> extraction and merging of elements from/to vectors.
Watch out for tree code starvation:
$ ~/devel/gomp-branch/gcc> grep ^DEFTREECODE *.def | wc
181 908
As of this morning, Ada no longer compiles for *-rtems.
I think this change broke it.
2005-11-14 Thomas Quinot <[EMAIL PROTECTED]>
* socket.c (__gnat_get_h_errno): New function to retrieve h_errno, the
hosts database last error code.
RTEMS has networking functions but they are not availa
On Wed, 16 Nov 2005, Richard Henderson wrote:
> On Wed, Nov 16, 2005 at 08:40:11PM +0100, Peter S. Mazinger wrote:
> > On Wed, 16 Nov 2005, Richard Henderson wrote:
> >
> > > On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
> > > > I meant exactly this, gcc supports -fno-stack-p
On Wed, Nov 16, 2005 at 10:02:23PM +0100, Peter S. Mazinger wrote:
> On Wed, 16 Nov 2005, Richard Henderson wrote:
>
> > On Wed, Nov 16, 2005 at 08:40:11PM +0100, Peter S. Mazinger wrote:
> > > On Wed, 16 Nov 2005, Richard Henderson wrote:
> > >
> > > > On Tue, Nov 15, 2005 at 09:01:21PM +0100, P
On Wed, 16 Nov 2005, Richard Henderson wrote:
> On Wed, Nov 16, 2005 at 10:02:23PM +0100, Peter S. Mazinger wrote:
> > On Wed, 16 Nov 2005, Richard Henderson wrote:
> >
> > > On Wed, Nov 16, 2005 at 08:40:11PM +0100, Peter S. Mazinger wrote:
> > > > On Wed, 16 Nov 2005, Richard Henderson wrote:
>
On Wed, 16 Nov 2005, Osku Salerma wrote:
> Not sure what you mean by "have the branches locally" (SVK?), but a
> plain rename of a branch doesn't force new check-outs, people can use
> svn switch to point their working copies at the new branch name.
As far as I can experienced, svn switch does hav
Is this valid C or C++? I am getting a syntax error when
compiled as C++ but not C.
int f()
{
int x, y, ;
}
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 3580
>
>
> Is this valid C or C++? I am getting a syntax error when
> compiled as C++ but not C.
>
> int f()
> {
> int x, y, ;
> }
I am getting a syntax error with the C front-end but not with the
C++ front-end. This is definitely a bug as this is invalid C++ also.
This is a regression from at lea
On Wed, Nov 16, 2005 at 10:32:45PM +0100, Peter S. Mazinger wrote:
> what happens w/ -fstack-protector-all -fstack-protector (in this order) ?
> do we have (2) or (1)
We have 1.
> so now it does
> -fstack-protector #define __SSP__ 1 ; #undef __SSP_ALL__
> -fstack-protector-all #define __SSP_ALL_
Andrew Pinski wrote:
Is this valid C or C++? I am getting a syntax error when
compiled as C++ but not C.
int f()
{
int x, y, ;
}
I am getting a syntax error with the C front-end but not with the
C++ front-end. This is definitely a bug as this is invalid C++ also.
This is a regression from
On Sun, 2005-11-13 at 17:55 +0100, Laurent GUERBY wrote:
> There are other PR filed for ACATS code but with other flags than -O2,
> or on platforms with lots of failures (hppa, ia64).
After the latest commit, ia64-linux is now in the same shape Ada wise
than x86 & x86_64:
x86 & x86_64 & ia64
2233
On Wed, Nov 16, 2005 at 04:38:29PM -0500, Andrew Pinski wrote:
> >
> >
> > Is this valid C or C++? I am getting a syntax error when
> > compiled as C++ but not C.
> >
> > int f()
> > {
> > int x, y, ;
> > }
>
> I am getting a syntax error with the C front-end but not with the
> C++ front-end.
The GCC community has talked about link-time optimization for some time.
In addition to results with other compilers, Geoff Keating's work on
inter-module optimization has demonstrated the potential for improved
code-generation from applying optimizations across translation units.
Some of us (Dan
>
> The GCC community has talked about link-time optimization for some time.
> In addition to results with other compilers, Geoff Keating's work on
> inter-module optimization has demonstrated the potential for improved
> code-generation from applying optimizations across translation units.
>
> O
> > > 4. An entirely new basic block on its own.
> >
> > When can option 4 happen??
> IIRC it occurs when there was only 1 insn in either the target
> or fall-thru block.When it gets sucked into the delay
> slot of a branch, then it is effectively its own basic
> block.
When the fall-throug
> Some of us (Dan Berlin, David Edelsohn, Steve Ellcey, Shin-Ming Liu,
> Tony Linthicum, Mike Meissner, Kenny Zadeck, and myself) have developed
> a high-level proposal for doing link-time optimization in GCC. At this
> point, this is just a design sketch. We look forward to jointly
> developing
On Wed, 2005-11-16 at 12:06 -0800, Richard Henderson wrote:
> On Sun, Nov 13, 2005 at 02:26:31PM -0700, Jeffrey A Law wrote:
> > On Sun, 2005-11-13 at 22:20 +0100, Steven Bosscher wrote:
> > > On Sunday 13 November 2005 22:02, Jeffrey A Law wrote:
> > > > No great insights on how to make dbr_schedu
>
> The GCC community has talked about link-time optimization for some time.
> In addition to results with other compilers, Geoff Keating's work on
> inter-module optimization has demonstrated the potential for improved
> code-generation from applying optimizations across translation units.
I don
>
> The GCC community has talked about link-time optimization for some time.
> In addition to results with other compilers, Geoff Keating's work on
> inter-module optimization has demonstrated the potential for improved
> code-generation from applying optimizations across translation units.
One t
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Thoughts?
Thanks for woking on this. Any specific reason why using the LLVM bytecode
wasn't taken into account? It is proven to be stable, high-level enough to
perform any kind of needed optimization, and already features interpreters,
JITters and whatn
On Thu, 2005-11-17 at 01:26 +0100, Giovanni Bajo wrote:
> Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
> > Thoughts?
>
>
> Thanks for woking on this. Any specific reason why using the LLVM bytecode
> wasn't taken into account?
It was.
A large number of alternatives were explored, including CIL,
On 11/16/05, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> On Wednesday 16 November 2005 15:35, Dorit Naishlos wrote:
> > We'd like to suggest a few new tree-codes/optabs in order to express the
> > extraction and merging of elements from/to vectors.
>
> Watch out for tree code starvation:
>
> $ ~/d
Hi Anton,
On Tue, 18 Oct 2005, Anton Titov wrote:
> I've set up a new gcc mirror in Sofia, Bulgaria
>
> ftp://mirrors.host.bg/gnu/ftp/gnu/gcc/
> http://mirrors.host.bg/gnu/ftp/gnu/gcc/
as far as I can see this is a mirror of ftp.gnu.org, not gcc.gnu.org?
Note that on our mirror lists we only ma
> "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes:
Andrew> One thing not mentioned here is how are you going to repesent
Andrew> different eh personality functions between languages, because
Andrew> currently we cannot even do different ones in the same
Andrew> compiling at all.
I think
Daniel Berlin Wrote:
> > It [LLVM] is proven to be stable, high-level enough to
> > perform any kind of needed optimization,
> This is not true, unfortunately. That's why it is called "low
level virtual machine".
> It doesn't have things we'd like to do high level optimizations
on, like
> d
On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote:
> http://gcc.gnu.org/projects/lto/lto.pdf
In Requirement 4, you say that the function F from input files a.o and
b.o should still be named F in the output file. Why is this requirement
more than simply having the debug information r
Richard Henderson wrote:
In general, I'm going to just collect comments in a folder for a while,
and then try to reply once the dust has settled a bit. I'm interested
in seeing where things go, and my primary interest is in getting *some*
consensus, independent of a particular one.
But, I'll try
On Wed, Nov 16, 2005 at 05:27:58PM -0800, Mark Mitchell wrote:
> > In Requirement 4, you say that the function F from input files a.o and
> > b.o should still be named F in the output file. Why is this requirement
> > more than simply having the debug information reflect that both names
> > were o
Mark Mitchell <[EMAIL PROTECTED]> writes:
| The GCC community has talked about link-time optimization for some time.
| In addition to results with other compilers, Geoff Keating's work on
| inter-module optimization has demonstrated the potential for improved
| code-generation from applying optimi
Some more comments (this time section by section and a little more thought out):
2.1:
Requirement 1: a good question is how does ICC or even XLC
do this without doing anything special? Or do they keep around
an "on-the-side" database.
(Requirements 2-4 assume Requirement 1)
Requirement 5: is pe
The document is on the web here:
http://gcc.gnu.org/projects/lto/lto.pdf
The LaTeX sources are in htdocs/projects/lto/*.tex.
Thoughts?
It may be worth mentioning that this type of optimization
applies mainly to one given type of output: a non-symbolic
a.out. When the output it a shared libr
> Our understanding was that the debugger actually uses the symbol table,
> in addition to the debugging information, in some cases. (This must be
> true when not running with -g, but I thought it was true in other cases
> as well.) It might be true for other tools, too.
I can't offhand recall i
Mark Mitchell <[EMAIL PROTECTED]> writes:
> http://gcc.gnu.org/projects/lto/lto.pdf
Section 2.2.1 (Variables and Functions) mentions C++ inline functions.
It should also mention gcc's C language "extern inline" functions.
The same section should consider common symbols. These appear as
uninit
On Wed, 16 Nov 2005, Richard Henderson wrote:
> On Wed, Nov 16, 2005 at 10:32:45PM +0100, Peter S. Mazinger wrote:
> > what happens w/ -fstack-protector-all -fstack-protector (in this order) ?
> > do we have (2) or (1)
>
> We have 1.
>
> > so now it does
> > -fstack-protector #define __SSP__ 1
65 matches
Mail list logo
