Re: [PATCH] Fix ms_struct/-mms-bitfields structure layout (PR target/52991)

[Kai Tietz]

Hello Jakub,

I can't approve this patch, but I can confirm that changes are
sensible.  I verified the structure layout - as far as possible - also
with MS' compiler, and can confirm the adjustments.

Cheers,
Ka

2018-02-28 1:26 GMT+01:00 Jakub Jelinek :
> Hi!
>
> The following patch fixes the reported ms_struct/-mms-bitfields structure
> layout issues from PR52991.
>
> There are multiple issues, two of them introduced by the
> https://gcc.gnu.org/ml/gcc-patches/2006-04/msg01064.html -mms-bitfields
> revamp from Eric and follow-up fix r114552, the rest has been introduced
> later when the known_align < desired_align case has been enabled for the ms
> bitfield layout.
>
> The first 2 hunks fix alignment of packed non-bitfield fields, we can't
> ignore all the alignment updates for them, just should use only
> desired_align which takes DECL_PACKED into account, rather than
> MAX (type_align, desired_align).  Similarly, the last hunk in stor-layout.c
> makes sure that for DECL_PACKED fields we use BITS_PER_UNIT alignment rather
> than the type alignment.
>
> The rest attempts to unbreak r184409 which enabled known_align < desired_align
> case; doing that if rli->prev_field and ms layout is wrong, we first need to
> deal with the bitfield packing and if we are within a bitfield word, we
> shouldn't do any realignment, only in between them.
>
> The patch reverts changes to bf-ms-layout{,-2}.c tests done in 2012, which
> were done just to match the r184409 changes, and adds 2 new tests.  All of
> these 4 I've tested (slightly tweaked, so that it compiles with VC) with
> the online VC compiler http://rextester.com/l/c_online_compiler_visual .
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-02-27  Jakub Jelinek  
>
> PR target/52991
> * stor-layout.c (update_alignment_for_field): For
> targetm.ms_bitfield_layout_p (rli->t), if !is_bitfield
> && !DECL_PACKED (field), do the alignment update, just use
> only desired_align instead of MAX (type_align, desired_align)
> as the alignment.
> (place_field): Don't do known_align < desired_align handling
> early if targetm.ms_bitfield_layout_p (rli->t) and rli->prev_field
> is non-NULL, instead do it after rli->prev_field handling and
> only if not within a bitfield word.  For DECL_PACKED (field)
> use type_align of BITS_PER_UNIT.
>
> * gcc.dg/bf-ms-layout.c: Revert 2012-04-26 changes.
> * gcc.dg/bf-ms-layout-2.c: Revert 2012-02-23 changes.
> * gcc.dg/bf-ms-layout-4.c: New test.
> * gcc.dg/bf-ms-layout-5.c: New test.
>
> --- gcc/stor-layout.c.jj2018-02-22 14:35:33.135216198 +0100
> +++ gcc/stor-layout.c   2018-02-27 18:56:26.906494801 +0100
> @@ -1038,7 +1038,7 @@ update_alignment_for_field (record_layou
>  the type, except that for zero-size bitfields this only
>  applies if there was an immediately prior, nonzero-size
>  bitfield.  (That's the way it is, experimentally.) */
> -  if ((!is_bitfield && !DECL_PACKED (field))
> +  if (!is_bitfield
>   || ((DECL_SIZE (field) == NULL_TREE
>|| !integer_zerop (DECL_SIZE (field)))
>   ? !DECL_PACKED (field)
> @@ -1047,7 +1047,10 @@ update_alignment_for_field (record_layou
>  && ! integer_zerop (DECL_SIZE (rli->prev_field)
> {
>   unsigned int type_align = TYPE_ALIGN (type);
> - type_align = MAX (type_align, desired_align);
> + if (!is_bitfield && DECL_PACKED (field))
> +   type_align = desired_align;
> + else
> +   type_align = MAX (type_align, desired_align);
>   if (maximum_field_alignment != 0)
> type_align = MIN (type_align, maximum_field_alignment);
>   rli->record_align = MAX (rli->record_align, type_align);
> @@ -1303,7 +1306,9 @@ place_field (record_layout_info rli, tre
>
>/* Does this field automatically have alignment it needs by virtue
>   of the fields that precede it and the record's own alignment?  */
> -  if (known_align < desired_align)
> +  if (known_align < desired_align
> +  && (! targetm.ms_bitfield_layout_p (rli->t)
> + || rli->prev_field == NULL))
>  {
>/* No, we need to skip space before this field.
>  Bump the cumulative size to multiple of field alignment.  */
> @@ -1331,8 +1336,6 @@ place_field (record_layout_info rli, tre
>
>if (! TREE_CONSTANT (rli->offset))
> rli->offset_align = desired_align;
> -  if (targetm.ms_bitfield_layout_p (rli->t))
> -   rli->prev_field = NULL;
>  }
>
>/* Handle compatibility with PCC.  Note that if the record has any
> @@ -1448,6 +1451,8 @@ place_field (record_layout_info rli, tre
>/* This is a bitfield if it exists.  */
>if (rli->prev_field)
> {
> + bool realign_p = known_align < desired_align;
> +
>   /* If both are bitfields, nonzero, an

[Patch] test_summary: handle single quotes

[Christophe Lyon]

Hi,

We happen to build GCC with '~' in the src and build dirs, leading to
single quotes around the configure path in config.status. For example:
[...]
S["TOPLEVEL_CONFIGURE_ARGUMENTS"]="'/home/christophe.lyon/src/Linaro/abe/abe-contrib-summary/mybuild/snapshots/gcc.git~linaro~gcc-7-branch/configure'
SHELL=/bin/bash --with-mpc=/home/"\
[...]

This confuses contrib/test_summary which matches "/configure .* in its
awk script, which fails to match when we have "/configure' XXX"
instead.

This patch fixes that by adding matches for the optional single
quotes. I use \047 to match the ascii "'", because I couldn't find how
to quote this properly in the awk script.

OK for trunk?

Thanks,

Christophe
contrib/ChangeLog:

2018-02-28  Christophe Lyon  

* test_summary: Match possible single quotes in configure path.

diff --git a/contrib/test_summary b/contrib/test_summary
index 5fc49f5..3560a64 100755
--- a/contrib/test_summary
+++ b/contrib/test_summary
@@ -103,14 +103,15 @@ BEGIN {
 NR == 1 {
 configflags = $0 " ";
 srcdir = configflags;
-sub(/\/configure .*/, "", srcdir);
+sub(/\/configure\047? .*/, "", srcdir);
+sub(/^\047/, "", srcdir);
 if ( system("test -f " srcdir "/LAST_UPDATED") == 0 ) {
 printf "LAST_UPDATED: ";
 system("tail -1 " srcdir "/LAST_UPDATED");
 print "";
 }
 
-sub(/^[^ ]*\/configure */, " ", configflags);
+sub(/^[^ ]*\/configure\047? */, " ", configflags);
 sub(/,;t t $/, " ", configflags);
 sub(/ --with-gcc-version-trigger=[^ ]* /, " ", configflags);
 sub(/ --norecursion /, " ", configflags);

Re: PING: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER

[Steve Beattie]

Hi Jeff,

On Thu, Feb 22, 2018 at 10:10:13AM -0700, Jeff Law wrote:
> A few notes.
> 
> 1. It's not even clear at this time that retpolining user space binaries
> makes any sense at all.   SO before doing anything to make this easier
> I'd like to see a justification for why it's really needed.

Do you have a reference that gives evidence that retpolining user
space is not needed or not preferred for x86? Everything that I've
seen has suggested user space to user space attacks are possible,
if difficult. And it does not seem likely that microcode updates will
occur for all processor generations out there.

> 2. On the other hand, the existing thunk options do make it easier to
> test independent of hte kernel.  ie, I can turn on inline thunks by
> default and test things in user space (ie, do thunks generally work
> properly).

If thunk-extern is to be the only maintained option, and its deemed
sensible for user space in at least some situations, is there a
preferred location for the thunks to end up?

(I ask these questions because you can already find individual users
recompiling apps important to them with retpoline options, and there
is pressure (with associated deadlines) in some quarters to rebuild
vast tracts of user space with retpolines for x86.)

Thanks.

-- 
Steve Beattie

http://NxNW.org/~steve/


signature.asc
Description: PGP signature

Re: [PATCH] adjust warning_n() to take uhwi (PR 84207)

[Jakub Jelinek]

On Tue, Feb 27, 2018 at 03:06:53PM -0700, Martin Sebor wrote:
> On 02/22/2018 02:15 PM, Joseph Myers wrote:
> > On Thu, 22 Feb 2018, Martin Sebor wrote:
> > 
> > > Ping: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00858.html
> > > 
> > > This is just a tweak to fix a translation bug introduced by
> > > one of my warnings (calling warning() where warning_n() is
> > > more appropriate), and to enhance warning_n() et al. to do
> > > the n % 100 + 100 computation so callers don't have
> > > to worry about it.
> > 
> > OK in the absence of diagnostic maintainer objections within 48 hours,
> > with the comment saying "ngettext()" changed to remove the "()" (see the
> > GNU Coding Standards: "Please do not write @samp{()} after a function name
> > just to indicate it is a function.  @code{foo ()} is not a function, it is
> > a function call with no arguments.").
> 
> Committed as r258044.

With the above change I can revert the
eltscnt > INT_MAX ? (eltscnt % 100) + 100 : eltscnt
stuff from inform_n call, as it can now accept all UHWI values.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed as obvious.

2018-02-28  Jakub Jelinek  

* decl.c (cp_finish_decomp): Don't adjust eltscnt when calling
inform_n.

--- gcc/cp/decl.c.jj2018-02-26 20:49:54.938331630 +0100
+++ gcc/cp/decl.c   2018-02-27 23:20:24.315913318 +0100
@@ -7493,10 +7493,7 @@ cp_finish_decomp (tree decl, tree first,
error_n (loc, count,
 "only %u name provided for structured binding",
 "only %u names provided for structured binding", count);
- /* Some languages have special plural rules even for large values,
-but it is periodic with period of 10, 100, 1000 etc.  */
- inform_n (loc, eltscnt > INT_MAX
-? (eltscnt % 100) + 100 : eltscnt,
+ inform_n (loc, eltscnt,
"while %qT decomposes into %wu element",
"while %qT decomposes into %wu elements",
type, eltscnt);

Jakub

Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)

[Jakub Jelinek]

On Mon, Feb 26, 2018 at 09:19:56PM -0700, Martin Sebor wrote:
>   PR c++/83871
>   PR c++/83503
>   * g++.dg/Wmissing-attributes.C: New test.
>   * g++.dg/ext/attr-const-pure.C: New test.
>   * g++.dg/ext/attr-const.C: New test.
>   * g++.dg/ext/attr-deprecated-2.C: New test.
>   * g++.dg/ext/attr-malloc-2.C: New test.
>   * g++.dg/ext/attr-malloc.C: New test.
>   * g++.dg/ext/attr-noinline-2.C: New test.
>   * g++.dg/ext/attr-noinline.C: New test.
>   * g++.dg/ext/attr-nonnull.C: New test.
>   * g++.dg/ext/attr-noreturn-2.C: New test.
>   * g++.dg/ext/attr-noreturn.C: New test.
>   * g++.dg/ext/attr-nothrow-2.C: New test.
>   * g++.dg/ext/attr-nothrow.C: New test.
>   * g++.dg/ext/attr-optimize.C: New test.
>   * g++.dg/ext/attr-pure.C: New test.
>   * g++.dg/ext/attr-returns-nonnull.C: New test.
>   * g++.dg/ext/attr-warning.C: New test.

I'm getting:
+UNRESOLVED: g++.dg/ext/attr-const.C  -std=gnu++11  scan-tree-dump-not 
optimized "test_const_none_failed"
+UNRESOLVED: g++.dg/ext/attr-const.C  -std=gnu++11  scan-tree-dump-not 
optimized "test_const_none_failed"
+UNRESOLVED: g++.dg/ext/attr-const.C  -std=gnu++11  scan-tree-dump-not 
optimized "test_none_const_failed"
+UNRESOLVED: g++.dg/ext/attr-const.C  -std=gnu++11  scan-tree-dump-not 
optimized "test_none_const_failed"
+UNRESOLVED: g++.dg/ext/attr-const.C  -std=gnu++14  scan-tree-dump-not 
optimized "test_const_none_failed"
+UNRESOLVED: g++.dg/ext/attr-const.C  -std=gnu++14  scan-tree-dump-not 
optimized "test_const_none_failed"
+UNRESOLVED: g++.dg/ext/attr-const.C  -std=gnu++14  scan-tree-dump-not 
optimized "test_none_const_failed"
+UNRESOLVED: g++.dg/ext/attr-const.C  -std=gnu++14  scan-tree-dump-not 
optimized "test_none_const_failed"
+UNRESOLVED: g++.dg/ext/attr-const.C  -std=gnu++98  scan-tree-dump-not 
optimized "test_const_none_failed"
+UNRESOLVED: g++.dg/ext/attr-const.C  -std=gnu++98  scan-tree-dump-not 
optimized "test_const_none_failed"
+UNRESOLVED: g++.dg/ext/attr-const.C  -std=gnu++98  scan-tree-dump-not 
optimized "test_none_const_failed"
+UNRESOLVED: g++.dg/ext/attr-const.C  -std=gnu++98  scan-tree-dump-not 
optimized "test_none_const_failed"
+UNRESOLVED: g++.dg/ext/attr-noinline-2.C  -std=gnu++11  scan-tree-dump-not 
optimized" "fnoinline_always_inline *();"
+UNRESOLVED: g++.dg/ext/attr-noinline-2.C  -std=gnu++14  scan-tree-dump-not 
optimized" "fnoinline_always_inline *();"
+UNRESOLVED: g++.dg/ext/attr-noinline-2.C  -std=gnu++98  scan-tree-dump-not 
optimized" "fnoinline_always_inline *();"
+UNRESOLVED: g++.dg/ext/attr-noinline.C  -std=gnu++11  scan-tree-dump-not 
optimized" "fnoinline_always_inline *();"
+UNRESOLVED: g++.dg/ext/attr-noinline.C  -std=gnu++11  scan-tree-dump-not 
optimized" "fnone_always_inline *();"
+UNRESOLVED: g++.dg/ext/attr-noinline.C  -std=gnu++14  scan-tree-dump-not 
optimized" "fnoinline_always_inline *();"
+UNRESOLVED: g++.dg/ext/attr-noinline.C  -std=gnu++14  scan-tree-dump-not 
optimized" "fnone_always_inline *();"
+UNRESOLVED: g++.dg/ext/attr-noinline.C  -std=gnu++98  scan-tree-dump-not 
optimized" "fnoinline_always_inline *();"
+UNRESOLVED: g++.dg/ext/attr-noinline.C  -std=gnu++98  scan-tree-dump-not 
optimized" "fnone_always_inline *();"
+UNRESOLVED: g++.dg/ext/attr-noreturn-2.C  -std=gnu++11  scan-tree-dump-not 
optimized "fnone_noreturn_failed"
+UNRESOLVED: g++.dg/ext/attr-noreturn-2.C  -std=gnu++11  scan-tree-dump-not 
optimized "fnoreturn_failed"
+UNRESOLVED: g++.dg/ext/attr-noreturn-2.C  -std=gnu++11  scan-tree-dump-not 
optimized "fnoreturn_none_failed"
+UNRESOLVED: g++.dg/ext/attr-noreturn-2.C  -std=gnu++14  scan-tree-dump-not 
optimized "fnone_noreturn_failed"
+UNRESOLVED: g++.dg/ext/attr-noreturn-2.C  -std=gnu++14  scan-tree-dump-not 
optimized "fnoreturn_failed"
+UNRESOLVED: g++.dg/ext/attr-noreturn-2.C  -std=gnu++14  scan-tree-dump-not 
optimized "fnoreturn_none_failed"
+UNRESOLVED: g++.dg/ext/attr-noreturn-2.C  -std=gnu++98  scan-tree-dump-not 
optimized "fnone_noreturn_failed"
+UNRESOLVED: g++.dg/ext/attr-noreturn-2.C  -std=gnu++98  scan-tree-dump-not 
optimized "fnoreturn_failed"
+UNRESOLVED: g++.dg/ext/attr-noreturn-2.C  -std=gnu++98  scan-tree-dump-not 
optimized "fnoreturn_none_failed"
+UNRESOLVED: g++.dg/ext/attr-pure.C  -std=gnu++11  scan-tree-dump-not optimized 
"test_none_pure_failed"
+UNRESOLVED: g++.dg/ext/attr-pure.C  -std=gnu++11  scan-tree-dump-not optimized 
"test_none_pure_failed"
+UNRESOLVED: g++.dg/ext/attr-pure.C  -std=gnu++11  scan-tree-dump-not optimized 
"test_pure_none_failed"
+UNRESOLVED: g++.dg/ext/attr-pure.C  -std=gnu++11  scan-tree-dump-not optimized 
"test_pure_none_failed"
+UNRESOLVED: g++.dg/ext/attr-pure.C  -std=gnu++14  scan-tree-dump-not optimized 
"test_none_pure_failed"
+UNRESOLVED: g++.dg/ext/attr-pure.C  -std=gnu++14  scan-tree-dump-not optimized 
"test_none_pure_failed"
+UNRESOLVED: g++.dg/ext/attr-pure.C  -st

[PATCH] Use warning_n instead of warning_at in gimple-ssa-warn-restrict.c

[Jakub Jelinek]

Hi!

This patch should fix most of the translation issues with plural forms
in gimple-ssa-warn-restrict.c, now that warning_n accepts UHWI, we can and
should just use warning_n in those cases.

I haven't touched the first set of warning_at calls, because the current wording
requires two plural forms in a single diagnostics, which is something
gettext can't handle.  I think the only way to fix it is to break the
message appart into warning_n and inform_n.

Anyway, following has been bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?

2018-02-28  Jakub Jelinek  

* gimple-ssa-warn-restrict.c (maybe_diag_overlap): Use warning_n
instead of warning_at with conditional singular and plural messages
where possible.

--- gcc/gimple-ssa-warn-restrict.c.jj   2018-02-21 11:32:56.417681850 +0100
+++ gcc/gimple-ssa-warn-restrict.c  2018-02-27 23:39:39.157721511 +0100
@@ -1399,42 +1399,38 @@ maybe_diag_overlap (location_t loc, gcal
call, func, sizrange[0],
offstr[0], offstr[1], ovlsiz[0], offstr[2]);
  else if (ovlsiz[1] >= 0 && ovlsiz[1] < maxobjsize.to_shwi ())
-   warning_at (loc, OPT_Wrestrict,
-   sizrange[0] == 1
-   ? G_("%G%qD accessing %wu byte at offsets %s "
-"and %s overlaps between %wu and %wu bytes "
-"at offset %s")
-   : G_("%G%qD accessing %wu bytes at offsets %s "
-"and %s overlaps between %wu and %wu bytes "
-"at offset %s"),
-   call, func, sizrange[0],
-   offstr[0], offstr[1], ovlsiz[0], ovlsiz[1],
-   offstr[2]);
+   warning_n (loc, OPT_Wrestrict, sizrange[0],
+  "%G%qD accessing %wu byte at offsets %s "
+  "and %s overlaps between %wu and %wu bytes "
+  "at offset %s",
+  "%G%qD accessing %wu bytes at offsets %s "
+  "and %s overlaps between %wu and %wu bytes "
+  "at offset %s",
+  call, func, sizrange[0], offstr[0], offstr[1],
+  ovlsiz[0], ovlsiz[1], offstr[2]);
  else
-   warning_at (loc, OPT_Wrestrict,
-   sizrange[0] == 1
-   ? G_("%G%qD accessing %wu byte at offsets %s and "
-"%s overlaps %wu or more bytes at offset %s")
-   : G_("%G%qD accessing %wu bytes at offsets %s and "
-"%s overlaps %wu or more bytes at offset %s"),
-   call, func, sizrange[0],
-   offstr[0], offstr[1], ovlsiz[0], offstr[2]);
+   warning_n (loc, OPT_Wrestrict, sizrange[0],
+  "%G%qD accessing %wu byte at offsets %s and "
+  "%s overlaps %wu or more bytes at offset %s",
+  "%G%qD accessing %wu bytes at offsets %s and "
+  "%s overlaps %wu or more bytes at offset %s",
+  call, func, sizrange[0],
+  offstr[0], offstr[1], ovlsiz[0], offstr[2]);
  return true;
}
 
   if (sizrange[1] >= 0 && sizrange[1] < maxobjsize.to_shwi ())
{
  if (ovlsiz[0] == ovlsiz[1])
-   warning_at (loc, OPT_Wrestrict,
-   ovlsiz[0] == 1
-   ? G_("%G%qD accessing between %wu and %wu bytes "
-"at offsets %s and %s overlaps %wu byte at "
-"offset %s")
-   : G_("%G%qD accessing between %wu and %wu bytes "
-"at offsets %s and %s overlaps %wu bytes "
-"at offset %s"),
-   call, func, sizrange[0], sizrange[1],
-   offstr[0], offstr[1], ovlsiz[0], offstr[2]);
+   warning_n (loc, OPT_Wrestrict, ovlsiz[0],
+  "%G%qD accessing between %wu and %wu bytes "
+  "at offsets %s and %s overlaps %wu byte at "
+  "offset %s",
+  "%G%qD accessing between %wu and %wu bytes "
+  "at offsets %s and %s overlaps %wu bytes "
+  "at offset %s",
+  call, func, sizrange[0], sizrange[1],
+  offstr[0], offstr[1], ovlsiz[0], offstr[2]);
  else if (ovlsiz[1] >= 0 && ovlsiz[1] < maxobjsize.to_shwi ())
warning_at (loc, OPT_Wrestrict,
"%G%qD accessing between %wu and %wu bytes at "
@@ -1457,14 +1453,13 @@ maybe_diag_overlap (location_t loc, gcal
ovlsiz[1] = maxobjsize.to_shwi ();
 
   if (ovlsiz[0] == ovlsiz[1])
-   warning_at (loc, OPT_Wrestrict,
-   ovlsiz[0] == 1
-   ? G_("%G%qD 

Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)

[Jakub Jelinek]

On Mon, Feb 26, 2018 at 09:19:56PM -0700, Martin Sebor wrote:
>   PR c++/83871
>   PR c++/83503
>   * g++.dg/ext/attr-const.C: New test.
>   * g++.dg/ext/attr-pure.C: New test.

I've tried to fix these 2 tests with following patch, without
-fdump-tree-optimized all the scan-tree-dump* tests are UNRESOLVED,
and when you use the same function for multiple-subtests all you get
is the same failures reported multiple times, but without knowing which
of them failed.

Unfortunately, even with this patch there are failures:
FAIL: g++.dg/ext/attr-const.C  -std=gnu++11  scan-tree-dump-not optimized 
"test_func_none_const_failed"
FAIL: g++.dg/ext/attr-const.C  -std=gnu++11  scan-tree-dump-not optimized 
"test_template_none_const_failed"
FAIL: g++.dg/ext/attr-const.C  -std=gnu++14  scan-tree-dump-not optimized 
"test_func_none_const_failed"
FAIL: g++.dg/ext/attr-const.C  -std=gnu++14  scan-tree-dump-not optimized 
"test_template_none_const_failed"
FAIL: g++.dg/ext/attr-const.C  -std=gnu++17 -fconcepts  scan-tree-dump-not 
optimized "test_func_none_const_failed"
FAIL: g++.dg/ext/attr-const.C  -std=gnu++17 -fconcepts  scan-tree-dump-not 
optimized "test_template_none_const_failed"
FAIL: g++.dg/ext/attr-const.C  -std=gnu++17  scan-tree-dump-not optimized 
"test_func_none_const_failed"
FAIL: g++.dg/ext/attr-const.C  -std=gnu++17  scan-tree-dump-not optimized 
"test_template_none_const_failed"
FAIL: g++.dg/ext/attr-const.C  -std=gnu++2a  scan-tree-dump-not optimized 
"test_func_none_const_failed"
FAIL: g++.dg/ext/attr-const.C  -std=gnu++2a  scan-tree-dump-not optimized 
"test_template_none_const_failed"
FAIL: g++.dg/ext/attr-const.C  -std=gnu++98  scan-tree-dump-not optimized 
"test_func_none_const_failed"
FAIL: g++.dg/ext/attr-const.C  -std=gnu++98  scan-tree-dump-not optimized 
"test_template_none_const_failed"
FAIL: g++.dg/ext/attr-pure.C  -std=gnu++11  scan-tree-dump-not optimized 
"test_template_none_pure_failed"
FAIL: g++.dg/ext/attr-pure.C  -std=gnu++14  scan-tree-dump-not optimized 
"test_template_none_pure_failed"
FAIL: g++.dg/ext/attr-pure.C  -std=gnu++17 -fconcepts  scan-tree-dump-not 
optimized "test_template_none_pure_failed"
FAIL: g++.dg/ext/attr-pure.C  -std=gnu++17  scan-tree-dump-not optimized 
"test_template_none_pure_failed"
FAIL: g++.dg/ext/attr-pure.C  -std=gnu++2a  scan-tree-dump-not optimized 
"test_template_none_pure_failed"
FAIL: g++.dg/ext/attr-pure.C  -std=gnu++98  scan-tree-dump-not optimized 
"test_template_none_pure_failed"
so if the test is right, then something is still broken on the C++ FE side.

I'll defer debugging this to you.

--- gcc/testsuite/g++.dg/ext/attr-const.C.jj2018-02-28 09:55:57.235897906 
+0100
+++ gcc/testsuite/g++.dg/ext/attr-const.C   2018-02-28 10:37:09.775438593 
+0100
@@ -1,37 +1,37 @@
 /*  PR c++/83871 - wrong code for attribute const and pure on distinct
 template specializations
 { dg-do compile }
-{ dg-options "-O -Wall" } */
+{ dg-options "-O -Wall -fdump-tree-optimized" } */
 
 int __attribute__ ((const)) fconst_none ();
 int fconst_none ();
 
-void test_const_none_failed ();
+void test_func_const_none_failed ();
 
 void func_const_none ()
 {
   int i0 = fconst_none ();
   int i1 = fconst_none ();
   if (i0 != i1)
-test_const_none_failed ();
+test_func_const_none_failed ();
 
-  // { dg-final { scan-tree-dump-not "test_const_none_failed" "optimized" } }
+  // { dg-final { scan-tree-dump-not "test_func_const_none_failed" "optimized" 
} }
 }
 
 
 int fnone_const ();
 int __attribute__ ((const)) fnone_const ();
 
-void test_none_const_failed ();
+void test_func_none_const_failed ();
 
 void func_none_const ()
 {
   int i0 = fnone_const ();
   int i1 = fnone_const ();
   if (i0 != i1)
-test_none_const_failed ();
+test_func_none_const_failed ();
 
-  // { dg-final { scan-tree-dump-not "test_none_const_failed" "optimized" } }
+  // { dg-final { scan-tree-dump-not "test_func_none_const_failed" "optimized" 
} }
 }
 
 
@@ -41,14 +41,16 @@ int __attribute__ ((const)) fconst_none
 template 
 int fconst_none (T);
 
+void test_template_const_none_failed ();
+
 void template_const_none ()
 {
   int i0 = fconst_none (0);
   int i1 = fconst_none (0);
   if (i0 != i1)
-test_const_none_failed ();
+test_template_const_none_failed ();
 
-  // { dg-final { scan-tree-dump-not "test_const_none_failed" "optimized" } }
+  // { dg-final { scan-tree-dump-not "test_template_const_none_failed" 
"optimized" } }
 }
 
 
@@ -58,12 +60,14 @@ int fnone_const (T);
 template 
 int __attribute__ ((const)) fnone_const (T);
 
+void test_template_none_const_failed ();
+
 void test_fnone_const ()
 {
   int i0 = fnone_const (0);
   int i1 = fnone_const (0);
   if (i0 != i1)
-test_none_const_failed ();
+test_template_none_const_failed ();
 
-  // { dg-final { scan-tree-dump-not "test_none_const_failed" "optimized" } }
+  // { dg-final { scan-tree-dump-not "test_template_none_const_failed" 
"optimized" } }
 }
--- gcc/testsuite/g++.dg/ex

[PATCH] Fix timevar format and fix tests (PR testsuite/84597).

[Martin Liška]

Hi.

It's fix of 2 tests that I forgot to adjust. Apart from that I'm slightly adjust
printf patterns in order to support '100%' values.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin

gcc/ChangeLog:

2018-02-28  Martin Liska  

PR testsuite/84597
* timevar.c (timer::print): Fix format to properly print 100%
values.

gcc/testsuite/ChangeLog:

2018-02-28  Martin Liska  

* g++.dg/ext/timevar1.C: Fix pruned patterns.
* g++.dg/ext/timevar2.C: Likewise.
---
 gcc/testsuite/g++.dg/ext/timevar1.C |  5 ++---
 gcc/testsuite/g++.dg/ext/timevar2.C |  5 ++---
 gcc/timevar.c   | 16 
 3 files changed, 12 insertions(+), 14 deletions(-)


diff --git a/gcc/testsuite/g++.dg/ext/timevar1.C b/gcc/testsuite/g++.dg/ext/timevar1.C
index a48f8ba3705..3f891a50aba 100644
--- a/gcc/testsuite/g++.dg/ext/timevar1.C
+++ b/gcc/testsuite/g++.dg/ext/timevar1.C
@@ -1,9 +1,8 @@
 // PR c++/52248
 // { dg-options "-ftime-report" }
 // { dg-allow-blank-lines-in-output 1 }
-// { dg-prune-output "wall" }
-// { dg-prune-output "times" }
-// { dg-prune-output "TOTAL" }
+// { dg-prune-output "Time variable" }
+// { dg-prune-output " kB" }
 // { dg-prune-output "checks" }
 
 void
diff --git a/gcc/testsuite/g++.dg/ext/timevar2.C b/gcc/testsuite/g++.dg/ext/timevar2.C
index 74c4fc8cfae..dd96d45c01e 100644
--- a/gcc/testsuite/g++.dg/ext/timevar2.C
+++ b/gcc/testsuite/g++.dg/ext/timevar2.C
@@ -1,8 +1,7 @@
 // PR c++/57524
 // { dg-options "-ftime-report" }
-// { dg-prune-output "wall" }
-// { dg-prune-output "times" }
-// { dg-prune-output "TOTAL" }
+// { dg-prune-output "Time variable" }
+// { dg-prune-output " kB" }
 // { dg-prune-output "checks" }
 
 namespace detail {
diff --git a/gcc/timevar.c b/gcc/timevar.c
index d209f5be0f5..2a7defbcc8c 100644
--- a/gcc/timevar.c
+++ b/gcc/timevar.c
@@ -641,27 +641,27 @@ timer::print_row (FILE *fp,
 
 #ifdef HAVE_USER_TIME
   /* Print user-mode time for this process.  */
-  fprintf (fp, "%7.2f (%2.0f%%)",
+  fprintf (fp, "%7.2f (%3.0f%%)",
 	   elapsed.user,
 	   (total->user == 0 ? 0 : elapsed.user / total->user) * 100);
 #endif /* HAVE_USER_TIME */
 
 #ifdef HAVE_SYS_TIME
   /* Print system-mode time for this process.  */
-  fprintf (fp, "%7.2f (%2.0f%%)",
+  fprintf (fp, "%7.2f (%3.0f%%)",
 	   elapsed.sys,
 	   (total->sys == 0 ? 0 : elapsed.sys / total->sys) * 100);
 #endif /* HAVE_SYS_TIME */
 
 #ifdef HAVE_WALL_TIME
   /* Print wall clock time elapsed.  */
-  fprintf (fp, "%7.2f (%2.0f%%)",
+  fprintf (fp, "%7.2f (%3.0f%%)",
 	   elapsed.wall,
 	   (total->wall == 0 ? 0 : elapsed.wall / total->wall) * 100);
 #endif /* HAVE_WALL_TIME */
 
   /* Print the amount of ggc memory allocated.  */
-  fprintf (fp, "%8u kB (%2.0f%%)",
+  fprintf (fp, "%8u kB (%3.0f%%)",
 	   (unsigned) (elapsed.ggc_mem >> 10),
 	   (total->ggc_mem == 0
 	? 0
@@ -712,7 +712,7 @@ timer::print (FILE *fp)
  TIMEVAR.  */
   m_start_time = now;
 
-  fprintf (fp, "\n%-35s%15s%13s%13s%17s\n", "Time variable", "usr", "sys",
+  fprintf (fp, "\n%-35s%16s%14s%14s%18s\n", "Time variable", "usr", "sys",
 	   "wall", "GGC");
   if (m_jit_client_items)
 fputs ("GCC items:\n", fp);
@@ -771,12 +771,12 @@ timer::print (FILE *fp)
   fprintf (fp, "%7.2f  ", total->user);
 #endif
 #ifdef HAVE_SYS_TIME
-  fprintf (fp, "%7.2f  ", total->sys);
+  fprintf (fp, "%8.2f  ", total->sys);
 #endif
 #ifdef HAVE_WALL_TIME
-  fprintf (fp, "%7.2f  ", total->wall);
+  fprintf (fp, "%8.2f  ", total->wall);
 #endif
-  fprintf (fp, "%8u kB\n", (unsigned) (total->ggc_mem >> 10));
+  fprintf (fp, "%9u kB\n", (unsigned) (total->ggc_mem >> 10));
 
   if (CHECKING_P || flag_checking)
 fprintf (fp, "Extra diagnostic checks enabled; compiler may run slowly.\n");

Re: [PATCH] Fix ms_struct/-mms-bitfields structure layout (PR target/52991)

[JonY]

On 02/28/2018 12:26 AM, Jakub Jelinek wrote:
> Hi!
> 
> The following patch fixes the reported ms_struct/-mms-bitfields structure
> layout issues from PR52991.
> 
> There are multiple issues, two of them introduced by the
> https://gcc.gnu.org/ml/gcc-patches/2006-04/msg01064.html -mms-bitfields
> revamp from Eric and follow-up fix r114552, the rest has been introduced
> later when the known_align < desired_align case has been enabled for the ms
> bitfield layout.
> 
> The first 2 hunks fix alignment of packed non-bitfield fields, we can't
> ignore all the alignment updates for them, just should use only
> desired_align which takes DECL_PACKED into account, rather than
> MAX (type_align, desired_align).  Similarly, the last hunk in stor-layout.c
> makes sure that for DECL_PACKED fields we use BITS_PER_UNIT alignment rather
> than the type alignment.
> 
> The rest attempts to unbreak r184409 which enabled known_align < desired_align
> case; doing that if rli->prev_field and ms layout is wrong, we first need to
> deal with the bitfield packing and if we are within a bitfield word, we
> shouldn't do any realignment, only in between them.
> 
> The patch reverts changes to bf-ms-layout{,-2}.c tests done in 2012, which
> were done just to match the r184409 changes, and adds 2 new tests.  All of
> these 4 I've tested (slightly tweaked, so that it compiles with VC) with
> the online VC compiler http://rextester.com/l/c_online_compiler_visual .
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 

No objections.





signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Fix pt.c bootstrap breakage

[Richard Biener]

On Wed, Feb 28, 2018 at 12:27 AM, David Edelsohn  wrote:
> The recent change to pt.c broke bootstrap by including C++ header file
>  directly and including it first.  This patch changes to the
> necessary method which includes the header file via system.h.
>
> Okay?

Ok.  But in reality nobody should use std::string ...

> Thanks, David
>
> * pt.c: Don't include string. Define INCLUDE_STRING before system.h.
>
> Index: pt.c
> ===
> --- pt.c(revision 258045)
> +++ pt.c(working copy)
> @@ -24,8 +24,8 @@
>   all methods must be provided in header files; can't use a source
>   file that contains only the method templates and "just win".  */
>
> -#include 
>  #include "config.h"
> +#define INCLUDE_STRING
>  #include "system.h"
>  #include "coretypes.h"
>  #include "cp-tree.h"

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

[Richard Biener]

On Wed, Feb 28, 2018 at 1:16 AM, Jeff Law  wrote:
> Richi, you worked on 57147 which touches on the issues here.  Your
> thoughts would be greatly appreciated.
>
>
> So 61118 is one of several bugs related to the clobbered-by-longjmp warning.
>
> In 61118 is we are unable to coalesce all the objects in the key
> partitions.  To remove the relevant PHIs we have to create two
> assignments to the key pseudos.
>
> Pseudos with more than one assignment are subject to the
> clobbered-by-longjmp analysis:
>
>  * True if register REGNO was alive at a place where `setjmp' was
>called and was set more than once or is an argument.  Such regs may
>be clobbered by `longjmp'.  */
>
> static bool
> regno_clobbered_at_setjmp (bitmap setjmp_crosses, int regno)
> {
>   /* There appear to be cases where some local vars never reach the
>  backend but have bogus regnos.  */
>   if (regno >= max_reg_num ())
> return false;
>
>   return ((REG_N_SETS (regno) > 1
>|| REGNO_REG_SET_P (df_get_live_out (ENTRY_BLOCK_PTR_FOR_FN
> (cfun)),
>regno))
>   && REGNO_REG_SET_P (setjmp_crosses, regno));
> }
>
>
> The fact that no path sets the pseudo more than once is not considered.
> If there is more than one static set of the pseudo, then it is
> considered for possible warning.
>
> --
>
>
> I looked at the propagations which led to the inability to coalesce.
> They all seemed valid to me.  We have always allowed copy propagation to
> replace one pseudo with another as long as neither has
> SSA_NAME_USED_IN_ABNORMAL_PHI set.
>
> We have a PHI like
>
> x1(ab) = (x0, x3 (ab))
>
> x0 is not marked as abnormal because the edge isn't abnormal and thus we
> can propagate into the x0 argument of the PHI.  This is consistent with
> behavior since, well, forever.   We propagate a value for x0 resulting
> in something like
>
> x1(b) = (y0, x3 (ab))
>
>
> Where y0 is still live across the PHI.  Thus the partition for x1/x3,
> etc conflicts with the partition for y0 and they can not be coalesced.
> This leads to the multiple assignments to the pseudo for the x1/x3
> partition.  I briefly looked marking all the PHI arguments as abnormal
> when the destination is abnormal, but it just doesn't seem right.
>
> Anyway, I'd already been looking at 21161 and was aware that the CFG's
> we're building in presence of setjmp/longjmp were slightly inaccurate.
>
> In particular, a longjmp returns to the point immediately after the
> setjmp, not to the setjmp itself.  But our CFG building has the edge
> from the abnormal dispatcher going to the block containing the setjmp call.

Yeah...  for SJLJ EH we get this right via __builtin_setjmp_receiver.

> This creates unnecessary irreducible loops.  It turns out that if we fix
> the tree CFG, then lifetimes become more accurate (and more
> constrained).  The more constrained, more accurate lifetime information
> is enough to allow things to coalesce the way we want and everything for
> 61118 just works.

Sounds good.

> It's actually pretty easy to fix the CFG.  We  just need to recognize
> that a "returns twice" function returns not to the call, but to the
> point immediately after the call.  So if we have a call to a returns
> twice function that ends a block with a single successor, when we wire
> up the abnormal dispatcher, we target the single successor rather than
> the block containing the returns-twice call.

Hmm, I think you need to check whether the successor has a single
predecessor, not whether we have a single successor (we always have
that unless setjmp also throws).  If you fix that you keep the CFG
"incorrect" if there are multiple predecessors so I think in addition
to properly creating the edges you have to work on the BB building
part to ensure that there's a single-predecessor block after
returns-twice function calls.  Note that currently we force returns-twice
to be the first (and only) stmt of a block -- your fix would relax this,
returns-twice no longer needs to start a new BB.

-   handle_abnormal_edges (dispatcher_bbs, bb, bb_to_omp_idx,
-  &ab_edge_call, false);
+   {
+ bool target_after_setjmp = false;
+
+ /* If the returns twice statement looks like a setjmp
+call at the end of a block with a single successor
+then we want the edge from the dispatcher to target
+that single successor.  That more accurately reflects
+actual control flow.  The more accurate CFG also
+results in fewer false positive warnings.  */
+ if (gsi_stmt (gsi_last_nondebug_bb (bb)) == call_stmt
+ && gimple_call_fndecl (call_stmt)
+ && setjmp_call_p (gimple_call_fndecl (call_stmt))
+ && single_succ_p (bb))
+   target_after_setjmp = true;
+ handle_abnormal_edges 

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

[Richard Biener]

On Wed, Feb 28, 2018 at 11:43 AM, Richard Biener
 wrote:
> On Wed, Feb 28, 2018 at 1:16 AM, Jeff Law  wrote:
>> Richi, you worked on 57147 which touches on the issues here.  Your
>> thoughts would be greatly appreciated.
>>
>>
>> So 61118 is one of several bugs related to the clobbered-by-longjmp warning.
>>
>> In 61118 is we are unable to coalesce all the objects in the key
>> partitions.  To remove the relevant PHIs we have to create two
>> assignments to the key pseudos.
>>
>> Pseudos with more than one assignment are subject to the
>> clobbered-by-longjmp analysis:
>>
>>  * True if register REGNO was alive at a place where `setjmp' was
>>called and was set more than once or is an argument.  Such regs may
>>be clobbered by `longjmp'.  */
>>
>> static bool
>> regno_clobbered_at_setjmp (bitmap setjmp_crosses, int regno)
>> {
>>   /* There appear to be cases where some local vars never reach the
>>  backend but have bogus regnos.  */
>>   if (regno >= max_reg_num ())
>> return false;
>>
>>   return ((REG_N_SETS (regno) > 1
>>|| REGNO_REG_SET_P (df_get_live_out (ENTRY_BLOCK_PTR_FOR_FN
>> (cfun)),
>>regno))
>>   && REGNO_REG_SET_P (setjmp_crosses, regno));
>> }
>>
>>
>> The fact that no path sets the pseudo more than once is not considered.
>> If there is more than one static set of the pseudo, then it is
>> considered for possible warning.
>>
>> --
>>
>>
>> I looked at the propagations which led to the inability to coalesce.
>> They all seemed valid to me.  We have always allowed copy propagation to
>> replace one pseudo with another as long as neither has
>> SSA_NAME_USED_IN_ABNORMAL_PHI set.
>>
>> We have a PHI like
>>
>> x1(ab) = (x0, x3 (ab))
>>
>> x0 is not marked as abnormal because the edge isn't abnormal and thus we
>> can propagate into the x0 argument of the PHI.  This is consistent with
>> behavior since, well, forever.   We propagate a value for x0 resulting
>> in something like
>>
>> x1(b) = (y0, x3 (ab))
>>
>>
>> Where y0 is still live across the PHI.  Thus the partition for x1/x3,
>> etc conflicts with the partition for y0 and they can not be coalesced.
>> This leads to the multiple assignments to the pseudo for the x1/x3
>> partition.  I briefly looked marking all the PHI arguments as abnormal
>> when the destination is abnormal, but it just doesn't seem right.
>>
>> Anyway, I'd already been looking at 21161 and was aware that the CFG's
>> we're building in presence of setjmp/longjmp were slightly inaccurate.
>>
>> In particular, a longjmp returns to the point immediately after the
>> setjmp, not to the setjmp itself.  But our CFG building has the edge
>> from the abnormal dispatcher going to the block containing the setjmp call.
>
> Yeah...  for SJLJ EH we get this right via __builtin_setjmp_receiver.
>
>> This creates unnecessary irreducible loops.  It turns out that if we fix
>> the tree CFG, then lifetimes become more accurate (and more
>> constrained).  The more constrained, more accurate lifetime information
>> is enough to allow things to coalesce the way we want and everything for
>> 61118 just works.
>
> Sounds good.

Oh - and to mention it, we have one long-standing issue after me trying
to fix things here which is that RTL doesn't have all those abnormal edges
for setjmp and friends because we throw away abnormal edges during
RTL expansion and expect to recompute them...

IIRC there's a bugreport about this to track this issue and the fix is
to stop removing abnormal edges and instread transition them to RTL:

  /* At the moment not all abnormal edges match the RTL
 representation.  It is safe to remove them here as
 find_many_sub_basic_blocks will rediscover them.
 In the future we should get this fixed properly.  */
  if ((e->flags & EDGE_ABNORMAL)
  && !(e->flags & EDGE_SIBCALL))
remove_edge (e);

not sure if we can use an edge flag to mark those we want to preserve.
But I don't understand the comment very well - why would any abnormal
edges not "match" the RTL representation?

>> It's actually pretty easy to fix the CFG.  We  just need to recognize
>> that a "returns twice" function returns not to the call, but to the
>> point immediately after the call.  So if we have a call to a returns
>> twice function that ends a block with a single successor, when we wire
>> up the abnormal dispatcher, we target the single successor rather than
>> the block containing the returns-twice call.
>
> Hmm, I think you need to check whether the successor has a single
> predecessor, not whether we have a single successor (we always have
> that unless setjmp also throws).  If you fix that you keep the CFG
> "incorrect" if there are multiple predecessors so I think in addition
> to properly creating the edges you have to work on the BB building
> part to ensure that there's a single-predecessor block after
> returns-twice function calls.  Note that current

Re: [Aarch64] Fix conditional branches with target far away.

[Sameera Deshpande]

On 27 February 2018 at 18:25, Ramana Radhakrishnan
 wrote:
> On Wed, Feb 14, 2018 at 8:30 AM, Sameera Deshpande
>  wrote:
>> Hi!
>>
>> Please find attached the patch to fix bug in branches with offsets over 1MiB.
>> There has been an attempt to fix this issue in commit
>> 050af05b9761f1979f11c151519e7244d5becd7c
>>
>> However, the far_branch attribute defined in above patch used
>> insn_length - which computes incorrect offset. Hence, eliminated the
>> attribute completely, and computed the offset from insn_addresses
>> instead.
>>
>> Ok for trunk?
>>
>> gcc/Changelog
>>
>> 2018-02-13 Sameera Deshpande 
>> * config/aarch64/aarch64.md (far_branch): Remove attribute. Eliminate
>> all the dependencies on the attribute from RTL patterns.
>>
>
> I'm not a maintainer but this looks good to me modulo notes about how
> this was tested. What would be nice is a testcase for the testsuite as
> well as ensuring that the patch has been bootstrapped and regression
> tested. AFAIR, the original patch was put in because match.pd failed
> when bootstrap in another context.
>
>
> regards
> Ramana
>
>> --
>> - Thanks and regards,
>>   Sameera D.

The patch is tested with GCC testsuite and bootstrapping successfully.
Also tested for spec benchmark.

-- 
- Thanks and regards,
  Sameera D.

Re: [PATCH] Fix timevar format and fix tests (PR testsuite/84597).

[Richard Biener]

On Wed, Feb 28, 2018 at 11:07 AM, Martin Liška  wrote:
> Hi.
>
> It's fix of 2 tests that I forgot to adjust. Apart from that I'm slightly 
> adjust
> printf patterns in order to support '100%' values.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?

Ok.
Richard.

> Martin
>
> gcc/ChangeLog:
>
> 2018-02-28  Martin Liska  
>
> PR testsuite/84597
> * timevar.c (timer::print): Fix format to properly print 100%
> values.
>
> gcc/testsuite/ChangeLog:
>
> 2018-02-28  Martin Liska  
>
> * g++.dg/ext/timevar1.C: Fix pruned patterns.
> * g++.dg/ext/timevar2.C: Likewise.
> ---
>  gcc/testsuite/g++.dg/ext/timevar1.C |  5 ++---
>  gcc/testsuite/g++.dg/ext/timevar2.C |  5 ++---
>  gcc/timevar.c   | 16 
>  3 files changed, 12 insertions(+), 14 deletions(-)
>
>

[PR c++/84492] return stmt expr ending with overload

[Alexandre Oliva]

We ICEd when returning a stmt expr that ends with an overloaded
function.  It's ill-formed when we can't convert the function name to
the return type, but we should say that, not ICE.

The problem was that instantiate_type did not know what to do with
STMT_EXPRs.

Regstrapped on x86_64- and i686-linux-gnu.  Ok to install?

for  gcc/cp/ChangeLog

PR c++/84492
* class.c (instantiate_type): Deal with STMT_EXPRs.

for  gcc/testsuite/ChangeLog

PR c++/84492
* g++.dg/pr84492.C: New.
---
 gcc/cp/class.c |6 +-
 gcc/testsuite/g++.dg/pr84492.C |7 +++
 2 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/pr84492.C

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 8348552a05b6..06630dc165d0 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -8013,7 +8013,8 @@ instantiate_type (tree lhstype, tree rhs, tsubst_flags_t 
complain)
   gcc_assert (TREE_CODE (rhs) == ADDR_EXPR
  || TREE_CODE (rhs) == COMPONENT_REF
  || is_overloaded_fn (rhs)
- || (flag_ms_extensions && TREE_CODE (rhs) == FUNCTION_DECL));
+ || (flag_ms_extensions && TREE_CODE (rhs) == FUNCTION_DECL)
+ || TREE_CODE (rhs) == STMT_EXPR);
 
   /* This should really only be used when attempting to distinguish
  what sort of a pointer to function we have.  For now, any
@@ -8073,6 +8074,9 @@ instantiate_type (tree lhstype, tree rhs, tsubst_flags_t 
complain)
   return instantiate_type (lhstype, TREE_OPERAND (rhs, 0), complain);
 }
 
+case STMT_EXPR:
+  return instantiate_type (lhstype, stmt_expr_value_expr (rhs), complain);
+
 case ERROR_MARK:
   return error_mark_node;
 
diff --git a/gcc/testsuite/g++.dg/pr84492.C b/gcc/testsuite/g++.dg/pr84492.C
new file mode 100644
index ..51fbd883a990
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr84492.C
@@ -0,0 +1,7 @@
+// { dg-do compile }
+// { dg-options "-fpermissive" }
+
+template int foo()
+{
+  return ({ foo; }); // { dg-error "cannot resolve overloaded function" }
+}

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

[PATCH] Fix PR84584

[Richard Biener]

The following fixes this PR.

Bootstrap & regtest running on x86_64-unknown-linux-gnu.

Richard.

2018-02-28  Richard Biener  

PR tree-optimization/84584
* graphite-scop-detection.c (scop_detection::add_scop): Discard
SCoPs with fake exit edge.

* gcc.dg/graphite/pr84584.c: New testcase.

Index: gcc/graphite-scop-detection.c
===
--- gcc/graphite-scop-detection.c   (revision 258056)
+++ gcc/graphite-scop-detection.c   (working copy)
@@ -590,6 +590,15 @@ scop_detection::add_scop (sese_l s)
 {
   gcc_assert (s);
 
+  /* If the exit edge is fake discard the SCoP for now as we're removing the
+ fake edges again after analysis.  */
+  if (s.exit->flags & EDGE_FAKE)
+{
+  DEBUG_PRINT (dp << "[scop-detection-fail] Discarding infinite loop SCoP: 
";
+  print_sese (dump_file, s));
+  return;
+}
+
   /* Include the BB with the loop-closed SSA PHI nodes, we need this
  block in the region for code-generating out-of-SSA copies.
  canonicalize_loop_closed_ssa makes sure that is in proper shape.  */
Index: gcc/testsuite/gcc.dg/graphite/pr84584.c
===
--- gcc/testsuite/gcc.dg/graphite/pr84584.c (nonexistent)
+++ gcc/testsuite/gcc.dg/graphite/pr84584.c (working copy)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fgraphite-identity -fno-tree-loop-im" } */
+
+int q3, w1;
+
+void
+bw (int b8)
+{
+  const int sd = 2;
+  int mc;
+
+  for (mc = 0; mc < sd; ++mc)
+{
+ik:
+  for (w1 = 0; w1 < sd; ++w1)
+   ++b8;
+}
+
+  for (q3 = 0; q3 < sd; ++q3)
+;
+
+  goto ik;
+}

[PR c++/84593] ice on braced init with uninit ref field

[Alexandre Oliva]

Don't allow the initializer expr to be NULL in a ctor initializer
list, make it error_marker_node instead.

Regstrapped on x86_64- and i686-linux-gnu.  Ok to install?

for  gcc/cp/ChangeLog

PR c++/84593
* typeck2.c (process_init_constructor_record): Set NULL next
to error_marker_node.

for  gcc/testsuite/ChangeLog

PR c++/84593
* g++.dg/cpp1y/pr84593.C: New.
---
 gcc/cp/typeck2.c |2 ++
 gcc/testsuite/g++.dg/cpp1y/pr84593.C |8 
 2 files changed, 10 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr84593.C

diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 153b46cca775..8c2aa3ed55a5 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1529,6 +1529,8 @@ process_init_constructor_record (tree type, tree init, 
int nested,
   /* If this is a bitfield, now convert to the lowered type.  */
   if (type != TREE_TYPE (field))
next = cp_convert_and_check (TREE_TYPE (field), next, complain);
+  if (!next)
+   next = error_mark_node;
   flags |= picflag_from_initializer (next);
   CONSTRUCTOR_APPEND_ELT (v, field, next);
 }
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr84593.C 
b/gcc/testsuite/g++.dg/cpp1y/pr84593.C
new file mode 100644
index ..8aa869f19193
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/pr84593.C
@@ -0,0 +1,8 @@
+// PR c++/84593
+// { dg-do compile { target c++14 } }
+
+struct a {
+  int x;
+  int c = 0;
+  int &b;
+} c = {}; // { dg-error "uninitialized reference" }

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

[PATCH] Fix PR84607

[Richard Biener]

genmatch was fooled by singelton expression leafs so it omitted
the required TREE_SIDE_EFFECTS check and building a COMPOUND_EXPR
for the side-effects.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2018-02-28  Richard Biener  

PR middle-end/84607
* genmatch.c (capture_info::walk_match): Do not mark
captured expressions without operands as expr_p given
they act more like predicates and should be subject to
"lost tail" side-effect preserving.

* gcc.dg/pr84607.c: New testcase.

Index: gcc/genmatch.c
===
--- gcc/genmatch.c  (revision 258056)
+++ gcc/genmatch.c  (working copy)
@@ -2104,7 +2104,11 @@ capture_info::walk_match (operand *o, un
   if (c->what
  && (e = dyn_cast  (c->what)))
{
- info[where].expr_p = true;
+ /* Zero-operand expression captures like ADDR_EXPR@0 are
+similar as predicates -- if they are not mentioned in
+the result we have to force them to have no side-effects.  */
+ if (e->ops.length () != 0)
+   info[where].expr_p = true;
  info[where].force_single_use |= e->force_single_use;
}
 }
Index: gcc/testsuite/gcc.dg/pr84607.c
===
--- gcc/testsuite/gcc.dg/pr84607.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/pr84607.c  (working copy)
@@ -0,0 +1,16 @@
+/* { dg-do run } */
+
+extern void exit(int);
+extern void abort(void);
+int a[10];
+int foo()
+{
+  exit (0);
+  return 0;
+}
+int main()
+{
+  if (&a[foo()])
+abort ();
+  return 0;
+}

[PR c++/84596] implicit conv in static assert

[Alexandre Oliva]

Evaluation of constant expressions, such as those passed to
static_assert, ICEd when encountering IMPLICIT_CONV_EXPRs.

Handle them like CONVERT_EXPR and NOP_EXPR.

Regstrapped on x86_64- and i686-linux-gnu.  Ok to install?

for  gcc/cp/ChangeLog

PR c++/84596
* constexpr.c (cxx_eval_constant_expression): Handle
IMPLICIT_CONV_EXPR.

for  gcc/testsuite/ChangeLog

PR c++/84596
* g++.dg/cpp0x/pr84596.C: New.
---
 gcc/cp/constexpr.c   |1 +
 gcc/testsuite/g++.dg/cpp0x/pr84596.C |7 +++
 2 files changed, 8 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr84596.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 4bbdbf434877..d38e2d83ae8c 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -4549,6 +4549,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
   non_constant_p, overflow_p);
   break;
 
+case IMPLICIT_CONV_EXPR:
 case CONVERT_EXPR:
 case VIEW_CONVERT_EXPR:
 case NOP_EXPR:
diff --git a/gcc/testsuite/g++.dg/cpp0x/pr84596.C 
b/gcc/testsuite/g++.dg/cpp0x/pr84596.C
new file mode 100644
index ..ee709f4200fe
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/pr84596.C
@@ -0,0 +1,7 @@
+// PR c++/84596
+// { dg-do compile { target c++11 } }
+
+template
+void b(int c) {
+  static_assert (c, "c"); // { dg-error "non-constant|not a constant" }
+}

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

[v3 PATCH] PR libstdc++/84601

[Ville Voutilainen]

Partially tested on Linux-x64, will run full suite on Linux-PPC64.

2018-02-28  Ville Voutilainen  

PR libstdc++/84601
* include/std/optional (_Optional_payload): Split into multiple
specializations that can handle different cases of trivial or
non-trivial assignment operators.
* testsuite/20_util/optional/84601.cc: New.
diff --git a/libstdc++-v3/include/std/optional 
b/libstdc++-v3/include/std/optional
index 01fc06b..0aa20dd 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -98,13 +98,137 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { _GLIBCXX_THROW_OR_ABORT(bad_optional_access()); }
 
 
-  // Payload for constexpr optionals.
+  // Payload for optionals with non-trivial destructor.
   template ::value>
+ is_trivially_destructible<_Tp>::value,
+   bool /*_HasTrivialCopyAssignment*/ =
+ is_trivially_copy_assignable<_Tp>::value,
+   bool /*_HasTrivialMoveAssignment*/ =
+ is_trivially_move_assignable<_Tp>::value>
 struct _Optional_payload
 {
   constexpr _Optional_payload()
+   : _M_empty() {}
+
+  template 
+  constexpr _Optional_payload(in_place_t, _Args&&... __args)
+   : _M_payload(std::forward<_Args>(__args)...),
+ _M_engaged(true) {}
+
+  template
+  constexpr _Optional_payload(std::initializer_list<_Up> __il,
+ _Args&&... __args)
+   : _M_payload(__il, std::forward<_Args>(__args)...),
+ _M_engaged(true) {}
+  constexpr
+  _Optional_payload(bool __engaged, const _Optional_payload& __other)
+   : _Optional_payload(__other)
+  {}
+
+  constexpr
+  _Optional_payload(bool __engaged, _Optional_payload&& __other)
+   : _Optional_payload(std::move(__other))
+  {}
+
+  constexpr _Optional_payload(const _Optional_payload& __other)
+  {
+   if (__other._M_engaged)
+ this->_M_construct(__other._M_payload);
+  }
+
+  constexpr _Optional_payload(_Optional_payload&& __other)
+  {
+   if (__other._M_engaged)
+ this->_M_construct(std::move(__other._M_payload));
+  }
+
+  _Optional_payload&
+  operator=(const _Optional_payload& __other)
+  {
+if (this->_M_engaged && __other._M_engaged)
+  this->_M_get() = __other._M_get();
+else
+ {
+   if (__other._M_engaged)
+ this->_M_construct(__other._M_get());
+   else
+ this->_M_reset();
+ }
+   return *this;
+  }
+
+  _Optional_payload&
+  operator=(_Optional_payload&& __other)
+  noexcept(__and_,
+ is_nothrow_move_assignable<_Tp>>())
+  {
+   if (this->_M_engaged && __other._M_engaged)
+ this->_M_get() = std::move(__other._M_get());
+   else
+ {
+   if (__other._M_engaged)
+ this->_M_construct(std::move(__other._M_get()));
+   else
+ this->_M_reset();
+ }
+   return *this;
+  }
+
+  using _Stored_type = remove_const_t<_Tp>;
+  struct _Empty_byte { };
+  union {
+  _Empty_byte _M_empty;
+  _Stored_type _M_payload;
+  };
+  bool _M_engaged = false;
+
+  ~_Optional_payload()
+  {
+if (_M_engaged)
+  _M_payload.~_Stored_type();
+  }
+
+  template
+void
+_M_construct(_Args&&... __args)
+noexcept(is_nothrow_constructible<_Stored_type, _Args...>())
+{
+  ::new ((void *) std::__addressof(this->_M_payload))
+_Stored_type(std::forward<_Args>(__args)...);
+  this->_M_engaged = true;
+}
+
+  // The _M_get operations have _M_engaged as a precondition.
+  constexpr _Tp&
+   _M_get() noexcept
+  {
+   return this->_M_payload;
+  }
+
+  constexpr const _Tp&
+   _M_get() const noexcept
+  {
+   return this->_M_payload;
+  }
+
+  // _M_reset is a 'safe' operation with no precondition.
+  void
+  _M_reset() noexcept
+  {
+   if (this->_M_engaged)
+ {
+   this->_M_engaged = false;
+   this->_M_payload.~_Stored_type();
+ }
+  }
+};
+
+  // Payload for constexpr optionals.
+  template 
+struct _Optional_payload<_Tp, true, true, true>
+{
+  constexpr _Optional_payload()
: _M_empty(), _M_engaged(false) {}
 
   template
@@ -161,44 +285,294 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   bool _M_engaged;
 };
 
-  // Payload for optionals with non-trivial destructor.
+  // Payload for optionals with non-trivial copy assignment.
   template 
-struct _Optional_payload<_Tp, false>
+struct _Optional_payload<_Tp, true, false, true>
 {
   constexpr _Optional_payload()
-   : _M_empty() {}
+   : _M_empty(), _M_engaged(false) {}
 
-  template 
+  template
   constexpr _Optional_payload(in_place_t, _Args&&... __args)
: _M_payload(s

[PR c++/84602] ICE with anon-struct

[Nathan Sidwell]

This fixes an ICE with anon-struct.  When reimplementing this bit of 
name lookup, I relied on what the standard said and the completeness of 
the testsuite WRT extensions.  Silly me.


Anyway, we can just have the anon-struct lookup recurse to 
get_class_binding_direct, so simpler!


nathan
--
Nathan Sidwell
2018-02-28  Nathan Sidwell  

	PR c++/84602
	* name-lookup.h (search_anon_aggr): Add defaulted WANT_TYPE arg.
	* name-lookup.c (fields_linear_search): Look in an anon-aggr
	regardless of want_type.
	(search_anon_aggr): Just use get_class_binding_direct.

	PR c++/84602
	* g++.dg/lookup/pr84602.C: New.

Index: cp/name-lookup.c
===
--- cp/name-lookup.c	(revision 258044)
+++ cp/name-lookup.c	(working copy)
@@ -1162,11 +1162,10 @@ fields_linear_search (tree klass, tree n
 {
   tree decl = fields;
 
-  if (!want_type
-	  && TREE_CODE (decl) == FIELD_DECL
+  if (TREE_CODE (decl) == FIELD_DECL
 	  && ANON_AGGR_TYPE_P (TREE_TYPE (decl)))
 	{
-	  if (tree temp = search_anon_aggr (TREE_TYPE (decl), name))
+	  if (tree temp = search_anon_aggr (TREE_TYPE (decl), name, want_type))
 	return temp;
 	}
 
@@ -1191,26 +1190,17 @@ fields_linear_search (tree klass, tree n
   return NULL_TREE;
 }
 
-/* Look for NAME field inside of anonymous aggregate ANON.  */
+/* Look for NAME member inside of anonymous aggregate ANON.  Although
+   such things should only contain FIELD_DECLs, we check that too
+   late, and would give very confusing errors if we weren't
+   permissive here.  */
 
 tree
-search_anon_aggr (tree anon, tree name)
+search_anon_aggr (tree anon, tree name, bool want_type)
 {
   gcc_assert (COMPLETE_TYPE_P (anon));
-  tree ret;
-	  
-  if (vec *member_vec = CLASSTYPE_MEMBER_VEC (anon))
-ret = member_vec_linear_search (member_vec, name);
-  else
-ret = fields_linear_search (anon, name, false);
-
-  if (ret)
-{
-  /* Anon members can only contain fields.  */
-  gcc_assert (!STAT_HACK_P (ret) && !DECL_DECLARES_TYPE_P (ret));
-  return ret;
-}
-  return NULL_TREE;
+  tree ret = get_class_binding_direct (anon, name, want_type);
+  return ret;
 }
 
 /* Look for NAME as an immediate member of KLASS (including
Index: cp/name-lookup.h
===
--- cp/name-lookup.h	(revision 258044)
+++ cp/name-lookup.h	(working copy)
@@ -307,7 +307,7 @@ extern void pop_decl_namespace (void);
 extern void do_namespace_alias (tree, tree);
 extern tree do_class_using_decl (tree, tree);
 extern tree lookup_arg_dependent (tree, tree, vec *);
-extern tree search_anon_aggr (tree, tree);
+extern tree search_anon_aggr (tree, tree, bool = false);
 extern tree get_class_binding_direct (tree, tree, int type_or_fns = -1);
 extern tree get_class_binding (tree, tree, int type_or_fns = -1);
 extern tree *find_member_slot (tree klass, tree name);
Index: testsuite/g++.dg/lookup/pr84602.C
===
--- testsuite/g++.dg/lookup/pr84602.C	(revision 0)
+++ testsuite/g++.dg/lookup/pr84602.C	(working copy)
@@ -0,0 +1,32 @@
+// PR c++/84602 ICE
+// { dg-additional-options "-fpermissive" }
+
+struct X {
+  union {
+class a; // { dg-warning "can only have" }
+  };
+  a *b;
+};
+X::a *a;
+
+struct Y {
+  union {
+class a; // { dg-warning "can only have" }
+int a;
+  };
+  class a *b;
+};
+
+class Y::a *y;
+
+struct Z {
+  union {
+// Force MEMBER_VEC creation
+int a1, a2, a3, a4, a5, a6, a7, a8, a9, a10;
+class a; // { dg-warning "can only have" }
+int a;
+  };
+  class a *b;
+};
+
+class Z::a *z;

Re: [v3 PATCH] PR libstdc++/84601

[Ville Voutilainen]

On 28 February 2018 at 14:27, Ville Voutilainen
 wrote:
> Partially tested on Linux-x64, will run full suite on Linux-PPC64.

Which didn't reveal anything I didn't know, but reminded me to adjust
the negative tests. :)

2018-02-28  Ville Voutilainen  

PR libstdc++/84601
* include/std/optional (_Optional_payload): Split into multiple
specializations that can handle different cases of trivial or
non-trivial assignment operators.
* testsuite/20_util/optional/84601.cc: New.
* testsuite/20_util/optional/cons/value_neg.cc: Adjust.
diff --git a/libstdc++-v3/include/std/optional 
b/libstdc++-v3/include/std/optional
index 01fc06b..0aa20dd 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -98,13 +98,137 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { _GLIBCXX_THROW_OR_ABORT(bad_optional_access()); }
 
 
-  // Payload for constexpr optionals.
+  // Payload for optionals with non-trivial destructor.
   template ::value>
+ is_trivially_destructible<_Tp>::value,
+   bool /*_HasTrivialCopyAssignment*/ =
+ is_trivially_copy_assignable<_Tp>::value,
+   bool /*_HasTrivialMoveAssignment*/ =
+ is_trivially_move_assignable<_Tp>::value>
 struct _Optional_payload
 {
   constexpr _Optional_payload()
+   : _M_empty() {}
+
+  template 
+  constexpr _Optional_payload(in_place_t, _Args&&... __args)
+   : _M_payload(std::forward<_Args>(__args)...),
+ _M_engaged(true) {}
+
+  template
+  constexpr _Optional_payload(std::initializer_list<_Up> __il,
+ _Args&&... __args)
+   : _M_payload(__il, std::forward<_Args>(__args)...),
+ _M_engaged(true) {}
+  constexpr
+  _Optional_payload(bool __engaged, const _Optional_payload& __other)
+   : _Optional_payload(__other)
+  {}
+
+  constexpr
+  _Optional_payload(bool __engaged, _Optional_payload&& __other)
+   : _Optional_payload(std::move(__other))
+  {}
+
+  constexpr _Optional_payload(const _Optional_payload& __other)
+  {
+   if (__other._M_engaged)
+ this->_M_construct(__other._M_payload);
+  }
+
+  constexpr _Optional_payload(_Optional_payload&& __other)
+  {
+   if (__other._M_engaged)
+ this->_M_construct(std::move(__other._M_payload));
+  }
+
+  _Optional_payload&
+  operator=(const _Optional_payload& __other)
+  {
+if (this->_M_engaged && __other._M_engaged)
+  this->_M_get() = __other._M_get();
+else
+ {
+   if (__other._M_engaged)
+ this->_M_construct(__other._M_get());
+   else
+ this->_M_reset();
+ }
+   return *this;
+  }
+
+  _Optional_payload&
+  operator=(_Optional_payload&& __other)
+  noexcept(__and_,
+ is_nothrow_move_assignable<_Tp>>())
+  {
+   if (this->_M_engaged && __other._M_engaged)
+ this->_M_get() = std::move(__other._M_get());
+   else
+ {
+   if (__other._M_engaged)
+ this->_M_construct(std::move(__other._M_get()));
+   else
+ this->_M_reset();
+ }
+   return *this;
+  }
+
+  using _Stored_type = remove_const_t<_Tp>;
+  struct _Empty_byte { };
+  union {
+  _Empty_byte _M_empty;
+  _Stored_type _M_payload;
+  };
+  bool _M_engaged = false;
+
+  ~_Optional_payload()
+  {
+if (_M_engaged)
+  _M_payload.~_Stored_type();
+  }
+
+  template
+void
+_M_construct(_Args&&... __args)
+noexcept(is_nothrow_constructible<_Stored_type, _Args...>())
+{
+  ::new ((void *) std::__addressof(this->_M_payload))
+_Stored_type(std::forward<_Args>(__args)...);
+  this->_M_engaged = true;
+}
+
+  // The _M_get operations have _M_engaged as a precondition.
+  constexpr _Tp&
+   _M_get() noexcept
+  {
+   return this->_M_payload;
+  }
+
+  constexpr const _Tp&
+   _M_get() const noexcept
+  {
+   return this->_M_payload;
+  }
+
+  // _M_reset is a 'safe' operation with no precondition.
+  void
+  _M_reset() noexcept
+  {
+   if (this->_M_engaged)
+ {
+   this->_M_engaged = false;
+   this->_M_payload.~_Stored_type();
+ }
+  }
+};
+
+  // Payload for constexpr optionals.
+  template 
+struct _Optional_payload<_Tp, true, true, true>
+{
+  constexpr _Optional_payload()
: _M_empty(), _M_engaged(false) {}
 
   template
@@ -161,44 +285,294 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   bool _M_engaged;
 };
 
-  // Payload for optionals with non-trivial destructor.
+  // Payload for optionals with non-trivial copy assignment.
   template 
-struct _Optional_payload<_Tp, false>
+struct _Optional_payload<_Tp, true, false, true>
 {
   constexp

[Ada] Fix handling of incomplete types with -fdump-ada-spec (1/2)

[Eric Botcazou]

In some cases, when a type is still incomplete, a pointer to this type will be 
translated as System.Address by -fdump-ada-spec, which is slightly annoying.
This fixes most of these cases and generates proper access types instead.

Tested on x86_64-suse-linux, applied on the mainline.


2018-02-28  Eric Botcazou  

c-family/
* c-ada-spec.c (dump_ada_import): Use boolean and fix formatting.
(is_char_array): Fix formatting.
(dump_template_types): Likewise.
(dump_generic_ada_node): Rename into...
(dump_ada_node): ...this.
: Remove superfluous space.  Use generic address for
incomplete structures and not for empty structures.  Do not use it
when forward declarations are needed.
(dump_forward_type): New function.
(dump_nested_types): Remove FORWARD parameter.  Do not consider
TREE_VISITED and do not generate a forward declaration.  Only dump
original nested types for nested declaration.
(dump_nested_type) : Call dump_forward_type.
: Likewise if the component type is an anonymous pointer.
: Do not consider TREE_VISITED.
(dump_ada_declaration): Use booleans and fix formatting throughout.
: Skip incomplete structures and not empty structures.
Call dump_forward_type instead of dump_nested_types for a typedef.
Remove superfluous check and adjust call to dump_nested_types.
: Call dump_forward_type and fall through.
(dump_ada_struct_decl): Rename into...
(dump_ada_structure): ...this.  Do not special-case empty structures.


2018-02-28  Eric Botcazou  

* c-c++-common/dump-ada-spec-8.c: New test.
* c-c++-common/dump-ada-spec-9.c: Likewise.
* c-c++-common/dump-ada-spec-10.c: Likewise.

-- 
Eric BotcazouIndex: c-ada-spec.c
===
--- c-ada-spec.c	(revision 257983)
+++ c-ada-spec.c	(working copy)
@@ -1590,8 +1590,9 @@ static void
 dump_ada_import (pretty_printer *buffer, tree t)
 {
   const char *name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (t));
-  int is_stdcall = TREE_CODE (t) == FUNCTION_DECL &&
-lookup_attribute ("stdcall", TYPE_ATTRIBUTES (TREE_TYPE (t)));
+  const bool is_stdcall
+= TREE_CODE (t) == FUNCTION_DECL
+  && lookup_attribute ("stdcall", TYPE_ATTRIBUTES (TREE_TYPE (t)));
 
   if (is_stdcall)
 pp_string (buffer, "pragma Import (Stdcall, ");
@@ -2209,9 +2210,9 @@ dump_generic_ada_node (pretty_printer *buffer, tre
   else if (TREE_CODE (TREE_TYPE (node)) == FUNCTION_TYPE)
 	{
 	  if (VOID_TYPE_P (TREE_TYPE (TREE_TYPE (node
-	pp_string (buffer, "access procedure ");
+	pp_string (buffer, "access procedure");
 	  else
-	pp_string (buffer, "access function ");
+	pp_string (buffer, "access function");
 
 	  dump_ada_function_declaration
 	(buffer, node, false, false, false, spc + INDENT_INCR);
@@ -2229,7 +2230,7 @@ dump_generic_ada_node (pretty_printer *buffer, tre
 	}
   else
 	{
-	  int is_access = false;
+	  bool is_access = false;
 	  unsigned int quals = TYPE_QUALS (TREE_TYPE (node));
 
 	  if (VOID_TYPE_P (TREE_TYPE (node)))
@@ -2266,24 +2267,12 @@ dump_generic_ada_node (pretty_printer *buffer, tre
 	  else
 		{
 		  tree type_name = TYPE_NAME (TREE_TYPE (node));
-		  tree decl = get_underlying_decl (TREE_TYPE (node));
-		  tree enclosing_decl = get_underlying_decl (type);
 
-		  /* For now, handle access-to-access, access-to-empty-struct
-		 or access-to-incomplete as opaque system.address.  */
+		  /* For now, handle access-to-access and access-to-incomplete
+		 as opaque System.Address.  */
 		  if (TREE_CODE (TREE_TYPE (node)) == POINTER_TYPE
 		  || (RECORD_OR_UNION_TYPE_P (TREE_TYPE (node))
-			  && !TYPE_FIELDS (TREE_TYPE (node)))
-		  || !decl
-		  || (!enclosing_decl
-			  && !TREE_VISITED (decl)
-			  && DECL_SOURCE_FILE (decl) == current_source_file)
-		  || (enclosing_decl
-			  && !TREE_VISITED (decl)
-			  && DECL_SOURCE_FILE (decl)
-			   == DECL_SOURCE_FILE (enclosing_decl)
-			  && decl_sloc (decl, true)
-			   > decl_sloc (enclosing_decl, true)))
+			  && !COMPLETE_TYPE_P (TREE_TYPE (node
 		{
 		  if (package_prefix)
 			{
@@ -2405,7 +2394,6 @@ dump_generic_ada_node (pretty_printer *buffer, tre
   if (DECL_IS_BUILTIN (node))
 	{
 	  /* Don't print the declaration of built-in types.  */
-
 	  if (name_only)
 	{
 	  /* If we're in the middle of a declaration, defaults to
@@ -2503,12 +2491,56 @@ dump_ada_methods (pretty_printer *buffer, tree nod
   return 1;
 }
 
+/* Dump in BUFFER a forward declaration for TYPE present inside T.
+   SPC is the indentation level.  */
+
+static void
+dump_forward_type (pretty_printer *buffer, tree type, tree t, int spc)
+{
+  tree decl = get_underlying_decl (type);
+
+  /* Anonymous pointer and function types.  */
+  if (!decl)
+{
+  if (TREE_CODE (type) == POINTER_TYPE)
+	dump_forward_

Re: [PR c++/84596] implicit conv in static assert

[Marek Polacek]

On Wed, Feb 28, 2018 at 09:11:24AM -0300, Alexandre Oliva wrote:
> Evaluation of constant expressions, such as those passed to
> static_assert, ICEd when encountering IMPLICIT_CONV_EXPRs.
> 
> Handle them like CONVERT_EXPR and NOP_EXPR.
> 
> Regstrapped on x86_64- and i686-linux-gnu.  Ok to install?
> 
> for  gcc/cp/ChangeLog
> 
>   PR c++/84596
>   * constexpr.c (cxx_eval_constant_expression): Handle
>   IMPLICIT_CONV_EXPR.
> 
> for  gcc/testsuite/ChangeLog
> 
>   PR c++/84596
>   * g++.dg/cpp0x/pr84596.C: New.
> ---
>  gcc/cp/constexpr.c   |1 +
>  gcc/testsuite/g++.dg/cpp0x/pr84596.C |7 +++
>  2 files changed, 8 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr84596.C
> 
> diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> index 4bbdbf434877..d38e2d83ae8c 100644
> --- a/gcc/cp/constexpr.c
> +++ b/gcc/cp/constexpr.c
> @@ -4549,6 +4549,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
> tree t,
>  non_constant_p, overflow_p);
>break;
>  
> +case IMPLICIT_CONV_EXPR:
>  case CONVERT_EXPR:
>  case VIEW_CONVERT_EXPR:
>  case NOP_EXPR:

I don't think it's correct to handle template codes here; they shouldn't
have gotten to cxx_eval_constant_expression in the first place.  Usually
they're substituted in instantiate_non_dependent_expr_internal e.g. via
calling fold_non_dependent_expr.  So I guess we need to find out how
IMPLICIT_CONV_EXPR has gotten there.

Marek

[Ada] Fix handling of incomplete types with -fdump-ada-spec (2/2)

[Eric Botcazou]

This extends the previous change to "opaque" types, i.e. types that are still 
incomplete at the end of the translation unit.

Tested on x86_64-suse-linux, applied on the mainline.


2018-02-28  Eric Botcazou  

c-family/
* c-ada-spec.c (dump_ada_node) : Do not use generic
address for incomplete structures.
(dump_forward_type): Do not bail out for incomplete structures.
(dump_ada_declaration): Do not special-case incomplete structures
for subtypes.  Dump them as null records for types.


2018-02-28  Eric Botcazou  

* c-c++-common/dump-ada-spec-11.c: New test.

-- 
Eric Botcazou/* { dg-do compile } */
/* { dg-options "-fdump-ada-spec" } */

typedef struct T My_T;

int foo1 (My_T *);

int foo2 (My_T *);

/* { dg-final { scan-ada-spec-not "System.Address" } } */
/* { dg-final { cleanup-ada-spec } } */
Index: c-ada-spec.c
===
--- c-ada-spec.c	(revision 258064)
+++ c-ada-spec.c	(working copy)
@@ -2266,11 +2266,8 @@ dump_ada_node (pretty_printer *buffer, tree node,
 		{
 		  tree type_name = TYPE_NAME (TREE_TYPE (node));
 
-		  /* For now, handle access-to-access and access-to-incomplete
-		 as opaque System.Address.  */
-		  if (TREE_CODE (TREE_TYPE (node)) == POINTER_TYPE
-		  || (RECORD_OR_UNION_TYPE_P (TREE_TYPE (node))
-			  && !COMPLETE_TYPE_P (TREE_TYPE (node
+		  /* For now, handle access-to-access as System.Address.  */
+		  if (TREE_CODE (TREE_TYPE (node)) == POINTER_TYPE)
 		{
 		  if (package_prefix)
 			{
@@ -2515,11 +2512,6 @@ dump_forward_type (pretty_printer *buffer, tree ty
   if (DECL_IS_BUILTIN (decl) || TREE_VISITED (decl))
 return;
 
-  /* We'll need to generate a completion at some point.  */
-  if (RECORD_OR_UNION_TYPE_P (TREE_TYPE (decl))
-  && !COMPLETE_TYPE_P (TREE_TYPE (decl)))
-return;
-
   /* Forward declarations are only needed within a given file.  */
   if (DECL_SOURCE_FILE (decl) != DECL_SOURCE_FILE (t))
 return;
@@ -2743,23 +2735,15 @@ dump_ada_declaration (pretty_printer *buffer, tree
 
 	  INDENT (spc);
 
-	  if (RECORD_OR_UNION_TYPE_P (typ) && !COMPLETE_TYPE_P (typ))
-		{
-		  pp_string (buffer, "--  skipped incomplete struct ");
-		  dump_ada_node (buffer, t, type, spc, false, true);
-		}
-	  else
-		{
-		  if (RECORD_OR_UNION_TYPE_P (typ))
-		dump_forward_type (buffer, stub, t, spc);
+	  if (RECORD_OR_UNION_TYPE_P (typ))
+		dump_forward_type (buffer, stub, t, spc);
 
-		  pp_string (buffer, "subtype ");
-		  dump_ada_node (buffer, t, type, spc, false, true);
-		  pp_string (buffer, " is ");
-		  dump_ada_node (buffer, typ, type, spc, false, true);
-		  pp_string (buffer, ";  -- ");
-		  dump_sloc (buffer, t);
-		}
+	  pp_string (buffer, "subtype ");
+	  dump_ada_node (buffer, t, type, spc, false, true);
+	  pp_string (buffer, " is ");
+	  dump_ada_node (buffer, typ, type, spc, false, true);
+	  pp_string (buffer, ";  -- ");
+	  dump_sloc (buffer, t);
 
 	  TREE_VISITED (t) = 1;
 	  return 1;
@@ -2788,8 +2772,10 @@ dump_ada_declaration (pretty_printer *buffer, tree
 	  case UNION_TYPE:
 	if (!COMPLETE_TYPE_P (TREE_TYPE (t)))
 	  {
-		pp_string (buffer, "--  skipped incomplete struct ");
+		pp_string (buffer, "type ");
 		dump_ada_node (buffer, t, type, spc, false, true);
+		pp_string (buffer, " is null record;   -- incomplete struct");
+		TREE_VISITED (t) = 1;
 		return 1;
 	  }
 

[Ada] Fix handling of nested enum types with -fdump-ada-spec

[Eric Botcazou]

They simply have been ignored up to now.

Tested on x86_64-suse-linux, applied on the mainline.


2018-02-28  Eric Botcazou  

c-family/
* c-ada-spec.c (dump_ada_double_name) : New case.
(is_char_array): Take a type instead of a declaration.
(dump_ada_array_type): Likewise.
(is_simple_enum): Minor tweak.
(dump_ada_enum_type): New function extracted from...
(dump_ada_node) : ...here.  Invoke it.
: Remove unreachable code.
: Likewise.  Minor tweaks.
(dump_nested_type) : Adjust to above changes.
: New case.
: Factor out common code.
(dump_ada_declaration) : Adjust to above changes.
Minor tweaks.  Deal with enumeral types.
(dump_ada_structure): Minor tweaks.


2018-02-28  Eric Botcazou  

* c-c++-common/dump-ada-spec-12.c: New test.
* c-c++-common/dump-ada-spec-13.c: Likewise.

-- 
Eric BotcazouIndex: c-ada-spec.c
===
--- c-ada-spec.c	(revision 258066)
+++ c-ada-spec.c	(working copy)
@@ -1511,9 +1511,9 @@ compute_overloading_index (tree decl)
   return index;
 }
 
-/* Dump in BUFFER the name of a DECL node if set, following Ada syntax.
-   LIMITED_ACCESS indicates whether NODE can be accessed via a limited
-   'with' clause rather than a regular 'with' clause.  */
+/* Dump in BUFFER the name of a DECL node if set, in Ada syntax.
+   LIMITED_ACCESS indicates whether NODE can be accessed via a
+   limited 'with' clause rather than a regular 'with' clause.  */
 
 static void
 dump_ada_decl_name (pretty_printer *buffer, tree decl, bool limited_access)
@@ -1571,6 +1571,9 @@ dump_ada_double_name (pretty_printer *buffer, tree
 case ARRAY_TYPE:
   pp_string (buffer, "_array");
   break;
+case ENUMERAL_TYPE:
+  pp_string (buffer, "_enum");
+  break;
 case RECORD_TYPE:
   pp_string (buffer, "_struct");
   break;
@@ -1639,7 +1642,7 @@ check_name (pretty_printer *buffer, tree t)
 }
 }
 
-/* Dump in BUFFER a function declaration FUNC with Ada syntax.
+/* Dump in BUFFER a function declaration FUNC in Ada syntax.
IS_METHOD indicates whether FUNC is a C++ method.
IS_CONSTRUCTOR whether FUNC is a C++ constructor.
IS_DESTRUCTOR whether FUNC is a C++ destructor.
@@ -1777,7 +1780,7 @@ dump_ada_function_declaration (pretty_printer *buf
 }
 
 /* Dump in BUFFER all the domains associated with an array NODE,
-   using Ada syntax.  SPC is the current indentation level.  */
+   in Ada syntax.  SPC is the current indentation level.  */
 
 static void
 dump_ada_array_domains (pretty_printer *buffer, tree node, int spc)
@@ -1837,57 +1840,49 @@ dump_sloc (pretty_printer *buffer, tree node)
 }
 }
 
-/* Return true if T designates a one dimension array of "char".  */
+/* Return true if type T designates a 1-dimension array of "char".  */
 
 static bool
 is_char_array (tree t)
 {
-  tree tmp;
   int num_dim = 0;
 
-  /* Retrieve array's type.  */
-  tmp = t;
-  while (TREE_CODE (TREE_TYPE (tmp)) == ARRAY_TYPE)
+  while (TREE_CODE (t) == ARRAY_TYPE)
 {
   num_dim++;
-  tmp = TREE_TYPE (tmp);
+  t = TREE_TYPE (t);
 }
 
-  tmp = TREE_TYPE (tmp);
   return num_dim == 1
-	 && TREE_CODE (tmp) == INTEGER_TYPE
-	 && id_equal (DECL_NAME (TYPE_NAME (tmp)), "char");
+	 && TREE_CODE (t) == INTEGER_TYPE
+	 && id_equal (DECL_NAME (TYPE_NAME (t)), "char");
 }
 
-/* Dump in BUFFER an array type T in Ada syntax.  Assume that the "type"
-   keyword and name have already been printed.  PARENT is the parent node of T.
-   SPC is the indentation level.  */
+/* Dump in BUFFER an array type NODE of type TYPE in Ada syntax.  SPC is the
+   indentation level.  */
 
 static void
-dump_ada_array_type (pretty_printer *buffer, tree t, tree parent, int spc)
+dump_ada_array_type (pretty_printer *buffer, tree node, tree type, int spc)
 {
-  const bool char_array = is_char_array (t);
-  tree tmp;
+  const bool char_array = is_char_array (node);
 
   /* Special case char arrays.  */
   if (char_array)
-{
-  pp_string (buffer, "Interfaces.C.char_array ");
-}
+pp_string (buffer, "Interfaces.C.char_array ");
   else
 pp_string (buffer, "array ");
 
   /* Print the dimensions.  */
-  dump_ada_array_domains (buffer, TREE_TYPE (t), spc);
+  dump_ada_array_domains (buffer, node, spc);
 
-  /* Retrieve the element type.  */
-  tmp = TREE_TYPE (t);
-  while (TREE_CODE (tmp) == ARRAY_TYPE)
-tmp = TREE_TYPE (tmp);
-
   /* Print array's type.  */
   if (!char_array)
 {
+  /* Retrieve the element type.  */
+  tree tmp = node;
+  while (TREE_CODE (tmp) == ARRAY_TYPE)
+	tmp = TREE_TYPE (tmp);
+
   pp_string (buffer, " of ");
 
   if (TREE_CODE (tmp) != POINTER_TYPE)
@@ -1894,9 +1889,9 @@ static void
 	pp_string (buffer, "aliased ");
 
   if (TYPE_NAME (tmp) || !RECORD_OR_UNION_TYPE_P (tmp))
-	dump_ada_node (buffer, tmp, TREE_TYPE (t), spc, false, true);
+	dump_ada_node (buffer

Don't vectorise zero-step rmw operations (PR 84485)

[Richard Sandiford]

GCC 6 and 7 would vectorise:

void
f (unsigned long incx, unsigned long incy,
   float *restrict dx, float *restrict dy)
{
  unsigned long ix = 0, iy = 0;
  for (unsigned long i = 0; i < 512; ++i)
{
  dy[iy] += dx[ix];
  ix += incx;
  iy += incy;
}
}

without first proving that incy is nonzero.  This is a regression from
GCC 5.  It was fixed on trunk in r223486, which versioned the loop based
on whether incy is zero, but that's obviously too invasive to backport.
This patch instead bails out for non-constant steps in the place that
trunk would try a check for zeroness.

I did wonder about trying to use range information to prove nonzeroness
for SSA_NAMEs, but that would be entirely new code and didn't seem
suitable for a release branch.

Tested on aarch64-linux-gnu.  OK for GCC 7 and 6?  I'll add the testcase
to trunk too.

Richard


2018-02-28  Richard Sandiford  

gcc/
PR tree-optimization/84485
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Return
true for zero dependence distances if either step is variable, and if
there is no metadata that guarantees correctness.

gcc/testsuite/
PR tree-optimization/84485
* gcc.dg/vect/pr84485.c: New test.

Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c   2017-07-27 18:08:43.779978373 +0100
+++ gcc/tree-vect-data-refs.c   2018-02-28 14:16:36.621113244 +
@@ -394,6 +394,16 @@ vect_analyze_data_ref_dependence (struct
}
}
 
+ if (!loop->force_vectorize
+ && (TREE_CODE (DR_STEP (dra)) != INTEGER_CST
+ || TREE_CODE (DR_STEP (drb)) != INTEGER_CST))
+   {
+ if (dump_enabled_p ())
+   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+"step could be zero.\n");
+ return true;
+   }
+
  continue;
}
 
Index: gcc/testsuite/gcc.dg/vect/pr84485.c
===
--- /dev/null   2018-02-26 10:26:41.624847060 +
+++ gcc/testsuite/gcc.dg/vect/pr84485.c 2018-02-28 14:16:36.620112862 +
@@ -0,0 +1,34 @@
+/* { dg-do run } */
+
+#include "tree-vect.h"
+
+#define N 256
+
+void __attribute__ ((noinline, noclone))
+f (unsigned long incx, unsigned long incy,
+   float *restrict dx, float *restrict dy)
+{
+  unsigned long ix = 0, iy = 0;
+  for (unsigned long i = 0; i < N; ++i)
+{
+  dy[iy] += dx[ix];
+  ix += incx;
+  iy += incy;
+}
+}
+
+float a = 0.0;
+float b[N];
+
+int
+main (void)
+{
+  check_vect ();
+
+  for (int i = 0; i < N; ++i)
+b[i] = i;
+  f (1, 0, b, &a);
+  if (a != N * (N - 1) / 2)
+__builtin_abort ();
+  return 0;
+}

[Ada] Generate minimally correct C/C++ binding for stddef.h

[Eric Botcazou]

This was broken when the default was changed to C11/C++11.

Tested on x86_64-suse-linux, applied on the mainline.


2018-02-28  Eric Botcazou  

ada/
* libgnat/i-cexten.ads (Float_128): New type.

c-family/
* c-ada-spec.c (dump_ada_node) : New case.
: Deal specifically with _Float128/__float128.

-- 
Eric BotcazouIndex: ada/libgnat/i-cexten.ads
===
--- ada/libgnat/i-cexten.ads	(revision 257983)
+++ ada/libgnat/i-cexten.ads	(working copy)
@@ -72,6 +72,15 @@ package Interfaces.C.Extensions is
pragma Convention (C_Pass_By_Copy, Signed_128);
for Signed_128'Alignment use unsigned_long_long'Alignment * 2;
 
+   --  128-bit floating-point type available on x86:
+   --  typedef long_double float_128 __attribute__ ((mode (TF)));
+
+   type Float_128 is record
+  low, high : unsigned_long_long;
+   end record;
+   pragma Convention (C_Pass_By_Copy, Float_128);
+   for Float_128'Alignment use unsigned_long_long'Alignment * 2;
+
--  Types for bitfields
 
type Unsigned_1 is mod 2 ** 1;
Index: c-family/c-ada-spec.c
===
--- c-family/c-ada-spec.c	(revision 258067)
+++ c-family/c-ada-spec.c	(working copy)
@@ -2126,6 +2126,7 @@ dump_ada_node (pretty_printer *buffer, tree node,
   pp_string (buffer, "--- unexpected node: TREE_VEC");
   return 0;
 
+case NULLPTR_TYPE:
 case VOID_TYPE:
   if (package_prefix)
 	{
@@ -2151,8 +2152,20 @@ dump_ada_node (pretty_printer *buffer, tree node,
 	dump_ada_enum_type (buffer, node, type, spc, true);
   break;
 
+case REAL_TYPE:
+  if (TYPE_NAME (node)
+	  && TREE_CODE (TYPE_NAME (node)) == TYPE_DECL
+	  && IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (node))) [0] == '_'
+	  && (id_equal (DECL_NAME (TYPE_NAME (node)), "_Float128")
+	  || id_equal (DECL_NAME (TYPE_NAME (node)), "__float128")))
+	{
+	  append_withs ("Interfaces.C.Extensions", false);
+	  pp_string (buffer, "Extensions.Float_128");
+	  break;
+	}
+  /* fallthrough */
+
 case INTEGER_TYPE:
-case REAL_TYPE:
 case FIXED_POINT_TYPE:
 case BOOLEAN_TYPE:
   if (TYPE_NAME (node))
@@ -2233,9 +2246,8 @@ dump_ada_node (pretty_printer *buffer, tree node,
 	{
 	  if (TREE_CODE (node) == POINTER_TYPE
 		  && TREE_CODE (TREE_TYPE (node)) == INTEGER_TYPE
-		  && !strcmp
-			(IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME
-			  (TREE_TYPE (node, "char"))
+		  && id_equal (DECL_NAME (TYPE_NAME (TREE_TYPE (node))),
+			   "char"))
 		{
 		  if (!name_only)
 		pp_string (buffer, "new ");

Re: C++ PATCH to fix static init with () in a template (PR c++/84582)

[Marek Polacek]

On Tue, Feb 27, 2018 at 04:16:31PM -0500, Jason Merrill wrote:
> On 02/27/2018 02:13 PM, Marek Polacek wrote:
> > My recent change introducing cxx_constant_init caused this code
> > 
> > template  class A {
> >static const long b = 0;
> >static const unsigned c = (b);
> > };
> > 
> > to be rejected.  The reason is that force_paren_expr turns "b" into "*(const
> > long int &) &b", where the former is not value-dependent but the latter is
> > value-dependent.  So when we get to maybe_constant_init_1:
> > 5147   if (!is_nondependent_static_init_expression (t))
> > 5148 /* Don't try to evaluate it.  */;
> > it's not evaluated and we get the non-constant initialization error.
> > (Before we'd always evaluated the expression.)
> > 
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> > 
> > 2018-02-27  Marek Polacek  
> > 
> > PR c++/84582
> > * semantics.c (force_paren_expr): Avoid creating a static cast
> > when processing a template.
> > 
> > * g++.dg/cpp1z/static1.C: New test.
> > * g++.dg/template/static37.C: New test.
> > 
> > diff --git gcc/cp/semantics.c gcc/cp/semantics.c
> > index 35569d0cb0d..b48de2df4e2 100644
> > --- gcc/cp/semantics.c
> > +++ gcc/cp/semantics.c
> > @@ -1697,7 +1697,7 @@ force_paren_expr (tree expr)
> >   expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
> > else if (VAR_P (expr) && DECL_HARD_REGISTER (expr))
> >   /* We can't bind a hard register variable to a reference.  */;
> > -  else
> > +  else if (!processing_template_decl)
> 
> Hmm, this means that we forget about the parentheses in a template.  I'm
> surprised that this didn't break anything in the testsuite.  In particular,
> auto-fn15.C.  I've attached an addition to auto-fn15.C to catch this issue.

Thanks, you're right.  I'll use it.

> Can we use PAREN_EXPR instead of the static_cast in a template?

I don't think so, it would fix the issue you pointed out in auto-fn15.C but
it wouldn't fix the original test.  The problem with using PAREN_EXPR in a
template is that instantiate_non_dependent_expr will turn in into the
static cast anyway; tsubst_copy_and_build has
case PAREN_EXPR:
  RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t, 0;
so it calls force_paren_expr and this time we're not in a template.  And
then when calling cxx_constant_init we have the same issue.

Should we play some ugly games with maybe_undo_parenthesized_ref?

Marek

[C++ Patch/RFC] PR 71569 ("[6/7/8 regression] Crash: External definition of template member from template struct")

[Paolo Carlini]

Hi,

in this P2 ICE on invalid we fail to diagnose an ill-formed variable 
template partial specialization and the assert at the beginning of 
determine_specialization triggers. Indeed, we didn't diagnose the 
problem via check_specialization_scope (there are no template <>, thus 
begin_specialization isn't involved). Simply adding a specific check to 
check_explicit_specialization exactly when we recognize a variable 
template partial specialization seems a safe thing to do and passes 
testing. Not sure if the test itself is as simple as possible or is 
better done somewhere else...


Thanks, Paolo.

//

Index: cp/pt.c
===
--- cp/pt.c (revision 258059)
+++ cp/pt.c (working copy)
@@ -2873,7 +2873,12 @@ check_explicit_specialization (tree declarator,
  /* Partial specialization of variable template.  */
  SET_DECL_TEMPLATE_SPECIALIZATION (decl);
  specialization = 1;
- goto ok;
+ if (template_count && DECL_CLASS_SCOPE_P (decl)
+ && template_class_depth (DECL_CONTEXT (decl)) > 0)
+   error ("variable template partial specialization %qD does "
+  "not specialize any template arguments", declarator);
+ else
+   goto ok;
}
  else if (cxx_dialect < cxx14)
error ("non-type partial specialization %qD "
Index: testsuite/g++.dg/cpp1y/var-templ58.C
===
--- testsuite/g++.dg/cpp1y/var-templ58.C(nonexistent)
+++ testsuite/g++.dg/cpp1y/var-templ58.C(working copy)
@@ -0,0 +1,13 @@
+// PR c++/71569
+// { dg-do compile { target c++14 } }
+
+template 
+class Foo
+{
+template 
+static bool Bar;
+};
+
+template
+template
+bool Foo::Bar;  // { dg-error "variable template partial" }

[PATCH] Fix i18n in warn_spec_missing_attributes (PR 83871)

[Jakub Jelinek]

On Tue, Feb 27, 2018 at 05:52:03PM -0700, Martin Sebor wrote:
> > This is broken for multiple reasons:
> > 1) it should be inform_n rather than inform
> > 2) you really can't do what you're doing for translations;
> >G_(...) marks the string for translations, but what actually is
> >translated is not that string, but rather what is passed to inform,
> >i.e. str.c_str (), so it will be likely never translated
> > 3) as others have mentioned, the #include  you are doing is
> >wrong
> > 4) I don't see justification to use std::string here
> > 
> > What you IMHO should use instead is use
> >   pretty_printer str;
> > instead, and the pp_* APIs to add stuff in there, including
> > pp_begin_quote (&str, pp_show_color (global_dc->printer))
> > and
> > pp_end_quote (&str, pp_show_color (global_dc->printer))
> > when you want to add what %< or %> expand to,
> > and finally
> >   inform_n (DECL_SOURCE_LOCATION (tmpl), nattrs,
> > "missing primary template attribute %s",
> > "missing primary template attributes %s",
> > pp_formatted_text (&str));
> > That way it should be properly translatable.
> 
> Using inform_n() would not be correct here.  What's being
> translated is one of exactly two forms: singular and plural.
> It doesn't matter how many things the plural form refers to
> because the number doesn't appear in the message.  Let's ask
> Google to translate the message above to a language with more
> than two plural forms, such as Czech:
> 
> there are missing attributes:
> https://translate.google.com/?tl=cs#auto/cs/there%20are%20missing%20attributes
> 
> vs there are 5 missing attributes:
> https://translate.google.com/?tl=cs#auto/cs/there%20are%205%20missing%20attributes
> 
> Only the first form is correct when the exact number isn't
> mentioned.

I stand corrected on 1) (though wonder if there are locales
which have different plurals based on the count in the list).

> There are many places in the C++ front-end where a string
> enclosed in G_() is assigned to a pointer and later used
> in a diagnostic call.  Is there something different about
> the usage I introduced that makes it unsuitable for
> translation?

G_() does what it is designed for, collects a string for
exgettext extraction into *.pot file.  For most of the
diagnostic calls we have arranged automatic extractions of
the string literals passed directly to the functions, so we don't need
to type it in most places, just where there is a conditional or
the string is elsewhere.  The problem in your code is that
you mark using G_() for translation one string literal,
e.g.
G_("missing primary template attributes ")
but then actually call inform with something different, like:
"missing primary template attributes %, %"
Functions inform will call will call gettext to translate that, but
as this second string is dynamic and never in the *.pot file, nobody
will translate it and so the inform will be always in English, even
when some translator translates everything he is provided.

And another advantage of using the %s appart from translatability is
that it is -Wformat-security compatible.

> std::string is used in a number of places in GCC.  Why does
> using it here need any special justification?

Outside of config/*/* (aarch64, arm, nvptx, sh backends only) where
the maintainers chose to use it, it is used just in a single file,
ipa-chkp.c which is going away soon, all the diagnostics uses the pretty
printers infrastructure instead.  More importantly, with the latter
you can do the begin/end quotes easily, with std::string you can't, unless
you just use pretty printers and convert that to std::string, at which point
it is certainly less efficient.

> Using the pretty printer as you suggest also sounds
> complicated to me and so prone to error but I will defer
> to Jason's opinion to decide if any changes are necessary.

Here it is in patch form, tested so far with:
make check-c++-all RUNTESTFLAGS="--target_board=unix\{-m32,-m64\} 
dg.exp='attr*.C Wmissing-attrib*'"
and waiting for bootstrap/regtest, ok for trunk if it passes?

2018-02-28  Jakub Jelinek  

PR c++/83871
PR c++/83503
* pt.c (INCLUDE_STRING): Remove define.
(warn_spec_missing_attributes): Use pretty_printer instead of
std::string.  Fix up inform call so that the list of attributes
is in %s argument.

--- gcc/cp/pt.c.jj  2018-02-28 09:55:57.830897618 +0100
+++ gcc/cp/pt.c 2018-02-28 11:00:52.185543847 +0100
@@ -25,7 +25,6 @@ along with GCC; see the file COPYING3.
  file that contains only the method templates and "just win".  */
 
 #include "config.h"
-#define INCLUDE_STRING
 #include "system.h"
 #include "coretypes.h"
 #include "cp-tree.h"
@@ -2681,7 +2680,7 @@ warn_spec_missing_attributes (tree tmpl,
  template is declared with that the specialization is not, in case
  it's not apparent from the most recent declaration of the primary.  */
   unsigned nattrs = 0;
-  std::string str;
+  pr

[PATCH, rs6000] Fix PR84534: several powerpc test cases fail starting with r257915

[Peter Bergner]

This patch fixes PR84534 by XFAILing one test because we are deprecating
-maltivec=be when run on LE.  The other tests are fixed by not counting
xxlor insns.  We cannot rely on stable counts of xxlor insns, because we
generate them not only when using __builtin_vec_or(), but also whenever
we need to copy one vsx reg to another...which can vary depending on
previous optimizations, moon phases, etc.  Therefore, we just make sure
we generate at least one.  I'll note I did try adding -dp and seeing
which patterns generated the xxlors, but there wasn't a clear match
between the xxlor's generated because of the __builtin_vec_or and the
reg copies.

Ok for trunk?

Peter

gcc/testsuite/
PR target/84534
* gcc.target/powerpc/vec-setup-be-long.c: xfail.
* gcc.target/powerpc/vsx-vector-6-le.c: Do not count xxlor's.
* gcc.target/powerpc/vsx-vector-6-le.p9.c: Likewise.

Index: gcc/testsuite/gcc.target/powerpc/vec-setup-be-long.c
===
--- gcc/testsuite/gcc.target/powerpc/vec-setup-be-long.c(revision 
258038)
+++ gcc/testsuite/gcc.target/powerpc/vec-setup-be-long.c(working copy)
@@ -1,4 +1,6 @@
-/* { dg-do run { target { powerpc64le*-*-linux* } } } */
+/* Per PR78303, we are deprecating usage of -maltivec=be on little endian,
+   so XFAIL this test until support is actually removed.  */
+/* { dg-do run xfail { powerpc64le*-*-linux* } } } */
 /* { dg-require-effective-target vsx_hw } */
 /* Disable warnings to squelch deprecation message about -maltivec=be.  */
 /* { dg-options "-w -O2 -mvsx -maltivec=be" } */
Index: gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c  (revision 258038)
+++ gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c  (working copy)
@@ -9,7 +9,7 @@
 /* { dg-final { scan-assembler-times "xvabsdp" 1 } } */
 /* { dg-final { scan-assembler-times "xvadddp" 1 } } */
 /* { dg-final { scan-assembler-times "xxlnor" 8 } } */
-/* { dg-final { scan-assembler-times "xxlor" 30 } } */
+/* { dg-final { scan-assembler "xxlor" } } */
 /* { dg-final { scan-assembler-times "xvcmpeqdp" 5 } } */
 /* { dg-final { scan-assembler-times "xvcmpgtdp" 8 } } */
 /* { dg-final { scan-assembler-times "xvcmpgedp" 6 } } */
Index: gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.p9.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.p9.c   (revision 
258038)
+++ gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.p9.c   (working copy)
@@ -9,7 +9,7 @@
 /* { dg-final { scan-assembler-times "xvabsdp" 1 } } */
 /* { dg-final { scan-assembler-times "xvadddp" 1 } } */
 /* { dg-final { scan-assembler-times "xxlnor" 7 } } */
-/* { dg-final { scan-assembler-times "xxlor" 20 } } */
+/* { dg-final { scan-assembler "xxlor" } } */
 /* { dg-final { scan-assembler-times "xvcmpeqdp" 5 } } */
 /* { dg-final { scan-assembler-times "xvcmpgtdp" 8 } } */
 /* { dg-final { scan-assembler-times "xvcmpgedp" 8 } } */

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

[Jeff Law]

On 02/28/2018 03:48 AM, Richard Biener wrote:
> On Wed, Feb 28, 2018 at 11:43 AM, Richard Biener
>  wrote:
>> On Wed, Feb 28, 2018 at 1:16 AM, Jeff Law  wrote:
>>> Richi, you worked on 57147 which touches on the issues here.  Your
>>> thoughts would be greatly appreciated.
>>>
>>>
>>> So 61118 is one of several bugs related to the clobbered-by-longjmp warning.
>>>
>>> In 61118 is we are unable to coalesce all the objects in the key
>>> partitions.  To remove the relevant PHIs we have to create two
>>> assignments to the key pseudos.
>>>
>>> Pseudos with more than one assignment are subject to the
>>> clobbered-by-longjmp analysis:
>>>
>>>  * True if register REGNO was alive at a place where `setjmp' was
>>>called and was set more than once or is an argument.  Such regs may
>>>be clobbered by `longjmp'.  */
>>>
>>> static bool
>>> regno_clobbered_at_setjmp (bitmap setjmp_crosses, int regno)
>>> {
>>>   /* There appear to be cases where some local vars never reach the
>>>  backend but have bogus regnos.  */
>>>   if (regno >= max_reg_num ())
>>> return false;
>>>
>>>   return ((REG_N_SETS (regno) > 1
>>>|| REGNO_REG_SET_P (df_get_live_out (ENTRY_BLOCK_PTR_FOR_FN
>>> (cfun)),
>>>regno))
>>>   && REGNO_REG_SET_P (setjmp_crosses, regno));
>>> }
>>>
>>>
>>> The fact that no path sets the pseudo more than once is not considered.
>>> If there is more than one static set of the pseudo, then it is
>>> considered for possible warning.
>>>
>>> --
>>>
>>>
>>> I looked at the propagations which led to the inability to coalesce.
>>> They all seemed valid to me.  We have always allowed copy propagation to
>>> replace one pseudo with another as long as neither has
>>> SSA_NAME_USED_IN_ABNORMAL_PHI set.
>>>
>>> We have a PHI like
>>>
>>> x1(ab) = (x0, x3 (ab))
>>>
>>> x0 is not marked as abnormal because the edge isn't abnormal and thus we
>>> can propagate into the x0 argument of the PHI.  This is consistent with
>>> behavior since, well, forever.   We propagate a value for x0 resulting
>>> in something like
>>>
>>> x1(b) = (y0, x3 (ab))
>>>
>>>
>>> Where y0 is still live across the PHI.  Thus the partition for x1/x3,
>>> etc conflicts with the partition for y0 and they can not be coalesced.
>>> This leads to the multiple assignments to the pseudo for the x1/x3
>>> partition.  I briefly looked marking all the PHI arguments as abnormal
>>> when the destination is abnormal, but it just doesn't seem right.
>>>
>>> Anyway, I'd already been looking at 21161 and was aware that the CFG's
>>> we're building in presence of setjmp/longjmp were slightly inaccurate.
>>>
>>> In particular, a longjmp returns to the point immediately after the
>>> setjmp, not to the setjmp itself.  But our CFG building has the edge
>>> from the abnormal dispatcher going to the block containing the setjmp call.
>>
>> Yeah...  for SJLJ EH we get this right via __builtin_setjmp_receiver.
>>
>>> This creates unnecessary irreducible loops.  It turns out that if we fix
>>> the tree CFG, then lifetimes become more accurate (and more
>>> constrained).  The more constrained, more accurate lifetime information
>>> is enough to allow things to coalesce the way we want and everything for
>>> 61118 just works.
>>
>> Sounds good.
> 
> Oh - and to mention it, we have one long-standing issue after me trying
> to fix things here which is that RTL doesn't have all those abnormal edges
> for setjmp and friends because we throw away abnormal edges during
> RTL expansion and expect to recompute them...
> 
> IIRC there's a bugreport about this to track this issue and the fix is57147
> to stop removing abnormal edges and instread transition them to RTL:
> 
>   /* At the moment not all abnormal edges match the RTL
>  representation.  It is safe to remove them here as
>  find_many_sub_basic_blocks will rediscover them.
>  In the future we should get this fixed properly.  */
>   if ((e->flags & EDGE_ABNORMAL)
>   && !(e->flags & EDGE_SIBCALL))
> remove_edge (e);
> 
> not sure if we can use an edge flag to mark those we want to preserve.
> But I don't understand the comment very well - why would any abnormal
> edges not "match" the RTL representation?
Yea, I was a bit surprised when I found out the lack of coordination
between gimple and RTL on this stuff.  I got as far as realizing that
the gimple edges related to setjmp/longjmp were dropped on the floor
when looking at 21161.  Fixing the CFG in gimple made absolutely no
difference and surprised the hell out of me.

Luckily I had the code stashed and could resurrect it when I realized
61118 was a problem with life analysis/coalescing caused by the slight
incorrectness in the gimple CFG.

For 21161 we end up needing to scan the RTL after the call to find the
condjump.  Then we figure out where the condjump goes.  That allows us
to look at the registers live on the longjmp path as opposed t

Re: [PATCH, rs6000] Fix PR83399, ICE During LRA with 2-op rtl pattern for lvx instruction

[Peter Bergner]

On 1/10/18 3:10 PM, Peter Bergner wrote:
> gcc/
> PR target/83399
> * config/rs6000/rs6000.c (print_operand) <'y'>: Use
> VECTOR_MEM_ALTIVEC_OR_VSX_P.
> * config/rs6000/vsx.md (*vsx_le_perm_load_ for VSX_D): Use
> indexed_or_indirect_operand predicate.
> (*vsx_le_perm_load_ for VSX_W): Likewise.
> (*vsx_le_perm_load_v8hi): Likewise.
> (*vsx_le_perm_load_v16qi): Likewise.
> (*vsx_le_perm_store_ for VSX_D): Likewise.
> (*vsx_le_perm_store_ for VSX_W): Likewise.
> (*vsx_le_perm_store_v8hi): Likewise.
> (*vsx_le_perm_store_v16qi): Likewise.
> (eight unnamed splitters): Likewise.
> 
> gcc/testsuite/
> PR target/83399
> * gcc.target/powerpc/pr83399.c: New test.

David reported that the new test case was failing on AIX because -mlittle
is not supported there.  I have committed as obvious the following patch
that limits the test being run on Linux only.

Peter

PR target/83399
* gcc.target/powerpc/pr83399.c: Only run on Linux.

PR tree-optimization/84584
Index: gcc/testsuite/gcc.target/powerpc/pr83399.c
===
--- gcc/testsuite/gcc.target/powerpc/pr83399.c  (revision 258070)
+++ gcc/testsuite/gcc.target/powerpc/pr83399.c  (working copy)
@@ -1,5 +1,5 @@
 /* PR target/83399 */
-/* { dg-do compile } */
+/* { dg-do compile { target { powerpc*-*-linux* } } } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
 /* { dg-options "-O1 -mabi=elfv2 -mlittle -mvsx" } */

Re: Don't vectorise zero-step rmw operations (PR 84485)

[Jakub Jelinek]

On Wed, Feb 28, 2018 at 02:20:27PM +, Richard Sandiford wrote:
> GCC 6 and 7 would vectorise:
> 
> void
> f (unsigned long incx, unsigned long incy,
>float *restrict dx, float *restrict dy)
> {
>   unsigned long ix = 0, iy = 0;
>   for (unsigned long i = 0; i < 512; ++i)
> {
>   dy[iy] += dx[ix];
>   ix += incx;
>   iy += incy;
> }
> }
> 
> without first proving that incy is nonzero.  This is a regression from
> GCC 5.  It was fixed on trunk in r223486, which versioned the loop based

Are you sure about the revision?  This one is from 2015 and so should be in
all of GCC 6/7/8.

Jakub

Re: C++ PATCH to fix static init with () in a template (PR c++/84582)

[Jason Merrill]

On Wed, Feb 28, 2018 at 9:32 AM, Marek Polacek  wrote:
> On Tue, Feb 27, 2018 at 04:16:31PM -0500, Jason Merrill wrote:
>> On 02/27/2018 02:13 PM, Marek Polacek wrote:
>> > My recent change introducing cxx_constant_init caused this code
>> >
>> > template  class A {
>> >static const long b = 0;
>> >static const unsigned c = (b);
>> > };
>> >
>> > to be rejected.  The reason is that force_paren_expr turns "b" into 
>> > "*(const
>> > long int &) &b", where the former is not value-dependent but the latter is
>> > value-dependent.  So when we get to maybe_constant_init_1:
>> > 5147   if (!is_nondependent_static_init_expression (t))
>> > 5148 /* Don't try to evaluate it.  */;
>> > it's not evaluated and we get the non-constant initialization error.
>> > (Before we'd always evaluated the expression.)
>> >
>> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
>> >
>> > 2018-02-27  Marek Polacek  
>> >
>> > PR c++/84582
>> > * semantics.c (force_paren_expr): Avoid creating a static cast
>> > when processing a template.
>> >
>> > * g++.dg/cpp1z/static1.C: New test.
>> > * g++.dg/template/static37.C: New test.
>> >
>> > diff --git gcc/cp/semantics.c gcc/cp/semantics.c
>> > index 35569d0cb0d..b48de2df4e2 100644
>> > --- gcc/cp/semantics.c
>> > +++ gcc/cp/semantics.c
>> > @@ -1697,7 +1697,7 @@ force_paren_expr (tree expr)
>> >   expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
>> > else if (VAR_P (expr) && DECL_HARD_REGISTER (expr))
>> >   /* We can't bind a hard register variable to a reference.  */;
>> > -  else
>> > +  else if (!processing_template_decl)
>>
>> Hmm, this means that we forget about the parentheses in a template.  I'm
>> surprised that this didn't break anything in the testsuite.  In particular,
>> auto-fn15.C.  I've attached an addition to auto-fn15.C to catch this issue.
>
> Thanks, you're right.  I'll use it.
>
>> Can we use PAREN_EXPR instead of the static_cast in a template?
>
> I don't think so, it would fix the issue you pointed out in auto-fn15.C but
> it wouldn't fix the original test.  The problem with using PAREN_EXPR in a
> template is that instantiate_non_dependent_expr will turn in into the
> static cast anyway; tsubst_copy_and_build has
> case PAREN_EXPR:
>   RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t, 0;
> so it calls force_paren_expr and this time we're not in a template.  And
> then when calling cxx_constant_init we have the same issue.

Then maybe we need something like fold_non_dependent_expr, which
checks for dependency before substitution and then immediately
evaluates the result.

Jason

Re: [C++ Patch/RFC] PR 71569 ("[6/7/8 regression] Crash: External definition of template member from template struct")

[Jason Merrill]

On Wed, Feb 28, 2018 at 9:36 AM, Paolo Carlini  wrote:
> in this P2 ICE on invalid we fail to diagnose an ill-formed variable
> template partial specialization and the assert at the beginning of
> determine_specialization triggers. Indeed, we didn't diagnose the problem
> via check_specialization_scope (there are no template <>, thus
> begin_specialization isn't involved). Simply adding a specific check to
> check_explicit_specialization exactly when we recognize a variable template
> partial specialization seems a safe thing to do and passes testing. Not sure
> if the test itself is as simple as possible or is better done somewhere
> else...

Hmm, this doesn't look like the user intended to write a partial
specialization, but rather that they were trying to define the member
template and wrote the template arguments out by mistake.

Jason

Re: PING: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER

[Jeff Law]

On 02/28/2018 02:39 AM, Steve Beattie wrote:
> Hi Jeff,
> 
> On Thu, Feb 22, 2018 at 10:10:13AM -0700, Jeff Law wrote:
>> A few notes.
>>
>> 1. It's not even clear at this time that retpolining user space binaries
>> makes any sense at all.   SO before doing anything to make this easier
>> I'd like to see a justification for why it's really needed.
> 
> Do you have a reference that gives evidence that retpolining user
> space is not needed or not preferred for x86? Everything that I've
> seen has suggested user space to user space attacks are possible,
> if difficult. And it does not seem likely that microcode updates will
> occur for all processor generations out there.
No reference, but that's general conclusion we've come to internally
with input from Intel.

Essentially you use the newly exposed capabilities from the microcode
updates to flush the state of the indirect predictor at context switch
time.  Combine that with the microcode change to stop sharing indirect
branch prediction state between SMT threads.

I'm being a bit imprecise, but that's the gist.


> 
>> 2. On the other hand, the existing thunk options do make it easier to
>> test independent of hte kernel.  ie, I can turn on inline thunks by
>> default and test things in user space (ie, do thunks generally work
>> properly).
> 
> If thunk-extern is to be the only maintained option, and its deemed
> sensible for user space in at least some situations, is there a
> preferred location for the thunks to end up?
Ideally you'd have one set of thunks per DSO.  Otherwise you end up
doing an indirect branch for the cross-DSO call to get to the thunk
which largely defeats the purpose of the thunks to begin with.


> 
> (I ask these questions because you can already find individual users
> recompiling apps important to them with retpoline options, and there
> is pressure (with associated deadlines) in some quarters to rebuild
> vast tracts of user space with retpolines for x86.)
I know.  I've given up trying to educate all of them.  I expected all
along that well intentioned, but ultimately clueless, folks would start
doing this kind of thing.

jeff



signature.asc
Description: OpenPGP digital signature

Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)

[Martin Sebor]

On 02/28/2018 02:51 AM, Jakub Jelinek wrote:

On Mon, Feb 26, 2018 at 09:19:56PM -0700, Martin Sebor wrote:

PR c++/83871
PR c++/83503
* g++.dg/ext/attr-const.C: New test.
* g++.dg/ext/attr-pure.C: New test.


I've tried to fix these 2 tests with following patch, without
-fdump-tree-optimized all the scan-tree-dump* tests are UNRESOLVED,
and when you use the same function for multiple-subtests all you get
is the same failures reported multiple times, but without knowing which
of them failed.

Unfortunately, even with this patch there are failures:
FAIL: g++.dg/ext/attr-const.C  -std=gnu++11  scan-tree-dump-not optimized 
"test_func_none_const_failed"

...

so if the test is right, then something is still broken on the C++ FE side.

I'll defer debugging this to you.


Thanks for fixing up the unresolved tests.  I have a script that
checks test results against a baseline for unexpected failures
but it doesn't look for differences in UNRESOLVED so I didn't
see them as problems.  I'll have to remember to enhance it to
do that.

With the unresolved problems fixed, the remaining failures are
due to two problems:

1) A regression in the merging of attributes introduced by my
   patch.  I wondered about why attributes const and pure were
   being handled differently than the others here:
   https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01479.html
   Jason explained that parts of the structure were being copied
   via memcpy.  Since I thought my tests were passing I took that
   to mean that the bits were being copied.  Sigh.

2) A pre-existing bug where the C++ front end doesn't apply
   an attribute to a declaration of a function template previously
   declared without one, as in:

   template  int f ();
   template  int __attribute__ ((const)) f ();

   The root cause might be the same as the one behind bug 84294
   - missing warning for ignored attribute on a function template
   declaration.

Let me fix the first one and see what it would take to handle
the second as well.

Martin

Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)

[Jason Merrill]

On Tue, Feb 27, 2018 at 7:52 PM, Martin Sebor  wrote:
> There are many places in the C++ front-end where a string
> enclosed in G_() is assigned to a pointer and later used
> in a diagnostic call.  Is there something different about
> the usage I introduced that makes it unsuitable for
> translation?

The difference is that you append to the string before it is used.

Looks like the _ macro might work better in this case?

Jason

Re: [C++ Patch/RFC] PR 71569 ("[6/7/8 regression] Crash: External definition of template member from template struct")

[Paolo Carlini]

Hi,

On 28/02/2018 16:53, Jason Merrill wrote:

On Wed, Feb 28, 2018 at 9:36 AM, Paolo Carlini  wrote:

in this P2 ICE on invalid we fail to diagnose an ill-formed variable
template partial specialization and the assert at the beginning of
determine_specialization triggers. Indeed, we didn't diagnose the problem
via check_specialization_scope (there are no template <>, thus
begin_specialization isn't involved). Simply adding a specific check to
check_explicit_specialization exactly when we recognize a variable template
partial specialization seems a safe thing to do and passes testing. Not sure
if the test itself is as simple as possible or is better done somewhere
else...

Hmm, this doesn't look like the user intended to write a partial
specialization, but rather that they were trying to define the member
template and wrote the template arguments out by mistake.
I see your point. If I understand correctly, in such cases clang somehow 
talks about both possibilities:


error: variable template partial specialization does not specialize any 
template argument; to define the primary template, remove the template 
argument list


What do you think, should we do something similar? (by the way, 
yesterday got a bit confused because in other vaguely related cases 
clang also has this kind of two-part error message and we don't. Eg, I 
cooked up:


template 
class Foo
{
  template 
  class Bar;
};

template
template
class Foo::Bar;

Thanks,
Paolo.

Re: [C++ Patch/RFC] PR 71569 ("[6/7/8 regression] Crash: External definition of template member from template struct")

[Jason Merrill]

On Wed, Feb 28, 2018 at 11:18 AM, Paolo Carlini
 wrote:
> On 28/02/2018 16:53, Jason Merrill wrote:
>> On Wed, Feb 28, 2018 at 9:36 AM, Paolo Carlini 
>> wrote:
>>>
>>> in this P2 ICE on invalid we fail to diagnose an ill-formed variable
>>> template partial specialization and the assert at the beginning of
>>> determine_specialization triggers. Indeed, we didn't diagnose the problem
>>> via check_specialization_scope (there are no template <>, thus
>>> begin_specialization isn't involved). Simply adding a specific check to
>>> check_explicit_specialization exactly when we recognize a variable template
>>> partial specialization seems a safe thing to do and passes testing. Not sure
>>> if the test itself is as simple as possible or is better done somewhere
>>> else...
>>
>> Hmm, this doesn't look like the user intended to write a partial
>> specialization, but rather that they were trying to define the member
>> template and wrote the template arguments out by mistake.
>
> I see your point. If I understand correctly, in such cases clang somehow
> talks about both possibilities:
>
> error: variable template partial specialization does not specialize any
> template argument; to define the primary template, remove the template
> argument list
>
> What do you think, should we do something similar?

Sounds good.

> (by the way, yesterday
> got a bit confused because in other vaguely related cases clang also has
> this kind of two-part error message and we don't. Eg, I cooked up:
>
> template 
> class Foo
> {
>   template 
>   class Bar;
> };
>
> template
> template
> class Foo::Bar;

And the same would be good for this example.

Jason

Re: [PATCH] Fix i18n in warn_spec_missing_attributes (PR 83871)

[Jason Merrill]

On Wed, Feb 28, 2018 at 5:26 AM, Jakub Jelinek  wrote:
> On Tue, Feb 27, 2018 at 05:52:03PM -0700, Martin Sebor wrote:
>> > This is broken for multiple reasons:
>> > 1) it should be inform_n rather than inform
>> > 2) you really can't do what you're doing for translations;
>> >G_(...) marks the string for translations, but what actually is
>> >translated is not that string, but rather what is passed to inform,
>> >i.e. str.c_str (), so it will be likely never translated
>> > 3) as others have mentioned, the #include  you are doing is
>> >wrong
>> > 4) I don't see justification to use std::string here
>> >
>> > What you IMHO should use instead is use
>> >   pretty_printer str;
>> > instead, and the pp_* APIs to add stuff in there, including
>> > pp_begin_quote (&str, pp_show_color (global_dc->printer))
>> > and
>> > pp_end_quote (&str, pp_show_color (global_dc->printer))
>> > when you want to add what %< or %> expand to,
>> > and finally
>> >   inform_n (DECL_SOURCE_LOCATION (tmpl), nattrs,
>> > "missing primary template attribute %s",
>> > "missing primary template attributes %s",
>> > pp_formatted_text (&str));
>> > That way it should be properly translatable.
>>
>> Using inform_n() would not be correct here.  What's being
>> translated is one of exactly two forms: singular and plural.
>> It doesn't matter how many things the plural form refers to
>> because the number doesn't appear in the message.  Let's ask
>> Google to translate the message above to a language with more
>> than two plural forms, such as Czech:
>>
>> there are missing attributes:
>> https://translate.google.com/?tl=cs#auto/cs/there%20are%20missing%20attributes
>>
>> vs there are 5 missing attributes:
>> https://translate.google.com/?tl=cs#auto/cs/there%20are%205%20missing%20attributes
>>
>> Only the first form is correct when the exact number isn't
>> mentioned.
>
> I stand corrected on 1) (though wonder if there are locales
> which have different plurals based on the count in the list).
>
>> There are many places in the C++ front-end where a string
>> enclosed in G_() is assigned to a pointer and later used
>> in a diagnostic call.  Is there something different about
>> the usage I introduced that makes it unsuitable for
>> translation?
>
> G_() does what it is designed for, collects a string for
> exgettext extraction into *.pot file.  For most of the
> diagnostic calls we have arranged automatic extractions of
> the string literals passed directly to the functions, so we don't need
> to type it in most places, just where there is a conditional or
> the string is elsewhere.  The problem in your code is that
> you mark using G_() for translation one string literal,
> e.g.
> G_("missing primary template attributes ")
> but then actually call inform with something different, like:
> "missing primary template attributes %, %"
> Functions inform will call will call gettext to translate that, but
> as this second string is dynamic and never in the *.pot file, nobody
> will translate it and so the inform will be always in English, even
> when some translator translates everything he is provided.
>
> And another advantage of using the %s appart from translatability is
> that it is -Wformat-security compatible.
>
>> std::string is used in a number of places in GCC.  Why does
>> using it here need any special justification?
>
> Outside of config/*/* (aarch64, arm, nvptx, sh backends only) where
> the maintainers chose to use it, it is used just in a single file,
> ipa-chkp.c which is going away soon, all the diagnostics uses the pretty
> printers infrastructure instead.  More importantly, with the latter
> you can do the begin/end quotes easily, with std::string you can't, unless
> you just use pretty printers and convert that to std::string, at which point
> it is certainly less efficient.
>
>> Using the pretty printer as you suggest also sounds
>> complicated to me and so prone to error but I will defer
>> to Jason's opinion to decide if any changes are necessary.
>
> Here it is in patch form, tested so far with:
> make check-c++-all RUNTESTFLAGS="--target_board=unix\{-m32,-m64\} 
> dg.exp='attr*.C Wmissing-attrib*'"
> and waiting for bootstrap/regtest, ok for trunk if it passes?

Yes.  (So never mind the _ suggestion in the other thread).

Jason

[Aarch64] Fix couple of formatting issues

[Eric Botcazou]

Superfluous parentheses plus trailing spaces introduced last June.

Tested on AArch64/Linux, applied on the mainline as obvious.


2018-02-28  Eric Botcazou  

* config/aarch64/aarch64.c (aarch64_emit_probe_stack_range): Remove
superfluous parentheses and trailing spaces.

-- 
Eric BotcazouIndex: config/aarch64/aarch64.c
===
--- config/aarch64/aarch64.c	(revision 258068)
+++ config/aarch64/aarch64.c	(working copy)
@@ -3852,11 +3852,9 @@ aarch64_emit_probe_stack_range (HOST_WIDE_INT firs
 	  emit_set_insn (reg2, gen_rtx_PLUS (Pmode, stack_pointer_rtx, reg2));
 	}
   else
-	{
-	  emit_set_insn (reg2,
-			 plus_constant (Pmode, stack_pointer_rtx, adjustment));
-	}
-	  	
+	emit_set_insn (reg2,
+		   plus_constant (Pmode, stack_pointer_rtx, adjustment));
+
   /* Step 3: the loop
 
 	 do

Re: [C++] [PR84231] overload on cond_expr in template

[Jason Merrill]

On Wed, Feb 28, 2018 at 12:24 AM, Alexandre Oliva  wrote:
> +  if (processing_template_decl)
> +result_type = cp_build_reference_type (result_type, !is_lvalue);

If !is_lvalue, we don't want a reference type at all, as the result is
a prvalue.  is_lvalue should probably rename to is_glvalue.

The second argument to cp_build_reference_type should be xvalue_p (arg2).

> +  /* Except for type-dependent exprs, a REFERENCE_TYPE will
> +indicate whether its result is an lvalue or so.

"or not" ?

> +  if (processing_template_decl
> + && !type_dependent_expression_p (CONST_CAST_TREE (ref)))
> +   return clk_none;

I think we want to return clk_class for a COND_EXPR of class type.

Can we actually get here for a type-dependent expression?  I'd think
we'd never get as far as asking whether a type-dependent expression is
an lvalue, since in general we can't answer that question.

Jason

Re: Don't vectorise zero-step rmw operations (PR 84485)

[Richard Sandiford]

Jakub Jelinek  writes:
> On Wed, Feb 28, 2018 at 02:20:27PM +, Richard Sandiford wrote:
>> GCC 6 and 7 would vectorise:
>> 
>> void
>> f (unsigned long incx, unsigned long incy,
>>float *restrict dx, float *restrict dy)
>> {
>>   unsigned long ix = 0, iy = 0;
>>   for (unsigned long i = 0; i < 512; ++i)
>> {
>>   dy[iy] += dx[ix];
>>   ix += incx;
>>   iy += incy;
>> }
>> }
>> 
>> without first proving that incy is nonzero.  This is a regression from
>> GCC 5.  It was fixed on trunk in r223486, which versioned the loop based
>
> Are you sure about the revision?  This one is from 2015 and so should be in
> all of GCC 6/7/8.

Oops, that was when the bug started.  r256644 was the fix.

[PATCH] handle fallout from attributes patch (PR 84617)

[Martin Sebor]

The attached patch fixes the regressions in merging attributes
on ordinary functions introduced by yesterday's commit to fix
bug 83871.  I've also added a new test to exercise the malloc
bit even better (this is test #3 for a single bit).

I have xfailed for now the remaining failures that expose
the bug where attributes on multiple declarations of the same
template function are not merged.  I'm assuming this being
tracked in bug 84294.  I'll look into it next but I want to
get the regressions resolved quickly.

A full bootstrap/regression test run is in progress.

Martin
PR testsuite/84617 - new test cases g++.dg/ext/attr-const.C and g++.dg/ext/attr-pure.C fail

gcc/cp/ChangeLog:

	PR testsuite/84617
	* decl.c (duplicate_decls): Fully merge attributes const, pure,
	and malloc.

gcc/testsuite/ChangeLog:

	PR testsuite/84617
	* g++.dg/ext/attr-malloc-3.C: New test.
	* g++.dg/ext/attr-const.C: Adjust.  Xfail assertions failing due
	to pre-existing problems.
	* g++.dg/ext/attr-pure.C: Same.

Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c	(revision 258068)
+++ gcc/cp/decl.c	(working copy)
@@ -2234,8 +2234,11 @@ next_arg:;
 	  TREE_NOTHROW (newdecl) |= TREE_NOTHROW (olddecl);
 	  TREE_NOTHROW (olddecl) |= TREE_NOTHROW (newdecl);
 	  TREE_READONLY (newdecl) |= TREE_READONLY (olddecl);
+	  TREE_READONLY (olddecl) |= TREE_READONLY (newdecl);
 	  DECL_IS_MALLOC (newdecl) |= DECL_IS_MALLOC (olddecl);
+	  DECL_IS_MALLOC (olddecl) |= DECL_IS_MALLOC (newdecl);
 	  DECL_PURE_P (newdecl) |= DECL_PURE_P (olddecl);
+	  DECL_PURE_P (olddecl) |= DECL_PURE_P (newdecl);
 	}
 	  else
 	{
Index: gcc/testsuite/g++.dg/ext/attr-const.C
===
--- gcc/testsuite/g++.dg/ext/attr-const.C	(revision 258068)
+++ gcc/testsuite/g++.dg/ext/attr-const.C	(working copy)
@@ -1,12 +1,12 @@
 /*  PR c++/83871 - wrong code for attribute const and pure on distinct
 template specializations
 { dg-do compile }
-{ dg-options "-O -Wall" } */
+{ dg-options "-O1 -Wall -fdump-tree-optimized" } */
 
 int __attribute__ ((const)) fconst_none ();
 int fconst_none ();
 
-void test_const_none_failed ();
+void func_const_none_failed ();
 
 void func_const_none ()
 {
@@ -13,9 +13,9 @@ void func_const_none ()
   int i0 = fconst_none ();
   int i1 = fconst_none ();
   if (i0 != i1)
-test_const_none_failed ();
+func_const_none_failed ();
 
-  // { dg-final { scan-tree-dump-not "test_const_none_failed" "optimized" } }
+  // { dg-final { scan-tree-dump-not "func_const_none_failed" "optimized" } }
 }
 
 
@@ -22,7 +22,7 @@ void func_const_none ()
 int fnone_const ();
 int __attribute__ ((const)) fnone_const ();
 
-void test_none_const_failed ();
+void func_none_const_failed ();
 
 void func_none_const ()
 {
@@ -29,12 +29,11 @@ void func_none_const ()
   int i0 = fnone_const ();
   int i1 = fnone_const ();
   if (i0 != i1)
-test_none_const_failed ();
+func_none_const_failed ();
 
-  // { dg-final { scan-tree-dump-not "test_none_const_failed" "optimized" } }
+  // { dg-final { scan-tree-dump-not "func_none_const_failed" "optimized" } }
 }
 
-
 template 
 int __attribute__ ((const)) fconst_none (T);
 
@@ -41,14 +40,16 @@ int __attribute__ ((const)) fconst_none (T);
 template 
 int fconst_none (T);
 
+void templ_const_none_failed ();
+
 void template_const_none ()
 {
   int i0 = fconst_none (0);
   int i1 = fconst_none (0);
   if (i0 != i1)
-test_const_none_failed ();
+templ_const_none_failed ();
 
-  // { dg-final { scan-tree-dump-not "test_const_none_failed" "optimized" } }
+  // { dg-final { scan-tree-dump-not "templ_const_none_failed" "optimized" } }
 }
 
 
@@ -58,12 +59,15 @@ int fnone_const (T);
 template 
 int __attribute__ ((const)) fnone_const (T);
 
+void templ_none_const_failed ();
+
 void test_fnone_const ()
 {
   int i0 = fnone_const (0);
   int i1 = fnone_const (0);
   if (i0 != i1)
-test_none_const_failed ();
+templ_none_const_failed ();
 
-  // { dg-final { scan-tree-dump-not "test_none_const_failed" "optimized" } }
+  // The following fails (most likely) due to bug 84294.
+  // { dg-final { scan-tree-dump-not "templ_none_const_failed" "optimized" { xfail *-*-* } } }
 }
Index: gcc/testsuite/g++.dg/ext/attr-malloc-3.C
===
--- gcc/testsuite/g++.dg/ext/attr-malloc-3.C	(nonexistent)
+++ gcc/testsuite/g++.dg/ext/attr-malloc-3.C	(working copy)
@@ -0,0 +1,97 @@
+// Bug c++/84617 - new test cases g++.dg/ext/attr-const.C and
+// g++.dg/ext/attr-pure.C fail
+// { dg-do compile }
+// { dg-options "-O -Wall -fdump-tree-optimized" }
+
+static char a[8];
+
+void* __attribute__ ((malloc))
+func_malloc_none (unsigned);
+
+void*
+func_alloc_none (unsigned); // redeclare with no attribute
+
+void func_malloc_none_failed ();
+
+void test_func_malloc_none (void)
+{
+  void *p = func_malloc_none (1);
+  

Re: [PATCH] handle fallout from attributes patch (PR 84617)

[Jason Merrill]

OK if testing passes.

On Wed, Feb 28, 2018 at 12:09 PM, Martin Sebor  wrote:
> The attached patch fixes the regressions in merging attributes
> on ordinary functions introduced by yesterday's commit to fix
> bug 83871.  I've also added a new test to exercise the malloc
> bit even better (this is test #3 for a single bit).
>
> I have xfailed for now the remaining failures that expose
> the bug where attributes on multiple declarations of the same
> template function are not merged.  I'm assuming this being
> tracked in bug 84294.  I'll look into it next but I want to
> get the regressions resolved quickly.
>
> A full bootstrap/regression test run is in progress.
>
> Martin

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

[Jeff Law]

On 02/28/2018 03:43 AM, Richard Biener wrote:
> On Wed, Feb 28, 2018 at 1:16 AM, Jeff Law  wrote:
[ ... snip ...]
>>
>> Anyway, I'd already been looking at 21161 and was aware that the CFG's
>> we're building in presence of setjmp/longjmp were slightly inaccurate.
>>
>> In particular, a longjmp returns to the point immediately after the
>> setjmp, not to the setjmp itself.  But our CFG building has the edge
>> from the abnormal dispatcher going to the block containing the setjmp call.
> 
> Yeah...  for SJLJ EH we get this right via __builtin_setjmp_receiver.
Right.

And as you noted in a follow-up we don't carry these abnormal edges from
gimple to RTL.  As a result they are both inaccurate, but in subtly
different ways.  I'd like to fix that wart, but probably not during this
cycle.

[ Another snip ]

>> It's actually pretty easy to fix the CFG.  We  just need to recognize
>> that a "returns twice" function returns not to the call, but to the
>> point immediately after the call.  So if we have a call to a returns
>> twice function that ends a block with a single successor, when we wire
>> up the abnormal dispatcher, we target the single successor rather than
>> the block containing the returns-twice call.
> 
> Hmm, I think you need to check whether the successor has a single
> predecessor, not whether we have a single successor (we always have
> that unless setjmp also throws).  If you fix that you keep the CFG
> "incorrect" if there are multiple predecessors so I think in addition
> to properly creating the edges you have to work on the BB building
> part to ensure that there's a single-predecessor block after
> returns-twice function calls.  Note that currently we force returns-twice
> to be the first (and only) stmt of a block -- your fix would relax this,
> returns-twice no longer needs to start a new BB.
The single successor test was strictly my paranoia WRT abnormal/EH edges.

I don't immediately see why the CFG would be incorrect if the successor
of the setjmp block has multiple preds.  But maybe it's something
downstream that I'm not familiar with -- my worry all along with this
work was the gimple->rtl conversion and block/edge discovery at that point.

Verifying the successor has a single pred seems simple enough if done at
the right time.  If it has multiple preds, then we can always fall back
to the less accurate CFG that we've been building for a decade or more.
The less precise CFG works, but the imprecision can impede more precise
analysis as we've seen with this BZ.



> -   handle_abnormal_edges (dispatcher_bbs, bb, bb_to_omp_idx,
> -  &ab_edge_call, false);
> +   {
> + bool target_after_setjmp = false;
> +
> + /* If the returns twice statement looks like a setjmp
> +call at the end of a block with a single successor
> +then we want the edge from the dispatcher to target
> +that single successor.  That more accurately reflects
> +actual control flow.  The more accurate CFG also
> +results in fewer false positive warnings.  */
> + if (gsi_stmt (gsi_last_nondebug_bb (bb)) == call_stmt
> + && gimple_call_fndecl (call_stmt)
> + && setjmp_call_p (gimple_call_fndecl (call_stmt))
> + && single_succ_p (bb))
> +   target_after_setjmp = true;
> + handle_abnormal_edges (dispatcher_bbs, bb, bb_to_omp_idx,
> +&ab_edge_call, false,
> +target_after_setjmp);
> +   }
> 
> I don't exactly get the hops you jump through here -- I think it's
> better to split the returns-twice (always last stmt of a block after
> the fixing) and the setjmp-receiver (always first stmt of a block) cases.
> So, remove the handling of returns-twice from the above case and
> handle returns-twice via
> 
>   gimple *last = last_stmt (bb);
>   if (last && ...)
> 
> also handle all returns-twice calls this way, not only setjmp_call_p.
> 
>>
[ ... snip ... ]

>> We can easily see that the call to __setjmp can never be reached given
>> that we consider the longjmp call as non-returning.  So AFAICT
>> everything is as should be expected.  I think the right thing is to just
>> remove this compromised test.
> 
> I agree.  Bonus points if you look at PR57147 and see if the testcase
> was misreduced (maybe it was just for an ICE so we can keep it
> and just remove the dump scanning?)
I had actually looked at 57147.  The original test is pr57147-1 which we
still handle correctly.  pr57147-2 doesn't represent any real world
code.  You took pr57147-1.c and twiddled it slightly based on reviewing
the CFG cleanup code and spotting a potential issue.

We might be able to change pr57147-2 to scan for changes in the edges
and their flags and given the simplicity of 

Re: [Patch, fortran] PR83901 - [8 Regression] ICE in fold_convert_loc, at fold-const.c:2402

[Paul Richard Thomas]

Committed as revision 258076.

Paul

On 27 February 2018 at 19:35, Paul Richard Thomas
 wrote:
> Hi All,
>
> I will commit this patch as obvious tomorrow night unless there are
> objections in the meantime.
>
> Bootstraps and regtests on FC27/x86_64 - OK?
>
> Paul
>
> 2018-02-27  Paul Thomas  
>
> PR fortran/83901
> * trans-stmt.c (trans_associate_var): Make sure that the se
> expression is a pointer type before converting it to the symbol
> backend_decl type.
>
> 2018-02-27  Paul Thomas  
>
> PR fortran/83901
> * gfortran.dg/associate_37.f90: New test.



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [PR c++/84492] return stmt expr ending with overload

[Jason Merrill]

On Wed, Feb 28, 2018 at 7:06 AM, Alexandre Oliva  wrote:
> We ICEd when returning a stmt expr that ends with an overloaded
> function.  It's ill-formed when we can't convert the function name to
> the return type, but we should say that, not ICE.

Hmm, what about the case where we could convert the function name to
the return type?  I think it should still be ill-formed for a
statement-expression to have an unresolved overload as its value.  So
finish_stmt_expr_expr should check type_unknown_p.

Jason

Tighten use of HARD_FRAME_POINTER_REGNUM in alias.c (PR 84538)

[Richard Sandiford]

RTL code needs to be consistent about whether it uses the stack
pointer, the frame pointer or the argument pointer to access a
given part of the frame.  alias.c used this to divide accesses
into three independent areas.

The problem in the PR is that we did this for HARD_FRAME_POINTER_REGNUM
even when the register wasn't being used as a frame pointer.  We can't
do that because the frame pointer is then just any old allocatable
register and could certainly point to info accessed through the
argument pointer or stack pointer.

In this case the bug triggered wrong code, but diffing the before and after
assembly output for one target per CPU shows that the bug also introduced
an unnecessary scheduling dependence between B and C in things like:

A: (set hfp (symbol_ref "..."))
B: ...(mem hfp)...
C: (clobber (mem sp))

where the hard frame pointer points to something that is obviously
distinct from the frame.  So it looks like this patch is both a
correctness fix and a very minor scheduling improvement.

Tested on aarch64-linux-gnu, and by diffing output as above.  OK to install?

Richard


2018-02-28  Richard Sandiford  

gcc/
PR rtl-optimization/84538
* alias.c (init_alias_target): Add commentary.
(init_alias_analysis): Only give HARD_FRAME_POINTER_REGNUM
a unique base value if the frame pointer is not eliminated
to the stack pointer.

gcc/testsuite/
PR rtl-optimization/84538
* gcc.dg/torture/pr84538.c: New test.

Index: gcc/alias.c
===
--- gcc/alias.c 2018-01-14 08:42:44.497155977 +
+++ gcc/alias.c 2018-02-28 17:47:36.486754143 +
@@ -3191,12 +3191,21 @@ init_alias_target (void)
&& targetm.hard_regno_mode_ok (i, Pmode))
   static_reg_base_value[i] = arg_base_value;
 
+  /* RTL code is required to be consistent about whether it uses the
+ stack pointer, the frame pointer or the argument pointer to
+ access a given area of the frame.  We can therefore use the
+ base address to distinguish between the different areas.  */
   static_reg_base_value[STACK_POINTER_REGNUM]
 = unique_base_value (UNIQUE_BASE_VALUE_SP);
   static_reg_base_value[ARG_POINTER_REGNUM]
 = unique_base_value (UNIQUE_BASE_VALUE_ARGP);
   static_reg_base_value[FRAME_POINTER_REGNUM]
 = unique_base_value (UNIQUE_BASE_VALUE_FP);
+
+  /* The above rules extend post-reload, with eliminations applying
+ consistently to each of the three pointers.  Cope with cases in
+ which the frame pointer is eliminated to the hard frame pointer
+ rather than the stack pointer.  */
   if (!HARD_FRAME_POINTER_IS_FRAME_POINTER)
 static_reg_base_value[HARD_FRAME_POINTER_REGNUM]
   = unique_base_value (UNIQUE_BASE_VALUE_HFP);
@@ -3329,7 +3338,14 @@ init_alias_analysis (void)
 
   /* Initialize the alias information for this pass.  */
   for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
-   if (static_reg_base_value[i])
+   if (static_reg_base_value[i]
+   /* Don't treat the hard frame pointer as special if we
+  eliminated the frame pointer to the stack pointer instead.  */
+   && !(i == HARD_FRAME_POINTER_REGNUM
+&& reload_completed
+&& !frame_pointer_needed
+&& targetm.can_eliminate (FRAME_POINTER_REGNUM,
+  STACK_POINTER_REGNUM)))
  {
new_reg_base_value[i] = static_reg_base_value[i];
bitmap_set_bit (reg_seen, i);
Index: gcc/testsuite/gcc.dg/torture/pr84538.c
===
--- /dev/null   2018-02-26 10:26:41.624847060 +
+++ gcc/testsuite/gcc.dg/torture/pr84538.c  2018-02-28 17:47:36.491754008 
+
@@ -0,0 +1,16 @@
+/* { dg-do run } */
+/* { dg-additional-options "-fno-omit-frame-pointer -w" } */
+
+#define SIZE 8
+
+main()
+{
+  int a[SIZE] = {1};
+  int i;
+
+  for (i = 1; i < SIZE; i++)
+if (a[i] != 0)
+  abort();
+
+  exit (0);
+}

[PATCH] pr84014 testcase fix

[David Edelsohn]

The powerpc-specific testcase should test ilp32 and not invoke -m32 explicitly.

Thanks, David

Index: pr84014.c
===
--- pr84014.c   (revision 258076)
+++ pr84014.c   (working copy)
@@ -1,5 +1,5 @@
-/* { dg-do compile { target powerpc*-*-* } }*/
-/* { dg-options "-O1 -fno-split-wide-types -m32 -mcpu=e300c3" } */
+/* { dg-do compile { target { powerpc*-*-* && ilp32 } } } */
+/* { dg-options "-O1 -fno-split-wide-types -mcpu=e300c3" } */

Re: [PATCH] Use warning_n instead of warning_at in gimple-ssa-warn-restrict.c

[Joseph Myers]

On Wed, 28 Feb 2018, Jakub Jelinek wrote:

> Hi!
> 
> This patch should fix most of the translation issues with plural forms
> in gimple-ssa-warn-restrict.c, now that warning_n accepts UHWI, we can and
> should just use warning_n in those cases.
> 
> I haven't touched the first set of warning_at calls, because the current 
> wording
> requires two plural forms in a single diagnostics, which is something
> gettext can't handle.  I think the only way to fix it is to break the
> message appart into warning_n and inform_n.
> 
> Anyway, following has been bootstrapped/regtested on x86_64-linux and
> i686-linux, ok for trunk?

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [C++ Patch/RFC] PR 71569 ("[6/7/8 regression] Crash: External definition of template member from template struct")

[Paolo Carlini]

Hi,

On 28/02/2018 17:24, Jason Merrill wrote:

What do you think, should we do something similar?

Sounds good.


(by the way, yesterday
got a bit confused because in other vaguely related cases clang also has
this kind of two-part error message and we don't. Eg, I cooked up:

template 
class Foo
{
   template 
   class Bar;
};

template
template
class Foo::Bar;

And the same would be good for this example.

Great. I'm finishing testing the below, looks Ok?

Thanks,
Paolo.

///
Index: cp/pt.c
===
--- cp/pt.c (revision 258059)
+++ cp/pt.c (working copy)
@@ -2873,7 +2873,18 @@ check_explicit_specialization (tree declarator,
  /* Partial specialization of variable template.  */
  SET_DECL_TEMPLATE_SPECIALIZATION (decl);
  specialization = 1;
- goto ok;
+ if (template_count && DECL_CLASS_SCOPE_P (decl)
+ && template_class_depth (DECL_CONTEXT (decl)) > 0)
+   {
+ error ("variable template partial specialization %qD does "
+"not specialize any template arguments; to define the "
+"primary template, remove the template argument list",
+declarator);
+ inform (DECL_SOURCE_LOCATION (TREE_OPERAND (declarator, 0)),
+ "primary template here");
+   }
+ else
+   goto ok;
}
  else if (cxx_dialect < cxx14)
error ("non-type partial specialization %qD "
@@ -4832,11 +4843,14 @@ process_partial_specialization (tree decl)
 get_constraints (maintmpl
 {
   if (!flag_concepts)
-error ("partial specialization %q+D does not specialize "
-  "any template arguments", decl);
+error ("partial specialization %q+D does not specialize any "
+  "template arguments; to define the primary template, "
+  "remove the template argument list", decl);
   else
 error ("partial specialization %q+D does not specialize any "
-  "template arguments and is not more constrained than", decl);
+  "template arguments and is not more constrained than "
+  "the primary template; to define the primary template, "
+  "remove the template argument list", decl);
   inform (DECL_SOURCE_LOCATION (maintmpl), "primary template here");
 }
 
Index: testsuite/g++.dg/cpp1y/var-templ58.C
===
--- testsuite/g++.dg/cpp1y/var-templ58.C(nonexistent)
+++ testsuite/g++.dg/cpp1y/var-templ58.C(working copy)
@@ -0,0 +1,13 @@
+// PR c++/71569
+// { dg-do compile { target c++14 } }
+
+template 
+class Foo
+{
+  template 
+  static bool Bar;  // { dg-message "primary template" }
+};
+
+template
+template
+bool Foo::Bar;  // { dg-error "variable template partial" }
Index: testsuite/g++.dg/template/partial-specialization9.C
===
--- testsuite/g++.dg/template/partial-specialization9.C (nonexistent)
+++ testsuite/g++.dg/template/partial-specialization9.C (working copy)
@@ -0,0 +1,12 @@
+// PR c++/71569
+
+template 
+class Foo
+{
+  template 
+  class Bar;  // { dg-message "primary template" }
+};
+
+template
+template
+class Foo::Bar {};  // { dg-error "partial specialization" }

Re: [PR c++/84593] ice on braced init with uninit ref field

[Jason Merrill]

On Wed, Feb 28, 2018 at 7:08 AM, Alexandre Oliva  wrote:
> Don't allow the initializer expr to be NULL in a ctor initializer
> list, make it error_marker_node instead.

I don't want error_mark_nodes in a CONSTRUCTOR, either.  When there
isn't an NSDMI to worry about, we zero-initialize the reference, and
it seems reasonable to continue doing that, by fixing
build_zero_init_1 to return something non-null for a reference.

Jason

Re: [PR c++/84596] implicit conv in static assert

[Jason Merrill]

On Wed, Feb 28, 2018 at 8:57 AM, Marek Polacek  wrote:
> On Wed, Feb 28, 2018 at 09:11:24AM -0300, Alexandre Oliva wrote:
>> Evaluation of constant expressions, such as those passed to
>> static_assert, ICEd when encountering IMPLICIT_CONV_EXPRs.
>>
>> Handle them like CONVERT_EXPR and NOP_EXPR.
>>
>> Regstrapped on x86_64- and i686-linux-gnu.  Ok to install?
>>
>> for  gcc/cp/ChangeLog
>>
>>   PR c++/84596
>>   * constexpr.c (cxx_eval_constant_expression): Handle
>>   IMPLICIT_CONV_EXPR.
>>
>> for  gcc/testsuite/ChangeLog
>>
>>   PR c++/84596
>>   * g++.dg/cpp0x/pr84596.C: New.
>> ---
>>  gcc/cp/constexpr.c   |1 +
>>  gcc/testsuite/g++.dg/cpp0x/pr84596.C |7 +++
>>  2 files changed, 8 insertions(+)
>>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr84596.C
>>
>> diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
>> index 4bbdbf434877..d38e2d83ae8c 100644
>> --- a/gcc/cp/constexpr.c
>> +++ b/gcc/cp/constexpr.c
>> @@ -4549,6 +4549,7 @@ cxx_eval_constant_expression (const constexpr_ctx 
>> *ctx, tree t,
>>  non_constant_p, overflow_p);
>>break;
>>
>> +case IMPLICIT_CONV_EXPR:
>>  case CONVERT_EXPR:
>>  case VIEW_CONVERT_EXPR:
>>  case NOP_EXPR:
>
> I don't think it's correct to handle template codes here; they shouldn't
> have gotten to cxx_eval_constant_expression in the first place.  Usually
> they're substituted in instantiate_non_dependent_expr_internal e.g. via
> calling fold_non_dependent_expr.  So I guess we need to find out how
> IMPLICIT_CONV_EXPR has gotten there.

Agreed.

Jason

Re: [C++ Patch/RFC] PR 71569 ("[6/7/8 regression] Crash: External definition of template member from template struct")

[Jason Merrill]

On Wed, Feb 28, 2018 at 1:42 PM, Paolo Carlini  wrote:
> Hi,
>
> On 28/02/2018 17:24, Jason Merrill wrote:
>>>
>>> What do you think, should we do something similar?
>>
>> Sounds good.
>>
>>> (by the way, yesterday
>>> got a bit confused because in other vaguely related cases clang also has
>>> this kind of two-part error message and we don't. Eg, I cooked up:
>>>
>>> template 
>>> class Foo
>>> {
>>>template 
>>>class Bar;
>>> };
>>>
>>> template
>>> template
>>> class Foo::Bar;
>>
>> And the same would be good for this example.
>
> Great. I'm finishing testing the below, looks Ok?

Hmm, the test seems wrong; the diagnostic talks about specializing the
arguments, but the actual test is checking whether the enclosing scope
is fully specialized.  It looks like you'll give the same error for

template 
struct A {
  template 
  static const U u;
};

template 
template 
const U* A::u = nullptr;

which does specialize the argument; since we accept

template 
struct A {
  template 
  struct B;
};

template 
template 
struct A::B { };

we ought to accept the above as well.

So, we could reject the testcase with this error, but we would need to
test for it using the same check as in process_partial_specialization.

Jason

[PATCH] AIX 7.1 and 7.2 configure support

[David Edelsohn]

AIX 7.1 continues to support Power4 as the minimum ISA level, so this
reverts the recent patch to aix71.h.

AIX 7.2 requires Power7 as the minimum ISA level.  The second part of
this patch adds a new aix72.h file and updates config.gcc.

Thanks, David

* config.gcc (powerpc-ibm-aix7.1.*): New stanza.
(powerpc-ibm-aix[789]*): Default to AIX 7.2.
* config/rs6000/aix71.h (TARGET_DEFAULT): Revert to Power4 ISA.
* config/rs6000/aix72.h: New file.

Index: config.gcc
===
--- config.gcc  (revision 258066)
+++ config.gcc  (working copy)
@@ -2648,7 +2648,7 @@
extra_headers=altivec.h
default_use_cxa_atexit=yes
;;
-rs6000-ibm-aix[789].* | powerpc-ibm-aix[789].*)
+rs6000-ibm-aix7.1.* | powerpc-ibm-aix7.1.*)
tm_file="${tm_file} rs6000/aix.h rs6000/aix71.h rs6000/xcoff.h
rs6000/aix-stdint.h"
tmake_file="rs6000/t-aix52 t-slibgcc"
extra_options="${extra_options} rs6000/aix64.opt"
@@ -2658,6 +2658,16 @@
extra_headers="altivec.h amo.h"
default_use_cxa_atexit=yes
;;
+rs6000-ibm-aix[789].* | powerpc-ibm-aix[789].*)
+   tm_file="${tm_file} rs6000/aix.h rs6000/aix72.h rs6000/xcoff.h
rs6000/aix-stdint.h"
+   tmake_file="rs6000/t-aix52 t-slibgcc"
+   extra_options="${extra_options} rs6000/aix64.opt"
+   use_collect2=yes
+   thread_file='aix'
+   use_gcc_stdint=wrap
+   extra_headers="altivec.h amo.h"
+   default_use_cxa_atexit=yes
+   ;;
 rl78-*-elf*)
tm_file="dbxelf.h elfos.h newlib-stdint.h ${tm_file}"
target_has_targetm_common=no

Index: config/rs6000/aix71.h
===
--- config/rs6000/aix71.h   (revision 258066)
+++ config/rs6000/aix71.h   (working copy)
@@ -132,7 +132,7 @@
 #undef RS6000_CPU

 #undef  TARGET_DEFAULT
-#define TARGET_DEFAULT ISA_2_5_MASKS_EMBEDDED
+#define TARGET_DEFAULT (MASK_PPC_GPOPT | MASK_PPC_GFXOPT | MASK_MFCRF)

 #undef  PROCESSOR_DEFAULT
 #define PROCESSOR_DEFAULT PROCESSOR_POWER7

Re: [C++ Patch/RFC] PR 71569 ("[6/7/8 regression] Crash: External definition of template member from template struct")

[Paolo Carlini]

Hi,

On 28/02/2018 20:20, Jason Merrill wrote:

Hmm, the test seems wrong; the diagnostic talks about specializing the
arguments, but the actual test is checking whether the enclosing scope
is fully specialized.  It looks like you'll give the same error for

template 
struct A {
   template 
   static const U u;
};

template 
template 
const U* A::u = nullptr;

which does specialize the argument; since we accept

template 
struct A {
   template 
   struct B;
};

template 
template 
struct A::B { };

we ought to accept the above as well.

So, we could reject the testcase with this error, but we would need to
test for it using the same check as in process_partial_specialization.
I see. Doing that seems relatively easy - I have a draft which appears 
to work - but then we have immediately to change the gcc_assert at the 
beginning of determine_specialization to let such specializations 
through (of course it still uses the wrong test!!). I'm not sure about 
the best way to do that... But that seems also doable. The next problem 
is duplicate_decls which apparently misses a bit of code to understand 
that the new declaration does not conflict with the old one near line 
#1650... So, frankly, I think that even with your great guidance I would 
need a few iterations to get right the whole package and we are so damn 
close to the release. What do you think? Do you want to take this over, 
or maybe you see us restricting a bit what we'll have working in this 
area for 8.1.0?


Thanks,
Paolo.

Re: C++ PATCH to fix static init with () in a template (PR c++/84582)

[Marek Polacek]

On Wed, Feb 28, 2018 at 10:51:17AM -0500, Jason Merrill wrote:
> On Wed, Feb 28, 2018 at 9:32 AM, Marek Polacek  wrote:
> > On Tue, Feb 27, 2018 at 04:16:31PM -0500, Jason Merrill wrote:
> >> On 02/27/2018 02:13 PM, Marek Polacek wrote:
> >> > My recent change introducing cxx_constant_init caused this code
> >> >
> >> > template  class A {
> >> >static const long b = 0;
> >> >static const unsigned c = (b);
> >> > };
> >> >
> >> > to be rejected.  The reason is that force_paren_expr turns "b" into 
> >> > "*(const
> >> > long int &) &b", where the former is not value-dependent but the latter 
> >> > is
> >> > value-dependent.  So when we get to maybe_constant_init_1:
> >> > 5147   if (!is_nondependent_static_init_expression (t))
> >> > 5148 /* Don't try to evaluate it.  */;
> >> > it's not evaluated and we get the non-constant initialization error.
> >> > (Before we'd always evaluated the expression.)
> >> >
> >> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >> >
> >> > 2018-02-27  Marek Polacek  
> >> >
> >> > PR c++/84582
> >> > * semantics.c (force_paren_expr): Avoid creating a static cast
> >> > when processing a template.
> >> >
> >> > * g++.dg/cpp1z/static1.C: New test.
> >> > * g++.dg/template/static37.C: New test.
> >> >
> >> > diff --git gcc/cp/semantics.c gcc/cp/semantics.c
> >> > index 35569d0cb0d..b48de2df4e2 100644
> >> > --- gcc/cp/semantics.c
> >> > +++ gcc/cp/semantics.c
> >> > @@ -1697,7 +1697,7 @@ force_paren_expr (tree expr)
> >> >   expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
> >> > else if (VAR_P (expr) && DECL_HARD_REGISTER (expr))
> >> >   /* We can't bind a hard register variable to a reference.  */;
> >> > -  else
> >> > +  else if (!processing_template_decl)
> >>
> >> Hmm, this means that we forget about the parentheses in a template.  I'm
> >> surprised that this didn't break anything in the testsuite.  In particular,
> >> auto-fn15.C.  I've attached an addition to auto-fn15.C to catch this issue.
> >
> > Thanks, you're right.  I'll use it.
> >
> >> Can we use PAREN_EXPR instead of the static_cast in a template?
> >
> > I don't think so, it would fix the issue you pointed out in auto-fn15.C but
> > it wouldn't fix the original test.  The problem with using PAREN_EXPR in a
> > template is that instantiate_non_dependent_expr will turn in into the
> > static cast anyway; tsubst_copy_and_build has
> > case PAREN_EXPR:
> >   RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t, 0;
> > so it calls force_paren_expr and this time we're not in a template.  And
> > then when calling cxx_constant_init we have the same issue.
> 
> Then maybe we need something like fold_non_dependent_expr, which
> checks for dependency before substitution and then immediately
> evaluates the result.

I hope you meant something like this.  Further testing also revealed that
maybe_undo_parenthesized_ref should be able to unwrap PAREN_EXPR (so that
(fn1)(); in paren2.C is handled correctly), and that lvalue_kind should look
into PAREN_EXPR so as to give the correct answer regarding lvalueness: we
should accept

template
void foo (int i)
{
  ++(i);
}

Apologies if I'm on the wrong track.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2018-02-28  Marek Polacek  
Jason Merrill  

PR c++/84582
* semantics.c (force_paren_expr): Avoid creating the static cast
when in a template.  Create a PAREN_EXPR when in a template.
(maybe_undo_parenthesized_ref): Unwrap PAREN_EXPR.
* typeck2.c (store_init_value): Call fold_non_dependent_expr instead
of instantiate_non_dependent_expr.
* tree.c (lvalue_kind): Handle PAREN_EXPR like NON_DEPENDENT_EXPR.

* g++.dg/cpp1y/auto-fn15.C: Extend testing.
* g++.dg/cpp1z/static1.C: New test.
* g++.dg/template/static37.C: New test.

diff --git gcc/cp/semantics.c gcc/cp/semantics.c
index 35569d0cb0d..722e3718a14 100644
--- gcc/cp/semantics.c
+++ gcc/cp/semantics.c
@@ -1697,7 +1697,7 @@ force_paren_expr (tree expr)
 expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
   else if (VAR_P (expr) && DECL_HARD_REGISTER (expr))
 /* We can't bind a hard register variable to a reference.  */;
-  else
+  else if (!processing_template_decl)
 {
   cp_lvalue_kind kind = lvalue_kind (expr);
   if ((kind & ~clk_class) != clk_none)
@@ -1713,6 +1713,8 @@ force_paren_expr (tree expr)
REF_PARENTHESIZED_P (expr) = true;
}
 }
+  else
+expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
 
   return expr;
 }
@@ -1724,9 +1726,10 @@ force_paren_expr (tree expr)
 tree
 maybe_undo_parenthesized_ref (tree t)
 {
-  if (cxx_dialect >= cxx14
-  && INDIRECT_REF_P (t)
-  && REF_PARENTHESIZED_P (t))
+  if (cxx_dialect < cxx14)
+return t;
+
+  if (INDIRECT_REF_P (t) && REF_PARENTHESIZED_P (t))
 {
   t = TREE_OPERAND (t, 0);
   while (TREE_CODE (t) == NON_LVALUE_EXPR
@@ -1737,6 +1740

C++ PATCH for c++/71784, ICE with explicit specialization and ref-qualifier

[Jason Merrill]

determine_specialization hadn't been taught about ref-qualifiers yet.

Tested x86_64-pc-linux-gnu, applying to trunk/7/6.
commit f69972ff3fa2b33609e1952c0936f13e98161e5f
Author: Jason Merrill 
Date:   Wed Feb 28 15:17:08 2018 -0500

PR c++/71784 - ICE with ref-qualifier and explicit specialization.

* pt.c (determine_specialization): Check ref-qualifier.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 23eb2db1a5d..e17b5387514 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -2164,10 +2164,17 @@ determine_specialization (tree template_id,
 that the const qualification is the same.  Since
 get_bindings does not try to merge the "this" parameter,
 we must do the comparison explicitly.  */
- if (DECL_NONSTATIC_MEMBER_FUNCTION_P (fn)
- && !same_type_p (TREE_VALUE (fn_arg_types),
-  TREE_VALUE (decl_arg_types)))
-   continue;
+ if (DECL_NONSTATIC_MEMBER_FUNCTION_P (fn))
+   {
+ if (!same_type_p (TREE_VALUE (fn_arg_types),
+   TREE_VALUE (decl_arg_types)))
+   continue;
+
+ /* And the ref-qualification.  */
+ if (type_memfn_rqual (TREE_TYPE (decl))
+ != type_memfn_rqual (TREE_TYPE (fn)))
+   continue;
+   }
 
  /* Skip the "this" parameter and, for constructors of
 classes with virtual bases, the VTT parameter.  A
@@ -2278,6 +2285,11 @@ determine_specialization (tree template_id,
 decl_arg_types))
 continue;
 
+ if (DECL_NONSTATIC_MEMBER_FUNCTION_P (fn)
+ && (type_memfn_rqual (TREE_TYPE (decl))
+ != type_memfn_rqual (TREE_TYPE (fn
+   continue;
+
   // If the deduced arguments do not satisfy the constraints,
   // this is not a candidate.
   if (flag_concepts && !constraints_satisfied_p (fn))
diff --git a/gcc/testsuite/g++.dg/cpp0x/ref-qual18.C 
b/gcc/testsuite/g++.dg/cpp0x/ref-qual18.C
new file mode 100644
index 000..aaa00b9cfc3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/ref-qual18.C
@@ -0,0 +1,18 @@
+// PR c++/71784
+// { dg-do compile { target c++11 } }
+
+template struct A {
+  template void f(U const&) & { }
+  template void f(U const&) && { }
+};
+
+template void A::f(int const&) &;
+template void A::f(int const&) &&;
+
+template struct B {
+  void f(int const&) & { }
+  void f(int const&) && { }
+};
+
+template void B::f(int const&) &;
+template void B::f(int const&) &&;

Re: [PATCH] [RFC] rs6000: -mreadonly-in-sdata (PR82411)

[Kees Cook via gcc-patches]

On Tue, Feb 27, 2018 at 2:01 PM, Segher Boessenkool
 wrote:
> This adds a new option -mreadonly-in-sdata (on by default) that
> controls whether readonly data can be put in sdata.  (For EABI this
> does nothing, readonly data is put in sdata2 as usual).

Cool! Thanks for working on this.

> Kees, could you try this out with your use case?  Add the flag
> -mno-readonly-in-sdata in your build scripts.  The patch is against
> GCC trunk.

I'm struggling to create a ppc cross compiler, otherwise I would be
happy to test this. :)

If you're able to build a ppc kernel and remove the "static" from
mm/rodata_test_data.c's rodata_test_data and see the rodata_test_data
variable not in .sdata, that should be sufficient. The case reported
was here:
https://lkml.org/lkml/2017/9/21/156

I'll continue trying to solve my cross build issue...

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH] Fix aarch64_simd_reg_or_zero predicate (PR fortran/84565)

[Jakub Jelinek]

On Tue, Feb 27, 2018 at 02:22:22PM +, Richard Sandiford wrote:
> > Bootstrapped/regtested on aarch64-linux (scratch Fedora gcc 8 package build
> > with the patch applied), ok for trunk?
> >
> > 2018-02-27  Jakub Jelinek  
> >
> > PR fortran/84565
> > * config/aarch64/predicates.md (aarch64_simd_reg_or_zero): Use
> > aarch64_simd_or_scalar_imm_zero rather than aarch64_simd_imm_zero.
> >
> > * gfortran.dg/pr84565.f90: New test.
> >
> > --- gcc/config/aarch64/predicates.md.jj 2018-02-06 13:13:06.305751221 
> > +0100
> > +++ gcc/config/aarch64/predicates.md2018-02-26 16:30:01.902195208 
> > +0100
> > @@ -395,7 +395,7 @@ (define_predicate "aarch64_simd_reg_or_z
> >(and (match_code "reg,subreg,const_int,const_double,const,const_vector")
> > (ior (match_operand 0 "register_operand")
> > (match_test "op == const0_rtx")
> > -   (match_operand 0 "aarch64_simd_imm_zero"
> > +   (match_operand 0 "aarch64_simd_or_scalar_imm_zero"
> 
> I think this makes the match_test on the line above redundant.

Yes, it is; it used to be redundant before too.  I can change it if needed,
it would be just a matter of dropping the (match_test "op == const0_rtx")
line.

Jakub

Re: C++ PATCH to fix static init with () in a template (PR c++/84582)

[Jason Merrill]

On Wed, Feb 28, 2018 at 4:19 PM, Marek Polacek  wrote:
> On Wed, Feb 28, 2018 at 10:51:17AM -0500, Jason Merrill wrote:
>> On Wed, Feb 28, 2018 at 9:32 AM, Marek Polacek  wrote:
>> > On Tue, Feb 27, 2018 at 04:16:31PM -0500, Jason Merrill wrote:
>> >> On 02/27/2018 02:13 PM, Marek Polacek wrote:
>> >> > My recent change introducing cxx_constant_init caused this code
>> >> >
>> >> > template  class A {
>> >> >static const long b = 0;
>> >> >static const unsigned c = (b);
>> >> > };
>> >> >
>> >> > to be rejected.  The reason is that force_paren_expr turns "b" into 
>> >> > "*(const
>> >> > long int &) &b", where the former is not value-dependent but the latter 
>> >> > is
>> >> > value-dependent.  So when we get to maybe_constant_init_1:
>> >> > 5147   if (!is_nondependent_static_init_expression (t))
>> >> > 5148 /* Don't try to evaluate it.  */;
>> >> > it's not evaluated and we get the non-constant initialization error.
>> >> > (Before we'd always evaluated the expression.)
>> >> >
>> >> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
>> >> >
>> >> > 2018-02-27  Marek Polacek  
>> >> >
>> >> > PR c++/84582
>> >> > * semantics.c (force_paren_expr): Avoid creating a static cast
>> >> > when processing a template.
>> >> >
>> >> > * g++.dg/cpp1z/static1.C: New test.
>> >> > * g++.dg/template/static37.C: New test.
>> >> >
>> >> > diff --git gcc/cp/semantics.c gcc/cp/semantics.c
>> >> > index 35569d0cb0d..b48de2df4e2 100644
>> >> > --- gcc/cp/semantics.c
>> >> > +++ gcc/cp/semantics.c
>> >> > @@ -1697,7 +1697,7 @@ force_paren_expr (tree expr)
>> >> >   expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
>> >> > else if (VAR_P (expr) && DECL_HARD_REGISTER (expr))
>> >> >   /* We can't bind a hard register variable to a reference.  */;
>> >> > -  else
>> >> > +  else if (!processing_template_decl)
>> >>
>> >> Hmm, this means that we forget about the parentheses in a template.  I'm
>> >> surprised that this didn't break anything in the testsuite.  In 
>> >> particular,
>> >> auto-fn15.C.  I've attached an addition to auto-fn15.C to catch this 
>> >> issue.
>> >
>> > Thanks, you're right.  I'll use it.
>> >
>> >> Can we use PAREN_EXPR instead of the static_cast in a template?
>> >
>> > I don't think so, it would fix the issue you pointed out in auto-fn15.C but
>> > it wouldn't fix the original test.  The problem with using PAREN_EXPR in a
>> > template is that instantiate_non_dependent_expr will turn in into the
>> > static cast anyway; tsubst_copy_and_build has
>> > case PAREN_EXPR:
>> >   RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t, 0;
>> > so it calls force_paren_expr and this time we're not in a template.  And
>> > then when calling cxx_constant_init we have the same issue.
>>
>> Then maybe we need something like fold_non_dependent_expr, which
>> checks for dependency before substitution and then immediately
>> evaluates the result.
>
> I hope you meant something like this.  Further testing also revealed that
> maybe_undo_parenthesized_ref should be able to unwrap PAREN_EXPR (so that
> (fn1)(); in paren2.C is handled correctly), and that lvalue_kind should look
> into PAREN_EXPR so as to give the correct answer regarding lvalueness: we
> should accept
>
> template
> void foo (int i)
> {
>   ++(i);
> }
>
> Apologies if I'm on the wrong track.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-02-28  Marek Polacek  
> Jason Merrill  
>
> PR c++/84582
> * semantics.c (force_paren_expr): Avoid creating the static cast
> when in a template.  Create a PAREN_EXPR when in a template.
> (maybe_undo_parenthesized_ref): Unwrap PAREN_EXPR.
> * typeck2.c (store_init_value): Call fold_non_dependent_expr instead
> of instantiate_non_dependent_expr.
> * tree.c (lvalue_kind): Handle PAREN_EXPR like NON_DEPENDENT_EXPR.
>
> * g++.dg/cpp1y/auto-fn15.C: Extend testing.
> * g++.dg/cpp1z/static1.C: New test.
> * g++.dg/template/static37.C: New test.
>
> diff --git gcc/cp/semantics.c gcc/cp/semantics.c
> index 35569d0cb0d..722e3718a14 100644
> --- gcc/cp/semantics.c
> +++ gcc/cp/semantics.c
> @@ -1697,7 +1697,7 @@ force_paren_expr (tree expr)
>  expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
>else if (VAR_P (expr) && DECL_HARD_REGISTER (expr))
>  /* We can't bind a hard register variable to a reference.  */;
> -  else
> +  else if (!processing_template_decl)
>  {
>cp_lvalue_kind kind = lvalue_kind (expr);
>if ((kind & ~clk_class) != clk_none)
> @@ -1713,6 +1713,8 @@ force_paren_expr (tree expr)
> REF_PARENTHESIZED_P (expr) = true;
> }
>  }
> +  else
> +expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);

There's already a branch for building PAREN_EXPR, let's just replace
its condition.

> -  value = instantiate_non_dependent_expr (value);
> +  value = fold_non_dependent_expr (val

Re: [PATCH, rs6000] (v2) Update altivec-7 testcase(s).

[Segher Boessenkool]

Hi Will,

On Tue, Feb 27, 2018 at 09:23:12AM -0600, Will Schmidt wrote:
> Move the vsx related content from the altivec-7-be test into
> a new vsx-7-be test.  Split out the VSX specific bits into a vsx-7.h
> header file, and include that when appropriate.

>   * gcc.target/powerpc/altivec-7-be.c:  Remove VSX content, allow
>   -32 bit target.

Only one space after ":".  "32-bit target".

> +/* { dg-final { scan-assembler-times {\mlxvd2x\M} 0 { target { p9vector_hw } 
> } } } */
> +/* { dg-final { scan-assembler-times {\mlxvd2x\M} 36 { target { { ! 
> powerpc_p9vector_ok }  &&   powerpc*le-*-* } } } } */
> +/* { dg-final { scan-assembler-times {\mlxvd2x\M} 6 { target { ! 
> powerpc*le-*-* } } } } */

These three conditions are overlapping, and don't cover everything?

The first and the third are both enabled when running on a BE p9 system
(not that those exist, but still).

None are active if compiling for LE p9 on another LE system.

Should the first line have  {powerpc*le-*-* && p9vector_ok}  instead?


Okay for trunk with that sorted out.  Thanks!


Segher

RE: [PATCH, PR83327] Fix liveness analysis in lra for spilled-into hard regs

[Matthew Fortune]

Tom de Vries  writes:
> On 02/26/2018 12:00 PM, Matthew Fortune wrote:
> > Tom de Vries  writes:
> >> On 01/08/2018 05:32 PM, Tom de Vries wrote:
> >>> On 12/18/2017 05:57 PM, Vladimir Makarov wrote:
> 
> 
>  On 12/15/2017 06:25 AM, Tom de Vries wrote:
> >
> > Proposed Solution:
> >
> > The patch addresses the problem, by:
> > - marking the hard regs that have been used in lra_spill in
> >    hard_regs_spilled_into
> > - using hard_regs_spilled_into in lra_create_live_ranges to
> >    make sure those registers are marked in the conflict_hard_regs
> >    of pseudos that overlap with the spill register usage
> >
> > [ I've also tried an approach where I didn't use
> > hard_regs_spilled_into, but tried to propagate all hard regs. I
> > figured out that I needed to mask out eliminable_regset.  Also I
> > needed to masked out lra_no_alloc_regs, but that could be due to
> > gcn-specific problems (pointers take 2 hard regs), I'm not yet
> sure.
> > Anyway, in the submitted patch I tried to avoid these problems
> and
> > went for the more minimal approach. ]
> >
>  Tom, thank you for the detail explanation of the problem and
>  solutions you considered.  It helped me a lot.  Your simple
> solution
>  is adequate as the most transformations and allocation are done on
>  the 1st LRA subpasses iteration.
> > In order to get the patch accepted for trunk, I think we need:
> > - bootstrap and reg-test on x86_64
> > - build and reg-test on mips (the only primary platform that has
> the
> >    spill_class hook enabled)
> >
> > Any comments?
> 
>  The patch looks ok to me.  You can commit it after successful
> testing
>  on x86-64 and mips but I am sure there will be no problems with
>  x86-64 as it does not use spill_class currently (actually your
> patch
>  might help to switch it on again for x86-64.  spill_class was
> quite
>  useful for x86-64 performance on Intel processors).
> 
> >>>
> >>> Hi Matthew,
> >>>
> >>> there's an lra optimization that is currently enabled for MIPS, and
> >>> not for any other primary or secondary target.
> >>>
> >>> This (already approved) patch fixes a bug in that optimization, and
> >>> needs to be tested on MIPS.
> >>>
> >>> Unfortunately, the optimization is only enabled for MIPS16, and we
> >>> don't have a current setup to test this.
> >>>
> >>> Could you help us out here and test this patch for MIPS16 on trunk?
> >>
> >> Hi Matthew,
> >>
> >> is this something you can help us out with?
> >
> > Hi Tom,
> >
> > I've just commented on the bug report that I've set of some builds to
> try
> > and give some assurance. It is far from comprehensive but it is as
> good as
> > the normal testing I do for MIPS16.
> >
> 
> Hi Matthew,
> 
> Awesome, thanks for the help.

I have tested trunk with and without the patch and can confirm there
is no change in test status for MIPS16 big endian.

I ended up fixing an assert-checking issue in the MIPS backend and
a bug (I think) in the C++ frontend to get to the point of testing so
quite a worthwhile effort all in all.

Thanks,
Matthew

Re: [PATCH, rs6000] Fix PR84534: several powerpc test cases fail starting with r257915

[Segher Boessenkool]

Hi!

On Wed, Feb 28, 2018 at 09:39:14AM -0600, Peter Bergner wrote:
> This patch fixes PR84534 by XFAILing one test because we are deprecating
> -maltivec=be when run on LE.  The other tests are fixed by not counting
> xxlor insns.  We cannot rely on stable counts of xxlor insns, because we
> generate them not only when using __builtin_vec_or(), but also whenever
> we need to copy one vsx reg to another...which can vary depending on
> previous optimizations, moon phases, etc.  Therefore, we just make sure
> we generate at least one.  I'll note I did try adding -dp and seeing
> which patterns generated the xxlors, but there wasn't a clear match
> between the xxlor's generated because of the __builtin_vec_or and the
> reg copies.

> gcc/testsuite/
>   PR target/84534
>   * gcc.target/powerpc/vec-setup-be-long.c: xfail.

"Add xfail for powerpc64le" or similar?

>   * gcc.target/powerpc/vsx-vector-6-le.c: Do not count xxlor's.
>   * gcc.target/powerpc/vsx-vector-6-le.p9.c: Likewise.

Please add a comment to the testcase why there is no count here.

Okay for trunk with that.  Thanks!


Segher

[PATCH] merge attributes from function template redeclarations (PR 84294)

[Martin Sebor]

Attached is a patch for the failure to merge a subset of attributes
specified on redeclarations of a function template with those of
the first declaration (const, malloc, pure, noinline, noreturn,
and nothrow).  This was uncovered this morning while debugging
failures in tests I added just yesterday and although it's not
a regression I figured since I introduced the test failures and
the fix appears easy it might as well be taken care of now.

The test I added for this exposed a subtle bug in -Wreturn-type
where the warning triggers on a function template instantiated
on a noreturn function even though the middle end successfully
eliminates statements after the noreturn call.  This is not
a regression either so to avoid mission creep I just xfailed
the test and opened bug 84621 to remind us to fix it in
the future.

Bootstrap passes, a full regression test suite run is underway.

Martin
PR c++/84294 - attributes on a function template redeclaration silently discarded

gcc/cp/ChangeLog:

	PR c++/84294
	* decl.c (check_redeclaration_no_default_args): Merge attributes
	specified on redeclarations of the same function template.

gcc/testsuite/ChangeLog:

	PR c++/84294
	* g++.dg/ext/attr-const.C: Remove xfail.
	* g++.dg/ext/attr-malloc-3.C: New test.
	* g++.dg/ext/attr-noinline-3.C: New test.
	* g++.dg/ext/attr-noreturn-3.C: New test.
	* g++.dg/ext/attr-nothrow-3.C: New test.
	* g++.dg/ext/attr-pure.C: Remove xfail.

Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c	(revision 258077)
+++ gcc/cp/decl.c	(working copy)
@@ -1355,6 +1355,26 @@ check_redeclaration_no_default_args (tree decl)
   }
 }
 
+/* Merge tree bits that correspond to attributes noreturn, nothrow,
+   const,  malloc, and pure from NEWDECL with those of OLDDECL.  */
+
+static void
+merge_attribute_bits (tree newdecl, tree olddecl)
+{
+  TREE_THIS_VOLATILE (newdecl) |= TREE_THIS_VOLATILE (olddecl);
+  TREE_THIS_VOLATILE (olddecl) |= TREE_THIS_VOLATILE (newdecl);
+  TREE_NOTHROW (newdecl) |= TREE_NOTHROW (olddecl);
+  TREE_NOTHROW (olddecl) |= TREE_NOTHROW (newdecl);
+  TREE_READONLY (newdecl) |= TREE_READONLY (olddecl);
+  TREE_READONLY (olddecl) |= TREE_READONLY (newdecl);
+  DECL_IS_MALLOC (newdecl) |= DECL_IS_MALLOC (olddecl);
+  DECL_IS_MALLOC (olddecl) |= DECL_IS_MALLOC (newdecl);
+  DECL_PURE_P (newdecl) |= DECL_PURE_P (olddecl);
+  DECL_PURE_P (olddecl) |= DECL_PURE_P (newdecl);
+  DECL_UNINLINABLE (newdecl) |= DECL_UNINLINABLE (olddecl);
+  DECL_UNINLINABLE (olddecl) |= DECL_UNINLINABLE (newdecl);
+}
+
 #define GNU_INLINE_P(fn) (DECL_DECLARED_INLINE_P (fn)			\
 			  && lookup_attribute ("gnu_inline",		\
 	   DECL_ATTRIBUTES (fn)))
@@ -2048,6 +2068,8 @@ next_arg:;
 	  DECL_DISREGARD_INLINE_LIMITS (old_result)
 	|= DECL_DISREGARD_INLINE_LIMITS (new_result);
 	  check_redeclaration_exception_specification (newdecl, olddecl);
+
+	  merge_attribute_bits (new_result, old_result);
 	}
 	}
 
@@ -2228,18 +2250,7 @@ next_arg:;
 	|= DECL_LOOPING_CONST_OR_PURE_P (olddecl);
 
 	  if (merge_attr)
-	{
-	  TREE_THIS_VOLATILE (newdecl) |= TREE_THIS_VOLATILE (olddecl);
-	  TREE_THIS_VOLATILE (olddecl) |= TREE_THIS_VOLATILE (newdecl);
-	  TREE_NOTHROW (newdecl) |= TREE_NOTHROW (olddecl);
-	  TREE_NOTHROW (olddecl) |= TREE_NOTHROW (newdecl);
-	  TREE_READONLY (newdecl) |= TREE_READONLY (olddecl);
-	  TREE_READONLY (olddecl) |= TREE_READONLY (newdecl);
-	  DECL_IS_MALLOC (newdecl) |= DECL_IS_MALLOC (olddecl);
-	  DECL_IS_MALLOC (olddecl) |= DECL_IS_MALLOC (newdecl);
-	  DECL_PURE_P (newdecl) |= DECL_PURE_P (olddecl);
-	  DECL_PURE_P (olddecl) |= DECL_PURE_P (newdecl);
-	}
+	merge_attribute_bits (newdecl, olddecl);
 	  else
 	{
 	  /* Merge the noreturn bit.  */
Index: gcc/testsuite/g++.dg/ext/attr-const.C
===
--- gcc/testsuite/g++.dg/ext/attr-const.C	(revision 258077)
+++ gcc/testsuite/g++.dg/ext/attr-const.C	(working copy)
@@ -68,6 +68,5 @@ void test_fnone_const ()
   if (i0 != i1)
 templ_none_const_failed ();
 
-  // The following fails (most likely) due to bug 84294.
-  // { dg-final { scan-tree-dump-not "templ_none_const_failed" "optimized" { xfail *-*-* } } }
+  // { dg-final { scan-tree-dump-not "templ_none_const_failed" "optimized" } }
 }
Index: gcc/testsuite/g++.dg/ext/attr-malloc-3.C
===
--- gcc/testsuite/g++.dg/ext/attr-malloc-3.C	(revision 258077)
+++ gcc/testsuite/g++.dg/ext/attr-malloc-3.C	(working copy)
@@ -91,7 +91,6 @@ void test_templ_none_malloc (void)
   if (p == a)   // must be false
 templ_none_malloc_failed ();// should be eliminated
 
-  // The following fails (most likely) due to bug 84294.
   // Verify that the call to templ_none_malloc_failed() is eliminated.
-  // { dg-final { scan-tree-dump-not "templ_none_malloc_failed" 

Re: [PATCH, rs6000] Fix PR84534: several powerpc test cases fail starting with r257915

[Peter Bergner]

On 2/28/18 4:36 PM, Segher Boessenkool wrote:
>>  * gcc.target/powerpc/vec-setup-be-long.c: xfail.
> 
> "Add xfail for powerpc64le" or similar?

Doh!  I was going to say "why?" since we're xfailing it everywhere, but I
see I messed up that hunk, which should be "xfail {*-*-*}".  The test case
currently only runs on powerpc64le*-*-linux* and we want to xfail it on
powerpc64le*-*-linux*, so that leaves not really running it anywhere.
Offline, I mentioned using:

  -/* { dg-do run { target { powerpc64le*-*-linux* } } } */
  +/* { dg-do run { target { powerpc64le*-*-linux* } xfail { 
powerpc64le*-*-linux* } } } */

...and you said we could just use "xfail {*-*-*}".  But thinking about
it some more, doesn't "xfail {*-*-*}" add XFAILs on BE, AIX, etc. that
never used to run the test because the target didn't allow it?
So should we go with my original idea above?  Or maybe we don't care
that we XFAIL on some targets since we're just going to remove the
test next release with the removal -maltivec=be?


>>  * gcc.target/powerpc/vsx-vector-6-le.c: Do not count xxlor's.
>>  * gcc.target/powerpc/vsx-vector-6-le.p9.c: Likewise.
> 
> Please add a comment to the testcase why there is no count here.

Will do.

Peter

Re: [PATCH, rs6000] Fix PR84534: several powerpc test cases fail starting with r257915

[Segher Boessenkool]

On Wed, Feb 28, 2018 at 04:51:27PM -0600, Peter Bergner wrote:
> On 2/28/18 4:36 PM, Segher Boessenkool wrote:
> >>* gcc.target/powerpc/vec-setup-be-long.c: xfail.
> > 
> > "Add xfail for powerpc64le" or similar?
> 
> Doh!  I was going to say "why?" since we're xfailing it everywhere, but I

Because you can use a few more words in changelog entries ;-)

"Add xfail." is fine, too.  Just "xfail." is unclear.

> see I messed up that hunk, which should be "xfail {*-*-*}".  The test case
> currently only runs on powerpc64le*-*-linux* and we want to xfail it on
> powerpc64le*-*-linux*, so that leaves not really running it anywhere.
> Offline, I mentioned using:
> 
>   -/* { dg-do run { target { powerpc64le*-*-linux* } } } */
>   +/* { dg-do run { target { powerpc64le*-*-linux* } xfail { 
> powerpc64le*-*-linux* } } } */
> 
> ...and you said we could just use "xfail {*-*-*}".  But thinking about
> it some more, doesn't "xfail {*-*-*}" add XFAILs on BE, AIX, etc. that
> never used to run the test because the target didn't allow it?

Yeah; keeping it as a separate dg-xfail-if statement works fine though
(is the above dg-do valid syntax even?  I have no idea).

> So should we go with my original idea above?  Or maybe we don't care
> that we XFAIL on some targets since we're just going to remove the
> test next release with the removal -maltivec=be?

It would be nice to have clean test results, which is all this patch is
about anyway, right?


Segher

Re: Tighten use of HARD_FRAME_POINTER_REGNUM in alias.c (PR 84538)

[Jeff Law]

On 02/28/2018 10:51 AM, Richard Sandiford wrote:
> RTL code needs to be consistent about whether it uses the stack
> pointer, the frame pointer or the argument pointer to access a
> given part of the frame.  alias.c used this to divide accesses
> into three independent areas.
> 
> The problem in the PR is that we did this for HARD_FRAME_POINTER_REGNUM
> even when the register wasn't being used as a frame pointer.  We can't
> do that because the frame pointer is then just any old allocatable
> register and could certainly point to info accessed through the
> argument pointer or stack pointer.
> 
> In this case the bug triggered wrong code, but diffing the before and after
> assembly output for one target per CPU shows that the bug also introduced
> an unnecessary scheduling dependence between B and C in things like:
> 
>   A: (set hfp (symbol_ref "..."))
>   B: ...(mem hfp)...
>   C: (clobber (mem sp))
> 
> where the hard frame pointer points to something that is obviously
> distinct from the frame.  So it looks like this patch is both a
> correctness fix and a very minor scheduling improvement.
> 
> Tested on aarch64-linux-gnu, and by diffing output as above.  OK to install?
> 
> Richard
> 
> 
> 2018-02-28  Richard Sandiford  
> 
> gcc/
>   PR rtl-optimization/84538
>   * alias.c (init_alias_target): Add commentary.
>   (init_alias_analysis): Only give HARD_FRAME_POINTER_REGNUM
>   a unique base value if the frame pointer is not eliminated
>   to the stack pointer.
> 
> gcc/testsuite/
>   PR rtl-optimization/84538
>   * gcc.dg/torture/pr84538.c: New test.
OK.
jeff

Re: [PATCH] expand description of poly_int conversions

[Jeff Law]

On 02/26/2018 02:09 PM, Richard Sandiford wrote:
> Martin Sebor  writes:
>> On 02/26/2018 12:45 PM, Richard Sandiford wrote:
>>> Martin Sebor  writes:
 Richard,

 If you agree, I'd like to update the conversion section of
 the poly_int manual to make the conversion to make it clearer
 that the to_constant() function can be used even with class
 types like offset_int besides scalars.

 Also, when testing this I also tried converting poly64_int
 into wide_int but that doesn't work.  Is there a way to do
 that?
>>>
>>> Not in one go, because you have to specify the intended precision
>>> of the wide_int when constructing it from something like HOST_WIDE_INT.
>>> (That's deliberate.)
>>>

 Thanks
 Martin

 gcc/ChangeLog:

* doc/poly-int.texi (is_constant): Expand.

 Index: gcc/doc/poly-int.texi
 ===
 --- gcc/doc/poly-int.texi  (revision 258004)
 +++ gcc/doc/poly-int.texi  (working copy)
 @@ -836,9 +836,24 @@ Return true if @code{poly_int} @var{value} is a co

  @item @var{value}.is_constant (&@var{c1})
  Return true if @code{poly_int} @var{value} is a compile-time constant,
 -storing it in @var{c1} if so.  @var{c1} must be able to hold all
 -constant values of @var{value} without loss of precision.
 +storing it in @var{c1} if so.  @var{c1} may be a scalar or a wide int
 +class type capable of holding all constant values of @var{value} without
>>>
>>> Not sure about "a scalar or a wide int", since that implies that wide ints
>>> aren't scalar.  Even more pedantic, sorry, but c1 is an object rather than
>>> a type.
>>>
>>> At a higher level, I'm a bit nervous about singling this out as a special
>>> case, since all the poly_int stuff allows HOST_WIDE_INT, offset_int and
>>> wide_int to be combined in the (hopefully) natural way.  E.g. you can
>>> add offset_ints to poly_int64s, assign HOST_WIDE_INTs to poly_offset_ints,
>>> and so on.
>>>
>>> But if we do keep it like this, how about:
>>>
>>>   @var{c1} must be some form of integer object that can hold all constant
>>>   values of @var{value} without loss of precision; it can be either a normal
>>>   C++ integer or a wide-int class like @code{offset_int}.
>>>
>>> ?
>>
>> Sure.  Attached is an update with your change.
> 
> LGTM (but I can't approve).
That, IMHO, is a technicality :-)  You know these bits better than
anyone.  So if you're OK with them, that's good enough for me :-)

Rubber-stamped for the trunk.


jeff

Re: [PATCH] [RFC] rs6000: -mreadonly-in-sdata (PR82411)

[Segher Boessenkool]

On Wed, Feb 28, 2018 at 01:46:33PM -0800, Kees Cook wrote:
> On Tue, Feb 27, 2018 at 2:01 PM, Segher Boessenkool
>  wrote:
> > This adds a new option -mreadonly-in-sdata (on by default) that
> > controls whether readonly data can be put in sdata.  (For EABI this
> > does nothing, readonly data is put in sdata2 as usual).
> 
> Cool! Thanks for working on this.
> 
> > Kees, could you try this out with your use case?  Add the flag
> > -mno-readonly-in-sdata in your build scripts.  The patch is against
> > GCC trunk.
> 
> I'm struggling to create a ppc cross compiler, otherwise I would be
> happy to test this. :)

For compiling kernels you can use


> If you're able to build a ppc kernel and remove the "static" from
> mm/rodata_test_data.c's rodata_test_data and see the rodata_test_data
> variable not in .sdata, that should be sufficient. The case reported
> was here:
> https://lkml.org/lkml/2017/9/21/156
> 
> I'll continue trying to solve my cross build issue...

I'm trying to figure out how to get that file to build at all :-)


Segher

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

[Roland McGrath via gcc-patches]

On Tue, Feb 27, 2018 at 8:14 PM, Ian Lance Taylor  wrote:
> Still OK, but it should wait until after the tree is back in stage 1.

I've been hoping to get this fixed on stable branches (6, 7).
Are you saying that this bug can only be fixed in 9?
Or will it be OK to backport to 6, 7, and 8 once stage 1 opens for 9?

Thanks,
Roland

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

[Ian Lance Taylor via gcc-patches]

On Wed, Feb 28, 2018 at 3:56 PM, Roland McGrath  wrote:
> On Tue, Feb 27, 2018 at 8:14 PM, Ian Lance Taylor  wrote:
>> Still OK, but it should wait until after the tree is back in stage 1.
>
> I've been hoping to get this fixed on stable branches (6, 7).
> Are you saying that this bug can only be fixed in 9?
> Or will it be OK to backport to 6, 7, and 8 once stage 1 opens for 9?

Since you already ran into trouble, I'm worried that will be other
trouble.  At least, it's hard for me to convince myself that there
won't be any other trouble.  And I don't think we should introduce
trouble at this point in the release cycle.  So, yes, I'd prefer to
see this fixed in GCC 9, and, once people have had a chance to test it
on various systems, backport to earlier versions if appropriate.

Ian

Re: [PATCH] [RFC] rs6000: -mreadonly-in-sdata (PR82411)

[Kees Cook via gcc-patches]

On Wed, Feb 28, 2018 at 3:23 PM, Segher Boessenkool
 wrote:
> On Wed, Feb 28, 2018 at 01:46:33PM -0800, Kees Cook wrote:
>> On Tue, Feb 27, 2018 at 2:01 PM, Segher Boessenkool
>>  wrote:
>> > This adds a new option -mreadonly-in-sdata (on by default) that
>> > controls whether readonly data can be put in sdata.  (For EABI this
>> > does nothing, readonly data is put in sdata2 as usual).
>>
>> Cool! Thanks for working on this.
>>
>> > Kees, could you try this out with your use case?  Add the flag
>> > -mno-readonly-in-sdata in your build scripts.  The patch is against
>> > GCC trunk.
>>
>> I'm struggling to create a ppc cross compiler, otherwise I would be
>> happy to test this. :)
>
> For compiling kernels you can use
> 

Hah, yes, I had just asked around privately about cross building tools
and was aimed there only to discover you're the author. ;)

>> If you're able to build a ppc kernel and remove the "static" from
>> mm/rodata_test_data.c's rodata_test_data and see the rodata_test_data
>> variable not in .sdata, that should be sufficient. The case reported
>> was here:
>> https://lkml.org/lkml/2017/9/21/156
>>
>> I'll continue trying to solve my cross build issue...
>
> I'm trying to figure out how to get that file to build at all :-)

This works for me with my distro cross compiler:

$ git diff
diff --git a/mm/rodata_test.c b/mm/rodata_test.c
index d908c8769b48..6bb4deb12e78 100644
--- a/mm/rodata_test.c
+++ b/mm/rodata_test.c
@@ -14,7 +14,7 @@
 #include 
 #include 

-static const int rodata_test_data = 0xC3;
+const int rodata_test_data = 0xC3;

 void rodata_test(void)
 {

$ CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc make wii_defconfig
$ for i in CONFIG_STRICT_KERNEL_RWX \
   CONFIG_DEBUG_KERNEL \
   CONFIG_DEBUG_RODATA_TEST ; do
CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc ./scripts/config -e $i
done

$ CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc make -j...
...
$ objdump -t mm/rodata_test.o | grep rodata_test_data
 g O .sdata 0004 rodata_test_data


-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

[Roland McGrath via gcc-patches]

OK.  I'll come back in stage 1.

Thanks,
Roland

Re: [PATCH] [RFC] rs6000: -mreadonly-in-sdata (PR82411)

[Segher Boessenkool]

On Wed, Feb 28, 2018 at 04:15:23PM -0800, Kees Cook wrote:
> On Wed, Feb 28, 2018 at 3:23 PM, Segher Boessenkool
>  wrote:
> > I'm trying to figure out how to get that file to build at all :-)

> $ CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc make wii_defconfig
> $ for i in CONFIG_STRICT_KERNEL_RWX \
>CONFIG_DEBUG_KERNEL \
>CONFIG_DEBUG_RODATA_TEST ; do
> CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc ./scripts/config -e $i
> done

I use ppc6xx_defconfig normally; I had to disable CONFIG_HIBERNATION
as well.

Without the new flag, rodata_test_data ends up in .sdata in the object
file and in .data in vmlinux.

Adding

===
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index ccd2556..31b9613 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -143,6 +143,8 @@ CFLAGS-$(CONFIG_PPC64)  += $(call cc-option,-mcmodel=med
 CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions)
 CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 $(MULTIPLEWORD)
 
+CFLAGS-$(CONFIG_PPC32) += $(call cc-option,-mno-readonly-in-sdata)
+
 ifeq ($(CONFIG_PPC_BOOK3S_64),y)
 CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power7,-mtune=power4)
 CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power4
===

it ends up in .rodata in both.

It would be nice to have a more comprehensive test, but this will do; I'll
commit it tomorrow (will resend, with doc and changelog and all that).

Cheers,


Segher

Re: [PATCH] [RFC] rs6000: -mreadonly-in-sdata (PR82411)

[Kees Cook via gcc-patches]

On Wed, Feb 28, 2018 at 4:39 PM, Segher Boessenkool
 wrote:
> On Wed, Feb 28, 2018 at 04:15:23PM -0800, Kees Cook wrote:
>> On Wed, Feb 28, 2018 at 3:23 PM, Segher Boessenkool
>>  wrote:
>> > I'm trying to figure out how to get that file to build at all :-)
>
>> $ CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc make wii_defconfig
>> $ for i in CONFIG_STRICT_KERNEL_RWX \
>>CONFIG_DEBUG_KERNEL \
>>CONFIG_DEBUG_RODATA_TEST ; do
>> CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc ./scripts/config -e $i
>> done
>
> I use ppc6xx_defconfig normally; I had to disable CONFIG_HIBERNATION
> as well.
>
> Without the new flag, rodata_test_data ends up in .sdata in the object
> file and in .data in vmlinux.
>
> Adding
>
> ===
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index ccd2556..31b9613 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -143,6 +143,8 @@ CFLAGS-$(CONFIG_PPC64)  += $(call 
> cc-option,-mcmodel=med
>  CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions)
>  CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 $(MULTIPLEWORD)
>
> +CFLAGS-$(CONFIG_PPC32) += $(call cc-option,-mno-readonly-in-sdata)
> +
>  ifeq ($(CONFIG_PPC_BOOK3S_64),y)
>  CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power7,-mtune=power4)
>  CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power4
> ===
>
> it ends up in .rodata in both.

Excellent! That's perfect. :)

> It would be nice to have a more comprehensive test, but this will do; I'll
> commit it tomorrow (will resend, with doc and changelog and all that).

Thank you! Do you want to send the Makefile fix upstream too, or
should I route that?

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH] [RFC] rs6000: -mreadonly-in-sdata (PR82411)

[Segher Boessenkool]

On Wed, Feb 28, 2018 at 04:43:56PM -0800, Kees Cook wrote:
> On Wed, Feb 28, 2018 at 4:39 PM, Segher Boessenkool
>  wrote:
> > On Wed, Feb 28, 2018 at 04:15:23PM -0800, Kees Cook wrote:
> >> On Wed, Feb 28, 2018 at 3:23 PM, Segher Boessenkool
> >>  wrote:
> >> > I'm trying to figure out how to get that file to build at all :-)
> >
> >> $ CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc make wii_defconfig
> >> $ for i in CONFIG_STRICT_KERNEL_RWX \
> >>CONFIG_DEBUG_KERNEL \
> >>CONFIG_DEBUG_RODATA_TEST ; do
> >> CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc ./scripts/config -e $i
> >> done
> >
> > I use ppc6xx_defconfig normally; I had to disable CONFIG_HIBERNATION
> > as well.
> >
> > Without the new flag, rodata_test_data ends up in .sdata in the object
> > file and in .data in vmlinux.
> >
> > Adding
> >
> > ===
> > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> > index ccd2556..31b9613 100644
> > --- a/arch/powerpc/Makefile
> > +++ b/arch/powerpc/Makefile
> > @@ -143,6 +143,8 @@ CFLAGS-$(CONFIG_PPC64)  += $(call 
> > cc-option,-mcmodel=med
> >  CFLAGS-$(CONFIG_PPC64) += $(call 
> > cc-option,-mno-pointers-to-nested-functions)
> >  CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 $(MULTIPLEWORD)
> >
> > +CFLAGS-$(CONFIG_PPC32) += $(call cc-option,-mno-readonly-in-sdata)
> > +
> >  ifeq ($(CONFIG_PPC_BOOK3S_64),y)
> >  CFLAGS-$(CONFIG_GENERIC_CPU) += $(call 
> > cc-option,-mtune=power7,-mtune=power4)
> >  CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power4
> > ===
> >
> > it ends up in .rodata in both.
> 
> Excellent! That's perfect. :)
> 
> > It would be nice to have a more comprehensive test, but this will do; I'll
> > commit it tomorrow (will resend, with doc and changelog and all that).
> 
> Thank you! Do you want to send the Makefile fix upstream too, or
> should I route that?

If you could?  Have my

Signed-off-by: Segher Boessenkool 

if you want.

It'll be a while before all users have a compiler with the new flag, but
I'll backport it to GCC 7 and GCC 6 (the open release branches) to speed
that up a bit.


Segher

Re: [PATCH] Fix -fcompare-debug failure on pr84146.c (PR target/84146)

[Paul Hua]

Hi Jakub:

It's introduce a regression on mips target.
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84623.

Paul hua


On Thu, Feb 8, 2018 at 6:36 AM, Jakub Jelinek  wrote:
> Hi!
>
> Unfortunately, seems my rest_of_insert_endbranch fix doesn't fix
> -fcompare-debug on the testcase, when adding the endbr after the setjmp
> call with no note in between, we add it into the same bb as the setjmp call,
> while when adding it with -g with NOTE_INSN_CALL_ARG_LOCATION, which is
> already outside of the bb, we add it outside of bb.
>
> This patch fixes it by removing lots of code:
>  22 files changed, 50 insertions(+), 205 deletions(-)
> instead of sticking the call arg location info into a separate note that
> is required to be adjacent to the call and thus requires lots of special
> cases everywhere we emit it as a REG_CALL_ARG_LOCATION note in REG_NOTES
> directly on the call.
> All we need to ensure is that we remove that reg note before emitting
> -fcompare-debug final insns dump, and need to unshare the rtl in there
> (apparently rtl sharing verification ignores
> NOTE_INSN_{CALL_ARG,VAR}_LOCATION notes, but of course not REG_NOTES).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-02-07  Jakub Jelinek  
>
> PR target/84146
> * reg-notes.def (REG_CALL_ARG_LOCATION): New reg note.
> * insn-notes.def (NOTE_INSN_CALL_ARG_LOCATION): Remove.
> * var-tracking.c (emit_note_insn_var_location): Remove all references
> to NOTE_INSN_CALL_ARG_LOCATION.
> (emit_notes_in_bb): Emit arguments as REG_CALL_ARG_LOCATION note on
> the CALL_INSN rather than separate NOTE_INSN_CALL_ARG_LOCATION note.
> Use copy_rtx_if_shared.
> * dwarf2out.c (gen_subprogram_die): Use XEXP with 0 instead of
> NOTE_VAR_LOCATION on ca_loc->call_arg_loc_note.
> (dwarf2out_var_location): Remove handling of
> NOTE_INSN_CALL_ARG_LOCATION, instead handle REG_CALL_ARG_LOCATION note
> on call_insn.
> * final.c (final_scan_insn): Remove all references to
> NOTE_INSN_CALL_ARG_LOCATION.
> (rest_of_clean_state): Likewise.  Remove REG_CALL_ARG_LOCATION notes
> before dumping final insns.
> * except.c (emit_note_eh_region_end): Remove all references to
> NOTE_INSN_CALL_ARG_LOCATION.
> * config/alpha/alpha.c (alpha_pad_function_end): Likewise.
> * config/c6x/c6x.c (c6x_gen_bundles): Likewise.
> * config/arc/arc.c (hwloop_optimize): Likewise.
> * config/arm/arm.c (create_fix_barrier): Likewise.
> * config/s390/s390.c (s390_chunkify_start): Likewise.
> * config/sh/sh.c (find_barrier): Likewise.
> * config/i386/i386.c (rest_of_insert_endbranch,
> ix86_seh_fixup_eh_fallthru): Likewise.
> * config/xtensa/xtensa.c (hwloop_optimize): Likewise.
> * config/iq2000/iq2000.c (final_prescan_insn): Likewise.
> * config/frv/frv.c (frv_function_prologue): Likewise.
> * emit-rtl.c (try_split): Likewise.  Copy over REG_CALL_ARG_LOCATION
> reg note.
> (note_outside_basic_block_p): Remove all references to
> NOTE_INSN_CALL_ARG_LOCATION.
> * gengtype.c (adjust_field_rtx_def): Likewise.
> * print-rtl.c (rtx_writer::print_rtx_operand_code_0, print_insn):
> Likewise.
> * jump.c (cleanup_barriers, delete_related_insns): Likewise.
> * cfgrtl.c (force_nonfallthru_and_redirect): Likewise.
>
> * gcc.target/i386/pr84146.c: Add -fcompare-debug to dg-options.
>
> --- gcc/reg-notes.def.jj2018-01-03 10:19:55.239533971 +0100
> +++ gcc/reg-notes.def   2018-02-07 16:40:03.800915206 +0100
> @@ -239,3 +239,6 @@ REG_NOTE (CALL_DECL)
> when a called function has a 'notrack' attribute.  This note is used by 
> the
> compiler when the option -fcf-protection=branch is specified.  */
>  REG_NOTE (CALL_NOCF_CHECK)
> +
> +/* The values passed to callee, for debuginfo purposes.  */
> +REG_NOTE (CALL_ARG_LOCATION)
> --- gcc/insn-notes.def.jj   2018-01-03 10:19:55.669534040 +0100
> +++ gcc/insn-notes.def  2018-02-07 16:40:03.800915206 +0100
> @@ -65,9 +65,6 @@ INSN_NOTE (EH_REGION_END)
>  /* The location of a variable.  */
>  INSN_NOTE (VAR_LOCATION)
>
> -/* The values passed to callee.  */
> -INSN_NOTE (CALL_ARG_LOCATION)
> -
>  /* The beginning of a statement.  */
>  INSN_NOTE (BEGIN_STMT)
>
> --- gcc/var-tracking.c.jj   2018-02-07 13:11:26.950985542 +0100
> +++ gcc/var-tracking.c  2018-02-07 16:44:10.810478942 +0100
> @@ -8860,14 +8860,12 @@ emit_note_insn_var_location (variable **
>/* Make sure that the call related notes come first.  */
>while (NEXT_INSN (insn)
>  && NOTE_P (insn)
> -&& ((NOTE_KIND (insn) == NOTE_INSN_VAR_LOCATION
> - && NOTE_DURING_CALL_P (insn))
> -|| NOTE_KIND (insn) == NOTE_INSN_CALL_ARG_LOCATION))
> +&& NOTE_KIND (insn) == NOTE_IN

Re: [PATCH 1/2] Untangle stddef.h a little

[coypu]

hi gcc-patches,

as part of pinging, i'll explain the story of this patch.

I want to make sure all netbsd archs work with upstream gcc.
in this case, netbsd/arm's EABI support.
I try to break up my changes into digestible chunks that are rational,
which is why this change came first.

building netbsd/arm gcc-trunk, I had a build error in libstdc++, because
this stddef.h relies on include guards:

#if defined(_ANSI_H_) || defined(_MACHINE_ANSI_H_) || defined(_X86_64_ANSI_H_)  
|| defined(_I386_ANSI_H_)

In theory I could have just added:
 || _ARM_ANSI_H_

this felt gross, so I tried a better solution.
the file even comes with comments like:
  /* Why is this file so hard to maintain properly?
so I try my best to help.

Please let me upstream local changes. there are a lot of them. and I
feel unable to get them across.
I have so many changes that it feels inappropriate to ask for help with
hard problems like internal compiler errors because upstream GCC hit a
different problem. I'm not familiar with stuff so this is hard :-(

Re: [PATCH, rs6000] Fix PR84534: several powerpc test cases fail starting with r257915

[Peter Bergner]

On 2/28/18 5:01 PM, Segher Boessenkool wrote:
> On Wed, Feb 28, 2018 at 04:51:27PM -0600, Peter Bergner wrote:
>> Doh!  I was going to say "why?" since we're xfailing it everywhere, but I
> 
> Because you can use a few more words in changelog entries ;-)
> 
> "Add xfail." is fine, too.  Just "xfail." is unclear.

Ok.



>> So should we go with my original idea above?  Or maybe we don't care
>> that we XFAIL on some targets since we're just going to remove the
>> test next release with the removal -maltivec=be?
> 
> It would be nice to have clean test results, which is all this patch is
> about anyway, right?

Ok, this XFAILs the test case and shouldn't create any extra noise when
it shouldn't.  I also added the comment about no longer counting xxlor
insns.  Better?

Peter

PR target/84534
* gcc.target/powerpc/vec-setup-be-long.c: Add dg-xfail-run-if
on powerpc64le*-*-linux*.
* gcc.target/powerpc/vsx-vector-6-le.c: Do not count xxlor's.
* gcc.target/powerpc/vsx-vector-6-le.p9.c: Likewise.

Index: gcc/testsuite/gcc.target/powerpc/vec-setup-be-long.c
===
--- gcc/testsuite/gcc.target/powerpc/vec-setup-be-long.c(revision 
258038)
+++ gcc/testsuite/gcc.target/powerpc/vec-setup-be-long.c(working copy)
@@ -1,4 +1,7 @@
+/* Per PR78303, we are deprecating usage of -maltivec=be on little endian,
+   so XFAIL this test until support is actually removed.  */
 /* { dg-do run { target { powerpc64le*-*-linux* } } } */
+/* { dg-xfail-run-if "PR78303 and PR84534" { powerpc64le*-*-linux* } } */
 /* { dg-require-effective-target vsx_hw } */
 /* Disable warnings to squelch deprecation message about -maltivec=be.  */
 /* { dg-options "-w -O2 -mvsx -maltivec=be" } */
Index: gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c  (revision 258038)
+++ gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c  (working copy)
@@ -9,7 +9,11 @@
 /* { dg-final { scan-assembler-times "xvabsdp" 1 } } */
 /* { dg-final { scan-assembler-times "xvadddp" 1 } } */
 /* { dg-final { scan-assembler-times "xxlnor" 8 } } */
-/* { dg-final { scan-assembler-times "xxlor" 30 } } */
+/* We generate xxlor instructions for many reasons other than or'ing vector
+   operands or calling __builtin_vec_or(), which  means we cannot rely on
+   their usage counts being stable.  Therefore, we just ensure at least one
+   xxlor instruction was generated.  */
+/* { dg-final { scan-assembler "xxlor" } } */
 /* { dg-final { scan-assembler-times "xvcmpeqdp" 5 } } */
 /* { dg-final { scan-assembler-times "xvcmpgtdp" 8 } } */
 /* { dg-final { scan-assembler-times "xvcmpgedp" 6 } } */
Index: gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.p9.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.p9.c   (revision 
258038)
+++ gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.p9.c   (working copy)
@@ -9,7 +9,11 @@
 /* { dg-final { scan-assembler-times "xvabsdp" 1 } } */
 /* { dg-final { scan-assembler-times "xvadddp" 1 } } */
 /* { dg-final { scan-assembler-times "xxlnor" 7 } } */
-/* { dg-final { scan-assembler-times "xxlor" 20 } } */
+/* We generate xxlor instructions for many reasons other than or'ing vector
+   operands or calling __builtin_vec_or(), which  means we cannot rely on
+   their usage counts being stable.  Therefore, we just ensure at least one
+   xxlor instruction was generated.  */
+/* { dg-final { scan-assembler "xxlor" } } */
 /* { dg-final { scan-assembler-times "xvcmpeqdp" 5 } } */
 /* { dg-final { scan-assembler-times "xvcmpgtdp" 8 } } */
 /* { dg-final { scan-assembler-times "xvcmpgedp" 8 } } */

Re: [PATCH 1/2] Untangle stddef.h a little

[Kamil Rytarowski]

On 01.03.2018 03:43, co...@sdf.org wrote:
> hi gcc-patches,
> 
> as part of pinging, i'll explain the story of this patch.
> 
> I want to make sure all netbsd archs work with upstream gcc.
> in this case, netbsd/arm's EABI support.
> I try to break up my changes into digestible chunks that are rational,
> which is why this change came first.
> 
> building netbsd/arm gcc-trunk, I had a build error in libstdc++, because
> this stddef.h relies on include guards:
> 
> #if defined(_ANSI_H_) || defined(_MACHINE_ANSI_H_) || 
> defined(_X86_64_ANSI_H_)  || defined(_I386_ANSI_H_)
> 
> In theory I could have just added:
>  || _ARM_ANSI_H_
> 
> this felt gross, so I tried a better solution.
> the file even comes with comments like:
>   /* Why is this file so hard to maintain properly?
> so I try my best to help.
> 
> Please let me upstream local changes. there are a lot of them. and I
> feel unable to get them across.
> I have so many changes that it feels inappropriate to ask for help with
> hard problems like internal compiler errors because upstream GCC hit a
> different problem. I'm not familiar with stuff so this is hard :-(
> 

Looks good, ping from my point of view for maintainers.

Adding defined(_*_ANSI_H) for each CPU and flavor of headers on NetBSD
does not scale even for the existing set of supported architectures.

NetBSD/hpcsh uses _HPCSH_ANSI_H_, NetBSD/dreamcast _DREAMCAST_ANSI_H_ etc.



signature.asc
Description: OpenPGP digital signature