Re: Patch reviews for 4.1

[Ian Lance Taylor]

Mark Mitchell <[EMAIL PROTECTED]> writes:

> Middle-End
> --
> 23109
> 23948

These are the same patch, and it's too complicated for me.

> 24365

Looks plausible but I don't understand the code well enough.

> 24483

Approved.

> 24589

Approved.

> 23155

Approved.

> 24408

The followup to the patch suggests that it is inappropriate:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01656.html

Ian

Re: svn diff branch woprking copy against mainline?

[Paolo Bonzini]

Branko Čibej wrote:

Joe Buck wrote:


On Wed, Nov 02, 2005 at 06:28:42PM -0500, Daniel Berlin wrote:
 


On Wed, 2005-11-02 at 14:33 -0800, Mike Stump wrote:
   


On Nov 2, 2005, at 2:18 PM, Joern RENNECKE wrote:
 


I tried:
bash-2.05b$ svn diff Makefile.in svn+ssh://[EMAIL PROTECTED]/svn/ 
gcc/trunk/gcc/[EMAIL PROTECTED]


But that gives me an error message:

svn: Target lists to diff may not contain both working copy paths  
and URLs



This works for us:

svn diff --old svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_4_0_1_release/ 
gcc/file.c --new file.c


for example.

svn needs to go on a long command line diet,   


True.
However, it *does* need some way to differentiate between url->url,
url->wc, and wc->url commands, so even if there was an SVNROOT, you'd
still have to specify it  on the command lines :)




It certainly seems that --old and --new are redundant.


I suggest a search in http://svn.haxx.se/dev/.


Also, you could
consider stealing some ideas from Perforce, where the command would be
something like

p4 diff [EMAIL PROTECTED] file.c

and the RCS figures out how to map the label to the repository version.
Basically, the # and @ characters are special; # is used to introduce
a revision number (the global revision number), and a number of things
can follow @, like a label, or a date.
  


This seems to be a common misconception. The important thing to remember 
here is that there is no separate namespace for labels and branches in 
SVN, and that the layout of the repository is arbitrary. IOW, the fact 
that you have branches in /branches is a convention, not something 
imposed by the SVN server.


With the above in mind, your p4 example would translate to something 
like this:


   svn diff [EMAIL PROTECTED]/gcc_4_0_1_release file.c

(not that this would work, for reasons discussed to death in the 
[EMAIL PROTECTED] archives).


Now suppose your file.c is trunk/somdir/file.c. How is Subversion 
supposed to translate from


trunk/somedir/[EMAIL PROTECTED]/gcc_4_0_1_release

to the intuitively correct path in the repo, which is

   branches/gcc_4_0_1_release/somedir/file.c ?

It can't, because it doesn't know that trunk is special.


But it could know that gcc-checkout/ was checked out from trunk, so 
gcc-checkout/gcc was checked out from the gcc subdirectory of trunk.


More formally, you can say that any file in the checkout is made of 
BASE/DIR/filename where BASE is the URL passed to the latest `svn co' or 
`svn switch' command. If filename is BASE/DIR/filename, [EMAIL PROTECTED] 
could be BRANCH/DIR/filename.


I guess this would require adding an attribute to the  
tag of the entries file, a la


> base="svn://gcc.gnu.org/svn/gcc/branches/dataflow-branch" <
   last-author="dberlin"
   kind="dir"
   uuid="138bc75d-0d04-0410-961f-82ee72b054a4"
   repos="svn+ssh://[EMAIL PROTECTED]/svn/gcc"
   prop-time="2005-10-28T21:45:00.00Z"
   revision="106422"/>


Telling the SVN devs to "change the diff syntax like /this/" is a bit 
like telling the GCC devs to "just add this extension to g++". We all 
know what the response to /that/ usually is. :)


Ehm, I guess you're right...

Paolo

toplevel Makefile.tpl hacking

[FX Coudert]

I've been working on PR libfortran/21547: f951 is linked with libgmp, 
but when this library is shared and located in a non-standard path, 
building with ./configure --with-gmp=/foo/bar fails because the correct 
$(RPATH_ENVVAR) is not set when building the libgfortran. The 
conclusions I draw after gazing helplessly at the toplevel Makefile.* 
for hours is:


  - I should add a GMPLBISDIR variable in the configure.in to store the 
paths to the libraries as a colon-separated list of absolute paths

  - the GMPLIBSDIR should be added to the HOST_LIB_PATH
  - then, i don't really know how this should come into HOST_LIB_PATH; 
perhaps by way of HOST_LIB_PATH_gcc


I have attached a patch that implements things that way. The questions I 
now have are:


  - is that the Right Scheme for doing this?
  - with this patch, the libgfortran is built, but the gfortran 
testsuite doesn't run; why isn't $(RPATH_ENVVAR) including HOST_LIB_PATH 
for the testsuite?


Thanks,
FX
Index: Makefile.tpl
===
--- Makefile.tpl	(revision 106019)
+++ Makefile.tpl	(working copy)
@@ -216,6 +216,7 @@
 
 # Where to find GMP
 HOST_GMPLIBS = @gmplibs@
+HOST_GMPLIBSDIR = @gmplibsdir@
 HOST_GMPINC = @gmpinc@
 
 # --
@@ -615,7 +616,7 @@
 
 # Define HOST_LIB_PATH_gcc here, for the sake of TARGET_LIB_PATH, ouch
 @if gcc
-HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc:$$r/$(HOST_SUBDIR)/prev-gcc:
+HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc:$$r/$(HOST_SUBDIR)/prev-gcc:$(HOST_GMPLIBSDIR):
 @endif gcc
 
 [+ FOR host_modules +][+ IF lib_path +]
Index: configure.in
===
--- configure.in	(revision 106019)
+++ configure.in	(working copy)
@@ -1058,6 +1058,7 @@
 # Check for GMP and MPFR
 gmplibs=
 gmpinc=
+gmplibsdir=
 have_gmp=yes
 # Specify a location for mpfr
 # check for this first so it ends up on the link line before gmp.
@@ -1075,6 +1076,7 @@
 if test "x$with_mpfr" != x; then
   gmplibs="-L$with_mpfr/lib $gmplibs"
   gmpinc="-I$with_mpfr/include"
+  gmplibsdir="$with_mpfr/lib"
 fi
 
 # Specify a location for gmp
@@ -1097,6 +1099,11 @@
 if test "x$with_gmp" != x; then
   gmplibs="-L$with_gmp/lib $gmplibs"
   gmpinc="-I$with_gmp/include $gmpinc"
+  if test "x$gmplibsdir" != x; then
+gmplibsdir="$gmplibsdir:$with_gmp/lib"
+  else
+gmplibsdir="$with_gmp/lib"
+  fi
 fi
 
 saved_CFLAGS="$CFLAGS"
@@ -1125,6 +1132,7 @@
 # Flags needed for both GMP and/or MPFR
 AC_SUBST(gmplibs)
 AC_SUBST(gmpinc)
+AC_SUBST(gmplibsdir)
 
 # By default, C is the only stage 1 language.
 stage1_languages=c
Index: libgfortran/Makefile.in
===
--- libgfortran/Makefile.in	(revision 106403)
+++ libgfortran/Makefile.in	(working copy)
@@ -278,6 +278,7 @@
 FC = @FC@
 FCFLAGS = @FCFLAGS@
 FPU_HOST_HEADER = @FPU_HOST_HEADER@
+GMPLIBSDIR = @GMPLIBSDIR@
 INSTALL_DATA = @INSTALL_DATA@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
 INSTALL_SCRIPT = @INSTALL_SCRIPT@
Index: libgfortran/configure.ac
===
--- libgfortran/configure.ac	(revision 106403)
+++ libgfortran/configure.ac	(working copy)
@@ -141,6 +141,8 @@
 AC_PROG_FC(gfortran)
 FCFLAGS="$FCFLAGS -Wall -fno-repack-arrays -fno-underscoring"
 
+AC_ARG_VAR(GMPLIBSDIR,[Directories containing the GMP and MPFR libraries])
+
 # extra LD Flags which are required for targets
 case "${host}" in
   *-darwin*)

RE: Patch reviews for 4.1

[Dave Korn]

Mark Mitchell wrote:
> This rather horrid URL:
> 
>
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=
allwordssubstr&short_desc=4.1&target_milestone=4.0.3&target_milestone=4.1.0&kn
own_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_ty
pe=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gc
chost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gc
cbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=patch&bug
_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bu
g_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&email
type1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=
&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same
+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=


... aka http://tinyurl.com/ckpny

 
> will get you the list of 4.1 PRs with the "patch" keyword set.  

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: toplevel Makefile.tpl hacking

[Paolo Bonzini]

  - I should add a GMPLBISDIR variable in the configure.in to store the 
paths to the libraries as a colon-separated list of absolute paths

  - the GMPLIBSDIR should be added to the HOST_LIB_PATH


Yes.

  - then, i don't really know how this should come into HOST_LIB_PATH; 
perhaps by way of HOST_LIB_PATH_gcc


You can also just put it into HOST_LIB_PATH after the autogen gunk.

HOST_LIB_PATH = [+ FOR host_modules +][+
  IF lib_path +]$(HOST_LIB_PATH_[+module+])[+ ENDIF lib_path +][+
  ENDFOR host_modules +]:$(GMPLIBSDIR)


  - is that the Right Scheme for doing this?


Yes.

  - with this patch, the libgfortran is built, but the gfortran 
testsuite doesn't run; why isn't $(RPATH_ENVVAR) including HOST_LIB_PATH 
for the testsuite?


It should:

BASE_TARGET_EXPORTS = \
...
$(RPATH_ENVVAR)=`echo 
"$(HOST_LIB_PATH)$(TARGET_LIB_PATH)$$$(RPATH_ENVVAR)" | sed 
's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR);


...

NORMAL_TARGET_EXPORTS = \
$(BASE_TARGET_EXPORTS) \
CXX="$(CXX_FOR_TARGET)"; export CXX;

...


check-target-libgfortran:
@$(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
$(NORMAL_TARGET_EXPORTS) \
(cd $(TARGET_SUBDIR)/libgfortran && \
  $(MAKE) $(TARGET_FLAGS_TO_PASS)   check)

Paolo

Re: Patch reviews for 4.1

[Paolo Bonzini]

Middle-End
--

>>
>> [snip approvals]

This only leaves out the two patches for 23948 and 24365, which are both 
showstoppers; plus 24408, whose audit trail says it's rather hard to fix 
it in 4.1.


Paolo

Re: Howto Cross Compile GCC to run on PPC Platform

[Jeff Stevens]

I am using the AMCC 440SP processor.  I went and
bought "Building Embedded Linux Systems" by Karim
Yaghmour.  It seems to be a pretty complete book, and
I have gotten the cross-compiler completely installed,
but it doesn't get into installing a native compiler. 
However, I tried cross compiling gcc by first running
this configure line:

../gcc-3.4.4/configure
--build=`../gcc-3.4.4/config.guess`
--target=powerpc-linux --host=powerpc-linux
--prefix=${PREFIX} --enable-languages=c

and then a make all.  The make went fine, and
completed without any errors.  However, when I ran
'make install' I got the following error:

powerpc-linux-gcc: installation problem, cannot exec
`/opt/recorder/tools/libexec/gcc/powerpc-linux/3.4.4/collect2':
Exec format error
make[2]: *** [nof/libgcc_s_nof.so] Error 1
make[2]: Leaving directory
`/opt/recorder/build-tools/build-native-gcc/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory
`/opt/recorder/build-tools/build-native-gcc/gcc'
make: *** [install-gcc] Error 2

How do I install the native compiler?

Thanks,
   Jeff Stevens

--- Clemens Koller <[EMAIL PROTECTED]> wrote:

> Hello, Jeff!
> 
> >I am trying to compile GCC on an x86 platform
> to
> > run natively on an embedded PPC platform.
> 
> What CPU do you use?
> I am currently working on an mpc8540 natively (from
> harddisk).
> And have a current toolchain up and running.
> I can recommend the latest Linux-From-Scratch
> documentation
> to get an idea of what to do.
> 
> >  I am able
> > to compile gcc as a cross compiler (to run on
> x86),
> > but can't seem to get it to cross compile gcc (to
> run
> > on ppc).  Does anyone know of a good HowTo to do
> this?
> >  I'm currently downloading the source distro of
> ELDK,
> > so if it's already in there I'll find it, but if
> there
> > is one elsewhere online please let me know.
> 
> I've started with the ELDK 3.1 too. And updated it
> step by step to the latest versions.
> 
> Greets,
> 
> Clemens Koller
> ___
> R&D Imaging Devices
> Anagramm GmbH
> Rupert-Mayer-Str. 45/1
> 81379 Muenchen
> Germany
> 
> http://www.anagramm.de
> Phone: +49-89-741518-50
> Fax: +49-89-741518-19
> 





__ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs

Re: Howto Cross Compile GCC to run on PPC Platform

[Kai Ruottu]

Jeff Stevens wrote:


.../gcc-3.4.4/configure
--build=`../gcc-3.4.4/config.guess`
--target=powerpc-linux --host=powerpc-linux
--prefix=${PREFIX} --enable-languages=c

and then a make all.  The make went fine, and
completed without any errors.  However, when I ran
'make install' I got the following error:

powerpc-linux-gcc: installation problem, cannot exec
`/opt/recorder/tools/libexec/gcc/powerpc-linux/3.4.4/collect2':
Exec format error

How do I install the native compiler?


You shouldn't ask how but where !

You cannot install alien binaries into
the native places on your host !  This
is not sane at all...

Ok, one solution is to collect the components
from the produced stuff, pack them into a
'.tar.gz' or something and then ftp or something
the stuff into the native system.

If you really want to install the stuff into your
host, you should know the answer to the "where"
first, and should read from the "GCC Install"
manual the chapter 7, "Final installation" and
see what option to 'make' you should use in order
to get the stuff into your chosen "where"...

Re: Howto Cross Compile GCC to run on PPC Platform

[Jeff Stevens]

I am creating the target tree on my host, so that I
can later transfer it to a USB storage device.  I was
going to manually move everything, but only saw one
binary, xgcc.  Is that all, or aren't there some other
utilities that go along with it?  I just didn't know
exactly what to copy and where to copy it to.  When I
built glibc, those were built for the target system,
but installed to the target directory structure that I
am creating.

The 'make install' command that I ran for glibc was:

make install_root=${TARGET_PREFIX} prefix="" install

where TARGET_PREFIX is the target filesystem tree.  I
used the same make install command for the native gcc
that I compiled.

Thanks,
   Jeff Stevens

--- Kai Ruottu <[EMAIL PROTECTED]> wrote:

> Jeff Stevens wrote:
> 
> > .../gcc-3.4.4/configure
> > --build=`../gcc-3.4.4/config.guess`
> > --target=powerpc-linux --host=powerpc-linux
> > --prefix=${PREFIX} --enable-languages=c
> > 
> > and then a make all.  The make went fine, and
> > completed without any errors.  However, when I ran
> > 'make install' I got the following error:
> > 
> > powerpc-linux-gcc: installation problem, cannot
> exec
> >
>
`/opt/recorder/tools/libexec/gcc/powerpc-linux/3.4.4/collect2':
> > Exec format error
> > 
> > How do I install the native compiler?
> 
> You shouldn't ask how but where !
> 
> You cannot install alien binaries into
> the native places on your host !  This
> is not sane at all...
> 
> Ok, one solution is to collect the components
> from the produced stuff, pack them into a
> '.tar.gz' or something and then ftp or something
> the stuff into the native system.
> 
> If you really want to install the stuff into your
> host, you should know the answer to the "where"
> first, and should read from the "GCC Install"
> manual the chapter 7, "Final installation" and
> see what option to 'make' you should use in order
> to get the stuff into your chosen "where"...
> 




__ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Re: svn diff branch woprking copy against mainline?

[Joern RENNECKE]

Branko Čibej wrote:

 



It certainly seems that --old and --new are redundant.


I suggest a search in http://svn.haxx.se/dev/.


What should we search for?  I tried both of --old and --new, and both 
searches

came up empty.




Also, you could
consider stealing some ideas from Perforce, where the command would be
something like

p4 diff [EMAIL PROTECTED] file.c

and the RCS figures out how to map the label to the repository version.
Basically, the # and @ characters are special; # is used to introduce
a revision number (the global revision number), and a number of things
can follow @, like a label, or a date.
  


This seems to be a common misconception. The important thing to 
remember here is that there is no separate namespace for labels and 
branches in SVN, and that the layout of the repository is arbitrary. 
IOW, the fact that you have branches in /branches is a convention, not 
something imposed by the SVN server.


It's not a misconception, it's a perception of an svn shortcoming.  
There should be a configurable mapping from branch/tag names to branch/tag
locations.  I.e. you tell the svn server once what your conventions are, 
and then you don't have to apply them by hand every time you refer to
a branch or tag.  Without such a mechanism, svn makes a rather poor cvs 
replacement.




With the above in mind, your p4 example would translate to something 
like this:


   svn diff [EMAIL PROTECTED]/gcc_4_0_1_release file.c


This syntax is bad not only because of the need to mention branches/ but 
also because you need to name file.c twice.
And how would you expand it to diff several files against a different 
branch/tag?




(not that this would work, for reasons discussed to death in the 
[EMAIL PROTECTED] archives).


url(s), please.

[translating branch->location]


  It can't, because it doesn't know that trunk is special.


Yes, that's one of the things that we have to tell it in some config 
file.  I think it's ok if we consider
'trunk' aka 'mainline' a branch/tag at the location trunk/ .  I.e. to 
diff a branch working copy
against the current mainline, you could say -rtrunk; to diff it against 
yesterdays mainline,

-rtrunk -Dyesterday or [EMAIL PROTECTED] .

(There is a remaining disadvantage here against cvs because we can't any 
longer use a single
version number to refer to a particular version in a particular 
branch.  However, that only
really applies to single files; for multiple files, in cvs you'd have 
to use dates or symbolic

tags to refer to a particular state of mainline/a branch ).




Now, as of not too long ago we can teach the svn client to expand the 
repository root; your example would become (assuming your working copy 
is on trunk, and assuming % expands to the repos root):


   svn diff --old %/branches/gcc_4_0_1_release/somedir/file.c --new 
file.c


I suppose that's a bit better, although I admit it's not ideal.



However, before coming up with a zillion suggestions about how to make 
the syntax nicer, please do consider the idea that we did put a lot of 
thought into the diff syntax,


Actually, it's not only diff.  Being able to refer to tags/branches by 
name is also important for other operations like log, annotate (aka 
blame), update,

merge...
I get the impression that a lot of work has gone into designing the 
underlying repository, and that is certainly fundamental to having
a powerful version control system, but the usability of the command-line 
interface is still way behind cvs when you want to seriously

work with branches.

and that covering all the uses and edge cases and is not easy. I'll be 
the first to admit that the current syntax sucks, but it works -- as 
opposed to most proposed (and many once implemented, now defunct...) 
forms that usually break down in the most trivial cases.


Telling the SVN devs to "change the diff syntax like /this/" is a bit 
like telling the GCC devs to "just add this extension to g++". We all 
know what the response to /that/ usually is. :)


It's a bit different here because we had something that worked for us 
before - cvs.  The main lure of switching to svn has been the promise of
better performance when doing operations on branches, and keeping 
history across copy / rename operations.  If working on branches turns
out to be actually harder with svn because it has no clue where the 
branches are, we might be better off with cvs after all.


More to the point, if I understood Daniel Berlin correctly, he offered 
to do some work on subversion to make it fit the requirements of the gcc
project.  But before any such work with regards to naming tags/branches 
can be done, there should be a consensus from the gcc developers about
what it is we want, and buy-in from the svn developers that the design 
would be acceptable for svn.


Thus, it is important that we have this discussion about design first.

In general, a repository could have more than one project, and 
branches/tags for one project need to apply to ano

cross newlib builds on svn head

[Joel Sherrill <[EMAIL PROTECTED]>]

Hi,

I have been trying to build sparc-rtems4.7 on the head using newlib's 
head for a few days now.  I have finally narrowed the behavior down.


If I configure for sparc I am configuring for sparc-rtems4.7 with c and 
c++, it builds fine.  The build process uses xgcc for newlib as one 
would expect.  If I add ada to the --enable-languages then newlib fails 
to build because it picks a non-existent compile (sparc-rtems4.7-cc) to 
build with.


Host: Fedora Core 3.  The GCC is the default

gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2)

Procedure:
+ build binutlis 2.16.1 for sparc-rtems4.7
+ co gcc head from svn
+ co newlib head from cvs
+ mv newlib under gcc
+ configure for C/C++ and make
  ../gcc-head-test/configure --target=sparc-rtems4.7 \
--enable-threads=rtems --prefix=/home/joel/gcc-41-test/ \
--with-gnu-as   --with-gnu-ld --with-newlib --verbose \
--with-system-zlib --disable-nls \
--enable-version-specific-runtime-libs --enable-languages=c,c++
  make

Builds completes.

+ configure for C/C++/Ada and make
  ../gcc-head-test/configure --target=sparc-rtems4.7 \
--enable-threads=rtems --prefix=/home/joel/gcc-41-test/ \
--with-gnu-as   --with-gnu-ld --with-newlib --verbose \
--with-system-zlib --disable-nls \
--enable-version-specific-runtime-libs --enable-languages=c,c++,ada
  make

Build fails when newlib attempts to compile with sparc-rtems4.7-cc.

Help is really appreciated.  I wanted to provide some feedback on the 
Ada status.


--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

Re: Howto Cross Compile GCC to run on PPC Platform

[Kai Ruottu]

Jeff Stevens wrote:

I am creating the target tree on my host, so that I
can later transfer it to a USB storage device.  I was
going to manually move everything, but only saw one
binary, xgcc.  Is that all, or aren't there some other
utilities that go along with it?


 The 'cpp', 'cc1*', 'collect2', 'g++',... BUT your stuff
is not a 'normal' native GCC... The '--prefix=/usr' is
the normal setting for that. So probably you must make
distclean, reconfigure and rebuild the GCC for the normal
native system...

> I just didn't know

exactly what to copy and where to copy it to.  When I
built glibc, those were built for the target system,
but installed to the target directory structure that I
am creating.

The 'make install' command that I ran for glibc was:

make install_root=${TARGET_PREFIX} prefix="" install

where TARGET_PREFIX is the target filesystem tree.  I
used the same make install command for the native gcc
that I compiled.


 The install command for GCC is :

   make DESTDIR=$SYSROOT install

and found via the RTFM method... Building GCC should
mean producing binaries and documents, not only the
first. But maybe I'm alone with this opinion and the
only one ever using 'pdftex' etc. document tools...

With the glibc configure you of course used the same
'--prefix=/usr' or how?  The native GCC and glibc normally
use that but the 'make install' has those 'install_root='
and 'DESTDIR=' options for installing into the $SYSROOT.

Why you used '${TARGET_PREFIX}' as your '$SYSROOT', is
a little odd, but I don't know about those LFS (Linux
From Scratch) oddities anything, maybe the book writer
didn't know so well :-) Maybe it suggests producing glibc
twice, once for the crosstools, once for the target system,
which of course is some kind of "bullying", doing it once
and for the target system of course is enough... The same
glibc works also on the cross-host, installed into the
target root directories... The '--with-sysroot=' or simple
symlinks to the '$(tooldir)' let it being used with a cross-
compiler... A already built glibc taken from an existing
Linux target of course must be installed somehow for an
usual crosscompiler for some Linux distro.

[gfortran] Problem parsing hexadecimal constants?

[Ioannis E. Venetis]

Dear all,

Firstly, let me say that I don't know that much about Fortran, but I use 
a source-code transformation tool that creates Fortran 77 code, which I 
feed to gfortran.


During this last stage, gfortran seems to have some problems to parse 
hexadecimal constants. I managed to reduce the problem to this very 
simple code:


TEST.f:

  PROGRAM HEX_TEST

  INTEGER(4) MASK

  MASK = 'c0'X

  END

~ $ gfortran -c TEST.f
 In file TEST.f:5

  MASK = 'c0'X
 1
Error: Unclassifiable statement at (1)


If, however, I make the following change:

  MASK = X'c0'

the program compiles correctly. I remember that I used this tool with 
g77 too and that I had no problem. Either form of a hexadecimal constant 
was accepted. The same holds for the Intel compiler.


Is this a bug of gfortran or some kind of extension that is not supported?

~ $ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.2/configure 
--prefix=/home/iev/apps/gcc-4.0.2 --enable-languages=c,c++,f95 
--enable-shared --enable-threads=posix --disable-checking 
--with-system-zlib --enable-__cxa_atexit --disable-libgcj --disable-nls

Thread model: posix
gcc version 4.0.2

Best regards,

Ioannis

interesting anecdote on gcc speed

[Joe Buck]

Many of us worry about the compiler getting slower over time, so I
was pleased to see a bit of good news from Planet Debian.

Norbert Tretkowski reports on his blog at

http://www.inittab.de/blog/2005/11/03#20051103_gcc33vs40 :

> Comparing gcc 3.3 and 4.0

> Kernel 2.6.14 builds fine with gcc 4.0 on alpha, so I switched the build
  system of the Debian linux-2.6 package from gcc 3.3 to gcc 4.0 on
  alpha. And it seemed that gcc 4.0 is much faster when building the
  kernel. I started two new builds using time(1), one with gcc 3.3 and one
  with gcc 4.0.

> Using gcc 3.3.6: 56692.17s user 2784.40s system 97% cpu 16:54:01.65 total
> Using gcc 4.0.2: 39189.33s user 2417.85s system 96% cpu 11:57:52.48 total

> 5 hours less... and the kernel still works fine.

Re: interesting anecdote on gcc speed

[Karel Gardas]

True! The same applies also to GNU C++ and MICO as a testing base. In fact 
every compiler from the 3.2, 3.3, 3.4, 4.0 set is faster than previous 
line.


Well, 4.0.x is really fast! Only Intel's C++ and Sun's C++ are faster 
(comparison made on linux and on solaris) when optimization is switched 
off, but completely lose the fight when optimization is switched on, this 
means: gcc generates faster code faster in both cases!


Once 4.1 is branched out, I'm ready to do some meassurements, since so far 
what I've seen 4.1 was a bit (really just a bit) slower than 4.0.


So thanks to all GCC developers for excellent work provided!
Karel

On Thu, 3 Nov 2005, Joe Buck wrote:


Many of us worry about the compiler getting slower over time, so I
was pleased to see a bit of good news from Planet Debian.

Norbert Tretkowski reports on his blog at

http://www.inittab.de/blog/2005/11/03#20051103_gcc33vs40 :


Comparing gcc 3.3 and 4.0



Kernel 2.6.14 builds fine with gcc 4.0 on alpha, so I switched the build

 system of the Debian linux-2.6 package from gcc 3.3 to gcc 4.0 on
 alpha. And it seemed that gcc 4.0 is much faster when building the
 kernel. I started two new builds using time(1), one with gcc 3.3 and one
 with gcc 4.0.


Using gcc 3.3.6: 56692.17s user 2784.40s system 97% cpu 16:54:01.65 total
Using gcc 4.0.2: 39189.33s user 2417.85s system 96% cpu 11:57:52.48 total



5 hours less... and the kernel still works fine.





--
Karel Gardas  [EMAIL PROTECTED]
ObjectSecurity Ltd.   http://www.objectsecurity.com

Re: bug 24599

[Doug Evans]

A question for the general group.
Is it really the case that it's ok that a testcase clobbers boolean_true_node
and sets overflow? (and is this one case of a more general problem?)

If that's not unintended, ok, but it seems confusing (aka source of bugs).
Or, which is certainly not unexpected, is this another case of
something being in transition and the transition isn't complete?

Note that I'm treating integer_nonzerop as a red-herring.
It's the clobbering of boolean_true_node that I'm concerned about.

pinskia at gcc dot gnu dot org writes:
 > 
 > 
 > --- Comment #3 from pinskia at gcc dot gnu dot org  2005-11-03 18:25 
 > ---
 > (In reply to comment #2)
 > > I'm not sure the root cause of this bug is fixed in 4.1.  It looks to me 
 > > like
 > > it's still there and is only (currently) hidden.  Am I mistaken?
 > > Apply this patch to gcc-4.1-20051029 and recompile the testcase with -O3.
 > > I'm seeing an abort.  If I set a breakpoint on integer_nonzerop and print 
 > > the
 > > boolean_true_node tree I see it's marked as "overflow".  Oops
 > 
 > Overflow should mean nothing to the optimizers or expanders.  It is only a
 > language term really that should only matter to the front-end. 
 > integer_nonzerop should not be used that much any more,  Yes I know it is but
 > really it needs to be changed to use nonzero_p instead.
 > 
 > 
 > -- 
 > 
 > 
 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
 > 
 > --- You are receiving this mail because: ---
 > You reported the bug, or are watching the reporter.

GCC mainline now open for bug fixes under normal Stage 3 rules

[Mark Mitchell]

There are now 99 serious regressions against GCC 4.1.

>From now until November 18th, the GCC mainline will be open for bug
fixes under the usual Stage 3 rules, rather than the more restrictive
rules we've been operating under recently.  On November 18th, I plan to
make the branch and open Stage 1 for GCC 4.2.

Please exercise due care during this time.  While we're allowing
bug-fixes, the primary goal is still to prepare for the 4.1 release.
So, if you're fixing bugs that aren't regressions, please be very
careful not to be introducing new bugs in the process.  I will consider
asking for patches to be reverted if they prove disruptive.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

timezone of svn server for -r?

[Joern RENNECKE]

What timezone does the svn server use when I specify time & date with -r?
With cvs that was never an issue because I appended UTC to the time, but svn
rejects that, so it seems I have to convert the time into whatever 
timezone the server

happens to use.

diffing directories with merged-as-deleted files?

[Joern RENNECKE]

I've a working copy of a branch in which I merged changes from mainline

- including the
deletion of the .cvsignore files.  When I try to diff a diretory, it 
errors out on the

.cvsignore files.  Is there an option not to diff files that don't exist?

bash-2.05b$ svn diff --old 
svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc --new gcc

Index: gcc/Makefile.in
===
/usr/bin/diff -up -F'^(' -u -L gcc/Makefile.in  
(.../svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc)   (revision 
106440) -L gcc/Makefile.in(.../gcc)   (working copy) 
gcc/.svn/tmp/text-base/Makefile.in.svn-base gcc/Makefile.in
--- gcc/Makefile.in 
(.../svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc)   (revision 106440)

+++ gcc/Makefile.in (.../gcc)   (working copy)
@@ -2400,7 +2400,8 @@ alias.o : alias.c $(CONFIG_H) $(SYSTEM_H
regmove.o : regmove.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) 
$(RTL_H) \

  insn-config.h timevar.h tree-pass.h \
  $(RECOG_H) output.h $(REGS_H) hard-reg-set.h $(FLAGS_H) function.h \
-   $(EXPR_H) $(BASIC_BLOCK_H) toplev.h $(TM_P_H) except.h reload.h
+   $(EXPR_H) $(BASIC_BLOCK_H) toplev.h $(TM_P_H) except.h reload.h \
+   $(OPTABS_H) gt-regmove.h
ddg.o : ddg.c $(DDG_H) $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TARGET_H) \
  toplev.h $(RTL_H) $(TM_P_H) $(REGS_H) function.h \
  $(FLAGS_H) insn-config.h $(INSN_ATTR_H) except.h $(RECOG_H) \
@@ -2755,7 +2756,7 @@ GTFILES = $(srcdir)/input.h $(srcdir)/co
 $(srcdir)/tree-iterator.c $(srcdir)/gimplify.c \
 $(srcdir)/tree-chrec.h $(srcdir)/tree-vect-generic.c \
 $(srcdir)/tree-ssa-operands.h $(srcdir)/tree-ssa-operands.c \
-  $(srcdir)/tree-profile.c $(srcdir)/tree-nested.c \
+  $(srcdir)/tree-profile.c $(srcdir)/tree-nested.c $(srcdir)/regmove.c \
 $(srcdir)/ipa-reference.c \
 $(srcdir)/targhooks.c $(out_file) \
 @all_gtfiles@
@@ -2772,7 +2773,7 @@ gt-lists.h gt-alias.h gt-cselib.h gt-gcs
gt-expr.h gt-sdbout.h gt-optabs.h gt-bitmap.h gt-dojump.h \
gt-dwarf2out.h gt-reg-stack.h gt-dwarf2asm.h \
gt-dbxout.h gt-c-common.h gt-c-decl.h gt-c-parser.h \
-gt-c-pragma.h gtype-c.h gt-cfglayout.h \
+gt-c-pragma.h gtype-c.h gt-cfglayout.h gt-regmove.h \
gt-tree-mudflap.h gt-tree-vect-generic.h \
gt-tree-profile.h gt-tree-ssa-address.h \
gt-tree-ssanames.h gt-tree-iterator.h gt-gimplify.h \
Index: gcc/.cvsignore
===
/usr/bin/diff -up -F'^(' -u -L gcc/.cvsignore   
(.../svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc)   (revision 0) -L 
gcc/.cvsignore  (.../gcc)   (revision 106387) gcc/.svn/empty-file 
gcc/.cvsignore

/usr/bin/diff: gcc/.cvsignore: No such file or directory
svn: '/home/afra/users/renneckej/bin/gccdiff' returned 2

Re: svn diff branch woprking copy against mainline?

[Mike Stump]

On Nov 2, 2005, at 7:45 PM, Branko Čibej wrote:
However, before coming up with a zillion suggestions about how to  
make the syntax nicer, please do consider the idea that we did put  
a lot of thought into the diff syntax, and that covering all the  
uses and edge cases and is not easy.


Any system that requires me to specify the same things over and over  
again, is broken.  cvs _never_ did.


cvs diff -rtag1 file.c
cvs update -jtag-1 -jtag-2 file1.c file2.c
cvs update -rnew-branch .

the list goes on and on.  You sacrificed usability for the masses for  
an edge case that we don't care about.  The good news, is the  
interface is trivial to fix.  Find a solution, and just fix it. I  
want a user interface that uses no more words than the above, for the  
above operations, and no more funny characters than the above  
either.  I don't mind if instead of -rtag1, I have to use -rtags/ 
tags1 and -rbranches/apple/trunk, that sort of expansion is fine.


In cvs land, I typed -d:whatever, about once a year, I want to type  
svn: about once a year as well.  If someone wants to do something  
funny, let them type a long command line, that's ok.


Until then, this _is_ a regression.

Oh, and how does one do:

-rb1 -D '20 days ago'

in svn?  It felt like svn threw away all the fine GNU data handling  
stuff.  Instead of throwing it away, reuse it.  cvs has it, GNU date  
has it.

Re: -Wuninitialized issues

[David Taylor]

> From: Jeffrey A Law <[EMAIL PROTECTED]>
> Date: Wed, 02 Nov 2005 19:17:06 -0700
> 
> On Wed, 2005-11-02 at 20:44 -0500, Daniel Jacobowitz wrote:

> > People who use -Wall -Werror are _already_ pissed off about
> > -Wuninitialized.  It virtually guarantees that your build will fail on
> > a new release of GCC.

Putting on my user hat, I would have to disagree.

At EMC we build with '-Wall -Werror' and do not get pissed off by
-Wuninitialized.  Historically, -Wuninitialized does not generate
a lot of false positives in our code.

> Very true, but I don't think that's an execute to generate even more
> false positives for them! :-)
> 
> Those groups of users also get upset anytime we add something -Wall, but
> that's another discussion unto itself!

I get upset when a new warning is added to -Wall, it generates noise,
and there's no way to turn it off.  But, let's not have that
discussion today.

> jeff

Take user hat off; put developer hat back on.

David

Re: svn diff branch woprking copy against mainline?

[Daniel Berlin]

[(I've copied this to [EMAIL PROTECTED], because there were questions about
what users actually wanted)]

On Thu, 2005-11-03 at 11:23 -0800, Mike Stump wrote:
> On Nov 2, 2005, at 7:45 PM, Branko Čibej wrote:
> > However, before coming up with a zillion suggestions about how to  
> > make the syntax nicer, please do consider the idea that we did put  
> > a lot of thought into the diff syntax, and that covering all the  
> > uses and edge cases and is not easy.
> 
> Any system that requires me to specify the same things over and over  
> again, is broken.  cvs _never_ did.
> 
> cvs diff -rtag1 file.c
> cvs update -jtag-1 -jtag-2 file1.c file2.c
> cvs update -rnew-branch .
> 
> the list goes on and on.  You sacrificed usability for the masses for  
> an edge case that we don't care about.  The good news, is the  
> interface is trivial to fix.  Find a solution, and just fix it. I  
> want a user interface that uses no more words than the above, for the  
> above operations, and no more funny characters than the above  
> either.  I don't mind if instead of -rtag1, I have to use -rtags/ 
> tags1 and -rbranches/apple/trunk, that sort of expansion is fine.
> 
> In cvs land, I typed -d:whatever, about once a year, I want to type  
> svn: about once a year as well.  If someone wants to do something  
> funny, let them type a long command line, that's ok.
> 
> Until then, this _is_ a regression.

No argument here from me.

> Oh, and how does one do:
> 
> -rb1 -D '20 days ago'
> 
> in svn?  It felt like svn threw away all the fine GNU data handling  
> stuff.  Instead of throwing it away, reuse it.  cvs has it, GNU date  
> has it.
> 
This, on the other hand was a very specific decision made to get rid of
the date parsing CVS did (it was used at one point) because it returns
*wrong* answers in a surprising number of cases.

If you've got a specific date syntax you'd like, and a good reason it
should be added, I doubt anybody would oppose adding it to svn.

--Dan

Re: diffing directories with merged-as-deleted files?

[Mike Stump]

On Nov 3, 2005, at 11:15 AM, Joern RENNECKE wrote:
bash-2.05b$ svn diff --old svn+ssh://[EMAIL PROTECTED]/svn/gcc/ 
trunk/gcc --new gcc


/usr/bin/diff -up -F'^(' -u -L gcc/.cvsignore   (.../svn+ssh:// 
[EMAIL PROTECTED]/svn/gcc/trunk/gcc)   (revision 0) -L  
gcc/.cvsignore  (.../gcc)   (revision 106387) gcc/.svn/empty- 
file gcc/.cvsignore

/usr/bin/diff: gcc/.cvsignore: No such file or directory
svn: '/home/afra/users/renneckej/bin/gccdiff' returned 2


Sounds like a bug in subversions.  cvs substituted /dev/null as I  
recall.


:-(

Re: diffing directories with merged-as-deleted files?

[Daniel Jacobowitz]

On Thu, Nov 03, 2005 at 07:15:22PM +, Joern RENNECKE wrote:
> Index: gcc/.cvsignore
> ===
> /usr/bin/diff -up -F'^(' -u -L gcc/.cvsignore   
> (.../svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc)   (revision 0) -L 
> gcc/.cvsignore  (.../gcc)   (revision 106387) gcc/.svn/empty-file 
> gcc/.cvsignore
> /usr/bin/diff: gcc/.cvsignore: No such file or directory
> svn: '/home/afra/users/renneckej/bin/gccdiff' returned 2

Presumably this is a bug in your 'gccdiff' script?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: diffing directories with merged-as-deleted files?

[Joern RENNECKE]

Daniel Jacobowitz wrote:


On Thu, Nov 03, 2005 at 07:15:22PM +, Joern RENNECKE wrote:
 


Index: gcc/.cvsignore
===
/usr/bin/diff -up -F'^(' -u -L gcc/.cvsignore   
(.../svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc)   (revision 0) -L 
gcc/.cvsignore  (.../gcc)   (revision 106387) gcc/.svn/empty-file 
gcc/.cvsignore

/usr/bin/diff: gcc/.cvsignore: No such file or directory
svn: '/home/afra/users/renneckej/bin/gccdiff' returned 2
   



Presumably this is a bug in your 'gccdiff' script?
 


Should it return success for diffing stuff that does not exist?

bash-2.05b$ cat ~/bin/gccdiff
#!/bin/bash
diff=/usr/bin/diff
args="-up -F'^('"

echo ${diff} ${args} "$@"
exec ${diff} ${args} "$@"

Re: diffing directories with merged-as-deleted files?

[Daniel Jacobowitz]

On Thu, Nov 03, 2005 at 08:08:27PM +, Joern RENNECKE wrote:
> Daniel Jacobowitz wrote:
> 
> >On Thu, Nov 03, 2005 at 07:15:22PM +, Joern RENNECKE wrote:
> > 
> >
> >>Index: gcc/.cvsignore
> >>===
> >>/usr/bin/diff -up -F'^(' -u -L gcc/.cvsignore   
> >>(.../svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc)   (revision 0) -L 
> >>gcc/.cvsignore  (.../gcc)   (revision 106387) gcc/.svn/empty-file 
> >>gcc/.cvsignore
> >>/usr/bin/diff: gcc/.cvsignore: No such file or directory
> >>svn: '/home/afra/users/renneckej/bin/gccdiff' returned 2
> >>   
> >>
> >
> >Presumably this is a bug in your 'gccdiff' script?
> > 
> >
> Should it return success for diffing stuff that does not exist?

Whatever you want.  It should probably either return success, or use -N.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: bug 24599

[Doug Evans]

It seems like there's a whole range of issues once boolean_true_node
(or any such global tree node) has been clobbered.

#include 

int
main (int argc, char **argv)
{
  if ((bool)((1527719483 + 1477819644))) {
  }

  return 0;
}

bool t1 = true;

---
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -O3 -S foo2.c -save-temps -pedantic
foo2.c: In function `main':
foo2.c:6: warning: integer overflow in expression
foo2.c: At top level:
foo2.c:12: warning: overflow in constant expression
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -v
Reading specs from ./specs
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/tmp/junk
Thread model: posix
gcc version 4.1.0 20051026 (experimental)
[EMAIL PROTECTED] gcc]$ 

Re: diffing directories with merged-as-deleted files?

[Joern RENNECKE]

Daniel Jacobowitz wrote:

 


Whatever you want.  It should probably either return success, or use -N.
 

I also get a failure when I comment out the diff-cmd line in my 
~/.subversion/config .
Does that mean that every subversion configuration that doesn't 
configure a diff-cmd to deal

with non-existant files is broken?

bash-2.05b$ svn diff --old 
svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc --new gcc

Index: gcc/Makefile.in
===
--- gcc/Makefile.in 
(.../svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc)   (revision 106446)

+++ gcc/Makefile.in (.../gcc)   (working copy)
@@ -2400,7 +2400,8 @@
regmove.o : regmove.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) 
$(RTL_H) \

   insn-config.h timevar.h tree-pass.h \
   $(RECOG_H) output.h $(REGS_H) hard-reg-set.h $(FLAGS_H) function.h \
-   $(EXPR_H) $(BASIC_BLOCK_H) toplev.h $(TM_P_H) except.h reload.h
+   $(EXPR_H) $(BASIC_BLOCK_H) toplev.h $(TM_P_H) except.h reload.h \
+   $(OPTABS_H) gt-regmove.h
ddg.o : ddg.c $(DDG_H) $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TARGET_H) \
   toplev.h $(RTL_H) $(TM_P_H) $(REGS_H) function.h \
   $(FLAGS_H) insn-config.h $(INSN_ATTR_H) except.h $(RECOG_H) \
@@ -2755,7 +2756,7 @@
  $(srcdir)/tree-iterator.c $(srcdir)/gimplify.c \
  $(srcdir)/tree-chrec.h $(srcdir)/tree-vect-generic.c \
  $(srcdir)/tree-ssa-operands.h $(srcdir)/tree-ssa-operands.c \
-  $(srcdir)/tree-profile.c $(srcdir)/tree-nested.c \
+  $(srcdir)/tree-profile.c $(srcdir)/tree-nested.c $(srcdir)/regmove.c \
  $(srcdir)/ipa-reference.c \
  $(srcdir)/targhooks.c $(out_file) \
  @all_gtfiles@
@@ -2772,7 +2773,7 @@
gt-expr.h gt-sdbout.h gt-optabs.h gt-bitmap.h gt-dojump.h \
gt-dwarf2out.h gt-reg-stack.h gt-dwarf2asm.h \
gt-dbxout.h gt-c-common.h gt-c-decl.h gt-c-parser.h \
-gt-c-pragma.h gtype-c.h gt-cfglayout.h \
+gt-c-pragma.h gtype-c.h gt-cfglayout.h gt-regmove.h \
gt-tree-mudflap.h gt-tree-vect-generic.h \
gt-tree-profile.h gt-tree-ssa-address.h \
gt-tree-ssanames.h gt-tree-iterator.h gt-gimplify.h \
svn: Can't open file 'gcc/.cvsignore': No such file or directory

Re: diffing directories with merged-as-deleted files?

[Joern RENNECKE]

Daniel Jacobowitz wrote:

 


Whatever you want.  It should probably either return success, or use -N.

 

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 identical, i.e. two 
lines for each file like:


Index: gcc/tree-ssa-operands.c
===

cvs would never do such nonsense.

svn repository incorrectly converted or corrupted

[Joern RENNECKE]

cvs version version 1.1.1.1.2.1 of 
gcc/libjava/classpath/java/awt/im/InputContext.java , i.e. the 
sh-elf-4_1-branch head,

is supposed to correspond to
svn+ssh://[EMAIL PROTECTED]/svn/gcc/branches/sh-elf-4_1-branch/libjava/classpath/java/awt/im/[EMAIL PROTECTED] 
.
However, every single line that was supposed to be kept from the 
previous version has been removed.

Re: weird installation problem on i686-pc-linux-gnu

[James E Wilson]

On Wed, 2005-11-02 at 02:35, Martin Reinecke wrote:
> Unfortunately I have no way of finding out more about the local "install",
> as it doesn't accept the --help flag:

Did you check to see if it might be a shell script?  If so, there might
be comments in it.  If it isn't a shell script, then running "strings"
on it might give useful info.  Also try options -v, --verbose, and
--version.

autoconf already has a number of checks for various known install
programs with various known bugs.  If it can be identified, then
autoconf can be fixed to avoid use of it.

I don't see the install program in my out-dated copy of POSIX, but there
is a long history of UNIX systems having a program called install that
works the way gcc expects it to work.  So I'm tempted to call it a bug
with your system, though I can't produce a convincing argument for
that.  One could also perhaps call it a bug in autoconf that it doesn't
check for this and work around it.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: timezone of svn server for -r?

[Andreas Schwab]

Joern RENNECKE <[EMAIL PROTECTED]> writes:

> What timezone does the svn server use when I specify time & date with -r?
> With cvs that was never an issue because I appended UTC to the time, but svn
> rejects that, so it seems I have to convert the time into whatever 
> timezone the server
> happens to use.

>From the subversion book:

Here are examples of the date formats that Subversion accepts. Remember to
use quotes around any date that contains spaces.
$ svn checkout --revision {2002-02-17}
$ svn checkout --revision {15:30}
$ svn checkout --revision {15:30:00.20}
$ svn checkout --revision {"2002-02-17 15:30"}
$ svn checkout --revision {"2002-02-17 15:30 +0230"}
$ svn checkout --revision {2002-02-17T15:30}
$ svn checkout --revision {2002-02-17T15:30Z}
$ svn checkout --revision {2002-02-17T15:30-04:00}
$ svn checkout --revision {20020217T1530}
$ svn checkout --revision {20020217T1530Z}
$ svn checkout --revision {20020217T1530-0500}

Use Z or + for the timezone.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: weird installation problem on i686-pc-linux-gnu

[Martin Reinecke]

On Thu, Nov 03, 2005 at 10:25:28AM -0800, James E Wilson wrote:
> On Wed, 2005-11-02 at 02:35, Martin Reinecke wrote:
> > Unfortunately I have no way of finding out more about the local "install",
> > as it doesn't accept the --help flag:
> 
> Did you check to see if it might be a shell script?  If so, there might
> be comments in it.  If it isn't a shell script, then running "strings"
> on it might give useful info.  Also try options -v, --verbose, and
> --version.

It's not a shell script, and "strings" doesn't reveal much either.
But I can probably talk to the responsible person at the computing center
tomorrow, and hope to learn more about the program.
 
> autoconf already has a number of checks for various known install
> programs with various known bugs.  If it can be identified, then
> autoconf can be fixed to avoid use of it.
> 
> I don't see the install program in my out-dated copy of POSIX, but there
> is a long history of UNIX systems having a program called install that
> works the way gcc expects it to work.  So I'm tempted to call it a bug
> with your system, though I can't produce a convincing argument for
> that.  One could also perhaps call it a bug in autoconf that it doesn't
> check for this and work around it.

I'll let you know what kind of install it is, as soon as I know it myself.
If it isn't something completely homegrown, a change to autoconf might
indeed be useful.

-- 

Re: toplevel Makefile.tpl hacking

[François-Xavier Coudert]

>>   - with this patch, the libgfortran is built, but the gfortran
>> testsuite doesn't run; why isn't $(RPATH_ENVVAR) including HOST_LIB_PATH
>> for the testsuite?
>
> It should

Well, it doesn't. The problem is that the gfortran testsuite is not
run with the toplevel Makefile, but by going into the $builddir/gcc
directory and typing "make check-fortran". I'm not sure whether this
is another deficiency (after all, make check-gcc and make check-g++
can be run from the toplevel makefile), and how to fix it.

FX

Re: svn diff branch woprking copy against mainline?

[Branko Čibej]

Paolo Bonzini wrote:
More formally, you can say that any file in the checkout is made of 
BASE/DIR/filename where BASE is the URL passed to the latest `svn co' 
or `svn switch' command.
The current SVN working copy philosophy (the same as CVS's, by the way) 
is that every working copy directory is self-contained. If we start 
recording command parameters in the working copy, we break that property.


Anyway, there are other ways of achieving this behaviour that are more 
friendly to SVN's concept; they'd been discussed in the past and are 
being discussed now on the SVN dev list, but (unlike simple root URL 
expansion) aren't trivial to implement, so don't expect any changes in 
this area by the day after tomorrow.



(I don't want to discuss these things in more detail on this list; SVN 
design discussions belong on the SVN dev list, and duplicating them here 
would be counter-productive.


Of course, anyone is welcome to participate in discussions on our dev list.)

-- Brane

Re: svn diff branch woprking copy against mainline?

[Branko Čibej]

Joern RENNECKE wrote:

Branko Čibej wrote:

 



It certainly seems that --old and --new are redundant.


I suggest a search in http://svn.haxx.se/dev/.


What should we search for?  I tried both of --old and --new, and both 
searches

came up empty.

Heh, that's Google search for you...

Try

   "--old" "--new"


Also, you could
consider stealing some ideas from Perforce, where the command would be
something like

p4 diff [EMAIL PROTECTED] file.c

and the RCS figures out how to map the label to the repository version.
Basically, the # and @ characters are special; # is used to introduce
a revision number (the global revision number), and a number of things
can follow @, like a label, or a date.
  


This seems to be a common misconception. The important thing to 
remember here is that there is no separate namespace for labels and 
branches in SVN, and that the layout of the repository is arbitrary. 
IOW, the fact that you have branches in /branches is a convention, 
not something imposed by the SVN server.



It's not a misconception, it's a perception of an svn shortcoming.  
There should be a configurable mapping from branch/tag names to 
branch/tag
locations.  I.e. you tell the svn server once what your conventions 
are, and then you don't have to apply them by hand every time you 
refer to
a branch or tag.  Without such a mechanism, svn makes a rather poor 
cvs replacement.
As I said in another post, I don't want to repeat past 
[EMAIL PROTECTED] discussions on this list (and yes, you're 
talking about things we've already discussed to death. :)


-- Brane

Re: svn diff branch woprking copy against mainline?

[Andreas Schwab]

Joern RENNECKE <[EMAIL PROTECTED]> writes:

> export 
> gcc_4_1_1_release='svn+ssh://[EMAIL PROTECTED]/svn/gcc/tags/gcc_4_1_1_release'

Btw, if you put the following in your ~/.ssh/config:

Host gcc.gnu.org
   User amylaar

you don't have to specify the username in the svn URL (or any other ssh
command line for connecting to gcc.gnu.org).

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: toplevel Makefile.tpl hacking

[Andreas Schwab]

François-Xavier Coudert <[EMAIL PROTECTED]> writes:

> (after all, make check-gcc and make check-g++
> can be run from the toplevel makefile)

The toplevel makefile only knows about check-gcc, which translates to "cd
gcc; make check" (modulo variable passing).  If you want to run only the
g++ testsuite, you need to run "make check-g++" from inside the gcc
directory.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: svn diff branch woprking copy against mainline?

[Andreas Schwab]

Branko Čibej <[EMAIL PROTECTED]> writes:

> Paolo Bonzini wrote:
>> More formally, you can say that any file in the checkout is made of
>> BASE/DIR/filename where BASE is the URL passed to the latest `svn co' or
>> svn switch' command.
> The current SVN working copy philosophy (the same as CVS's, by the way) 
> is that every working copy directory is self-contained. If we start 
> recording command parameters in the working copy, we break that property.

Isn't this what the "Repository Root" from svn info gives?

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: svn diff branch woprking copy against mainline?

[Branko Čibej]

Andreas Schwab wrote:

Branko Čibej <[EMAIL PROTECTED]> writes:

  

Paolo Bonzini wrote:


More formally, you can say that any file in the checkout is made of
BASE/DIR/filename where BASE is the URL passed to the latest `svn co' or
svn switch' command.
  
The current SVN working copy philosophy (the same as CVS's, by the way) 
is that every working copy directory is self-contained. If we start 
recording command parameters in the working copy, we break that property.



Isn't this what the "Repository Root" from svn info gives?
  

No, that's the root of the repository, not the parameter given to "svn co".

If you

   svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk

the repository root that gets recorded is

   svn+ssh://gcc.gnu.org/svn/gcc

The same root is recorded if you

   svn co svn+ssh://gcc.gnu.org/svn/gcc/branches/bounded-pointers-branch

-- Brane

Re: svn repository incorrectly converted or corrupted

[Daniel Berlin]

On Thu, 2005-11-03 at 21:27 +, Joern RENNECKE wrote:
> cvs version version 1.1.1.1.2.1 of 
> gcc/libjava/classpath/java/awt/im/InputContext.java , i.e. the 
> sh-elf-4_1-branch head,
> is supposed to correspond to
> svn+ssh://[EMAIL 
> PROTECTED]/svn/gcc/branches/sh-elf-4_1-branch/libjava/classpath/java/awt/im/[EMAIL
>  PROTECTED] 
> .
> However, every single line that was supposed to be kept from the 
> previous version has been removed.
Yes, there were a few problems of copying from "incorrect files" on
branches when it came to libjava.
cvs2svn only uses a heuristic, and sometimes reorders commits when it
has to.
There is no perfect reconstruction of a svn repo from a cvs one.
It does the best it can.

This particular problem seems to be related to vendor imports done of
classpath and pulling those versions back to branches.

I fixed the branches i noticed this happened on.

If you had actually emailed me, i would have given you simple
instructions on how to fix it.

Simply do a recopy of libjava from the approriate tag, and all will be
well.

Re: svn url shortcuts

[DJ Delorie]

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 trunk svn://gcc.gnu.org/svn/gcc/trunk
tag 4.0 svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch

You could just "svn co tag:4.0/gcc/config/i386"

It probably screams for lots more prettying up, but at least I did
something about it ;-)

If you want it shorter, I could rewrite this so that the tag name goes
before the colon, like "4.0:gcc/config/i386"

DJ


Index: subversion/libsvn_subr/path.c
===
--- subversion/libsvn_subr/path.c   (revision 17180)
+++ subversion/libsvn_subr/path.c   (working copy)
@@ -1103,6 +1103,50 @@
 }
 
 
+
+static const char *
+replace_tag (const char *path, apr_pool_t *pool)
+{
+  FILE *svnrc;
+  char *svnrc_name;
+  const char *home;
+  const char *tb, *te;
+  char *newpath;
+  char line[1000];
+
+  tb = path + 4;
+  te = strchr (tb, '/');
+  if (!te)
+te = tb + strlen(tb);
+  home = getenv("HOME");
+  if (!home)
+return path;
+  svnrc_name = apr_pcalloc (pool, strlen(home) + 8);
+  strcpy (svnrc_name, home);
+  strcat(svnrc_name, "/.svnrc");
+  svnrc = fopen(svnrc_name, "r");
+  if (!svnrc)
+return path;
+  while (fgets(line, 1000, svnrc))
+{
+  if (memcmp (line, "tag ", 4))
+   continue;
+  if (strncmp (line+4, tb, te-tb))
+   continue;
+  if (line[4+te-tb] != ' ')
+   continue;
+  newpath = apr_pcalloc (pool, strlen(line+4+(te-tb)+1) + strlen(te) + 1);
+  strcpy (newpath, line+4+(te-tb)+1);
+  while (newpath[strlen(newpath)-1] == '\n')
+   newpath[strlen(newpath)-1] = 0;
+  strcat (newpath, te);
+  fclose(svnrc);
+  return newpath;
+}
+  fclose(svnrc);
+  return path;
+}
+
 const char *
 svn_path_canonicalize (const char *path, apr_pool_t *pool)
 {
@@ -1112,6 +1156,9 @@
   apr_size_t canon_segments = 0;
   svn_boolean_t uri;
 
+  if (strncmp (path, "tag:", 4) == 0)
+path = replace_tag (path, pool);
+
   dst = canon = apr_pcalloc (pool, strlen (path) + 1);
 
   /* Copy over the URI scheme if present. */

Re: svn diff branch woprking copy against mainline?

[Joern RENNECKE]

Branko Čibej wrote:


"--old" "--new"


Hmm, that finds a lot more, although not specific to options.
I've found one thread that seems slightly relevant,  Diff syntax changes 
for issue #1093 . 

I get the impression that you devise neat ways to navigate precisely 
through multiple
time dimensions.  By all means, do that, but please don't use up the 
very option letters that

cvs uses to do commonplace repository navigation with.
An ordinary tag is a static thing; you don't expect it to change over 
time.  An ordinary
branch will be present in the head revision.  With a suitable repository 
layout, and some
descriptive config files, the -r option should give capabilities 
comparable to cvs.
I suppose it doesn't matter if numerical arguments to -r are always pure 
operational versions,
but you should be able to name a branch/tag and thus imply a root 
directory for the location,
in the current head revision unless modified with @rev-number (on the 
branch name) or -D.



  As I said in another post, I don't want to repeat past 
[EMAIL PROTECTED] discussions on this list (and yes, you're 
talking about things we've already discussed to death. :)


So why is there no pointer in the FAQ to these posts?

Re: svn repository incorrectly converted or corrupted

[Joern RENNECKE]

Daniel Berlin wrote:

 



Simply do a recopy of libjava from the approriate tag, and all will be
well.
 


Do you have a list of potentially affected files?

Re: svn repository incorrectly converted or corrupted

[Daniel Berlin]

On Thu, 2005-11-03 at 23:49 +, Joern RENNECKE wrote:
> Daniel Berlin wrote:
> 
> >  
> >
> >
> >Simply do a recopy of libjava from the approriate tag, and all will be
> >well.
> >  
> >
> Do you have a list of potentially affected files?

Anything on vendor imports from classpath.


Unless you've modified the sh-elf-4_1 branch, just do

svn rm svn+ssh://gcc.gnu.org/svn/gcc/branches/sh-elf-4_1-branch/libjava
svn cp -r  svn
+ssh://gcc.gnu.org/svn/gcc/trunk/libjava svn
+ssh://gcc.gnu.org/svn/gcc/branches/sh-elf-4_1-branch

Re: svn diff branch woprking copy against mainline?

[Joern RENNECKE]

Joern Rennecke wrote:

 
but you should be able to name a branch/tag and thus imply a root 
directory for the location,
in the current head revision unless modified with @rev-number (on the 
branch name) or -D.


P.S.: instead of adding a -D option we could also a syntax of -r 
[EMAIL PROTECTED]

Re: diffing directories with merged-as-deleted files?

[Giovanni Bajo]

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 identical, i.e.
> two lines for each file like:
>
> Index: gcc/tree-ssa-operands.c
> ===
>
> cvs would never do such nonsense.


Absolutely! It would just print all the directory names in the middle of the
diffs. I call that nonsense as well.

Giovanni Bajo

Re: diffing directories with merged-as-deleted files?

[Phil Edwards]

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 identical, i.e.
> > two lines for each file like:
> >
> > Index: gcc/tree-ssa-operands.c
> > ===
> >
> > cvs would never do such nonsense.
> 
> Absolutely! It would just print all the directory names in the middle of the
> diffs. I call that nonsense as well.

Somewhere I have a tiny awk script to remove all that garbage, ping me if
I should hunt it up.


-- 
Behind everything some further thing is found, forever; thus the tree behind
the bird, stone beneath soil, the sun behind Urth.  Behind our efforts, let
there be found our efforts.
  - Ascian saying, as related by Loyal to the Group of Seventeen

Re: diffing directories with merged-as-deleted files?

[Daniel Berlin]

On Thu, 2005-11-03 at 20:36 +, Joern RENNECKE wrote:
> Daniel Jacobowitz wrote:
> 
> >  
> >
> >Whatever you want.  It should probably either return success, or use -N.
> >
> >  
> >
> P.S.: When I use a diff-cmd with -N, I not only get a diff for the 44 
> files that are different,

Don't use -N

Re: diffing directories with merged-as-deleted files?

[Daniel Berlin]

On Thu, 2005-11-03 at 12:03 -0800, Mike Stump wrote:
> On Nov 3, 2005, at 11:15 AM, Joern RENNECKE wrote:
> > bash-2.05b$ svn diff --old svn+ssh://[EMAIL PROTECTED]/svn/gcc/ 
> > trunk/gcc --new gcc
> 
> > /usr/bin/diff -up -F'^(' -u -L gcc/.cvsignore   (.../svn+ssh:// 
> > [EMAIL PROTECTED]/svn/gcc/trunk/gcc)   (revision 0) -L  
> > gcc/.cvsignore  (.../gcc)   (revision 106387) gcc/.svn/empty- 
> > file gcc/.cvsignore
> > /usr/bin/diff: gcc/.cvsignore: No such file or directory
> > svn: '/home/afra/users/renneckej/bin/gccdiff' returned 2
> 
> Sounds like a bug in subversions.  cvs substituted /dev/null as I  
> recall.

Actually, it's not a bug at all.
Or at least, i can't reproduce it at all

Re: diffing directories with merged-as-deleted files?

[Daniel Berlin]

On Thu, 2005-11-03 at 20:18 +, Joern RENNECKE wrote:
> Daniel Jacobowitz wrote:
> 
> >  
> >
> >Whatever you want.  It should probably either return success, or use -N.
> >  
> >
> I also get a failure when I comment out the diff-cmd line in my 
> ~/.subversion/config .
> Does that mean that every subversion configuration that doesn't 
> configure a diff-cmd to deal
> with non-existant files is broken?

No.

You need to give me more info.

What version of svn?
What is the exact branch you are trying to diff??

doing
svn diff -N
--old=svn+ssh://gcc.gnu.org/svn/gcc/trunk/[EMAIL PROTECTED] --new=.

in my gcc dir  gives me 
Index: .cvsignore
===
--- .cvsignore  (.../svn+ssh://gcc.gnu.org/svn/gcc/trunk/gcc)
(revision 106276)
+++ .cvsignore  (working copy)
@@ -1,9 +0,0 @@
-GPATH
-GRTAGS
-GSYMS
-GTAGS
-cscope.files
-cscope.out
-cscope.in.out
-cscope.po.out
-autom4te.cache


This is exactly what i would expect.

Can you *PLEASE* copy me on emails you want answers to subversion
questions about?

Re: diffing directories with merged-as-deleted files?

[Daniel Berlin]

On Thu, 2005-11-03 at 19:13 -0500, Daniel Berlin wrote:
> On Thu, 2005-11-03 at 12:03 -0800, Mike Stump wrote:
> > On Nov 3, 2005, at 11:15 AM, Joern RENNECKE wrote:
> > > bash-2.05b$ svn diff --old svn+ssh://[EMAIL PROTECTED]/svn/gcc/ 
> > > trunk/gcc --new gcc
> > 
> > > /usr/bin/diff -up -F'^(' -u -L gcc/.cvsignore   (.../svn+ssh:// 
> > > [EMAIL PROTECTED]/svn/gcc/trunk/gcc)   (revision 0) -L  
> > > gcc/.cvsignore  (.../gcc)   (revision 106387) gcc/.svn/empty- 
> > > file gcc/.cvsignore
> > > /usr/bin/diff: gcc/.cvsignore: No such file or directory
> > > svn: '/home/afra/users/renneckej/bin/gccdiff' returned 2
> > 
> > Sounds like a bug in subversions.  cvs substituted /dev/null as I  
> > recall.
> 
> Actually, it's not a bug at all.
> Or at least, i can't reproduce it at all

You'll also notice, BTW, that it substituted in gcc/.svn/empty-file for
the empty file, which is what it is supposed to do (in 1.4, we remoed
the empty file and just use /dev/null)

Re: svn diff branch woprking copy against mainline?

[Kevin Puetz]

I'm replying to a thread off of gcc-devel, but as I think I may have just
had a thought that hasn't already been chewed through. So, I'm shifting to
subversion-devel. If I'm wrong and this is already debunked, just shoot me
down...

Branko Čibej wrote:

> Andreas Schwab wrote:
>> Branko Čibej <[EMAIL PROTECTED]> writes:
>>
>>   
>>> Paolo Bonzini wrote:
>>> 
 More formally, you can say that any file in the checkout is made of
 BASE/DIR/filename where BASE is the URL passed to the latest `svn co'
 or svn switch' command.
   
>>> The current SVN working copy philosophy (the same as CVS's, by the way)
>>> is that every working copy directory is self-contained. If we start
>>> recording command parameters in the working copy, we break that
>>> property.
>>> 
>>
>> Isn't this what the "Repository Root" from svn info gives?
>>   
> No, that's the root of the repository, not the parameter given to "svn
> co".
> 
> If you
> 
> svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
> 
> the repository root that gets recorded is
> 
> svn+ssh://gcc.gnu.org/svn/gcc
> 
> The same root is recorded if you
> 
> svn co svn+ssh://gcc.gnu.org/svn/gcc/branches/bounded-pointers-branch
> 
> -- Brane

Sure. But svn info also knows (and has known for far longer) the URL.
and URL with the Repository-Root prefix whacked off is BASE/DIR. So that
info is obtainable.

Actually, I just had a thought I haven't seen proposed before (and I have
followed several of these discussions). This wouldn't have worked before
1.3, since we didn't know the repository root, but it ought to Perhaps
(stealing a page from patch) a good, and familiar 'swizzle' syntax would be
-pN:/path where N is the number of initial directories to prune between the
repository root and the current URL, and /path is the prefix to tack on
instead.

so, for the most common cases, we'd have
which would do
# svn info
URL: svn://root/trunk/subdir
Repository-Root: svn://root

# svn diff -p1:/branches/foo bar.c baz.c (trunk to branch)
which would mean:
# svn diff --old svn://root/trunk/subdir --new
svn://root/branches/foo/subdir bar.c baz.c
-
# svn info
URL: svn://root/branches/foo/subdir
Repository-Root: svn://root

#svn diff -p2:/trunk bar.c baz.c (branch to trunk)
which would mean:
#svn diff --old svn://root/branches/foo/subdir --new svn://root/trunk/subdir
bar.c baz.c

This feels like it translates pretty straightforwardly onto the existing
--old and --new primitives, doesn't break the SVN "it's a filesystem"
paradigm, and it's pretty agreably terse for common operations and
repository layouts.

It probably needs some way to reverse the interpretation of old and new,
since reversing the order and doing -p/path:2 looks weird and has a quoting
problem to find the :. Maybe +pN:/path? Or just svn diff --reverse.

It's mildly annoying to have to think about the depth of the current WC, but
I don't really think it's too bad - it wouldn't work well for scripting,
but --old and --new work find for that - scripts don't mind the typing.

Ok, here goes nuthin'...

Re: svn diff branch woprking copy against mainline?

[Branko Čibej]

Kevin Puetz wrote:

I'm replying to a thread off of gcc-devel, but as I think I may have just
had a thought that hasn't already been chewed through. So, I'm shifting to
subversion-devel. If I'm wrong and this is already debunked, just shoot me
down...

Branko Čibej wrote:

  

Andreas Schwab wrote:


Isn't this what the "Repository Root" from svn info gives?
  

No, that's the root of the repository, not the parameter given to "svn
co".

If you

svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk

the repository root that gets recorded is

svn+ssh://gcc.gnu.org/svn/gcc

The same root is recorded if you

svn co svn+ssh://gcc.gnu.org/svn/gcc/branches/bounded-pointers-branch

-- Brane



Sure. But svn info also knows (and has known for far longer) the URL.
and URL with the Repository-Root prefix whacked off is BASE/DIR. So that
info is obtainable.
  

You can't tell which is BASE and which is DIR.

-- Brane

Re: diffing directories with merged-as-deleted files?

[amylaar]

>> cvs would never do such nonsense.


>Absolutely! It would just print all the directory names in the middle of the
>diffs. I call that nonsense as well.

But the directory names go to stderr.  When you redirect stdout to a file,
a diff without the directory names is written to that file, while you
get an ongoing progress report.

Re: diffing directories with merged-as-deleted files?

[Joern Rennecke]

> What version of svn?

The 1.3 release candidate.

> What is the exact branch you are trying to diff??

I had checked out a copy of the sh-elf-4_1-branch, and used
svn merge to apply the patches from the last merge point to
the current mainline.  This merge deleted the .cvsignore file
in my working copy, but svn diff still tries to reference it.

Re: diffing directories with merged-as-deleted files?

[Daniel Berlin]

On Thu, 2005-11-03 at 20:29 -0500, Joern Rennecke wrote:
> > What version of svn?
> 
> The 1.3 release candidate.
> 
> > What is the exact branch you are trying to diff??
> 
> I had checked out a copy of the sh-elf-4_1-branch, and used
> svn merge to apply the patches from the last merge point to
> the current mainline.  This merge deleted the .cvsignore file
> in my working copy, but svn diff still tries to reference it.

Well

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-branch> svn diff -N
Index: .cvsignore
===
--- .cvsignore  (revision 106478)
+++ .cvsignore  (working copy)
@@ -1,32 +0,0 @@
-*-all
-*-co
-*-dirs
-*-done
-*-install-info
-*-src
-*-stamp-*
-*-tagged
-blockit
-cfg-paper.info
-config.status
-configure.aux
-configure.cp
-configure.cps
-configure.dvi
-configure.fn
-configure.fns
-configure.ky
-configure.kys
-configure.log
-configure.pg
-configure.pgs
-configure.toc
-configure.tp
-configure.tps
-configure.vr
-configure.vrs
-dir.info
-Makefile
-lost+found
-update.out
-LAST_UPDATED

which is what i expect.

svn diff (without non-recursive) gives me all the .cvsignore files

I tried this with both 1.4 (on my machine) and 1.3rc1 (directly on
gcc.gnu.org)

So uh, i'm not sure what to tell you.
I need to be able to reproduce this to be able to fix it, so i need an
exact set of command lines i can type to make this fail.
--Dan

Re: toplevel Makefile.tpl hacking

[Paolo Bonzini]

François-Xavier Coudert wrote:


 - with this patch, the libgfortran is built, but the gfortran
testsuite doesn't run; why isn't $(RPATH_ENVVAR) including HOST_LIB_PATH
for the testsuite?
 


It should
   



Well, it doesn't. The problem is that the gfortran testsuite is not
run with the toplevel Makefile, but by going into the $builddir/gcc
directory and typing "make check-fortran". I'm not sure whether this
is another deficiency (after all, make check-gcc and make check-g++
can be run from the toplevel makefile), and how to fix it.

 

You can use "make check-target-libgfortran", which is what I thought you 
were using to test.


Paolo