Re: Unused GCC builtins
Thank you for all answers, which are very useful for us! As you pointed out, we only considered GitHub projects. If I understood correctly, builtins would still not be deprecated even if we considered all other open-source hosting sites because closed-source projects could still rely on them, right? Additionally, target-specific builtins could not be deprecated or removed because of vendor ABIs. Several of you noted that we did not consider internal builtins that are used in the implementation of GCC headers or directly by the compiler. Also the documentation mentions that GCC provides "a large number of built-in functions other than the ones mentioned" for "internal use" which "are not documented here because they may change from time to time" (see https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Other-Builtins.html#Other- Builtins). We deliberately looked only at public builtins (and not internal ones), as we are mainly interested in the effort needed to support GCC builtins in other tools that process C code (e.g., other compilers or analysis tools). We want to prevent that such tool developers need to implement internal or unused builtins. So even if we cannot remove the implementation of a builtin, removing it from the documentation could already be a win. In a second step, we also considered internal builtins and found that the vararg handling builtins (__builtin_va_start, __builtin_va_end, __builtin_va_arg, and __builtin_va_copy) are relied upon by many projects, even though they are undocumented in GCC's builtins API. Could they be added to the documentation? Thanks, Manuel 2018-01-22 19:29 GMT+01:00 Florian Weimer : > * Manuel Rigger: > > > Details: We downloaded all C projects from GitHub that had more than 80 > > GitHub stars, which yielded almost 5,000 projects with a total of more > > than one billion lines of C code. We filtered GCC, forks of GCC, and > > other compilers as we did not want to incorporate internal usages of GCC > > builtins or test cases. We extracted all builtin names from the GCC > > docs, and also tried to find such names in the source code, which we > > considered as builtin usages. > > You actually need to compile the sources with an instrumented compiler > to discover uses of built-ins. Not all references will have verbatim, > textual references in source code, but their names are constructed > using preprocessor macros. This happens for the majority of the > floating-point-related built-ins you listed, I think. >
Re: Unused GCC builtins
On Wed, Jan 24, 2018 at 03:04:55PM +0100, Manuel Rigger wrote: > In a second step, we also considered internal builtins and found that the > vararg handling builtins (__builtin_va_start, __builtin_va_end, > __builtin_va_arg, and __builtin_va_copy) are relied upon by many projects, > even though they are undocumented in GCC's builtins API. Could they be > added to the documentation? Why? What is documented is va_start/va_end/va_arg/va_copy, that is what people should use, the builtins are just internal implementation of those macros. Jakub
Re: Unused GCC builtins
* Jakub Jelinek: > On Wed, Jan 24, 2018 at 03:04:55PM +0100, Manuel Rigger wrote: >> In a second step, we also considered internal builtins and found that the >> vararg handling builtins (__builtin_va_start, __builtin_va_end, >> __builtin_va_arg, and __builtin_va_copy) are relied upon by many projects, >> even though they are undocumented in GCC's builtins API. Could they be >> added to the documentation? > > Why? What is documented is va_start/va_end/va_arg/va_copy, that is > what people should use, the builtins are just internal implementation of > those macros. And these builtins differ from the math builtins because is provided by GCC, but is not, and there are many different implementations.
jamais-vu can now ignore renumbering of source lines in dg output (Re: GCC Buildbot Update)
On Sat, 2017-12-16 at 12:06 +0100, Paulo Matos wrote:
>
> On 15/12/17 15:29, David Malcolm wrote:
> > On Fri, 2017-12-15 at 10:16 +0100, Paulo Matos wrote:
> > >
> > > On 14/12/17 12:39, David Malcolm wrote:
> >
> > [...]
> >
> > > > It looks like you're capturing the textual output from "jv
> > > > compare"
> > > > and
> > > > using the exit code. Would you prefer to import "jv" as a
> > > > python
> > > > module and use some kind of API? Or a different output format?
> > > >
> > >
> > > Well, I am using a fork of it which I converted to Python3. Would
> > > you
> > > be
> > > open to convert yours to Python3? The reason I am doing this is
> > > because
> > > all other Python software I have and the buildbot use Python3.
> >
> > Done.
> >
> > I found and fixed some more bugs, also (introduced during my
> > refactoring, sigh...)
> >
>
> That's great. Thank you very much for this work.
>
> > > I would also prefer to have some json format or something but
> > > when I
> > > looked at it, the software was just printing to stdout and I
> > > didn't
> > > want
> > > to spend too much time implementing it, so I thought parsing the
> > > output
> > > was just easier.
> >
> > I can add JSON output (or whatever), but I need to get back to gcc
> > 8
> > work, so if the stdout output is good enough for now, let's defer
> > output changes.
> >
>
> Agree, for now I can use what I already have to read the output of
> jv.
> I think I can now delete my fork and just use upstream jv as a
> submodule.
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).
Is this something that the buildbot can use?
Dave
nonsense warning from texinfo while processing intrinsic.texi
I added some documentation to fortran/intrinsic.texi. In processing the gfortran.f90, I discovered this warning. makeinfo --split-size=500 --split-size=500 --split-size=500 \ -I ../../gcc/gcc/doc/include -I ../../gcc/gcc/fortran \ -o doc/gfortran.info ../../gcc/gcc/fortran/gfortran.texi; \ else true; fi ../../gcc/gcc/fortran/gfortran.texi:2701: warning: @ref node name should not contain `:' Line 2701 is @fnindex DBESYN not only is there no ':', there is no @ref. What to do? -- Steve
Re: Different dynamical array debug info 7.2 vs. 8.0
On Tue, Jan 23, 2018 at 4:02 PM, Yao Qi wrote: > > Hi, > I observed that gfortran 7.2 and 8.0 generate different debug info for > dynamical array. > Attributes DW_AT_data_location and DW_AT_allocated are different. There > is an extra "DW_OP_plus_uconst: 8" generated by gcc 8.0. Is it > intended or expected? gfortran 8.0 causes many gdb.fotran vla-related > tests fail, but gfortran 7.2 doesn't. That is why I took a look at the > debug information. > I did 'git bisect', and find the following commit causes the change in the debug information. Paul, do you have any clue on the different debug information caused by your commit? commit c0dbf68e8b1cf24bd54de0c3b6ec056436f174ac Author: pault Date: Sun Sep 10 17:02:53 2017 + 2017-09-10 Paul Thomas PR fortran/34640 PR fortran/40737 PR fortran/55763 PR fortran/57019 PR fortran/57116 * expr.c (is_subref_array): Add class pointer array dummies to the list of expressions that return true. * trans-array.c: Add SPAN_FIELD and update indices for subsequent fields. (gfc_conv_descriptor_span, gfc_conv_descriptor_span_get, gfc_conv_descriptor_span_set, is_pointer_array, get_array_span): New functions. (gfc_get_descriptor_offsets_for_info): New function to preserve API for access to descriptor fields for trans-types.c. (gfc_conv_scalarized_array_ref): If the expression is a subref array, make sure that info->descriptor is a descriptor type. Otherwise, if info->descriptor is a pointer array, set 'decl' and fix it if it is a component reference. (build_array_ref): Simplify handling of class array refs by passing the vptr to gfc_build_array_ref rather than generating the pointer arithmetic in this function. (gfc_conv_array_ref): As in gfc_conv_scalarized_array_ref, set 'decl'. (gfc_array_allocate): Set the span field if this is a pointer array. Use the expr3 element size if it is available, so that the dynamic type element size is used. (gfc_conv_expr_descriptor): Set the span field for pointer assignments. -- Yao (齐尧)
gcc-6-20180124 is now available
Snapshot gcc-6-20180124 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180124/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 257031 You'll find: gcc-6-20180124.tar.xzComplete GCC SHA256=0529abb627054729cc1211a9e60aa5249d5219188d071d42e60b1b2ac2be9630 SHA1=fc72ba6c576d67fa0d1423801c4e9f8641d7baf2 Diffs from 6-20180117 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
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).
>
> Is this something that the buildbot can use?
>
Hi David,
Thanks for the amazing improvements.
I will take a look at them on Monday. I have a lot of work at the moment
so I decided to take 1/5 of my week (usually Monday) to work on buildbot
so I will definitely get it integrated on Monday and hopefully have
something to say afterwards.
Thanks for keeping me up-to-date with these changes.
--
Paulo Matos
