On Thu, 22 Nov 2018 at 14:09, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote: > > Hi Christophe, > > > On Sat, 10 Nov 2018 at 00:43, Martin Sebor <mse...@gmail.com> wrote: > >> > >> On 11/09/2018 12:59 PM, Jeff Law wrote: > >> > On 10/31/18 10:27 AM, Martin Sebor wrote: > >> >> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01473.html > >> >> > >> >> With the C++ bits approved I'm still looking for a review/approval > >> >> of the remaining changes: the C front end and the shared c-family > >> >> handling of the new built-in. > >> > I thought I acked those with just a couple minor doc nits: > >> > >> I don't see a formal approval for the rest in my Inbox or in > >> the archive. > >> > >> >> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > >> >> index 8ffb0cd..dcf4747 100644 > >> >> --- a/gcc/doc/extend.texi > >> >> +++ b/gcc/doc/extend.texi > >> >> @@ -2649,8 +2649,9 @@ explicit @code{externally_visible} attributes > >> > are still necessary. > >> >> @cindex @code{flatten} function attribute > >> >> Generally, inlining into a function is limited. For a function > >> > marked with > >> >> this attribute, every call inside this function is inlined, if > >> >> possible. > >> >> -Whether the function itself is considered for inlining depends on its > >> > size and > >> >> -the current inlining parameters. > >> >> +Functions declared with attribute @code{noinline} and similar are not > >> >> +inlined. Whether the function itself is considered for inlining > >> >> depends > >> >> +on its size and the current inlining parameters. > >> > Guessing this was from another doc patch that I think has already been > >> > approved > >> > >> Yes. It shouldn't be in the latest patch at the link above. > >> > >> >> @@ -11726,6 +11728,33 @@ check its compatibility with @var{size}. > >> >> > >> >> @end deftypefn > >> >> > >> >> +@deftypefn {Built-in Function} bool __builtin_has_attribute > >> > (@var{type-or-expression}, @var{attribute}) > >> >> +The @code{__builtin_has_attribute} function evaluates to an integer > >> > constant > >> >> +expression equal to @code{true} if the symbol or type referenced by > >> >> +the @var{type-or-expression} argument has been declared with > >> >> +the @var{attribute} referenced by the second argument. Neither > >> >> argument > >> >> +is valuated. The @var{type-or-expression} argument is subject to the > >> > same > >> > s/valuated/evaluated/ ? > >> > >> This should also be fixed in the latest patch at the link above. > >> > >> > Did the implementation change significantly requiring another review > >> > iteration? > >> > >> I don't think it changed too significantly between the last two > >> revisions but I don't have a record of anyone having approved > >> the C FE and the middle-end bits. (Sorry if I missed it.) Other > >> than this response from you all I see in the archive is this: > >> > >> https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00606.html > >> > >> Please let me if the last revision is okay to commit. > >> > > > > Hi, > > > > It seems you committed this yesterday as r266335, and I have noticed > > new failures: > > on both aarch64 and arm: > > FAIL: c-c++-common/builtin-has-attribute-3.c -Wc++-compat (test for > > excess errors) > > > > gcc.log says: > > Excess errors: > > /gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:11:25: error: > > alignment for 'faligned_1' must be at least 4 > > /gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:12:25: error: > > alignment for 'faligned_2' must be at least 4 > > /gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:39:3: error: > > alignment for '__builtin_has_attribute_tmp.' must be at least 4 > > /gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:40:3: error: > > alignment for '__builtin_has_attribute_tmp.' must be at least 4 > > /gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:47:3: error: > > alignment for '__builtin_has_attribute_tmp.' must be at least 4 > > /gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:48:3: error: > > alignment for '__builtin_has_attribute_tmp.' must be at least 4 > > /gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:50:3: error: > > size of array 'Assert' is negative > > /gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:52:3: error: > > alignment for '__builtin_has_attribute_tmp.' must be at least 4 > > /gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:52:3: error: > > size of array 'Assert' is negative > > /gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:53:3: error: > > alignment for '__builtin_has_attribute_tmp.' must be at least 4 > > /gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:56:3: error: > > size of array 'Assert' is negative > > /gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:58:3: error: > > alignment for '__builtin_has_attribute_tmp.' must be at least 4 > > /gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:59:3: error: > > alignment for '__builtin_has_attribute_tmp.' must be at least 4 > > /gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:59:3: error: > > size of array 'Assert' is negative > > > > on arm only: > > gcc.dg/builtin-has-attribute.c (test for excess errors) > > gdb.log says: > > Excess errors: > > /gcc/testsuite/gcc.dg/builtin-has-attribute.c:12:15: error: size of > > array 'Assert' is negative > > I'm seeing the same on sparc-sun-solaris2.11, plus > > +FAIL: c-c++-common/builtin-has-attribute-3.c -std=gnu++14 (test for excess > errors) > +FAIL: c-c++-common/builtin-has-attribute-3.c -std=gnu++17 (test for excess > errors) > +FAIL: c-c++-common/builtin-has-attribute-3.c -std=gnu++98 (test for excess > errors) >
Right, me too. As I split reports in one column for gcc, one for g++, one for libstdc++ and one for gfortran, I forgot to report the g++ regressions. Thanks > According to gcc-testresults postings, several other targets are also > affected: > > aarch64-unknown-linux-gnu > armv8l-unknown-linux-gnueabihf > m68k-unknown-linux-gnu > mips64el-unknown-linux-gnu > moxie-unknown-elf > powerpc64-unknown-linux-gnu > powerpc64le-unknown-linux-gnu > > Rainer > > -- > ----------------------------------------------------------------------------- > Rainer Orth, Center for Biotechnology, Bielefeld University
