> 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
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
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
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
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)
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
>> 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 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
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 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);
> }
>
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 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
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 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_
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, 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 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
#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?
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
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
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, 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
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
> 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
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
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
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 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
>
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
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
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];
> > };
> >
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?
>
>
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
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
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
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
"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 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
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
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 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
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 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
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
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
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
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
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
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
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 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
51 matches
Mail list logo
