To be used conveniently on Panther, the recent stfiwx change in HEAD
requires a later version of cctools than the 528.5 version that's
currently on gcc.gnu.org. So, I've put cctools-576 on gcc.gnu.org.
You can install it by clicking on the link below, or by running these
commands:
ftp ft
> Less to maintain is all I was hoping for. I think the configure
> scripts (both libiberty's and gcc's) could be simplified quite a bit
> if we assumed a C89 compliant runtime library, as could libiberty.h
> and system.h.
Well, gcc can make assumptions libiberty can't, and as far as
libiberty's
On Fri, Mar 25, 2005 at 10:10:17PM -0800, Zack Weinberg wrote:
> DJ Delorie <[EMAIL PROTECTED]> writes:
[ dropping C89 functions ]
> > What would that buy us? I mean, aside from the obvious "less to
> > maintain" reason?
>
> Less to maintain is all I was hoping for. I think the configure
> scrip
DJ Delorie <[EMAIL PROTECTED]> writes:
>> I take it that all libiberty-using projects have taken the plunge,
>> then? You vetoed this conversion awhile back because libiberty had
>> to be done last.
>
> At this point, I think libiberty *is* the last.
I'm glad to hear it. It'll be nice to be com
> I take it that all libiberty-using projects have taken the plunge,
> then? You vetoed this conversion awhile back because libiberty had
> to be done last.
At this point, I think libiberty *is* the last.
> What's your opinion on dropping C89 library routines from libiberty?
What would that bu
DJ Delorie <[EMAIL PROTECTED]> writes:
> I only want to avoid a situation where libiberty is left half
> converted (except short term, of course). The mechanics of the
> process are irrelevent to me.
I take it that all libiberty-using projects have taken the plunge,
then? You vetoed this conver
DJ Delorie <[EMAIL PROTECTED]> writes:
| > Just to make sure I understand. I was thinking of whatever was
| > under $GCC/libiberty (and included). Are you thinking of something
| > more?
|
| No.
OK.
| > A single patch is a huge stuff; I propose to break it into a series
| > of patches. Is th
> Just to make sure I understand. I was thinking of whatever was
> under $GCC/libiberty (and included). Are you thinking of something
> more?
No.
> A single patch is a huge stuff; I propose to break it into a series
> of patches. Is that OK with you?
I only want to avoid a situation where li
DJ Delorie <[EMAIL PROTECTED]> writes:
| > Would there be any objection to patches that convert function
| > definitions in libiberty to use ISO C prototype style, instead of
| > K&R style?
|
| I would be in support of such a patch iff it converts all the
| functions, not just the ones gcc hap
> Would there be any objection to patches that convert function
> definitions in libiberty to use ISO C prototype style, instead of
> K&R style?
I would be in support of such a patch iff it converts all the
functions, not just the ones gcc happens to use.
Paul Schlie <[EMAIL PROTECTED]> writes:
> > 1) Many of the optimizers analyze instructions by first calling
> >single_set and working with the results of that. For example,
> >combine won't work with any insn for which single_set returns NULL.
> >And single_set will normally return NU
On Saturday 26 March 2005 02:22, Canqun Yang wrote:
> * loop.c (PREFETCH_BLOCKS_BEFORE_LOOP_MAX): Defined
> conditionally.
> (scan_loop): Change extra_size from 16 to 128.
> (emit_prefetch_instructions): Don't ignore all prefetches
> within
> loop.
OK, so I know this is n
Hi, all
Currently, GCC just ignores all data prefetches within
loop when the number of prefetches exceeds
SIMULTANEOUS_PREFETCHES. It isn't advisable.
Also, macros defined in ia64.h for data prefetching
are too small.
This patch modified the data prefetch algorithm
defined in loop.c and red
Snapshot gcc-3.4-20050325 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050325/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050325
You'll
> From: Ian Lance Taylor
>> Paul Schlie <[EMAIL PROTECTED]> writes:
>> Thereby enabling something like:
>>
>> (insn xxx [(set (reg: A) (xxx: (reg: B) (reg: C)))
>>(set (reg: CC) (newly-set-reg: A))
>> )
>>
>> (insn branch-equal (set (pc) (if_then_else
>>
Hi,
Would there be any objection to patches that convert function
definitions in libiberty to use ISO C prototype style, instead of
K&R style?
(rationale: they are getting in the way when compiling GCC with a C++
compiler, for example).
-- Gaby
Joe Buck <[EMAIL PROTECTED]> writes:
| On Fri, Mar 25, 2005 at 08:03:55PM +0100, Gabriel Dos Reis wrote:
| > Joe Buck <[EMAIL PROTECTED]> writes:
| > | That wouldn't have saved me in the case described above, as the pathnames
| > | are already set in the executable. A *runtime* way of altering th
On Fri, Mar 25, 2005 at 08:03:55PM +0100, Gabriel Dos Reis wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
> | That wouldn't have saved me in the case described above, as the pathnames
> | are already set in the executable. A *runtime* way of altering the
> | locations of the .gcda files would be ni
Joe Buck <[EMAIL PROTECTED]> writes:
| Mark Mitchell <[EMAIL PROTECTED]> writes:
| > | When we generate data for feedback, we insert the .gcda name into the
| > | object file as an absolute path. As a result, when we try to do
| > | remote testing, we lose, as, in general the remote file system d
"Aaron W. LaFramboise" <[EMAIL PROTECTED]> writes:
> This is due to this code:
>
> #if !HAVE_DECL_GETOPT
> #if defined (__GNU_LIBRARY__) || defined (HAVE_DECL_GETOPT)
> /* Many other libraries have conflicting prototypes for getopt, with
>differences in the consts, in unistd.h. To avoid comp
> I'm a little concerned about the fact that (in theory) DECL_NAME could
> have spaces, or other assembler-unfriendly characters. I'm not sure
> what to do in that circumstance; it's probably impossible to do anything
> better than we do now, without the assembler providing some kind of
> special
Paul Schlie <[EMAIL PROTECTED]> writes:
> Is there any convenient way to reference the newly set register by an
> instruction, as opposed to otherwise needing to redundantly re-specify
> the operation producing it's value again?
>
> Thereby enabling something like:
>
> (insn xxx [(set (reg: A) (
On Mar 25, 2005, at 9:47 AM, Gabriel Dos Reis wrote:
"Timothy J.Wood" <[EMAIL PROTECTED]> writes:
|A compiler option to set the target directory for these files (and
| the coverage ones!) would be great. Possibly even better would be an
| environment variable. If the user wants to compare two
> From: Ian Lance Taylor
>> Paul Schlie <[EMAIL PROTECTED]> writes:
>> Does GCC truley need to identify/treat condition state registers uniquely
>> from any other value produced as a result of a calculation?
>
> No, it doesn't. The change I am proposing removes the unique handling
> of condition
In trying to do "gmake dvi" in the build directory, the
gfortran.texi eventually dies with
Loading texinfo [version 2004-10-31.06]: Basics, pdf, fonts, page headings,
tables, conditionals, indexing, sectioning, toc, environments, defuns, macros,
cross references, insertions, (/usr/local/share/tex
"Timothy J.Wood" <[EMAIL PROTECTED]> writes:
| On Mar 24, 2005, at 11:59 PM, Mark Mitchell wrote:
|
| > When we generate data for feedback, we insert the .gcda name into
| > the object file as an absolute path. As a result, when we try to do
| > remote testing, we lose, as, in general the remote
On Fri, Mar 25, 2005 at 10:45:36PM +1100, Greg Schafer wrote:
> On Fri, Mar 25, 2005 at 12:06:33PM +0100, Eric Botcazou wrote:
>
> > What is wrong exactly? Why should 2 different build processes generate the
> > same executable? Is there a (written) rule about this?
>
> No, there is no written
Mark Mitchell <[EMAIL PROTECTED]> writes:
> | When we generate data for feedback, we insert the .gcda name into the
> | object file as an absolute path. As a result, when we try to do
> | remote testing, we lose, as, in general the remote file system does
> | not have the same file hierarchy as t
Eric Botcazou wrote:
OK. (FWIW, you're not on the CC: list for that PR either.)
Sorry, I only wanted to explain why the patch is still pending. About your
question: am I right in thinking that the real name is the name as written
in the assembly file? If so, that's what is now implemented in
> OK. (FWIW, you're not on the CC: list for that PR either.)
No, but I'm the assignee so... :-)
> > Note that the patch has been approved by Roger for 4.x, so it should
> > already have been checked in, had I not run into technical contingencies
> > lately.
>
> Great; I shan't second-guess then.
On Mar 24, 2005, at 11:59 PM, Mark Mitchell wrote:
When we generate data for feedback, we insert the .gcda name into the
object file as an absolute path. As a result, when we try to do
remote testing, we lose, as, in general the remote file system does
not have the same file hierarchy as the bu
Eric Botcazou wrote:
20263 SPARC64 ASM bug
Eric has a patch; I've asked about possible other ways to fix it.
I've answered, but probably not very constructively as your remark was not
crystal-clear either. :-) Btw, I think you should "Add CC" you when you
comment on specific PRs in order to spe
> zouq writes:
zouq> first i made gcc-4.1-20050320 a cross-compiler for powerpc.
zouq> when i compile the above program, it goes like this:
zouq> testcom.c:34: internal compiler error: in schedule_insns, at
sched-rgn.c:2549
zouq> who can tell me why?
zouq> why can it bring compiler error?
Paul Schlie <[EMAIL PROTECTED]> writes:
> Does GCC truley need to identify/treat condition state registers uniquely
> from any other value produced as a result of a calculation?
No, it doesn't. The change I am proposing removes the unique handling
of condition state registers, and treats them li
On Thu, Mar 24, 2005 at 11:59:55PM -0800, Mark Mitchell wrote:
> When we generate data for feedback, we insert the .gcda name into the
> object file as an absolute path. As a result, when we try to do remote
> testing, we lose, as, in general the remote file system does not have
> the same file
> Ian Lance Taylor writes:
> We would like to eliminate cc0 and the associated machinery from the
> compiler, because it is complicated and not supported on popular or
> modern processors. Here is a plan which I think could accomplish that
> without unreasonable effort.
I pre-apologize if this i
Look at the IP2K port. It's an 8-bit chip with a 16 bit accumulator
and VERY limited
registers and addressing. When I did this port originally, I mostlyh
hid the accumulator
from the register allocator. But I did implement extended precision
arithmetic as a pattern that
optimized use of the a
<[EMAIL PROTECTED]> writes:
> It will generate a lot of redundant moves to/from the accumulator because
> the accumulator is exposed much too late.
>
> Consider the 3AC code:
>
> add i,j,k
> add k,l,m
>
> it will be broken down into:
>
> mov i,a
> add j,a
> mov a,k
> mov k,a
> add l,a
> mov a,
On 22 Mar 2005, Ian Lance Taylor wrote:
> Miles Bader <[EMAIL PROTECTED]> writes:
>
> > I've defined SECONDARY_*_RELOAD_CLASS (and PREFERRED_* to try to help
> > things along), and am now running into more understandable reload
> > problems: "unable to find a register to spill in class" :-/
> >
On Fri, Mar 25, 2005 at 12:06:33PM +0100, Eric Botcazou wrote:
> What is wrong exactly? Why should 2 different build processes generate the
> same executable? Is there a (written) rule about this?
No, there is no written rule. However, some folks (like me) are concerned
with matters of binary
> Umm.. you've missed my point.
Not really if you read correctly. :-) I was saying that the compilers are
not meant to be identical in the general case.
> To reiterate, this is different behaviour from past GCC releases, and it
> appears wrong to me.
What is wrong exactly? Why should 2 differ
On Fri, Mar 25, 2005 at 08:46:12AM +0100, Eric Botcazou wrote:
> Isn't that always the case in general? With a 'make bootstrap' the compiler
> is built by itself whereas with a bare 'make' it is built by the installed
> compiler. So in general the final compilers are not identical.
Umm.. you'
zouq <[EMAIL PROTECTED]> wrote:
> /testcom.c
> int main (void)
> {
> int i,j;
> int u[100][100], v[100][100],
> p[100][100], unew[100][100],
> vnew[100][100],pnew[100][100],
> uold[100][100],vold[100][100],
> pold[100][100],cu[100
On Friday 25 March 2005 01:31, James E Wilson wrote:
> On Thu, 2005-03-24 at 15:52, Steven Bosscher wrote:
> > I'd suggest trying -fmove-loop-invariants, and report a bug about
> > that instead if it does not move those loop invariants. We really
> > should move away from loop.c anyway.
>
> In gen
/testcom.c
int main (void)
{
int i,j;
int u[100][100], v[100][100],
p[100][100], unew[100][100],
vnew[100][100],pnew[100][100],
uold[100][100],vold[100][100],
pold[100][100],cu[100][100],
cv[100][100],z[100][100],h[100
Mark Mitchell <[EMAIL PROTECTED]> writes:
| When we generate data for feedback, we insert the .gcda name into the
| object file as an absolute path. As a result, when we try to do
| remote testing, we lose, as, in general the remote file system does
| not have the same file hierarchy as the build
When we generate data for feedback, we insert the .gcda name into the
object file as an absolute path. As a result, when we try to do remote
testing, we lose, as, in general the remote file system does not have
the same file hierarchy as the build system.
I understand why we generate an asbolu
47 matches
Mail list logo
