Re: [PATCH][AArch64] Implement ALU_BRANCH fusion

[Hurugalawadi, Naveen]

Hi James,

>> My reason for asking is that the instruction fusion implemented in LLVM
>> ( lib/Target/AArch64/AArch64MacroFusion.cpp::shouldScheduleAdjacent )

Sorry. There seems to be some confusion in the branch instructions.
The branch should be conditional for ALU_BRANCH fusion.

Please find attached the modified patch that fuses ALU instructions and
conditional branches.

Bootstrapped and Regression tested on aarch64-thunder-linux.
Please review the patch and let us know if its okay?

Thanks,
Naveen
diff --git a/gcc/config/aarch64/aarch64-fusion-pairs.def b/gcc/config/aarch64/aarch64-fusion-pairs.def
index f0e6dbc..300cd00 100644
--- a/gcc/config/aarch64/aarch64-fusion-pairs.def
+++ b/gcc/config/aarch64/aarch64-fusion-pairs.def
@@ -34,5 +34,6 @@ AARCH64_FUSION_PAIR ("movk+movk", MOVK_MOVK)
 AARCH64_FUSION_PAIR ("adrp+ldr", ADRP_LDR)
 AARCH64_FUSION_PAIR ("cmp+branch", CMP_BRANCH)
 AARCH64_FUSION_PAIR ("aes+aesmc", AES_AESMC)
+AARCH64_FUSION_PAIR ("alu+branch", ALU_BRANCH)
 
 #undef AARCH64_FUSION_PAIR
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index a069427..f76a2ff 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -792,7 +792,8 @@ static const struct tune_params thunderx2t99_tunings =
   _approx_modes,
   4, /* memmov_cost.  */
   4, /* issue_rate.  */
-  (AARCH64_FUSE_CMP_BRANCH | AARCH64_FUSE_AES_AESMC), /* fusible_ops  */
+  (AARCH64_FUSE_CMP_BRANCH | AARCH64_FUSE_AES_AESMC
+   | AARCH64_FUSE_ALU_BRANCH), /* fusible_ops  */
   16,	/* function_align.  */
   8,	/* jump_align.  */
   16,	/* loop_align.  */
@@ -13981,6 +13982,37 @@ aarch_macro_fusion_pair_p (rtx_insn *prev, rtx_insn *curr)
 return true;
 }
 
+  if (aarch64_fusion_enabled_p (AARCH64_FUSE_ALU_BRANCH)
+  && any_condjump_p (curr))
+{
+  /* These types correspond to the reservation "vulcan_alu_basic" for
+	 Broadcom Vulcan: these are ALU operations that produce a single uop
+	 during instruction decoding.  */
+  switch (get_attr_type (prev))
+	{
+	case TYPE_ALU_IMM:
+	case TYPE_ALU_SREG:
+	case TYPE_ADC_REG:
+	case TYPE_ADC_IMM:
+	case TYPE_ADCS_REG:
+	case TYPE_ADCS_IMM:
+	case TYPE_LOGIC_REG:
+	case TYPE_LOGIC_IMM:
+	case TYPE_CSEL:
+	case TYPE_ADR:
+	case TYPE_MOV_IMM:
+	case TYPE_SHIFT_REG:
+	case TYPE_SHIFT_IMM:
+	case TYPE_BFM:
+	case TYPE_RBIT:
+	case TYPE_REV:
+	case TYPE_EXTEND:
+	  return true;
+
+	default:;
+	}
+}
+
   return false;
 }
 

[P1][bootstrap/79771] [PATCH] Hack around zlib bug on Cygwin

[Jeff Law]

Our current version of zlib has a bug where zlib has an unsatisfied 
reference to _wopen on Cygnwin.


This is a bug in the upstream zlib and is being discussed there.  This 
patch (from Yaakov Selkowitz) works around the problem and we'll carry 
it as a local change until upstream decides on the proper fix.


Installed on the trunk.

Jeff
diff --git a/zlib/ChangeLog.gcj b/zlib/ChangeLog.gcj
index 4792811..9a7fa51 100644
--- a/zlib/ChangeLog.gcj
+++ b/zlib/ChangeLog.gcj
@@ -1,3 +1,10 @@
+2017-03-15  Yaakov Selkowitz 
+
+   PR bootstrap/79771
+   * gzguts.h (WIDECHAR): Do not define for __CYGWIN__.
+   * zlib.h (gzopen_w): Do not declare for __CYGWIN__.
+   * win32/zlib.def: Remove gzopen_w.
+   
 2017-01-22  Matthias Klose  
 
* Import zlib 1.2.11.
diff --git a/zlib/gzguts.h b/zlib/gzguts.h
index 990a4d2..6378d46 100644
--- a/zlib/gzguts.h
+++ b/zlib/gzguts.h
@@ -39,7 +39,7 @@
 #  include 
 #endif
 
-#if defined(_WIN32) || defined(__CYGWIN__)
+#if defined(_WIN32)
 #  define WIDECHAR
 #endif
 
diff --git a/zlib/win32/zlib.def b/zlib/win32/zlib.def
index 784b138..0cb3f5d 100644
--- a/zlib/win32/zlib.def
+++ b/zlib/win32/zlib.def
@@ -91,4 +91,3 @@ EXPORTS
 inflateCodesUsed
 inflateResetKeep
 deflateResetKeep
-gzopen_w
diff --git a/zlib/zlib.h b/zlib/zlib.h
index f09cdaf..49dfcec 100644
--- a/zlib/zlib.h
+++ b/zlib/zlib.h
@@ -1893,7 +1893,7 @@ ZEXTERN intZEXPORT inflateValidate 
OF((z_streamp, int));
 ZEXTERN unsigned long  ZEXPORT inflateCodesUsed OF ((z_streamp));
 ZEXTERN intZEXPORT inflateResetKeep OF((z_streamp));
 ZEXTERN intZEXPORT deflateResetKeep OF((z_streamp));
-#if (defined(_WIN32) || defined(__CYGWIN__)) && !defined(Z_SOLO)
+#if defined(_WIN32) && !defined(Z_SOLO)
 ZEXTERN gzFile ZEXPORT gzopen_w OF((const wchar_t *path,
 const char *mode));
 #endif

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #9 from Jeffrey A. Law  ---
Yaakov's patch has been installed as a local change while upstream figures out
they want to address in the long term.

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Wed Mar 15 05:01:23 2017
New Revision: 246152

URL: https://gcc.gnu.org/viewcvs?rev=246152=gcc=rev
Log:
2017-03-15  Yaakov Selkowitz 

PR bootstrap/79771
* gzguts.h (WIDECHAR): Do not define for __CYGWIN__.
* zlib.h (gzopen_w): Do not declare for __CYGWIN__.
* win32/zlib.def: Remove gzopen_w.

Modified:
trunk/zlib/ChangeLog.gcj
trunk/zlib/gzguts.h
trunk/zlib/win32/zlib.def
trunk/zlib/zlib.h

[Bug tree-optimization/79800] [7 Regression] wrong snprintf result range with precision in a narrow negative-positive range

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79800

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #4 from Jeffrey A. Law  ---
Fixed by Martin's patch on the trunk.

Re: [PATCH] correct handling of negative-positive precision ranges with floating directives (PR 79800)

[Jeff Law]

On 03/13/2017 06:33 PM, Martin Sebor wrote:

The output of a floating point directive whose precision is
specified by an asterisk with an argument that's in a range
that includes both negative and positive values less than
six may include between zero and six fractional digits plus
a decimal point.  For example,

  printf ("%.*e", p, x);

results in the 14 bytes

  -1.797693e+308

when p == -1 and x == -DBL_MIN because a negative precision
is ignored and the directive assumes the default 6, and in
just the one byte

  0

when p == 0 and x == 0.0.

Current trunk doesn't handle this case correctly when the
floating argument isn't known and uses the upper bound of
the specified precision as the maximum number of fractional
digits.  As a result, it sets the range on the return value
in this case as [5, 7] (plus 5 for the longest multibyte
decimal decimal point) when the correct range is [5, 14] as
explained above (plus 5 again).

The attached patch corrects the handling of such precision
ranges to avoid this unlikely bug.

Martin

gcc-79800.diff


PR tree-optimization/79800 - wrong snprintf result range with precision in a 
narrow negative-positive range

gcc/ChangeLog:

PR tree-optimization/79800
* gimple-ssa-sprintf.c (format_floating: Add argument.  Handle
precision in negative-positive range.
(format_floating): Call non-const overload with adjusted precision.

gcc/testsuite/ChangeLog:

PR tree-optimization/79800
* gcc.dg/tree-ssa/builtin-sprintf-warn-15.c: Add test cases.
* gcc.dg/tree-ssa/pr79800.c: New test.

Thanks.  Installed.

jeff

[Bug tree-optimization/79800] [7 Regression] wrong snprintf result range with precision in a narrow negative-positive range

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79800

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Wed Mar 15 04:31:27 2017
New Revision: 246151

URL: https://gcc.gnu.org/viewcvs?rev=246151=gcc=rev
Log:
PR tree-optimization/79800
* gimple-ssa-sprintf.c (format_floating: Add argument.  Handle
precision in negative-positive range.
(format_floating): Call non-const overload with adjusted precision.

PR tree-optimization/79800
* gcc.dg/tree-ssa/builtin-sprintf-warn-15.c: Add test cases.
* gcc.dg/tree-ssa/pr79800.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr79800.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-15.c

Re: [PATCH] Suppress compiler warning in libgcc/unwind-seh.c

[Jeff Law]

On 03/01/2017 04:36 AM, JonY wrote:

Patch OK?

ChangeLog:
* unwind-seh.c: Suppress warnings for RtlUnwindEx() calls.
You know this stuff better than anyone else working with GCC.  If you 
think this is the right thing to do for the SEH code, go for it.


jeff

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #6 from Jerry DeLisle  ---
(In reply to Nicolas Koenig from comment #5)
> Created attachment 40977 [details]
> Proposed patch to fix the ICE
> 
> After far too many hours in the depths of gdb, there appeared to be one
> malicious statement in the code. This patch should fix it.
> 
> Regression tested for GNU Fortran (GCC) 7.0.1 20170314 (experimental) on
> x86_64-pc-linux-gnu with no regressions.

This falls into the PITA classification. Also known as simple enough,
regression test and commit. (consider it approved)

Re: patch, libfortran] [patch, fortran] Fix PR 79956, part two, attempt 3

[Jerry DeLisle]

On 03/14/2017 04:01 PM, Thomas Koenig wrote:
> Hello world,
> 
> well, here is the third attempt at fixing the second part of the PR.
> Glancing over the source, I think there are quite a few places where
> we currently issue a runtime error which we could replace by an
> assert, but that's something for 8.0.
> 
> Regression-tested on x86_64-pc-linux-gnu.
> 
> OK for trunk?

Yes, OK.

Jerry

Re: Diagnostics that should not be translated

[Martin Sebor]

On 03/12/2017 04:51 PM, Roland Illig wrote:

Hi,

the gcc.pot file currently contains more than 12000 messages to be
translated, which is a very high number. Many of these messages are
diagnostics, and they can be categorized as follows:

* errors in user programs, reported via error ()
* additional info for internal errors, reported via error ()
* internal errors, reported via gfc_internal_error ()
* others

In my opinion, there is no point in having internal error messages
translated, since their only purpose is to be sent back to the GCC
developers, instead of being interpreted and acted upon by the GCC user.
By not translating the internal errors, the necessary work for
translators can be cut down by several hundred messages.

Therefore the internal errors should not be translated at all.
https://gcc.gnu.org/codingconventions.html#Diagnostics currently
mentions a few ways of emitting diagnostics, but there is no way to
produce untranslated diagnostics. Therefore I'd like to have a new
function error_no_i18n that is used instead of error for nonfatal
internal errors, like this:

@code{error_no_i18n} is for diagnostics that are printed before invoking
internal_error. They are not translated.


AFAIK, internal errors are reported using the internal_error
or internal_error_no_backtrace APIs.

Would using the existing internal_error{,no_backtrace}, and
sorry work for this? (I.e., not translating those.)  If my
count is right there are nearly 500 calls to these three in
GCC sources so I'm not sure that would put enough of a dent
in the 12K messages to translate but I'm even less sure that
adding yet another API would do even that much.

There are 20-some-odd functions to report diagnostics in GCC
(counting those in diagnostic-core.h).  I haven't used them all
or even understand all their differences and use cases yet so
I would rather no add more to the list if it can be helped.

Martin

Re: [PATCH doc] use "cannot" consistently

[Martin Sebor]

On 03/14/2017 02:53 PM, Richard Kenner wrote:

The GCC manual uses "cannot" in most places (280 lines) but there
are a few instances of "can't" (33 lines).

The attached patch replaces the informal "can't" with the former
for consistency.


In my opinion, this is the wrong direction.  Contractions are becoming
more acceptable in even more formal writing and there's even a current
US Supreme Court justice who uses them in her opinions.

I certainly don't think it's worth a change to use "can't" throughout,
but I'm not in favor of eliminating it either.


I don't consider this change important enough to spend too much
time on but since you voiced an objection but offered little in
the way of a rationale I feel I'd be remiss not to respond and
explain my perspective.

First, I agree that the less formal language is becoming more
acceptable.  Some style guides explicitly allow contractions,
but others advise against them.  The technical specifications
that significant parts of GCC aim to conform to, and those I
happen  to work with the most closely (the C, C++, and POSIX
standards), avoid them.  The IEEE Editorial Style Manual
recommends against using them.  The author of Engineer's Guide
to Technical Writing, Kenneth Budinski, equates them with slang.

I personally don't feel too strongly about it, but the change
seems like an opportunity to improve not just the style of
the manual but also increase its consistency.  I could see
one being indifferent to such changes but I have trouble
understanding how they could be viewed as the wrong direction.
What is your rationale against it and what would you consider
the right direction for the manual?

Martin

PS While researching this subject I came across the following
two interesting references that I think are worth quoting:

In Engineer's Guide to Technical Writing, the author writes:

  Contractions should never be used in technical writing [my
  opinion].  They are essentially a form of slang, and slang
  expressions are not appropriate in technical writing.  Some
  technical writers disagree with it.  They believe that writing
  without contractions is stiff.  Use the appropriate practice
  for your organization.  Use contractions sparingly, if at all.

The NASA Technical Documentation Style Guide offers, in my view,
sound advice:

  Contractions (for example, it's for it is or it has; don't for
  do not; doesn't for does not; isn't for is not; and won't for
  will not) are not forbidden in technical or business writing.
  A few well-placed contractions can help your material sound as
  if a person wrote it--always a worthy goal.  But too many
  contractions can make your message sound too casual.

The challenge with following this advice in the GCC manual is
that engineers are rarely good at writing or judging the right
tone of text.  Often, contributions are also made by non-native
speakers some of whom may not be able to discern between the of
a contraction that helps achieve the goal and one that works
against it.  The one thing most of us do have is an eye and
affinity for consistency, so using one style consistently
throughout the manual seems like a good (and safe) approach.

[Bug target/61837] missed loop invariant expression optimization

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-15
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
Confirmed.  Still happens.

[Bug target/62147] missed loop counter based optimization

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62147

--- Comment #3 from Segher Boessenkool  ---
Still happens.

[Bug target/62233] unnecessary shift instructions to prepare loop counter

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62233

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #3 from Segher Boessenkool  ---
Both trunk and 6 generate

rldicl 9,9,0,2

instead of the two shifts.  Still not ideal of course.

[Bug sanitizer/65643] FAIL: c-c++-common/asan/swapcontext-test-1.c on powerpc64

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65643

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #4 from Segher Boessenkool  ---
This was a bug in glibc, see
https://sourceware.org/bugzilla/show_bug.cgi?id=20004 , fixed at
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=cbc06bc486635347ee0da51d04a82eedf51602d5
.

No GCC testsuite workaround planned; closing the bug here.

[Bug translation/80001] diagnostics: untranslateable %s placeholders in omp-offload.c

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80001

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-15
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00795.html

[Bug c++/80016] error is positioned incorrectly

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80016

--- Comment #2 from David Malcolm  ---
Candidate patch for bogus *starting* location:
  https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00797.html

(this doesn't fix the bogus finish location)

[Bug c++/80014] [6/7 Regression] Caret missing in error message

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80014

--- Comment #4 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00796.html

[Bug fortran/79852] diagnostics should not end with exclamation mark

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79852

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-15
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from David Malcolm  ---
Resend of patch to fortran list:
  https://gcc.gnu.org/ml/fortran/2017-03/msg00064.html

[Bug fortran/79860] i18n: single-word translation in "Character-valued %s %qs"

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79860

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-15
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/fortran/2017-03/msg00065.html

[PATCH] Fix location of sizeof/alignof (PR c++/80016)

[David Malcolm]

PR c++/80016 reports an issue with bizarre underlined range
for a complicated expression.

The root cause for the incorrect *starting* location of that range
is that alignof and sizeof expressions currently have
start == finish == caret at the opening parenthesis of the
expression.

This patch fixes this by generating appropriate start and finish
locations for alignof and sizeof expressions.

Successfully bootstrapped on x86_64-pc-linux-gnu.

OK for trunk now, or should this wait until stage 1?

gcc/cp/ChangeLog:
PR c++/80016
* parser.c (cp_parser_unary_expression):  Generate a location
range for alignof and sizeof expressions.

gcc/testsuite/ChangeLog:
PR c++/80016
* g++.dg/plugin/diagnostic-test-expressions-1.C (test_sizeof): New
test function.
(test_alignof): New test function.
---
 gcc/cp/parser.c| 19 +--
 .../g++.dg/plugin/diagnostic-test-expressions-1.C  | 66 ++
 2 files changed, 81 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index aecf9a5..0d9667e 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -7817,12 +7817,11 @@ cp_parser_unary_expression (cp_parser *parser, 
cp_id_kind * pidk,
  {
tree operand, ret;
enum tree_code op;
-   location_t first_loc;
+   location_t start_loc = token->location;
 
op = keyword == RID_ALIGNOF ? ALIGNOF_EXPR : SIZEOF_EXPR;
/* Consume the token.  */
cp_lexer_consume_token (parser->lexer);
-   first_loc = cp_lexer_peek_token (parser->lexer)->location;
/* Parse the operand.  */
operand = cp_parser_sizeof_operand (parser, keyword);
 
@@ -7858,9 +7857,21 @@ cp_parser_unary_expression (cp_parser *parser, 
cp_id_kind * pidk,
TREE_SIDE_EFFECTS (ret) = 0;
TREE_READONLY (ret) = 1;
  }
-   SET_EXPR_LOCATION (ret, first_loc);
  }
-   return ret;
+
+   /* Construct a location e.g. :
+  alignof (expr)
+  ^~
+  with start == caret at the start of the "alignof"/"sizeof"
+  token, with the endpoint at the final closing paren.  */
+   location_t finish_loc
+ = cp_lexer_previous_token (parser->lexer)->location;
+   location_t compound_loc
+ = make_location (start_loc, start_loc, finish_loc);
+
+   cp_expr ret_expr (ret);
+   ret_expr.set_location (compound_loc);
+   return ret_expr;
  }
 
case RID_NEW:
diff --git a/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C 
b/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C
index 3554086..64eb660 100644
--- a/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C
+++ b/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C
@@ -101,6 +101,72 @@ int test_postfix_incdec (int i)
 
 /* Unary operators.  /
 
+int test_sizeof (int i)
+{
+  __emit_expression_range (0, sizeof(int) + i); /* { dg-warning "range" } */
+/* { dg-begin-multiline-output "" }
+   __emit_expression_range (0, sizeof(int) + i);
+   ^~~
+   { dg-end-multiline-output "" } */
+
+  __emit_expression_range (0, i + sizeof(int)); /* { dg-warning "range" } */
+/* { dg-begin-multiline-output "" }
+   __emit_expression_range (0, i + sizeof(int));
+   ~~^
+   { dg-end-multiline-output "" } */
+
+  __emit_expression_range (0, sizeof i + i); /* { dg-warning "range" } */
+/* { dg-begin-multiline-output "" }
+   __emit_expression_range (0, sizeof i + i);
+   ~^~~
+   { dg-end-multiline-output "" } */
+
+  __emit_expression_range (0, i + sizeof i); /* { dg-warning "range" } */
+/* { dg-begin-multiline-output "" }
+   __emit_expression_range (0, i + sizeof i);
+   ~~^~
+   { dg-end-multiline-output "" } */
+}
+
+int test_alignof (int i)
+{
+  __emit_expression_range (0, alignof(int) + i); /* { dg-warning "range" } */
+/* { dg-begin-multiline-output "" }
+   __emit_expression_range (0, alignof(int) + i);
+   ~^~~
+   { dg-end-multiline-output "" } */
+
+  __emit_expression_range (0, i + alignof(int)); /* { dg-warning "range" } */
+/* { dg-begin-multiline-output "" }
+   __emit_expression_range (0, i + alignof(int));
+   ~~^~
+   { dg-end-multiline-output "" } */
+
+  __emit_expression_range (0, __alignof__(int) + i); /* { dg-warning "range" } 
*/
+/* { dg-begin-multiline-output "" }
+   __emit_expression_range (0, __alignof__(int) + i);
+   ~^~~
+   { dg-end-multiline-output "" } */
+
+  __emit_expression_range (0, i + __alignof__(int)); /* { dg-warning 

[PATCH] Fix location of typeid() (PR c++/80014)

[David Malcolm]

PR c++/80014 reports an issue where no caret is printed when issuing an
error for this bogus code:
  !typeid(void);

Root cause is that we're not setting up the location for the cp_expr for
the typeid expression, so that
  !typeid(void)
has start == caret at the '!', but finish == UNKNOWN_LOCATION, and so
the layout ctor within diagnostic-show-locus.c filters out the primary
range, and hence layout::should_print_annotation_line_p returns false.

This patch fixes things by setting up a location for the typeid
expression when parsing it.

Successfully bootstrapped on x86_64-pc-linux-gnu.

OK for trunk now, or should this wait until stage 1?

gcc/cp/ChangeLog:
PR c++/80014
* parser.c (cp_parser_postfix_expression): Construct a location
for typeid expressions.

gcc/testsuite/ChangeLog:
PR c++/80014
* g++.dg/plugin/diagnostic-test-expressions-1.C (std::type_info):
Add declaration.
(test_typeid): New test function.
---
 gcc/cp/parser.c| 17 --
 .../g++.dg/plugin/diagnostic-test-expressions-1.C  | 26 ++
 2 files changed, 41 insertions(+), 2 deletions(-)

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index c1b6496..aecf9a5 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -6513,7 +6513,10 @@ cp_parser_postfix_expression (cp_parser *parser, bool 
address_p, bool cast_p,
/* Look for the `)' token.  Otherwise, we can't be sure that
   we're not looking at an expression: consider `typeid (int
   (3))', for example.  */
-   cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN);
+   cp_token *close_paren = cp_parser_require (parser, CPP_CLOSE_PAREN,
+  RT_CLOSE_PAREN);
+   location_t end_loc = close_paren ?
+ close_paren->location : UNKNOWN_LOCATION;
/* If all went well, simply lookup the type-id.  */
if (cp_parser_parse_definitely (parser))
  postfix_expression = get_typeid (type, tf_warning_or_error);
@@ -6527,13 +6530,23 @@ cp_parser_postfix_expression (cp_parser *parser, bool 
address_p, bool cast_p,
/* Compute its typeid.  */
postfix_expression = build_typeid (expression, tf_warning_or_error);
/* Look for the `)' token.  */
-   cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN);
+   close_paren
+ = cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN);
+   end_loc = close_paren ? close_paren->location : UNKNOWN_LOCATION;
  }
/* Restore the saved message.  */
parser->type_definition_forbidden_message = saved_message;
/* `typeid' may not appear in an integral constant expression.  */
if (cp_parser_non_integral_constant_expression (parser, NIC_TYPEID))
  postfix_expression = error_mark_node;
+
+   /* Construct a location e.g. :
+typeid (expr)
+^
+  ranging from the start of the "typeid" token to the final closing
+  paren, with the caret at the start.  */
+   location_t typeid_loc = make_location (start_loc, start_loc, end_loc);
+   postfix_expression.set_location (typeid_loc);
   }
   break;
 
diff --git a/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C 
b/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C
index 4d3b07c..3554086 100644
--- a/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C
+++ b/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C
@@ -782,3 +782,29 @@ tests::test_method_calls ()
~~^~
{ dg-end-multiline-output "" } */
 }
+
+namespace std
+{
+  class type_info { public: int foo; };
+}
+
+void test_typeid (int i)
+{
+  __emit_expression_range (0, (i)); /* { dg-warning "range" } */
+/* { dg-begin-multiline-output "" }
+   __emit_expression_range (0, (i));
+   ^~
+   { dg-end-multiline-output "" } */
+
+  __emit_expression_range (0, (i * 2)); /* { dg-warning "range" } */
+/* { dg-begin-multiline-output "" }
+   __emit_expression_range (0, (i * 2));
+   ^~
+   { dg-end-multiline-output "" } */
+
+  __emit_expression_range (0, typeid(int).foo); /* { dg-warning "range" } */
+/* { dg-begin-multiline-output "" }
+   __emit_expression_range (0, typeid(int).foo);
+   ^~~
+   { dg-end-multiline-output "" } */
+}
-- 
1.8.5.3

[PATCH] omp-offload.c: translation fixes (PR translation/80001)

[David Malcolm]

Successfully bootstrapped on x86_64-pc-linux-gnu.

OK for trunk? (either now in stage 4, or for next stage1?)

gcc/ChangeLog:
PR translation/80001
* omp-offload.c (oacc_loop_fixed_partitions): Make diagnostics
more amenable to translation.
(oacc_loop_auto_partitions): Likewise.
---
 gcc/omp-offload.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/gcc/omp-offload.c b/gcc/omp-offload.c
index 520bb91..d73955c 100644
--- a/gcc/omp-offload.c
+++ b/gcc/omp-offload.c
@@ -1150,14 +1150,20 @@ oacc_loop_fixed_partitions (oacc_loop *loop, unsigned 
outer_mask)
  if (outer)
{
  error_at (loop->loc,
-   "%s uses same OpenACC parallelism as containing loop",
-   loop->routine ? "routine call" : "inner loop");
+   loop->routine
+   ? G_("routine call uses same OpenACC parallelism"
+" as containing loop")
+   : G_("inner loop uses same OpenACC parallelism"
+" as containing loop"));
  inform (outer->loc, "containing loop here");
}
  else
error_at (loop->loc,
- "%s uses OpenACC parallelism disallowed by containing "
- "routine", loop->routine ? "routine call" : "loop");
+ loop->routine
+ ? G_("routine call uses OpenACC parallelism disallowed"
+  " by containing routine")
+ : G_("loop uses OpenACC parallelism disallowed"
+  " by containing routine"));
 
  if (loop->routine)
inform (DECL_SOURCE_LOCATION (loop->routine),
@@ -1322,8 +1328,11 @@ oacc_loop_auto_partitions (oacc_loop *loop, unsigned 
outer_mask,
   loop->mask |= this_mask;
   if (!loop->mask && noisy)
warning_at (loop->loc, 0,
-   "insufficient partitioning available"
-   " to parallelize%s loop", tiling ? " tile" : "");
+   tiling
+   ? G_("insufficient partitioning available"
+" to parallelize tile loop")
+   : G_("insufficient partitioning available"
+" to parallelize loop"));
 }
 
   if (assign && dump_file)
-- 
1.8.5.3

[Bug target/79947] [6/7 Regression] ICE in rs6000_emit_swsqrt at gcc/config/rs6000/rs6000.c:37570

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79947

--- Comment #5 from Michael Meissner  ---
Author: meissner
Date: Wed Mar 15 00:25:10 2017
New Revision: 246150

URL: https://gcc.gnu.org/viewcvs?rev=246150=gcc=rev
Log:
[gcc]
2017-03-14  Michael Meissner  

PR target/79947
* config/rs6000/rs6000.h (TARGET_FRSQRTES): Add check for
-mpowerpc-gfxopt.

[gcc/testsuite]
2017-03-14  Michael Meissner  

PR target/79947
* gcc.target/powerpc/pr79947.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr79947.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/testsuite/ChangeLog

[Bug target/80035] [nvptx] non-returning function call causes ptxas sigsegv

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80035

--- Comment #5 from Tom de Vries  ---
(In reply to Alexander Monakov from comment #3)
> ptxas gets confused around loops lacking
> exit edges (and perhaps other "unusual" CFG structures). They can easily
> appear even in original source and do not require presence of noreturn
> functions:
> 
> extern __device__ void g();
> extern __device__ void h();
> __device__ void f(int v)
> {
>   if (v) goto L;
>   for (;;) {
> g();
> L:
> h();
>   }
> }
> 

This problem goes away for ptxas -ori in cuda 6.5 and later (haven't tried
earlier versions).

[Bug target/80035] [nvptx] non-returning function call causes ptxas sigsegv

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80035

--- Comment #4 from Tom de Vries  ---
(In reply to Tom de Vries from comment #2)
> Replacing trap with exit or ret (or adding it after trap), makes the sigsegv
> go away.

This problem goes away for ptxas -ori starting cuda 7.0.

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

[koenigni at student dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499

Nicolas Koenig  changed:

   What|Removed |Added

 CC||koenigni at student dot ethz.ch

--- Comment #5 from Nicolas Koenig  ---
Created attachment 40977
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40977=edit
Proposed patch to fix the ICE

After far too many hours in the depths of gdb, there appeared to be one
malicious statement in the code. This patch should fix it.

Regression tested for GNU Fortran (GCC) 7.0.1 20170314 (experimental) on
x86_64-pc-linux-gnu with no regressions.

[Bug driver/80044] New: Specifying both -static and -pie insanity

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80044

Bug ID: 80044
   Summary: Specifying both -static and -pie insanity
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

-static and -pie are incompatible, yet gcc neither warns nor errors on the
combination.  What's more, gcc's behaviour depends on whether gcc was built
with --enable-default-pie.

If gcc was built with --enable-default-pie then -static silently overrides an
explicit -pie, at least on x86 and I suspect most targets.  -static is passed
on to ld, gcc specifies the static startup files, and no -dynamic-linker is
passed to ld.  This is reasonable, but a warning that the explicit -pie was
overridden would be nicer.

If gcc was built with --disable-default-pie then -static does not fully
override -pie.  On x86, you get the static startup files, no -dynamic-linker,
and both -static and -pie are passed on to the linker.  ld.gold errors on that
combination.  ld.bfd tries to generate a PIE using the static startup files and
static (typically non-pic) libraries, and typically the wrong ld.so.  The wrong
ld.so leads to a somewhat cryptic "file not found" message on trying to run an
executable.  Non-pic startup and libraries result in a linker error on x86_64,
and text relocations on powerpc64le.  TEXTREL and ifunc as found in modern
glibc are fundamentally incompatible: When applying the text relocations, ld.so
makes the text segment temporarily writeable (and non-exec), but the text needs
to be exec to run ifunc resolvers.  A segfault before main is the result.

Re: [PATCH 1/5] Fix *_CST ICEs connected to MPX.

[Ilya Enkovich]

2017-03-13 16:33 GMT+03:00 Martin Liška :
> On 03/13/2017 02:07 PM, Richard Biener wrote:
>> No, that can't happen.  I said that for example for
>>
>> struct S { ... } s;
>> foo (s);
>>
>> pass_by_reference may be true but on gimple you see a struct s as
>> actual argument.  I'm not sure
>> what chkp_find_bounds does to 's' in this case.  Like if floats are
>> passed by reference you might
>> see a REAL_CST passed to chkp_find_bounds but in reality it will get a
>> pointer (with bounds
>> according to the argument slot that was used).
>
> Currently constants have invalid bounds assigned. Thus I guess it can't cause 
> a trouble
> when such constant is used as a pointer. Anyhow, the discrepancy should be 
> handled better.
>
> Last question related to the patch. May I at least install the part which 
> adds {COMPLEX,VECTOR}_CSTs
> handling as it can happen with -mabi=ms (where formal and actual args do 
> match)? Or using -mabi=ms + CHKP
> does not make sense at all?

Hi,

Originally casted function calls were not taken into account by
instrumentation pass and it
caused such sloppy handling of these casts later. It would be nice to
revise this code.

Meanwhile your fix should go to trunk. CHKP instrumentation pass is
supposed to be target
independent and therefore shouldn't rely on any ABI.

Thanks,
Ilya

>
> Martin

[Bug fortran/79447] [F08] gfortran rejects valid & accepts invalid internal subprogram in a submodule

[damian at sourceryinstitute dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79447

Damian Rouson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Damian Rouson  ---
Comment 7 indicates that a patch was applied to the trunk nearly a month ago so
I assumed this can be marked as Resolved/Fixed.

[Bug c/79936] [7 Regression] ICE with -Walloc-size-larger-than=32767

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79936

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Martin Sebor  ---
Fixed in r246144.

Re: [PATCH,RS6000] PR79963: Correct which condition code bit represents result of vec_any_eq built-in function

[Segher Boessenkool]

Hi Kelvin,

On Tue, Mar 14, 2017 at 03:06:13PM -0600, Kelvin Nilsen wrote:
> 2017-03-14  Kelvin Nilsen  
> 
>   PR target/79963
>   * config/rs6000/altivec.h (vec_all_ne): Under __cplusplus++ and

It is spelled __cplusplus__.

>   __POWER9_VECTOR__ #ifdef control, change template definition to
>   use Power9-specific built-in function.
>   (vec_any_eq): Likewise.
>   * config/rs6000/vector.md (vector_ae_v2di_p): Change the flag used
>   to control outcomes from this test.
>   (vector_ae_p): For VEC_F modes, likewise.

Could you please add a testcase?  Otherwise it looks good.

Thanks,


Segher

Re: Reload fix for an old aarch64 issue

[Jeff Law]

On 03/14/2017 05:22 PM, Bernd Schmidt wrote:

This triggered a kernel miscompilation with an old (4.8 I think) aarch64
toolchain.

Here's the reloads for the insn where things go wrong:

Reloads for insn # 210
Reload 0: reload_in (DI) = (reg/v/f:DI 80 [ pgdata ])
GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 0)
reload_in_reg: (reg/v/f:DI 80 [ pgdata ])
reload_reg_rtx: (reg:DI 5 x5)
Reload 1: reload_in (DI) = (plus:DI (reg/v/f:DI 80 [ pgdata ])
(const_int 7172
[0x1c04]))
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 0), inc by 2
reload_in_reg: (plus:DI (reg/v/f:DI 80 [ pgdata ])
(const_int 7172
[0x1c04]))
reload_reg_rtx: (reg:DI 5 x5)

Note how the input and input_address reloads use the same reload
register. This is intended as the two categories aren't supposed to
conflict. The problem is that reload 1 is a PLUS expression, and when
reloading these, gen_reload may have to resort to tricks, such as
loading one of the operands (the constant 7172) into the reload
register, and then adding the other operand to it. In effect that's an
earlyclobber of the reload register, and that is not represented in the
for_input/for_input_address classification.

Most likely we haven't tripped over this earlier because on other
machines the addition can be done in a single insn.

The following fixes this by using RELOAD_OTHER in this case. This is
pessimistic, but at that point I don't think we can really know what
gen_reload will have to do. Bootstrapped and tested on x86_64-linux on
the 4.7 branch - that's the best method of testing that I can think of
(but I think I'll also run some c6x tests with trunk). If no one
objects, I'll check this in soonish.


Bernd

rld-other.diff


* reload.c (find_reloads): When reloading a nonoffsettable address,
use RELOAD_OTHER for it and its address reloads.

I've already got state on this...  OK.

jeff

Re: Reload fix for an old aarch64 issue

[Andrew Pinski]

On Tue, Mar 14, 2017 at 4:22 PM, Bernd Schmidt  wrote:
> This triggered a kernel miscompilation with an old (4.8 I think) aarch64
> toolchain.

Yes RHEL's 4.8 has the issue.  So did Cavium/MontaVista's GCC 4.7 with
AARCH64 support backported to it.  We would work around the bug in the
kernel some of the time.  I never looked into it since I knew it was
in some part of reload and I am not a person to look into a reload
issue.

Thanks,
Andrew

>
> Here's the reloads for the insn where things go wrong:
>
> Reloads for insn # 210
> Reload 0: reload_in (DI) = (reg/v/f:DI 80 [ pgdata ])
> GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 0)
> reload_in_reg: (reg/v/f:DI 80 [ pgdata ])
> reload_reg_rtx: (reg:DI 5 x5)
> Reload 1: reload_in (DI) = (plus:DI (reg/v/f:DI 80 [ pgdata ])
> (const_int 7172
> [0x1c04]))
> GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 0), inc by 2
> reload_in_reg: (plus:DI (reg/v/f:DI 80 [ pgdata ])
> (const_int 7172
> [0x1c04]))
> reload_reg_rtx: (reg:DI 5 x5)
>
> Note how the input and input_address reloads use the same reload register.
> This is intended as the two categories aren't supposed to conflict. The
> problem is that reload 1 is a PLUS expression, and when reloading these,
> gen_reload may have to resort to tricks, such as loading one of the operands
> (the constant 7172) into the reload register, and then adding the other
> operand to it. In effect that's an earlyclobber of the reload register, and
> that is not represented in the for_input/for_input_address classification.
>
> Most likely we haven't tripped over this earlier because on other machines
> the addition can be done in a single insn.
>
> The following fixes this by using RELOAD_OTHER in this case. This is
> pessimistic, but at that point I don't think we can really know what
> gen_reload will have to do. Bootstrapped and tested on x86_64-linux on the
> 4.7 branch - that's the best method of testing that I can think of (but I
> think I'll also run some c6x tests with trunk). If no one objects, I'll
> check this in soonish.
>
>
> Bernd

Reload fix for an old aarch64 issue

[Bernd Schmidt]

This triggered a kernel miscompilation with an old (4.8 I think) aarch64 
toolchain.


Here's the reloads for the insn where things go wrong:

Reloads for insn # 210
Reload 0: reload_in (DI) = (reg/v/f:DI 80 [ pgdata ])
GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 0)
reload_in_reg: (reg/v/f:DI 80 [ pgdata ])
reload_reg_rtx: (reg:DI 5 x5)
Reload 1: reload_in (DI) = (plus:DI (reg/v/f:DI 80 [ pgdata ])
(const_int 7172 
[0x1c04]))

GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 0), inc by 2
reload_in_reg: (plus:DI (reg/v/f:DI 80 [ pgdata ])
(const_int 7172 
[0x1c04]))

reload_reg_rtx: (reg:DI 5 x5)

Note how the input and input_address reloads use the same reload 
register. This is intended as the two categories aren't supposed to 
conflict. The problem is that reload 1 is a PLUS expression, and when 
reloading these, gen_reload may have to resort to tricks, such as 
loading one of the operands (the constant 7172) into the reload 
register, and then adding the other operand to it. In effect that's an 
earlyclobber of the reload register, and that is not represented in the 
for_input/for_input_address classification.


Most likely we haven't tripped over this earlier because on other 
machines the addition can be done in a single insn.


The following fixes this by using RELOAD_OTHER in this case. This is 
pessimistic, but at that point I don't think we can really know what 
gen_reload will have to do. Bootstrapped and tested on x86_64-linux on 
the 4.7 branch - that's the best method of testing that I can think of 
(but I think I'll also run some c6x tests with trunk). If no one 
objects, I'll check this in soonish.



Bernd
	* reload.c (find_reloads): When reloading a nonoffsettable address,
	use RELOAD_OTHER for it and its address reloads.

Index: gcc/reload.c
===
--- gcc/reload.c	(revision 211480)
+++ gcc/reload.c	(working copy)
@@ -3989,14 +3989,14 @@ find_reloads (rtx insn, int replace, int
 			  (recog_data.operand[i], 0), (rtx*) 0,
 			 base_reg_class (VOIDmode, as, MEM, SCRATCH),
 			 address_mode,
-			 VOIDmode, 0, 0, i, RELOAD_FOR_INPUT);
+			 VOIDmode, 0, 0, i, RELOAD_OTHER);
 	rld[operand_reloadnum[i]].inc
 	  = GET_MODE_SIZE (GET_MODE (recog_data.operand[i]));
 
 	/* If this operand is an output, we will have made any
 	   reloads for its address as RELOAD_FOR_OUTPUT_ADDRESS, but
 	   now we are treating part of the operand as an input, so
-	   we must change these to RELOAD_FOR_INPUT_ADDRESS.  */
+	   we must change these to RELOAD_FOR_OTHER_ADDRESS.  */
 
 	if (modified[i] == RELOAD_WRITE)
 	  {
@@ -4005,10 +4005,10 @@ find_reloads (rtx insn, int replace, int
 		if (rld[j].opnum == i)
 		  {
 			if (rld[j].when_needed == RELOAD_FOR_OUTPUT_ADDRESS)
-			  rld[j].when_needed = RELOAD_FOR_INPUT_ADDRESS;
+			  rld[j].when_needed = RELOAD_FOR_OTHER_ADDRESS;
 			else if (rld[j].when_needed
  == RELOAD_FOR_OUTADDR_ADDRESS)
-			  rld[j].when_needed = RELOAD_FOR_INPADDR_ADDRESS;
+			  rld[j].when_needed = RELOAD_FOR_OTHER_ADDRESS;
 		  }
 		  }
 	  }

[Bug middle-end/79753] [7 Regression][CHKP] ICE in ix86_expand_builtin, at config/i386/i386.c:36869

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79753

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P1  |P2
 CC||law at redhat dot com

--- Comment #6 from Jeffrey A. Law  ---
Similarly to the other CHKP issue -- not a P1, downgrading to P2.

[Bug middle-end/79988] [7 Regression][CHKP] ICE in tree check: accessed operand 5 of call_expr with 4 operands in ix86_expand_builtin, at config/i386/i386.c:36851

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79988

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P1  |P2
 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
Jakub and I kicked these CHKP bugs around prior to his PTO.  Neither of us
think they are P1s, but they certainly qualify as P2.  So changing accordingly.

[Bug target/71399] [5/6/7 Regression] 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #21 from Jeffrey A. Law  ---
Per c#19.

Re: [PATCH] PR libstdc++/79789 fix non-reserved names in headers

[Jonathan Wakely]

On 10/03/17 15:20 +, Jonathan Wakely wrote:

On 09/03/17 19:46 +, Jonathan Wakely wrote:

On 03/03/17 10:47 -0500, David Edelsohn wrote:

This patch caused a new regression on AIX.


I'm unable to bootstrap on either gcc111 or gcc119 so I can't test
the fix.


export CONFIG_SHELL=/usr/bin/bash
PATH=/opt/freeware/bin:$PATH
$gccsrcdir/configure ... --disable-werror --with-included-gettext 
--with-gmp=/opt/cfarm --with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch

Here's what I'm committing to trunk.

Tested powerpc64le-linux and powerpc-ibm-aix7.2.0.0


Also committed to gcc-5-branch and gcc-6-branch.



commit 5e390a2874a9629c13eaddb76f82a66f0634a864
Author: Jonathan Wakely 
Date:   Fri Mar 10 13:14:33 2017 +

   Fix libstdc++ reserved names test to pass on AIX
   
   	* testsuite/17_intro/names.cc: Undefine macros that clash with

identifiers in AIX system headers.

diff --git a/libstdc++-v3/testsuite/17_intro/names.cc 
b/libstdc++-v3/testsuite/17_intro/names.cc
index a7d9a6b..c525861 100644
--- a/libstdc++-v3/testsuite/17_intro/names.cc
+++ b/libstdc++-v3/testsuite/17_intro/names.cc
@@ -98,4 +98,13 @@
#define x (
#define y (
#define z (
+
+#ifdef _AIX
+// See https://gcc.gnu.org/ml/libstdc++/2017-03/msg00015.html
+#undef f
+#undef r
+#undef x
+#undef y
+#endif
+
#include 

[Bug sanitizer/79096] [7 Regression] address sanitizer and jni does not work

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79096

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-14
 CC||law at redhat dot com
   Target Milestone|7.0 |8.0
 Ever confirmed|0   |1

--- Comment #5 from Jeffrey A. Law  ---
Upstream sanitizer runtime issue.  Deferring out of gcc-7.

[Bug c++/79393] [7 Regression] cc1plus rejects valid code with noexcept

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79393

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Target Milestone|7.0 |8.0

--- Comment #4 from Jeffrey A. Law  ---
With workaround in place and pending discussion of the DR, deferring further
work on this BZ to gcc-8.

Re: Combiner fix for PR79910

[Bernd Schmidt]

On 03/15/2017 12:03 AM, Jeff Law wrote:

On 03/10/2017 04:24 PM, Bernd Schmidt wrote:


PR rtl-optimization/79910
* combine.c (record_used_regs): New static function.
(try_combine): Handle situations where there is an additional
instruction between I2 and I3 which needs to have a LOG_LINK
updated.

PR rtl-optimization/79910
* gcc.dg/torture/pr79910.c: New test.

What a nasty little problem.

I don't like that we have to build these bitmaps due to the compile-time
cost.  Would it make sense to only build them when i0/i1 exist?


I suppose at the moment we don't do 2->2 combinations, so we could 
conditionalize this on having an i1.



We don't do 4->3 combinations, just 4->2 and 3->2, so it's only the
i2pattern where we might need to conjure up a LOG_LINK, right?


We don't do 4->3 combinations, right?  So we only have to care about
when there's going to be an newi2pat, right (3->2 or 4->2).



We don't ever create a newi1pat (for a 4->3 combination), right?  So we
only have to worry about testing when there's a newi2pat, right?


Yes to all, there isn't a newi1pat, only 4->2 and 3->2 can be an issue.


+if (prev_nonnote_insn (i3) != i2)
+  for (unsigned r = 0; r < FIRST_PSEUDO_REGISTER; r++)
+if (bitmap_bit_p (new_regs_in_i2, r))

if (prev_nonnote_insn (i3) != i2
&& bitmap_first_set_bit (new_regs_in_i2) < FIRST_PSEUDO_REGISTER)


Ah. I had wondered about the loop but only thought in the direction of 
intersecting this bitmap with one of all hard regs (and I think there 
isn't such a bitmap, so I kept the loop). I'll retest with your 
suggestion and with the bitmap creation conditional on i1 being nonnull.



Bernd

Re: Combiner fix for PR79910

[Jeff Law]

On 03/10/2017 04:24 PM, Bernd Schmidt wrote:

In this PR, we have a few insns involved in two instruction combinations:

insn 16: set r100
insn 27: some calculation
insn 28: some calculation
insn 32: using r100
insn 33: using r100
insn 35: some calculation

Then we combine insns 27, 28 and 33, producing two output insns, As a
result, insn 28 (i2) now obtains a use of r100. But insn 32, which is
not involved in this combination, has the LOG_LINKS entry for that
register, and we don't know that we need to update it. As a result, the
second combination, involving regs 16, 32 and 35 (based on the remaining
LOG_LINK for r100), produces incorrect code, as we don't realize there's
a use of r100 before insn 32.

The following fixes it. Bootstrapped and tested on x86_64-linux, ok (on
all branches)?


Bernd


79910.diff


PR rtl-optimization/79910
* combine.c (record_used_regs): New static function.
(try_combine): Handle situations where there is an additional
instruction between I2 and I3 which needs to have a LOG_LINK
updated.

PR rtl-optimization/79910
* gcc.dg/torture/pr79910.c: New test.

What a nasty little problem.

I don't like that we have to build these bitmaps due to the compile-time 
cost.  Would it make sense to only build them when i0/i1 exist?


We don't do 4->3 combinations, just 4->2 and 3->2, so it's only the 
i2pattern where we might need to conjure up a LOG_LINK, right?



We don't do 4->3 combinations, right?  So we only have to care about 
when there's going to be an newi2pat, right (3->2 or 4->2).
We don't ever create a newi1pat (for a 4->3 combination), right?  So we 
only have to worry about testing when there's a newi2pat, right?



Do you need to handle 4->3, in which case the new bits could be on newi1pat?


Index: gcc/combine.c
===
--- gcc/combine.c   (revision 245685)
+++ gcc/combine.c   (working copy)
@@ -2559,6 +2560,57 @@ can_split_parallel_of_n_reg_sets (rtx_in
   return true;
 }




@@ -4051,6 +4124,33 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
   return 0;
 }

+  auto_bitmap new_regs_in_i2;
+  if (newi2pat)
+{
+  /* We need to discover situations where we introduce a use of a
+register into I2, where none of the existing LOG_LINKS contain
+a reference to it.  This can happen if previously I3 referenced
+the reg, and there is an additional use between I2 and I3.  We
+must remove the LOG_LINKS entry from that additional use and
+distribute it along with our own ones.  */
+   note_uses (, record_used_regs, (bitmap)new_regs_in_i2);
+   bitmap_and_compl_into (new_regs_in_i2, i2_regset);
+   bitmap_and_compl_into (new_regs_in_i2, links_regset);
+
+   /* Here, we first look for situations where a hard register use
+  moved, and just give up.  This should happen approximately
+  never, and it's not worth it to deal with possibilities like
+  multi-word registers.  Later, when fixing up LOG_LINKS, we
+  deal with the case where a pseudo use moved.  */
+   if (prev_nonnote_insn (i3) != i2)
+ for (unsigned r = 0; r < FIRST_PSEUDO_REGISTER; r++)
+   if (bitmap_bit_p (new_regs_in_i2, r))

if (prev_nonnote_insn (i3) != i2
&& bitmap_first_set_bit (new_regs_in_i2) < FIRST_PSEUDO_REGISTER)

?



Overall it seems reasonable.  If possible, let's avoid the calls to 
create the bitmaps in case where we know we'll never be creating a new 
use in i2.


I'm not wed to using bitmap_first_set_bit.  It's clearer and may be 
faster since you're not doing a ton of calls into bitmap_bit_p.  The 
bitmap_first_set_bit implementation under the hood finds the word within 
the first bitmap element that is nonzero, then uses ctzl on that to get 
its bit.


Jeff

patch, libfortran] [patch, fortran] Fix PR 79956, part two, attempt 3

[Thomas Koenig]

Hello world,

well, here is the third attempt at fixing the second part of the PR.
Glancing over the source, I think there are quite a few places where
we currently issue a runtime error which we could replace by an
assert, but that's something for 8.0.

Regression-tested on x86_64-pc-linux-gnu.

OK for trunk?

Thomas

(I won't be able to commit for a few days, so if somebody
wants to commit for me, feel free).

2017-03-12  Thomas Koenig  

PR libfortran/79956
* libgfortran.h (GFC_ASSERT):  New macro.
* m4/reshape.m4 (reshape_'rtype_ccode`):  Use GFC_ASSERT
to specify that sdim > 0 and rdim > 0.
* intrinsic/reshape_generic.c (reshape_internal):  Likweise.
* generated/reshape_c10.c: Regenerated.
* generated/reshape_c16.c: Regenerated.
* generated/reshape_c4.c: Regenerated.
* generated/reshape_c8.c: Regenerated.
* generated/reshape_i16.c: Regenerated.
* generated/reshape_i4.c: Regenerated.
* generated/reshape_i8.c: Regenerated.
* generated/reshape_r10.c: Regenerated.
* generated/reshape_r16.c: Regenerated.
* generated/reshape_r4.c: Regenerated.
* generated/reshape_r8.c: Regenerated.
Index: generated/reshape_c10.c
===
--- generated/reshape_c10.c	(Revision 245760)
+++ generated/reshape_c10.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_c10 (gfc_array_c10 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_c16.c
===
--- generated/reshape_c16.c	(Revision 245760)
+++ generated/reshape_c16.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_c16 (gfc_array_c16 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_c4.c
===
--- generated/reshape_c4.c	(Revision 245760)
+++ generated/reshape_c4.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_c4 (gfc_array_c4 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_c8.c
===
--- generated/reshape_c8.c	(Revision 245760)
+++ generated/reshape_c8.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_c8 (gfc_array_c8 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_i16.c
===
--- generated/reshape_i16.c	(Revision 245760)
+++ generated/reshape_i16.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_16 (gfc_array_i16 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_i4.c
===
--- generated/reshape_i4.c	(Revision 245760)
+++ generated/reshape_i4.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_4 (gfc_array_i4 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_i8.c
===
--- generated/reshape_i8.c	(Revision 245760)
+++ generated/reshape_i8.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_8 (gfc_array_i8 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_r10.c
===
--- generated/reshape_r10.c	(Revision 245760)
+++ generated/reshape_r10.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_r10 (gfc_array_r10 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler 

Re: [patch, fortran] PR39239 Warning about EQUIVALENCE and VOLATILE

[Nicolas Koenig]

On 03/14/2017 10:42 PM, Jerry DeLisle wrote:

On 03/14/2017 01:17 PM, Nicolas Koenig wrote:

Hello everyone,

a simple patch to throw a warning if not all and not none of the equivalence
objects are volatile. (And the according modification of
gfortran.dg/volatile11.f90)

Nicolas

Regression tested for:

GNU Fortran (GCC) 7.0.1 20170311 (experimental)

Changelog:

2017-03-13  Nicolas Koenig  

 PR fortran/39239
 * resolve.c (resolve_equivalence): Warn if not either none or
all equivalence objects are volatile
 * gfortran.dg/volatile11.f90: Changed test to test for the new
warning



Hi Nicolas,

Thanks for starting in on this.

Since this results in a warning, maybe change the wording from 'shall' to 
should.

I did not dig into the Fortran Standards so I assume it need not be an error.

Also when you submit a patch, please also let us know what platform you
regression tested on, such as x86-64-linux, or Windows, or similar. (You can get
the whole string from subdirectory names in build directory. On mine its
x86_64-pc-linux-gnu) Sometimes we accidentally break things on different
platforms. so this way we can see it tested ok over here and seems to fail over
there.

Your patch has changed some of the scan dumps and I am wondering if you have
deleted something we use to check for?

Jerry


Hello Jerry,
I have to thank for the kind feedback.
Attached is a reworked version of the patch with the changes applied. It 
also should  have the same scan dump now, one of the test cases was 
edited stupidly.
The regression tests for both the old as well as the new test have been 
performed on an x86-64-linux (x86_64-pc-linux-gnu).

Nicolas

Index: fortran/resolve.c
===
--- fortran/resolve.c	(revision 246143)
+++ fortran/resolve.c	(working copy)
@@ -15560,7 +15560,7 @@ resolve_equivalence (gfc_equiv *eq)
   locus *last_where = NULL;
   seq_type eq_type, last_eq_type;
   gfc_typespec *last_ts;
-  int object, cnt_protected;
+  int object, cnt_protected, cnt_volatile;
   const char *msg;
 
   last_ts = >expr->symtree->n.sym->ts;
@@ -15569,6 +15569,8 @@ resolve_equivalence (gfc_equiv *eq)
 
   cnt_protected = 0;
 
+  cnt_volatile = 0;
+
   for (object = 1; eq; eq = eq->eq, object++)
 {
   e = eq->expr;
@@ -15641,6 +15643,17 @@ resolve_equivalence (gfc_equiv *eq)
 
   sym = e->symtree->n.sym;
 
+  if(sym->attr.volatile_)
+cnt_volatile++;
+  if(cnt_volatile > 0 && cnt_volatile != object)
+	{
+	  gfc_warning (0, "Either all or none of the objects in "
+	  	   "the EQUIVALENCE set at %L should have the "
+		   "VOLATILE attribute",
+		   >where);
+	  break;
+	}
+
   if (sym->attr.is_protected)
 	cnt_protected++;
   if (cnt_protected > 0 && cnt_protected != object)
Index: testsuite/gfortran.dg/volatile11.f90
===
--- testsuite/gfortran.dg/volatile11.f90	(revision 246140)
+++ testsuite/gfortran.dg/volatile11.f90	(working copy)
@@ -3,6 +3,7 @@
 ! Tests that volatile can be applied to members of common blocks or
 ! equivalence groups (PR fortran/35037)
 !
+
 subroutine wait1
   logical event
   volatile event
@@ -16,7 +17,7 @@ end subroutine
 subroutine wait2
   logical event, foo
   volatile event
-  equivalence (event, foo)
+  equivalence (event, foo) ! { dg-warning "in the EQUIVALENCE set" }
   event = .false.
   do
 if (event) print *, 'NotOptimizedAway2'
@@ -27,7 +28,7 @@ subroutine wait3
   logical event
   integer foo
   volatile foo
-  equivalence (event, foo)
+  equivalence (event, foo) ! { dg-warning "in the EQUIVALENCE set" }
   event = .false.
   do
 if (event) print *, 'IsOptimizedAway'

[Bug c/80036] Source line not printed for diagnostic if expanded from a macro

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80036

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
 Depends on||43486

--- Comment #2 from Manuel López-Ibáñez  ---
Variable-uses don't have locations in GCC (yet, hopefully some day when the FEs
get replaced by Clang), so the warning points to "print_it", which is inside
the macro. Then, warn_uninit does:

  location = linemap_resolve_location (line_table, location,
   LRK_SPELLING_LOCATION, NULL);

which means that the location points at the spelling location, that is, inside
the macro.

This has nothing to do with headers. A simpler testcase is: 

void bar(int);
#define foo(x) bar(x)
void test(void)
{
  int uninit;
  foo(uninit);
}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
[Bug 43486] Preserve variable-use locations

Re: [PATCH doc] use "cannot" consistently

[Joseph Myers]

On Tue, 14 Mar 2017, Martin Sebor wrote:

> PS I wasted quite a bit of time updating tm.texi.  I kept getting
> the error below and didn't realize (forgot) that it was asking me
> to copy $objdir/gcc/tm.texi to $srcdir/gcc/doc/tm.texi.  Can
> someone explain why this file requires these special steps when
> the rest of the .texi files can be updated directly?

Both a GPL copy and a GFDL copy of the text shared between tm.texi and 
target.def need to be checked in (hence not just having tm.texi.in but not 
tm.texi checked in).  If existing text that was only in one place (so only 
under one of GPL and GFDL) is being moved so that there are copies under 
both licenses, then this involves docstring relicensing review (otherwise, 
just copying the generated tm.texi without any extra review for that 
copying is appropriate).

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

Re: [PATCH doc] use "cannot" consistently

[Martin Sebor]

On 03/14/2017 01:41 PM, Richard Sandiford wrote:

Martin Sebor  writes:

@@ -373,7 +373,7 @@ example, this code would produce an error:

 @smallexample
 #if 0
-You can't expect this to work.
+You cannot expect this to work.
 #endif
 @end smallexample



Sure the maintainers would have caught this, but: the "'" is needed here.
The point is that code doesn't tokenise properly.


Great catch, thanks!  I'll be sure to fix that if the patch is
approved.

Martin

gcc-5-20170314 is now available

[gccadmin]

Snapshot gcc-5-20170314 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170314/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch 
revision 246145

You'll find:

 gcc-5-20170314.tar.bz2   Complete GCC

  SHA256=f5939b41b7694ca8fcf8557d9265ceda014db5f76c9f91601e9f8ec9fa8330fb
  SHA1=3210d8798c8e8a607a850767ecda3fc886c5043a

Diffs from 5-20170307 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[gomp4] cleanup trans-stmt.h

[Cesar Philippidis]

I noticed that gcc/fortran/trans-stmt.h made a reference to a
non-existent trans-openacc.c. Those functions have been placed in
trans-openmp.c. This patch has been applied to gomp-4_0-branch to
correct that error.

Cesar
2017-03-14  Cesar Philippidis  

	gcc/fortran/
	* trans-stmt.h: Remove stale reference to trans-openacc.c.

diff --git a/gcc/fortran/trans-stmt.h b/gcc/fortran/trans-stmt.h
index f9c8e74..6ca0c1b 100644
--- a/gcc/fortran/trans-stmt.h
+++ b/gcc/fortran/trans-stmt.h
@@ -65,8 +65,6 @@ tree gfc_trans_deallocate_array (tree);
 /* trans-openmp.c */
 tree gfc_trans_omp_directive (gfc_code *);
 void gfc_trans_omp_declare_simd (gfc_namespace *);
-
-/* trans-openacc.c */
 tree gfc_trans_oacc_directive (gfc_code *);
 tree gfc_trans_oacc_declare (gfc_namespace *);
 

[Bug rtl-optimization/80025] [5/6/7 Regression] ICE w/ -O2 (-O3, -Ofast) -g -ftracer (infinite recursion in rtx_equal_for_cselib_1)

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80025

Bernd Schmidt  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||bernds at gcc dot gnu.org

--- Comment #7 from Bernd Schmidt  ---
CC'ing Alex. I've poked around this a bit and it seems to be in code he's
written and which I don't fully understand.

Re: [PATCH] MPX: fix PR middle-end/79753

[Ilya Enkovich]

2017-03-10 16:15 GMT+03:00 Martin Liška :
> Hello.
>
> Currently, __builtin_ia32_bndret is used for all functions that have non-void
> return type. I think the right fix is to return bounds just for a bounded 
> type.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Martin

Hi,

The fix makes sense and allows you to pass the test but it seems like we
still have the issue in inlining which can result in bndret call with wrong arg.
Do you avoid all such cases by this fix? Can we still have similar problem
if cast function with integer return type to a function with pointer return type
and the inline the call (not sure if we can inline such calls)?

I think this fix still should go to trunk anyway.

Thanks,
Ilya

[Bug driver/79659] Provide valid values for integer options (e.g. -Wformat) with --help= option

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79659

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-14
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Martin Liška from comment #1)
> because we generate assert for optimization options:
> 
>   gcc_assert (IN_RANGE (opts->x_flag_lifetime_dse, -128, 127));
> 
> I'm wondering whether cutting values out of possible range to maximum (or
> minimum) would be desired?

Even that range is too large for an option that only takes 0,1,2

It should simply emit an error that the value passed is not within the allowed
values. Allowed values should be encoded in the .opt files.

Re: [PATCH], PR target/79947, Fix compiler segmentation fault with -Ofast -mno-powerpc-gfxopt

[Segher Boessenkool]

Hi Mike,

On Tue, Mar 14, 2017 at 05:01:53PM -0400, Michael Meissner wrote:
> In PR target/79947, the code for using the float reciprocal square root
> estimate instruction did not check if the -mpowerpc-gfxopt option was enabled.
> The code needs this option to generate a conditional floating point move.
> 
> I have checked this patch on the trunk, and it fixes the problem and it does
> not cause any regressions.  Is it ok to apply to the trunk?  Assuming there 
> are
> no additional problems, can I apply the patch to the GCC 5 and 6 branches as
> well?

All CPUs that have the reciprocal estimate insns also have the gfxopt
insns (and this will not change), so this is okay (also for the branches).
Thanks!


Segher

[Bug c/67146] Wchkp is not documented in invoke.texi

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67146

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Manuel López-Ibáñez  ---
Dup and fixed.

*** This bug has been marked as a duplicate of bug 79831 ***

[Bug middle-end/79831] [DOC][CHKP] Missing -Wchkp

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79831

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
*** Bug 67146 has been marked as a duplicate of this bug. ***

[Bug c++/80043] [6/7 Regression] ICE with pointer-to-member-function and -fpermissive

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80043

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-14
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r233183 (similar to PR72775, but it's a different issue
because it's resolved on trunk).

[Bug middle-end/80020] [7 Regression] gcc confused about aligned_alloc argument order

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80020

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law  ---
Fixed by Martin's patch on the trunk.

[Bug middle-end/80020] [7 Regression] gcc confused about aligned_alloc argument order

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80020

--- Comment #2 from Jeffrey A. Law  ---
Author: law
Date: Tue Mar 14 22:16:27 2017
New Revision: 246145

URL: https://gcc.gnu.org/viewcvs?rev=246145=gcc=rev
Log:
PR middle-end/80020
* builtin-attrs.def (ATTR_ALLOC_SIZE_2_NOTHROW_LIST): New macro.
* builtins.def (aligned_alloc): Use it.

PR middle-end/80020
* gcc.dg/attr-alloc_size-6.c: Correct aligned_alloc argument order.
* gcc.dg/attr-alloc_size-7.c: Same.
* gcc.dg/attr-alloc_size-9.c: Same.
* gcc.dg/builtin-alloc-size.c: Same.
* gcc.dg/pr80020.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr80020.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtin-attrs.def
trunk/gcc/builtins.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-6.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-7.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-9.c
trunk/gcc/testsuite/gcc.dg/builtin-alloc-size.c

Re: [PATCH] add calls.c to GTFILES in Makefile.in

[Jeff Law]

On 03/07/2017 06:03 PM, Martin Sebor wrote:

In bug 79936 - ICE with -Walloc-size-larger-than=32767 the reporter
encountered an ICE on x86_64-apple-darwin10.8.0 caused by GCC source
file that implements the warning accessing a global tree without
having included the file in GTFILES make variable.  (Thanks again
to David Malcolm who helped me root cause this bug.)

The attached patch fixes this by adding calls.c to the variable and
by including the requisite generated header, gt-calls.h, at the end
of the source.

Martin

gcc-79936.diff


PR c/79936 - [7 Regression] ICE with -Walloc-size-larger-than=32767

gcc/ChangeLog:

PR c/79936
* Makefile.in (GTFILES): Add calls.c.
* calls.c (must_pass_in_stack_var_size_or_pad): Include "gt-calls.h".

I fixed the ChangeLog entry for calls.c and installed this.

Thanks,
jeff

Re: [PATCH] correct aligned_alloc argument order (PR 80020)

[Jeff Law]

On 03/13/2017 02:44 AM, Richard Biener wrote:

On Mon, Mar 13, 2017 at 2:13 AM, Martin Sebor  wrote:

r243470 decorates standard allocation functions like alloca
and malloc with attribute alloc_size.  However, in applying
the attribute to aligned_alloc I had overlooked that the size
argument is the second one and not the first.  That oversight
has led to __builtin_object_size() reporting the wrong size
for aligned_alloc-allocated objects and, consequently, to
checking functions like __memset_chk calling abort for buffer
bogus overflows.

The attached patch corrects this mistake by decorating the
function with the correct alloc_size attribute.


Ok.

I installed the patch on the trunk
jeff

[Bug c/79936] [7 Regression] ICE with -Walloc-size-larger-than=32767

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79936

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #9 from Jeffrey A. Law  ---
Fixed by Martin's patch on the trunk.

[Bug c/79936] [7 Regression] ICE with -Walloc-size-larger-than=32767

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79936

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Tue Mar 14 22:09:40 2017
New Revision: 246144

URL: https://gcc.gnu.org/viewcvs?rev=246144=gcc=rev
Log:
PR c/79936
* Makefile.in (GTFILES): Add calls.c.
* calls.c: Include "gt-calls.h".

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/calls.c

Re: [patch, fortran] PR39239 Warning about EQUIVALENCE and VOLATILE

[Jerry DeLisle]

On 03/14/2017 01:17 PM, Nicolas Koenig wrote:
> Hello everyone,
> 
> a simple patch to throw a warning if not all and not none of the equivalence
> objects are volatile. (And the according modification of
> gfortran.dg/volatile11.f90)
> 
> Nicolas
> 
> Regression tested for:
> 
> GNU Fortran (GCC) 7.0.1 20170311 (experimental)
> 
> Changelog:
> 
> 2017-03-13  Nicolas Koenig  
> 
> PR fortran/39239
> * resolve.c (resolve_equivalence): Warn if not either none or
> all equivalence objects are volatile
> * gfortran.dg/volatile11.f90: Changed test to test for the new
> warning
> 
> 

Hi Nicolas,

Thanks for starting in on this.

Since this results in a warning, maybe change the wording from 'shall' to 
should.

I did not dig into the Fortran Standards so I assume it need not be an error.

Also when you submit a patch, please also let us know what platform you
regression tested on, such as x86-64-linux, or Windows, or similar. (You can get
the whole string from subdirectory names in build directory. On mine its
x86_64-pc-linux-gnu) Sometimes we accidentally break things on different
platforms. so this way we can see it tested ok over here and seems to fail over
there.

Your patch has changed some of the scan dumps and I am wondering if you have
deleted something we use to check for?

Jerry

Re: [PATCH] Fix PR79908

[Bill Schmidt]

> On Mar 14, 2017, at 11:07 AM, Bill Schmidt  
> wrote:
>> 
>> Your suggestion failed bootstrap in libiberty on vprintf-support.c.  
>> Compilation failed with:
>> 
>> /home/wschmidt/gcc/build/gcc-mainline-test2-debug/gcc/xgcc 
>> -B/home/wschmidt/gcc/build/gcc-mainline-test2-debug/gcc/ 
>> -B/home/wschmidt/gcc/install/gcc-mainline-test2-debug/powerpc64le-unknown-linux-gnu/bin/
>>  
>> -B/home/wschmidt/gcc/install/gcc-mainline-test2-debug/powerpc64le-unknown-linux-gnu/bin/
>>  
>> -B/home/wschmidt/gcc/install/gcc-mainline-test2-debug/powerpc64le-unknown-linux-gnu/lib/
>>  -isystem 
>> /home/wschmidt/gcc/install/gcc-mainline-test2-debug/powerpc64le-unknown-linux-gnu/include
>>  -isystem 
>> /home/wschmidt/gcc/install/gcc-mainline-test2-debug/powerpc64le-unknown-linux-gnu/sys-include
>> -c -DHAVE_CONFIG_H -g -O2 -gtoggle  -I. 
>> -I/home/wschmidt/gcc/gcc-mainline-test2/libiberty/../include  -W -Wall 
>> -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic  
>> -D_GNU_SOURCE -fPIC 
>> /home/wschmidt/gcc/gcc-mainline-test2/libiberty/vprintf-support.c -o 
>> pic/vprintf-support.o
>> 
>> The initial expression being gimplified is ADDR_EXPR (VAR_DECL (ap)).  
>> Gimplification
>> turns this into MEM_REF (VAR_DECL (D.4274), 0), and the is_gimple_val test 
>> fails on that.
> 
> Reduced test case:
> 
> typedef __builtin_va_list __gnuc_va_list;
> typedef __gnuc_va_list va_list;
> 
> void
> foo (va_list args)
> {
>  va_list ap;
>  __builtin_va_copy (ap, args);
>  (void)__builtin_va_arg (ap, int);
>  __builtin_va_end(ap);
> }
> 

Perhaps something like this?  It appears to be doing better on bootstrap, and 
avoids
failure on both the original problem and the new test case above:

Index: gcc/tree-stdarg.c
===
--- gcc/tree-stdarg.c   (revision 246109)   
+++ gcc/tree-stdarg.c   (working copy)  
@@ -1058,7 +1058,13 @@ expand_ifn_va_arg_1 (function *fun)
gimplify_assign (lhs, expr, );  
  } 
else
- gimplify_expr (, , , is_gimple_lvalue, fb_lvalue);  
+ { 
+   enum gimplify_status status;
+   status = gimplify_expr (, , , is_gimple_lvalue,   
+   fb_lvalue | fb_mayfail);
+   if (status == GS_ERROR) 
+ gimplify_expr (, , , is_gimple_val, fb_rvalue); 
+ } 

input_location = saved_location;
pop_gimplify_context (NULL);

Bill

[PATCH,RS6000] PR79963: Correct which condition code bit represents result of vec_any_eq built-in function

[Kelvin Nilsen]

This patch corrects several errors in a patch that was submitted on
2017-03-01.  A copy-and-paste error in the previous patch resulted in
accidental use of the lt flag instead of the eq flag to represent the
outcome of the vec_any_eq built-in function.  Also, in reviewing the
code of the previous patch, it was discovered that changes to the C++
templates representing the vec_all_ne and vec_any_eq built-in functions
were incomplete.

This patch has bootstrapped and been tested on
powerpc64le-unknown-linux with no regressions.

Is this ok for trunk?

gcc/ChangeLog:

2017-03-14  Kelvin Nilsen  

PR target/79963
* config/rs6000/altivec.h (vec_all_ne): Under __cplusplus++ and
__POWER9_VECTOR__ #ifdef control, change template definition to
use Power9-specific built-in function.
(vec_any_eq): Likewise.
* config/rs6000/vector.md (vector_ae_v2di_p): Change the flag used
to control outcomes from this test.
(vector_ae_p): For VEC_F modes, likewise.

Index: gcc/config/rs6000/altivec.h
===
--- gcc/config/rs6000/altivec.h (revision 246096)
+++ gcc/config/rs6000/altivec.h (working copy)
@@ -521,9 +521,9 @@ __altivec_scalar_pred(vec_all_nez,
 __altivec_scalar_pred(vec_any_eqz,
   __builtin_vec_vcmpnez_p (__CR6_LT_REV, a1, a2))
 __altivec_scalar_pred(vec_all_ne,
-  __builtin_vec_allne_p (a1, a2))
+  __builtin_vec_vcmpne_p (a1, a2))
 __altivec_scalar_pred(vec_any_eq,
-  __builtin_vec_anyeq_p (a1, a2))
+  __builtin_vec_vcmpae_p (a1, a2))
 #endif
 
 __altivec_scalar_pred(vec_any_ne,
Index: gcc/config/rs6000/vector.md
===
--- gcc/config/rs6000/vector.md (revision 246096)
+++ gcc/config/rs6000/vector.md (working copy)
@@ -790,7 +790,7 @@
  (eq:V2DI (match_dup 1)
   (match_dup 2)))])
(set (match_operand:SI 0 "register_operand" "=r")
-   (lt:SI (reg:CC CR6_REGNO)
+   (eq:SI (reg:CC CR6_REGNO)
   (const_int 0)))
(set (match_dup 0)
(xor:SI (match_dup 0)
@@ -837,7 +837,7 @@
  (eq:VEC_F (match_dup 1)
(match_dup 2)))])
(set (match_operand:SI 0 "register_operand" "=r")
-   (lt:SI (reg:CC CR6_REGNO)
+   (eq:SI (reg:CC CR6_REGNO)
   (const_int 0)))
(set (match_dup 0)
(xor:SI (match_dup 0)

[PATCH], PR target/79947, Fix compiler segmentation fault with -Ofast -mno-powerpc-gfxopt

[Michael Meissner]

In PR target/79947, the code for using the float reciprocal square root
estimate instruction did not check if the -mpowerpc-gfxopt option was enabled.
The code needs this option to generate a conditional floating point move.

I have checked this patch on the trunk, and it fixes the problem and it does
not cause any regressions.  Is it ok to apply to the trunk?  Assuming there are
no additional problems, can I apply the patch to the GCC 5 and 6 branches as
well?

[gcc]
2017-03-14  Michael Meissner  

PR target/79947
* config/rs6000/rs6000.h (TARGET_FRSQRTES): Add check for
-mpowerpc-gfxopt.

[gcc/testsuite]
2017-03-14  Michael Meissner  

PR target/79947
* gcc.target/powerpc/pr79947.c: New test.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h  (revision 246137)
+++ gcc/config/rs6000/rs6000.h  (working copy)
@@ -752,7 +752,8 @@ extern int rs6000_vector_align[];
 && (TARGET_POPCNTB || VECTOR_UNIT_VSX_P (DFmode)))
 
 #define TARGET_FRSQRTES(TARGET_HARD_FLOAT && TARGET_POPCNTB \
-&& TARGET_FPRS && TARGET_SINGLE_FLOAT)
+&& TARGET_PPC_GFXOPT && TARGET_FPRS \
+&& TARGET_SINGLE_FLOAT)
 
 #define TARGET_FRSQRTE (TARGET_HARD_FLOAT && TARGET_FPRS \
 && TARGET_DOUBLE_FLOAT \
Index: gcc/testsuite/gcc.target/powerpc/pr79947.c
===
--- gcc/testsuite/gcc.target/powerpc/pr79947.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr79947.c  (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-options "-Ofast -mno-powerpc-gfxopt -mcmpb -mno-vsx" } */
+
+/* PR 79949: Compiler segmentation fault due to not having conditional move
+   support for the target if the -mno-powerpc-gfxopt option is used.  */
+
+float a, b;
+void
+c ()
+{
+  a = __builtin_sqrtf (b);
+}

[Bug libstdc++/78870] Support std::filesystem on Windows

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870

--- Comment #10 from niXman  ---
(In reply to Jonathan Wakely from comment #9)
> There's a patch at https://gcc.gnu.org/ml/libstdc++/2017-02/msg00041.html
> 
> I haven't reviewed or tested it yet.

https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00772.html

Tested on i686/x86_64-MinGW-W64 and x86_64-linux-gnu.

Re: [PATCH doc] use "cannot" consistently

[Richard Kenner]

> The GCC manual uses "cannot" in most places (280 lines) but there
> are a few instances of "can't" (33 lines).
> 
> The attached patch replaces the informal "can't" with the former
> for consistency.

In my opinion, this is the wrong direction.  Contractions are becoming
more acceptable in even more formal writing and there's even a current
US Supreme Court justice who uses them in her opinions.

I certainly don't think it's worth a change to use "can't" throughout,
but I'm not in favor of eliminating it either.

Re: [PATCH] Windows support for std::filesystem

[niXman]

niXman 2017-02-12 20:28:

Hi,

Tested on i686/x86_64-MinGW-W64

Please test possible regressions on posix platform.


As continuation for: 
https://gcc.gnu.org/ml/libstdc++/2017-02/msg00041.html



Regression on posix platform was fixed.

Tested on i686/x86_64-MinGW-W64 and x86_64-linux-gnu.
Index: libstdc++-v3/src/filesystem/dir.cc
===
--- libstdc++-v3/src/filesystem/dir.cc	(revision 246136)
+++ libstdc++-v3/src/filesystem/dir.cc	(working copy)
@@ -41,9 +41,10 @@
 #endif
 
 #ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
-# undef opendir
-# define opendir _wopendir
-#endif
+# include "fs-win32.h"
+#else
+# include "fs-posix.h"
+#endif // _GLIBCXX_FILESYSTEM_IS_WINDOWS
 
 namespace fs = std::experimental::filesystem;
 
@@ -51,7 +52,7 @@
 {
   _Dir() : dirp(nullptr) { }
 
-  _Dir(DIR* dirp, const fs::path& path) : dirp(dirp), path(path) { }
+  _Dir(os_DIR_t* dirp, const fs::path& path) : dirp(dirp), path(path) { }
 
   _Dir(_Dir&& d)
   : dirp(std::exchange(d.dirp, nullptr)), path(std::move(d.path)),
@@ -60,11 +61,11 @@
 
   _Dir& operator=(_Dir&&) = delete;
 
-  ~_Dir() { if (dirp) ::closedir(dirp); }
+  ~_Dir() { if (dirp) ::os_closedir(dirp); }
 
   bool advance(std::error_code*, directory_options = directory_options::none);
 
-  DIR*			dirp;
+  os_DIR_t*			dirp;
   fs::path		path;
   directory_entry	entry;
   file_type		type = file_type::none;
@@ -87,7 +88,7 @@
 if (ec)
   ec->clear();
 
-if (DIR* dirp = ::opendir(p.c_str()))
+if (os_DIR_t* dirp = ::os_opendir(p.c_str()))
   return {dirp, p};
 
 const int err = errno;
@@ -105,7 +106,7 @@
   }
 
   inline fs::file_type
-  get_file_type(const ::dirent& d __attribute__((__unused__)))
+  get_file_type(const ::os_dirent_t& d __attribute__((__unused__)))
   {
 #ifdef _GLIBCXX_HAVE_STRUCT_DIRENT_D_TYPE
 switch (d.d_type)
@@ -145,13 +146,14 @@
 ec->clear();
 
   int err = std::exchange(errno, 0);
-  const auto entp = readdir(dirp);
+  const auto entp = ::os_readdir(dirp);
   std::swap(errno, err);
 
   if (entp)
 {
   // skip past dot and dot-dot
-  if (!strcmp(entp->d_name, ".") || !strcmp(entp->d_name, ".."))
+  if (!std::char_traits::compare(entp->d_name, _WS("."), 1) ||
+	!std::char_traits::compare(entp->d_name, _WS(".."), 2))
 	return advance(ec, options);
   entry = fs::directory_entry{path / entp->d_name};
   type = get_file_type(*entp);
@@ -239,7 +241,7 @@
  error_code* ec)
 : _M_options(options), _M_pending(true)
 {
-  if (DIR* dirp = ::opendir(p.c_str()))
+  if (os_DIR_t* dirp = ::os_opendir(p.c_str()))
 {
   auto sp = std::make_shared<_Dir_stack>();
   sp->push(_Dir{ dirp, p });
Index: libstdc++-v3/src/filesystem/fs-posix.h
===
--- libstdc++-v3/src/filesystem/fs-posix.h	(revision 0)
+++ libstdc++-v3/src/filesystem/fs-posix.h	(working copy)
@@ -0,0 +1,49 @@
+
+// Copyright (C) 2014-2017 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+#ifndef _GLIBCXX_EXPERIMENTAL_FS_POSIX_H
+#define _GLIBCXX_EXPERIMENTAL_FS_POSIX_H 1
+
+#define os_DIR_t DIR
+#define os_dirent_t dirent
+#define os_open open
+#define os_opendir opendir
+#define os_closedir closedir
+#define os_readdir readdir
+#define os_stat stat
+#define os_stat_t stat
+#define os_chmod chmod
+#define os_mkdir mkdir
+#define os_getcwd getcwd
+#define os_chdir chdir
+#define os_utimbuf_t utimbuf
+#define os_utime utime
+#define os_remove remove
+#define os_rename rename
+#define os_truncate truncate
+
+#define os_utime utime
+
+#define _WS(x) x
+
+#endif // _GLIBCXX_EXPERIMENTAL_FS_POSIX_H
Index: libstdc++-v3/src/filesystem/fs-win32.h
===
--- libstdc++-v3/src/filesystem/fs-win32.h	(revision 0)
+++ libstdc++-v3/src/filesystem/fs-win32.h	(working copy)
@@ -0,0 +1,64 @@
+
+// Copyright (C) 2014-2017 Free Software Foundation, Inc.
+//
+// This file is part of 

[Bug target/79947] [6/7 Regression] ICE in rs6000_emit_swsqrt at gcc/config/rs6000/rs6000.c:37570

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79947

--- Comment #4 from Michael Meissner  ---
Created attachment 40976
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40976=edit
Proposed patch to fix the problem

The tARGET_RSQRTES macro needed a guard to require -mpowerpc-gfxopt.

Re: [PATCH] RISC-V documentation cleanups

[Gerald Pfeifer]

On Mon, 13 Mar 2017, Palmer Dabbelt wrote:
> A recent mailing list post about install.texi cleanup suggested I 
> take a look at ours, and there were a few problems:
> 
>  * No table of contents entries
>  * Not alphabetically ordered
>  * Missing a note about requiring binutils-2.28

This looks fine with a few changes, thank you.

Perhaps a bit repetitive?  I'm wondering, would it make sense to 
have general riscv64-*-* entries that cover the general items?

> 2017-03-13  Palmer Dabbelt   
> * doc/install.texi (Specific) : Add table of contents
> link.
> : Likewise.
> : Likewise
> : Likewise.

Here I'd just say

* doc/install.texi (Specific): Add foo, bar, didl, doo to the
table of contents.

> : Add a note about requiring binutils-2.28.

Here and in the text, binutils 2.28 (without the dash).

Approved.

Gerald

PS: We usually send patches to the gcc-patches@ list.

[Bug libstdc++/80041] std::codecvt_utf16 converts to UTF-8 not UTF-16

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80041

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Jonathan Wakely  ---
Patch posted to https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00765.html

[wwwdocs] remove power.org links from readings.html

[Gerald Pfeifer]

Segher confirmed that power.org is gone and that it's okay to remove
those links for now.

He kindly agreed to help and look for alternatives.

Applied.

Gerald

Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.269
diff -u -r1.269 readings.html
--- readings.html   1 Mar 2017 13:38:38 -   1.269
+++ readings.html   14 Mar 2017 20:17:36 -
@@ -252,10 +252,8 @@
  rs6000 (powerpc, powerpcle)
   Manufacturer: IBM, Motorola
   https://members.openpowerfoundation.org/document/dl/576;>64-Bit ELF V2 
ABI - OpenPOWER ABI
-  https://www.power.org/wp-content/uploads/2013/05/PowerISA_V2.07_PUBLIC.pdf;>POWER8
 ISA
   http://publib16.boulder.ibm.com/pseries/en_US/infocenter/base/43_docs/aixassem/alangref/toc.htm;>AIX
 V4.3 Assembler Language Ref.
   http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixassem/alangref/alangreftfrm.htm;>AIX
 5L Assembler Language Ref.
-  https://www.power.org/documentation/;>Documentation and tools 
at power.org
  
  
  rx

[patch, fortran] PR39239 Warning about EQUIVALENCE and VOLATILE

[Nicolas Koenig]

Hello everyone,

a simple patch to throw a warning if not all and not none of the 
equivalence objects are volatile. (And the according modification of 
gfortran.dg/volatile11.f90)


Nicolas

Regression tested for:

GNU Fortran (GCC) 7.0.1 20170311 (experimental)

Changelog:

2017-03-13  Nicolas Koenig  

PR fortran/39239
* resolve.c (resolve_equivalence): Warn if not either 
none or all equivalence objects are volatile
* gfortran.dg/volatile11.f90: Changed test to test for 
the new warning



Index: fortran/resolve.c
===
--- fortran/resolve.c	(revision 246070)
+++ fortran/resolve.c	(working copy)
@@ -15560,7 +15560,7 @@ resolve_equivalence (gfc_equiv *eq)
   locus *last_where = NULL;
   seq_type eq_type, last_eq_type;
   gfc_typespec *last_ts;
-  int object, cnt_protected;
+  int object, cnt_protected, cnt_volatile;
   const char *msg;
 
   last_ts = >expr->symtree->n.sym->ts;
@@ -15569,6 +15569,8 @@ resolve_equivalence (gfc_equiv *eq)
 
   cnt_protected = 0;
 
+  cnt_volatile = 0;
+
   for (object = 1; eq; eq = eq->eq, object++)
 {
   e = eq->expr;
@@ -15641,6 +15643,17 @@ resolve_equivalence (gfc_equiv *eq)
 
   sym = e->symtree->n.sym;
 
+  if(sym->attr.volatile_)
+cnt_volatile++;
+  if(cnt_volatile > 0 && cnt_volatile != object)
+	{
+	  gfc_warning (0, "Either all or none of the objects in "
+	  	   "the EQUIVALENCE set at %L shall have the "
+		   "VOLATILE attribute",
+		   >where);
+	  break;
+	}
+
   if (sym->attr.is_protected)
 	cnt_protected++;
   if (cnt_protected > 0 && cnt_protected != object)
Index: testsuite/gfortran.dg/volatile11.f90
===
--- testsuite/gfortran.dg/volatile11.f90	(revision 246070)
+++ testsuite/gfortran.dg/volatile11.f90	(working copy)
@@ -1,8 +1,9 @@
 ! { dg-do compile }
-! { dg-options "-O2 -fdump-tree-optimized" }
+! { dg-options "-Wall -O2 -fdump-tree-optimized" }
 ! Tests that volatile can be applied to members of common blocks or
 ! equivalence groups (PR fortran/35037)
 !
+
 subroutine wait1
   logical event
   volatile event
@@ -14,26 +15,10 @@ subroutine wait1
 end subroutine
 
 subroutine wait2
-  logical event, foo
-  volatile event
-  equivalence (event, foo)
-  event = .false.
-  do
-if (event) print *, 'NotOptimizedAway2'
-  end do
-end subroutine
-
-subroutine wait3
   logical event
   integer foo
   volatile foo
-  equivalence (event, foo)
-  event = .false.
-  do
-if (event) print *, 'IsOptimizedAway'
-  end do
+  equivalence (event, foo) ! { dg-warning "in the EQUIVALENCE set" } 
 end subroutine
 
 ! { dg-final { scan-tree-dump "NotOptimizedAway1" "optimized" } } */
-! { dg-final { scan-tree-dump "NotOptimizedAway2" "optimized" } } */
-! { dg-final { scan-tree-dump-not "IsOptimizedAway" "optimized" } } */

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[koenigni at student dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39239

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #40964|0   |1
is obsolete||

--- Comment #11 from Nicolas Koenig  ---
Created attachment 40975
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40975=edit
Proposed patch for EQUIVALENCE / VOLATILE 3

I will keep that in mind (Thanks for the information!).

After seeing the discussion over at comp.lang.fortran on what this "should"
really means, I settled for a warning.

[Bug target/79947] [6/7 Regression] ICE in rs6000_emit_swsqrt at gcc/config/rs6000/rs6000.c:37570

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79947

--- Comment #3 from Michael Meissner  ---
The problem is the -mno-powerpc-gfxopt option disables floating point
conditional moves, which is needed to use the floating point reciprocal
estimate instructions.

The macro TARGET_FRSQRTES did not have a check for GFXOPT.

[Bug target/79947] [6/7 Regression] ICE in rs6000_emit_swsqrt at gcc/config/rs6000/rs6000.c:37570

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79947

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-14
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.

[Martin Sebor]

On 03/12/2017 05:23 PM, Gerald Pfeifer wrote:

Hi Martin,

On Mon, 27 Feb 2017, Martin Sebor wrote:

Sorry to be jumping in so late. I only noticed this bit now.

I would suggest to say that these new built-ins evaluate to integer
constant expressions when their arguments do.  Not all C programmers
are familiar with C++ constexpr so they may not understand the use
use case.  The request for these built-ins also came from a C user
and was specifically motivated by avoiding -Woverflow warnings so
adding an example demonstrating that might be helpful as well.
Something like this:

  ... Calls to these built-ins with integer constant arguments
  evaluate to integer constants expressions.
  For example, in the following, c is assigned
  the result of a * b only if the multiplication
  does not overflow, otherwise it is assigned the value zero.
  The multiplication is performed at compile-time and without
  triggering a -Woverflow warning.





  
enum {
  a = 12345678,
  b = 87654321,
  c = __builtin_mul_overflow_p (a, b, a) ? 0 : a * b
};
  


this works for me, modulo the closing  which I believe will be
necessary.  Were you seeing approval for this from someone?  (If so,
that may not have been me. ;-)


Thanks.  I just committed it.

Martin

Re: [PATCH doc] use "cannot" consistently

[Richard Sandiford]

Martin Sebor  writes:
> @@ -373,7 +373,7 @@ example, this code would produce an error:
>  
>  @smallexample
>  #if 0
> -You can't expect this to work.
> +You cannot expect this to work.
>  #endif
>  @end smallexample
>  

Sure the maintainers would have caught this, but: the "'" is needed here.
The point is that code doesn't tokenise properly.

Thanks,
Richard

Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)

[Jeff Law]

On 03/12/2017 07:32 PM, Martin Sebor wrote:

On 03/10/2017 10:51 PM, Jeff Law wrote:

On 03/10/2017 09:20 AM, Martin Sebor wrote:

On 03/10/2017 05:57 AM, Rainer Orth wrote:

Hi Segher,


On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote:

Segher Boessenkool  writes:


As stated in the PR, this test now passes on aarch64, ia64, powerpc,
and s390x.  This patch disables the xfails for those targets.


As I'd mentioned in PR tree-optimization/78775, the test XPASSes on
SPARC, too.


Tested on powerpc64-linux {-m32,-m64}.  Is this okay for trunk?

[...]

2017-02-09  Segher Boessenkool  

gcc/testsuite/
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64,
powerpc,
or s390x.


TBH, I'd strongly prefer to have a proper analysis instead of just
un-xfail-ing the test on an ever growing apparently random list of
targets.


Yeah, I agree.  I thought it was just another test that stopped
failing,
but it seems to fail in two ways now, making the testcase succeed?
Lovely.  Please consider this patch withdrawn.


I just noticed that nothing has happened at all in a month, so anything
is better than the tests XPASSing on a number of targets.

So the patch is ok for mainline with sparc*-*-* added to the target
lists and a reference to PR testsuite/79356 in the comment.

I'd still be very grateful if Martin could have a look what's really
going on here, though.


Sorry, I haven't had a chance to look more deeply into why these
assertions pass on some targets and fail on others.  There is at
least one bug that tracks a VRP problem that manifests only on
some targets and not others (79054).  I don't know if this is
a symptom of the same bug or something different.  I'll see if
I can find some time to isolate it.

It could well be a BRANCH_COST effect.  BRANCH_COST is probably the most
annoying target property that bleeds into the tree/gimple world.  From
looking at the gimple in the BZ that could well be the case.

See logical_op_short_circuit for how this is often dealt with in the
testsuite.


Thanks for the hint.  I extracted the test case from
attr-alloc_size-11.c and reproduced the discrepancy on powerpc64le
and x86_64.  It looks to me like two bugs(?) conspire to trigger
it.  I opened pr80006 with the details and I'm working on a patch.

Here's some more detail.  First, on x86_64 (but not on powerpc64le
and I suspect the other targets where this assertion passes), GCC
very early on introduces a spurious conversion from signed char to
int.  For instance, given:

  void* f (signed char x)
  {
extern void* ff (signed char) __attribute__ ((alloc_size (1)));

if (-3 <= x && x <= 7)
  x = -4;

return ff (x);
  }

the tree-original dump on x86_64 is as follows (note the (int)x
cast):

  ;; Function f (null)
  ;; enabled by -tree-original
  {
extern void * ff (signed char);

if ((unsigned char) x + 3 <= 10)
  {
x = -4;
  }
return ff ((int) x);   <<< spurious cast
  }

while the following the same dump on powerpc64le (no cast):

  ;; Function f (null)
  ;; enabled by -tree-original
  {
extern void * ff (signed char);

if ((unsigned char) x + 3 <= 10)
  {
x = -4;
  }

return ff (x);   <<< no cast
  }
Those differences could well be related to promotions implied by the ABI 
in use on each target.  Those certainly happen too, they're just not as 
common a problem as the logical_op_short_circuit stuff.






The cast makes its way to VRP where it causes the range on x
to be lost in the conversion to the temporary it introduces:

  Found new range for x_4: ~[-3, 7]
  marking stmt to be not simulated again

  Visiting statement:
  _9 = (int) x_4;
  Meeting
[-128, -4]
  and
[8, 127]
  to
[-128, 127]
  Found new range for _9: [-128, 127]   <<< anti-range lost
Seems like a problem.  Given that we're converting to a wider type, we 
ought to be able to do better and not lose the anti range.





  ...
  Visiting PHI node: prephitmp_10 = PHI <_9(3), -4(2)>
  ...
  Meeting
[-128, 127]
  and
[-4, -4]
  to
[-128, 127]
  Intersecting
[-128, 127]
  and
[-128, 127]
  to
[-128, 127]
  Found new range for prephitmp_10: [-128, 127]
  ...
  Visiting statement:
  _8 = ff (prephitmp_10);
ISTM that ~[-3,7] U -4 should result in ~[-3,7], right?   The 
union/intersection of ANTI ranges looked like it could use some 
improvement when I was in there last month, so I wouldn't be surprised 
if it needs some improvement.





Debugging tree-vrp.c suggests that this is a deficiency in
the extract_range_from_unary_expr function the computes the
range of the result of the NOP_EXPR (the cast) of an SSA_NAME
with an anti-range ~[A, B] as a union of [TYPE_MIN, A - 1] and
[B + 1, TYPE_MAX], which for ~[-3, 7] and the signed char x in
the test case results in [SCHAR_MIN, -4] U [8, SCHAR_MAX], or
[SCHAR_MIN, SCHAR_MAX].  There's a comment in the function

[PATCH doc] use "cannot" consistently

[Martin Sebor]

In formal writing it's recommended to prefer the word "cannot"
to the somewhat informal "can't."

The GCC manual uses "cannot" in most places (280 lines) but there
are a few instances of "can't" (33 lines).

The attached patch replaces the informal "can't" with the former
for consistency.

Thanks
Martin

PS I wasted quite a bit of time updating tm.texi.  I kept getting
the error below and didn't realize (forgot) that it was asking me
to copy $objdir/gcc/tm.texi to $srcdir/gcc/doc/tm.texi.  Can
someone explain why this file requires these special steps when
the rest of the .texi files can be updated directly?

mv tmp2-tm.texi tmp-tm.texi
/bin/sh /src/gcc/svn/gcc/../move-if-change tmp-tm.texi tm.texi

Verify that you have permission to grant a GFDL license for all
new text in tm.texi, then copy it to /src/gcc/svn/gcc/doc/tm.texi.,
Makefile:2437: recipe for target 's-tm-texi' failed
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 246134)
+++ gcc/doc/extend.texi	(working copy)
@@ -7509,7 +7509,7 @@ In this case, GCC does not actually output assembl
 function, unless you specify the option @option{-fkeep-inline-functions}.
 If there is a nonintegrated call, then the function is compiled to
 assembler code as usual.  The function must also be compiled as usual if
-the program refers to its address, because that can't be inlined.
+the program refers to its address, because that cannot be inlined.
 
 @opindex Winline
 Note that certain usages in a function definition can make it unsuitable
@@ -9176,7 +9176,7 @@ This results in an incomplete type, much like what
 @code{struct foo} without describing the elements.  A later declaration
 that does specify the possible values completes the type.
 
-You can't allocate variables or storage using the type while it is
+You cannot allocate variables or storage using the type while it is
 incomplete.  However, you can work with pointers to that type.
 
 This extension may not be very useful, but it makes the handling of
Index: gcc/doc/hostconfig.texi
===
--- gcc/doc/hostconfig.texi	(revision 246134)
+++ gcc/doc/hostconfig.texi	(working copy)
@@ -22,7 +22,7 @@ header.  @xref{System Config}.
 
 @menu
 * Host Common:: Things every host probably needs implemented.
-* Filesystem::  Your host can't have the letter `a' in filenames?
+* Filesystem::  Your host cannot have the letter `a' in filenames?
 * Host Misc::   Rare configuration options for hosts.
 @end menu
 
Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi	(revision 246134)
+++ gcc/doc/install.texi	(working copy)
@@ -3633,7 +3633,7 @@ The libffi library haven't been ported to 64-bit H
 
 Refer to @uref{binaries.html,,binaries} for information about obtaining
 precompiled GCC binaries for HP-UX@.  Precompiled binaries must be obtained
-to build the Ada language as it can't be bootstrapped using C@.  Ada is
+to build the Ada language as it cannot be bootstrapped using C@.  Ada is
 only available for the 32-bit PA-RISC runtime.
 
 Starting with GCC 3.4 an ISO C compiler is required to bootstrap.  The
@@ -3713,12 +3713,12 @@ Although the HP and GNU linkers are both supported
 HP linker be used for link editing on this target.
 
 At this time, the GNU linker does not support the creation of long
-branch stubs.  As a result, it can't successfully link binaries
+branch stubs.  As a result, it cannot successfully link binaries
 containing branch offsets larger than 8 megabytes.  In addition,
 there are problems linking shared libraries, linking executables
 with @option{-static}, and with dwarf2 unwind and exception support.
 It also doesn't provide stubs for internal calls to global functions
-in shared libraries, so these calls can't be overloaded.
+in shared libraries, so these calls cannot be overloaded.
 
 The HP dynamic loader does not support GNU symbol versioning, so symbol
 versioning is not supported.  It may be necessary to disable symbol
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 246134)
+++ gcc/doc/invoke.texi	(working copy)
@@ -6471,7 +6471,7 @@ different size.
 @opindex Winvalid-pch
 @opindex Wno-invalid-pch
 Warn if a precompiled header (@pxref{Precompiled Headers}) is found in
-the search path but can't be used.
+the search path but cannot be used.
 
 @item -Wlong-long
 @opindex Wlong-long
@@ -10733,7 +10733,7 @@ more details.  The run-time behavior can be influe
 the available options are shown at startup of the instrumented program.  See
 @url{https://github.com/google/sanitizers/wiki/AddressSanitizerFlags#run-time-flags}
 for a list of supported options.
-The option can't be combined with @option{-fsanitize=thread}
+The option cannot be combined with @option{-fsanitize=thread}
 

[Bug middle-end/80042] gcc thinks sin/cos don't set errno

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80042

--- Comment #1 from Andrew Pinski  ---
Most likely because gcc assumes sin ( Inf); is a full constant so it can remove
the load after it.

[Bug target/79951] ICE in extract_insn, at recog.c:2311 on ppc64le with -mno-cmpb

[pthaugen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79951

Pat Haugen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-14
 CC||pthaugen at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pthaugen at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Pat Haugen  ---
Confirmed.

Reduced testcase.

// gcc -S -mno-cmpb test.c
float
testf (float x, float y)
{
  return __builtin_copysignf (x, y);
}

Re: [PATCH] Various fixes for facets

[Jonathan Wakely]

On 13/03/17 19:35 +, Jonathan Wakely wrote:

This is a series of patches to fix various bugs in the Unicode
character conversion facets.

Ther first patch fixes a silly < versus <= bug that meant that 0x
got written as a surrogate pair instead of as simply 0xff, and an
endianness bug for the internal representation of UTF-16 code units
stored in char32_t or wchar_t values. That's PR 79511.

The second patch fixes some incorrect bitwise operations (because I
confused & and |) and some incorrect limits (because I confused max
and min). That fixes determining the endianness of the external
representation bytes when they start with a Byte OrderMark, and
correctly reports errors on invalid UCS2. It also fixes
wstring_convert so that it reports the number of characters that were
converted prior to an error. That's PR 79980.

The third patch fixes the output of the encoding() and max_length()
member functions on the codecvt facets, because I wasn't correctly
accounting for a BOM or for the differences between UTF-16 and UCS2.

I plan to commit these for all branches, but I'll wait until after GCC
7.1 is released, and fix it for 7.2 instead. These bugs aren't
important enough to rush into trunk now.


One more patch for a problem found by the libc++ testsuite. Now we
pass all the libc++ tests, and we even pass a test that libc++ fails.
With this, I hope our  is 100% conforming. Just in time to be
deprecated for C++17 :-)


commit 3118704bc37cd771b9fc5bf83230f38a16a7c5c3
Author: Jonathan Wakely 
Date:   Tue Mar 14 17:47:12 2017 +

PR libstdc++/80041 fix codecvt_utf16 to use UTF-16 not UTF-8

	PR libstdc++/80041
	* src/c++11/codecvt.cc (__codecvt_utf16_base::do_out)
	(__codecvt_utf16_base::do_in): Convert char arguments to
	char16_t to work with UTF-16 instead of UTF-8.
	* testsuite/22_locale/codecvt/codecvt_utf16/80041.cc: New test.

diff --git a/libstdc++-v3/src/c++11/codecvt.cc b/libstdc++-v3/src/c++11/codecvt.cc
index 9c91725..ef38267 100644
--- a/libstdc++-v3/src/c++11/codecvt.cc
+++ b/libstdc++-v3/src/c++11/codecvt.cc
@@ -1217,7 +1217,10 @@ do_out(state_type&, const intern_type* __from, const intern_type* __from_end,
extern_type* __to, extern_type* __to_end,
extern_type*& __to_next) const
 {
-  range to{ __to, __to_end };
+  range to{
+reinterpret_cast(__to),
+reinterpret_cast(__to_end)
+  };
 #if __SIZEOF_WCHAR_T__ == 2
   range from{
 reinterpret_cast(__from),
@@ -1234,7 +1237,7 @@ do_out(state_type&, const intern_type* __from, const intern_type* __from_end,
   return codecvt_base::error;
 #endif
   __from_next = reinterpret_cast(from.next);
-  __to_next = to.next;
+  __to_next = reinterpret_cast(to.next);
   return res;
 }
 
@@ -1254,7 +1257,10 @@ do_in(state_type&, const extern_type* __from, const extern_type* __from_end,
   intern_type* __to, intern_type* __to_end,
   intern_type*& __to_next) const
 {
-  range from{ __from, __from_end };
+  range from{
+reinterpret_cast(__from),
+reinterpret_cast(__from_end)
+  };
 #if __SIZEOF_WCHAR_T__ == 2
   range to{
 reinterpret_cast(__to),
@@ -1270,7 +1276,7 @@ do_in(state_type&, const extern_type* __from, const extern_type* __from_end,
 #else
   return codecvt_base::error;
 #endif
-  __from_next = from.next;
+  __from_next = reinterpret_cast(from.next);
   __to_next = reinterpret_cast(to.next);
   return res;
 }
diff --git a/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf16/80041.cc b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf16/80041.cc
new file mode 100644
index 000..a78b194
--- /dev/null
+++ b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf16/80041.cc
@@ -0,0 +1,87 @@
+// Copyright (C) 2017 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do run { target c++11 } }
+
+#include 
+#include 
+
+void
+test01()
+{
+#ifdef _GLIBCXX_USE_WCHAR_T
+  std::codecvt_utf16 conv;
+  const wchar_t wc = 0x6557;
+  char bytes[2] = {0};
+  const wchar_t* wcnext;
+  std::mbstate_t st{};
+  char* next = nullptr;
+  auto res = conv.out(st, , + 1, wcnext, bytes, std::end(bytes), next);
+  VERIFY( res == std::codecvt_base::ok );
+  VERIFY( wcnext ==  + 1 );
+  VERIFY( next == std::end(bytes) );
+  VERIFY( 

Re: C++ PATCH to fix ICE in replace_placeholders_r (PR c++/79937)

[Jason Merrill]

On Tue, Mar 14, 2017 at 2:33 PM, Jason Merrill  wrote:
> On Tue, Mar 7, 2017 at 12:10 PM, Marek Polacek  wrote:
>> In this testcase we have
>> C c = bar (X{1});
>> which store_init_value sees as
>> c = TARGET_EXPR > .n=(&)->i}>)>
>> i.e. we're initializing "c" with a TARGET_EXPR.  We call replace_placeholders
>> that walks the whole tree to substitute the placeholders.  Eventually we find
>> the nested  but that's for another object, so we
>> crash.  Seems that we shouldn't have stepped into the second TARGET_EXPR at
>> all; it has nothing to with "c", it's bar's argument.
>>
>> It occurred to me that we shouldn't step into CALL_EXPRs and leave the
>> placeholders in function arguments to cp_gimplify_init_expr which calls
>> replace_placeholders for constructors.  Not sure if it's enough to handle
>> CALL_EXPRs like this, anything else?
>
> Hmm, we might have a DMI containing a call with an argument referring
> to *this, i.e.
>
> struct A
> {
>   int i;
>   int j = frob (this->i);
> };
>
> The TARGET_EXPR seems like a more likely barrier, but even there we
> could have something like
>
> struct A { int i; };
> struct B
> {
>   int i;
>   A a = A{this->i};
> };
>
> I think we need replace_placeholders to keep a stack of objects, so
> that when we see a TARGET_EXPR we add it to the stack and therefore
> can properly replace a PLACEHOLDER_EXPR of its type.

Or actually, avoid replacing such a PLACEHOLDER_EXPR, but rather leave
it for later when we lower the TARGET_EXPR.

Jason

Re: C++ PATCH to fix ICE in replace_placeholders_r (PR c++/79937)

[Jason Merrill]

On Tue, Mar 7, 2017 at 12:10 PM, Marek Polacek  wrote:
> In this testcase we have
> C c = bar (X{1});
> which store_init_value sees as
> c = TARGET_EXPR  .n=(&)->i}>)>
> i.e. we're initializing "c" with a TARGET_EXPR.  We call replace_placeholders
> that walks the whole tree to substitute the placeholders.  Eventually we find
> the nested  but that's for another object, so we
> crash.  Seems that we shouldn't have stepped into the second TARGET_EXPR at
> all; it has nothing to with "c", it's bar's argument.
>
> It occurred to me that we shouldn't step into CALL_EXPRs and leave the
> placeholders in function arguments to cp_gimplify_init_expr which calls
> replace_placeholders for constructors.  Not sure if it's enough to handle
> CALL_EXPRs like this, anything else?

Hmm, we might have a DMI containing a call with an argument referring
to *this, i.e.

struct A
{
  int i;
  int j = frob (this->i);
};

The TARGET_EXPR seems like a more likely barrier, but even there we
could have something like

struct A { int i; };
struct B
{
  int i;
  A a = A{this->i};
};

I think we need replace_placeholders to keep a stack of objects, so
that when we see a TARGET_EXPR we add it to the stack and therefore
can properly replace a PLACEHOLDER_EXPR of its type.

Jason

[Bug c++/80043] New: [6/7 Regression] ICE with pointer-to-member-function and -fpermissive

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80043

Bug ID: 80043
   Summary: [6/7 Regression] ICE with pointer-to-member-function
and -fpermissive
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following code snippet (compiled with -fpermissive) triggers an ICE
since GCC 6.1.0:

=
struct A
{
  template void foo()
  {
void (A::* fp)();
fp = A::foo<0>;
  }
};

void bar()
{
  A().foo<0>();
}
=

bug.cc: In instantiation of 'void A::foo() [with int  = 0]':
bug.cc:12:14:   required from here
bug.cc:6:8: warning: assuming pointer to member 'void A::foo() [with int
 = 0]' [-fpermissive]
 fp = A::foo<0>;
 ~~~^~~
bug.cc:6:8: note: (a pointer to member can only be formed with '::foo<0>')
bug.cc:6:5: internal compiler error: in finish_expr_stmt, at cp/semantics.c:677
 fp = A::foo<0>;
 ^~
0x7affd0 finish_expr_stmt(tree_node*)
../../gcc-6.1.0/gcc/cp/semantics.c:677
0x683322 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-6.1.0/gcc/cp/pt.c:15121
0x68089c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-6.1.0/gcc/cp/pt.c:15103
0x681662 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-6.1.0/gcc/cp/pt.c:15289
0x6c105e instantiate_decl(tree_node*, int, bool)
../../gcc-6.1.0/gcc/cp/pt.c:22013
0x6c7e3b instantiate_pending_templates(int)
../../gcc-6.1.0/gcc/cp/pt.c:22130
0x708d61 c_parse_final_cleanups()
../../gcc-6.1.0/gcc/cp/decl2.c:4599
Please submit a full bug report, [etc.]

[Bug middle-end/80042] New: gcc thinks sin/cos don't set errno

[craig.topper at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80042

Bug ID: 80042
   Summary: gcc thinks sin/cos don't set errno
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: craig.topper at gmail dot com
  Target Milestone: ---

Created attachment 40974
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40974=edit
Test that uses sin and errno

As of glibc version 2.10, sin and cos set errno when the input is infinity. gcc
thinks sin/cos never write errno and will move them around relative to reads of
errno.

The attached test case will return a failing error code at O0 and a passing
error code at O2 when the errno read after the sin call is optimized out.


glibc commit
https://sourceware.org/git/?p=glibc.git;a=commit;f=sysdeps/ieee754/dbl-64/s_sin.c;h=0c59a1963e948c546e0d3e34de974c7e71de1134

I believe sincos was also changed to update errno in 2015
https://sourceware.org/bugzilla/show_bug.cgi?id=15467

[Bug rtl-optimization/79728] [7 Regression] ICE in setup_pressure_classes, at ira.c:912

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79728

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #8 from Jeffrey A. Law  ---
Fixed by Bernd's patch on the trunk.

[Bug rtl-optimization/79728] [7 Regression] ICE in setup_pressure_classes, at ira.c:912

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79728

--- Comment #7 from Jeffrey A. Law  ---
Author: law
Date: Tue Mar 14 17:50:46 2017
New Revision: 246138

URL: https://gcc.gnu.org/viewcvs?rev=246138=gcc=rev
Log:
PR rtl-optimization/79728
* regs.h (struct target_regs): New field
x_contains_allocatable_regs_of_mode.
(contains_allocatable_regs_of_mode): New macro.
* reginfo.c (init_reg_sets_1): Initialize it, and change
contains_reg_of_mode so it includes global regs as well.
* reload.c (push_reload): Use contains_allocatable_regs_of_mode
rather than contains_regs_of_mode.

PR rtl-optimization/79728
* gcc.target/i386/sse-globalreg.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/sse-globalreg.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reginfo.c
trunk/gcc/regs.h
trunk/gcc/reload.c
trunk/gcc/testsuite/ChangeLog

Re: Fix IRA issue, PR79728

[Jeff Law]

On 03/03/2017 06:51 AM, Bernd Schmidt wrote:

This is an ICE where setup_pressure_classes fails if xmm0 is a global
reg. Instead of GENERAL/FLOAT/SSE/MMX_REGS, it computes only
SSE_FIRST_REG as the third register class. The problem is that the costs
for moving between SSE_FIRST_REG and SSE_REGS are inflated because we
think we have no available registers in SSE_FIRST_REG (since the only
register in that class is global), and that somewhat confuses the
algorithm.

The following fixes it by tweaking contains_regs_of_mode. Out of
caution, I've retained the old meaning for code in reload which uses this.

Bootstrapped and tested on x86_64-linux. Ok?


Bernd

global-reg-cost.diff


PR rtl-optimization/79728
* regs.h (struct target_regs): New field
x_contains_allocatable_regs_of_mode.
(contains_allocatable_regs_of_mode): New macro.
* reginfo.c (init_reg_sets_1): Initialize it, and change
contains_reg_of_mode so it includes global regs as well.
* reload.c (push_reload): Use contains_allocatable_regs_of_mode
rather thanc ontains_regs_of_mode.

PR rtl-optimization/79728
* gcc.target/i386/sse-globalreg.c: New test.

And I went ahead and installed on the trunk.

jeff

Re: [PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace

[Denis Khalikov]

Thanks for answer, i got it now.
I will also delete all readlink code. Looks like is no reason
to use it instead just one call of realpath(char*,char*). Binutils
using realpath in the same cases.

On 03/14/2017 07:26 PM, Ian Lance Taylor wrote:

On Tue, Mar 14, 2017 at 7:30 AM, Denis Khalikov
 wrote:

Thanks for review, got all of my mistakes, except one.



-  descriptor = backtrace_open (info->dlpi_name, pd->error_callback,
-   pd->data, _not_exist);
+  descriptor
+ = backtrace_open_debugfile (info->dlpi_name, pd->error_callback,
pd->data,
+_does_not_exist, pd->state, 0);
+  if (descriptor < 0)
+  descriptor = backtrace_open (info->dlpi_name, pd->error_callback,
+   pd->data, _not_exist);


This seems like unnecessary work.  Shouldn't we only try to open the
debug file if we find a .gnu_debuglink section?

Should i move code below

  /* check if debug section does exist */
 debug_link_data
= elf_gnu_debuglink_section (state, descriptor, error_callbackdata, exe,
_link_data_len);

from backtrace_open_debugfile .


As far as I know all the debuglink code is ELF-specific.  I would do
it all in elf.c.  While reading the sections of the executable, look
for a debuglink section, and use it if present.  Keep the readlink
code in posix.c, I suppose.  Apologies if this doesn't make sense.

Ian




On 03/14/2017 04:49 PM, Ian Lance Taylor wrote:


On Mon, Mar 13, 2017 at 10:16 AM, Denis Khalikov
 wrote:


Hello everyone, i have a patch for this issue.

List of implemented functionality:

1.Reading .gnu_debuglink section from ELF file:
 a. Reading name of debug info file.
 b. Verifying crc32 sum.

2. Searching for separate debug info file from paths:
 a. /usr/lib/debug/path/to/executable
 b. /path/to/executable
 c. /path/to/executable/.debug

Assumed that debug info file generated by objcopy from binutils.

objcopy --only-keep-debug foo foo.debug
strip -g foo
objcopy --add-gnu-debuglink=foo.debug foo




+clean_separate:glinktest.debug
+ rm -f glinktest.debug
+
+separate: glinktest
+ if test -n "$(OBJCOPY)" &&  test -n "$(STRIP)";  \
+ then \
+ $(OBJCOPY) --only-keep-debug glinktest glinktest.debug;\
+ $(STRIP) glinktest;\
+ $(OBJCOPY) --add-gnu-debuglink=glinktest.debug glinktest;\
+ fi;



As far as I know "separate" is not a special thing in automake.  We
should always run (and clean) this test if the necessary objcopy
option is available.


+glinktest.lo: (INCDIR)/filenames.h backtrace.h backtrace-supported.h



Missing '$'  in "$(INCDIR)".


+/* Return 1 if header is valid and -1 on fail */



This comment does not explain what the function actually does.


+/* Return the pointer to char array with data from .gnudebuglink section
inside.  */



Line too long, we use 80 column lines.


+unsigned char *
+elf_gnu_debuglink_section (struct backtrace_state *state, int
descriptor,
+   backtrace_error_callback error_callback, void *data,
+   int exe, int *gnulink_data_len_out)



This should be static.  I see that you are calling it elsewhere, but
it doesn't make sense to call an "elf" function outside of elf.c.
This library is used on non-ELF systems.


+  /* Look for for the .gnu_debuglink section  */



Period at end of sentence.


   /* To translate PC to file/line when using DWARF, we need to find
- the .debug_info and .debug_line sections.  */
+   the .debug_info and .debug_line sections.  */



Why change the indentation like this?  I think the original was correct.


-  descriptor = backtrace_open (info->dlpi_name, pd->error_callback,
-   pd->data, _not_exist);
+  descriptor
+ = backtrace_open_debugfile (info->dlpi_name, pd->error_callback,
pd->data,
+_does_not_exist, pd->state, 0);
+  if (descriptor < 0)
+  descriptor = backtrace_open (info->dlpi_name, pd->error_callback,
+   pd->data, _not_exist);



This seems like unnecessary work.  Shouldn't we only try to open the
debug file if we find a .gnu_debuglink section?


+/*Just a simple test copied from btest.c, but in this case we don't have
debug
+ * info in the executable and test should verify that we can read debug
info
+ * from separate file. See Makefile check-TESTS target. */



No leading '*' on subsequent lines of multi-line comments, see existing
code.

I'm not sure I see the point of glinktest.c.  Why don't we just use
btest.c?


+#define MAX_PATH_LEN 4096 /*  from linux/limits.h   */



This library works on systems other than GNU/Linux.  We should
dynamically allocate the buffer.


+  while (len > 1 && !IS_DIR_SEPARATOR (*(buffer + (len - 1



while (len > 1 && !IS_DIR_SEPARATOR(buffer[len-1]))

or just call basename.  I'm not sure why you bother with the count
variable; doesn't full_filename_len - count exactly == len?


+  sign_byte = 0x00;
+  count = 0;
+  while (*(buffer + count) != sign_byte && size > count)
+++count;
+  return count;



This looks like `return strnlen(buffer, size)`.

Ian

Re: Fix IRA issue, PR79728

[Jeff Law]

On 03/03/2017 06:51 AM, Bernd Schmidt wrote:

This is an ICE where setup_pressure_classes fails if xmm0 is a global
reg. Instead of GENERAL/FLOAT/SSE/MMX_REGS, it computes only
SSE_FIRST_REG as the third register class. The problem is that the costs
for moving between SSE_FIRST_REG and SSE_REGS are inflated because we
think we have no available registers in SSE_FIRST_REG (since the only
register in that class is global), and that somewhat confuses the
algorithm.

The following fixes it by tweaking contains_regs_of_mode. Out of
caution, I've retained the old meaning for code in reload which uses this.

Bootstrapped and tested on x86_64-linux. Ok?


Bernd

global-reg-cost.diff


PR rtl-optimization/79728
* regs.h (struct target_regs): New field
x_contains_allocatable_regs_of_mode.
(contains_allocatable_regs_of_mode): New macro.
* reginfo.c (init_reg_sets_1): Initialize it, and change
contains_reg_of_mode so it includes global regs as well.
* reload.c (push_reload): Use contains_allocatable_regs_of_mode
rather thanc ontains_regs_of_mode.

PR rtl-optimization/79728
* gcc.target/i386/sse-globalreg.c: New test.

OK.
jeff

Re: [PATCH] Use fixed_nonglobal_reg_set to deduce ok_regs (PR rtl-optimization/79728)

[Jeff Law]

On 03/06/2017 01:27 AM, Xi Ruoyao wrote:

Hi,

After Bernd fixed PR44281 (r235809), the registers fixed only because
they are global can be selected by IRA. However, since they are not
in ok_regs, the move cost estimation about them are wrong. Then an
assertion in ira.c failed and then ICE.

To fix this, add these registers into ok_regs.

Bootstrapped/regtested on x86_64-linux-gnu. Is this ok for trunk?

2017-03-06  Xi Ruoyao  

PR rtl-optimization/79728
* reginfo.c (init_reg_sets_1): Use fixed_nonglobal_reg_set
(instead of fixed_regs) to deduce ok_regs.

* gcc.target/i386/pr79728.c: New test.
I think I prefer Bernd's patch, mostly because it preserves the old 
meaning of the code for reload.


jeff

[Bug rtl-optimization/79949] ICE in Max. number of generated reload insns per insn is achieved (90)

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79949

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #6 from Jeffrey A. Law  ---
Fixed by Vlad's commit on the trunk.

Re: [PATCH] Install gcov-dump.

[Matthias Klose]

On 14.03.2017 15:15, Richard Biener wrote:
> On Tue, Mar 14, 2017 at 1:30 PM, Martin Liška  wrote:
>> Tested on my local machine that's properly installed.
>>
>> Ready for trunk?
> 
> Ok.
> 
> Richard.

shouldn't that go to the active branches as well?

Matthias

[Bug c++/80038] Random segfault using local vectors in Cilk function

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038

--- Comment #8 from Jeffrey A. Law  ---
It's unfortunate and directly  related to the maintenance effort involved.

The deprecation plan for Cilk+ would have code in gcc-7, but the code would be
removed prior to the gcc-8 release.  Unless someone wanted to step up and
maintain the code -- so far efforts to find new maintainers for Cilk+ haven't
produced any results.

[Bug libstdc++/80041] std::codecvt_utf16 converts to UTF-8 not UTF-16

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80041

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-14
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1