On Sat, 2005-11-05 at 01:07 +, Joseph S. Myers wrote:
> On Fri, 4 Nov 2005, Daniel Berlin wrote:
>
> >
> >
> > On Fri, 4 Nov 2005, Kelley Cook wrote:
> >
> > > Snapshots haven't been created since 10/29.
> >
> > I updated the one gccadmin uses yesterday.
> > look in /home/gccadmin/scripts
On Fri, 4 Nov 2005, Daniel Berlin wrote:
>
>
> On Fri, 4 Nov 2005, Kelley Cook wrote:
>
> > Snapshots haven't been created since 10/29.
>
> I updated the one gccadmin uses yesterday.
> look in /home/gccadmin/scripts
I haven't seen the changes on gcc-patches yet.
--
Joseph S. Myers
On Fri, 4 Nov 2005, Kelley Cook wrote:
Snapshots haven't been created since 10/29.
I updated the one gccadmin uses yesterday.
look in /home/gccadmin/scripts
Looks like the version of gcc_release running on gcc.gnu.org is still the old
CVS based one.
gcc_release: Tagging sources as gcc
Snapshots haven't been created since 10/29.
Looks like the version of gcc_release running on gcc.gnu.org is still
the old CVS based one.
> gcc_release: Tagging sources as gcc-ss-4_0-20051103
> cvs [export aborted]: no such tag gcc-ss-4_0-20051103
> cvs [rtag aborted]: could not open lock file
Hi,
It works if the unwind library is HP's libunwind (aka system libunwind) but
doesn't if the unwind library is the bundled one (config/ia64/unwind-ia64.c).
That's with a 3.4.5pre-based compiler on SLES 9, but the problem is very
likely present on all branches.
The bottom line is that the CFM
Andi Kleen wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
I must say I am a bit surprised that gcc never takes advantage
of the fact that inc and dec do not destroy the carry flag, this
is quite significant for some loops.
A lot of this old wisdom is no longer true.
inc and dec are to be g
I must say I am a bit surprised that gcc never takes advantage
of the fact that inc and dec do not destroy the carry flag, this
is quite significant for some loops.
And which is extremely bad on Pentium II and newer.
Paolo, who made the first paid computer work on Realia COBOL
Robert Dewar <[EMAIL PROTECTED]> writes:
>
> I must say I am a bit surprised that gcc never takes advantage
> of the fact that inc and dec do not destroy the carry flag, this
> is quite significant for some loops.
A lot of this old wisdom is no longer true.
inc and dec are to be generally avoide
On 2005-11-04 19:26:14 +0200, Janne Blomqvist wrote:
> Would it be possible to replace gmp with mpfr entirely?
MPFR is based on GMP. It mainly uses the MPN and MPZ layers.
However the MPF layer isn't used at all. So, you still need
GMP somewhere anyway.
--
Vincent Lefèvre <[EMAIL PROTECTED]> - W
Quoting Janne Blomqvist <[EMAIL PROTECTED]>:
> Would it be possible to replace gmp with mpfr entirely? Or do we use
> gmp functionality that isn't found in mpfr?
We use mpz_* for our integer handling, so that's not an option, unfortunately.
- Tobi
On 2005-11-04 16:21:29 +0100, François-Xavier Coudert wrote:
> > The newest version of mpfr will build a shared library.
> > In fact, we should move to using the newest version,
> > but I think some/many people would object to having two
> > external library dependencies.
>
> What advantages have
My question: does GCC-generated code ever actually depend on this aspect
of the x86 architecture - i.e., on instructions that architecturally
change some but not all condition codes _not_ changing those bits that
they're not supposed to change?
No.
An interesting anecdote from decades ago. W
On Fri, Nov 04, 2005 at 09:22:11AM -0800, Steve Kargl wrote:
> On Fri, Nov 04, 2005 at 04:21:29PM +0100, Fran?ois-Xavier Coudert wrote:
> > > The newest version of mpfr will build a shared library.
> > > In fact, we should move to using the newest version,
> > > but I think some/many people would o
On Fri, Nov 04, 2005 at 04:21:29PM +0100, Fran?ois-Xavier Coudert wrote:
> > The newest version of mpfr will build a shared library.
> > In fact, we should move to using the newest version,
> > but I think some/many people would object to having two
> > external library dependencies.
>
> What adva
"Joel Sherrill <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]> writes:
> mips64-rtems4.7, mips-rtems4.7, and powerpc-rtems4.7 all die in Ada at
> the same spot.
>
> ../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg a-calend.adb -o
> a-calend.o
> +===GNAT BUG DETECTED
On Friday 04 November 2005 11:34, Richard Guenther wrote:
> * tree-flow.h (ref_contains_indirect_ref): Rename to
> array_ref_contains_indirect_ref.
> * tree-flow-inline.h (ref_contains_indirect_ref): Likewise.
> (array_ref_contains_indirect_ref): Make comment match the code
I added an include of to gcc/ada/raise.c and now the
arm-rtems4.7 target compiles Ada enough to get to the same GNAT bug box
as powerpc, mips, and mips64 do. So whatever I tripped appears to
be a cross-CPU Ada issue.
Long term, where should the include of stdarg.h be for raise.c?
I just add
Thanks to Paolo Bonzini's patch, I can get much further and now have
more to report. :)
The Good
h8300-rtems4.7 - C, C++ build OK (Ada not tried)
i386-rtems4.7 - C, C++, Ada build OK
m68k-rtems4.7 - C, C++, Ada build OK
sh-rtems4.7 - C, C++ build OK (Ada not tried)
sparc-rtems4.7 - C
Daniel Berlin wrote:
[cc list trimmed because it's just one of those silly friday afternoon things]
> On Fri, 2005-11-04 at 16:23 +, Dave Korn wrote:
>> Daniel Berlin wrote:
>>
>>> The use in tree-ssa-loop-niter.c is really trying to skip out on
>>> inferring loop bounds from pointer to stru
On Fri, 4 Nov 2005, Diego Novillo wrote:
> On Friday 04 November 2005 10:07, Richard Kenner wrote:
> > #if defined ENABLE_CHECKING
> > gcc_assert (handled_component_p (ref))
> > #endif
> >
> > If the comment says it has to be an ARRAY_REF, why not just check for
> > that?
>
>
On Fri, 2005-11-04 at 16:23 +, Dave Korn wrote:
> Daniel Berlin wrote:
>
> > The use in tree-ssa-loop-niter.c is really trying to skip out on
> > inferring loop bounds from pointer to structure accesses in the case of
> > things like:
> >
> >
> > struct a
> > {
> > char foo[1];
> > };
> >
Daniel Berlin wrote:
> The use in tree-ssa-loop-niter.c is really trying to skip out on
> inferring loop bounds from pointer to structure accesses in the case of
> things like:
>
>
> struct a
> {
> char foo[1];
> };
>
>
> struct a *b = malloc (sizeof (struct a) + 100);
> b->foo = "I like can
Daniel Berlin wrote:
Uh, but a diff against the pristine copy is the same as a diff against
mainline at that point, since your only differences come from merging
the mainline.
No, the pristine copy is the pristine copy of the branch. I want to diff
my working copy of the branch against t
On Fri, 2005-11-04 at 10:17 -0500, Diego Novillo wrote:
> On Friday 04 November 2005 10:07, Richard Kenner wrote:
> > #if defined ENABLE_CHECKING
> > gcc_assert (handled_component_p (ref))
> > #endif
> >
> > If the comment says it has to be an ARRAY_REF, why not just check for
>
On Fri, 2005-11-04 at 15:05 +, Joern RENNECKE wrote:
> Daniel Berlin wrote:
>
> >
> >
> >I did
> >
> >svn co svn+ssh://gcc.gnu.org/svn/gcc/branches/sh-elf-4_1-branch
> >cd sh-elf-4_1-branch
> >svn merge -r106276:106279 svn+ssh://gcc.gnu.org/svn/gcc/trunk .
> >(rev 106276:106279 contains the
On 11/4/05, Alex Tzanov <[EMAIL PROTECTED]> wrote:
> Dear developers,
>
>
> I have recently upgraded my PC to Suse Linux 10 (from 9.3). The
> distribution
> comes with gcc 4.0.2. The problem that arrised after the upgrade is that
> I
> cannot compile f77 codes anymore. More precisely when I try to
Dear developers,
I have recently upgraded my PC to Suse Linux 10 (from 9.3). The
distribution
comes with gcc 4.0.2. The problem that arrised after the upgrade is that
I
cannot compile f77 codes anymore. More precisely when I try to compile a
Fortran file (*.f) I am getting the error:
"gcc: inst
> The newest version of mpfr will build a shared library.
> In fact, we should move to using the newest version,
> but I think some/many people would object to having two
> external library dependencies.
What advantages have the newest version? And (sorry for the obvious
question) why isn't it kep
On Friday 04 November 2005 10:07, Richard Kenner wrote:
> #if defined ENABLE_CHECKING
> gcc_assert (handled_component_p (ref))
> #endif
>
> If the comment says it has to be an ARRAY_REF, why not just check for
> that?
The comment is out of sync with the code. It's used in code that
On Fri, 4 Nov 2005, Diego Novillo wrote:
> On Friday 04 November 2005 09:45, Richard Guenther wrote:
> > On Fri, 4 Nov 2005, Diego Novillo wrote:
> > > On Friday 04 November 2005 08:34, Richard Guenther wrote:
> > > > * tree-flow-inline.h (ref_contains_indirect_ref): Deal
> > > > w
Richard Kenner wrote:
> #if defined ENABLE_CHECKING
> gcc_assert (handled_component_p (ref))
> #endif
>
> If the comment says it has to be an ARRAY_REF, why not just check for
> that?
Given that we're supposed to be passing in an ARRAY_REF and we don't want it
to return true if
On Fri, Nov 04, 2005 at 01:32:06PM +0100, Fran?ois-Xavier Coudert wrote:
> >> Here is a patch to fix PR libfortran/21547: when building with
> >> --with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
> >> $(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
> >> correctly when using the
Daniel Berlin wrote:
I did
svn co svn+ssh://gcc.gnu.org/svn/gcc/branches/sh-elf-4_1-branch
cd sh-elf-4_1-branch
svn merge -r106276:106279 svn+ssh://gcc.gnu.org/svn/gcc/trunk .
(rev 106276:106279 contains the change that will remove .cvsignore)
[EMAIL PROTECTED]:/mnt/gccstuff/sh-elf-4_1-bran
#if defined ENABLE_CHECKING
gcc_assert (handled_component_p (ref))
#endif
If the comment says it has to be an ARRAY_REF, why not just check for that?
On Friday 04 November 2005 09:45, Richard Guenther wrote:
> On Fri, 4 Nov 2005, Diego Novillo wrote:
> > On Friday 04 November 2005 08:34, Richard Guenther wrote:
> > > * tree-flow-inline.h (ref_contains_indirect_ref): Deal
> > > with INDIRECT_REF not in handled_component_p.
> >
> > If you hand
On Fri, 2005-11-04 at 15:45 +0100, Richard Guenther wrote:
> On Fri, 4 Nov 2005, Diego Novillo wrote:
>
> > On Friday 04 November 2005 08:34, Richard Guenther wrote:
> >
> > > * tree-flow-inline.h (ref_contains_indirect_ref): Deal
> > > with INDIRECT_REF not in handled_component_p.
> > >
> >
On Fri, 4 Nov 2005, Diego Novillo wrote:
> On Friday 04 November 2005 08:34, Richard Guenther wrote:
>
> > * tree-flow-inline.h (ref_contains_indirect_ref): Deal
> > with INDIRECT_REF not in handled_component_p.
> >
> If you handle INDIRECT_REF directly, then you are seemingly changing th
On Fri, 4 Nov 2005, Richard Kenner wrote:
> The following patch "fixes" this by imitating ref_contains_array_ref
> semantics. Bootstrapped on x86_64-unknonw-linux-gnu, regtest in
> progress, ok for mainline if it succeeds?
>
> Wouldn't this be simpler:
>
> static inline bool
> ref_
If you handle INDIRECT_REF directly, then you are seemingly changing the
semantics of the predicate. The predicate says that it's expecting an
ARRAY_REF as input.
The way it's documented, the input *must* be an ARRAY_REF. If that's
not what's meant, the comment should be changed.
On Friday 04 November 2005 08:34, Richard Guenther wrote:
> * tree-flow-inline.h (ref_contains_indirect_ref): Deal
> with INDIRECT_REF not in handled_component_p.
>
If you handle INDIRECT_REF directly, then you are seemingly changing the
semantics of the predicate. The predicate says
The following patch "fixes" this by imitating ref_contains_array_ref
semantics. Bootstrapped on x86_64-unknonw-linux-gnu, regtest in
progress, ok for mainline if it succeeds?
Wouldn't this be simpler:
static inline bool
ref_contains_indirect_ref (tree ref)
{
while (handled_compon
On Fri, 4 Nov 2005, Richard Guenther wrote:
> Hi!
>
> it seems that
>
> static inline bool
> ref_contains_indirect_ref (tree ref)
> {
> while (handled_component_p (ref))
> {
> if (TREE_CODE (ref) == INDIRECT_REF)
> return true;
> ref = TREE_OPERAND (ref, 0);
> }
>
On 2005-11-03 18:43:56 -0500, DJ Delorie wrote:
> This is crude, but it lets you use "tag:foo/bar/grill"
> as a repository, and it replaces the "tag:foo" with a matching
> entry in ~/.svnrc like this:
>
> tag foo svn://gcc.gnu.org/svn/gcc/trunk/whatever
>
> So, with a .svnrc like this:
>
> tag t
On 2005-11-03 22:58:17 +0100, Andreas Schwab wrote:
> Joern RENNECKE <[EMAIL PROTECTED]> writes:
>
> > What timezone does the svn server use when I specify time & date with -r?
The date is relative to your local timezone (the one of the client).
The server doesn't use a particular timezone.
> Fr
>> Here is a patch to fix PR libfortran/21547: when building with
>> --with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
>> $(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
>> correctly when using the freshly built gfortran to build libgfortran.
>> The same thing happens for the g
On Fri, Nov 04, 2005 at 10:10:14AM +0100, FranXois-Xavier_Coudert wrote:
> Here is a patch to fix PR libfortran/21547: when building with
> --with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
> $(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
> correctly when using the freshly bui
Hi!
it seems that
static inline bool
ref_contains_indirect_ref (tree ref)
{
while (handled_component_p (ref))
{
if (TREE_CODE (ref) == INDIRECT_REF)
return true;
ref = TREE_OPERAND (ref, 0);
}
return false;
}
always returns false, because handled_component_p (ref)
Hi Richard,
On Wednesday 26 October 2005 00:30, Richard Henderson wrote:
> On Mon, Oct 24, 2005 at 03:39:53PM -0500, Bryan Ford wrote:
> > My question: does GCC-generated code ever actually depend on this aspect
> > of the x86 architecture - i.e., on instructions that architecturally
> > change so
Phil Edwards wrote:
> On Fri, Nov 04, 2005 at 12:58:11AM +0100, Giovanni Bajo wrote:
>> Joern RENNECKE <[EMAIL PROTECTED]> wrote:
>>
>>> P.S.: When I use a diff-cmd with -N, I not only get a diff for the 44
>>> files that are different, but also a header for each of the 752 files
>>> that are iden
Here is a patch to fix PR libfortran/21547: when building with
--with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
$(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
correctly when using the freshly built gfortran to build libgfortran.
The same thing happens for the gfortran testsui
> You can use "make check-target-libgfortran", which is what I thought you
> were using to test.
There's no testsuite for libgfortran (the command you mentionned does
not test anything). The only way I'm aware of to run the gfortran
testsuite is "make check-fortran" inside $builddir/gcc. I think I
51 matches
Mail list logo
