Re: Couldn't `function(arg[static 3])` imply nonnull and array size in C?
On 7 May 2015 at 19:51, Martin Uecker wrote: > Am Mon, 04 May 2015 18:28:49 +0200 > schrieb Manuel López-Ibáñez : > >> On 04/05/15 07:40, Martin Uecker wrote: >> > >> > BTW: Why is 'nonnull' a function attribute and not something >> > which can be attached to pointer types? >> >> I think this is something wanted for a long time: >> >> https://gcc.gnu.org/ml/gcc/2006-04/msg00550.html >> >> but nobody has implemented it yet. Perhaps there was some technical hurdle in >> the past, probably long gone. >> >> Clang has implemented this variation already sometime ago: >> >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140203/098497.html >> >> so there is a precedent. > > Interestingly, this leads to an incompatibility between gcc and > clang. Consider this: > > void foo(__attribute__((nonnull)) int *a) Good catch! Perhaps this applies? "At present, the first parameter in a function prototype must have some type specifier that is not an attribute specifier; this resolves an ambiguity in the interpretation of void f(int (__attribute__((foo)) x))" https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax But I don't understand the example given in the docs. In any case, what would be the syntax (in Clang) for specifying that '*a' is a nonnull function? Clang also implements the gnu-style nonnull attribute, hence they probably have some incompatibility with previous versions of itself (the new syntax is only one year old). In general, my impression (Jason, Joseph, please correct me if I'm wrong here) is that it is ok to accept attributes in a place that was ignored previously, and to ignore attributes if the placement was working by luck and not documented (hopefully with a warning, which we are missing above?), but it is definitely not ok to ignore attributes that were documented to work before. It is definitely a goal to make the placement consistent between C and C++ and to satisfy the rules of C++ as to where the attributes can appear (but being permissive as to where they cannot appear). Thus, any testcases that you add should go to testsuite/c-c++-common unless they are testing C-only or C++-only syntax. Cheers, Manuel.
Re: Merging debug-early work?
On Thu, May 7, 2015 at 5:29 PM, Aldy Hernandez wrote: > On 05/06/2015 04:22 AM, Richard Biener wrote: >> >> On Wed, May 6, 2015 at 12:33 AM, Aldy Hernandez wrote: >>> >>> Gentlemen! >>> >>> I believe I have done as much as is reasonable for a merge, but I'd like >>> to >>> get your opinion before I post a huge patch to the list. >>> >>> The branch bootstraps with one regression in GCC >>> (gcc.dg/debug/dwarf2/stacked-qualified-types-3.c) and none for GDB. >> >> >> On which triplets? > > > x86_64-unknown-linux-gnu > powerpc-ibm-aix7.1.2.0 > powerpc64-unknown-linux-gnu > aarch64-unknown-linux-gnu > > So, two non x86 targets, and one non-x86 target that is also non-dwarf. Two > primary targets and two secondary targets. For the record, the gdb > testsuite was only run on x86_64-linux, everything else was just the usual > GCC testing. Did you see if --with-build-config=bootstrap-lto still works? >> >>> The GCC regression is a missed optimization while merging the common >>> denominator of a set of qualifiers for a type within a DIE. For example, >>> if >>> two types share "const volatile" (say "const volatile int" and "const >>> volatile char"), dwarf2out outputs things in the most efficient manner as >>> to >>> share the maximum common type DIEs. This is not working in the branch as >>> TYPE_MAIN_VARIANTs are not complete by the time early dwarf is run. If >>> it >>> is possible, I'd like to work on this one regression post-merge. Not a >>> big >>> deal if you disagree, but I'd prefer to postpone on this non crucial bit. >>> >>> A few caveats... >>> >>> Richi wants to play around with free-lang-data in the non LTO path. I >>> haven't not done so, and it's left as an exercise to the reader :). >> >> >> Yeah - I'd also like the early/late paths in dwarf2out.c to be refactored >> to completely different functions (that is, not have a single function >> creating and/or annotating DIEs early and late but two - with the late >> one only doing the annotation work and only annotating with stuff >> we expect). The branch already has accumulated quite some checks >> like "if DIE was created early..." and with the LTO prototype work I saw >> I'd only need to add (very?) much more of those. > > > That would be very much appreciated. It is something I realized a bit too > late. Yeah. The nice thing is that we already have an entry for the most sophisticated part - the function_decl debug-hook called from the appropriate place in final.c for functions we have output. Of course that simply maps to dwarf2out_decl right now, but it's a good start to prune stuff here by "inlining" stuff here an pruning obviously unnecessary (and harmful) stuff. What we are missing is a corresponding hook (well, that could be just late_gobal_decl ...) for global vars we output, called from the approriate place in varasm.c (assemble_variable? called from varpool assemble_decl via symtab output_variables). At least hook-wise that would be the clean solution for the late dwarf stage. While doing the LTO work I wondered why you have the late_global_decl loop in toplev.c:compile_file at all (well, maybe due to the missing one for global vars output). At least for function decls we should have covered everything by that point. Early debug seems to be enforced at finalize-compilation-unit time, but only for function decls - I wonder why not as well for global vars (and why the odd !decl_function_context check is there for functions). That said, this and the code in rest_of_decl_compilation should best be merged to a single place (preferably rest_of_decl_compilation). >>> Thoughts on moving forward? Is the stacked qualifier regression a show >>> stopper? Is the .debug_info size regression acceptable? >> >> >> I think both are acceptable if they are fixed in a reasonable time frame >> (before stage1 ends). So I suggest to go forward with merging and send >> a nice patch-set. > > > Great. Coming up... Thanks. Richard. > Aldy
Re: AutoFDO profile toolchain is open-sourced
On 11.04.2015 01:49, Xinliang David Li wrote: On Fri, Apr 10, 2015 at 3:43 PM, Jan Hubicka wrote: LBR is used for both cfg edge profiling and indirect call Target value profiling. I see, that makes sense ;) I guess if we want to support profile collection on targets w/o this feature we could still use one of the algorithms that try to guess edge profile from BB profile. Our experience with sampling cycles or retired instructions to guess BB profile has not been great -- the profile quality is significantly worse than LBR (which can almost match instrumentation based profile). Suppose that I have no opportunity to collect profile on x86 architecture with LBR support and the only available architecture is arm/aarch64 (since the application code is significantly different when compiled for different architectures because of manual optimizations and different function names and structure). Honza has mentioned that it's possible to guess edge profile from BB profile. How do you think, can this help in the above described situation? Yes, this will be much worse than LBR, but can it give any performance benefit compared with no edge profile at all? -- Ilya
Re: Change to C++11 by default?
On Thursday 07 May 2015, Jason Merrill wrote: > I think it's time to switch to C++11 as the default C++ dialect for GCC > 6. Any thoughts? > Would it be unrealistic to make C++14 the default? With it being an fixup of C++11, I would guess it could have longer staying power as the default. `Allan
Re: Couldn't `function(arg[static 3])` imply nonnull and array size in C?
On Fri, 8 May 2015, Manuel López-Ibáñez wrote: > "At present, the first parameter in a function prototype must have > some type specifier that is not an attribute specifier; this resolves > an ambiguity in the interpretation of void f(int (__attribute__((foo)) > x))" > https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax > > But I don't understand the example given in the docs. This means that this example is interpreted as void f(int __attribute__((foo)) x); and not void f(int (*)(int __attribute__((foo)) x)); (with implicit int and adjustment of a parameter declared with function type to have pointer to function type), which would be a valid parse if you only consider the syntax productions without the above disambiguation. Cf C11 6.7.6.3#11 "If, in a parameter declaration, an identifier can be treated either as a typedef name or as a parameter name, it shall be taken as a typedef name." (disambiguating cases such as "void f(int (T))" where T is a typedef name). And some other cases in C90 that became irrelevant in C99 with the removal of implicit int. -- Joseph S. Myers jos...@codesourcery.com
Re: Change to C++11 by default?
2015-05-07 20:46 GMT+02:00 Jason Merrill : > I think it's time to switch to C++11 as the default C++ dialect for GCC 6. > Any thoughts? Does it mean that gcc 6 will have an official support for C++11, instead of experimental as gcc 5 has now (See C++ section inhttps://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Standards.html#Standards)? As others in the thread noted - C++ 14 maybe should be considered as default dialect provided that it will also have a official support instead of experimental by the time gcc 6 is released. > > Jason
Re: AutoFDO profile toolchain is open-sourced
On Fri, May 8, 2015 at 2:00 AM, Ilya Palachev wrote: > On 11.04.2015 01:49, Xinliang David Li wrote: >> >> On Fri, Apr 10, 2015 at 3:43 PM, Jan Hubicka wrote: LBR is used for both cfg edge profiling and indirect call Target value profiling. >>> >>> I see, that makes sense ;) I guess if we want to support profile >>> collection >>> on targets w/o this feature we could still use one of the algorithms that >>> try to guess edge profile from BB profile. >> >> Our experience with sampling cycles or retired instructions to guess >> BB profile has not been great -- the profile quality is significantly >> worse than LBR (which can almost match instrumentation based profile). > > Suppose that I have no opportunity to collect profile on x86 architecture > with LBR support and the only available architecture is arm/aarch64 (since > the application code is significantly different when compiled for different > architectures because of manual optimizations and different function names > and structure). If it's already manually tuned towards architecture (or even hand-written inlined-assembly), then I don't think FDO/AutoFDO can help much. > > Honza has mentioned that it's possible to guess edge profile from BB > profile. How do you think, can this help in the above described situation? > Yes, this will be much worse than LBR, but can it give any performance > benefit compared with no edge profile at all? Yes, it will. But it's not well tuned at all. I will start tuning it if I have free cycles. It would be great if opensource community can also contribute to this tuning effort. Cheers, Dehao > > -- > Ilya
nonnull attribute (was: Re: Couldn't `function(arg[static 3])` imply nonnull and array size in C?)
Am Fri, 8 May 2015 11:04:22 +
Joseph Myers :
> On Fri, 8 May 2015, Manuel López-Ibáñez wrote:
>
> > "At present, the first parameter in a function prototype must have
> > some type specifier that is not an attribute specifier; this resolves
> > an ambiguity in the interpretation of void f(int (__attribute__((foo))
> > x))"
> > https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax
> >
> > But I don't understand the example given in the docs.
>
> This means that this example is interpreted as
>
> void f(int __attribute__((foo)) x);
>
> and not
>
> void f(int (*)(int __attribute__((foo)) x));
>
> (with implicit int and adjustment of a parameter declared with function
> type to have pointer to function type), which would be a valid parse if
> you only consider the syntax productions without the above disambiguation.
So this is merely a syntax issue unrelated to the original problem:
void foo(__attribute__((nonnull)) int *a) { }
void bar(__attribute__((nonnull)) int (*a)(int*)) { (*a)(0); }
where the first works with clang but not with gcc (which gives
a warning) and the latter applies the attribute to the parameter
with clang, but to the pointed-to function with gcc. For clang,
to get nonnull to apply to the pointed-to function, one has to
put it into the parameter list of the pointed-to function.
So more relevant seems this quote:
"Where an attribute specifier is applied to a parameter declared as a
function or an array, it should apply to the function or array rather
than the pointer to which the parameter is implicitly converted, but
this is not yet correctly implemented."
Which may suggest that if the parameter is *not* declared as a function
or an array, it is supposed to apply to the parameter itself instead...
But then there is also:
"For compatibility with existing code
If an attribute that only applies to function types is applied to a
pointer-to-function type, it is treated as applying to the pointer
target type; "
Which I guess applies here.
So without breaking the existing behaviour of nonnull, we cannot make
this work... We could add an entirely new attribute (e.g. nonzero)
which is not a function attribute? Or just implement 'static', but this
does not work for C++.
From reading the documentation, it seems that attributes originally
were supposed to only go with declarations and were not meant to be a
general extension to the type system. But then there is the example:
char *__attribute__((aligned(8))) *f;
which implies that now (some) attributes could work similar to type
qualifiers. Is this the idea?
Martin
Re: nonnull attribute (was: Re: Couldn't `function(arg[static 3])` imply nonnull and array size in C?)
On Fri, 8 May 2015, Martin Uecker wrote: > From reading the documentation, it seems that attributes originally > were supposed to only go with declarations and were not meant to be a > general extension to the type system. But then there is the example: > > char *__attribute__((aligned(8))) *f; > > which implies that now (some) attributes could work similar to type > qualifiers. Is this the idea? Yes (keeping in mind that many type attributes can only apply to a limited subset of types - if the attribute is only meaningful for structures or unions, for example, the syntactic binding inside nested declarators is fairly irrelevant to it). Make sure to distinguish the binding of GNU attributes (as defined in the manual) and the binding of C++11 attributes (as defined in C++11). -- Joseph S. Myers jos...@codesourcery.com
RE: AutoFDO profile toolchain is open-sourced
> Date: Fri, 8 May 2015 11:19:12 -0700 > Subject: Re: AutoFDO profile toolchain is open-sourced > From: de...@google.com > To: i.palac...@samsung.com > CC: davi...@google.com; hubi...@ucw.cz; gcc@gcc.gnu.org; > v.bari...@samsung.com; dnovi...@google.com; seb...@gmail.com > > On Fri, May 8, 2015 at 2:00 AM, Ilya Palachev wrote: >> On 11.04.2015 01:49, Xinliang David Li wrote: >>> >>> On Fri, Apr 10, 2015 at 3:43 PM, Jan Hubicka wrote: > > LBR is used for both cfg edge profiling and indirect call Target value > profiling. I see, that makes sense ;) I guess if we want to support profile collection on targets w/o this feature we could still use one of the algorithms that try to guess edge profile from BB profile. >>> >>> Our experience with sampling cycles or retired instructions to guess >>> BB profile has not been great -- the profile quality is significantly >>> worse than LBR (which can almost match instrumentation based profile). >> >> Suppose that I have no opportunity to collect profile on x86 architecture >> with LBR support and the only available architecture is arm/aarch64 (since >> the application code is significantly different when compiled for different >> architectures because of manual optimizations and different function names >> and structure). > > If it's already manually tuned towards architecture (or even > hand-written inlined-assembly), then I don't think FDO/AutoFDO can > help much. > >> >> Honza has mentioned that it's possible to guess edge profile from BB >> profile. How do you think, can this help in the above described situation? >> Yes, this will be much worse than LBR, but can it give any performance >> benefit compared with no edge profile at all? > > Yes, it will. But it's not well tuned at all. I will start tuning it > if I have free cycles. It would be great if opensource community can > also contribute to this tuning effort. If you could outline portions of code which needs tuning, rewriting, that will help get started in this effort. Thanks, -Aditya > > Cheers, > Dehao > >> >> -- >> Ilya
