Re: jamais-vu can now ignore renumbering of source lines in dg output (Re: GCC Buildbot Update)
On 24/01/18 20:20, David Malcolm wrote:
>
> I've added a new feature to jamais-vu (as of
> 77849e2809ca9a049d5683571e27ebe190977fa8): it can now ignore test
> results that merely changed line number.
>
> For example, if the old .sum file has a:
>
> PASS: g++.dg/diagnostic/param-type-mismatch.C -std=gnu++11 (test for
> errors, line 106)
>
> and the new .sum file has a:
>
> PASS: g++.dg/diagnostic/param-type-mismatch.C -std=gnu++11 (test for
> errors, line 103)
>
> and diffing the source trees reveals that line 106 became line 103, the
> change won't be reported by "jv compare".
>
> It also does it for dg-{begin|end}-multiline-output.
>
> It will report them if the outcome changed (e.g. from PASS to FAIL).
>
> To do this filtering, jv needs access to the old and new source trees,
> so it can diff the pertinent source files, so "jv compare" has gained
> the optional arguments
> --old-source-path=
> and
> --new-source-path=
> See the example in the jv Makefile for more info. If they're not
> present, it should work as before (without being able to do the above
> filtering).
Hi,
I am looking at this today and I noticed that having the source file for
all recent GCC revisions is costly in terms of time (if we wish to
compress them) and space (for storage). I was instead thinking that jv
could calculate the differences offline using pysvn and the old and new
revision numbers.
I have started implementing this in my port. Would you consider merging it?
--
Paulo Matos
Re: jamais-vu can now ignore renumbering of source lines in dg output (Re: GCC Buildbot Update)
On Mon, 2018-01-29 at 14:55 +0100, Paulo Matos wrote:
>
> On 24/01/18 20:20, David Malcolm wrote:
> >
> > I've added a new feature to jamais-vu (as of
> > 77849e2809ca9a049d5683571e27ebe190977fa8): it can now ignore test
> > results that merely changed line number.
> >
> > For example, if the old .sum file has a:
> >
> > PASS: g++.dg/diagnostic/param-type-mismatch.C -
> > std=gnu++11 (test for errors, line 106)
> >
> > and the new .sum file has a:
> >
> > PASS: g++.dg/diagnostic/param-type-mismatch.C -
> > std=gnu++11 (test for errors, line 103)
> >
> > and diffing the source trees reveals that line 106 became line 103,
> > the
> > change won't be reported by "jv compare".
> >
> > It also does it for dg-{begin|end}-multiline-output.
> >
> > It will report them if the outcome changed (e.g. from PASS to
> > FAIL).
> >
> > To do this filtering, jv needs access to the old and new source
> > trees,
> > so it can diff the pertinent source files, so "jv compare" has
> > gained
> > the optional arguments
> > --old-source-path=
> > and
> > --new-source-path=
> > See the example in the jv Makefile for more info. If they're not
> > present, it should work as before (without being able to do the
> > above
> > filtering).
>
>
> Hi,
>
> I am looking at this today and I noticed that having the source file
> for
> all recent GCC revisions is costly in terms of time (if we wish to
> compress them) and space (for storage). I was instead thinking that
> jv
> could calculate the differences offline using pysvn and the old and
> new
> revision numbers.
Note that access to the source files is optional - jv doesn't need
them, it just helps for the particular situation described above.
> I have started implementing this in my port. Would you consider
> merging it?
Sounds reasonable - though bear in mind that gcc might be switching to
git at some point.
Send a pull request (I've turned on travis CI on the github repository,
so pull requests now automatically get tested on a bunch of different
Python 3 versions).
Thanks
Dave
Re: jamais-vu can now ignore renumbering of source lines in dg output (Re: GCC Buildbot Update)
On 29/01/18 15:19, David Malcolm wrote: >> >> Hi, >> >> I am looking at this today and I noticed that having the source file >> for >> all recent GCC revisions is costly in terms of time (if we wish to >> compress them) and space (for storage). I was instead thinking that >> jv >> could calculate the differences offline using pysvn and the old and >> new >> revision numbers. > > Note that access to the source files is optional - jv doesn't need > them, it just helps for the particular situation described above. > I understand but it would be great to have line number filtering. >> I have started implementing this in my port. Would you consider >> merging it? > > Sounds reasonable - though bear in mind that gcc might be switching to > git at some point. > Yes, I know... but... if we wait for that to happen to implement something... :) > Send a pull request (I've turned on travis CI on the github repository, > so pull requests now automatically get tested on a bunch of different > Python 3 versions). > Sure. -- Paulo Matos
Re: gcc generated memcpy calls symbol version
Tom Mason writes: > Is there any way for me to force the version for these symbols aswell? It seems pointless because the ABI for these symbols will never change. -Andi
Mac now fails to build because of libiconv
It's been a few months since I tried to build GCC on my Mac, and in earlier tries it worked fine. I have a log from 20-Sep-2017 that shows success. But currently when I do the same configs as before, I get failures about _iconv being undefined. This is in spite of the fact that I have libiconv installed, and just to be sure, told configure where to find it (--with-libiconv=/usr/local) g++-g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -Wl,-no_pie -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-fold.o c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o default-c.o \ cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -lmpc -lmpfr -lgmp -L./../zlib -lz Undefined symbols for architecture x86_64: "_iconv", referenced from: convert_using_iconv(void*, unsigned char const*, unsigned long, _cpp_strbuf*) in libcpp.a(charset.o) __nl_find_msg in libintl.a(dcigettext.o) (maybe you meant: __Z14cpp_init_iconvP10cpp_reader, __cpp_destroy_iconv ) "_iconv_close", referenced from: __cpp_destroy_iconv in libcpp.a(charset.o) __cpp_convert_input in libcpp.a(charset.o) __nl_free_domain_conv in libintl.a(loadmsgcat.o) "_iconv_open", referenced from: init_iconv_desc(cpp_reader*, char const*, char const*) in libcpp.a(charset.o) __nl_init_domain_conv in libintl.a(loadmsgcat.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Not only that, but if I configure --without-libiconv, I get the exact same error, i.e., that configure switch has no effect. Any suggestions? paul
