Re: [PATCH][GIMPLEFE] Fix for ICE due to undeclared variable

[Prasad Ghangal]

On 7 February 2017 at 13:40, Richard Biener  wrote:
> On Mon, Feb 6, 2017 at 7:00 AM, Prasad Ghangal  
> wrote:
>> On 4 January 2017 at 16:02, Richard Biener  
>> wrote:
>>> On Wed, Dec 28, 2016 at 7:27 PM, Prasad Ghangal
>>>  wrote:
 Hi,
 The attached patch tries fix ICE due to undeclared variable(s) in the 
 input.
 Successfully bootstrapped on x86_64-pc-linux-gnu, testing is in progress
>>>
>>> Ok.
>>>
>> Can you please commit the patch? I don't have access for that.
>
> Can you share a testcase that broke?  I tried
>

Consider following testcases:

Case 1:
int __GIMPLE foo()
{
  if (a != 2)
goto bb1;
  else
goto bb2;

bb1:
  a_1 = 10;
  return a_1;

bb2:
  return 1;
}

gives:

 foo
gcc/test.c: In function ‘foo’:
gcc/test.c:3:7: error: ‘a’ undeclared (first use in this function)
   if (a != 2)
   ^
gcc/test.c:3:7: note: each undeclared identifier is reported only once
for each function it appears in
gcc/test.c:9:3: internal compiler error: in make_ssa_name_fn, at
tree-ssanames.c:268
   a_1 = 10;
   ^~~
0x1199aa0 make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
../../git_gcc/gcc/tree-ssanames.c:265
0x839e2c c_parser_parse_ssa_name
../../git_gcc/gcc/c/gimple-parser.c:675
0x83a5e6 c_parser_gimple_postfix_expression
../../git_gcc/gcc/c/gimple-parser.c:845
0x839ac5 c_parser_gimple_unary_expression
../../git_gcc/gcc/c/gimple-parser.c:603
0x838544 c_parser_gimple_statement
../../git_gcc/gcc/c/gimple-parser.c:271
0x83848e c_parser_gimple_compound_statement
../../git_gcc/gcc/c/gimple-parser.c:226
0x837fd2 c_parser_parse_gimple_body(c_parser*)
../../git_gcc/gcc/c/gimple-parser.c:92
0x7f7bb5 c_parser_declaration_or_fndef
../../git_gcc/gcc/c/c-parser.c:2091
0x7f628a c_parser_external_declaration
../../git_gcc/gcc/c/c-parser.c:1468
0x7f5dd3 c_parser_translation_unit
../../git_gcc/gcc/c/c-parser.c:1348
0x82a3c4 c_parse_file()
../../git_gcc/gcc/c/c-parser.c:18185
0x89c5d9 c_common_parse_file()
../../git_gcc/gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



Case 2:

int __GIMPLE ()
main (int argc, char * * argv)
{

  bb_2:
  switch (a) {default: L2; case 1: L0; case 2: L1; }

L0:
  a = 0;
  goto bb_6;

L1:
  a = 3;
  goto L2;

L2:
  return a;

}

 main
gcc/test3.c: In function ‘main’:
gcc/test3.c:6:11: error: ‘a’ undeclared (first use in this function)
   switch (a) {default: L2; case 1: L0; case 2: L1; }
   ^
gcc/test3.c:6:11: note: each undeclared identifier is reported only
once for each function it appears in
gcc/test3.c:6:3: internal compiler error: in gimple_switch_set_index,
at gimple.h:4513
   switch (a) {default: L2; case 1: L0; case 2: L1; }
   ^~
0xb31385 gimple_switch_set_index
../../git_gcc/gcc/gimple.h:4513
0xb33b3f gimple_build_switch_nlabels(unsigned int, tree_node*, tree_node*)
../../git_gcc/gcc/gimple.c:757
0xb33b90 gimple_build_switch(tree_node*, tree_node*, vec)
../../git_gcc/gcc/gimple.c:773
0x83bd94 c_parser_gimple_switch_stmt
../../git_gcc/gcc/c/gimple-parser.c:1445
0x83832c c_parser_gimple_compound_statement
../../git_gcc/gcc/c/gimple-parser.c:175
0x837fd2 c_parser_parse_gimple_body(c_parser*)
../../git_gcc/gcc/c/gimple-parser.c:92
0x7f7bb5 c_parser_declaration_or_fndef
../../git_gcc/gcc/c/c-parser.c:2091
0x7f628a c_parser_external_declaration
../../git_gcc/gcc/c/c-parser.c:1468
0x7f5dd3 c_parser_translation_unit
../../git_gcc/gcc/c/c-parser.c:1348
0x82a3c4 c_parse_file()
../../git_gcc/gcc/c/c-parser.c:18185
0x89c5d9 c_common_parse_file()
../../git_gcc/gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Case 3:

void __GIMPLE () foo (int a)
{
bb_2:
  a = *b;

bb_3:
  return;
}

 foo
gcc/test6.c: In function ‘foo’:
gcc/test6.c:5:8: error: ‘b’ undeclared (first use in this function)
   a = *b;
^
gcc/test6.c:5:8: note: each undeclared identifier is reported only
once for each function it appears in
gcc/test6.c:5:3: internal compiler error: tree check: expected class
‘type’, have ‘exceptional’ (error_mark) in build_int_cst, at
tree.c:1297
   a = *b;
   ^
0x125cd92 tree_class_check_failed(tree_node const*, tree_code_class,
char const*, int, char const*)
../../git_gcc/gcc/tree.c:9866
0x77f8e3 tree_class_check(tree_node*, tree_code_class, char const*,
int, char const*)
../../git_gcc/gcc/tree.h:3183
0x123db1e build_int_cst(tree_node*, long)
../../git_gcc/gcc/tree.c:1297
0x124b279 

Re: [PATCH 0/2] [ARC] Define __NPS400__ properly

[Andrew Burgess]

* Claudiu Zissulescu  [2017-01-30 10:35:08 
+]:

> Hi,
> 
> > 
> > Andrew Burgess (2):
> >   ARC: Make arc_selected_cpu global
> >   ARC: Better creation of __NPS400__ define
> > 
> >  gcc/ChangeLog   | 31 
> >  gcc/config/arc/arc-arch.h   | 50 ++
> > ---
> >  gcc/config/arc/arc-c.def|  1 +
> >  gcc/config/arc/arc.c| 35 ++-
> >  gcc/config/arc/arc.h| 24 ++
> >  gcc/config/arc/driver-arc.c |  2 +-
> >  6 files changed, 88 insertions(+), 55 deletions(-)
> 
> I haven't check them functionally, but they seems alright to me.
> 
> Thank you for your contribution,

Thank you for the review.  Sorry it took me a while to apply these
changes.

These are now committed as r245293 and r245294 respectively.

Thanks again,
Andrew

[committed] Fix libgomp testsuite failures on hppa*-*-hpux*

[John David Anglin]

The libgomp.oacc-c-c++-common/loop-dim-default.c test uses asms and needs to be 
skipped on hppa.

We don't have the complex.h header on hppa*-*-hpux*.  The 
libgomp.oacc-c-c++-common/reduction-cplx-dbl.c
and libgomp.oacc-c-c++-common/reduction-cplx-flt.c tests compile fine on hppa 
without it.

As a result, we have no fails in libgomp testsuite on hppa64-hp-hpux11.11.

Dave
--
John David Anglin   dave.ang...@bell.net


2017-02-08  John David Anglin  

* testsuite/libgomp.oacc-c-c++-common/loop-dim-default.c: Skip on
hppa*-*-*.
* testsuite/libgomp.oacc-c-c++-common/reduction-cplx-dbl.c: Don't
include complex.h on hppa*-*-hpux*.
* testsuite/libgomp.oacc-c-c++-common/reduction-cplx-flt.c: Likewise.

Index: testsuite/libgomp.oacc-c-c++-common/loop-dim-default.c
===
--- testsuite/libgomp.oacc-c-c++-common/loop-dim-default.c  (revision 
245238)
+++ testsuite/libgomp.oacc-c-c++-common/loop-dim-default.c  (working copy)
@@ -1,6 +1,7 @@
 /* This code uses nvptx inline assembly guarded with acc_on_device, which is
not optimized away at -O0, and then confuses the target assembler.
{ dg-skip-if "" { *-*-* } { "-O0" } { "" } } */
+   { dg-skip-if "" { hppa*-*-* } { "*" } { "" } } */
 /* { dg-additional-options "-fopenacc-dim=16:16" } */
 
 #include 
Index: testsuite/libgomp.oacc-c-c++-common/reduction-cplx-dbl.c
===
--- testsuite/libgomp.oacc-c-c++-common/reduction-cplx-dbl.c(revision 
245238)
+++ testsuite/libgomp.oacc-c-c++-common/reduction-cplx-dbl.c(working copy)
@@ -1,5 +1,7 @@
 
+#if !defined(__hppa__) || !defined(__hpux__)
 #include 
+#endif
 
 /* Double float has 53 bits of fraction. */
 #define FRAC (1.0 / (1LL << 48))
Index: testsuite/libgomp.oacc-c-c++-common/reduction-cplx-flt.c
===
--- testsuite/libgomp.oacc-c-c++-common/reduction-cplx-flt.c(revision 
245238)
+++ testsuite/libgomp.oacc-c-c++-common/reduction-cplx-flt.c(working copy)
@@ -1,5 +1,7 @@
 
+#if !defined(__hppa__) || !defined(__hpux__)
 #include 
+#endif
 
 /* Single float has 23 bits of fraction. */
 #define FRAC (1.0f / (1 << 20))

Re: [C++ PATCH] For -std=c++1z treat class types with inherited ctors as non-aggregate (PR c++/79143)

[Jason Merrill]

On Wed, Feb 8, 2017 at 5:24 PM, Jakub Jelinek  wrote:
> On Wed, Feb 08, 2017 at 04:51:54PM -0500, Jason Merrill wrote:
>> On Tue, Feb 7, 2017 at 4:30 PM, Jakub Jelinek  wrote:
>> > P0017R1 added in [dcl.init.aggr]/1 that classes with inherited constructors
>> > are not aggregate.  CLASSTYPE_NON_AGGREGATE is set slightly before
>> > add_implicitly_declared_members is called and so we don't know about the
>> > inherited ctors yet.
>>
>> Hmm, why doesn't my patch for 78124 to set CLASSTYPE_NON_AGGREGATE in
>> do_class_using_decl cover this testcase?
>
> It does set CLASSTYPE_NON_AGGREGATE on a different RECORD_TYPE,
> do_class_using_decl sees the template, while what is tested and what
> check_bases_and_members is called on is the implicit instantiation thereof.
>
> The following completely untested patch also fixes it.  Or is there some
> even better place where to copy over that bit from the template to the
> instantiation?

Better I think in instantiate_class_template_1, about where we copy TYPE_PACKED.

Jason

Re: [PATCH 2/8] [i386] Add option -moutline-msabi-xlogues

[Bernhard Reutner-Fischer]

On 7 February 2017 19:40:17 CET, Daniel Santos  wrote:

>+{ "-mmoutline-msabi-xlogues", MASK_OUTLINE_MSABI_XLOGUES }
>   };

s/mm/m/

>+thus reducing function size at the cost of and few extra instructions.

s/and/a/

Re: [C++ PATCH] For -std=c++1z treat class types with inherited ctors as non-aggregate (PR c++/79143)

[Jakub Jelinek]

On Wed, Feb 08, 2017 at 04:51:54PM -0500, Jason Merrill wrote:
> On Tue, Feb 7, 2017 at 4:30 PM, Jakub Jelinek  wrote:
> > P0017R1 added in [dcl.init.aggr]/1 that classes with inherited constructors
> > are not aggregate.  CLASSTYPE_NON_AGGREGATE is set slightly before
> > add_implicitly_declared_members is called and so we don't know about the
> > inherited ctors yet.
> 
> Hmm, why doesn't my patch for 78124 to set CLASSTYPE_NON_AGGREGATE in
> do_class_using_decl cover this testcase?

It does set CLASSTYPE_NON_AGGREGATE on a different RECORD_TYPE,
do_class_using_decl sees the template, while what is tested and what
check_bases_and_members is called on is the implicit instantiation thereof.

The following completely untested patch also fixes it.  Or is there some
even better place where to copy over that bit from the template to the
instantiation?

2017-02-08  Jakub Jelinek  

PR c++/79143
* pt.c (lookup_template_class_1): Copy CLASSTYPE_NON_AGGREGATE
from template_type to t.

* g++.dg/cpp1z/pr79143.C: New test.

--- gcc/cp/pt.c.jj  2017-02-06 21:02:40.0 +0100
+++ gcc/cp/pt.c 2017-02-08 23:18:20.461836658 +0100
@@ -8770,6 +8770,8 @@ lookup_template_class_1 (tree d1, tree a
  t = make_class_type (TREE_CODE (template_type));
  CLASSTYPE_DECLARED_CLASS (t)
= CLASSTYPE_DECLARED_CLASS (template_type);
+ CLASSTYPE_NON_AGGREGATE (t)
+   = CLASSTYPE_NON_AGGREGATE (template_type);
  SET_CLASSTYPE_IMPLICIT_INSTANTIATION (t);
 
  /* A local class.  Make sure the decl gets registered properly.  */
--- gcc/testsuite/g++.dg/cpp1z/pr79143.C.jj 2017-02-07 17:55:19.091028200 
+0100
+++ gcc/testsuite/g++.dg/cpp1z/pr79143.C2017-02-07 17:54:48.0 
+0100
@@ -0,0 +1,28 @@
+// PR c++/79143
+// { dg-do compile }
+// { dg-options "-std=c++1z" }
+
+struct base {
+  base (int, int) {}
+};
+
+template
+struct derived : base {
+  using base::base;
+};
+
+template
+struct derived2 : base {
+  derived2 (int x, int y) : base (x, y) {}
+};
+
+int
+main ()
+{
+  base (13, 42);
+  derived (13, 42);
+  derived2 (13, 42);
+  base{13, 42};
+  derived{13, 42}; // { dg-bogus "too many initializers" }
+  derived2{13, 42};
+}


Jakub

Re: [C++ PATCH] For -std=c++1z treat class types with inherited ctors as non-aggregate (PR c++/79143)

[Jason Merrill]

On Tue, Feb 7, 2017 at 4:30 PM, Jakub Jelinek  wrote:
> P0017R1 added in [dcl.init.aggr]/1 that classes with inherited constructors
> are not aggregate.  CLASSTYPE_NON_AGGREGATE is set slightly before
> add_implicitly_declared_members is called and so we don't know about the
> inherited ctors yet.

Hmm, why doesn't my patch for 78124 to set CLASSTYPE_NON_AGGREGATE in
do_class_using_decl cover this testcase?

Jason

Re: [wwwdocs] RISC-V readings and features

[Palmer Dabbelt]

On Wed, 08 Feb 2017 13:43:55 PST (-0800), ger...@pfeifer.com wrote:
> On Wed, 8 Feb 2017, Gerald Pfeifer wrote:
>> So, both are okay.
>
> Except http://riscv.org actually redirects to https://riscv.org . :-}
>
> Fixed thusly.
>
> Gerald
>
> Index: index.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
> retrieving revision 1.1043
> diff -u -r1.1043 index.html
> --- index.html3 Feb 2017 20:39:15 -   1.1043
> +++ index.html8 Feb 2017 17:01:33 -
> @@ -48,7 +48,7 @@
>
>  RISC-V support
>   [2017-02-02]
> - Support for the http://riscv.org;>RISC-V ISA was 
> added, contributed by Palmer Dabbelt and Andrew Waterman.
> + Support for the https://riscv.org;>RISC-V ISA was 
> added, contributed by Palmer Dabbelt and Andrew Waterman.
>
>  BRIG/HSAIL (Heterogeneous Systems Architecture Intermediate 
> Language) frontend added
>   [2017-02-01]

Thanks

Re: [libstdc++,PATCH] src/c++11/snprintf_lite.cc - update bug reporting URL

[Gerald Pfeifer]

On Wed, 8 Feb 2017, Jonathan Wakely wrote:
>> +  "(Please submit full bug report at http://gcc.gnu.org/bugs/):\n";
> Shouldn't that be https ? :-)

You're right!  Fixed by the patch at the end.

On Wed, 8 Feb 2017, Jakub Jelinek wrote:
> Note ACX_BUGURL in gcc/configure.ac needs adjustments too.

That, and a few others such as libquadmath or gcc/po/exgettext. :-(

On Wed, 8 Feb 2017, Jakub Jelinek wrote:
> I wouldn't, people who configure with 256KB long --with-bugurl arguments
> should be adequately punished.

Agreed. ;-)

Gerald


2017-02-08  Gerald Pfeifer  
 
* src/c++11/snprintf_lite.cc (__err): Use https for bug reporting.
 
Index: src/c++11/snprintf_lite.cc
===
--- src/c++11/snprintf_lite.cc  (revision 245268)
+++ src/c++11/snprintf_lite.cc  (working copy)
@@ -52,7 +52,7 @@
 const size_t __len = __bufend - __buf + 1;
 
 const char __err[] = "not enough space for format expansion "
-  "(Please submit full bug report at http://gcc.gnu.org/bugs/):\n";
+  "(Please submit full bug report at https://gcc.gnu.org/bugs/):\n";
 const size_t __errlen = sizeof(__err) - 1;
 
 char *const __e

Re: [wwwdocs] RISC-V readings and features

[Gerald Pfeifer]

On Wed, 8 Feb 2017, Gerald Pfeifer wrote:
> So, both are okay.

Except http://riscv.org actually redirects to https://riscv.org . :-}

Fixed thusly.

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.1043
diff -u -r1.1043 index.html
--- index.html  3 Feb 2017 20:39:15 -   1.1043
+++ index.html  8 Feb 2017 17:01:33 -
@@ -48,7 +48,7 @@
 
 RISC-V support
  [2017-02-02]
- Support for the http://riscv.org;>RISC-V ISA was added, 
contributed by Palmer Dabbelt and Andrew Waterman.
+ Support for the https://riscv.org;>RISC-V ISA was added, 
contributed by Palmer Dabbelt and Andrew Waterman.
 
 BRIG/HSAIL (Heterogeneous Systems Architecture Intermediate 
Language) frontend added
  [2017-02-01]

Re: [PATCH] Properly deprecate -fipa-cp-alignment

[Joseph Myers]

On Wed, 8 Feb 2017, Jakub Jelinek wrote:

> >  fipa-cp-alignment
> > -Common Report Var(flag_ipa_cp_alignment) Optimization
> > -Perform alignment discovery and propagation to make Interprocedural 
> > constant propagation stronger.
> > +Common Report
> > +This switch is deprecated.  Use -fipa-bit-cp instead.
> 
> I think this should be
> Common Ignore
> Does nothing. Preserved for backward compatibility.

Indeed, for any non-semantic option being obsoleted.

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

[patch, fortran] Fix PR 65542, accepts invalid F95

[Thomas Koenig]

Hello world,

the attached patch fixes a 5/6/7 regression where we accept
code that is invalid for F95.  Regression-tested.

OK for trunk?

(For some reason attaching the file doesn't work, and I don't want to
reboot my computer or log out just now because of some long-running
calculation. Therefore, I'm pasting both patch and test file.)


Regards

Thomas

2017-02-08  Thomas Koenig  

PR fortran/65542
* intrinsic.c (gfc_intrinsic_func_interface):  Return an error
for -std=f95 for disallowed transformational functions in
initialization expressions.

2017-02-08  Thomas Koenig  

PR fortran/65542
* spread_init_expr_2.f90:  New test case.

Patch:

Index: intrinsic.c
===
--- intrinsic.c (Revision 244747)
+++ intrinsic.c (Arbeitskopie)
@@ -4680,6 +4680,27 @@ gfc_intrinsic_func_interface (gfc_expr *expr, int
   return MATCH_ERROR;
 }

+  /* F95, 7.1.6.1: Only transformational functions REPEAT, RESHAPE,
+ SELECTED_INT_KIND, SELECTED_REAL_KIND, TRANSFER, and TRIM are 
allowed in

+ initialization expressions.  */
+
+  if (gfc_init_expr_flag && isym->transformational)
+{
+  gfc_isym_id id = isym->id;
+  if (id != GFC_ISYM_REPEAT && id != GFC_ISYM_RESHAPE
+ && id != GFC_ISYM_SI_KIND && id != GFC_ISYM_SR_KIND
+ && id != GFC_ISYM_TRANSFER && id != GFC_ISYM_TRIM
+ && !gfc_notify_std (GFC_STD_F2003, "Transformational function 
%qs "
+ "invalid as initialization expression is 
at %L",

+ name, >where))
+   {
+ if (!error_flag)
+   gfc_pop_suppress_errors ();
+
+ return MATCH_ERROR;
+   }
+}
+
   gfc_current_intrinsic_where = >where;

   /* Bypass the generic list for min, max and ISO_C_Binding's c_loc.  */

Test case:

! { dg-do compile }
! { dg-options "-std=f95" }
! PR fortran/65542 - this did not give an error.
module bug
  integer :: ibug(42) = spread(42, 1, 42) ! { dg-error "invalid as 
initialization expression" }

end module

Re: [PATCH, rs6000] Fix PR78604

[Segher Boessenkool]

On Wed, Feb 08, 2017 at 12:45:22PM -0600, Pat Haugen wrote:
> The following patch fixes the pr by adding code for integer comparisons to 
> invert the condition and swap operands to avoid generation of a compound 
> test. Bootstrap/regtest on powerpc64-unknown-linux-gnu with no new 
> regressions. Ok for trunk?

This had me confused for a bit, but you're not swapping the operands of
the condition, you're swapping the true/false operands of the cond
expression :-)
Okay for trunk.  Thanks,


Segher


> 2017-02-08  Pat Haugen  
> 
>   PR target/78604
>   * config/rs6000/rs6000.c (rs6000_emit_vector_cond_expr): Invert
>   condition/operands for integer GE/LE/GEU/LEU operations.
> 
> 
> testsuite/ChangeLog:
> 2017-02-08  Pat Haugen  
> 
>   PR target/78604
>   * gcc.target/powerpc/pr78604.c: New.

Re: [PATCH] gfortran -- Map REAL128 to REAL kind type with widest precision

[Mikael Morin]

Le 08/02/2017 à 10:25, FX a écrit :

Hi Steve,

I see Mikael has okayed the patch, but I did not have any time to comment 
prior. I wanted to note that:

 - the choice was deliberate, as the standard allows us to choose which real 
kind REAL128 corresponds to when there are several matching choices. The idea 
behind the current choice was to avoid forcing the use of slower soft-float 
arithmetic when a hardware type existed. I don’t have a strong opinion myself 
on the issue.

Hello, I didn’t have this in mind when I OKed the patch.
Still, I think the rule above goes against the principle of least surprise.
Actually I don’t really see the use case for these constants.
When would a user say; give me a real that big, including padding bits?



 - Is this appropriate for stage 4?


Now  that you remind of it, if we take the rules to the letter, no.
My opinion is that it should be accepted, in stage 4 or later.
But I don’t have a strong opinion about it either.

Mikael

Re: [C++PATCH] c++/79393 virtual base of abstract class

[Nathan Sidwell]

On 02/08/2017 12:53 PM, Jason Merrill wrote:


Perhaps the defect is in the standard.  Will you email core about it?


Correct, done.

nathan

--
Nathan Sidwell

[PATCH] Add RISC-V Maintainers

[Palmer Dabbelt]

2017-02-08  Palmer Dabbelt  

* MAINTAINERS (CPU Port Maintainers): Add Kito Cheng, Palmer Dabbelt,
and Andrew Waterman as the RISC-V maintainers.
---
 ChangeLog   | 5 +
 MAINTAINERS | 3 +++
 2 files changed, 8 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index d2c498a..2623a7d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2017-02-08  Palmer Dabbelt  
+
+   * MAINTAINERS (CPU Port Maintainers): Add Kito Cheng, Palmer Dabbelt,
+   and Andrew Waterman as the RISC-V maintainers.
+
 2017-02-07  Gerald Pfeifer  
 
* MAINTAINERS: Adjust bug reporting URL.
diff --git a/MAINTAINERS b/MAINTAINERS
index aad4231..6f29872 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -88,6 +88,9 @@ nios2 portSandra Loosemore

 nvptx port Bernd Schmidt   
 pdp11 port Paul Koning 
 picochip port  Daniel Towner   
+riscv port Kito Cheng  
+riscv port Palmer Dabbelt  
+riscv port Andrew Waterman 
 rl78 port  DJ Delorie  
 rs6000/powerpc portDavid Edelsohn  
 rs6000/powerpc portSegher Boessenkool  
-- 
2.10.2

Re: New Port for RISC-V v3

[Palmer Dabbelt]

On Wed, 08 Feb 2017 00:43:09 PST (-0800), ebotca...@adacore.com wrote:
>> I believe we're in.  Thanks for the help!
>
> Congratulations.  There are a few post-integration items to be done:
>
> "If the back end is added to the official GCC source repository, the
> following are also necessary:
>
>* An entry for the target architecture in `readings.html' on the GCC
>  web site, with any relevant links.
>
>* Details of the properties of the back end and target architecture
>  in `backends.html' on the GCC web site.

These two patches were in flight, they were just approved and I committed them
a few minutes ago.

>* A news item about the contribution of support for that target
>  architecture, in `index.html' on the GCC web site.

There's a "RISC-V support" section in index.html.

>* Normally, one or more maintainers of that target listed in
>  `MAINTAINERS'.  Some existing architectures may be unmaintained,
>  but it would be unusual to add support for a target that does not
>  have a maintainer when support is added.

Sorry, we forgot about that.  I just sent a patch.

>* Target triplets covering all `config.gcc' stanzas for the target,
>  in the list in `contrib/config-list.mk'."

I added the Linux targets, but forgot the ELF ones.  I sent a patch for this as
well.

Thanks for checking up!

[PATCH] Add the RISC-V ELF targets to config-list.mk

[Palmer Dabbelt]

2017-02-08  Palmer Dabbelt  

* config-list.mk (LIST): Add riscv32-unknown-elf and
riscv64-unknown-elf.
---
 contrib/ChangeLog  | 5 +
 contrib/config-list.mk | 1 +
 2 files changed, 6 insertions(+)

diff --git a/contrib/ChangeLog b/contrib/ChangeLog
index f89ff38..23c6d7a 100644
--- a/contrib/ChangeLog
+++ b/contrib/ChangeLog
@@ -1,3 +1,8 @@
+2017-02-08  Palmer Dabbelt  
+
+   * config-list.mk (LIST): Add riscv32-unknown-elf and
+   riscv64-unknown-elf.
+
 2017-02-06  Palmer Dabbelt  
 
* config-list.mki (LIST): Add riscv32-unknown-linux-gun and
diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index 0edc8a4..ffbf8d4 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -79,6 +79,7 @@ LIST = aarch64-elf aarch64-linux-gnu aarch64-rtems \
   powerpc-wrs-vxworks powerpc-wrs-vxworksae powerpc-wrs-vxworksmils \
   powerpc-lynxos powerpcle-elf \
   powerpcle-eabisim powerpcle-eabi \
+  riscv32-unknown-elf riscv64-unknown-elf \
   riscv32-unknown-linux-gnu riscv64-unknown-linux-gnu \
   rs6000-ibm-aix5.3.0 rs6000-ibm-aix6.1 rs6000-ibm-aix7.1 \
   rl78-elf rx-elf s390-linux-gnu s390x-linux-gnu s390x-ibm-tpf sh-elf \
-- 
2.10.2

Re: [wwwdocs] RISC-V readings and features

[Palmer Dabbelt]

Sorry, I must have missed that one.  They're committed.

Thanks!

On Wed, 08 Feb 2017 03:33:19 PST (-0800), ger...@pfeifer.com wrote:
> Hi Palmer,
>
> On Tue, 7 Feb 2017, Palmer Dabbelt wrote:
>> These were suggested as part of our review process, but I never got an
>> OK on them.  Am I meant to just commit these?
>
> I am pretty sure I acked htdocs/readings.html (see the mail below).
>
> backends.html I am not sufficiently knowledgable, but since we trust
> you to maintain the port, it makes sense to trust you to describe the
> port's characteristics, too. ;-)
>
> So, both are okay.
>
> Thanks,
> Gerald
>
>  forwarded message 
> From: Gerald Pfeifer 
> To: Palmer Dabbelt 
> Cc: jos...@codesourcery.com, gcc-patches@gcc.gnu.org
> Date: Fri, 3 Feb 2017 22:55:05 +0100 (CET)
> Subject: Re: New Port for RISC-V v2
>
> On Fri, 3 Feb 2017, Palmer Dabbelt wrote:
>> How do these look?
>
> Fine for readings.html.  backends.html, not my cup of tea. ;-)
>
> Gerald

[PATCH, rs6000] Fix PR78604

[Pat Haugen]

The following patch fixes the pr by adding code for integer comparisons to 
invert the condition and swap operands to avoid generation of a compound test. 
Bootstrap/regtest on powerpc64-unknown-linux-gnu with no new regressions. Ok 
for trunk?

-Pat


2017-02-08  Pat Haugen  

PR target/78604
* config/rs6000/rs6000.c (rs6000_emit_vector_cond_expr): Invert
condition/operands for integer GE/LE/GEU/LEU operations.


testsuite/ChangeLog:
2017-02-08  Pat Haugen  

PR target/78604
* gcc.target/powerpc/pr78604.c: New.



Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c  (revision 245252)
+++ config/rs6000/rs6000.c  (working copy)
@@ -25150,12 +25150,29 @@ rs6000_emit_vector_cond_expr (rtx dest,
return 0;
   break;
 
-  /* Mark unsigned tests with CCUNSmode.  */
+case GE:
+case LE:
+  if (GET_MODE_CLASS (mask_mode) == MODE_VECTOR_INT)
+   {
+ /* Invert condition to avoid compound test.  */
+ invert_move = true;
+ rcode = reverse_condition (rcode);
+   }
+  break;
+
 case GTU:
 case GEU:
 case LTU:
 case LEU:
+  /* Mark unsigned tests with CCUNSmode.  */
   cc_mode = CCUNSmode;
+
+  /* Invert condition to avoid compound test if necessary.  */
+  if (rcode == GEU || rcode == LEU)
+   {
+ invert_move = true;
+ rcode = reverse_condition (rcode);
+   }
   break;
 
 default:
Index: testsuite/gcc.target/powerpc/pr78604.c
===
--- testsuite/gcc.target/powerpc/pr78604.c  (revision 0)
+++ testsuite/gcc.target/powerpc/pr78604.c  (working copy)
@@ -0,0 +1,112 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
+/* { dg-options "-mcpu=power8 -O2 -ftree-vectorize" } */
+
+#ifndef SIZE
+#define SIZE 1024
+#endif
+
+#ifndef ALIGN
+#define ALIGN 32
+#endif
+
+#ifndef TYPE
+#define TYPE long long
+#endif
+
+#ifndef SIGN_TYPE
+#define SIGN_TYPE signed TYPE
+#endif
+
+#ifndef UNS_TYPE
+#define UNS_TYPE unsigned TYPE
+#endif
+
+#define ALIGN_ATTR __attribute__((__aligned__(ALIGN)))
+
+SIGN_TYPE  sa[SIZE] ALIGN_ATTR;
+SIGN_TYPE  sb[SIZE] ALIGN_ATTR;
+SIGN_TYPE  sc[SIZE] ALIGN_ATTR;
+
+UNS_TYPE   ua[SIZE] ALIGN_ATTR;
+UNS_TYPE   ub[SIZE] ALIGN_ATTR;
+UNS_TYPE   uc[SIZE] ALIGN_ATTR;
+
+void
+sign_lt (SIGN_TYPE val1, SIGN_TYPE val2)
+{
+  unsigned long i;
+
+  for (i = 0; i < SIZE; i++)
+sa[i] = (sb[i] < sc[i]) ? val1 : val2;
+}
+
+void
+sign_lte (SIGN_TYPE val1, SIGN_TYPE val2)
+{
+  unsigned long i;
+
+  for (i = 0; i < SIZE; i++)
+sa[i] = (sb[i] <= sc[i]) ? val1 : val2;
+}
+
+void
+sign_gt (SIGN_TYPE val1, SIGN_TYPE val2)
+{
+  unsigned long i;
+
+  for (i = 0; i < SIZE; i++)
+sa[i] = (sb[i] > sc[i]) ? val1 : val2;
+}
+
+void
+sign_gte (SIGN_TYPE val1, SIGN_TYPE val2)
+{
+  unsigned long i;
+
+  for (i = 0; i < SIZE; i++)
+sa[i] = (sb[i] >= sc[i]) ? val1 : val2;
+}
+
+
+void
+uns_lt (UNS_TYPE val1, UNS_TYPE val2)
+{
+  unsigned long i;
+
+  for (i = 0; i < SIZE; i++)
+ua[i] = (ub[i] < uc[i]) ? val1 : val2;
+}
+
+void
+uns_lte (UNS_TYPE val1, UNS_TYPE val2)
+{
+  unsigned long i;
+
+  for (i = 0; i < SIZE; i++)
+ua[i] = (ub[i] <= uc[i]) ? val1 : val2;
+}
+
+void
+uns_gt (UNS_TYPE val1, UNS_TYPE val2)
+{
+  unsigned long i;
+
+  for (i = 0; i < SIZE; i++)
+ua[i] = (ub[i] > uc[i]) ? val1 : val2;
+}
+
+void
+uns_gte (UNS_TYPE val1, UNS_TYPE val2)
+{
+  unsigned long i;
+
+  for (i = 0; i < SIZE; i++)
+ua[i] = (ub[i] >= uc[i]) ? val1 : val2;
+}
+
+/* { dg-final { scan-assembler-times {\mvcmpgtsd\M} 4 } } */
+/* { dg-final { scan-assembler-times {\mvcmpgtud\M} 4 } } */
+/* { dg-final { scan-assembler-not   {\mvcmpequd\M} } } */

Re: [wwwdocs] Add a case to porting_to + a question wrt validity of another one

[Jason Merrill]

On Wed, Feb 8, 2017 at 12:45 PM, Marek Polacek  wrote:
> On Wed, Feb 08, 2017 at 02:14:14PM +0100, Markus Trippelsdorf wrote:
>> I'm not suggesting to drop both. But:
>>
>> »As a consequence, the following examples are invalid and G++ will no
>> longer compile them, because, in the following examples, G++ used to...«
>>
>> The second occurrence of "the following examples" doesn't add any new
>> meaning and is therefore redundant, because you are already referring to
>> "the following examples".
>
> Hm, ok, so:
>
> Index: porting_to.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/porting_to.html,v
> retrieving revision 1.5
> diff -u -r1.5 porting_to.html
> --- porting_to.html 7 Feb 2017 14:22:39 -   1.5
> +++ porting_to.html 8 Feb 2017 17:44:57 -
> @@ -52,7 +52,8 @@
>
>  
>  As a consequence, the following examples are invalid and G++ will no longer
> -compile them:
> +compile them, because G++ used to treat this->member
> +where member has a non-dependent type, as type-dependent, and now it doesn't.
>  

Looks good.

Jason

Re: [C++PATCH] c++/79393 virtual base of abstract class

[Jason Merrill]

On Wed, Feb 8, 2017 at 10:09 AM, Nathan Sidwell  wrote:
> On 02/08/2017 09:33 AM, Tim Song wrote:
>> On Wed, Feb 8, 2017 at 10:08 PM, Nathan Sidwell  wrote:

>>> 'potentially constructed subobject' appears to be a term without
>>> definition.
>>
>> [special]/5:
>>
>> For a class, its non-static data members, its non-virtual direct base
>> classes, and, if the class is not abstract, its virtual base classes
>> are called its potentially constructed subobjects.
>
> thanks.  That suggests that this, pedantically, is not a defect.  It's
> certainly an unwelcome surprise though.

Perhaps the defect is in the standard.  Will you email core about it?

Jason

Re: [wwwdocs] Add a case to porting_to + a question wrt validity of another one

[Marek Polacek]

On Wed, Feb 08, 2017 at 02:14:14PM +0100, Markus Trippelsdorf wrote:
> I'm not suggesting to drop both. But:
> 
> »As a consequence, the following examples are invalid and G++ will no
> longer compile them, because, in the following examples, G++ used to...«
> 
> The second occurrence of "the following examples" doesn't add any new
> meaning and is therefore redundant, because you are already referring to
> "the following examples".

Hm, ok, so:

Index: porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/porting_to.html,v
retrieving revision 1.5
diff -u -r1.5 porting_to.html
--- porting_to.html 7 Feb 2017 14:22:39 -   1.5
+++ porting_to.html 8 Feb 2017 17:44:57 -
@@ -52,7 +52,8 @@
 
 
 As a consequence, the following examples are invalid and G++ will no longer
-compile them:
+compile them, because G++ used to treat this->member
+where member has a non-dependent type, as type-dependent, and now it doesn't.
 
 
 

Marek

Re: [PATCH] Fix PR69823

[Sebastian Pop]

On Wed, Feb 8, 2017 at 8:34 AM, Richard Biener  wrote:
>
> The following fixes walking the SESE region when determining if it is
> valid.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> Will commit as obvious once that passed.

The change looks good.

Thanks,
Sebastian

>
> Thanks,
> Richard.
>
> 2017-02-08  Richard Biener  
>
> PR tree-optimization/69823
> * graphite-scop-detection.c (scop_detection::harmful_loop_in_region):
> Properly enumerate all BBs in the region.  Use auto_vec/auto_bitmap.
>
> * gcc.dg/graphite/pr69823.c: New testcase.
>
> Index: gcc/graphite-scop-detection.c
> ===
> --- gcc/graphite-scop-detection.c   (revision 245276)
> +++ gcc/graphite-scop-detection.c   (working copy)
> @@ -1062,35 +1062,18 @@ scop_detection::harmful_loop_in_region (
>print_sese (dump_file, scop));
>gcc_assert (dominated_by_p (CDI_DOMINATORS, exit_bb, entry_bb));
>
> -  int depth = bb_dom_dfs_in (CDI_DOMINATORS, exit_bb)
> -- bb_dom_dfs_in (CDI_DOMINATORS, entry_bb);
> +  auto_vec worklist;
> +  auto_bitmap loops;
>
> -  gcc_assert (depth > 0);
> -
> -  vec dom
> -  = get_dominated_to_depth (CDI_DOMINATORS, entry_bb, depth);
> -  int i;
> -  basic_block bb;
> -  bitmap loops = BITMAP_ALLOC (NULL);
> -  FOR_EACH_VEC_ELT (dom, i, bb)
> +  worklist.safe_push (entry_bb);
> +  while (! worklist.is_empty ())
>  {
> +  basic_block bb = worklist.pop ();
>DEBUG_PRINT (dp << "Visiting bb_" << bb->index << "\n");
>
> -  /* We don't want to analyze any bb outside sese.  */
> -  if (!dominated_by_p (CDI_POST_DOMINATORS, bb, exit_bb))
> -   continue;
> -
> -  /* Basic blocks dominated by the scop->exit are not in the scop.  */
> -  if (bb != exit_bb && dominated_by_p (CDI_DOMINATORS, bb, exit_bb))
> -   continue;
> -
>/* The basic block should not be part of an irreducible loop.  */
>if (bb->flags & BB_IRREDUCIBLE_LOOP)
> -   {
> - dom.release ();
> - BITMAP_FREE (loops);
> - return true;
> -   }
> +   return true;
>
>/* Check for unstructured control flow: CFG not generated by structured
>  if-then-else.  */
> @@ -1114,13 +1097,14 @@ scop_detection::harmful_loop_in_region (
>  any loop fully contained in the scop: other bbs are checked below
>  in loop_is_valid_in_scop.  */
>   if (harmful_stmt_in_bb (scop, bb))
> -   {
> - dom.release ();
> - BITMAP_FREE (loops);
> - return true;
> -   }
> +   return true;
> }
>
> +  if (bb != exit_bb)
> +   for (basic_block dom = first_dom_son (CDI_DOMINATORS, bb);
> +dom;
> +dom = next_dom_son (CDI_DOMINATORS, dom))
> + worklist.safe_push (dom);
>  }
>
>/* Go through all loops and check that they are still valid in the combined
> @@ -1133,15 +1117,9 @@ scop_detection::harmful_loop_in_region (
>gcc_assert (loop->num == (int) j);
>
>if (!loop_is_valid_in_scop (loop, scop))
> -   {
> - dom.release ();
> - BITMAP_FREE (loops);
> - return true;
> -   }
> +   return true;
>  }
>
> -  dom.release ();
> -  BITMAP_FREE (loops);
>return false;
>  }
>
> Index: gcc/testsuite/gcc.dg/graphite/pr69823.c
> ===
> --- gcc/testsuite/gcc.dg/graphite/pr69823.c (nonexistent)
> +++ gcc/testsuite/gcc.dg/graphite/pr69823.c (working copy)
> @@ -0,0 +1,20 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -floop-nest-optimize" } */
> +
> +void
> +foo (int c, int *p, int *a1, int *a2, int *a3)
> +{
> +  int i;
> +
> +  if (c)
> +{
> +  for (i = 0; i < 8; i++)
> +   a1[i] = 1;
> +
> +  if (*p)
> +   *a2 = 0;
> +}
> +
> +  for (i = 0; i < 8; i++)
> +a3[i] = 0;
> +}

Re: [PATCH] gfortran -- Map REAL128 to REAL kind type with widest precision

[Steve Kargl]

On Wed, Feb 08, 2017 at 10:25:22AM +0100, FX wrote:
> Hi Steve,
> 
> I see Mikael has okayed the patch, but I did not have any
> time to comment prior. I wanted to note that:
> 
>  - the choice was deliberate, as the standard allows us to
> choose which real kind REAL128 corresponds to when there are
> several matching choices. The idea behind the current choice
> was to avoid forcing the use of slower soft-float arithmetic
> when a hardware type existed. I don’t have a strong opinion
> myself on the issue.

Yes, I considered that REAL128 would now be a software implementation.
However, as an individual who works on FreeBSD, I found it rather
unpleasing for i686-*-freebsd to map REAL128 to REAL(16) and 
x86_64-*-freebsd to map it to REAL(10).  I also considered that
some (many?, most?) users who don't look under the hood may 
expect REAL128 to map to a IEEE754 128-bit floating point entity
where it has 113 bits of precision.

>  - This is a breakage of the ABI, so we want to write it in the
> release notes, and in the doc about ISO_FORTRAN_ENV.

The 6.3 manual has 

REAL32, REAL64, REAL128:  Kind type parameters to specify a REAL
type with a storage size of 32, 64, and 128 bits.  It is negative
if a target platform does not support the particular kind.
(Fortran 2008 or later.) 

My patch does not change the above.

I'll also note that with my patch REAL128 does not change with
-m96bit-long-double, -mlong-double-64, or -mlong-double-80.  So,
the ABI is now stable.  On my x86_64-*-freebsd system, gfortran6
does not include my unpatched and gfc7 is patches.

% cat a.f90
program foo
   use iso_fortran_env
   REAL(REAL128) x
   print '(3(I0,1X))', kind(x), digits(x), precision(x)
end program foo

% gfortran6 -static -o z a.f90 && ./z
10 64 18
% gfortran6 -static -o z a.f90 -m96bit-long-double && ./z
16 113 33
% gfc7 -static -o z a.f90 && ./z
16 113 33
% gfc7 -static -o z a.f90 -m96bit-long-double && ./z
16 113 33

>  - Is this appropriate for stage 4?

I think it is appropriate as we already broke libgfortran
for 7.0.  I'll revert the patch as I can always maintain a
local patches.

-- 
Steve
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: [Patch, fortran] PR79402 - ICE with submodules: module procedure interface defined in parent module

[Paul Richard Thomas]

Dear All,

The attached rework of the patch functions in the same way as
yesterday's but is based in resolve.c rather than trans-decl.c. It
looks to me to be by far cleaner.

Bootstraps and regtests on FC23/x86_64 - OK for trunk?

Cheers

Paul

2017-02-08  Paul Thomas  

PR fortran/79344
* resolve.c (fixup_unique_dummy): New function.
(gfc_resolve_expr): Call it for dummy variables with a unique
symtree name.

2017-02-08  Paul Thomas  

PR fortran/79344
* gfortran.dg/submodule_23.f90: New test.



On 7 February 2017 at 16:06, Paul Richard Thomas
 wrote:
> Dear All,
>
> This bug generates an ICE because the symbol for dummy 'n' in the
> specification expression for the result of 'fun1' is not the same as
> the symbol in the formal arglist. For some reason that I have been
> unable to uncover, this false dummy is associated with a unique
> symtree. The odd thing is that the dump of the parse tree for the
> failing module procedure case is identical to that where the interface
> is explcitely reproduced in the submodule. The cause of the ICE is
> that the false dummy has no backend_decl as it should.
>
> This patch hits the problem directly on the head by using the
> backend_decl from the symbol in the namespace of the formal arglist,
> as described in the comment in the patch. If it is deemed to be more
> hygenic, the chunk of code can be lifted out and deposited in a
> separate function.
>
> Bootstraps and regtests on FC23/x86_64 - OK for trunk?
>
> Cheers
>
> Paul
>
> 2017-02-07  Paul Thomas  
>
> PR fortran/79344
> * trans-decl.c (gfc_get_symbol_decl): If a dummy apparently has
> a null backend_decl, look for a replacement symbol in the
> namespace of the 1st formal argument and use its backend_decl.
>
> 2017-02-07  Paul Thomas  
>
> PR fortran/79344
> * gfortran.dg/submodule_23.f90: New test.



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 245196)
--- gcc/fortran/resolve.c   (working copy)
*** gfc_is_expandable_expr (gfc_expr *e)
*** 6433,6438 
--- 6433,6463 
return false;
  }
  
+ 
+ /* Sometimes variables in specification expressions of the result
+of module procedures in submodules wind up not being the 'real'
+dummy.  Find this, if possible, in the namespace of the first
+formal argument.  */
+ 
+ static void
+ fixup_unique_dummy (gfc_expr *e)
+ {
+   gfc_symtree *st = NULL;
+   gfc_symbol *s = NULL;
+ 
+   if (e->symtree->n.sym->ns->proc_name
+   && e->symtree->n.sym->ns->proc_name->formal)
+ s = e->symtree->n.sym->ns->proc_name->formal->sym;
+ 
+   if (s != NULL)
+ st = gfc_find_symtree (s->ns->sym_root, e->symtree->n.sym->name);
+ 
+   if (st != NULL
+   && st->n.sym != NULL
+   && st->n.sym->attr.dummy)
+ e->symtree = st;
+ }
+ 
  /* Resolve an expression.  That is, make sure that types of operands agree
 with their operators, intrinsic operators are converted to function calls
 for overloaded types and unresolved function references are resolved.  */
*** gfc_resolve_expr (gfc_expr *e)
*** 6457,6462 
--- 6482,6495 
actual_arg = false;
first_actual_arg = false;
  }
+   else if (e->symtree != NULL
+  && *e->symtree->name == '@'
+  && e->symtree->n.sym->attr.dummy)
+ {
+   /* Deal with submodule specification expressions that are not
+found to be referenced in module.c(read_cleanup).  */
+   fixup_unique_dummy (e);
+ }
  
switch (e->expr_type)
  {
Index: gcc/testsuite/gfortran.dg/submodule_23.f90
===
*** gcc/testsuite/gfortran.dg/submodule_23.f90  (nonexistent)
--- gcc/testsuite/gfortran.dg/submodule_23.f90  (working copy)
***
*** 0 
--- 1,29 
+ ! { dg-do compile }
+ !
+ ! Test the fix for PR79402, in which the module procedure 'fun1' picked
+ ! up a spurious symbol for the dummy 'n' in the specification expression
+ ! for the result 'y'.
+ !
+ ! Contributed by Chris Coutinho  
+ !
+ module mod
+   interface myfun
+ module function fun1(n) result(y)
+   integer,  intent(in):: n
+   real, dimension(n)  :: y
+ end function fun1
+   end interface myfun
+ 
+ end module mod
+ 
+ submodule (mod) submod
+ contains
+   module procedure fun1
+ integer :: i
+ y = [(float (i), i = 1, n)]
+   end procedure fun1
+ end submodule
+ 
+   use mod
+   print *, fun1(10)
+ end

Re: [C++PATCH] c++/79393 virtual base of abstract class

[Nathan Sidwell]

On 02/08/2017 09:33 AM, Tim Song wrote:

On Wed, Feb 8, 2017 at 10:08 PM, Nathan Sidwell  wrote:


'potentially constructed subobject' appears to be a term without definition.


[special]/5:

For a class, its non-static data members, its non-virtual direct base
classes, and, if the class is not abstract, its virtual base classes
are called its potentially constructed subobjects.


thanks.  That suggests that this, pedantically, is not a defect.  It's 
certainly an unwelcome surprise though.


nathan

--
Nathan Sidwell

Re: [PATCH 3/5] Support WORD_REGISTER_OPERATIONS requirements in simplify_operand_subreg

[Eric Botcazou]

> This patch is a minimal change to prevent (subreg(mem)) from being
> simplified to use the outer mode for WORD_REGISTER_OPERATIONS.  There
> is high probability of refining and/or re-implementing this for GCC 8
> but such a change would be too invasive.  This change at least ensures
> correctness but may prevent simplification of some acceptable cases.

This one causes:

+FAIL: gcc.dg/torture/builtin-complex-1.c   -O3 -fomit-frame-pointer -funroll-
loops -fpeel-loops -ftracer -finline-functions  (test for excess errors)
+WARNING: gcc.dg/torture/builtin-complex-1.c   -O3 -fomit-frame-pointer -
funroll-loops -fpeel-loops -ftracer -finline-functions  compilation failed to 
produce executable
+FAIL: gcc.dg/torture/builtin-complex-1.c   -O3 -g  (test for excess errors)
+WARNING: gcc.dg/torture/builtin-complex-1.c   -O3 -g  compilation failed to 
produce executable
+WARNING: program timed out.
+WARNING: program timed out.

on SPARC 32-bit, i.e. LRA hangs.  Reduced testcase attached, compile at -O3 
with a cc1 configured for sparc-sun-solaris2.10.

> gcc/
>   PR target/78660
>   * lra-constraints.c (simplify_operand_subreg): Handle
>   WORD_REGISTER_OPERATIONS targets.
> ---
>  gcc/lra-constraints.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
> index 66ff2bb..484a70d 100644
> --- a/gcc/lra-constraints.c
> +++ b/gcc/lra-constraints.c
> @@ -1541,11 +1541,18 @@ simplify_operand_subreg (int nop, machine_mode
> reg_mode) subregs as we don't substitute such equiv memory (see processing
> equivalences in function lra_constraints) and because for spilled pseudos
> we allocate stack memory enough for the biggest
> -  corresponding paradoxical subreg.  */
> -   if (!(MEM_ALIGN (subst) < GET_MODE_ALIGNMENT (mode)
> - && SLOW_UNALIGNED_ACCESS (mode, MEM_ALIGN (subst)))
> -   || (MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (innermode)
> -   && SLOW_UNALIGNED_ACCESS (innermode, MEM_ALIGN (reg
> +  corresponding paradoxical subreg.
> +
> +  However, never simplify a (subreg (mem ...)) for
> +  WORD_REGISTER_OPERATIONS targets as this may lead to loading junk
> +  data into a register when the inner is narrower than outer or
> +  missing important data from memory when the inner is wider than
> +  outer.  */
> +   if (!WORD_REGISTER_OPERATIONS
> +   && (!(MEM_ALIGN (subst) < GET_MODE_ALIGNMENT (mode)
> + && SLOW_UNALIGNED_ACCESS (mode, MEM_ALIGN (subst)))
> +   || (MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (innermode)
> +   && SLOW_UNALIGNED_ACCESS (innermode, MEM_ALIGN 
(reg)
>   return true;
> 
> *curr_id->operand_loc[nop] = operand;

I think that we might need:

  if (!(GET_MODE_PRECISION (mode) > GET_MODE_PRECISION (innermode)
&& WORD_REGISTER_OPERATIONS)
  && (!(MEM_ALIGN (subst) < GET_MODE_ALIGNMENT (mode)
&& SLOW_UNALIGNED_ACCESS (mode, MEM_ALIGN (subst)))
  || (MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (innermode)
  && SLOW_UNALIGNED_ACCESS (innermode, MEM_ALIGN (reg)
return true;

i.e. we force the reloading only for paradoxical subregs.

-- 
Eric Botcazouextern void abort (void);

static void
comparel (long double a, long double b)
{
  long double s1 = __builtin_copysignl ((long double) 1.0, a);
  long double s2 = __builtin_copysignl ((long double) 1.0, b);

  if (s1 != s2)
abort ();
  if ((a != b) != (__builtin_isnan (a) != 0))
abort ();
}

void
comparecl (_Complex long double a, long double r, long double i)
{
  comparel (__real__ a, r);
  comparel (__imag__ a, i);
}

Re: [PATCH 1/5] Handle WORD_REGISTER_OPERATIONS when reloading (subreg(reg))

[Eric Botcazou]

>   PR target/78660
>   * lra-constraints.c (curr_insn_transform): Handle
>   WORD_REGISTER_OPERATIONS requirements when reloading SUBREGs.
> ---
>  gcc/lra-constraints.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
> index 22323b2..f29308f 100644
> --- a/gcc/lra-constraints.c
> +++ b/gcc/lra-constraints.c
> @@ -4130,7 +4130,14 @@ curr_insn_transform (bool check_only_p)
> && (goal_alt[i] == NO_REGS
> 
> || (simplify_subreg_regno
> 
> (ira_class_hard_regs[goal_alt[i]][0],
> -GET_MODE (reg), byte, mode) >= 0)
> +GET_MODE (reg), byte, mode) >= 0)))
> +   /* WORD_REGISTER_OPERATIONS targets require the 
register
> +  to be reloaded when the outer mode is strictly
> +  narrower than the inner mode.  Note: It may be
> +  necessary to always reload the inner mode here but 
it
> +  requires further investigation.  */
> +   || (GET_MODE_SIZE (mode) < GET_MODE_SIZE (GET_MODE 
(reg))
> +   && WORD_REGISTER_OPERATIONS)))
>   {
> if (type == OP_OUT)
>   type = OP_INOUT;

You want GET_MODE_PRECISION instead of GET_MODE_SIZE here.

-- 
Eric Botcazou

[gomp4] fix a reduction bug involving GOMP_MAP_FIRSTPRIVATE_POINTER variables

[Cesar Philippidis]

This patch teaches lower_oacc_reductions how to handle reduction
variables that were transferred to the accelerator via
GOMP_MAP_FIRSTPRIVATE_POINTER, e.g. fortran dummy variables. One side
effect of this change is that the ref_to_res variable gets remapped to
the (void *) field decl that gets transferred into the accelerator with
the argument struct. This happens, in part, because firstprivate_pointer
variables are remapped after the OpenACC reduction variables have been
processed. Consequently, I had to adjust the type of the ref_to_res
variable during the oaccdevlow pass.

While working on this patch I noticed that I misnamed
convert_{to,from}_firstprivate_pointer functions. Those functions cast
'scalar' values into something that can be handled as a
GOMP_MAP_FIRSTPRIVATE_INT. Therefore, I renamed those functions as
covert_{to,from}_firstprivate_int.

This patch has been applied to gomp-4_0-branch.

Cesar
2017-02-08  Cesar Philippidis  

	gcc/
	* config/nvptx/nvptx.c (nvptx_adjust_reduction_type): New function.
	(nvptx_goacc_reduction_setup): Use it to adjust the type of ref_to_res.
	(nvptx_goacc_reduction_fini): Likewise.
	(nvptx_goacc_reduction_teardown): Likewise.
	* omp-low.c (lower_oacc_reductions): Handle reduction decls mapped
	with GOMP_MAP_FIRSTPRIVATE_POINTER.
	* convert_to_firstprivate_pointer: Rename to ...
	* convert_to_firstprivate_int: ... this.
	* convert_from_firstprivate_pointer: Rename to ...
	* convert_from_firstprivate_int: ... this.
	(lower_omp_target): Update calls to convert_{to,from}_firstprivate_int.
	(default_goacc_reduction): Retype ref_to_res as necessary.

	libgomp/
	* testsuite/libgomp.oacc-fortran/reduction-9.f90: New test.


diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 4e6ed60..a9822e268 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -4794,6 +4794,23 @@ nvptx_vector_reduction (location_t loc, gimple_stmt_iterator *gsi,
   return new_var;
 }
 
+/* Dummy reduction vars that have GOMP_MAP_FIRSTPRIVATE_POINTER data
+   mappings gets retyped to (void *).  Adjust the type of VAR to TYPE
+   as appropriate.  */
+
+static tree
+nvptx_adjust_reduction_type (tree var, tree type, gimple_seq *seq)
+{
+  if (TREE_TYPE (TREE_TYPE (var)) == type)
+return var;
+
+  tree ptype = build_pointer_type (type);
+  tree t = make_ssa_name (ptype);
+  tree expr = fold_build1 (NOP_EXPR, ptype, var);
+  gimple_seq_add_stmt (seq, gimple_build_assign (t, expr));
+  return t;
+}
+
 /* NVPTX implementation of GOACC_REDUCTION_SETUP.  */
 
 static void
@@ -4813,7 +4830,11 @@ nvptx_goacc_reduction_setup (gcall *call)
   tree ref_to_res = gimple_call_arg (call, 1);
 
   if (!integer_zerop (ref_to_res))
-	var = build_simple_mem_ref (ref_to_res);
+	{
+	  ref_to_res = nvptx_adjust_reduction_type (ref_to_res, TREE_TYPE (var),
+		);
+	  var = build_simple_mem_ref (ref_to_res);
+	}
 }
   
   if (level == GOMP_DIM_WORKER)
@@ -4954,7 +4975,11 @@ nvptx_goacc_reduction_fini (gcall *call)
   else if (integer_zerop (ref_to_res))
 	r = var;
   else
-	accum = ref_to_res;
+	{
+	  ref_to_res = nvptx_adjust_reduction_type (ref_to_res, TREE_TYPE (var),
+		);
+	  accum = ref_to_res;
+	}
 
   if (accum)
 	{
@@ -5003,7 +5028,11 @@ nvptx_goacc_reduction_teardown (gcall *call)
   tree ref_to_res = gimple_call_arg (call, 1);
 
   if (!integer_zerop (ref_to_res))
-	gimplify_assign (build_simple_mem_ref (ref_to_res), var, );
+	{
+	  ref_to_res = nvptx_adjust_reduction_type (ref_to_res, TREE_TYPE (var),
+		);
+	  gimplify_assign (build_simple_mem_ref (ref_to_res), var, );
+	}
 }
 
   if (lhs)
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 450d76e..bb2d1fa 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -5818,6 +5818,7 @@ lower_oacc_reductions (location_t loc, tree clauses, tree level, bool inner,
 	tree ref_to_res = NULL_TREE;
 	tree incoming, outgoing, v1, v2, v3;
 	bool is_private = false;
+	bool is_fpp = false;
 
 	enum tree_code rcode = OMP_CLAUSE_REDUCTION_CODE (c);
 	if (rcode == MINUS_EXPR)
@@ -5876,19 +5877,37 @@ lower_oacc_reductions (location_t loc, tree clauses, tree level, bool inner,
 		  is_private = true;
 		  goto do_lookup;
 		}
+		  else if (OMP_CLAUSE_CODE (cls) == OMP_CLAUSE_MAP
+			   && (OMP_CLAUSE_MAP_KIND (cls)
+			   == GOMP_MAP_FIRSTPRIVATE_POINTER)
+			   && orig == OMP_CLAUSE_DECL (cls))
+		{
+		  is_fpp = true;
+		  goto do_lookup;
+		}
 	  }
 
 	  do_lookup:
 	/* This is the outermost construct with this reduction,
 	   see if there's a mapping for it.  */
 	if (gimple_code (outer->stmt) == GIMPLE_OMP_TARGET
-		&& maybe_lookup_field (orig, outer) && !is_private)
+		&& (maybe_lookup_field (orig, outer) || is_fpp) && !is_private)
 	  {
-		ref_to_res = build_receiver_ref (orig, false, outer);
-		if (is_reference (orig))
-		  ref_to_res = build_simple_mem_ref (ref_to_res);
-
 		tree type = TREE_TYPE (var);
+
+		if 

[PATCH] Fix PR69823

[Richard Biener]

The following fixes walking the SESE region when determining if it is 
valid.

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

Will commit as obvious once that passed.

Thanks,
Richard.

2017-02-08  Richard Biener  

PR tree-optimization/69823
* graphite-scop-detection.c (scop_detection::harmful_loop_in_region):
Properly enumerate all BBs in the region.  Use auto_vec/auto_bitmap.

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

Index: gcc/graphite-scop-detection.c
===
--- gcc/graphite-scop-detection.c   (revision 245276)
+++ gcc/graphite-scop-detection.c   (working copy)
@@ -1062,35 +1062,18 @@ scop_detection::harmful_loop_in_region (
   print_sese (dump_file, scop));
   gcc_assert (dominated_by_p (CDI_DOMINATORS, exit_bb, entry_bb));
 
-  int depth = bb_dom_dfs_in (CDI_DOMINATORS, exit_bb)
-- bb_dom_dfs_in (CDI_DOMINATORS, entry_bb);
+  auto_vec worklist;
+  auto_bitmap loops;
 
-  gcc_assert (depth > 0);
-
-  vec dom
-  = get_dominated_to_depth (CDI_DOMINATORS, entry_bb, depth);
-  int i;
-  basic_block bb;
-  bitmap loops = BITMAP_ALLOC (NULL);
-  FOR_EACH_VEC_ELT (dom, i, bb)
+  worklist.safe_push (entry_bb);
+  while (! worklist.is_empty ())
 {
+  basic_block bb = worklist.pop ();
   DEBUG_PRINT (dp << "Visiting bb_" << bb->index << "\n");
 
-  /* We don't want to analyze any bb outside sese.  */
-  if (!dominated_by_p (CDI_POST_DOMINATORS, bb, exit_bb))
-   continue;
-
-  /* Basic blocks dominated by the scop->exit are not in the scop.  */
-  if (bb != exit_bb && dominated_by_p (CDI_DOMINATORS, bb, exit_bb))
-   continue;
-
   /* The basic block should not be part of an irreducible loop.  */
   if (bb->flags & BB_IRREDUCIBLE_LOOP)
-   {
- dom.release ();
- BITMAP_FREE (loops);
- return true;
-   }
+   return true;
 
   /* Check for unstructured control flow: CFG not generated by structured
 if-then-else.  */
@@ -1114,13 +1097,14 @@ scop_detection::harmful_loop_in_region (
 any loop fully contained in the scop: other bbs are checked below
 in loop_is_valid_in_scop.  */
  if (harmful_stmt_in_bb (scop, bb))
-   {
- dom.release ();
- BITMAP_FREE (loops);
- return true;
-   }
+   return true;
}
 
+  if (bb != exit_bb)
+   for (basic_block dom = first_dom_son (CDI_DOMINATORS, bb);
+dom;
+dom = next_dom_son (CDI_DOMINATORS, dom))
+ worklist.safe_push (dom);
 }
 
   /* Go through all loops and check that they are still valid in the combined
@@ -1133,15 +1117,9 @@ scop_detection::harmful_loop_in_region (
   gcc_assert (loop->num == (int) j);
 
   if (!loop_is_valid_in_scop (loop, scop))
-   {
- dom.release ();
- BITMAP_FREE (loops);
- return true;
-   }
+   return true;
 }
 
-  dom.release ();
-  BITMAP_FREE (loops);
   return false;
 }
 
Index: gcc/testsuite/gcc.dg/graphite/pr69823.c
===
--- gcc/testsuite/gcc.dg/graphite/pr69823.c (nonexistent)
+++ gcc/testsuite/gcc.dg/graphite/pr69823.c (working copy)
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -floop-nest-optimize" } */
+
+void
+foo (int c, int *p, int *a1, int *a2, int *a3)
+{
+  int i;
+
+  if (c)
+{
+  for (i = 0; i < 8; i++)
+   a1[i] = 1;
+
+  if (*p)
+   *a2 = 0;
+}
+
+  for (i = 0; i < 8; i++)
+a3[i] = 0;
+}

Re: [C++PATCH] c++/79393 virtual base of abstract class

[Tim Song]

On Wed, Feb 8, 2017 at 10:08 PM, Nathan Sidwell  wrote:
>
> 'potentially constructed subobject' appears to be a term without definition.

[special]/5:

For a class, its non-static data members, its non-virtual direct base
classes, and, if the class is not abstract, its virtual base classes
are called its potentially constructed subobjects.

[C++PATCH] c++/79393 virtual base of abstract class

[Nathan Sidwell]

This patch fixes 79393, but I'm not 100% sure it's right.

[15.4]/8 says:
'The exception specification for an implicitly-declared destructor, or a 
destructor without a noexcept-specifier, is potentially-throwing if and 
only if any of the destructors for any of its potentially constructed 
subojects is potentially throwing.'


'potentially constructed subobject' appears to be a term without 
definition.  I have interpreted it to mean all the bases of the object, 
including virtual bases that are not deleted by a base destructor.


This we add the eh specs for both virtual and non-virtual dtors of 
virtual bases.


An alternative approach might be to just add eh specs of virtual dtors 
of virtual bases?


While working on this I discovered 79424.  In this testcase we 
synthesize A2::~A2's decl before we know A2 is abstract.  By the time we 
need its eh-spec, we have worked that out though.


Jason, wdyt?

nathan
--
Nathan Sidwell
2017-02-08  Nathan Sidwell  

	PR c++/79393
	* method.c (synthesized_method_walk): Check vbases of abstract
	classes for eh spec.

Index: cp/method.c
===
--- cp/method.c	(revision 245277)
+++ cp/method.c	(working copy)
@@ -1660,12 +1660,21 @@ synthesized_method_walk (tree ctype, spe
 /* Already examined vbases above.  */;
   else if (vec_safe_is_empty (vbases))
 /* No virtual bases to worry about.  */;
-  else if (ABSTRACT_CLASS_TYPE_P (ctype) && cxx_dialect >= cxx14)
+  else if (ABSTRACT_CLASS_TYPE_P (ctype) && cxx_dialect >= cxx14
+	   && !(sfk == sfk_destructor && spec_p))
 /* Vbase cdtors are not relevant.  */;
   else
 {
   if (constexpr_p)
 	*constexpr_p = false;
+
+  /* We might not be concerned with access, just the eh-spec for each
+	 potentially-constructed sub-object.  */
+  bool no_access_check = (cxx_dialect >= cxx14
+			  && ABSTRACT_CLASS_TYPE_P (ctype));
+  
+  if (no_access_check)
+	push_deferring_access_checks (dk_no_check);
   FOR_EACH_VEC_ELT (*vbases, i, base_binfo)
 	synthesized_method_base_walk (binfo, base_binfo, quals,
   copy_arg_p, move_p, ctor_p,
@@ -1673,6 +1682,8 @@ synthesized_method_walk (tree ctype, spe
   fnname, flags, diag,
   spec_p, trivial_p,
   deleted_p, constexpr_p);
+  if (no_access_check)
+	pop_deferring_access_checks ();
 }
 
   /* Now handle the non-static data members.  */
Index: testsuite/g++.dg/cpp1y/pr79393.C
===
--- testsuite/g++.dg/cpp1y/pr79393.C	(revision 0)
+++ testsuite/g++.dg/cpp1y/pr79393.C	(working copy)
@@ -0,0 +1,21 @@
+// { dg-do compile { target c++14 } }
+// PR c++/79393 deduced eh spec, deleted dtors and vbases
+
+struct A3;
+
+struct VDT {
+  virtual ~VDT () noexcept (false);
+};
+
+struct A1 : virtual VDT {
+  virtual void abstract () = 0;
+};
+
+struct A2 : A1 {  };
+
+struct A3 : A2 
+{
+  virtual void abstract ();
+};
+
+A3 a3;

Re: [v3 PATCH] Fix an access problem in variant.

[Jonathan Wakely]

On 08/02/17 13:56 +, Jonathan Wakely wrote:

Definitely a clang bug, see
http://melpon.org/wandbox/permlink/PkbNSpvjPrLh8rov

If we remove the nested namespace we see that the friend declaration
is declaring a second, unrelated function, and so we get an ambiguity:
http://melpon.org/wandbox/permlink/wvmzgAzpLp5pOf86



It's https://llvm.org/bugs/show_bug.cgi?id=31852

Re: [v3 PATCH] Fix an access problem in variant.

[Jonathan Wakely]

On 07/02/17 23:29 +0200, Ville Voutilainen wrote:

On 7 February 2017 at 22:00, Ville Voutilainen
 wrote:

Currently, clang rejects all attempts to visit a libstdc++ variant:
https://godbolt.org/g/kSmBTg

While gcc doesn't reject such code, that seems like an access checking
bug. This patch makes the offending _M_u member accessible for the rest
of the code.



Hmh. There's already a friend declaration for the functions that
supposedly need it. clang doesn't
seem to grok that friend declaration. gcc requires that friend
declaration, so perhaps the bug
is indeed in how clang handles friend templates.


Definitely a clang bug, see
http://melpon.org/wandbox/permlink/PkbNSpvjPrLh8rov

If we remove the nested namespace we see that the friend declaration
is declaring a second, unrelated function, and so we get an ambiguity:
http://melpon.org/wandbox/permlink/wvmzgAzpLp5pOf86

Re: [wwwdocs] Add a case to porting_to + a question wrt validity of another one

[Markus Trippelsdorf]

On 2017.02.08 at 13:56 +0100, Marek Polacek wrote:
> On Wed, Feb 08, 2017 at 12:54:44PM +0100, Markus Trippelsdorf wrote:
> > On 2017.02.08 at 12:05 +0100, Marek Polacek wrote:
> > > On Tue, Feb 07, 2017 at 04:17:48PM -0500, Jason Merrill wrote:
> > > > On Tue, Feb 7, 2017 at 9:13 AM, Jonathan Wakely  
> > > > wrote:
> > > > > On 07/02/17 15:04 +0100, Marek Polacek wrote:
> > > > >>
> > > > >> Thanks much for the review.  Looks ok now?
> > > > 
> > > > I'd suggest adding something to say that the reason these are now
> > > > being diagnosed is that G++ used to treat e.g. this->member, where
> > > > member has a non-dependent type, as type-dependent, and now it
> > > > doesn't.
> > > 
> > > Like this?
> > > 
> > > Index: porting_to.html
> > > ===
> > > RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/porting_to.html,v
> > > retrieving revision 1.5
> > > diff -u -r1.5 porting_to.html
> > > --- porting_to.html   7 Feb 2017 14:22:39 -   1.5
> > > +++ porting_to.html   8 Feb 2017 11:05:22 -
> > > @@ -52,7 +52,9 @@
> > >  
> > >  
> > >  As a consequence, the following examples are invalid and G++ will no 
> > > longer
> > > -compile them:
> > > +compile them, because, in the following examples, G++ used to treat
> > 
> > Please drop the redundant ", in the following examples".
> 
> Why?  I don't mean in generally, I only mean in in the context of those
> examples.

I'm not suggesting to drop both. But:

»As a consequence, the following examples are invalid and G++ will no
longer compile them, because, in the following examples, G++ used to...«

The second occurrence of "the following examples" doesn't add any new
meaning and is therefore redundant, because you are already referring to
"the following examples".

-- 
Markus

Re: [PATCH] Properly deprecate -fipa-cp-alignment

[Richard Biener]

On Wed, Feb 8, 2017 at 1:49 PM, Jakub Jelinek  wrote:
> On Wed, Feb 08, 2017 at 01:41:24PM +0100, Martin Jambor wrote:
>> 2017-02-08  Martin Jambor  
>>
>>   * common.opt (-finstrument-functions-exclude-file-list): Remove Var
>>   and Optimization, Document as deprecated and superseded by
>>   -fipa-bit-cp.
>>   * doc/invoke.texi (Option Summary): Remove -fipa-cp-alignment.
>>   (Optimize Options): Likewise.
>>   (-fipa-cp-alignment): Document as deprecated.
>> ---
>>  gcc/common.opt  |  4 ++--
>>  gcc/doc/invoke.texi | 11 +++
>>  2 files changed, 5 insertions(+), 10 deletions(-)
>>
>> diff --git a/gcc/common.opt b/gcc/common.opt
>> index ad6baa3db68..661235ee4a9 100644
>> --- a/gcc/common.opt
>> +++ b/gcc/common.opt
>> @@ -1612,8 +1612,8 @@ Common Report Var(flag_ipa_cp_clone) Optimization
>>  Perform cloning to make Interprocedural constant propagation stronger.
>>
>>  fipa-cp-alignment
>> -Common Report Var(flag_ipa_cp_alignment) Optimization
>> -Perform alignment discovery and propagation to make Interprocedural 
>> constant propagation stronger.
>> +Common Report
>> +This switch is deprecated.  Use -fipa-bit-cp instead.
>
> I think this should be
> Common Ignore
> Does nothing. Preserved for backward compatibility.
> instead, but Joseph is the option handling maintainer, so CCing him.

Or make it an alias for -fipa-bit-cp.

Richard.

> Jakub

Re: [wwwdocs] Add a case to porting_to + a question wrt validity of another one

[Marek Polacek]

On Wed, Feb 08, 2017 at 12:54:44PM +0100, Markus Trippelsdorf wrote:
> On 2017.02.08 at 12:05 +0100, Marek Polacek wrote:
> > On Tue, Feb 07, 2017 at 04:17:48PM -0500, Jason Merrill wrote:
> > > On Tue, Feb 7, 2017 at 9:13 AM, Jonathan Wakely  
> > > wrote:
> > > > On 07/02/17 15:04 +0100, Marek Polacek wrote:
> > > >>
> > > >> Thanks much for the review.  Looks ok now?
> > > 
> > > I'd suggest adding something to say that the reason these are now
> > > being diagnosed is that G++ used to treat e.g. this->member, where
> > > member has a non-dependent type, as type-dependent, and now it
> > > doesn't.
> > 
> > Like this?
> > 
> > Index: porting_to.html
> > ===
> > RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/porting_to.html,v
> > retrieving revision 1.5
> > diff -u -r1.5 porting_to.html
> > --- porting_to.html 7 Feb 2017 14:22:39 -   1.5
> > +++ porting_to.html 8 Feb 2017 11:05:22 -
> > @@ -52,7 +52,9 @@
> >  
> >  
> >  As a consequence, the following examples are invalid and G++ will no longer
> > -compile them:
> > +compile them, because, in the following examples, G++ used to treat
> 
> Please drop the redundant ", in the following examples".

Why?  I don't mean in generally, I only mean in in the context of those
examples.

Marek

Re: [RFA][PR tree-optimization/79095] [PATCH 1/4] Improve ranges for MINUS_EXPR and EXACT_DIV_EXPR

[Richard Biener]

On Tue, Feb 7, 2017 at 7:34 PM, Jeff Law  wrote:
> On 02/07/2017 01:39 AM, Richard Biener wrote:
>>
>> On Mon, Feb 6, 2017 at 10:57 PM, Jeff Law  wrote:
>>>
>>> On 02/06/2017 08:33 AM, Richard Biener wrote:
>>>
 ah, indeed vr0type is VR_ANTI_RANGE and yes we have the case of a
 range with an anti-range "inside".  This also covers [-1,1] v
 ~[0,0] where you choose the much larger anti-range now.  So at
 least we want to have some idea about the sizes of the ranges
 (ideally we'd choose the smaller though for most further
 propagations anti-ranges often degenerate to varying...)
>>>
>>>
>>> vr0 as an anti-singleton range like ~[0,0] is the only one likely
>>> of any interest right now and that's always going to have a range
>>> that is all but one value :-)
>>>
>>> vr1 is the tricky case.  We could do v1.max - vr1.min and if that
>>> overflows or is some "large" value (say > 65536 just to throw out a
>>> value), then we conclude creating the singleton anti-range like
>>> ~[0,0] is more useful.
>>
>>
>> Yes, but it's hard to tell.  As said, anti-ranges quickly degrade in
>> further propagation and I fear that without a better range
>> representation it's hard to do better in all cases here.
>
> All very true.  What I threw into testing overnight was the >65536
> heuristic.   While I don't expect we're going to see any testing failures, I
> also suspect we don't have a lot of cases where wide ranges are all that
> useful and even less testsuite coverage of those cases.
>
> One more targeted approach would be to *wipe* the old range when it is wide
> and we discover ~[0,0] as a new range.  We could do this just for
> EXACT_DIV_EXPR.  We'd do this much earlier than vrp_intersect so that we'd
> still have enough context to know we're dealing with EXACT_DIV_EXPR.  It's
> obviously much less likely to have side effects, but feels even more like a
> hack to me.
>
> *If* we come up with something useful, it might suggest a different approach
> to even discovering the ~[0,0] case for EXACT_DIV_EXPR.  Part of the problem
> is we have a numerator of ~[0,0].  We covert that into [MININT,-1] U
> [1,MAXINT]  Then apply the denominator's range to both generating
> [MININT/4,0] U [0, MAXINT/4], which we convert to [MININT/4,MAXINT/4]
>
> But the initial conversion of the numerator's range is imprecise for
> EXACT_DIV_EXPR.  If we mask out the low order bits at conversion time we end
> up generating the (reasonable) [MININT/4,-1] U [1,MAXINT/4].  Then we union
> those together into [MININT/4,MAXINT/4], but if we had a good heuristic we
> might be able to realize ~[0,0] is better.
>
>
>
>  The fact is
>>
>> we can't represent the result of the intersection and thus we have to
>> conservatively choose an approximation.
>
> Right.  There's no way apriori to absolutely know which range representation
> is better.  Though we have some sense that a wide range is not generally
> useful (for some definition of wide) and a singleton anti-range sometimes
> has value (because it can be used to propagate simple equivalences).  We
> could approximate the latter by looking at uses of the SSA_NAME and guess
> which of those would benefit from the propagation enabled by a singleton
> anti-range.  That sounds painful though.
>
>
>  Sometimes we have the other
>>
>> range on an SSA name and thus can use equivalences (when coming from
>> assert processing), but most of the time not and thus we can't use
>> equivalences (which use SSA name versions rather than an index into
>> a ranges array - one possible improvement to the range
>> representation).
>
> Right.
>
>  Iff ~[0,0] is useful information querying sth for
>>
>> non-null should also look at equivalences btw.
>
> ~[0,0] is primarily useful in pointer contexts -- null pointer check
> elimination and pointer arithmetic.  Outside those contexts I doubt it has
> all that much value.
>
> Sadly, I don't think we can rely on types either -- IIRC everything is
> casted to a generic integer type, so we can't key on ptrdiff_t.

Bah.

Add a nonnull_p flag to value_range ...

/me runs...

Honestly, the way to go is ditch VR_ANTI_RANGE and make value_range be

// template 
struct GTY(()) value_range
{
  enum value_range_type type;
  // The value range is the union of [ min[0], max[0] ], [ min[1], max[1] ] ...
  tree min[N];
  tree max[N];
  bitmap equiv;
};

or better use a sub-struct for the individual sub-ranges (and maybe a vec so
that the actual N is variable and we just impose an upper limit somewhere).

for the moment with fixed N == 2.  Then we can represent [MIN/4, 1] U [MAX/4, 1]
exactly.

Btw, there's always much talk about that mysterious VRP improvements by Andrew.
I hope he doesn't mind if his work gets torn apart during hypothetical
review which
usually happens if you develop stuff somewhere hidden in a dark
corner...  and yes,
I didn't want to duplicate any work and thus I refrained from doing
the above kind of
refactorings at 

Re: [PATCH] Properly deprecate -fipa-cp-alignment

[Jakub Jelinek]

On Wed, Feb 08, 2017 at 01:41:24PM +0100, Martin Jambor wrote:
> 2017-02-08  Martin Jambor  
> 
>   * common.opt (-finstrument-functions-exclude-file-list): Remove Var
>   and Optimization, Document as deprecated and superseded by
>   -fipa-bit-cp.
>   * doc/invoke.texi (Option Summary): Remove -fipa-cp-alignment.
>   (Optimize Options): Likewise.
>   (-fipa-cp-alignment): Document as deprecated.
> ---
>  gcc/common.opt  |  4 ++--
>  gcc/doc/invoke.texi | 11 +++
>  2 files changed, 5 insertions(+), 10 deletions(-)
> 
> diff --git a/gcc/common.opt b/gcc/common.opt
> index ad6baa3db68..661235ee4a9 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -1612,8 +1612,8 @@ Common Report Var(flag_ipa_cp_clone) Optimization
>  Perform cloning to make Interprocedural constant propagation stronger.
>  
>  fipa-cp-alignment
> -Common Report Var(flag_ipa_cp_alignment) Optimization
> -Perform alignment discovery and propagation to make Interprocedural constant 
> propagation stronger.
> +Common Report
> +This switch is deprecated.  Use -fipa-bit-cp instead.

I think this should be
Common Ignore
Does nothing. Preserved for backward compatibility.
instead, but Joseph is the option handling maintainer, so CCing him.

Jakub

Re: [RFA][PR tree-optimization/79095] [PATCH 1/4] Improve ranges for MINUS_EXPR and EXACT_DIV_EXPR V2

[Richard Biener]

On Tue, Feb 7, 2017 at 7:31 PM, Jeff Law  wrote:
>
> This patch addresses issues Richi raised from V1.  Specifically it moves
> EXACT_DIV_EXPR handling into extract_range_from_binary_expr_1 and less
> aggressively uses ~[0,0] when intersecting ranges -- only doing so when
> vr1's range is > 65536 elements.  That number is highly arbitrary.  I'm
> certainly open to other values, not sure if a PARAM makes sense or not, but
> can certainly do that if folks think it would be useful.  There were other
> minor nits Richi pointed out that were fixed too.
>
> Bootstrapped and regression tested as part of the full patch series.
>
> OK for the trunk?
>
>
> * tree-vrp.c (extract_range_from_binary_expr_1): For EXACT_DIV_EXPR,
> if the numerator has the range ~[0,0] make the resultant range
> ~[0,0].
> (extract_range_from_binary_expr): For MINUS_EXPR with no derived
> range,
> if the operands are known to be not equal, then the resulting range
> is ~[0,0].
> (difference_larger_than): New function.
> (intersect_ranges): If the new range is ~[0,0] and the old range is
> wide, then prefer ~[0,0].
>
> diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
> index b429217..ad8173c 100644
> --- a/gcc/tree-vrp.c
> +++ b/gcc/tree-vrp.c
> @@ -2264,6 +2264,19 @@ extract_range_from_binary_expr_1 (value_range *vr,
>if (vr0.type == VR_ANTI_RANGE
>&& ranges_from_anti_range (, , ))
>  {
> +  /* We get imprecise results from ranges_from_anti_range when
> +code is EXACT_DIV_EXPR.  We could mask out bits in the resulting
> +range, but then we also need to hack up vrp_meet.  It's just
> +easier to special case when vr0 is ~[0,0] for EXACT_DIV_EXPR.  */
> +  if (code == EXACT_DIV_EXPR
> + && vr0.type == VR_ANTI_RANGE
> + && vr0.min == vr0.max
> + && integer_zerop (vr0.min))
> +   {
> + set_value_range_to_nonnull (vr, expr_type);
> + return;
> +   }
> +

Please move this before the surrounding if.

>extract_range_from_binary_expr_1 (vr, code, expr_type, ,
> vr1_);
>if (vrtem1.type != VR_UNDEFINED)
> {
> @@ -3298,6 +3311,21 @@ extract_range_from_binary_expr (value_range *vr,
>
>extract_range_from_binary_expr_1 (vr, code, expr_type, _vr0, );
>  }
> +
> +  /* If we didn't derive a range for MINUS_EXPR, and
> + op1's range is ~[op0,op0] or vice-versa, then we
> + can derive a non-null range.  This happens often for
> + pointer subtraction.  */
> +  if (vr->type == VR_VARYING
> +  && code == MINUS_EXPR
> +  && TREE_CODE (op0) == SSA_NAME
> +  && ((vr0.type == VR_ANTI_RANGE
> +  && symbolic_range_based_on_p (, op1)

Just seeing this again this also covers ~[op1 - 1, op1 - 1] and you are
just lucky because of the vr0.min == vr0.max equality compare and
both op1 - 1 hopefully not tree-shared (I'm not confident in that...).

So I think it would be better written as simply

   && vr0.min == op1

together with vr0.min == vr0.max you'd get what you are after.

> +  && vr0.min == vr0.max)
> + || (vr1.type == VR_ANTI_RANGE
> + && symbolic_range_based_on_p (, op0)

Likewise of course.

> + && vr1.min == vr1.max)))
> +  set_value_range_to_nonnull (vr, TREE_TYPE (op0));
>  }
>
>  /* Extract range information from a unary operation CODE based on
> @@ -8448,6 +8476,17 @@ give_up:
>*vr0max = NULL_TREE;
>  }
>
> +/* Return TRUE if MAX - MIN (both trees) is larger than LIMIT
> (HOST_WIDE_INT)
> +   or overflows, FALSE otherwise.  */
> +
> +static bool
> +difference_larger_than (tree max, tree min, HOST_WIDE_INT limit)
> +{
> +  bool overflow;
> +  wide_int res = wi::sub (max, min, SIGNED, );
> +  return wi::gt_p (res, limit, UNSIGNED) || overflow;
> +}
> +
>  /* Intersect the two value-ranges { *VR0TYPE, *VR0MIN, *VR0MAX } and
> { VR1TYPE, VR0MIN, VR0MAX } and store the result
> in { *VR0TYPE, *VR0MIN, *VR0MAX }.  This may not be the smallest
> @@ -8620,6 +8659,15 @@ intersect_ranges (enum value_range_type *vr0type,
>   else if (vrp_val_is_min (vr1min)
>&& vrp_val_is_max (vr1max))
> ;
> + /* Choose the anti-range if it is ~[0,0], that range is special
> +enough to special case when vr1's range is relatively wide.  */
> + else if (*vr0type == VR_ANTI_RANGE

That's already known to be true here.

> +  && *vr0min == *vr0max
> +  && integer_zerop (*vr0min)
> +  && TREE_CODE (vr1max) == INTEGER_CST
> +  && TREE_CODE (vr1min) == INTEGER_CST
> +  && difference_larger_than (vr1max, vr1min, 65536))
> +   ;

in the case that interests us for the PR what is vr1?

>   /* Else choose the range.  */
>   else
> {
>

[PATCH] Properly deprecate -fipa-cp-alignment

[Martin Jambor]

Hi,

the patch below is my attempt at properly deprecating switch
-fipa-cp-alignment.  I have not found any clear example to follow but
hopefully I have not missed anything.  If so, please let me know.

So far I have only tested this with a normal build and "make info" but
I will give it a proper bootstrap before committing if ACKed.  OK for
trunk as it is?

Thanks,

Martin


2017-02-08  Martin Jambor  

* common.opt (-finstrument-functions-exclude-file-list): Remove Var
and Optimization, Document as deprecated and superseded by
-fipa-bit-cp.
* doc/invoke.texi (Option Summary): Remove -fipa-cp-alignment.
(Optimize Options): Likewise.
(-fipa-cp-alignment): Document as deprecated.
---
 gcc/common.opt  |  4 ++--
 gcc/doc/invoke.texi | 11 +++
 2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index ad6baa3db68..661235ee4a9 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1612,8 +1612,8 @@ Common Report Var(flag_ipa_cp_clone) Optimization
 Perform cloning to make Interprocedural constant propagation stronger.
 
 fipa-cp-alignment
-Common Report Var(flag_ipa_cp_alignment) Optimization
-Perform alignment discovery and propagation to make Interprocedural constant 
propagation stronger.
+Common Report
+This switch is deprecated.  Use -fipa-bit-cp instead.
 
 fipa-bit-cp
 Common Report Var(flag_ipa_bit_cp) Optimization
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 08d26a1d858..ba70b0f0cc7 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -371,7 +371,7 @@ Objective-C and Objective-C++ Dialects}.
 -fif-conversion2  -findirect-inlining @gol
 -finline-functions  -finline-functions-called-once  -finline-limit=@var{n} @gol
 -finline-small-functions  -fipa-cp  -fipa-cp-clone @gol
--fipa-cp-alignment  -fipa-bit-cp @gol
+-fipa-bit-cp @gol
 -fipa-pta  -fipa-profile  -fipa-pure-const  -fipa-reference  -fipa-icf @gol
 -fira-algorithm=@var{algorithm} @gol
 -fira-region=@var{region}  -fira-hoist-pressure @gol
@@ -7040,7 +7040,6 @@ also turns on the following optimization flags:
 -finline-small-functions @gol
 -findirect-inlining @gol
 -fipa-cp @gol
--fipa-cp-alignment @gol
 -fipa-bit-cp @gol
 -fipa-sra @gol
 -fipa-icf @gol
@@ -8052,12 +8051,8 @@ This flag is enabled by default at @option{-O3}.
 
 @item -fipa-cp-alignment
 @opindex -fipa-cp-alignment
-When enabled, this optimization propagates alignment of function
-parameters to support better vectorization and string operations.
-
-This flag is enabled by default at @option{-O2} and @option{-Os}.  It
-requires that @option{-fipa-cp} is enabled.
-@option{-fipa-cp-alignment} is obsolete, use @option{-fipa-bit-cp} instead.
+This option has been superseded by @option{-fipa-bit-cp} and is now
+deprecated.  Use @option{-fipa-bit-cp} instead.
 
 @item -fipa-bit-cp
 @opindex -fipa-bit-cp
-- 
2.11.0

Re: [GIMPLE FE] Handle abs_expr

[Richard Biener]

On Wed, 8 Feb 2017, Prathamesh Kulkarni wrote:

> On 8 February 2017 at 17:24, Richard Biener  wrote:
> > On Wed, 8 Feb 2017, Prathamesh Kulkarni wrote:
> >
> >> On 7 February 2017 at 20:06, Richard Biener  wrote:
> >> > On Tue, 7 Feb 2017, Prathamesh Kulkarni wrote:
> >> >
> >> >> Hi Richard,
> >> >> The attached patch tries to handle ABS_EXPR in gimple-fe.
> >> >> I am not sure if __ABS_EXPR should be parsed as id (like __MEM)
> >> >> or parse it as keyword (like __GIMPLE). Currently in the patch, I
> >> >> parse it as id.
> >> >> Patch passes gimplefe tests, is it OK to commit after bootstrap+test ?
> >> >
> >> > Few comments - the new oper_code argument to unary parsing seems
> >> > superfluous - you check the name again for __ABS_EXPR.  Also I'd
> >> > spell it __ABS, without the _EXPR part.
> >> Thanks for the suggestions. The name is not checked again for
> >> __ABS_EXPR, if oper_code is set to sth
> >> other than ERROR_MARK. oper_code is set only by c_parser_gimple_statement.
> >> However I agree it's ugly since the comparison code is placed in both
> >> the functions.
> >>
> >> In the attached patch, I changed it to __ABS and name comparison is
> >> done only within
> >> c_parser_gimple_unary_expression. However it uses an ugly hack to know
> >> it's called from
> >> c_parser_gimple_statement and then backs off from further parsing the
> >> token if it's type is
> >> CPP_NAME and value is not  "__ABS". Not sure if this is good idea either.
> >
> > I'd rather compare the name twice without any extra parameter passing.
> > As said, some bigger refactoring should be done to avoid this in the
> > future.
> Is this version OK after bootstrap+test ?

Yes.

Thanks,
Richard.

> Thanks,
> Prathamesh
> >
> > Richard.
> >
> >> Thanks,
> >> Prathamesh
> >> >
> >> > For __MEM we go to binary op parsing and then take the "not binary op"
> >> > route.  I guess some refactoring might clean up things here - not for
> >> > now though.
> >> >
> >> > I'm not sure whether new RID_ keywords would be prefered for this
> >> > kind of stuff.  We added one for __PHI.  Joseph, is the RID_ space
> >> > somehow limited so that we should avoid ending up with, say, up to
> >> > 226 RID_s for GIMPLE (upper estimate taken from the number of
> >> > tree codes we have in tree.def)?  I see currently cpplib puts
> >> > rid_code into an unsigned char and we do already seem to have quite
> >> > some of them (114 if I count correctly).
> >> >
> >> > Thanks,
> >> > Richard.
> >>
> >
> > --
> > Richard Biener 
> > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
> > 21284 (AG Nuernberg)
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [GIMPLE FE] Handle abs_expr

[Prathamesh Kulkarni]

On 8 February 2017 at 17:24, Richard Biener  wrote:
> On Wed, 8 Feb 2017, Prathamesh Kulkarni wrote:
>
>> On 7 February 2017 at 20:06, Richard Biener  wrote:
>> > On Tue, 7 Feb 2017, Prathamesh Kulkarni wrote:
>> >
>> >> Hi Richard,
>> >> The attached patch tries to handle ABS_EXPR in gimple-fe.
>> >> I am not sure if __ABS_EXPR should be parsed as id (like __MEM)
>> >> or parse it as keyword (like __GIMPLE). Currently in the patch, I
>> >> parse it as id.
>> >> Patch passes gimplefe tests, is it OK to commit after bootstrap+test ?
>> >
>> > Few comments - the new oper_code argument to unary parsing seems
>> > superfluous - you check the name again for __ABS_EXPR.  Also I'd
>> > spell it __ABS, without the _EXPR part.
>> Thanks for the suggestions. The name is not checked again for
>> __ABS_EXPR, if oper_code is set to sth
>> other than ERROR_MARK. oper_code is set only by c_parser_gimple_statement.
>> However I agree it's ugly since the comparison code is placed in both
>> the functions.
>>
>> In the attached patch, I changed it to __ABS and name comparison is
>> done only within
>> c_parser_gimple_unary_expression. However it uses an ugly hack to know
>> it's called from
>> c_parser_gimple_statement and then backs off from further parsing the
>> token if it's type is
>> CPP_NAME and value is not  "__ABS". Not sure if this is good idea either.
>
> I'd rather compare the name twice without any extra parameter passing.
> As said, some bigger refactoring should be done to avoid this in the
> future.
Is this version OK after bootstrap+test ?

Thanks,
Prathamesh
>
> Richard.
>
>> Thanks,
>> Prathamesh
>> >
>> > For __MEM we go to binary op parsing and then take the "not binary op"
>> > route.  I guess some refactoring might clean up things here - not for
>> > now though.
>> >
>> > I'm not sure whether new RID_ keywords would be prefered for this
>> > kind of stuff.  We added one for __PHI.  Joseph, is the RID_ space
>> > somehow limited so that we should avoid ending up with, say, up to
>> > 226 RID_s for GIMPLE (upper estimate taken from the number of
>> > tree codes we have in tree.def)?  I see currently cpplib puts
>> > rid_code into an unsigned char and we do already seem to have quite
>> > some of them (114 if I count correctly).
>> >
>> > Thanks,
>> > Richard.
>>
>
> --
> Richard Biener 
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
> 21284 (AG Nuernberg)
diff --git a/gcc/c/gimple-parser.c b/gcc/c/gimple-parser.c
index e167e42..681951c 100644
--- a/gcc/c/gimple-parser.c
+++ b/gcc/c/gimple-parser.c
@@ -325,6 +325,13 @@ c_parser_gimple_statement (c_parser *parser, gimple_seq 
*seq)
   /* Unary expression.  */
   switch (c_parser_peek_token (parser)->type)
 {
+case CPP_NAME:
+  {
+   tree id = c_parser_peek_token (parser)->value;
+   if (strcmp (IDENTIFIER_POINTER (id), "__ABS") == 0)
+ goto build_unary_expr;
+   break;
+  }
 case CPP_KEYWORD:
   if (c_parser_peek_token (parser)->keyword != RID_REALPART
  && c_parser_peek_token (parser)->keyword != RID_IMAGPART)
@@ -336,6 +343,7 @@ c_parser_gimple_statement (c_parser *parser, gimple_seq 
*seq)
 case CPP_COMPL:
 case CPP_NOT:
 case CPP_MULT: /* pointer deref */
+build_unary_expr:
   rhs = c_parser_gimple_unary_expression (parser);
   if (rhs.value != error_mark_node)
{
@@ -537,7 +545,7 @@ c_parser_gimple_binary_expression (c_parser *parser)
  unary-operator gimple-postfix-expression
 
unary-operator: one of
- & * + - ~
+ & * + - ~ abs_expr
 */
 
 static c_expr
@@ -599,6 +607,18 @@ c_parser_gimple_unary_expression (c_parser *parser)
default:
  return c_parser_gimple_postfix_expression (parser);
}
+case CPP_NAME:
+   {
+ tree id = c_parser_peek_token (parser)->value;
+ if (strcmp (IDENTIFIER_POINTER (id), "__ABS") == 0)
+   {
+ c_parser_consume_token (parser);
+ op = c_parser_gimple_postfix_expression (parser);
+ return parser_build_unary_op (op_loc, ABS_EXPR, op);
+   }
+ else
+   return c_parser_gimple_postfix_expression (parser);
+   }
 default:
   return c_parser_gimple_postfix_expression (parser);
 }
diff --git a/gcc/gimple-pretty-print.c b/gcc/gimple-pretty-print.c
index 91c839d..0033e97 100644
--- a/gcc/gimple-pretty-print.c
+++ b/gcc/gimple-pretty-print.c
@@ -323,9 +323,17 @@ dump_unary_rhs (pretty_printer *buffer, gassign *gs, int 
spc, int flags)
   break;
 
 case ABS_EXPR:
-  pp_string (buffer, "ABS_EXPR <");
-  dump_generic_node (buffer, rhs, spc, flags, false);
-  pp_greater (buffer);
+  if (flags & TDF_GIMPLE)
+   {
+ pp_string (buffer, "__ABS ");
+ dump_generic_node (buffer, rhs, spc, flags, false);
+   }
+  else
+   {
+ pp_string (buffer, "ABS_EXPR <");
+ 

[PATCH] Update links and references in libstdc++ manual

[Jonathan Wakely]

This fixes a number of links that Gerald pointed out are either
redirecting or broken.

* doc/xml/manual/policy_data_structures.xml: Fix spelling of author's
name.
* doc/xml/manual/policy_data_structures_biblio.xml: Likewise. Remove
broken links to texts that are no longer online.
* doc/xml/manual/profile_mode.xml: Update links to CGO 2009 paper and
LCPC 2006 paper.
* doc/xml/manual/using.xml: Update links to memory model information.
* doc/xml/manual/using_exceptions.xml: Update link to "Appendix E:
Standard-Library Exception Safety".
* doc/html/*: Regenerate.

Committing to trunk.

commit bfa5151177d3c8bb4892534b00393fc3b0dd6e8c
Author: Jonathan Wakely 
Date:   Wed Feb 8 12:01:18 2017 +

Update links and references in libstdc++ manual

* doc/xml/manual/policy_data_structures.xml: Fix spelling of author's
name.
* doc/xml/manual/policy_data_structures_biblio.xml: Likewise. Remove
broken links to texts that are no longer online.
* doc/xml/manual/profile_mode.xml: Update links to CGO 2009 paper and
LCPC 2006 paper.
* doc/xml/manual/using.xml: Update links to memory model information.
* doc/xml/manual/using_exceptions.xml: Update link to "Appendix E:
Standard-Library Exception Safety".
* doc/html/*: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/policy_data_structures.xml 
b/libstdc++-v3/doc/xml/manual/policy_data_structures.xml
index 4de8236..dca958c 100644
--- a/libstdc++-v3/doc/xml/manual/policy_data_structures.xml
+++ b/libstdc++-v3/doc/xml/manual/policy_data_structures.xml
@@ -4719,7 +4719,7 @@
an underlying pairing heap (),
binary heap (),
binomial heap (),
-   a binomial heap with a redundant binary counter (),
+   a binomial heap with a redundant binary counter (),
or a thin heap ().

 
diff --git a/libstdc++-v3/doc/xml/manual/policy_data_structures_biblio.xml 
b/libstdc++-v3/doc/xml/manual/policy_data_structures_biblio.xml
index 3c4c320..16b73d6 100644
--- a/libstdc++-v3/doc/xml/manual/policy_data_structures_biblio.xml
+++ b/libstdc++-v3/doc/xml/manual/policy_data_structures_biblio.xml
@@ -892,12 +892,9 @@
 
 
 
-
+
   
-   http://www.w3.org/1999/xlink;
- 
xlink:href="http://magic.aladdin.cs.cmu.edu/2005/08/01/deamortization-part-2-binomial-heaps/;>
- Deamortization - Part 2: Binomial Heaps
-   
+   Deamortization - Part 2: Binomial Heaps
   
   
2005
@@ -906,7 +903,7 @@
   

  
-   Maverik
+   Maverick
  
  
Woo
@@ -1422,10 +1419,7 @@
 
 
   
-   http://www.w3.org/1999/xlink;
- 
xlink:href="http://myweb.wvnet.edu/~gsa00121/books/amongdead30.zip;>
- Thirty Years Among the Dead
-   
+   Thirty Years Among the Dead
   
   
1996
diff --git a/libstdc++-v3/doc/xml/manual/profile_mode.xml 
b/libstdc++-v3/doc/xml/manual/profile_mode.xml
index ae846d9..39c176b 100644
--- a/libstdc++-v3/doc/xml/manual/profile_mode.xml
+++ b/libstdc++-v3/doc/xml/manual/profile_mode.xml
@@ -25,9 +25,9 @@
   calls to an instrumentation library to record the internal state of
   various components at interesting entry/exit points to/from the standard
   library.  Process trace, recognize suboptimal patterns, give advice.
-  For details, see
-  http://www.w3.org/1999/xlink; 
xlink:href="http://dx.doi.org/10.1109/CGO.2009.36;>paper presented at
-   CGO 2009.
+  For details, see the
+  http://www.w3.org/1999/xlink; 
xlink:href="http://http://ieeexplore.ieee.org/document/4907670/;>Perflint
+  paper presented at CGO 2009.
   
   
   Strengths: 
@@ -1509,8 +1509,8 @@ foo.cc:7: advice: Insert prefetch instruction.
   Fundamentals:Allocation can be tuned
   to a specific traversal pattern, to result in better data locality.
   See paper:
-  http://www.w3.org/1999/xlink; 
xlink:href="http://www.springerlink.com/content/8085744l00x72662/;>
-  Custom Memory Allocation for Free.
+  http://www.w3.org/1999/xlink; 
xlink:href="https://parasol.tamu.edu/publications/download.php?file_id=570;>
+  Custom Memory Allocation for Free by Jula and Rauchwerger.
   
   Sample runtime reduction:30%.
   
diff --git a/libstdc++-v3/doc/xml/manual/using.xml 
b/libstdc++-v3/doc/xml/manual/using.xml
index c06ce16..1970845 100644
--- a/libstdc++-v3/doc/xml/manual/using.xml
+++ b/libstdc++-v3/doc/xml/manual/using.xml
@@ -1624,9 +1624,9 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
   
 
   For further details of the C++11 memory model see Hans-J. Boehm's
-  http://www.w3.org/1999/xlink; 
xlink:href="http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/user-faq.html;>Threads
+  http://www.w3.org/1999/xlink; 
xlink:href="https://www.hboehm.info/c++mm/;>Threads
   and memory model for C++ pages, particularly the 

Re: [wwwdocs] Add a case to porting_to + a question wrt validity of another one

[Markus Trippelsdorf]

On 2017.02.08 at 12:05 +0100, Marek Polacek wrote:
> On Tue, Feb 07, 2017 at 04:17:48PM -0500, Jason Merrill wrote:
> > On Tue, Feb 7, 2017 at 9:13 AM, Jonathan Wakely  wrote:
> > > On 07/02/17 15:04 +0100, Marek Polacek wrote:
> > >>
> > >> Thanks much for the review.  Looks ok now?
> > 
> > I'd suggest adding something to say that the reason these are now
> > being diagnosed is that G++ used to treat e.g. this->member, where
> > member has a non-dependent type, as type-dependent, and now it
> > doesn't.
> 
> Like this?
> 
> Index: porting_to.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/porting_to.html,v
> retrieving revision 1.5
> diff -u -r1.5 porting_to.html
> --- porting_to.html   7 Feb 2017 14:22:39 -   1.5
> +++ porting_to.html   8 Feb 2017 11:05:22 -
> @@ -52,7 +52,9 @@
>  
>  
>  As a consequence, the following examples are invalid and G++ will no longer
> -compile them:
> +compile them, because, in the following examples, G++ used to treat

Please drop the redundant ", in the following examples".

> +this->member where member has a non-dependent type, as
> +type-dependent, and now it doesn't.
>  
>  
>  
> 
>   Marek
> 

-- 
Markus

Re: [GIMPLE FE] Handle abs_expr

[Richard Biener]

On Wed, 8 Feb 2017, Prathamesh Kulkarni wrote:

> On 7 February 2017 at 20:06, Richard Biener  wrote:
> > On Tue, 7 Feb 2017, Prathamesh Kulkarni wrote:
> >
> >> Hi Richard,
> >> The attached patch tries to handle ABS_EXPR in gimple-fe.
> >> I am not sure if __ABS_EXPR should be parsed as id (like __MEM)
> >> or parse it as keyword (like __GIMPLE). Currently in the patch, I
> >> parse it as id.
> >> Patch passes gimplefe tests, is it OK to commit after bootstrap+test ?
> >
> > Few comments - the new oper_code argument to unary parsing seems
> > superfluous - you check the name again for __ABS_EXPR.  Also I'd
> > spell it __ABS, without the _EXPR part.
> Thanks for the suggestions. The name is not checked again for
> __ABS_EXPR, if oper_code is set to sth
> other than ERROR_MARK. oper_code is set only by c_parser_gimple_statement.
> However I agree it's ugly since the comparison code is placed in both
> the functions.
> 
> In the attached patch, I changed it to __ABS and name comparison is
> done only within
> c_parser_gimple_unary_expression. However it uses an ugly hack to know
> it's called from
> c_parser_gimple_statement and then backs off from further parsing the
> token if it's type is
> CPP_NAME and value is not  "__ABS". Not sure if this is good idea either.

I'd rather compare the name twice without any extra parameter passing.
As said, some bigger refactoring should be done to avoid this in the
future.

Richard.

> Thanks,
> Prathamesh
> >
> > For __MEM we go to binary op parsing and then take the "not binary op"
> > route.  I guess some refactoring might clean up things here - not for
> > now though.
> >
> > I'm not sure whether new RID_ keywords would be prefered for this
> > kind of stuff.  We added one for __PHI.  Joseph, is the RID_ space
> > somehow limited so that we should avoid ending up with, say, up to
> > 226 RID_s for GIMPLE (upper estimate taken from the number of
> > tree codes we have in tree.def)?  I see currently cpplib puts
> > rid_code into an unsigned char and we do already seem to have quite
> > some of them (114 if I count correctly).
> >
> > Thanks,
> > Richard.
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [ GIMPLE FE] replace calls to c_parser_gimple_unary_expression by c_parser_gimple_postfix_expression

[Prathamesh Kulkarni]

On 8 February 2017 at 17:18, Prathamesh Kulkarni
 wrote:
> Hi,
> The attached patch replaces couple of calls to 
> c_parser_gimple_unary_expression
> by c_parser_gimple_postfix_expression, to reject invalid cases like:
> ~t0_1 = ~a;
> OK to commit after bootstrap+test ?
Oops no, this would reject valid cases like: *p = rhs.
>
> Thanks,
> Prathamesh

[ GIMPLE FE] replace calls to c_parser_gimple_unary_expression by c_parser_gimple_postfix_expression

[Prathamesh Kulkarni]

Hi,
The attached patch replaces couple of calls to c_parser_gimple_unary_expression
by c_parser_gimple_postfix_expression, to reject invalid cases like:
~t0_1 = ~a;
OK to commit after bootstrap+test ?

Thanks,
Prathamesh
diff --git a/gcc/c/gimple-parser.c b/gcc/c/gimple-parser.c
index 942597a..00809a5 100644
--- a/gcc/c/gimple-parser.c
+++ b/gcc/c/gimple-parser.c
@@ -268,7 +268,7 @@ c_parser_gimple_statement (c_parser *parser, gimple_seq 
*seq)
   tree arg = NULL_TREE;
   auto_vec vargs;
 
-  lhs = c_parser_gimple_unary_expression (parser);
+  lhs = c_parser_gimple_postfix_expression (parser);
   loc = EXPR_LOCATION (lhs.value);
   rhs.value = error_mark_node;
 
@@ -403,7 +403,7 @@ c_parser_gimple_statement (c_parser *parser, gimple_seq 
*seq)
   && c_parser_peek_2nd_token (parser)->type == CPP_OPEN_PAREN
   && lookup_name (c_parser_peek_token (parser)->value))
 {
-  rhs = c_parser_gimple_unary_expression (parser);
+  rhs = c_parser_gimple_postfix_expression (parser);
   if (rhs.value != error_mark_node)
{
  gimple *call = gimple_build_call_from_tree (rhs.value);

Re: [PATCH v5] add -fprolog-pad=N,M option

[Jakub Jelinek]

On Wed, Feb 08, 2017 at 12:18:05PM +0100, Torsten Duwe wrote:
> On Mon, Jan 23, 2017 at 05:25:45PM +0100, Bernd Schmidt wrote:
> > There's still a a few details that need addressing, and some questions I
> > have. Also Ccing Jakub to have another pair of eyes on the name of the
> > section - I don't know if we want some sort of .gnu.something name.
> 
> So Jakub, Richard E., what's the outcome?
> 
> Is this all the feedback the "gcc developers" will provide? Bernd, don't
> get me wrong, I also consider it important to watch the coding style in a 
> project, I've seen cases were nobody cared ... not good.
> 
> But OTOH some of the code you rightfully criticised in the previous run
> just went away after some smart feedback from Richard Biener (thanks!);
> I'd rather sort out the design issues first before I polish the code.
> 
> So, can I please have a statement from a responsible maintainer (if such
> a person really exists for this area) about whether this feature would be
> acceptable at all?

First of all, GCC is in stage4 and this isn't a fix for a regression, so it
is not acceptable at this point.  Next stage1 will start in April or so.
Second thing that is questionable is what units are the arguments of the
option or attribute.
+  if (record_p)
   
+fprintf (file, "1:");  
   
+   
   
+  unsigned i;  
   
+  for (i = 0; i < pad_size; ++i)   
   
+fprintf (file, "\tnop\n"); 
   
+   
   
+  if (record_p)
   
+{  
   
+  fprintf (file, "\t.section __prolog_pads_loc, \"a\",@progbits\n");   
   
+  fprintf (file, "\t.quad 1b\n");  
   
+  fprintf (file, "\t.previous\n"); 
   
+}  
   
suggests that it is at least by default the number of nops, whatever that
means.  The length of nop varies greatly across different architectures,
some architectures have different spelling for it (e.g.
ia64, s390{,x} use nop 0 and mmix uses swym 0), some architectures have
tons of different nops with different sizes (see e.g. x86_64/i686), for some
longer sizes it is often beneficial to emit a jump around the rest of nops
instead of just tons of nops.

Even if it is counted always in nops and only nops are emitted (not really
efficient, and I guess kernel cares about efficiency), the above is
definitely not acceptable for a generic hook implementation, it contains too
many ELF specific details as well as 64-bit target specific details etc.
For the label, you should use something like:
  static int ppad_no;
  char tmp_label[...];
  ASM_GENERATE_INTERNAL_LABEL (tmp_label, "LPPAD", ppad_no);
  ppad_no++;
  ASM_OUTPUT_LABEL (file, tmp_label);
the "a",@progbits is not generic enough, you want
  switch_to_section (get_section ("__prolog_pads_loc", 0, NULL));
or so.  .previous doesn't work on many targets, you need to actuall switch
to the previously current section.  .quad is not supported by many
assemblers, you want assemble_integer, with the appropriate size (say
derived from size of pointer), decide whether in that section everything is
aligned or unaligned, emit aligning directive if the former.

> I thought that was obvious, sorry. Instrumentation / profiling will need
> some registers, and live patching (the current use case) may allocate
> different registers for the replacement functions. You will probably want
> to replace the NOPs with a standardised code snippet etc. Conclusion: do not
> make any assumptions about callee's register utilisation and strictly stick
> to 

Re: [wwwdocs] RISC-V readings and features

[Gerald Pfeifer]

Hi Palmer,

On Tue, 7 Feb 2017, Palmer Dabbelt wrote:
> These were suggested as part of our review process, but I never got an 
> OK on them.  Am I meant to just commit these?

I am pretty sure I acked htdocs/readings.html (see the mail below).

backends.html I am not sufficiently knowledgable, but since we trust
you to maintain the port, it makes sense to trust you to describe the
port's characteristics, too. ;-)

So, both are okay.

Thanks,
Gerald

 forwarded message 
From: Gerald Pfeifer 
To: Palmer Dabbelt 
Cc: jos...@codesourcery.com, gcc-patches@gcc.gnu.org
Date: Fri, 3 Feb 2017 22:55:05 +0100 (CET)
Subject: Re: New Port for RISC-V v2

On Fri, 3 Feb 2017, Palmer Dabbelt wrote:
> How do these look?

Fine for readings.html.  backends.html, not my cup of tea. ;-)

Gerald

Re: [PATCH v5] add -fprolog-pad=N,M option

[Torsten Duwe]

On Mon, Jan 23, 2017 at 05:25:45PM +0100, Bernd Schmidt wrote:
> There's still a a few details that need addressing, and some questions I
> have. Also Ccing Jakub to have another pair of eyes on the name of the
> section - I don't know if we want some sort of .gnu.something name.

So Jakub, Richard E., what's the outcome?

Is this all the feedback the "gcc developers" will provide? Bernd, don't
get me wrong, I also consider it important to watch the coding style in a 
project, I've seen cases were nobody cared ... not good.

But OTOH some of the code you rightfully criticised in the previous run
just went away after some smart feedback from Richard Biener (thanks!);
I'd rather sort out the design issues first before I polish the code.

So, can I please have a statement from a responsible maintainer (if such
a person really exists for this area) about whether this feature would be
acceptable at all?

Thank you very much in advance.

> >diff --git a/gcc/testsuite/c-c++-common/attribute-prolog_pad-1.c 
> >b/gcc/testsuite/c-c++-common/attribute-prolog_pad-1.c
> >new file mode 100644
> >index 000..2236aa8
> >--- /dev/null
> >+++ b/gcc/testsuite/c-c++-common/attribute-prolog_pad-1.c
> >@@ -0,0 +1,34 @@
> >+/* { dg-do compile } */
> >+/* { dg-options "-fprolog-pad=3,1" } */
> 
> This test does not actually seem to verify that the padding has the expected
> size.

Honestly, I do not know how to complete that test case, this is a mere sketch.
Shame on me I'm really not familiar with that framework; suggestions welcome.

> >  /* Do not use IPA optimizations for register allocation if profiler is 
> > active
> >+or prolog pads are inserted for run-time instrumentation
> > or port does not emit prologue and epilogue as RTL.  */
> >-  if (profile_flag || !targetm.have_prologue () || !targetm.have_epilogue 
> >())
> >+  if (profile_flag || prolog_nop_pad_size
> >+  || !targetm.have_prologue () || !targetm.have_epilogue ())
> > flag_ipa_ra = 0;
> 
> Was this explained? Why would ipa-ra be a problem?

I thought that was obvious, sorry. Instrumentation / profiling will need
some registers, and live patching (the current use case) may allocate
different registers for the replacement functions. You will probably want
to replace the NOPs with a standardised code snippet etc. Conclusion: do not
make any assumptions about callee's register utilisation and strictly stick
to the ABI! I remember to have discussed this, maybe not here.

Torsten

Re: [libstdc++,PATCH] src/c++11/snprintf_lite.cc - update bug reporting URL

[Jonathan Wakely]

On 08/02/17 12:02 +0100, Jakub Jelinek wrote:

On Wed, Feb 08, 2017 at 10:58:20AM +, Jonathan Wakely wrote:

On 08/02/17 11:50 +0100, Jakub Jelinek wrote:
> On Wed, Feb 08, 2017 at 10:42:58AM +, Jonathan Wakely wrote:
> > On 08/02/17 08:17 +0100, Gerald Pfeifer wrote:
> > > Index: src/c++11/snprintf_lite.cc
> > > ===
> > > --- src/c++11/snprintf_lite.cc   (revision 245267)
> > > +++ src/c++11/snprintf_lite.cc   (working copy)
> > > @@ -52,7 +52,7 @@
> > > const size_t __len = __bufend - __buf + 1;
> > >
> > > const char __err[] = "not enough space for format expansion "
> > > -  "(Please submit full bug report at http://gcc.gnu.org/bugs.html):\n
";
> > > +  "(Please submit full bug report at http://gcc.gnu.org/bugs/):\n
";
> > > const size_t __errlen = sizeof(__err) - 1;
> > >
> > > char *const __e
> >
> > Shouldn't that be https ? :-)
> >
> > I'd welcome better suggestions for how to deal with this error
> > condition (which should never happen) but I can't think of any myself.
>
> ACX_BUGURL([https://gcc.gnu.org/bugs/])
> in configure.ac and then use REPORT_BUGS_TO in the Makefile?
>
> Note ACX_BUGURL in gcc/configure.ac needs adjustments too.

Do we need to worry about an arbitrarily long bugurl causing the
alloca to fail?


I wouldn't, people who configure with 256KB long --with-bugurl arguments
should be adequately punished.


Works for me :-)

This is now https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79422

[PATCH] asan: fix missing include of signal.h

[Rolf Eike Beer]

From 205aa8e97bab553e5e6fe45896325e97962de704 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer 
Date: Wed, 8 Feb 2017 11:42:52 +0100
Subject: [PATCH] asan: fix missing include of signal.h

This breaks when building gcc 5.4.0 with 
target_platform=powerpc-unknown-linux-gnu with glibc 2.25:

../../../../gcc-host/libsanitizer/asan/asan_linux.cc: In function 'bool 
__asan::AsanInterceptsSignal(int)':
../../../../gcc-host/libsanitizer/asan/asan_linux.cc:222:20: error: 'SIGSEGV' 
was not declared in this scope
   return signum == SIGSEGV && common_flags()->handle_segv;

This applies only to gcc-5-branch, the code has been reworked for gcc 6.
---
 libsanitizer/asan/asan_linux.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libsanitizer/asan/asan_linux.cc b/libsanitizer/asan/asan_linux.cc
index c504168..59087b9 100644
--- a/libsanitizer/asan/asan_linux.cc
+++ b/libsanitizer/asan/asan_linux.cc
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.8.3

-- 
Besuchen Sie uns auf der Embedded World 2017 in Nürnberg!
-> Halle 4, Stand 368

Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Bertha-von-Suttner-Str. 9, 37085 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix – smart embedded open source

Re: [GIMPLE FE] Handle abs_expr

[Prathamesh Kulkarni]

On 7 February 2017 at 20:06, Richard Biener  wrote:
> On Tue, 7 Feb 2017, Prathamesh Kulkarni wrote:
>
>> Hi Richard,
>> The attached patch tries to handle ABS_EXPR in gimple-fe.
>> I am not sure if __ABS_EXPR should be parsed as id (like __MEM)
>> or parse it as keyword (like __GIMPLE). Currently in the patch, I
>> parse it as id.
>> Patch passes gimplefe tests, is it OK to commit after bootstrap+test ?
>
> Few comments - the new oper_code argument to unary parsing seems
> superfluous - you check the name again for __ABS_EXPR.  Also I'd
> spell it __ABS, without the _EXPR part.
Thanks for the suggestions. The name is not checked again for
__ABS_EXPR, if oper_code is set to sth
other than ERROR_MARK. oper_code is set only by c_parser_gimple_statement.
However I agree it's ugly since the comparison code is placed in both
the functions.

In the attached patch, I changed it to __ABS and name comparison is
done only within
c_parser_gimple_unary_expression. However it uses an ugly hack to know
it's called from
c_parser_gimple_statement and then backs off from further parsing the
token if it's type is
CPP_NAME and value is not  "__ABS". Not sure if this is good idea either.

Thanks,
Prathamesh
>
> For __MEM we go to binary op parsing and then take the "not binary op"
> route.  I guess some refactoring might clean up things here - not for
> now though.
>
> I'm not sure whether new RID_ keywords would be prefered for this
> kind of stuff.  We added one for __PHI.  Joseph, is the RID_ space
> somehow limited so that we should avoid ending up with, say, up to
> 226 RID_s for GIMPLE (upper estimate taken from the number of
> tree codes we have in tree.def)?  I see currently cpplib puts
> rid_code into an unsigned char and we do already seem to have quite
> some of them (114 if I count correctly).
>
> Thanks,
> Richard.
diff --git a/gcc/c/gimple-parser.c b/gcc/c/gimple-parser.c
index e167e42..942597a 100644
--- a/gcc/c/gimple-parser.c
+++ b/gcc/c/gimple-parser.c
@@ -61,7 +61,7 @@ static bool c_parser_gimple_compound_statement (c_parser *, 
gimple_seq *);
 static void c_parser_gimple_label (c_parser *, gimple_seq *);
 static void c_parser_gimple_statement (c_parser *, gimple_seq *);
 static struct c_expr c_parser_gimple_binary_expression (c_parser *);
-static struct c_expr c_parser_gimple_unary_expression (c_parser *);
+static struct c_expr c_parser_gimple_unary_expression (c_parser *, bool 
called_from_stmt_parser = false);
 static struct c_expr c_parser_gimple_postfix_expression (c_parser *);
 static struct c_expr c_parser_gimple_postfix_expression_after_primary 
(c_parser *,
   
location_t,
@@ -323,7 +323,8 @@ c_parser_gimple_statement (c_parser *parser, gimple_seq 
*seq)
 }
 
   /* Unary expression.  */
-  switch (c_parser_peek_token (parser)->type)
+  enum cpp_ttype toktype = c_parser_peek_token (parser)->type;
+  switch (toktype)
 {
 case CPP_KEYWORD:
   if (c_parser_peek_token (parser)->keyword != RID_REALPART
@@ -336,7 +337,12 @@ c_parser_gimple_statement (c_parser *parser, gimple_seq 
*seq)
 case CPP_COMPL:
 case CPP_NOT:
 case CPP_MULT: /* pointer deref */
-  rhs = c_parser_gimple_unary_expression (parser);
+case CPP_NAME:
+  rhs = c_parser_gimple_unary_expression (parser, true);
+  if (toktype == CPP_NAME
+ && rhs.value == NULL)
+   break;
+
   if (rhs.value != error_mark_node)
{
  assign = gimple_build_assign (lhs.value, rhs.value);
@@ -537,11 +543,11 @@ c_parser_gimple_binary_expression (c_parser *parser)
  unary-operator gimple-postfix-expression
 
unary-operator: one of
- & * + - ~
+ & * + - ~ abs_expr
 */
 
 static c_expr
-c_parser_gimple_unary_expression (c_parser *parser)
+c_parser_gimple_unary_expression (c_parser *parser, bool 
called_from_stmt_parser)
 {
   struct c_expr ret, op;
   location_t op_loc = c_parser_peek_token (parser)->location;
@@ -599,6 +606,23 @@ c_parser_gimple_unary_expression (c_parser *parser)
default:
  return c_parser_gimple_postfix_expression (parser);
}
+case CPP_NAME:
+   {
+ tree id = c_parser_peek_token (parser)->value;
+ if (strcmp (IDENTIFIER_POINTER (id), "__ABS") == 0)
+   {
+ c_parser_consume_token (parser);
+ op = c_parser_gimple_postfix_expression (parser);
+ return parser_build_unary_op (op_loc, ABS_EXPR, op);
+   }
+ else if (called_from_stmt_parser)
+   {
+ ret.value = NULL;
+ return ret;
+   }
+ else
+   return c_parser_gimple_postfix_expression (parser);
+   }
 default:
   return c_parser_gimple_postfix_expression (parser);
 }
diff --git a/gcc/gimple-pretty-print.c b/gcc/gimple-pretty-print.c
index 91c839d..0033e97 100644
--- a/gcc/gimple-pretty-print.c
+++ b/gcc/gimple-pretty-print.c
@@ -323,9 +323,17 @@ 

Re: [wwwdocs] Add a case to porting_to + a question wrt validity of another one

[Marek Polacek]

On Tue, Feb 07, 2017 at 04:17:48PM -0500, Jason Merrill wrote:
> On Tue, Feb 7, 2017 at 9:13 AM, Jonathan Wakely  wrote:
> > On 07/02/17 15:04 +0100, Marek Polacek wrote:
> >>
> >> Thanks much for the review.  Looks ok now?
> 
> I'd suggest adding something to say that the reason these are now
> being diagnosed is that G++ used to treat e.g. this->member, where
> member has a non-dependent type, as type-dependent, and now it
> doesn't.

Like this?

Index: porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/porting_to.html,v
retrieving revision 1.5
diff -u -r1.5 porting_to.html
--- porting_to.html 7 Feb 2017 14:22:39 -   1.5
+++ porting_to.html 8 Feb 2017 11:05:22 -
@@ -52,7 +52,9 @@
 
 
 As a consequence, the following examples are invalid and G++ will no longer
-compile them:
+compile them, because, in the following examples, G++ used to treat
+this->member where member has a non-dependent type, as
+type-dependent, and now it doesn't.
 
 
 

Marek

Re: [libstdc++,PATCH] src/c++11/snprintf_lite.cc - update bug reporting URL

[Jakub Jelinek]

On Wed, Feb 08, 2017 at 10:58:20AM +, Jonathan Wakely wrote:
> On 08/02/17 11:50 +0100, Jakub Jelinek wrote:
> > On Wed, Feb 08, 2017 at 10:42:58AM +, Jonathan Wakely wrote:
> > > On 08/02/17 08:17 +0100, Gerald Pfeifer wrote:
> > > > Index: src/c++11/snprintf_lite.cc
> > > > ===
> > > > --- src/c++11/snprintf_lite.cc  (revision 245267)
> > > > +++ src/c++11/snprintf_lite.cc  (working copy)
> > > > @@ -52,7 +52,7 @@
> > > > const size_t __len = __bufend - __buf + 1;
> > > >
> > > > const char __err[] = "not enough space for format expansion "
> > > > -  "(Please submit full bug report at 
> > > > http://gcc.gnu.org/bugs.html):\n";
> > > > +  "(Please submit full bug report at http://gcc.gnu.org/bugs/):\n  
> > > >   ";
> > > > const size_t __errlen = sizeof(__err) - 1;
> > > >
> > > > char *const __e
> > > 
> > > Shouldn't that be https ? :-)
> > > 
> > > I'd welcome better suggestions for how to deal with this error
> > > condition (which should never happen) but I can't think of any myself.
> > 
> > ACX_BUGURL([https://gcc.gnu.org/bugs/])
> > in configure.ac and then use REPORT_BUGS_TO in the Makefile?
> > 
> > Note ACX_BUGURL in gcc/configure.ac needs adjustments too.
> 
> Do we need to worry about an arbitrarily long bugurl causing the
> alloca to fail?

I wouldn't, people who configure with 256KB long --with-bugurl arguments
should be adequately punished.

Jakub

Re: [libstdc++,PATCH] src/c++11/snprintf_lite.cc - update bug reporting URL

[Jonathan Wakely]

On 08/02/17 11:50 +0100, Jakub Jelinek wrote:

On Wed, Feb 08, 2017 at 10:42:58AM +, Jonathan Wakely wrote:

On 08/02/17 08:17 +0100, Gerald Pfeifer wrote:
> Index: src/c++11/snprintf_lite.cc
> ===
> --- src/c++11/snprintf_lite.cc (revision 245267)
> +++ src/c++11/snprintf_lite.cc (working copy)
> @@ -52,7 +52,7 @@
> const size_t __len = __bufend - __buf + 1;
>
> const char __err[] = "not enough space for format expansion "
> -  "(Please submit full bug report at http://gcc.gnu.org/bugs.html):\n
";
> +  "(Please submit full bug report at http://gcc.gnu.org/bugs/):\n";
> const size_t __errlen = sizeof(__err) - 1;
>
> char *const __e

Shouldn't that be https ? :-)

I'd welcome better suggestions for how to deal with this error
condition (which should never happen) but I can't think of any myself.


ACX_BUGURL([https://gcc.gnu.org/bugs/])
in configure.ac and then use REPORT_BUGS_TO in the Makefile?

Note ACX_BUGURL in gcc/configure.ac needs adjustments too.


Do we need to worry about an arbitrarily long bugurl causing the
alloca to fail?

Re: [libstdc++,PATCH] src/c++11/snprintf_lite.cc - update bug reporting URL

[Jakub Jelinek]

On Wed, Feb 08, 2017 at 10:42:58AM +, Jonathan Wakely wrote:
> On 08/02/17 08:17 +0100, Gerald Pfeifer wrote:
> > Index: src/c++11/snprintf_lite.cc
> > ===
> > --- src/c++11/snprintf_lite.cc  (revision 245267)
> > +++ src/c++11/snprintf_lite.cc  (working copy)
> > @@ -52,7 +52,7 @@
> > const size_t __len = __bufend - __buf + 1;
> > 
> > const char __err[] = "not enough space for format expansion "
> > -  "(Please submit full bug report at http://gcc.gnu.org/bugs.html):\n  
> >   ";
> > +  "(Please submit full bug report at http://gcc.gnu.org/bugs/):\n";
> > const size_t __errlen = sizeof(__err) - 1;
> > 
> > char *const __e
> 
> Shouldn't that be https ? :-)
> 
> I'd welcome better suggestions for how to deal with this error
> condition (which should never happen) but I can't think of any myself.

ACX_BUGURL([https://gcc.gnu.org/bugs/])
in configure.ac and then use REPORT_BUGS_TO in the Makefile?

Note ACX_BUGURL in gcc/configure.ac needs adjustments too.

Jakub

Re: [libstdc++,PATCH] src/c++11/snprintf_lite.cc - update bug reporting URL

[Jonathan Wakely]

On 08/02/17 08:17 +0100, Gerald Pfeifer wrote:

Index: src/c++11/snprintf_lite.cc
===
--- src/c++11/snprintf_lite.cc  (revision 245267)
+++ src/c++11/snprintf_lite.cc  (working copy)
@@ -52,7 +52,7 @@
const size_t __len = __bufend - __buf + 1;

const char __err[] = "not enough space for format expansion "
-  "(Please submit full bug report at http://gcc.gnu.org/bugs.html):\n";
+  "(Please submit full bug report at http://gcc.gnu.org/bugs/):\n";
const size_t __errlen = sizeof(__err) - 1;

char *const __e


Shouldn't that be https ? :-)

I'd welcome better suggestions for how to deal with this error
condition (which should never happen) but I can't think of any myself.

RE: [PATCH 0/5] LRA fixes for MIPS-like targets

[Matthew Fortune]

Eric Botcazou  writes:
> > @Eric: thanks for the offer of sparc testing; please can you let me
> > know if there are any issues?
> 
> Sure, but can you post a consolidated patch as an attachment? (btw it's
> SPARC instead of sparc, like MIPS instead of mips I presume).

I've attached the consolidated patch. Apologies about capitalisation, I
normally try to get them right everywhere just slipped here.

Thanks,
Matthew




combined_lra_fix.patch
Description: combined_lra_fix.patch

[PATCH] rs6000: Fix spelling of AltiVec in rs6000.opt (PR79397)

[Segher Boessenkool]

It was spelled Altivec in two user-facing messages in rs6000.opt; let's
be consistent.

Committing to trunk.  Will also backport as needed.


Segher


2017-02-08  Segher Boessenkool  

PR translation/79397
* config/rs6000/rs6000.opt (maltivec=le, maltivec=be): Fix spelling
of AltiVec.

---
 gcc/config/rs6000/rs6000.opt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.opt b/gcc/config/rs6000/rs6000.opt
index 803753e..a232d57 100644
--- a/gcc/config/rs6000/rs6000.opt
+++ b/gcc/config/rs6000/rs6000.opt
@@ -142,11 +142,11 @@ Use AltiVec instructions.
 
 maltivec=le
 Target Report RejectNegative Var(rs6000_altivec_element_order, 1) Save
-Generate Altivec instructions using little-endian element order.
+Generate AltiVec instructions using little-endian element order.
 
 maltivec=be
 Target Report RejectNegative Var(rs6000_altivec_element_order, 2)
-Generate Altivec instructions using big-endian element order.
+Generate AltiVec instructions using big-endian element order.
 
 mhard-dfp
 Target Report Mask(DFP) Var(rs6000_isa_flags)
-- 
1.9.3

[PATCH] Testcase for PR79409

[Richard Biener]

Tested on x86_64-unknown-linux-gnu, applied.

Richard.

2017-02-08  Richard Biener  

PR tree-optimization/71824
PR tree-optimization/79409
* gcc.dg/graphite/pr71824-3.c: New testcase.

Index: gcc/testsuite/gcc.dg/graphite/pr71824-3.c
===
--- gcc/testsuite/gcc.dg/graphite/pr71824-3.c   (nonexistent)
+++ gcc/testsuite/gcc.dg/graphite/pr71824-3.c   (working copy)
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -ftree-loop-distribution -floop-nest-optimize" } */
+
+struct
+{
+  int bz;
+} od, ka[2];
+
+int fw;
+
+void
+pc (void)
+{
+  for (od.bz = 0; od.bz < 2; ++od.bz)
+{
+  ++fw;
+  ka[0] = ka[1];
+}
+}

Re: [PATCH] gfortran -- Map REAL128 to REAL kind type with widest precision

[FX]

Hi Steve,

I see Mikael has okayed the patch, but I did not have any time to comment 
prior. I wanted to note that:

 - the choice was deliberate, as the standard allows us to choose which real 
kind REAL128 corresponds to when there are several matching choices. The idea 
behind the current choice was to avoid forcing the use of slower soft-float 
arithmetic when a hardware type existed. I don’t have a strong opinion myself 
on the issue.

 - This is a breakage of the ABI, so we want to write it in the release notes, 
and in the doc about ISO_FORTRAN_ENV.

 - Is this appropriate for stage 4?

FX

Re: [wwwdocs] readings.html link maintenance

[Rainer Orth]

Hi Gerald,

> Index: readings.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
> retrieving revision 1.257
> diff -u -r1.257 readings.html
> --- readings.html 6 Feb 2017 17:47:51 -   1.257
> +++ readings.html 8 Feb 2017 07:10:14 -
[...]
> @@ -632,10 +623,6 @@
>https://en.wikipedia.org/wiki/IEEE_754r;>IEEE 754r, an
>ongoing revision to the IEEE 754 floating point standard.
>  
> -   href="http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51_HTML/SUPPDOCS/OBJSPEC/TITLE.HTM;>
> -  Information on the Digital UNIX/Compaq Tru64 UNIX object file 
> format
> -

while the HTML link on
http://h41361.www4.hpe.com/docs/pub_page/V51B_DOCS/v51b_doclist.htm is
dangling, the PDF link there is still valid.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH 0/5] LRA fixes for MIPS-like targets

[Eric Botcazou]

> @Eric: thanks for the offer of sparc testing; please can you let me know
> if there are any issues?

Sure, but can you post a consolidated patch as an attachment? (btw it's SPARC 
instead of sparc, like MIPS instead of mips I presume).

-- 
Eric Botcazou

Re: New Port for RISC-V v3

[Eric Botcazou]

> I believe we're in.  Thanks for the help!

Congratulations.  There are a few post-integration items to be done:

"If the back end is added to the official GCC source repository, the
following are also necessary:

   * An entry for the target architecture in `readings.html' on the GCC
 web site, with any relevant links.

   * Details of the properties of the back end and target architecture
 in `backends.html' on the GCC web site.

   * A news item about the contribution of support for that target
 architecture, in `index.html' on the GCC web site.

   * Normally, one or more maintainers of that target listed in
 `MAINTAINERS'.  Some existing architectures may be unmaintained,
 but it would be unusual to add support for a target that does not
 have a maintainer when support is added.

   * Target triplets covering all `config.gcc' stanzas for the target,
 in the list in `contrib/config-list.mk'."

if they haven't already been done of course.

-- 
Eric Botcazou

Re: [PATCH] Improve x % y to x VRP optimization (PR tree-optimization/79408)

[Richard Biener]

On Tue, 7 Feb 2017, Jakub Jelinek wrote:

> Hi!
> 
> While looking at the RTL problem when combiner optimizes away
> (x & 0xfffe) % 0x into just (x & 0xfffe), I've looked at VRP
> which optimizes that case well (-O2 only, the PR is -O1), but discovered
> that it isn't generic enough, we actually don't need op1 to be constant
> in this case, a range whose (positive) minimum satisfies it can be handled
> the same.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk (or
> shall I defer it for GCC8)?

Ok for trunk if you adjust the function comment accordingly.

Thanks,
Richard.

> 2017-02-07  Jakub Jelinek  
> 
>   PR tree-optimization/79408
>   * tree-vrp.c (simplify_div_or_mod_using_ranges): If op1 is not
>   constant, but SSA_NAME with a known integer range, use the minimum
>   of that range instead of op1 to determine if modulo can be replaced
>   with its first operand.
> 
>   * gcc.dg/tree-ssa/pr79408.c: New test.
> 
> --- gcc/tree-vrp.c.jj 2017-01-30 19:10:50.0 +0100
> +++ gcc/tree-vrp.c2017-02-07 12:33:32.721482609 +0100
> @@ -9241,17 +9241,25 @@ simplify_div_or_mod_using_ranges (gimple
>tree val = NULL;
>tree op0 = gimple_assign_rhs1 (stmt);
>tree op1 = gimple_assign_rhs2 (stmt);
> +  tree op1min = op1;
>value_range *vr = get_value_range (op0);
>  
>if (rhs_code == TRUNC_MOD_EXPR
> -  && TREE_CODE (op1) == INTEGER_CST
> -  && tree_int_cst_sgn (op1) == 1
> +  && TREE_CODE (op1) == SSA_NAME)
> +{
> +  value_range *vr1 = get_value_range (op1);
> +  if (range_int_cst_p (vr1))
> + op1min = vr1->min;
> +}
> +  if (rhs_code == TRUNC_MOD_EXPR
> +  && TREE_CODE (op1min) == INTEGER_CST
> +  && tree_int_cst_sgn (op1min) == 1
>&& range_int_cst_p (vr)
> -  && tree_int_cst_lt (vr->max, op1))
> +  && tree_int_cst_lt (vr->max, op1min))
>  {
>if (TYPE_UNSIGNED (TREE_TYPE (op0))
> || tree_int_cst_sgn (vr->min) >= 0
> -   || tree_int_cst_lt (fold_unary (NEGATE_EXPR, TREE_TYPE (op1), op1),
> -   vr->min))
> +   || tree_int_cst_lt (fold_unary (NEGATE_EXPR, TREE_TYPE (op1min),
> +   op1min), vr->min))
>   {
> /* If op0 already has the range op0 % op1 has,
> --- gcc/testsuite/gcc.dg/tree-ssa/pr79408.c.jj2017-02-07 
> 16:30:42.439774777 +0100
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr79408.c   2017-02-07 16:32:37.653282317 
> +0100
> @@ -0,0 +1,40 @@
> +/* PR tree-optimization/79408 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-optimized" } */
> +
> +void link_error (void);
> +
> +void
> +foo (unsigned int x, unsigned int y)
> +{
> +  if (x > 7312)
> +return;
> +  if (y <= 7312)
> +return;
> +  if (x % y != x)
> +link_error ();
> +}
> +
> +void
> +bar (int x, int y)
> +{
> +  if (x > 7312 || x < 0)
> +return;
> +  if (y <= 7312)
> +return;
> +  if (x % y != x)
> +link_error ();
> +}
> +
> +void
> +baz (int x, int y)
> +{
> +  if (x > 7312 || x < -7312)
> +return;
> +  if (y <= 7312)
> +return;
> +  if (x % y != x)
> +link_error ();
> +}
> +
> +/* { dg-final { scan-tree-dump-times "link_error" 0 "optimized"} } */
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

[PATCH, MIPS] Calling convention differs depending on the presence of MSA

[Sameera Deshpande]

Hi Matthew,

Please find attached the patch to fix the calling convention issue, 
where argument and result passing convention differed for MSA and 
non-MSA variants.

The implementation of TARGET_RETURN_IN_MEMORY is altered to block V4SF to be 
returned in registers.

Ok for trunk?

- Thanks and regards,
  Sameera D.


Changelog:
gcc/
* config/mips/mips.c (mips_return_in_memory) : Restrict V4SFmode to be 
returned in registers.

gcc/testsuite/
* gcc.target/mips/msa-fp-cc.c : New testcase.