AFAIU, the gcc_3_4_0_release tag seems to be misplaced on several files in CVS. After a cvs co -r gcc_3_4_0_release cvs diff -uNR produces a larger diff containing files that seem to be tagged gcc_3_4_0_release but not contained in the actual release (As it seems to me these files have been tagged gcc_3_4_0_release but had been "cvs rm"'ed afterwards). This causes problems when having local additions in a checked out copy of gcc-3.4-branch and wanting to generated diffs against gcc-3.4.0 (cvs diff -uNR -r gcc_3_4_0_release) I'd expect removing the gcc_3_4_0_release tag from these files to fix this issue. Affect are: gcc/config/mips/iris6-o32-as.h gcc/config/mips/iris6-o32-gas.h gcc/config/mips/iris6-o32.h gcc/config/mips/irix6-crti.asm gcc/config/mips/irix6-crtn.asm gcc/config/mips/t-iris6gld gcc/config/sparc/t-linux gcc/fixinc/tests/base/libgen.h gcc/testsuite/g++.dg/pch/wchar-1.C gcc/testsuite/g++.dg/pch/wchar-1.Hs gcc/testsuite/gcc.c-torture/execute/990208-1.x gcc/testsuite/gcc.dg/compat/struct-by-value-5_main.c gcc/testsuite/gcc.dg/compat/struct-by-value-5_x.c gcc/testsuite/gcc.dg/compat/struct-by-value-5_y.c gcc/testsuite/gcc.dg/compat/struct-by-value-6_main.c gcc/testsuite/gcc.dg/compat/struct-by-value-6_x.c gcc/testsuite/gcc.dg/compat/struct-by-value-6_y.c gcc/testsuite/gcc.dg/compat/struct-by-value-7_main.c gcc/testsuite/gcc.dg/compat/struct-by-value-7_x.c gcc/testsuite/gcc.dg/compat/struct-by-value-7_y.c libstdc++-v3/include/bits/demangle.h libstdc++-v3/libmath/nan.c libstdc++-v3/src/demangle.cc libstdc++-v3/testsuite/26_numerics/cmath/overloads.C libstdc++-v3/testsuite/26_numerics/complex/pow.C libstdc++-v3/testsuite/performance/allocator.cc libstdc++-v3/testsuite/performance/allocator_thread.cc libstdc++-v3/testsuite/performance/complex_norm.cc libstdc++-v3/testsuite/performance/container_benchmark.cc libstdc++-v3/testsuite/performance/cout_insert_int.cc libstdc++-v3/testsuite/performance/filebuf_copy.cc libstdc++-v3/testsuite/performance/filebuf_sputc.cc libstdc++-v3/testsuite/performance/fmtflags_manipulators.cc libstdc++-v3/testsuite/performance/fstream_seek_write.cc libstdc++-v3/testsuite/performance/ifstream_extract_float.cc libstdc++-v3/testsuite/performance/ifstream_extract_int.cc libstdc++-v3/testsuite/performance/ifstream_getline.cc libstdc++-v3/testsuite/performance/is_wchar_t.cc libstdc++-v3/testsuite/performance/list_create_fill_sort.cc libstdc++-v3/testsuite/performance/map_create_fill.cc libstdc++-v3/testsuite/performance/narrow_widen_char.cc libstdc++-v3/testsuite/performance/narrow_widen_wchar_t.cc libstdc++-v3/testsuite/performance/ofstream_insert_float.cc libstdc++-v3/testsuite/performance/ofstream_insert_int.cc libstdc++-v3/testsuite/performance/string_append.cc libstdc++-v3/testsuite/performance/string_cons_input_iterator.cc libstdc++-v3/testsuite/performance/wchar_t_in.cc libstdc++-v3/testsuite/performance/wchar_t_length.cc libstdc++-v3/testsuite/performance/wchar_t_out.cc
Subject: Re: New: CVS Misplaced gcc_3_4_0_release tags On Fri, 21 May 2004, ralf_corsepius at rtems dot org wrote: > produces a larger diff containing files that seem to be tagged gcc_3_4_0_release > but not contained in the actual release (As it seems to me these files have been > tagged gcc_3_4_0_release but had been "cvs rm"'ed afterwards). These look rather like files that were deleted on 3.4 branch before the release was made. As the revisions have status "dead" (i.e., deleted files), I fail to see the intrinsic problem; cvs tag does put tags on some dead revisions; they may not be useful but any problems they cause sound like bugs in other software. > This causes problems when having local additions in a checked out copy of > gcc-3.4-branch and wanting to generated diffs against gcc-3.4.0 > (cvs diff -uNR -r gcc_3_4_0_release) This sounds like a bug in cvs diff.
(In reply to comment #1) > These look rather like files that were deleted on 3.4 branch before the > release was made. As the revisions have status "dead" (i.e., deleted > files), I fail to see the intrinsic problem; I don't know what you mean by "intrinsic problem", but the "user side problem" is "plain simple": cvs diff -uNR -r gcc_3_4_0_release produces invalid diffs. > This sounds like a bug in cvs diff. May-be, I don't know.
Subject: Re: CVS Misplaced gcc_3_4_0_release tags On Sat, 22 May 2004, ralf_corsepius at rtems dot org wrote: > > These look rather like files that were deleted on 3.4 branch before the > > release was made. As the revisions have status "dead" (i.e., deleted > > files), I fail to see the intrinsic problem; > > I don't know what you mean by "intrinsic problem", but the "user side problem" A problem with the contents of 3.4.0 implied by the semantics of the repository contents not agreeing with the contents of 3.4.0 as released in tarballs. The format of CVS repositories may not be perfectly documented, but the manual says: # A `dead' state means that file has been removed, or # never added, for that revision. I.e., dead state on 3.4 branch means the file has been removed or never added on 3.4 branch, and dead state for 3.4.0 release means the file is not in 3.4.0 release, and tools treating it as such are in error. The release script would have built the tarball with cvs export -rgcc_3_4_0_release, and it does not appear to include the files you list, and from your bug report, it seems that cvs co is correctly interpreting the repository as well. If checking out from a tag and immediately running a diff against that tag shows any diffs, that clearly indicates a CVS bug in that different commands are interpreting the same repository differently. In this case, it seems to be cvs diff which is making an incorrect interpretation.
So not a bug in our repostitory but a bug in CVS.